nitro322

I have 1.6.1 packaged and ready to go, but I decided to hold off a bit to get some feedback on the beta release. I'm a bit concerned that 7-Zip may be a bit too aggressive at unpacking now and interfere with some of the other unpackers. Please grab the beta from the link above and post any feedback here. I'll keep this open until tomorrow (Monday) night; after that, I'm finalizing and publishing 1.6.1. Thanks.

The following features have been previously requested but cannot be added/supported. Unless you can provide a specific means of support (such as suggesting a new unpacker that I've not seen before - this is definitely welcome), please do not request them again - your posts will be ignored. Please search the forums for previous discussion of each topic of you'd like more information. Note: This is currently a short list from old notes; I'll add to it as I come across other requests that cannot be supported. Extraction support ASprotect - no freely redistributable unpacker InstallShield 12.x cabs - no freely redistributable unpacker PECompact - no freely redistributable unpacker Skype Installer - custom build of Inno Setup unsupported by innounp Thinstall installers - no freely redistributable unpacker UniExtract features batch processing / multiple file support - this will be coming, but not until the next major version context menu icons / nested context menu - no apparent free way to do this (this may change for WIndows 7) optional debug file - currently cannot be done; it's used for more than just failure output, and UniExtract currently needs this file to read output from other programs, including TrID; I may be able to work around this with some ideas I have in mind for v2.0, but that's still a long way out

You did mention the Office 2007 trial, but I was looking for a direct link. I don't mean to sound rude, but with all the requests I get here, on my forum, and even through e-mail for troubleshooting specific files, I simply can't spend time hunting download links, signing up for trial offers, etc. If you run into any other similar files that I can easily download, please let me know, but I'm going to have to pass on this one.

by the way, changes since last update: Added support for Windows Installer merge modules (.msm) via MsiX Added support for environmental variables (eg., specify %temp% for debug dir) Changed Windows installer support (.msi, .msp) to use MsiX instead of msi2xml CHanged FEAD support to use PEiD rather than TrID for detection Fixed cosmetic bug in Visual C++ SFX status dialog Remove msi2xml helper binary and MSXML download link on MSI selection page Updated PEiD detection of Microsoft SFX cab files for more reliable extraction

I think I'm done. I still need to update the installer (there have been a few changes to Inno Setup since my last release), but in the meantime I have the noinst version packaged and uploaded to my server. I'd really appreciate it if I could get at least a couple people to do some quick testing. Specifically: environmental variable support - should work for debug directory and file/directory selection; any issues? MSI/MSP - did addition of MSM affect detection of MSI and MSP? 7-zip does generic resource extraction on unknown .exe files now - does this negatively affect extraction of files that previously worked? FEAD support - does new PEiD detection work properly? Any false positives? Windows 7 support - no specific changes, but if anything doesn't work quite right, please let me know Thanks. Please try to report back ASAP - still hoping to get the final version out tonight. Heck, also let me know if you don't find any problems, that'll also help. :-) Download: http://www.legroom.net/public/uniextract161beta_noinst.rar

Well, I lied. I got ambitious and decided to add it to 1.6.1. :-) Seems to work ok, but it hasn't been exhaustively tested; will probably need to release a beta to make sure there are no side effects.

Two quick updates: Added detection (TrID) and extraction support for MSM files Dropped msi2xml in favor of MsiX In my brief testing, MsiX seems to do everything at least as well as msi2xml, so I didn't see a need to keep it around. I only commented out msi2xml support, though, so I can easily re-add it later if necessary. Again, feedback would be welcome here. Also, with MsiX, is there a still a need to have the Total Commander MSI extractor as well? Ideally I'd like to knock this down to just two options: an administrative install by default (this is the cleanest option, when it works), and a "ripper" such as MsiX to forcibly extract files when the administrative option fails or is restricted.

FEAD support does exist, but like many formats in UniExtract it relies on accurate filetype detection. I was using TrID to detect FEAD files, but it wasn't very reliable - it would detect FEAD files with a low degree of confidence, but it'd also detect other executables as FEAD as well, leading to false positives. I tried to compensate by having it do some extra checks, but this wasn't very reliable either. So... for 1.6.1 I downloaded as many FEAD packages as I could find (which basically consists of the one you linked to and a bunch of versions of Adobe Reader) and generated some new signatures using PEiD rather than TrID. So far it seems to be much more reliable for this. Give 1.6.1 a show when it's released and see if it works for you. In the meantime, if anyone comes across other FEAD packages that aren't detected properly please let me know and I'll update the PEiD signature for future releases.

