nitro322

Can you post a link to such a file? I'd be happy to look into it.

I don't think it's possible to extract file from data2.cab directly. However, I believe that files stored in data2.cab are also included if you extract data1.cab. This has been my experience, anyway. I guess as with anything your mileage may vary. I can tell you that UniExtract uses i6comp.exe on the backend to extract files from InstallShield cabs. If you don't seem to get all of the files by extracting from data1.cab like I suggested, maybe you can search for i6comp on Google for more information.

Thanks for the virus reports. A couple people had e-mailed me about it as well, but I've been rather busy for the last week and haven't had time to work on this myself. This has actually happened a few times in the past; not specifically to UniExtract.exe, but rather all AutoIT scripts. As Camarade_Tux pointed out, this is generally because AutoIT uses UPX to compress it's executables. UPX is also used by a lot of malware for the same purposes, so A/V vendors sometimes get a little too aggressive on there updates and end up treating ALL UPX executables as malware. I personally encountered this with AVG about a year ago, and after it deleted every AutoIT script on my system I very quickly uninstalled it and have never used it again. ggf31416, big thanks for reporting this to AVG and getting it taken care of.

You're welcome. Someone else had requested this as well. I'll look into it for the next release (still probably a few weeks out), but if I recall correctly I believe that the Setup Factory unpacker you linked to only supports older versions of the product. I'll have to do some testing, of course, but if you happen to know of a specific .exe that it will unpack it'd be a huge help of you could send me a link to it.

Ok, I gotcha now. I'll have to investigate this for the next version. I'm not opposed to it, just have never realized it could be done. Thanks for the suggestion. Hmm... I've actually never seen this "view" in Windows Explorer before. Interesting. :-) I don't know how difficult this would be, but I'll look into it for the next version.

I don't quite follow you here. IS Unpacker Explorer, as far as I'm aware, is a frontend to innounp.exe. All it does is provide the ability to unpack Inno Setup installers with innounp using a GUI interface. The end result should be the exact same as Universal Extractor, since I'm also using innounp to unpack Inno Setup installers. What exactly are you requesting? I'm not really sure what they mean myself, as I also use Inno Setup for all my packaging needs. Even more confusing is that each NSIS installer I've unpacked seems to be slightly different. For example, compare the directories shown in your image (which looks like the DivX Player installer) to the directories extracted from the Gaim installer: $_OUTDIR $1 $PLUGINSDIR $R0 $SYSDIR DivX doesn't use $_OUTDIR, it uses $0 instead of $1, and it has a bunch of DivX-specific folders that Gaim lacks. I don't get it either. :-)

Ok, I got this working for me, but before I explain what I did I want to be really clear about this: This seems to work for me. I cannot guarantee it'll work for anyone else. I don't think this can break anything, per say, but it could possibly corrupt your automatic updates database, which may prevent future updates from being recognized. I won't know if this is an issue or not until the June updates are released. I got some ideas from this thread, but nothing discussed there seem to do exactly what I wanted. Still, it's a great thread for more information on this topic: http://www.msfn.org/board/index.php?showtopic=50194 Now, as part of my image build process I include two steps for patches. First, I slipstream what I can using nLite. I then add anything that can't be slipstreamed to a "System Updates" folder that I include in $oem$. I have an AutoIt script that runs through this folder and silently installs each patch during Windows installation (this also includes the most recent Malware Removal scanner). The net effect is that once Windows is installed, all applicable patches at the time of the image build have been applied. With that said, here's what I did: 1) Build new image with up-to-date patches slipstreamed 2) Install image along with leftover patches 3) After initial login, force Automatic Updates to check for new updates: wuauclt /detectnow 4) The only thing that should be detected at this point are items that you don't want installed, for whatever reason. Clear out this list, set to not prompt you again, and close the window. 5) I'd recommend forcing another check at this point, just to be sure. Repeat if anything else is found. 6) Stop the Automatic Updates Service: net stop "Automatic Updates" 7) Copy %windir%\SoftwareDistribution\DataStore\DataStore.edb to your CD: $oem$\$$\SoftwareDistribution\DataStore\DataStore.edb That should do it. During your next installation, your preset datastore file automatically be copied and used by Automatic Update. As I said above, though, it's possible this method could lead to corruption of the AU database, but so far it seems to be working for me. I'll let you know if it's still working after June 13. If anyone else has better suggestions, feel free to post them. I'm always open for improvement.

