nitro322

Did you use the installer or the archive? If you used the installer, did you choose to "Add Universal Extractor to your system path"?

Matidio, is this the file you're encountering problems with? http://download.winzip.com/winzip100.exe I just downloaded it and tried it out myself, and it worked fine for me. PEiD does return "Nothing found [Overlay]" as described above, but UniExtract extracts the contents anyway as an "Unknown 7-zip archive". I'd noticed in the past that a lot of self-extracting archives do not have a recognized signature, so I basically added a default case to attempt extraction with both 7-zip and InfoZip if it's unknown. In this case, it works perfectly. This behavior has been present since version 1.0, though it was missing in earlier versions. After investigating this further, I'm puzzled that you're having this problem. Are you sure you're using version 1.1?

Matidio, I saw your comment about this problem on my website a few weeks ago. I'm glad I finally have a chance to reply to you. :-) This issue occurs because of the method I'm using to analyze the files and determine the type. UniExtract doesn't actually do any of this itself; instead, it uses PEiD.exe to analyze the file, and takes action based on its output. If PEiD.exe returns "Nothing found [Overlay]" (as in your specific example), then UniExtract doesn't know how to handle it. I know this isn't perfect, but so far it's the best method I've been able to come up with. If you know of a better way to determine the filetype of these "unknown" executables, please let me know. I'll do what I can to include it in UniExtract. Thanks.

Well, I figured out the problem. There's a bit of a story involved, but the summary is that I had compiled it with the stable version of AutoIt rather than the beta version. As of UniExtract 1.1, the beta version is required. I've recompiled, retested, and reuploaded. Everything should work correctly now. Please let me know if you have any other issues. Thanks.

Sorry guys. I'm not sure happened. I've been out of town for the last couple days, but I'm heading back home tonight and will fix the error. Thanks for the reports.

I just released version 1.1 of Universal Extractor. Please see the original post for details and download links. As usual, feedback is most welcome.

I have a request for anyone reading this. I've added support for .iso files to the next version of Universal Extractor. I'd also like to add support for bin/cue images. Of course, extracting from these requires first converting to .iso. I know of several programs that can do this under Windows, but there are two criteria that must be met: A) freely redistributable, and B) supports command line arguments for extraction. So far I've only been able to find one program that can do this: bin2iso. However, it won't convert my test .bin file (which I've verified is valid by converting with another GUI app). Does anyone else know of a program that can do this, and meets the two above requirements? Thanks.

Hi, XPect. I'm currently working on an update, and I'll add this to my list of possible features. I'm not sure at this time if it'll be possible, but I'll certainly look into it. Thanks for the suggestion.

Unfortunately, I still haven't been able to find any utility capable of extracting NSIS installers. I can promise you that it will be included as soon as I do, though, as this is my number one todo item. If anyone finds (or manages to write themselves) a utility that can do this, please let me know. I, and I'm sure a great many others, would be quite grateful. :-)

I've never messed with a PackgefortheWeb installer before, so it's be difficult for me to help out with this without being able to analyze and actual executable. There's some discussion of PackagefortheWeb silent installation at this site: http://unattended.sourceforge.net/installers.php, but it looks like you already tried that approach. The only thing different I can see is that you have a colon in your /f1 parameter. Try running it without the colon. Can't think of anything else without being able to do some testing on my own. Perhaps you can find a free or shareware application using the same installer that you could link to?

cmdlines.txt is for installing applications during the OS installation in the context of the Default User, whereas GUIRunOnce is for installing applications after the first login in the context of the logged on user (usually Administrator). Which one you want to use really depends on your preference. I generally prefer to do everything I can in cmdlines.txt, but certain apps may need to be installed during GUIRunOnce. As for how to actually do it, that also depends. There are several methods documented on this forum, but my preferred approach is to use cmdlines.txt call a batch file, which in turn does all of the work. Well, actually it calls an AutoIt script now, but I used a simple .bat file for quite a while before moving to AutoIt and it worked fine. The reason I do this is because Cmdlines.txt is very picky and very sensitive about syntax, and can sometimes be difficult to make work. So, my Cmdlines.txt looks like this: [Commands] "inst_oem_apps.bat" Then create an inst_oem_apps.bat file that contains the installation commands for all of your programs. You're on the right track with importing the registry settings. There's one thing I should point out here as well, though. Remember I said that cmdlines.txt and GUIRunOnce are executed at different times during installation? Well, certain registry settings need to be applied at different times as well. My personal approach is to import my .reg file in both cmdlines.txt AND GUIRunOnce. It's a rather brute-force approach, but it works. I'm sure you can get a better technical explanation from other users, but this should get you started. Let me know if you have any more problems.

