nitro322

I'll check it out. Thanks for the suggestion, sample, AND extraction utility. :-)

Are there any free downloadable examples? I can look into this to determine whether or not UniExtract appears to be successfully extracting the contents, but I can't tell you what to do with it beyond that point as I don't know anything about how the Oblivion mods are supposed to work.

I don't know autoit, but that's an odd arrangement of quotation marks in the command string. There's an even number ok, but I can't pair them up sensibly. Actually, this is the exact line of code: runwait($cmd & $inno & ' -x -m "' & $file & '"' & $output, $outdir) And those quotes do indeed match up. The full thing translates to the following (making assumptions for the paths): c:\windows\command.com /c innounp.exe -x -m "c:\path\to\file.exe" | tee.exe c:\uniextract.exe The problem you're seeing is not from invalid syntax in that line of code, but rather from various path and environmental variable issues that I could never work out quite right under Windows 9x. You can search through the really long main Universal Extractor thread for some more details if you'd like. Actually, it is. Software vendors can't support a given OS perpetually, and I think when the OS vendor itself end-of-life's the OS it's time to move on. Think about it - a line has to be drawn somewhere, otherwise the same argument could be made for why Windows 2.0 isn't supported. With that said, though, I didn't intentionally remove support for Windows 9x in UniExtract. It just never really worked right to begin with. :-) The big difference with 1.6, however, is that the current versions of AutoIt has moved to native Unicode binaries. Windows 9x doesn't support this, and as such new AutoIt applications will not run under Windows 9x. They still offer an option to compile ASCII binaries instead for use with Windows 9x, but I'm just not interested in maintaining separate versions, particular when one of them is for an OS that's been end-of-life'd and will be receiving no new security patches and updates. Plus, as I already mentioned, support for Windows 9x was always buggy to begin with (which is why it was never officially supported). I don't mean to come across as an a** here, and I apologize if I do. This topic has come up a lot, and while I'd love to be able to fully support Windows 9x, it's just not feasible for a number of reasons.

Actually, if UniExtract is clobbering your existing PEiD settings, then that's a bug. I have code in there to deliberately work around that issue - any existing settings should be preserved and reset after execution is complete. I'll look into it.

I'm having some trouble understanding what you mean. I believe you're suggesting that someone create an "unofficial" version of Universal Extract that natively includes support for formats for which no freely redistributable utilities exist, such as InstallShield 12.x, later versions of Stuff-It, etc. The problem with this doing this is that it's illegal, at least in the United States. Even if someone were to create an unofficial version, that unofficial version would be illegal to distribute, host, etc. While I'd love to add support for these formats, officially or unofficially, there's just no way to do it legally. Probably the best option would be to add support in the code for these formats, but require the end-user to provide the support utilities to do the extraction. For example, I could add support for InstallShield 12.x, but not include the needed iscab.exe (and related) utilities. If the end-user has a legitimate copy of InstallShield, he could copy these utilities to the bin\ directory, and then it'd just automatically work. I'm not sure if I want to go down that road, but I've seen similar techniques done before in other open source apps, and as far as I can tell it should be perfectly legal. As for source code, UniExtract is already released under the GPL. Anyone's welcome to modify the source however they'd like in accordance with the terms of the GPL.

I saved a copy of this and will look into it once I start working on the next version.

Ahh. That makes sense. THanks for the clarification. This issue has come up a whole lot. Please search the original Universal Extractor thread for lots of discussion on why it hasn't been implemented, and why it (unfortunately) likely won't be implemented any time soon.

You can. These options are on the "Select Additional Tasks" page of the installer. What do you mean? I agree that'd be nice, but there are some technical challenges involved. Feel free to add it to the Feature Request thread, though. It's worth looking into. This has come up once or twice before, and the file compression is fundamentally a completely different problem than what UniExtract is meant to solve. For some archiving utilities, such as WinZip, it makes sense to do both; WinZip is meant to control Zip files, which can be both compressed and extracted, so it makes sense that WinZip should be able to handle both operations. However, UniExtract deals with all kinds of different formats, including executables, ISO CD-ROM images, etc. This is stuff that simply can't be packed or compressed in the traditional sense. If you extract files from a Wise installer, for example, and want to replace one of the included files with your own, you can't recreate that installer without using Wise's own utilities. UniExtract can't do anything about this. If you want to be able to create archives in multiple different formats, I suggest using 7-Zip. It has pretty flexible format support, and can handle most non-proprietary formats.

Wow. You've really been paying attention, haven't you? :-) foszhila45, mushu13 is correct on both counts. Proper multiple file support has been requested before, and it's something I'd like to add, but it'll require some fairly significant changes. It's on my radar for 1.7. In the meantime, if you're using the installer version with context-menu support, you actually can extract multiple files at once by highlighting more than one, right-clicking, and select Extract to Subdir (or Extract Here). Windows Explorer will spawn multiple independent UniExtract process at this point, and extract all files concurrently. Of course, this approach can have problems, so it's not exactly recommended, but it should generally work fine as long as you don't throw a crazy amount of files at it. Integrating helper utility output into the main UniExtract window, rather than spawning a separate cmd.exe window, is something that's been on my todo list for a while. However, it'll require much more significant changes than the multiple file support mentioned above, and there are various other challenges to take into account, such as providing input (for passwords, for overwrite confirmations, etc.) as well as output. This is such a major, fundamental change in functionality that it'd come essentially as a 2.0 release. Of course, there's no telling when (or if) that'll happen, but I'm certainly keeping it in mind.

