nitro322

This is using an old version of NSIS that is not supported by 7-Zip. I looked into CreateInstall a while back for Gentee installers. I couldn't figure out any way to extract it, though. I can't even figure out what kind of installer this is, let alone how to unpack it. Thanks, will check it out.

That simply means that the file cannot be extracted/unpacked/decompressed. There's nothing that you really can do. Just click cancel to exit. If you'd prefer, you can click OK to analyze the file in PeID, but that won't be of much help for end-users.

Thanks for the suggestion. I'll look into it for the next major version. This wouldn't be difficult to implement, but I'm trying to understand the usefulness. You can drag-and-drop a file onto the binary or a shortcut to the binary just as fast as the GUI. Alternatively, if you're using the installer and have context menu associations enabled, you can simple select all of the files that you want to extract, right-click on one of them, then Click UniExtract to Subdir. All selected files will be extracted to their own subdirectories. Any other thoughts on this?

This has been requested several times already, but for reasons I explained in previous comments it cannot be done without a shell extension DLL. Please search through previous posts for more details.

Well, WinRAR supports a temporary extraction mode, which you can configure in the SFX options. This does the trick nicely, but it's an all-or-nothing approach. Eg, you have to specify this when creating the archive, so it'll either always delete itself after execution, or it never will. There isn't really any clean/easy way to do what you asked. It's possible to write a batch file that can delete the extracted files, but given that RAR SFX can only execute programs before or after extraction, you can't tell it to wait until after the program has completed execution before running the cleanup script. I guess you could work around that by having WinRAR launch the cleanup script first, then having it run the application and wait until execution has completed before prompting you and deleting the files, but like I said, it's not very clean. Another issue is that you're talking about deleting groups of files without any real interation (other than simply clicking Yes). I trust WinRAR to do stuff like this in temporary extraction mode because it's specifically written to create unique directories and ensure it doesn't delete any other files, but I'd be a heck of a lot less willing to run a custom written script on my system that's going to do the equivalent of deltree on any directory. Call me paranoid.

Thanks, I'll check this out when I get home. Glad to hear it. Another Win9x user has sent me some bug reports via e-mail, and I believe there are still some problems with this version as well, but I'll continue to look into it. Will check it out. Thanks for the tip.

