nitro322

Ok, I found the problem. It's actually a couple different issues that combine to cause the crash, which is why I never saw it before. As you know, UniExtract first tries to use isxunpack to extract an InstallShield installer. If that fails, it then prompts the user to try the cache method. Although UniExtract is crashing after trying the cache method, the issue actually occurs during the isxunpack stage. isunpack does not allow me to specify the output directory, so to work around that I move the file to the output directory, attempt to extract it from there, then move it back right after the attempt. Ordinarily this will work fine, but it turns out that it will fail if extracting a file from the root directory of a drive (C:, D:, etc.). Annoyingly, Windows requires a backslash at the end of the target directory name when copying/moving files to a root directory, even though any other directory will work fine. To illustrate: move c:\old\test.exe c:\new\ move c:\old\test.exe c:\new move c:\old\test.exe c:\ move c:\old\test.exe c: The first three cases work fine and the file is moved as expected. The last, however, does not, and the file is left behind in the old directory. This is essentially what's happening for you. Now, the crash issue occurs at the next step. UniExtract knows that extraction failed, thinks it moved the file back to its original location, and procedes to try the cache method. However, when it tries to execute the file, it crashes because it's not found. Whew. So, now I need to spend yet more time working around Windows filesystem inadequacies. Yay. Thanks for reporting the issue - I'll make sure it works properly before the final release.

That's really odd. It should be extracted to the directory you specify. How are you calling UniExtract? Eg, from the context-menu (which option are you clicking, and what directory do you specific if using the 'UniExtract Files...' option?) or the command line (can you post the full command line)? InstExplorer support for modern InstallShield installers appears to be broken. It'll recognize and extract the files (as you show in your screenshot), but the output is incorrect. Try opening one of the .ini files - on my system it's binary nonsense. Try running the .msi file - you should be told that it's not valid. I experimented with adding InstExplorer support to the list of options for InstallShield, but rejected it for this reason. This is also odd. I coded UniExtract specifically so that it can handle long paths, for both itself and any files it's trying to extract. I'll check this out and see if I can duplicate it, but off the top of my head I have no idea why it's failing here. I'll look into it. I'm generally not a fan of message boxes that can't be moved or hidden, though.

I couldn't reproduce this. Here's what I found: UniExtract does successfully unpack cfmail.exe using the /b (cache) switch method. So, I'm not sure why you had to mess around with other tools in the first place. IShield.wcx, along with i5comp and i6comp, only work with InstallShield cab files, not executable installers (as far as I can tell). I tested the IShield.wcx file just to be sure, and it would not unpack cfmail.exe. To verify that I was using it correctly, I tried unpacking some other IS cab files I use for testing, and it worked fine for them. So, I seem to have the exact opposite results from you: UniExtract works fine, and the alternative you suggested does not. Very odd. Can you please double-check this? If you're still having the issue, could you provide some more details and/or screenshots? Thanks.

I wanted to put out one last call for comments and/or bug reports. I'm waiting on just four language updates now; as soon as I receive those I plan on publishing the final version. If you've found any issues not previously discussed, now would be the time to report them. I never was able to do anything about cutting down the false positives, but I made a couple changes that I think should help reduce the problem: InstallShield installers have been moved to the bottom of the list for TrID matches, which means that if any other "possible" matches are found, they will be acted upon first I switched to providing a choice for users between isxunpack and using the /b (cache) switch. While this won't really do anything about false positives, it moves InstallShield support into line with the other installers that have multiple unpackers (such as Wise), providing a more consistent user experience. Of course, I'm still open to any other ideas you may have.

Not currently, but that's not a bad idea and shouldn't be difficult to implement given that all failures should already be routed through a single terminate() function within the program. I'll look into it and see if I can add it to the upcoming version. Edit: Well I added it, but after giving it some more thought I'm not sure how useful this will really be. If UniExtract detects an error during extraction. First, the new error codes: 0 = successful exit or user-initiated cancel 1 = supposedly supported file, but extraction failed 2 = unknown executable - cannot be extracted 3 = unknown filetype - cannot be extracted 4 = invalid output directory specified As for the question about its usefulness, I display an error message after every non-successful exit. So, any "failures" (as designated by return codes 1-4 above) already display a message to inform the user of what happened and why. If you have a dialog message already explaining the problem, setting a program-readable error code seems rather redundant. Maybe I'm not thinking this all the way through, though. Any other thoughts on this?