I also noticed some functional changes Adding files using the filepicker is broken, and there may be other problems as well. If you want to roll your own build, I highly recommend sticking with AutoIt 3.2.10.x for now. Edit: Nevermind. The filepicker issue I mentioned above is actually a bug in my code. If you use the Preferences GUI to toggle the history option, and then select a file using the filepicker without first restarting UniExtract, it will output the file name incorrectly to the input box. I'll fix this in 1.6.1, as well as, obviously, updating it to use the latest version of AutoIt. However, there still may be some other changes when used with 3.2.12.0, and I still recommend sticking with 3.2.10.x just to play it safe.

No, unfortunately. This has come up several times before. UniExtract has limited support for Setup Factory 6.0 installers, but I can't find any utilities capable of extracting files from later versions.

What version of AutoIt are you using? I seem to recall seeing a number of incompatible changes in the most recent release, so I stuck with the version I was using when last doing active development, which was 3.2.10.0. I didn't want to risk introducing any new bugs this late in the release cycle. Can you try compiling with 3.2.10.0 and let me know if that works? I can add a warning note about it on my website. Edit: These are the changes I mentioned. I see a couple of lines in there related to constants and includes. http://www.autoitscript.com/autoit3/docs/s...ing_changes.htm Cool, thanks. Will get it fixed.

Really? Cool, I'll have to check this out. I didn't think 7-zip supported this. This should work in the current release. Do you know what's improved about it in 7-Zip 4.60? This is absolutely correct. However, in the case of incremental improvements to existing supported files, such as the WIM and CHM support that freeko mentioned above, simply upgrading 7-zip should work. Of course, I can't officially recommend it as I can't say that with certainty, but if you have a WIM or CHM file that's not working properly, it can't hurt to try updating the 7-Zip binaries. Just keep a backup of the originals in case something goes wrong (or just reinstall UniExtract).

I just released the final version of Universal Extractor 1.6. You can find more info and download links in the Universal Extractor Latest Version thread. I'm also locking this thread. It's been a hell of a ride, but after 3 years and 872 posts, I figure it's time to let it rest. :-) Now that we have our own subforum, let's take advantage of it. Bug reports and features requests should go into the pinned threads, and feel free to start a new thread for anything else. Enjoy the new version.

The latest 7-zip beta added support for XAR archives and UDF and DMG/HFS images. This sounds like something worth supporting in the next version of UniExtract. :-) Edit: The latest 7-zip beta also directly supports LZMA files. Have UniExtract use 7-zip to decompress these files rather than the separate lzma.exe binary currently used.

Cool, thanks. I'll download them and check them out, but keep in mind that support (if possible) won't be added until the next version.

Project Details Website ChangeLog ToDo Archive All details regarding usage and supporting formats can be found on the main website link above. Latest Stable Version - 1.6.1 This released is focused on bug fixes, reliability improvements, and component updates. The few new features include: Support for environmental variables (eg., specifying %temp% for the debug file localation) Support for XZ, MSM, and NBH files Improved MSI and MSP support Download Links Installation Package Binary Archive Source Archive Note: Please use the official links provided here instead of hotlinking directly to the files. The backend server will change soon and any direct links will fail. Changes Added support for environmental variables (eg., specify %temp% for debug dir) Added support for XZ compressed files and txz/tlz archives via 7-Zip Added support for Windows Installer merge modules (.msm) via MsiX Added support for NBH files via NBHextract Added translations for Armenian, Czeck, Persian (Farsi), Serbian, Swedish Changed 7-Zip unpacking behavior; now attempts brute force extraction only after External PEiD scan; change due to aggressive .exe resource extraction in new versions Changed Windows installer support (.msi, .msp) to use MsiX instead of msi2xml Changed LZMA support to use 7-Zip for extraction Changed FEAD support to use PEiD rather than TrID for detection Changed following formats to call 7z by name (also see 7-Zip debug comment): bz2, chm, gz, tar, Z this is mostly for code cleanup; functionality should be the same Fixed InstallShield 5.x regression in 1.6 preventing successful extraction Fixed bug in extraction of non-TAR LZW compressed files Fixed bug that prevented picking files after toggling history option Fixed bug in display of history combo boxes when no items listed Fixed cosmetic bug in Visual C++ SFX status dialog Fixed cosmetic bug in status dialogs due to extra padding by AutoIt Removed lzma helper binary Removed msi2xml helper binary and MSXML download link on MSI selection page Removed Windows NT 4.0 support from installer Removed debug output for 7-Zip, arj, hlp; buffers output, preventing proper user feedback and input prompts Updated success/fail detection to check output directory timestamp; can detect cases where files are overwritten, which old method missed; will still consider failed if user chooses not to overwrite files, or if all files are written to a subdirectory of the output directory Updated RPM and DEB support to extract interim CPIO and TAR files Updated FEAD support to workaround read-only permission issue Updated Zip support to log unzip output and permit minor reported unzip errors Updated PEiD detection of Microsoft SFX cab files for more reliable extraction Updated some UniExtract window sizes for better internationalization support Updated translations for Italian, Korean, Russian Updated 7-Zip to 9.13 beta Updated AutoIt to 3.3.6.1 and replaced deprecated _ArrayCreate UDF Updated InfoZip unzip to 6.0.0 Updated Inno Setup to 5.3.9 Updated innounp to 0.31 (supports Inno Setup 5.3.9) Updated InstallExplorer WCX to 0.9.2 Updated MSI WCX to 1.2.1 Updated PEiD to 0.95 Updated UnRAR to 3.93 Latest Development Version - N/A

