nitro322

LZMA support will be included in the next version. Thanks for the suggestion and links.

I had some code in 1.4.2, before I started using TrID, that would try to detect if crap files were extracted instead of files with the proper names since I couldn't distinguish between the two from analyzing the file. The code was ugly, hackish, and slow, so I removed it in favor of properly identifying the files with TrID, but unfortunately the old method seemed to be more reliable. I'll look into this more deeply once I start working on the code again, and may add that code back if I can't get the TrID detection to work more reliably. Ok, I think we should be good on this for the next version. I made some updates to the TrID defs file file a while back (forgot the specifics), and it seems to be much more reliable than the old version. I just tried extracting all hotfixes that I had archives, including several newish ones such as linked to in post 606, and TrID detection is working fine. Just in case this becomes an issue again in the future, though, I also added back the manual checking/validation that I performed in 1.4.2. It's ugly code and I was really hoping to deprecate it, but I guess it's best left there as a failsafe than removing it altogether. Should TrID detection fail on these hotfixes, the manual check should now catch it and instruct UniExtract to do the right thing.

Sorry, I can't download this. It wants me to register for a trial version, and I'm really not interested in providing personal information to that site.

I just took a look, and unfortunately I'm too lingually challenged to attempt this one. If anyone can provide a utility or directions to extract the files then I'll be happy to add it, but given that I can't read anything about it I can't do a whole lot myself.

That's actually very similar to what I did in 1.4.2, though I use 7-Zip instead of cabextract.

sherpya, do you know the origin of that file? I know unshield comes from the SynCE project (I've looked at it many times), but I've never found a native version of it before that doesn't require cygwin. This is a really good find, and I'd like to make sure I credit both the original author(s) at the SynCE product as well as the porter. And yeah, I know it's been a while since you posted that. Hopefully you're still following this thread. :-)

I had some code in 1.4.2, before I started using TrID, that would try to detect if crap files were extracted instead of files with the proper names since I couldn't distinguish between the two from analyzing the file. The code was ugly, hackish, and slow, so I removed it in favor of properly identifying the files with TrID, but unfortunately the old method seemed to be more reliable. I'll look into this more deeply once I start working on the code again, and may add that code back if I can't get the TrID detection to work more reliably.

Will check it out. That means that TrID doesn't even recognize it as a Microsoft Patch. I added special signatures specifically for them since they're an odd case. There's not a whole lot I can do without scanning it, unfortunately. No, it's not official, but I'm aware of it. I obviously can't endorse it or anything like that, but it looks like he fixed a few of the outstanding bugs from v1.5, as well as updated some of the tools. If any of the addressed issues are causing problems for you and you can't wait until the next official version (which, honestly, is likely still a little ways off), it may be worthwhile checking this out. You can see this thread for a bit more information about the release if interested.

It was mentioned, but I know this is a big issue so it's worth repeating. If you come across any specific hotfixes that do not work, please post download links here. I need to actually scan them with TrID in order to update the signature file. This will improve detection in future releases.

Thanks for doing a lot of the legwork for me. Many of these have already been updated in the dev version, but I'll be double-checking everything before the next final release to be certain that I haven't missed anything. At the risk of sounding dumb, why did you include this one? I use 7-Zip to extract NSIS installers where supported (there's no other way to do it, as far as I'm aware), so I don't really have any use for the official NSIS installer. Or do you know something that I don't? Yeah, I'm aware of this problem. The short answer is that there are two different types of Microsoft hotfixes, which require different extraction methods, and it can be difficult to distinguish between them. If you can send me links to the specific files you're having trouble with I can scan them with TrID and try to increase the detection reliability,

Cool, thanks for the heads up. I'll add it to the next version, assuming there are no compatibility issues. I always appreciate new suggestions. I'll keep these in mind for the next major update. The next release in progress will focus on compatability and bug fixes. I'll look into them when I get the chance. I can't say whether or not the can or should be supported until I actually examine them myself. Note: A lot of people have posted requests like this (questions about a specific executable), and my answer applies to all of them. I'll look into any reported compatibility issues, but just to save some time I'm only replying this one time to this type of request. Do you know of any other apps or utilities that can do it? Also, sample installer greatly help if you can post any direct links. This is a known issue. Please see this post for more details. If anyone can figure out a solution for this, I'd love to hear about it so I can integrate it into UniExtract. Can you please post a link to the SDK or other sample files? I'll look into it. Are you running as an administrator or limited user? There are definitely some compatibility issues with Vista, and I'm going to try to address some of them in the next release. Any details you can provide about this would help. Can you please explain this a bit more? I'm not quite sure what you're getting at.