Thanks, Perch. Once again, this is fantastic feedback! I've been working on some fixes, which should be completed soon. The one thing that still concerns me, though, is the InstallShield false-positives. TrID recognizes a LOT of files as possible InstallShield installers, even completely unrelated stuff like the Windows gVim binary. I tried fine-tuning it a bit, but I don't think I'll be able to do much to prevent it. I'm still playing with some ideas, though. Thanks for reporting it - I had seen it myself, but wasn't sure how much of an issue it'd be until you also reported it. The installer should behave that way now. Ie, if I install UniExtract as an administrator, any standard users should be able to use it upon next login. Does that not happen for you? Can anyone else confirm this issue? That's a great idea, and I'm pleased to say that thanks to the new signature detection in 1.5 (provided by TrID), this works automatically in version 1.5. No code changes necessary. W00t.

Well, I actually have three replies for this: 1. I do not run Vista, nor do I expect to have access to a copy anytime soon. As a result, I cannot guarantee Vista support. I will make a best-effort attempt to fix reported problems, but such fixes may be delayed or require assistance from someone that does use Vista. Any Vista users should keep this in mind. 2. The latest version of Inno Setup contains a lot of Vista compatibility updates. I don't know if any of them would relate directly to this issue, but it's possible that this version (which will be used to create the 1.5 installer) may fix the problem on its own. 3. More likely, though, this seems related to another problem that users reported when running as a standard user under Windows XP. Standard users do not have access to write to HKCR registry tree. I have an idea of how to fix this, but it would appear to require duplicating nearly 500 lines worth of registry entries, and I'd prefer not to go that route. I'm still exploring other possible fixes. I'm going to try to have something in place for the final 1.5 release, but again, I cannot make any guarantees. In the meantime, you may want to try MagicAndre1981's suggestion.

It took a whole lot longer than expected, but I've finally finished the beta version of Universal Extractor 1.5. I'm including a complete changelog for the beta at the end of this post, but the biggest changes include: Filetype signature scanning via TrID Support for a large number of new installers and formats via Total Commander plugins thanks to cmdTotal Multiple new languages and internationalization tweaks Before posting download links, I'd like to make a few things clear: This version contains a large number of changes, include several significant changes in functionality. Because of these changes, I fully expect there to be bugs. The reason I'm posting a public beta is because I need help finding all of them. I've done as much as I can myself; I need some other eyes looking it over now. If version 1.4.2 is working fine for you and you're not interested in beta testing 1.5, please stick with 1.4.2 until the final version of 1.5 is released. If you do download 1.5, please report any and all bugs and other feedback to this forum so I can fix the issues as quickly as possible. With that said, if you're interested in testing this version and providing feedback, you can download the no-install version from: uniextract15_beta_noinst.rar Edit: Damnit. I'm having problems with my web host right now. I'll post download links first thing in the morning. Edit 2: Download link fixed. Edit 3: I forgot to mention, the language files included in this beta are incomplete. This is a known issue (I didn't provide the beta to the translators until just yesterday), so there's no need to report any errors if you see an English phrase instead of the expected language. This will be updated for the final release. Here's the beta ChangeLog: Added filetype signature scanning via TrID; no longer dependent on extensions Added support for Adobe Reader 7.x and 8.x installers Added support for Base64, Quoted-Printable, UUe, and yEnc files via uudeview Added support for Gentee, Installer VISE, and SetupFactory installers via cmdTotal + InstallExplorer Added support for InstallShield 3.x SFX installers via stix Added support for InstallShield 5.x CAB files via i5comp Added support for Itsy packages (.ipk) Added support for Outlook Express (DBX) archives Added support for Pea archives Added support for SIS (SymbianOS) installers via cmtTotal + PDunSIS Added support for StuffIt packages (.sit, but not .sitx) Added support for Windows Installer patch (.msp) files via cmdTotal + MSI Packer Plugin and 7-zip Added support for Zoo archives Added support for files without an extension (eg, unknown files) Added Polish, Russian, Slovak, and Spanish translations Fixed bug that prevented extraction of UPXed Zip and 7-Zip installers Fixed ACE SFX error handling to continue processing if extraction fails Fixed InstallShield cache mode handling to prevent hangs Removed 'i6comp by group' option for InstallShield cabs Removed expand.exe in favor of using 7-Zip for Microsoft Compressed files Updated UniExtract to scan signatures by default; extensions used as backup Updated UniExtract to display icon in system tray during extraction Updated UniExtract to select Cancel by default on PEiD and log prompts Updated UniExtract internationalization support to simplify translation Updated UniExtract with many code changes to increase robustness, simplicity, and efficiency wherever possible Updated support for Inno Setup, NSIS, Wise Installer, and and InstallShield via cmdTotal + InstallExplorer Updated ACE support to include non-PE ACE SFX archives Updated BIN/CUE support with better conversion support and validation Updated InstallShield CAB support to display progress dialog Updated InstallShield cache extraction to support multiple nested MSIs Updated InstallShield cache extraction to better detect installer window Updated MHTML support to include option for extraction via cmdTotal + MHT Packer Plugin Updated Wise Installer support to include non-PE Wise installers Updated Wise Installer support to include unzip option Updated Wise Installer support to append missing file extensions Updated Wise Installer support to provide option for removing temporary files Updated Microsoft SFX CAB support for better detection and robustness Updated Windows Installer support to append missing file extensions Updated Windows Installer support to include option for extraction via cmdTotal + MSI Packer Plugin Updated AutoIt to 3.2.2.0 Updated bin2iso to 1.95 Updated Inno Setup to 5.1.9 Updated UnRAR to 3.62

