nitro322

It's just leftover debugging code. Aside from the annoying message box, it'll function properly. This will be fixed in the next version.

This pretty much nails the issue. Thanks, phkninja. B)--> QUOTE(chris.b @ Feb 26 2007, 12:59 PM) <{POST_SNAPBACK}>nitro, many people will be happy if you would update the installation package with the corrected TrID Definitions.I'm working on a 1.5.1 release right now, which will mainly address issues with 1.5 rather than introduce much in the way of new features. No release estimate right now, but I plan on including the updated definitions with it. I'll also explore options to ease future updates. Someone mentioned an auto-updater previous, though I don't think I'm quite ready to go that far. By the way, I strongly suggest that UniExtract users do not replace the TrID defs package with the one available from TrID's home page. I had to add/replace/delete a number of definitions to make it work correctly with Universal Extractor. I submitted the changes back to the author, but I don't know if he'll roll them into his official package. If and until that happens, please stick with the version included with UniExtract. I'll check it out, but I haven't had much luck with recent Java packages, so no promises. It was from Inno Setup installers. I've already fixed that problem. Yeah, definite typo. I'll get that fixed as well. Great idea, and something I'd like to see myself, but it'll have to wait a little while before I can do it. Perhaps 1.6? It sounds like you have some interesting ideas. I'd be happy to discuss them further, but as I mentioned above it'll be a little while before I'm able to implement any major new features. UniExtract should not currently write anything to the registry. I switched to using an .ini file for the 1.4 release.

Actually, that's already been taken care of. There was some miscommunication, but it's been worked out now, and I just forgot to take that line out of the todo file. Thanks for the offer, though.

B)--> QUOTE(chris.b @ Feb 23 2007, 05:51 PM) <{POST_SNAPBACK}>at the moment I can't see the reason why uniextract doesn't recognize them as ms cab archives.Universal Extractor doesn't recognize them as MS Cab Archives because TrID isn't reporting them as such. I just updated the TrID definition for that filetype. Please try downloading this file and extracting it to the bin\ directory of your UniExtract installation: TrIDDefs.rar This file contains the updated definition. You'll want to replace the existing TrIDDefs.TRD in the bin\ directory. Let me know if that works for you, please. Also, if anyone else discovers a similar issue, please report it here, along with a download link to the specific file. I can use scan those files to add support for them (and similar files) to figure versions of UniExtract.

B)--> QUOTE(chris.b @ Feb 23 2007, 11:14 AM) <{POST_SNAPBACK}>Tonight I installed v1.5 and since then Microsoft Hotfix CAB archives are treated as 7zip files and only _sfx_xxxx._p files come outta there.Edit: Umm, was a bit hastily. It's only WINDOWSXP-KB925876-X86-DEU.EXE that's extracted like 7zip. Ok, so just to confirm, the patch you linked to is the ONLY one that behaves this way, correct? All others are extracted as they should be?

Dang. I'll check it out later today. Thanks for letting me know.

Yeah, just hadn't yet had a chance to announce it here. Thanks for stealing my thunder. B) I'm going to update the first post with new download links and a copy of the changelog for this release. In the meantime, you can find out more information about the new features available in Universal Extractor 1.5 from this post on my website, and download it or view the complete changelog from UniExtract's home page. As usual, feedback is welcome.

Yeah, agreed. I'll check it out and see if there's anything I can do, but this will be a low-priority request. Oh, now that's just mean. I was actually on thier site earlier today to verify that I was using the latest version before creating the final 1.5 package, and only 5.1.9 was available at that time. Oh well. I've already packaged up 1.5 at this point, and will not be making any more changes. Right now I'm just updating some documentation in preparation for the release. The Inno Setup issue will have to wait until 1.5.1. Thanks for letting me know about it, though.

The administrative install option fails, but the other two work for me. The output isn't pretty (GUIDs contained within the filenames, some missing extensions, etc.), but it's there. Does it not work for you at all, or are you just seeing that ugly output? The administrative install is usually the only one that gives really clean output. If one of the other "ripping" methods are used, you'll likely end up with jumbled filenames. It can't be helped.

Huh. Would you believe I just found a generic way to do this? I still need to do a lot more testing, but early results look promising. It's too late to include it in version 1.5, but I'll certainly include it in the next version if everything pans out. Thanks for making me look into this again.