Added in 1.6.1 for MSI and MSP. MSM untested because I don't have sample files. Edit: MSM support added as well

I've mentioned this a few other times already, but it's worth repeating - support for this already exists, but it's dependent on accurate detection by PEiD. In order to add support for newer files I need to refine the PEiD signature, and in order to do that I need files to test myself. If you can provide download links to the installers you're having trouble with, I'll check them out and see if I can generate better PEiD signatures.

Thank you, Noise. I needed a good laugh today. :-)

I can only help by checking out the file in question. Is this available someplace I can download for testing?

Dude, don't take it personally. I haven't been doing any UniExtract development at all for a while, so it's not like I'm singling you out. This is how uudeview chooses to output the decoded file: > uudeview -p . -i Dancing_Dog_.wmv.b64 Loaded from Dancing_Dog_.wmv.b64: '' (UNKNOWN.001): part -1 Base64 Found 'UNKNOWN.001' State 16 Base64 Parts 1 OK File successfully written to ./UNKNOWN.001 1 file decoded from 1 input file, 0 failed I don't know where it gets the name from, but I'm assuming it's choosing that because whatever encoded the file did not specify a filename in the encoding. If I could assume that only one file would ever be decoded by uudeview, then I'm sure I could have UniExtract rename the file back to the original filename after decoding was complete. However, I can't make that assumption. uudeview is used for a number of encoding formats, some of which can include multiple files. I can't just arbitrarily rename some files and not others. I could maybe have it check to see if only one file was output and that filename was unknown.001 and then rename it, but I'm not sure how beneficial that would be. Anyone else have thoughts on this?

Support for environmental variable just doesn't exist at this time. I'd like to add it - this has come up before. You can actually specify %TEMP% (or whatever else) in the installer and it'll work properly, but this gets converted to an absolute path when saved in the UniExtract preferences file, so it doesn't help too much for portable versions. I'll try to get this included in the next major version.

I don't disagree with your point, but it was the best approach I could come up with at the time that didn't involve crewing up the rest of the layout. I'll give some thought to improving this for the next release.

This will kind of work in 1.6.1. 7-Zip added support for generic .exe resource unpacking, which works here. Unfortunately, the output is kind of ugly at this time. I can maybe clean it up a bit with UniExtract, but that won't be done for 1.6.1. In order to extract this file with 1.6.1, select the 'not installshield' option and 7-zip should unpack a few poorly named (and hidden) files. Fine the file named [0], rename it to 0.exe, then run that through UniExtract. This should be seen and extracted as an InstallShield2 installer. I can see some limited usefulness for this, but honestly not much. I don't want to risk accidentally deleting files that are still needed or wanted, and it usually isn't too tough to hit the delete key after extraction is complete. For the batch processing part, again, it shouldn't be too difficult to add a follow up line to delete the source files after UniExtract is done (after, of course, verifying that the files were properly extracted). I'm not ruling this out, though. Will give it some thought. If anyone else has feedback on this, please let me know. I'm not "refusing" anything. I've thoroughly explained, on multiple occasions, why this currently can't and won't be done. Please search the forum for additional information. This is good news. I'll look into it for the next major release. This is most likely another detection issue - if you can provide examples, I'll see what I can do. Please check out the new MsiX support in 1.6.1 and let me know if that works for you. MsiX makes four methods for MSI extraction and three for MSP extraction... I really don't want to add more if possible, but then again I'm always open to better solutions. Please compare and let me know how it works.

Will check it out for the next major release, but unless there are very clear and significant advantages I'll probably stick with PEiD. I've added quite a number of custom signatures to PEiD for recognizing new file types, and it'd be difficult to reliably recreate them for another utility, not to mention update all of the UniExtract bits that look for specific PEiD output. I can use WinZip because it can't be freely redistributed. If you can provide some example files, though, I'll look for an alternative way to support the files. This is already supported, but requires accurate PEiD detection. If you can provide examples that fail I should be able to update the PEiD custom signature for better detection. This is also supported, but again, it requires accurate filetype detection, this time using TrID rather than PEiD. Ditto on the examples part.

