[nitro322]

freeko, on Sep 11 2006, 06:31 AM, said:

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?

[freeko]

nitro322, on Sep 12 2006, 07:57 AM, said:

freeko, on Sep 11 2006, 06:31 AM, said:

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

This post has been edited by freeko: 12 September 2006 - 08:29 AM

[nitro322]

I just released version 1.3. I updated the first post in this thread to include the changes, as well as link to the downloads and official site.

Enjoy!

This post has been edited by nitro322: 14 September 2006 - 11:58 PM

[gmx]

Thanks Nitro. This is an awesome tool thats saved me lots of time when i started repacking apps for my UACD

[freeko]

Thanks alot for v1.30

regarding
add JPEG extraction support? - comment 195

try

JPG Extractor 0.01
http://dwing.51.net/download/xJPG.zip

just 1.5kb in size

[Drugwash]

In first post, links appear to be pointing to old 1.2.1 build, although they show as pointing to 1.3. Could you please fix it? Thank you.

[Acheron]

Thanks for this release. Shell integration works ok now.

P.S. I would really like it if you could make the taskbar button for Universal Extractor visible, so you could end the program manually, without using taskmanager.

This post has been edited by hp38guser: 15 September 2006 - 09:08 AM

[Drugwash]

I tried both 1.2.1 and 1.3 (no-install versions) and I can't seem to be able to extract (at least) NSIS packages. It appears to detect package type as NSIS, it opens a DOS box and then closes and creates a file called &1 with no extension and length zero in the destination folder.
I'm running Win98SE with some upgrades (USP, KUP and others). What would you advise me to do?

[nitro322]

freeko, on Sep 15 2006, 07:39 AM, said:

try JPG Extractor 0.01
http://dwing.51.net/download/xJPG.zip

Will keep it in mind. Thanks.

Drugwash, on Sep 15 2006, 08:30 AM, said:

In first post, links appear to be pointing to old 1.2.1 build, although they show as pointing to 1.3. Could you please fix it? Thank you.

Oops. Fixed now, thanks for pointing it out.

The reason it was still downloading v1.3 is because I created symlinks on the server to redirect requests for all older versions to the new version. Looks like that helped out this time.

hp38guser, on Sep 15 2006, 08:34 AM, said:

Thanks for this release. Shell integration works ok now.

Excellent. I was going to post and ask you to try again with this version, but I see you didn't waste any time testing it out. Glad it's working for you.

hp38guser, on Sep 15 2006, 08:34 AM, said:

P.S. I would really like it if you could make the taskbar button for Universal Extractor visible, so you could end the program manually, without using taskmanager.

How often do you have to terminate UniExtract.exe manually? If this you need to do this on a regular basis, then there's a bug somewhere that should be fixed. Please share any details you can about this.

Drugwash, on Sep 15 2006, 09:49 AM, said:

I tried both 1.2.1 and 1.3 (no-install versions) and I can't seem to be able to extract (at least) NSIS packages. It appears to detect package type as NSIS, it opens a DOS box and then closes and creates a file called &1 with no extension and length zero in the destination folder.
I'm running Win98SE with some upgrades (USP, KUP and others). What would you advise me to do?

Hmm... few suggestions:

• Can you send me a link to download that specific NSIS package? I can tell you for sure if it's supported or not.
  
• Can you try extracting the AutoIt installer? This one is definitely supported. Please let me know what happens.
  
• What happens if you try extracting a simply Zip file?

You also mentioned that you're running Windows 98. To be honest, I've never testing this on anything prior to Windows 2000, so I don't know if or how well it works on older 9x-based systems. Has anyone else on the board tried using it under Windows 98? Can you share you experience?

[Drugwash]

1. The eMule installer, the SlimBrowser installer... They're NSIS installers.
2. The result is the following, along with the &1 file in the source folder this time:
3. It says "Extracting file from zip archive", opens/closes a DOS box but nothing can be found in the destination folder.