That's a good idea. I'll start doing that. Edit: Well, I tried to do it, but couldn't figure out how. Is it possible for a non-admin to change the title of threads? orlp, thanks for all of your work on this. This has been requested several times in the past, but I was never able to get any sample apps to use for testing. Your code looks good, and I'd certainly like to add it to the next version of UniExtract (I couldn't do it in time for 1.4.2), but I still need one or more sample apps for testing. Could you please post a download link to an application that uses this format? Thanks! Edit: After rereading your post I see that you mentioned a couple apps. Unfortunately, I don't have a copy of Photoshop, and obviously you can't post download links for it. Do you happen to know of any other apps, preferably freeware or shareware, that use this format? I'm not familiar with Homesite; is that something I can download?

I just posted Universal Extractor 1.4.2. This version has a lot of improvements, including a fix for the crash issue in 1.4.1. Highlights include: Full internationalization support for installer New preferences page for installer to set history and debug options introduced in 1.4 Four new languages included by default Various bug fixes for Windows 9x Please see the first post[/rul] of this thread for downloads and detailed change information.

Yeah, that's my bad. I thought there was a specific topic for questions like this, but I couldn't find it when looking through the list earlier. Obviously I need to look harder next time. Oh, believe me, I understand that position. Believe it or not, I'm actually a security analyst by day (and script-fu ninja by night ), and I've been giving this a good deal of thought before posting. I know it can help prevent session hijacking (among other things), but as I stated in my original post it just doesn't seem worth the inconvenience on a site like this. If there was any kind of sensitive data at all involved I'd understand, but considering this is a public forum, there isn't a whole lot of secrecy involved. What's worse, forcing users to continually reauthenticate, on an unencrypted site no less, could potentially expose them to various password sniffing, cross-site scripting, and man-in-the-middle attacks. That's actually more of an issue for me than the convenience factor - every time I submit my password in paintext, the security guru in me cries out in pain. Of course, this is really only an issue for users that regularly visit from multiple systems, and I wouldn't think there's a significant percentage of them, but it is quite annoying when you're one of them. I'm not going to try to change your mind about this, as I'm sure you have your own reasons for it, but would it be possible to perhaps make this a user option as opposed to a global system option? Eg, when if I setup a new account then I'm restricted to logging in from a single system by default, just like today, but I have the option of setting it to allow me to login from multiple systems if I so choose. Just a thought. Thanks for the reply.

When I login to the MSFN forum I always check the "Remember Me" option, but that only seems to work if I return to the site using the same computer. If I change computers/OSes, I have to re-authenticate, even if I've alreade previously logged in and selected the "Remember Me" option from that system. Given that I regularly use 5 different systems/OSes, this can be quite annoying. It may seem that this is simply how it's supposed to work, but I regularly browse the AutoIt and Hydrogenaudio forums as well, both of which appear to use the same forum software, and neither behaves the same way. Eg, if I login to AutoIt from my desktop, then login from my laptop, I will then remain logged in next time I visit from either system. If I were to do the same with MSFN, I'd have to login again from my desktop the next time I visited. Is there any particular reason that the login system is setup like this on MSFN? I guess I can see it as a security feature, but it doesn't seem like it's worth the hassle on a site like this. I'd just like to know the rationale behind it. Thanks.

FYI, a bit more information about the crash issue in 1.4.1: http://www.legroom.net/modules.php?op=modl...cle&sid=223 I'm still working on 1.4.2, trying to knock out a dang Windows 9x issue right now.

I originally planned on releasing 1.4.2 tonight to just address the crashing issue that was previously reported, but in the process of working on it I decided to throw in some other stuff as well. It's taking a little while longer than anticipated to get the changes made, and of course I'll want to do proper testing this time , so in the meantime I'm making available a "patch" (for lack of a better term) to fix the issue for current 1.4.1 users. You can download an updated version of the UniExtract.exe binary from here: http://www.legroom.net/~jbreland/transfer/UniExtract.exe Replace the copy of UniExtract.exe in your existing install with this new version, then use as you normally would. I should have a proper 1.4.2 release out within the next day or so, so unless you're currently affected by the crash issue, you may want to just hold off until then before upgrading.

I'm back at my computer now, so I'll try to get an update out ASAP. As for some of the previous comments... I plan on adding an archived section to my website for just such a need. I've actually maintained copies of UniExtract going all the way back to version 0.8, but they currently sit on my home file server. I'll make it available through my website at some point. Yeah, I have all older links set to automatically download the latest version. Nearly every release I put out fixes bugs in addition to any new feature support, so I want to make sure that people are always downloading the latest version, even if they're following an old link. As I said above, I plan on making archives copies available through my website, but that'll be hosted separately than the current release. That was the only Chinese file that was e-mailed to me. Can you send me yours? I have no problem including it if it's more accurate. This is most likely the issue, as you pointed out. This issue crept in while adding support for dynamic language selection in 1.4.1. It was a rushed release, as I was trying to get it out before heading out of town for the holidays, and I missed this issue in my testing. My bad. As I stated at the beginning of the post, I'm going to put out a new release ASAP to fix this issue. Stay tuned.

A couple other people have e-mailed me about this issue as well. I recommend holding off on the 1.4.1 upgrade at this time. It may be a few days before I'm able to fix the problem and release a new version, so please continue to use 1.4 or 1.3.1 for now. I'll post another note once I've had a chance to fully investigate.

I just posted Universal Extractor 1.4.1. As noted in my previous post, this is primarily a bugfix release for some of the internationalization issues. I think I fixed a couple other issues as well, but can't remember the details of the top of my head. I'll update the first post in this thread to include updated download links and the full ChangeLog. Also, I'll be out of town for the next few days for Thanksgiving. I'll check the forum when I return to see if there were any issues with this release (hopefully not ). Have a happy Thanksgiving, and enjoy the new release.

Brief update: I've been working on some issues that have been reported, as well as working on improving multilingual support. I plan on releasing version 1.4.1 soon, hopefully before I leave town for Thanksgiving. I've also received a few language files, which I had meant to post sooner (to prevent anyone from doing duplicate work), but I've been delayed working on the previously mentioned issues. Here's what I currently have: Simplified Chinese German (actually 3 separate submissions for this one) French I saw a couple previous posts about adding language support - if it's not on this list, feel free to submit it. I'm sure other users would appreciate as well. If it is already on this list, then I appreciate the offer, but there's no need at this time. Once I do make the language files available, though, I'd appreciate a quick double-check to ensure that everything is correct (translated text, GUI display/layout, hotkey support, etc.). As I can only read English, I'm pretty limited in my ability to check the translation files. This should already be fixed in the dev version. Please check it again when I release 1.4.1 and verify. Just set history=0 in the INI file (as you've already done) to disable registry writes for the standalone version. The file associate registry entries are only applicable to the installer. Yes, I'm aware of this. Is that a problem? I've updated 1.4.1 to reinitialize the GUI when a new language is selected, so that it displays the correct language immediately after selection, but it's still not written to the INI file until after a file is selected and execution begins. Given that the whole purpose of UniExtract is to extract files, I don't see why you'd have any need to run it for any other reason. If you do have some issue with this, though, please let me know. This is also a known issue. There are about 130 separate language items defined in the language INI files. It would be rather time-consuming, as well as increase ongoing maintenance time, to hardcode these items. Given that use of Universal Extract already requires a group of files in a particular order (all support binaries under bin\, for example), I don't think it's unreasonable to expect that users leave the lang\ directory intact. By the way, the ??? is hardocded so that I know if a particular language item is missing. It's a debugging item for me. Users (obviously) should never see it, assuming that all translation files are correct. You can do this simply by setting the "Write debug file to" option, or setting debugdir in the INI file. No code changes should be necessary. You can do this by unchecking the "Track archive history option", or setting history=0 in the INI file. No code changes should be necessary. Nope, I certainly don't mind, but honestly I don't see the need. I added support for both of these options to version 1.4 specifically so that users would have an easy way of changing them. If you still feel the need to resort to source code changes, then I must've done something wrong. Can you please explain why the options do not work for you?