This is based on the same FEAD Optimizer packaging system that is used by Adobe Reader. Unfortunately, there's no way (that I've been able to find) to simply extract the files. You have to run the installer, wait for it to reconstruct the setup files (basically doing a self-extraction), then grab the reconstructed files when the actual setup begins. While this is easy enough to do manually, it's rather difficult programmatically because each and every product version can behave differently. For example, I added support for Adobe Reader 7.x and 8.x installers to UniExtract v1.5, but both of those behave differently version each other, and from version 6.x (which is not supported). I'd have to write another custom extraction/copy routine for this as well, which I'm not really inclined to do at this time. I'll keep it on the back burner, though, in case I ever find a general extractor for these types of packages. Good lord, a 24 MB .mht file? That's just downright evil. I can confirm that it doesn't work, but I haven't had a chance to do too much research. It appears to use a different identifier for file names than ExtractMHT expects (eg, different than everything else I've tested). I'll look into updating ExtractMHT to support it if possible, and then I can role that into the next version of Universal Extractor (1.5.1, or whatever). I tried to do this in the past, but I never could make it work. I think I was using dmg2iso as well, but it failed on every single test file I threw at it. If you (or anyone else) can find something that works, I'll be more than happy to add it.

Oh. Sorry man, I wasn't really trying to send a message. I was just in a rather bad mood that day and Windows' lack of cooperation just wasn't helping. I would certainly welcome your continued feedback, as I've been able to fix quite a few issues in the past that I wouldn't have otherwise known about. True, Windows 9x is not a supported OS, as I've mentioned a couple of times, but I still want UniExtract to at least be usable for users of that OS. Obviously all of the features may not work, but there's no reason why the core functionality of selecting a package and extracting its contents should fail. Anyway, I'd hate to see you go, but I understand I probably came across as an a** in that last post. Just don't take it personally, please.

You got it working? What'd you do? Edit: I haven't had a chance to mess with it anymore since my last post.

Yeah, I know it's been a long time coming. Believe me, I'm quite ready to be done with this version. As for the actual release date, I'm thinking it should be ready on Monday. Two reasons: First, I'm still waiting for one language file. Getting the updated language files has been the main delay, but at this point I'm ready to just drop the missing language and then add it back later once I do finally get the updated version. Second, I may be away from the computer for the next few days, so I want to hold off on the next release. The last time I rushed out a release before leaving town (Thanksgiving) proved to be a rather bad experience. I don't want to repeat that. So, check back here next Monday. After playing around with it for a few minutes, I think this is yet another path-related issue, which has been the root cause of almost every problem found in Windows 9x so far. <rant>What a complete and total piece of crap.</rant> I have not yet been able to duplicate your exact error, as extracting the MSP file works fine for me even under Windows 9x. However, I did come across some other weird problems which may or may not occur depending on how Universal Extract is used, how it was installed, which options were selected, whether Bill Gates is currently in a good mood, the alignment of the stars and planets, etc.; basically, a whole lot of dumb crap that makes no sense whatsoever. I'll keep playing with it and see if I can get something workable, but I'm pretty close to losing my patience with it. By the way, I also found out that the new "append missing file extensions" option doesn't work under Windows 9x. UniExtract just freezes up, and I have no idea why. I'm not in the mood to debug it, though, so I just disabled the function call if run from Windows 9x. This is an FYI, in case you're wondering why it's not doing anything different when enabled.

Confirmed, works fine.

Is this what you're talking about? Check out the "download the code / gadget from OdeToCode" in the second paragraph of the article. I tested that file and it does indeed work fine.

If they're just renamed Zip files, then they should work just fine with version 1.5. TrID should detect the fact that it's a Zip file, regardless of the extension. I still wasn't able to test it, though, because I still couldn't find an example to work with. I tried downloading "Vista RTM Sidebar for Windows XP" from the link you provided, but it didn't include any actual .gadget files, nor could I find any other obvious link in that thread (of course, I don't know what I'm looking for). If you can give me a direct link to something, I'll test it out to be sure. I just tested this file under XP and it seems to work fine. I have not tested any cmdTotal functionality under Windows 9x, so that's likely the cause of the problem. I'll take a look at it when I get a chance and see what I can do, but as a reminder I don't officially support Windows 9x for the reasons listed here.

What are .Gadget files? If it's something that requires Vista, then I won't be able to add support for it anytime soon. If it's something I can test out under XP, then I'll at least give it a shot.

Thanks for the reply, Makave2345. I was really hoping to learn how to do it myself, though. It's more about the learning process than the convenience for me. I'll keep poking around at it and see if I have any luck. I sure wouldn't mind any pointers, though, if anyone else has figured this out. Thanks,