It looks like it should do it, just to a different location: C:\1\Scorched3D-40.1d>where /r . "white.bmp" C:\1\Scorched3D-40.1d\$_OUTDIR\data\accessories\sa6\white.bmp C:\1\Scorched3D-40.1d\$_OUTDIR\data\tanks\tux\white.bmp C:\1\Scorched3D-40.1d\$_OUTDIR\data\windows\white.bmp I'm not familiar with this game, so I don't know for certain if these are the files you're looking for, but I've noticed that installers sometimes store files internally differently than they install to disk. One common example is that an installer might include both 32-bit and 64-bit versions of an .exe - which one gets installed depends on your system, but both are included in the installer so both may be extracted when "ripped" from the installer. Anyway, if that's NOT what you're looking for, then I'm afraid I can't help you any further. UniExtract relies entirely upon 7-Zip for NSIS support, so if 7-Zip is missing something then there isn't really anything I can do.

I'll be releasing a beta version for 1.5 within the next day or so. Please test that version and let me know if you still get the error. If so, an actual copy of the message or screenshot should help greatly. Thanks for the suggestions, but 1.5 is pretty much frozen at this point. I'm just finishing up some testing and debugging right now. I'll keep these in mind for the next version, though.

Thanks. I've added support for it in the dev version.

I guess not. I missed the IS7 reference in your first post. Sure would be nice if there was an i7comp, huh? Glad to hear you got this working.

i6comp does indeed support these types of files: C:\1\Test\iscab>dir 04/24/2002 06:01 AM 1,203,219 data1.cab 04/24/2002 06:03 AM 46,414 data1.hdr 04/24/2002 06:04 AM 11,782,898 data2.cab 3 File(s) 13,032,531 bytes 2 Dir(s) 5,239,394,304 bytes free C:\1\Test\iscab>i6comp l data1.cab <SNIP> Date Time OrigSize Attr CompSize Ind,Vol FileName ========== ===== ========= ==== ========= ======= ================= 12-16-1999 10:24 28529 A___ 5841 0, 1 corecomp.ini 01-04-2000 06:44 151552 A___ 66724 1, 1 ctor.dll 01-04-2000 06:39 32768 A___ 4524 2, 1 objectps.dll 01-08-2000 06:40 208896 A___ 90177 3, 1 iuser.dll 07-09-1999 21:43 0 A___ 0 4, 1 ILog.dll <SNIP> Now, it's possible that the particular files that you are working with may not be supported by i6comp, but just because it's split into multiple files does not mean it's unsupported. If that's the case, I'd recommend trying i5comp instead, which can sometimes work in cases where i6comp fails. You may also want to try using WinPack, which includes both of these utilities, i3comp for even older archives, and a nice little GUI frontend. You can read more about WinPack here: http://snoopy81.ifrance.com/snoopy81/en/winpack.htm If you really want to use InstallShield Cabinet Viewer instead, you'll have to do a bit more work. I don't know why, but as you've seen extraction doesn't work quite right. I can't remember the details of what I had to do to make it work, but I think it involved listing the files first, reading through the list and creating all subdirectories, then running iscab again to actually extract the files. I'm pretty sure all subdirectories have to be created first. It's a pain, so like I said earlier I'd recommend trying i6comp/i5comp instead ad using this only as a fallback option.

Well, the update is (still) taking longer than expected to finish up. Let's set a new timeframe of Wednesday/Thursday for the beta. They should already be supported. Can you provide some more information about what exactly is failing? What version of UniExtract are you using? What application are you trying to extract? Can you post a download link for it? Unfortunately I can't use these. Somebody had actually sent me a link to this a while back, but it turns out that this is official InstallShield/Macrovision code which cannot be redistributed. Heck, according the the license and previous discusson I've seen on the issue it can't even be redistributed within your own organization, let alone including it in a separate product and distributing to everyone on the internet. It stinks, too, because it does a good job and I had actually figured out how to make it work with UniExtract before realizing the licensing issue. This is new to me, I'll have to check it out. Thanks for the tip.