It appears that it calls PEiD 3 times (in this particular case; for other files it only calls it once or twice). After that, the error message box appears. Most likely it's a Win9x issue, as the Dependency Walker log reveals missing functions in some modules (log attached below).

 DWlog.txt (124.79K)
Number of downloads: 25

[the_guy]

About the 98SE issue. I have experienced that with every archive except type 1 updates (those don't work regardless, as update.exe requires missing dependencies). I'm not sure about ME though. I'll try it this weekend and get back to you.

the_guy

[Galactical]

nitro322, on Sep 15 2006, 05:58 AM, said:

I just released version 1.3. [...]

Enjoy!

Thanks, this is very handy

The error log location is 'hard coded' to the root of C:\, but different users will have different preferences and disk layouts. Could you include a means for us to change that location, perhaps to any/all of: the Universal Extractor installation directory; or the starting location for the extraction; or the target location for the extraction; or just anywhere the user prefers?

Thanks

[the_guy]

I have no idea why, but the issue on 98SE is also on ME.

the_guy

[Drugwash]

That's bad news. Maybe actually building the main exe on a 9x system could fix things. No idea if AutoIt does work on 9x and currently I have no free HDD space to install and test. Could you test it, nitro322, maybe in a virtual machine or something?

[maska]

I'm having problems extracting latest GOM Player setup; I think this wasn't a problem with version 1.2.1. The program hangs at Extracting files from: 7-Zip Installer package. If I cancel the operation not all files are extracted.

This post has been edited by maska: 17 September 2006 - 05:04 AM

[Camarade_Tux]

maska, on Sep 17 2006, 11:00 AM, said:

I'm having problems extracting latest GOM Player setup; I think this wasn't a problem with version 1.2.1. The program hangs at Extracting files from: 7-Zip Installer pacakage. If I cancel the operation not all files are extracted.

Working with 1.2.

I also wanted to say, 1.3 installer could not be extracted with UniExtract1.2.

And, indeed, 1.3 does not work with this player.

[Hanschke]

here i got an error message:

[nitro322]

Drugwash, on Sep 15 2006, 11:58 AM, said:

It appears that it calls PEiD 3 times (in this particular case; for other files it only calls it once or twice). After that, the error message box appears. Most likely it's a Win9x issue, as the Dependency Walker log reveals missing functions in some modules (log attached below).

PEiD is supposed to be called 3 times if the filetype isn't obvious. UniExtract runs PEiD in three different modes (deep, hardcore, and external), and then takes action based on the results of the three scans (each scan can return different results). This is new behavior in 1.3.

I agree, it's most likely a Windows 98 issue. I have two statements here (please read both fully):

1. I do not and really can not support Windows 9x. I haven't done anything that should explicitely prevent it from working, but I don't have access to any system running Windows 9x, and vendor support for all Windows 9x systems (including security fixes) ended on 06/30/2006. Because of this, any system running Windows 9x really should be upgraded (or migrated to another OS, such as Linux), and as a security professional I cannot justify officially supporting an end-of-life'd OS.

2. With that said, I do understand that some people simple cannot upgrade or migrate to a newer OS, and I have no intention of simply ignoring them. I'll look into this issue when I have the time, and will try to fix the problem if possible. I'll post back once I've had a chance to investigate this further.

Galactical, on Sep 16 2006, 04:03 AM, said:

The error log location is 'hard coded' to the root of C:\, but different users will have different preferences and disk layouts. Could you include a means for us to change that location, perhaps to any/all of: the Universal Extractor installation directory; or the starting location for the extraction; or the target location for the extraction; or just anywhere the user prefers?

Actually, it's not harcoded to C:, it's hardcoded to the root of your %SYSTEMDRIVE%. This will ensure that the file always gets written, even if Windows is installed on your G: drive. I chose %SYSTEMDRIVE% because out of all of the other possible locations (installation directory, temp directory, etc.) it's the quickest and easiest to get to if you need to view that file. The only other place I can think of that would be even easier would be your desktop, but I hate desktop clutter, so that's not going to happen.

Now, I do intend on reworking this in some way during the next major upgrade. I'm not sure what I want to do with it just yet, but making the location user-selectable seems reasonable. I'll keep it in mind.

the_guy, on Sep 16 2006, 08:29 AM, said:

I have no idea why, but the issue on 98SE is also on ME.

Yeah, I'd expect as much. I'm sure most of the people on this message board already knows this, but there are substantial difference between 9x-based systems (95, 98, and ME) and NT-based systems (NT, 2000, XP). Most likely either UniExtract or one of its components is calling some function that's only available on NT, so the same error message would appaer regardless of 98 or ME.

Drugwash, on Sep 16 2006, 11:28 AM, said:

That's bad news. Maybe actually building the main exe on a 9x system could fix things. No idea if AutoIt does work on 9x and currently I have no free HDD space to install and test. Could you test it, nitro322, maybe in a virtual machine or something?

AutoIt does work under Windows 9x, but simply compiling it under 9x wouldn't make a difference. As I mentioned previously, there's probably some function call that requires NT, and I'll have to troubleshoot when I get some time.

justwanna, on Sep 16 2006, 03:38 PM, said:

Universal Extractor fails to extract the installer exe of the new version of yEnc32 (v1.0.7).

I can't get it to work, either. NSIS support is not at all complete; this looks like one of the unsupported types.

Hanschke, on Sep 17 2006, 10:07 AM, said:

here i got an error message:

Based on the description (CAB SFX), this file looks like it should be supported, but I can't say for sure without testing the actual file. Can you provide a download link?

This post has been edited by nitro322: 17 September 2006 - 09:16 PM

[nitro322]

maska, on Sep 17 2006, 03:00 AM, said:

I'm having problems extracting latest GOM Player setup; I think this wasn't a problem with version 1.2.1. The program hangs at Extracting files from: 7-Zip Installer package. If I cancel the operation not all files are extracted.

Unfortunately, this is something of a known problem. The reason why is a bit lengthy, though.

UniExtract needs to do two things with program output - display it, so you know the current status and if there are any problems, and log it, so you can refer to it if there ARE problems. I use a program called tee to do this. I pipe all command output to tee, which essentially splits the data into two streams - one gets echoed to the screen, the other gets saved in the log file.

The problem is that cmd.exe apparently buffers its output. So, if I pass a short stream through tee, it won't be displayed until after execution completes. Alternatively, if I pass a long stream through tee, it won't display any text until the buffer has been exceeded.

So, how does all of this relate to the above problem? What's happening is 7-Zip is pausing for confirmation on something, and waiting for your input. However, because the output is buffered and hasn't been echoed to the console yet, you don't know that it's prompting you, or what it's asking.

I came across this issue while working on 1.3, and put in some workarounds to try to prevent it from occuring, but it's admittedly a hack and not a proper solution. There's bound to be some files out there that will trigger this situation, as you've found out. I have this on my todo list for the next major upgrade, just not sure how to handle it at this point.

In the meantime, I can offer a workaround. These apparent freezes usually occur because 7-Zip is asking for confirmation to replace a file. Some installers store multiple files that get output to the same location (eg, a 32-bit and 64-bit version of the same .exe). Only one gets "installed" during normal operation, but when extracting files from the installer like this the duplicates can overwrite each other. So, to workaround the issue, wait until it looks like 7-Zip is frozen (no new files are being written), then type 'a' into the console and hit enter (no quotes). That should tell it to overwrite any existing files, which should then make it continue extraction.

Warning - This workaround is NOT recommend if extracting to a directory that already contains files. You may accidently overwrite something else. I'd only recommend doing this if you're extracting files to a newly created subdirectory.

[maska]

Thanks for your detailed explanations, typing a in the console resolved the problem.

Btw, same problem occurs with Quintessential Media Player setup but that is resolved too.