All, As you've undoubtedly noticed, I've been out of the loop for a while due to other priorities. However, I wanted to let you know that I haven't forgotten about UniExtract and that I very much plan on releasing an updated version to fix the dumb Inno Setup bug as well as address the InstallShield false positives. I also have limited access to a Windows Vista system now, so I'm going to do some testing on it and see if I can take care of some of the issues that people have reported. It'll still take some time before I can get this done, but believe me, it IS coming.

As mentioned above I'll need to check this out myself to see what's going on. Can you provide a download link? Will look into it. Do you know of any existing unpackers/extractors for it? This is outside the scope of Universal Extractor. It's sole purpose is to unpack/extract files, not recompile. For assistance with Inno Setup, I'd recommend the IS newsgroups. Look here. I agree. That is annoying. UniExtract should restore your existing settings upon completion. If it's failing, then you found a bug in the code. I'll investigate. I'm not sure that this will help. PEiD doesn't change it's settings. UniExtract does. The basic issue is that when UniExtract calls PEiD for analysis, certain options need to be set prior to that call. So, UniExtract reads the current values, writes the new ones that are necessary, runs PEiD, then should restore the values to the previous state. PEiD is simply doing what it's told, so there isn't really any need to patch it. I just need to make UniExtract behave correctly. Of course, the ability for PEiD to read settings from an .ini file or from CLI arguments would be a much better option, but that doesn't seem to be possible. Edit: Let me clarify that last statement. One of the PEiD developers does make a PEiD DLL available for applications that use it in the manner UniExtract does. However, my choice of language development skillset makes this option difficult if not impossible. As a result, I have to simple call the .exe directly and interpret the results. I do wish that PEiD.exe could be configured via .ini file or CLI arguments, but the developers do offer an alternative that would be suitable in most situations, so I certainly can't fault them. Besides, without PEiD this program probably would have never been written.

Will check it out. Thanks for the suggestion. Will have to investigate as soon as I have time to try to figure out what's happening. This has also been corrected in the dev version. I just need to find the time to polish it up for the translators and then make it available. Been very busy lately.

Well, I do use nLite to slipstream my drivers, etc. It works great. The problem is that my laptop, desktop, and various VMware images, for example, are configured very differently, and I use the winnt.sif and other support files on that floppy disk to configure each accordingly. I can also throw certain config updates on the floppy if needed for a new install without building and burning an entirely new CD. It allows for much more flexibility than using just the CD itself. Of course, all of that means nil when I don't have a floppy drive. So... does anyone else know of a way to make this work? Or am I just out of luck here?

My method for performing an unattended install involves: A ) A heavily customized Windows CD, that B ) Boots from CD-ROM, and C ) Reads winnt.sif and some other support files from floppy disk I use a different winnt.sif file (and associated support files) for each different system. This method has worked very well for the last several years, but now I have two systems without any floppy drive. While I could find a spare drive took hook up temporarily during the install, I'd much prefer to find a solution that doesn't involve a painful workaround. What I'd like to do instead is use essentially the same method, but use a USB drive rather than a floppy disk for the answer/support files. However, Windows doesn't seem to recognize this by default. I figure at this point in time there must be some way to do it, either by official or unofficial means, but my Google searches were too generic to turn up anything useful. So, I figured I'd ask the pros on MSFN. I searched the the forum as well, but mostly just found discussions about booting from USB rather than CD. I only have a 128 MB stick, so this isn't an option for me at this time. Instead, I'd like to continue booting off the CD-ROM as usual, but just be able to read my answer file from a USB device. Any pointers? Thanks.

Yes, this is a false positive. See this post. Unfortunately it's a common issue with AutoIt apps, and there just isn't anything I can do about it. This is already included in the dev version. I don't know why you're having this issue. I'll investigate. Note, if it's an encrypted (password-protected) installer as dA CLOwN mentioned, then you cannot extract it without the password. However, it should not hang at the Scanning message. It should proceed past that and the Extracting stage, then display a CMD window. If it's truly hanging at the Scanning stage then something's wrong. I may need to follow up with you for some more info. yes, it extracted fine on my PC. How do you get an AutoIt error from an Installshield Installer? UniExtract is written in AutoIt, so if it craps out for some reason during an extraction process then you'll see an AutoIt error message. anonymous_person, sounds like you have your problem solved now. Let me know if you have any other issues.

At this time it looks like I won't be able to add support for .wim files. According to the license terms you posted, the Microsoft utilities are most definitely not freely redistributable. Until a 3rd-party solution becomes available, this won't be possible.