RyanVM, I'm trying to figure out how to enable support for WPA2-PSK as well. Specifically, I need to set AES encryption rather than TKIP. Have you had any luck with this?

JuMz, let me know if you have any luck with that. I'd like to prevent the Malware Removal Tool from installing/running. Simply clicking to not prompt me once would be easy enough, but the **** thing treats each monthly release as a separate update. So, I get prompted separately for each and every month, going back at least through November (which is when I started ignoring the prompts altogether).

Thanks, Bezalel. That's what I was looking for. I did a search and found some other threads already covering this topic. Just didn't know what to search for previously. I'll check them for additional information. T D and TheFlash428, I aprpeciate your responses as well. However, I was looking for where this information is kept because I want to slipstream some customizations on my installation CD. I was already familiar with both of your suggestions.

Where does Windows keep track of which updates have not been installed, and which have been set to not notify the user? Title edited -- Please, use [TAGS] in your topic's title. --Sonic

I see you're point. I'll look into this again when I start working on a new version. Camarade_Tux, I believe that ggf31416 is correct in that 7za.exe support significantly fewer formats than 7z.exe. In fact, when I first added 7-zip to Universal Extractor, I started with 7za. However, I couldn't get it to work with many of the supposedly supported formats, which eventually led me to using 7z.exe with all of the DLLs. I believe that the update you mentioned was simply to bring it in sync with the latest version of 7-Zip. However, just to be sure I'll go ahead and check it out again on during my next dev cycle. Believe me, I'm all for making this as small as possible. :-) Excellent! I'll definitely use this new version, which should hopefully improve my .exe filetype detection. Being able to accurately determine the archive/installer type is the single most important piece of the puzzle, so this should help improve things quite a bit. You're more than welcome. Glad to hear it's getting a lot of use. :-) I'll let everyone know when I start working on a new version, but at this point it's still likely a few weeks away. Real work keeps getting in the way.

Thanks for the heads up on this, ggf31416. I've been following this pretty closely, though I haven't had time to reply in the last few days. There's also a thread about this on 7-Zip's forum: http://sourceforge.net/forum/forum.php?thr...&forum_id=45797 The bottom line is that a vocal minority on Winamp.com's forums are making a huge deal out of a non-issue. Even on their own forum, most of the posts have been along the lines of, "NSIS is an open-source installer. It shouldn't be relied upon for foolproof protection of sensitive data." Those sentiments hit the nail on the head. This issue is no different than when innounp was first released, and did the same thing for Inno Setup installers. Want to know what happened? Nothing. Except Inno Setup installer users had more options available to them. To be completely honest, innounp is one of the reasons I myself use Inno Setup for all of my installers - I LIKE the fact that my users have this capability, if they so choose. As an NSIS installer user (for Gaim, FileZilla, and many others), I HATE the fact that I cannot extract files from the installer without installing it, adding who knows what to my registry, copy the files out of the installed directory, uninstall it, then deal with anything it may have left behind. It's a pain in the rear, and I'm sure many people on this forum would agree with me (especially considering NSIS has been the number one request for Universal Extractor). So, I'll continue to follow this and see what develops. Hopefully this will all blow over, proper support will be enabled in 7-zip, and we can all live happily ever after. hp38guser, I need more details here. Wise and InstallShield are two different packaging systems. There's no such thing as a "WISE installshield installation package". Can you be more specific about what you're trying to extract? Direct download links help. I don't follow you here. Are you saying that version 0.20 of i6comp is more reliable than 1.03b? Was there another release somewhere that I missed? Can you provide a link to the specific version you're discussing? This has been requested before, but I haven't added it because, frankly, I don't see the it as a good fit for Universal Extractor. UniExtract is a general purpose extractor/unpacker. It's not meant to be a decompiler, unless that may be needed is part of the extraction process. Can you provide a little more information on why you'd like this added? How would it benefit you, and other users? I'm not asking for a detailed jusification or anything, just trying to get a better understanding of how it'd be used. Thanks.

