Universal Extractor

[freeko]

1-EML email format used in outlook

2- IMF IncrediMail File

3-db & dbx outlook / express DataBase

Good suggestions, freeko. I started looking into this, and here are my initial thoughts:

EML - These files do not behave the same way as regular MHT files. The most noticeable difference is that they contain two separate boundaries, one nested within the other, which really wreaks havoc with my script. I started playing around with this and implementing some preliminary ideas, but right now it looks like this will take too much work to support properly without enough payoff. If this proves to be a popular request I may add it to a future version, but I'm going to hold off for now.

One other issue is that there are apparently different standards for .eml files. The .eml files saved by Thudnerbird, for example, are standard mbox files, drastically different than these (which, I presume, were created with Outlook Express).

IMF - I've never heard of this before, but if it's nothing more than a renamed cab file, then support is simple. It'll be included in 1.3.

db & dbx - I don't really know what to do with this. What are .db and .dbx files? From the description on the sites you linked to I'm guessing they're Outlook Express files, but I really don't know for sure. If they are, what exactly would you want to do with them? IE, how does this fit in with Universal Extractor's stated purpose of being able to extract files from archives and installers?

EML= i second that.. for initial support you can add the Base64 extraction of the embedded files..

IMF= thanks.. to resolve any future error .. UX should support files via header not extension. In my example. it has "MSCF" signature..which means CAB..

DB= db & dbx is a database of the EML files so you extract EML from these database then extract the content of the extracted EML files.. and it depends on EML support

new founding i have regarding the data stored in xml-document (office 2003, office2007) .. all data is stored in base64 code i had document and i save it in both mht and xml and combared the content i found that the image blocks are exactly 100% same..

Others

MSCAB other links

http://synce.sourceforge.net/synce/unshield.php

http://www.kyz.uklinux.net/cabextract.php

http://www.kyz.uklinux.net/libmspack/

http://www.speakeasy.org/~russotto/chm/

[Camarade_Tux]

One quick word about UPX decompression : AutoHotKey uses upx.exe to compress the scripts it compiles. And if you use upx to expand these files, then you can't run them anymore (stupid CRC ?).

Yeah, I've noticed this too with some, but not all, AutoIt scripts. I don't know why this happens, though. Can any UPX/AutoIt/AutoHotkey gurus answer this question? I'm rather curious about this myself.

I think I understood a bit why : compiled script (.exe) are just text files plus a compiler; they are not native code, they don't obey the same logic.

Now, let's ask a real developper.

[Dumpy Dooby]

Do you intend to ever add a universal compressor?

So like ... one could select a bunch of files and then select how they'd like to pack them.

Edited September 24, 2006 by Dumpy Dooby

[nitro322]

Do you intend to ever add a universal compressor?

So like ... one could select a bunch of files and then select how they'd like to pack them.

Nah. There are already far better programs available that do this better than anything I could write. Besides, it seems to me that most people would prefer to stick with just one or two formats for archiving, in which case something that can support 27 methods of archiving really wouldn't do any good. The reason Universal Extractor is so useful is because it lets you handle content from other users, which is out of your control. Content that you create yourself is within your control, and therefore you can use your own preferred format and compression utility.

Just out of curiosity, though, does anyone else see value in this? Am I missing the mark here?

Edit: Woo-hoo! I'm a full-fledged "Member" now. And it only took 22 months. B)

Edited September 25, 2006 by nitro322

[Dumpy Dooby]

Do you intend to ever add a universal compressor?

So like ... one could select a bunch of files and then select how they'd like to pack them.

Nah. There are already far better programs available that do this better than anything I could write. Besides, it seems to me that most people would prefer to stick with just one or two formats for archiving, in which case something that can support 27 methods of archiving really wouldn't do any good. The reason Universal Extractor is so useful is because it lets you handle content from other users, which is out of your control. Content that you create yourself is within your control, and therefore you can use your own preferred format and compression utility.

Just out of curiosity, though, does anyone else see value in this? Am I missing the mark here?

Edit: Woo-hoo! I'm a full-fledged "Member" now. And it only took 22 months. B)

I was thinking more along the lines of repacking installers. Say you decompress an MSI, replace a file, and then wanna repack it as an MSI. Of course the same would apply to Inno and the others.

That's more of what I was thinking. I'm pretty sure most will agree that for just archiving, 7zip has the best compression.

[MHz]

One quick word about UPX decompression : AutoHotKey uses upx.exe to compress the scripts it compiles. And if you use upx to expand these files, then you can't run them anymore (stupid CRC ?).

Yeah, I've noticed this too with some, but not all, AutoIt scripts. I don't know why this happens, though. Can any UPX/AutoIt/AutoHotkey gurus answer this question? I'm rather curious about this myself.