Nope. I played around with it for about 45 min., but couldn't figure it out. To be honest, I can't even figure out what kind of installer it is, let alone how to extract files. It looks like it might be an NSIS installer, but doesn't behave like others I've seen. Perhaps it's a custom NSIS build, similar to how Skype uses a custom version of Inno Setup. Alternatively, is it possible to package applications in an installer directly with Visual Studio? If so, that may be the case here rather than NSIS. Either way, though, I can't support it at this time.

Thanks, anonymous_person. I was able to get both of those working. Wow, when I asked for "older" SetupFactory installers, you really delivered! It looks like these are too old, though. I can't find anything to support them. I'll hang on to them for future testing, though. Thanks to both of you for your response. By the way, I think UniExtract 1.5 is feature-complete at this point. I still need to do a lot of testing and fine-tuning, and will need to get some assistance updating the translation files, but I'm hoping to put out a beta version either this weekend or on Monday. I've made some significant changes in this version, so I'll definitely need some help testing it before releasing the final version to make sure I haven't added any regressions. If you're interested in helping out, check back here periodically over the next couple days. I'll post a download link and beta ChangeLog as soon as it's ready.

I have another request. Can anyone point me to some older Setup Factory installers (< v7.0)? I should be able to support them now with the new additions to what-will-become version 1.5, but I need at least two examples to test. So far I've only been able to find stuff packaged with Setup Factory 7.x, which is not supported.

Well, the current dev version can extract the contents of that file, but all I get is images and various support files as well. Just like you, I don't see the actual .exe that's doing the work. This seems to be related to the issue I described in post 374, in which I'm able to extract support files from the VMware installer (in particular the installer for Windows Installer), but not the VMware installer itself. I have yet to figure out why. I poked around at this one for a few minutes, but didn't have any luck with it, either. If anyone else can figure this out, I'd love to hear it. It'd probably help out with my installer issue as well. Thanks.

Can you post a download link (assuming it's share/trial/etc. software)? I'll be happy to take a look. Yeah, I had e-mailed him as well, around the same time I originally posted the request for assembly help here. I definitely agree that there's no need to waste time doing duplicate work on essentially the same program. The kakeeware author also wrote a more generic version of the wrapper, which should work with any TotcalCommander plugin (as well as a separate one for FAR plugins). Very cool. I'm sure you already know this, though, as I see your name listed in the credits. http://www.kakeeware.com/i_cmdtotal.php Anyway, thanks again for helping out with this, as well as working with Adam at kakeeware on the updated versions. It looks like cmdTotal should do everything I need, so I'll play around with it and see how it works. Hi, BoB. Welcome to the MSFN forum, and thanks for the tip. I've actually looked into using your DLL in the past, but was never able to figure out quite how to do it. I'm also not a very good low-level coder in general (as I've stated here before), and AutoIt's DLL capabilities isn't quite as straightforward as some other languages. Without specific example code to follow, I usually don't have much luck with this kind of stuff. However, I see you've included some pre-compiled examples with the DLL, so I'll check them out and see how it works. Yeah, very useful. Thanks for posting it. Now that I think about it, though, this may be a good reason to stick with the standalone .exe rather than using your DLL. As you pointed out I use your external userdb.txt file for additional signatures, but I've also added a few of my own. If I switch to the DLL with an embedded external database, I won't be able to just append my own custom entries to it. I suppose it'd be possible to create my own userdb.txt and reference it in addition to your embedded copy, but I find it useful to be able to search through your copy as well to copy/update/modify existing entries. I think I'd lose some of that flexability by switching to the DLL. These are just some initial and random thoughts, though. Like I said, I'll play around with it and see what I can do. Thanks again.

Does anyone know where I can download or how I can generate some uuencode, xxencode, base64, binhex, and/or yenc encoded files? I had a request from a user to add support for these, and I found a good open source utility to do the job, but I need some samples to test before I can add it to UniExtract. I'm thinking this should be rather easy to do, but I don't really know where to start. Any pointers? Thanks.

Dang, Perch. That's awesome! As you said in your last post, the main issue with with the output filenames. A second issue was that I wanted to switch over to the newer InstallerExplorer version, but I see you already did that as well. Very, very cool. I'll out it through some thorough testing and give you feedback. Would you prefer PMs, e-mail, or just posted here? Some initial feedback after minor testing: I see what you mean about duplicate files. It's not simply duplicating the files, though - in some cases, I have four copies of the same file or group of files, just in different locations. Very weird. I can't really think of any suggestions though. Ordinarily I'd ask to take a look at the code, but in this case that obviously wouldn't do much good. I also have two feature requests. I know this is an extremely early version, but you did ask for feedback. Neither of these are showstoppers, but they'd make integration with UniExtract easier. 1. Provide option to simply list Installer Type and/or output instead of extracting the files (similar to 7z.exe's 'l' switch output). This would allow me to easily test if the installer is supported. 2. Provide option to specify target directory. I know this is much more of a pain to do, so don't bother if it looks like it'll take up too much time. Thanks again!