Man, I'm sorry. I did that myself about 3 years ago. I learned a lot of interesting stuff about how Windows works, but it got pretty old after a year or so. Hope you've found some way to keep things interesting. Ok, by Setup Launchers I'm assuming you're referring to the dang bootstrapped InstallShield installers? I know that supprt isn't that great for this, primarily because there's just no good standard way of dealing with them. InstallShield was the bane of my existance in my former packaging life, which was why we had standardized on Wise. I refused to contribute to the circle of pain. So, flash-forward three years and here they are causing trouble again. Sigh. Ok, time for some details. When UniExtract detects and InstallShield package, it first tries to extract the files using IsXunpack.exe. If that fails, it prompts you about the cache method. I don't recall offhand where exactly I found this switch, but I believe it was in InstallShield's KnowledgeBase or forum. This is the specific command I run: "\path\to\installer.msi" /b"\path\to\output" As you stated, that'll generally extract the main program MSI. Now, for my purposes, that's generally good enough. For example, I use it on Sun's Java installer to extract the Java MSI, which I then install using msiexec.exe with my own switches. However, I do understand that for your purposes you do need to get all of the support files as well, especially the installscript MSI. And this is where the next problem comes into play. The only method I know of getting this (if IsXunpack.exe fails) is to run the installation and try to get the files from %temp%, just as you suggested. Unfortunately, there doesn't seem to be any predictable way to determine the temporary directory that gets created within %temp%. Without being able to predict the path, I have no way of programmatically determining which directory from which to pull the files. Granted, I've not spent a tremendous amount of time researching this, but I haven't yet come across a good way of doing it. Do you have any suggestions on how I can locate these files in %temp%, assuming that the installer does actually create them (some installers do not)? If so, believe me, I'll be more than happy to take them into consideration. Do you happen to have a direct link? Maybe you can e-mail it to me? I don't have any desire to register an account with Adobe just to download a trial program for testing. Thanks for the catch. I'll correct it in the next version. Also, thanks for the feedback in general. Believe me, I know where you're coming from, and I'm more than happy to make this program even more useful for you if possible. I know I would've LOVED to have a utility like this back when I was doing that job. It's actually part of my inspiration for creating and working on this now.

I'll look into it tonight. Could you please post a link to this program? I found a copy of the program myself, and found the problem. During development of v1.1 I had to change the "mode" used by the GUI in order to make drag-and-drop work correctly. Changing that mode meant substantially modifying the code behind the GUI. Well, I did a lot of testing to make sure that the code changes I made all worked fine, but I forgat that the Wise Installer method selection was a completely separate GUI, and it was still coded for the original mode. That' why it simply didn't respond to any events. Oops. Anyway, it should all be working again. I bumped the version to 1.2.1 and re-released. The Wise Installer bug fix is the only change from 1.2. New download links are available in the original post.

Glad you find it useful. :-) As Kelsenellenelvian pointed out, the easiest way is with /verysilent. However, Inno Setup offers quite a few options for unattended installs. This page describes all of the options: http://unattended.sourceforge.net/InnoSetu..._ExitCodes.html One of the extremely nice things is you can use the /tasks parameter to specify which install options you'd like, if for some reason the defaults don't work for you. The 3 task names are associate, associate\force, and modify.

What's SA Utils? Not directly. Your best bet for doing that would be to download the source code archive, look at the [Registry] section of the Inno Setup (.iss), then recreate in a standard .reg file that you can import yourself on any system. If you go down this route, though I should warn you that the Registry section is fairly complex. I had to account for various conditions for each type of archive (whether or not it's already associated with something, whether or not you want to force association with UniExtract, etc.). The simplest route would be to add all of the "; Native associations" and all of the "; Additional Associations" that are flagged with "Tasks: associate\force". This will register the UniExtract context menu entries with Windows, and associate all supported apps, which in turn will use add the context menu entries. However, this will overwrite any existing associations (such as with WinRAR, for example). If you want to maintain existing associations, you have a lot more work to do. Alternatively, you could just use the installer. Edit: Shoot, I just realized that I had an error in the script that generates the source archive, and the .iss file is not included. I'll get that fixed tonight and upload a new copy. Edit 2: Fixed the source archive. Sorry about that.

The installer should set this up automatically for you. Make sure that "Enable Explorer context menu integration" is enabled during installation. This will associate UniExtract with all currently unassociated formats, and add context menus to all currently associated formats, but leave the association in place so that double-clicking will still open it in the current application. By currently [un]associated, I'm referring to any other applications such as WinRAR that may already be installed. That should work for you. If it doesn't, try enabling the "Force association with with all supported archive formats" option. This will do essentially the same thing, but will associate ALL formats with UniExtract, overwriting any current associations. If for some reason neither of those options work, let me know. I'll probably need to get some more information from you, and look into it.