The AutoIt3 compiler that existed before March, 2006 used to search for the script code at a certain address to locate in the executable. The compiler was changed so UPX alternatives and such could be used so now AutoIt searches for tags which give the location to the script code in the executable. The latter does not rely on a fixed address which means decompressing the executable will not destroy the chances of the script code being found.

AutoHotKey, AFAIK, would be still using the compiler from AutoIt2 (modified) so decompressing it's executables would make the script code missing and would fail to execute.

[Dumpy Dooby]

Mhz, your knowledge of AutoIt is quite impressive. You're there immediately answering everyone's AutoIt questions. Good man.

[Camarade_Tux]

Nice to know. Thanks.

However, is AHK using AutoIt's old compiler ??

[nitro322]

I was thinking more along the lines of repacking installers. Say you decompress an MSI, replace a file, and then wanna repack it as an MSI. Of course the same would apply to Inno and the others.

Ok, I gotcha. That'd actually be pretty cool, but pretty darn difficult to implement. I don't think this is something I would/could ever do, but I'd certainly be interested if anyone else takes a crack at it.

[nitro322]

new founding i have regarding the data stored in xml-document (office 2003, office2007) .. all data is stored in base64 code i had document and i save it in both mht and xml and combared the content i found that the image blocks are exactly 100% same..

Sounds interesting. I'll check that out when I start working on the next version.

[MHz]

Nice to know. Thanks.

However, is AHK using AutoIt's old compiler ??

I just had a look at AHK 1.40 installer and it is using the early v3.0...build of the AutoIt3 Aut2Exe compiler which is a few years old.

[nitro322]

I just updated Universal Extractor to version 1.3.1. This is primarily a bugfix release for version 1.3, focusing on improved 7-zip support, improved "default" checks for unknown .exe files, and Windows 9x compatability. I also made a few other small tweaks and fixes. As usual, full details can be found in the ChangeLog.

I updated the first post to reflect the new version.

Edited September 28, 2006 by nitro322

[ma$e]

Hi nitro322!

I found out what the problem was. To remind u about my problem see post 185.

I changed starting path of my command shell to "c:\" by introducing following keys to the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"AutoRun"=hex(2):43,44,20,2f,44,20,25,43,4d,44,41,55,54,4f,52,55,4e,50,41,54,48,\
  25,00

(The hex value means: "CD /D %CMDAUTORUNPATH%"

[HKEY_CURRENT_USER\Environment]
"CMDAUTORUNPATH"="c:\\"

If I switch it back tzo the default option everything is all right again.

Perhaps u can solve this PRoblem. Thanks for the new release!!!

[nitro322]

I found out what the problem was. To remind u about my problem see post 185.

Great! I'm glad you figured this out. Now that you mention it, I remember having trouble with this myself quite a while back. I ended up deleting the AutoRun value and just creating a hotkey shortcut to cmd.exe instead that drops me into the correct directory. It's been so long ago, though, that I'd completely forgotten about it.

I can pretty easily fix this in future versions. The /d option for cmd.exe will disable the AutoRun value, which should solve the problem.

Thanks for letting me know about this.

[Drugwash]

First of all, thank you for attempting to fix Win9x issues. Using build 1.3.1, I managed to unpack FlashGet v1.73 and Yahoo! Messenger 8 (both Wise Installer) by using option 3 (the /x switch). However, extraction of SlimBrowser 4.08.105 NSIS package failed for some reason and the log is again 2 bytes long (0D 0A). Same thing happened with the Uniextract 1.3.1 package itself (Zip SFX), Win32 OpenSSL 0.9.8c (Zip SFX), MDGx's 98SE2ME package (Inno Setup) and some MS SFX Cabinet files also from MDGx's site.

An improvement might be the option to remember (at least) last source folder when browsing for a package to extract, instead of always opening the bin folder where the Uniextract exe is. As an example, I use FlashGet to always download my files in E:\Downloads and that's where all source packages are, so it would spare a few mouse clicks having it always open the same folder after I used it once.

One tiny problem that was there probably since the beginning is that the dropdown lists in the initial dialog don't show anything but a fine horizontal line when expanded. That is another known Win9x issue that happens in other applications too. Unfortunately, the exe cannot be reshacked as it is UPXed, so - although it's not that big of a problem as it can be worked around by using arrow keys to navigate through previous paths - it might be the last minor detail for you to fix, when and if possible.

However, all these apart, I really appreciate the effort and there's clearly an improvement given that Wise Installer unpacking works. If/when you get some time, I'm sure you'll try to fix the remaining issues too. Thank you very much for all the work done so far!