Does anyone know assembly? I have a couple possible ideas that could greatly expand UniExtract's format support, but it requires modification of an assembly program (see my last post about IETOTALX). I've been playing around with the source code for a few hours trying to make sense of it, and while I can somewhat understand what's going on, I'm really at a loss when trying to make any changes. If you're interested in helping out, please PM me. Thanks.

Thanks, Perch. This was VERY useful. I was able to get Universal Extractor to support everything you included, with the current exception of Balls98.exe. As previously discussed I cannot use Total Commander because it is not freely redistributable. However, I've been playing around with IETOTALX which is essentially a wrapper for the InstallExplorer plugin to allow it to run as a standalone app, and I've had some limited success with it. It seems to extract the files just fine, but the file names and extensions are not correct (among a couple other issues). I'm going to keep playing with it and see if I have any luck, but so far I've run out of ideas. The fact that it's coded in assembly really doesn't help, either. These look like some greate suggestions, Stranger. I'll check them out and see if/how they can be used. I've added TrID to the current dev version and so far it seems to be helping with detecting non-exe files. I got it this time. Still don't know what happened last time. I'll check it out when I get a chance. Thanks.

I have an unpacking question for the experts here. There are certain installers distributed as bootstrapped Windows Installer executables. By bootstrapped, I mean it's an .exe file that contains both the MSI and the actual Windows Installer installer. When executed, it extracts both files to a temporary directory, runs the Windows Installer installer to ensure that the system is running the required version, then runs the MSI to install the application. The odd thing about these files is the way that they're packed. If I run UniExtract on it, it seems to successfully extract the files, but it turns out that it actually extracted the contents of the included Windows Installer installer rather than the package itself. For example, I'm trying to extract the contents of the VMware Player installer: VMware-player-1.0.3-34682.exe. If I run the file and search for the temporary files extracted to %temp%, I see that it includes two files: VMware Player.msi and instmsiw.exe. instmsiw.exe is, of course, the installer for Windows Installer (sigh, I really wish they'd used a less generic/confusing name). So now, if I use UniExtract to extract the contents of instmsiw.exe, it's identical to the output I get when running UniExtract directly on VMware-player-1.0.3-34682.exe. For some reason, 7-Zip must be extracting files from that portion of the package rather than the package itself. Like I said, I've seen this behavior with a few such installers, but I've never really taken the time to look into it too deeply (believe me, there's no shortage of stuff to occupy my time lately). However, I'm pretty dang annoyed right now, and would really like to figure this out. Does anyone have any ideas on how I can extract these files? Simply running the installer and trying to copy the self-extracted files from %temp% doesn't seem possible because of the inability to predict the temporary folder name. I'm really interested in hearing about any suggestions that you may have on this. You can download a copy of VMware player for free if you'd like to try testing it.

Beats me. Seriously, this utility is only intended to extract files from archives/installers/packages. If you want to make changes to an NSIS installer and then recompile it, you'll probably need to just create an entirely new installer with NSIS. As far as I'm aware, you can't really "edit" an NSIS installer, and I doubt that the files extracted could simply be repacked without any additional work. As an alternative, I recommend checking out Inno Setup. Personally I think it is far superior to NSIS, for several reasons. Since you'll likely need to recreate your own installer anyway, it wouldn't really matter whether NSIS or Inno Setup (or anything else, for that matter) was used - just make it functionally do the same thing that the original one did (with your changes, of course). I have not heard about that one, but I'll add it to the ever-growing list of unpackers to check out. That's odd. I just tested version 1.4.2 on my system with a .1 file, and it worked fine. I'm not sure why it's failing for you. How large is the file? Send me a PM, please, and we'll figure out a way for you to get it to me (e-mail, FTP upload, something like rapidshare, etc.). Sounds very interesting. Will definitely check it out.