Universal Extractor 1.4 has been released. As previously stated, the two primary goals of this release were to make it more "portable" and to add support for internationalization. I also added a few tweaks and fixed a few bugs to try to speed up installer extraction. Warning: Adding support for internationalization required a substantial number of changes to the code, which may have introduced some new bugs. If 1.3.1 is working fine for you, it may be a good idea to stick with it for a little while until 1.4 is more thoroughly tested. If, however, you are a not a native English speaker, typically run applications from a portable USB drive, or just live for bleeding-edge software, then I do recommend upgrading to 1.4. Anyone interested in translating UniExtract to another language should follow the instructions in English.ini. If you do this, please send me the completed translation file so I can include it in the next version of UniExtract (as well as probably make it available for download directly from my site). This way everyone can benefit from your work. I've updated the first post to include direct download links for the new version, as well as the complete ChangeLog. Thanks! I also received a German file as well, so I'll add them to the website. Yeah, looks like you're right. I'll have to check it out later tonight when I'm back in Windows, but I definitely don't think that $dircontont is a valid variable. Thanks for reporting it. Thanks. I'll check it out tonight.

That's a Setup Factory installer, for which I have not been able to find a utility capable of extracting.

Sure, can you please provide a download link?

inutil, can you confirm that this is still a problem? Did it perhaps fix itself after you rebooted? Can anyone else confirm that this is a problem? I just created a limited user account (after having already installed UniExtract as an Admin), and the context menus work perfectly fine. I did a little bit of research into how file associations are handled for admin vs. user, and as long as UniExtract is installed with an admin account the associations (and therefore context-menu items) should apply to any and all accounts on the system. That seems to be the case on my system, so I'd really like to hear feedback from anyone else that may have seen this problem. Skype cannot be extracted. I've looked into this in the past, and they use a custom version of Inno Setup that's not supported by innounp. I'll be happy to look into Easy CD/DC Extractor. Assuming this is freeware/shareware/demoware, can you provide a download link?