Can you post a link to the package?

No problem, thanks for the update. I searched and couldn't find any information about avatar uploading, though I did see some other mentions of site problems a few days ago.

I'm trying to upload an avatar in my control panel, but I keep getting an error message stating that, "You are not allowed to upload that type of file as an avatar or personal photo." However, I cannot figure out why the image is being rejected. It's a 64x64, 2K jpeg image. Any thoughts on what the problem might be? Thanks.

I'm not sure I follow you. Are you talking about being able to right-click on files in Windows Explorer and extract from the context menu? If so, that capability is already included. You'll need to use the installer version, though, as the self-extracting version does not support this functionality. If you're referring to something else, though, well.. you lost me. Could you please explain a little more? Thanks.

I did a little bit of research on UHARC. It looks like this is a method of compression that can be used by NSIS when creating the installers, but after compression an SFX "wrapper" is applied to the package. This is what allows users to double-click on the setup.exe and begin the installation process. Without decoding that part, it's impossible to decompress anything encapsulated. Shoot.

I downloaded the source code, but I have no way to build it. Do you know of any precompiled binaries I can download? If not, could you post/e-mail a binary you've built? Also, could you point me to an installer that uses this type of compression? If I have a binary that can do the extraction and test it on a package, I should be able to add support for it pretty easily. You're definitely overestimating my programming abilities. :-) I can script like a madman, but I know very little about low-level development. As noted above, I can't even compile a simple, ready-made demo program under Windows (I'm a bit better in Linux, however). If anyone ever does write an extractor for NSIS packages, I'll most definitely add support for it. Until then, however, I'm afraid there isn't much I can do.

I'm not familiar with this. Could you please direct me to information on how to decompress this type of file, as well as an example compressed file that I could test with? Assuming there are no technical limitations involved, I'd be happy to add support. I'd love to add support for NSIS installers. If you'll check out my ToDo file, you'll see that it's one of the two specific formats that I'd still like to add. However, to my knowledge there's currently no possible way to extract files from NSIS installers. If you know of a way, please let me know! By supporting UPX, do you mean simply de-UPXing a packed .exe? Or do you mean extracting files from self-extracting archives that have been further compressed with UPX? If it's the latter, then yes it does (for recognized signatures). If it's the former, however, it does not. I had considered it, but didn't really see the value in it. Could you explain why this would be a useful feature? What practical benefit would it give you? I'm certainly open to it, but I'd like to know why.

Ok, gotcha. I'd actually like to do something like this myself, but I don't think it's possible without writing a shell extension (.dll). Ultimately I'd like to get to this point, so that, in addition to grouping all options into one menu, I could also add the context menu entries to all supported filetypes without worrying about taking over their associations. Eg, when I double-click on a .rar file, it sill opens with WinRAR, but I have my UniExtract entries available should I need them. Any care to work on something like this? It'a bit over my head, and I don't have a copy of Visual Studio (which I think is required for writing shell extensions), so it'll be quite a while before I'm able to do something like this myself.

I created and uploaded a new copy of the self-extracting archive. I'm not getting any errors from this one, but I'd appreciate it if someone could confirm. smashly, the installer does exactly what you describe by default. The "Enable Explorer context menu integration" only adds associations for native Windows extensions; specifically, this includes .exe, .??_, .chm, .hlp, and .msi. The "Associate Universal Extractor..." is what handles integration with other supported archive types. I don't particularly have a problem with you modifying the code, but it seems a bit unnecessary. Btw, the source code for the installer is included in the source archive. You can download that from it's home page. No need to unpack the installer if that's all you want. :-)