I'd like to create an installation package for the .NET Framework 2.0 that contains the two available patches slipstreamed into the installer. Basically, I don't want to have to install the framework, then each of the patches. Does anyone know if this is possible? I used this method for version 1.1, with which I was able to slipstream SP1 and both patches into the installer without a problem, but so far I've not been successful with version 2.0. I tried the same process I used for 1.1, but that just resulted in a completely corrupt installation. Yay. Any suggestions would be appreciated. Thanks.

Brief update: The primary delay in releasing 1.5 final has been getting the language files updated. While I've already received most of them, there were still a few that I was missing. Well, I just realized earlier tonight that my spam filter had been falsely identifying the translators' e-mails as spam. ****! So, I got that issue worked out and e-mailed everyone about the issue and asked them to please resubmit their updates. I've already received two of the four missing files. Hopefully it won't be long before I receive the two final ones. As soon as I do, I'm packaging 1.5 final and releasing it. I cannot begin to express how ready I am to be done with this version. Oh, and in case you're interested in reading a bit of information about a couple of the new features in 1.5, you can check out this post on my website: Two very cool applications - cmdTotal and TrID

I agree, but I cannot do it for reasons stated previously. I've considered that, but it won't be included in version 1.5. Perhaps next version. I'd certainly like to do this. Version 1.5 is already frozen, so I'll look into it for the next version. I already did this for 1.5, using TrID, in fact. Check the beta changelog from a few posts back for more details.

I don't know how many lines of coding it would require. The issue is not implementation time, it's implementation method. Creating a cascading context menu, as far as I can tell, requires a shell extension DLL. Doing this, again as far as I can tell, requires the use of the commercial version of Visual Studio (it requires MFC components, which are not included in the Express edition). There are three problems with this: 1) I write free, open source software; I'm really not interested in buying a commercial application to do it 2) Because I write free, open source software, I feel that requiring a commercial compiler to modify the code would largely defeat the point of the license 3) I primarily write scripts, not system libraries; doing something like this would be a completely different experience Now as I've said in the past, if anyone is willing to help out and/or contribute such an extension for UniExtract, I'd be more than happy to include it. That's not very likely, though, so for now it'll remain on my list of long-term goals.

Again, you have a good point. I'll consider adding this option to the next version. For now, though, I'm just waiting on a few more translations before releasing 1.5 final, so I don't want to make any more "feature" changes that may delay the release even longer (if that's even possible at this point... sigh). I'd like to make this an option, but at this point it'll have to remain on the long-term todo list. The situation hasn't changed any since the last time it came up. You may want to check out urie's suggestion, though. I played briefly with CMenu a while back, and I think you can make it do what you want. It's a pretty nifty little program. As urie pointed out, it is indeed built with Inno Setup. In addition to the syntax help he posted, you can also simply run the installer with a '/?' switch. This will display a list of all standard Inno Setup options (pretty much the same thing as urie posted) as well as all of the custom tasks and parameters supported by UniExtract. This isn't a standard feature of Inno Setup, though; I added it using my Inno Setup CLI Help script. <not-so-shameless-plug>Actually, any package developers can very easily add this same kind of help information to their Inno Setup installer by using this script. As a developer it doesn't really benefit you any, but from a user's perspective it's immensely useful to have a detailed list of command line options readily available for any given program. That's the main reason I wrote it to begin with - I want other package developers to start using it as well, so that I, as an end-user, can benefit from it. If you write any applications that use Inno Setup for the installer, consider checking it out.</not-so-shameless-plug>

I thought about that, and the basic reason is speed. One of the InstallShield test files I use is the installer for Alien Arena. It's over 100 MB, and copying that file to another directory, whether short on disk space or not, takes a while. Given that this is for purely temporary purposes, I think simply moving the file then moving it back is the easiest and fastest. Of course, I do understand your point: if some part of the move/move back process fails for any reason, then the file would be left in the "output" directory, which could certainly cause confusion for the end user. However, this method has been in use since Universal Extractor 1.0 (and I think 0.8 as well, though I'm not sure), and Perch's issue was the first reported time this process process had failed. I think that's a pretty good record on its own, and I've since fixed the cause of his problem so the root directory issue will no longer be a problem. So, I feel the risk of move/losing a users file due to program failure is minimal enough that the significantly faster move process is safe to use. Great question, though.