I've started preparing for the next version of Universal Extractor. This version will primarily focus more on the user interface than backend format support (as opposed to 1.3, for example, which was almost entirely backend-related). The biggest goals I'd like to achieve are making it truly "portable", for those of you that like to run it from a USB drive, and add proper support for internationalization. I'm sure there will be some other tweaks here and there as well, but most of my work will focus on those two goals. With that said, I'd like to solicit feedback on the portability issue. As far as I can tell, there are 2 main issues that portable users may have: 1. It writes an archive/directory history to the registry 2. It writes the debug file to C:\uniextract.txt I can address the first issue by switching to a local .ini file rather than using the registry for history. This .ini file could also be used to set preferences, such as "don't track history at all", so portable users can have it preconfigured to ensure that it doesn't leave any traces on the computer's hard disk. The second issue should be resolvable by allowing the output directory to be customized, which can be another option set in the .ini file. This file MUST be written, as it's used during the extraction process in addition to simply being left there afterward in case there's an error, but allowing it to be written to any given directory (such as the root of the USB drive) should be a reasonable compromise. Any other suggestions or comments along these lines?

A user named Jason Murray e-mailed me about some enhancements he had made to Universal Extractor a couple months ago. In his own words: "it adds RTF to HTML, PDF to text, lit to text, and HTML to text... For rtf I use Drag2HTML found at http://www55.pair.com/betasoft HTML to text uses dg9ep's html2txt at http://www.u32.de/html2txt.htm pdf2txt uses ftp://ftp.simtel.net/pub/simtelnet/msdos/txtutl/pdftxt1.zip, ... To explode lit files I use clit from http://www.convertlit.com/download.php" He provided a diff against UniExtract version 1.3 to add these features, making it really easy to add support for these formats (just apply the diff, drop the above files into the bin directory and recompile). I had originally planned on adding this to the official version, but after going back and forth on it a good bit I ultimately decided against it. The core purpose of Universal Extractor is file extraction, not conversion. Sure, the argument could be made that this allows for extraction of, for example, text from a multimedia PDF file, but I'm focused more on extracting files and components from archives/installers than extracting content from an already "unpacked" file. The LIT extraction may likely make it to UniExtract, as it does seem to actually extract nested files out of the LIT format (similar to decompiling an CHM file), but the rest probably will not. However, I'm sure there are some people out there just like Jason that could benefit from this, so I wanted to take the time to post this information here and make it available for everyone. If you're interested in adding any of the above conversion features to UniExtract, you can do so yourself using the Universal Extractor source code and Jason's diff that I've attached to this post. One note, however: This diff was written for version 1.3, which was the most recent version as of the time Jason e-mailed me. I've since released version 1.3.1, however, so there will likely be some changes that need to be made before the diff can be applied. Consider this more of a blueprint than the exact line-by-line code and you'll be ok. Jason, if you follow this forum, thanks for sending this my way! Edit: I had to add a .txt to the end of the filename to get it attached. Just rename it to UniExtract_1.3_1.3a.au3.diff after saving it for the original filename. UniExtract_1.3_1.3a.au3.diff.txt