smashly, I can confirm this error. Not sure what happened, though. When I get home tonight I'll compare it to my local copy and see what's going on. Also, I don't have any problem with you adding it to your SA package (which looks pretty cool, btw). After all, the whole reason I put this out there is for others to benefit from it. :-)

I just released version 1.0 of Universal Extractor. Please see the original post for details and download links. As usual, feedback is most welcome.

Ahh. Yeah, I know what you mean. I actually considered this issue during development. However, I have common code that takes care of initial setup and then final verification of extraction for each type of archive. I would need to create a special case specifically for this type of file to get around it, and just didn't want to go down that route. Additionally, since every other archive type extracts to a subdirectory, I figured this one as well, if only for consistency. I hope this isn't too much of an inconvenience. :-) For the next version I'll probably look into this again, see if there's some better way of handling it. However, as I said, I'd prefer not to create a special case just for this one filetype, so we'll see what happens. Thanks for the suggestion, ATM. I actually do exactly this with 7-Zip. which I use to open .7z, 7-Zip SFX .exe, .bz2, .cab, .chm, .cpio, .deb, .gz, .lzh, .rpm, .tar, and .Z files. I still use some other standalone binaries, however, because they may support their native format more robustly. For example, the official unrar.exe can open certain RAR files (particularly SFX files) that 7-Zip cannot, despite the fact that it does support RAR files. I chose to use 7-Zip rather than IZArc primarily because it's open source (which I am a huge proponent of), and because it has a great command line interface. However, I didn't realize that IZArc could handle .iso files. I'll look into it and see if it's possible to use in my program.

I am getting this everytime i try to extract adobe reader, quicktime and firefox. Ok, I still haven't been able to duplicate this behavior. I don't think that Adobe Reader cannot be extracted with UniExtract, so that may not make a good test case. Quicktime I'm not sure about one way or another. Firefox, however, definitely works. I just downloaded and tested again to make sure that nothing changed in version 1.5, and it still works fine. It's a Self-Extracting 7-Zip archive, so UniExtract should call 7z.exe to extract the contents. With that said, I did notice a couple oddities while testing for this problem. If you've already extracted the archive and try to extract again (while the previous folder still exists), UniExtract will appear to hang after spawning an empty command shell. What's actually happening is 7-Zip is prompting you to confirm whether or not you want to overwrite the existing files; however, for some reason the prompt itself is not shown. Simply hitting a then enter will make it continue. Now, I've only just encountered this problem with 7-Zip while extracting the Firefox installer, so I don't know how pervasive it is. I'll do some more testing and figure out a better way to deal with this. Regardless, though, this doesn't appear to be related to your problem since this occurs after the file is scanned with PEiD. I also noticed that when using the Explorer integration, short names (8.3) are used instead of long file names when creating the new directory. I've already tracked down this problem and will include the fix in the next release. Finally, I have a couple other questions for you, to help track down your problem. #1, are you using the installed version, or the self-extracting version? #2, do you have any other copies of PEiD open when you're running UniExtract? Thanks for the feedback. I am very interested in making this the best it can possibly be, so please keep it coming.

atomizer, the supported formats are listed in detail on the app's home page. McStarfighter, can you please give me an example of the kind of file you're trying to extract? I've never seen this behavior. boooggy, what do you mean? What exactly is an uncabbed file? Wish I could, but for now that's not possible. The UniExtract front-end doesn't do any of the work itself - it calls all of the other binaries in bin\ to extract the files. As a result, there's no way for UniExtract to know the current status or progress of any given operation; the only thing it knows for sure is the beginning and end points. It would be easy to hide the DOS box and only show a static GUI message like, "Extracting. Please wait...", but I find it much more useful to know the current status of the operation. With that said, the current beta versions of AutoIt does allow STDIO operations with external DOS programs. As a long-term goal I plan on moving to this approach (also noted in the ToDo file), which should at least allow me to wrap the output in a GUI text box. I still won't be able to give a simple progress bar, but it would look much cleaner. That'll be coming in version 2.0. :-)