It's leftover debugging code, as previously mentioned. You can just click OK and ignore it, as it doesn't do anything other than pause execution. It'll be fixed in the next version.

I haven't had anytime to work on UniExtract lately, but will check this out next time I do. Thanks for your work on this. Nice trick. :-) UniExtract could originally be run from the command line easily enough, but I inadvertently broke that ability with the 1.4 release when I moved UniExtract.exe to the root install directory rather than \bin\. I only just recently discovered that. Oops. I'm going to investigate improving this in a future release. Look lower left corner of any page in the thread. You should see an input box that says "Enter Keywords" and a button labeled Search Topic. This should do what you want.

Looks promising. Will investigate. Thanks for the tip. I'll include innounp 0.19 in the next version. DigeratiPrime, are these the same builds you're using? Good luck. I've bashed my head against this while for quite some time, and every time I think I have it figured out some new and seemingly completely random problem pops up. winset.exe was may latest desperate attempt, but even that fails. Well, do you know AutoIt? I really don't have much time to work on this at the moment, but if you can figure it out yourself I'll be more than happy to include the fix in the next release. Search through UniExtract.au3 for references to WIN32. These are the places where I'm doing different things depending on the version of Windows. I'm sure there has to be SOME magic combination of enget, envset, and winset that would make this work, but I sure haven't been able to find it. If not, I'll continue working on this later on when I get some more free time.

I just don't have a copy of Vista. Microsoft has severely p***ed me off with the licensing terms for Vista, the forced WGA checks and calling home, the ridiculous new levels of DRM that they're trying to shove down my throat, etc. I have do not intend nor desire to buy a copy of Vista. I'm perfectly happy with Gentoo, and rebooting to my copy of XP when necessary. It's really a shame, too - a lot of the new security features and technologies are long overdue in the Windows environment. With that said, though, I'm sure it's only a matter of time before I have access to some Vista box somewhere, be it at work, a friend's house, etc. At that point I'll do what I can to make sure UniExtract works properly. Can you post a link? I can never figure out where exactly you're supposed to download it from. The Sourceforge site only lists builds from 2002 and 2004.

Unfortunately, this is somewhat of a known issue. AutoIt and Windows 9x seem to have a whole lot of difficulty agreeing on the PATH, so I've been hacking awaay at various workarounds for the last few versions. You can read through this thread for some of my frustrations with this issue (also look for some of drugwash's previous posts - it sounds like he had the same issues). I'm going to continue to work on that when I have time, but Windows 9x is not officially supported, so this is a "when I have the time" kind of issue. Would love to, but it can't currently be done. Please review this thread for previous discussions about this. For the most part, you can. The relevant options will appear as needed. For example. the "remove duplicate files" option will appear when you choose to use InstExplorer to extract archives. These options are displayed as needed rather than globally in the main GUI. Unfortunately, there are currently some cases where a specific option is used and you are not prompted for this option before hand. I'm investigating possible ways of handling that. I may add a separate options page, or something similar, in future versions. Probably not, but I'll look into it just in case. There's been some discussion in the last couple months about Vista. The basic story there is that I don't have access to a system running Windows Vista, so I'm very limited in my ability to test and fix Vista-related issues. As such, Vista is currently not an officially supported OS, though I plan on doing my best to fix issues that are reported. This is one of those issues that I still need to figure out. Will try to address it as soon as I can.

Yeah, that's been fixed. Someone reported it very quickly, before I had even posted the announcement here, so I just pushed out a fixed 1.5 package. Relatively few people should be affected by that, and it's just a cosmetic issue even for those that are.

Interesting. I tested a .zip file and an .exe installer with no extension, and they both worked, but I hadn't checked .rar files. Will need to investigate. Well, unfortunately there isn't a whole lot that I can do about that. If a file is missing its extension then UniExtract is completely dependent on TrID to identify the file. If that fails, then UniExtract fails. If you can find the file that was misidentified, it may be worthwhile to contact the TrID author and let him know. Will have to investigate this as well - like I said, I only tested a few test cases. The icon was enabled based on some previous suggestions. It's simply an easy mechanism to kill UniExtract should something fail. It's default AutoIt behavior, which prior to this version had been disabled. It's not meant to be a user interface for the program. I agree with your points, but it's not really a bug. I'll revisit this idea for version 1.6. Yeah, Skype's a known problem. They used a custom build of Inno Setup, which is similar enough for innounp to recognize, but different enough to fail unpacking. I haven't been able to find any way to work around this.