I'll explore the Send To option. Also, while I agree with you that there are seemingly too many shell extensions out there, I personally feel that this project (and its users) could benefit from one. One of the most request features is a cascading menu for the UniExtract options, which I cannot do without a shell extension. Another feature that has been requested a couple times (and one that I'd like to see, as I'm used to WinRAR's great implementation) is the ability to drag the icon to a specific directory and extract the files there. Again, I believe you need a shell extension to do this. One final feature that I think would be nice, though by no means essential, is a simple icon in the context menu to differentiate UniExtract from any other archiving/extraction programs that may be installed. If I ever do get this included, it will be optional. Of course, none of this debate really matters unless someone actually steps forward and volunteers to do this. I looked into this a few weeks ago at someone else's request, but couldn't find anything suitable. The closest I could find were two command line scripts, but one required a perl installation and the other required a python implementation. Neither of are very portable. I'll look into unmakesis.exe and see if that'd be usable. Can you please provide a download link? Edit: Surfer made this request, as pointed out just above.

If anyone is interested in archiving their audio CD collection, you may be interested in checking out AutoFLAC. It automates ripping CDs using EAC (Exact Audio Copy) and FLAC, which combined allows for perfect backup copies. Additionally, it supports a "write" mode as well that automates the process of decoding back to WAVs and burning the CD with EAC, should the originals be lost or stolen (which was actually my original motivation to write this. I usually try not to pimp my own software, but one of the MSFN mods actually came across it on his own and found it so useful that he recommended I post about it here. I guess that's a pretty good endorsement. I don't want to spend too much time discussing it here, as it's not at all related to Universal Extractor, but if you're interested you can get full details about it from the AutoFLAC home page. Additionally, there's a long discussion thread about it over at the Hydrogenaudio Forums. Hydrogenaudio has become the main point of discussion for AutoFLAC (similar to this thread for Universal Extractor), so if you have any questions about or suggestions for it I'd suggest posting it at the above link. Enjoy.

That's a great tip, DerekB, but unfortunately AutoIt isn't very well suited to work with DLLs like this. It can be done, just rather painfully from what I've been able to tell. Besides, I'm really not much of a programmer myself. I can write some pretty bad-a** scripts (if I may brag a bit), but when it comes to low-level program, system calls, etc., I usually have to leave it to the pros. That's why AutoIt relies on so many support programs to get the job done - I have absolutely no idea how to rip data out of a .zip file, for example, but I can most certainly script using unzip.exe to perform the job. I'll have to stick with the PEiD .exe for the time being, but I'll keep an eye on it. This is a great idea, and I'd love to implement it, but as far as I can tell this behavior requires a shell extension DLL. All of the programs you mentioned register a DLL with Windows Explorer to enable this options. Unfortunately, as I stated in response to DerekB's response above, this kind of programming is beyond me. I actually did look into modifying the source code for 7-Zip's DLL to do something similar, but I wasn't able to make that work either, as these DLLs apparently require the commercial version of Visual Studio (for MFC support). Given that I write free and open source software, I really don't have any intention of purchasing Visual Studio. With that said, if any other talented hackers out there are interested in improving Universal Extractor and would like to contribute such a DLL, I certainly wouldn't be opposed. I'll have to investigate this. I'm not sure what the problem is at this point, but I'll do my best to resolve it for the next release. Thanks for reporting it. The C:\ issue has been debated before, and I do plan on changing this in the next version. However, the administrative rights issue that you mentioned is an argument that I haven't heard before. That's certainly a more serious issue than previous discussions have addressed. I took at look at your changes to the source code, and they're pretty good. In fact, it'll probably save me some time when working on the next version. The only problem I could find were a couple cases where the new log file was properly quoted (%temp% has spaces in the default path). I fixed the problem and did a small amount of testing on the attached copy. I can't guarantee that I didn't overlook anything, but this should do the job of writing the log files to %temp% rather than C:\. To use, simply compile the modified script with AutoIt, then replace the existing UniExtract.exe binary. I'd recommend backing up the original UniExtract.exe, though, just in case this one has any unexpected problems. Again, this for reporting this. UniExtract_mod.au3