Will look into it for next major version. I've looked into all of these before, but was not able to find any freely-redistributable unpackers for them. If you know of any, please suggest here, otherwise this will need to stay on the unsupported list. Not sure what you're looking for here. Can you elaborate? Would love to add support for both of these, but as Dumpy Dooby pointed out, it requires an external DLL to implement, and yes, it's more difficult than you might imagine. The main problem, though, is that I cannot (or could not - it's been a while since I looked into this) find any free way to do this. All of the examples I found required the commercial version of Visual Studio to create an appropriate DLL; even the free/express versions wouldn't work because MFC is required. I'm not interesting in buying Visual Studio for this, and even more importantly I'm not interested in writing/providing code that requires a non-free product to compile. If anyone can provide examples of how to do this with a free solution, I'll try my best to add support for it, but otherwise this won't happen.

I'm fine with this, but need sample files. I don't know what you're requesting here. If you're referring to the helper binaries, they are all included, both with the installer and noinst versions. If you're referring to something else, please clarify. Fixed in 1.6.1. Support for this was already included, but I needed to update the PEiD signature to properly detect this file.

I haven't ruled them out, but I haven't gotten around to checking them out yet, either. The ToDo file on the UniExtract website is the closest I have to a list of priorities. It's updated along with each new release. Generally, tasks at the top are more recent recent or important issues, so I'll take a look at them first when I begin a new development cycle.

This was packed a newer version of Inno Setup, which requires an updated version of innounp. It'll be supported in 1.6.1.

The problem with that approach is it's possible to extract files to an existing folder filled with other files. For example, I very frequently use the 'UniExtract Here...' option to extract files, and I most definitely don't want to delete the current working directory, nor even offer the option. I also may extract files directly to C:\Windows or some other such directory, depending on what specifically I'm extracting, and obviously we wouldn't want to delete that either. This would be useful when using the 'UniExtract to Subdir...' option, but I don't think covering that one possibility alone would be worthwhile. It could help in some circumstances, but it'd also be incomplete and provide inconsistent feedback. On the other hand, tweaking the error message to include a statement about the folder already existing would work, but there's a catch here as well - this would require an update to the translation files, which I won't be able to do for this release. It's a very time-consuming process to get support for all of the foreign languages updated. So, this option would also need to wait until the next major release.

Thanks for the suggestion. Will look into it. If it's not too tricky (MSI support is fairly ugly within UniExtract) I'll try to get it included in this release. Otherwise, it will be targeted in the next feature release. Done, for MSI and MSP files (MSM supposedly support as well, but I have none to test). Was nice and easy; I like this utility. :-) Here's a request of my own - can someone do some testing of this against the other MSI and MSP options and see if any of them can be dropped in favor of this? I did some pretty thorough testing of all the existing options and found that they all can be useful in certain circumstances, but if MsiX can fully replace one or more of them then I'd much prefer to trim that list.

Thanks for the suggestion. Will look into it. If it's not too tricky (MSI support is fairly ugly within UniExtract) I'll try to get it included in this release. Otherwise, it will be targeted in the next feature release.

Well, it's not exactly incorrect, but I'd agree that it's insufficient. I've noticed this problem before, but I can't think of an obvious way to fix it. Currently, UniExtract determines success based on output directory size: it checks the size before extraction and again after extraction, and if the after size is <= the before size than failure is assumed. Ideally, I'd prefer to use one of the following methods: check list of files in archive and compare against output files check exit code of helper binary to determine success or failure In some specific cases, I do use the above techniques for determining if a specific file is supported and/or successfully extracted, but there's no good way to generalize the checks. Eg., if I only had to worry about verifying 7-Zip output, then I could do it easily enough as I could write some very specific checks (plus, 7-Zip reliably sets error codes, making it even easier). Unfortunately, I need to deal with 40 different helper binaries, and not all them play nice. In fact, most of them don't. I'll give this some though to see if I can come up with a good, general, and efficient method to do better error checking, but it may need to wait until the next feature release. Thanks for reporting - this does need to get addressed at some point.