I'll look into it tonight. Could you please post a link to this program?

When UniExtract.exe is executed, it determins it's current path, then sets the working path equal to: %path% = path\to\uniextract;%path% So, while UniExtract is running, it looks for executables in the current running directory first for all of its support binaries, then looks in the rest of the path directories. This was done so that even if the user chooses not to add UniExtract to the system path, it'll still function properly (which is mainly suitable for people using the .rar file rather than the installer). Basically, the only way I could see this failing due to a path issue is if the following conditions are met: A) UniExtract.exe is moved outside of the default bin\ directory --AND-- B) The .rar version is being used or the system path option was unchecked in the installer As you said, it's likely a rare condition. I'm not sure if I agree with you that it's a bug, though. In order for the above conditions to be met, the user would have to manually move UniExtract.exe to a different directory that was intended. I guess I could make it only look for binaries in the same directory as UniExtract.exe, but I think I'm using a couple native windows programs for certain formats, which would then break. Of course, it's also still possible it's something else altogether, though I still have no idea what it would be. :-) Either way, glad you finally got your problem resolved.

Ok, I got antsy and decided to work on this tonight. So, I'm pleased to present Universal Extractor v1.2. As usual, you can find download links and the changelog in the original post. This release adds support for NSIS (finally!), thanks to some very talented folks working on 7-Zip, but please note that it is still preliminary at this time. There's already been some discussion about this, so please refer to the previous few posts for details. Two other notes: the_guy, does this version properly support the type 1 and type 2 patches you were talking about? I downloaded the patch for MS06-008 and saw that it didn't extract properly, and was able to get a unique identifier from PEiD, so I added support for the /x switch as you suggested. It seems to work fine for me now, but I only have the one test file. matidio, I still haven't been able to reproduce your issue with winzip100.exe. I've tried it on three different systems using versions 1.0, 1.1, and 1.2, and they all work for me. PEiD detects it as Nothing found [Overlay], but whenever this message is encountered UniExtract attempts to extract it with both 7-Zip and InfoZip, just in case it works. In this case, 7-Zip ran and was able to extract it every time. I'd still like to work with you to figure out what's going on, though. If this behavior occurs for you, it may very well occur for other people as well. Have you been able to find any more details about why it works on one of your systems bot not the other?

While I'd definitely like to do this, it's not currently possible, nor likely to be implemented. This would writing a shell extension (.dll), and I lack both the tools and skills to do that. However, if anyone else wants to volunteer... :-) If you only wanted one option rather than three in the context menu, it would be possible to modify the installer to only add registry entries for that one particular option. Alternatively, you could use the noinstall version, and write a custom batch file to only associate it only with the desired options and/or filetypes.

I saw this earlier myself. I most certainly plan on adding support for it. It may take a couple days before I have time to implement it, though. By the way, for those of you that may not be aware, I use 7-Zip extensively in Universal Extractor. In addition to using it as the default extractor for unknown archives (which actually works quite a bit), I also use it to extract files from all of the following file types: .7z, 7-Zip SFX .exe, .bz2, .cab, .chm, .cpio, .deb, .gz, .iso, .lha, .lzh, .rpm, .tar, .Z Also, as mentioned above, the latest beta even includes preliminary support for NSIS, which is the single most requested feature. If you find 7-Zip useful, please consider leaving some positive feedback on the 7-Zip forum, or even donating to 7-Zip. I myself just donated $50 to the project, as the recent additions of ISO and NSIS support are two long-desired features that alone justify the donation. I also strongly recommend checking out the Credits section of the UniExtract home page, just so you understand that this project wouldn't exist if not for the hard work of other F/OSS programmers. Now, back to work. :-)

the_guy, could you please post links to a couple examples of what you're calling type 1 and type 2 hotfixes? I wasn't aware that they had different types with different methods of extraction. I'd be happy to look into it.

Giorgio_ap, I use innounp to extract files from Inno Setup packages. innounp only supports installers created with Inno Setup 3.0 and newer. Based on your error message, I'm guessing that the installer you're trying to extract was created with a 2.x version. I'm not sure why this limit exists, but unfortunately UniExtract can only support packages which are in turn supported by its helper programs. If you'd like, though, I'd be happy to take a look specifically at this file and see if I can diagnose the problem. Can you send me a download link? tap52384, I don't think I understand your request. As Lost Soul just mentioned, each of the archive types you listed are already supported. Are you asking about other types that aren't listed?