Dude, that's some hardcore testing right there. I actually found that myself earlier tonight while working on some documentation updates, but I didn't bother mentioning it because I didn't think anyone would actually notice. :-) It's already been fixed.

Crap. I was able to confirm that this is exactly what's happening by simply adding another checkbox to the window, but I have no idea how to actually fix it. Just getting the custom dialog in the first place was difficult enough. :-( I'll mess around with it and see if I can make it work, but worse case this may be pushed off until 1.7. Thanks for reporting this, though. Obviously this is something that needs to be fixed, though it's impact right now is fairly minimal.

I'm using a custom dialog window here, so maybe Inno Setup doesn't automatically ad a vertical scroll bar when necessary like it does with the other dialog windows. I'll need to investigate this. That works for me, though it won't be done until the next version. Feel like adding it to the feature request thread?

You can actually try this yourself. AutoIt includes two compiler versions - the default (which I use) compiles as unicode and only supports NT+. The other compiles as ANSI and support 9x. All you would need to do to try this is download the noinst and source packages and compile using the ANSI compiler. To be honest, though, I'm really not interested in creating separate releases for 9x, particularly since support for that platform was never very good to begin with. mushu13 already answered this (very accurately in fact, but for the record I'd like to state that if I ever have to completely abandon UniExtract, I'll make sure it's known. Unless you see an official statement stating that UniExtract development has ceased, just assume that I got busy with something else. :-) Also, should that ever happen, I'll be more than happy to turn over development and maintenance to someone else. No, Hebrew has not been previously contributed. If you'd like to create this, just following the English.ini file. Where did you find this version, and is it freely redistributable? All other utilities have already been updated. Looks interesting. Will check it out. One thing that you need to keep in mind is that freeware != freely redistributable. StuffitExpander may be free to download and use on your own computer, but I can't rip out certain components, embed it in my own (competing) application, and redistribute it to anyone that wants it. Unless they've changed their license recently, no version past 6.x can be freely redistributed. Of course, I'd love to be proven wrong on this. If anyone can find proof that these newer versions are freely redistributable, please let me know. Thanks, I hadn't noticed this. Will get it included.

Do you mean you get this error when you try to compile your own installer for Universal Extractor? Assuming you're using the sources available in the *_source.rar package, you shouldn't have any problem. You do also need to grab a copy of clihelp.iss from my website, which it sounds like you've already done. Make sure you have the latest version. I compile the official installer using the exact same files, so I know it should work. I'm sorry, but what? I didn't follow you at all? NRG images are already supported in 1.6. Can you provide a download link?

Both of those files are successfully extracted with v1.6rc. They appear to be Inno Setup installers. Try again with the RC version and let me know if you still have any trouble. I tried using this in the past, but I could never get it to work quite right for me. I'm not even talking about integrating it into UniExtract - even manual attempts failed. I gave up on it and moved to the other three options that we now have, which, so far, can unpack everything I've thrown at it. Looks useful. Will check it out. Also looks useful. Will check it out. The problem with supporting formats like this is that I can't add support for something unless I have sample files to work with, and it's difficult to find or create files that require proprietary applications to create. If someone can point me to some sample files (I typically require two separate samples of each format), then I'll be happy to look into adding support. Thanks for the suggestions.

Oops. Fixed now. Thanks for the heads up.

I agree that it would be a very nice feature. However, aside from the amount of time it'd take to properly implement and test, I'm reluctant to do this because it can potentially break support for certain filetypes. For example, if a new version of innounp was released that required an additional argument, that new argument has to be hardcoded into UniExtract. Otherwise, UniExtract could no longer open Inno Setup installers, because it wouldn't know how to properly call innounp to do the job. It looks like you're running this under Windows 9x. I had to throw some ugly hacks in there to make it semi-functional under that OS, but, really, it was never that reliable to begin with. You just hit one of the bugs that I was never able to fully work out. Unfortunately, there isn't really anything that you can do about it.