[nitro322]

Hey, guys. I know I've been away for a really long time now, and I apologize for that. UniExtract development and support unfortunately just hasn't been a high priority for the past couple of years, and while I don't consider that much of an excuse, it is the truth. So, I hope you can understand, if not forgive, the long absence.

The reason I'm posting tonight, however, is to let you know that I'm trying to push out an update for UniExtract. This will be a maintenance release, with two primary goals:

• Update helper binaries to support newer file format versions (7-zip, innounp, etc.)
  
• Fix any major or oft-encountered bugs

A third consideration is actually getting it to work correctly with recent versions of AutoIt, since a lot has changed there as well since I last updated UniExtract. I'm currently working on the AutoIt bits, and hope to have that plus the binary updates done this weekend. What I'm asking from you is to please provide feedback regarding bugs. I know there are many bug reports in the forum, but I have a limited amount of time available for this and I really want to use this opportunity to push out a new release. I'd greatly appreciate any assistance in filtering this information down to the key issues, such as crashes, compatibility issues, etc. Windows 7-specific bug reports also welcome.

Thanks. I'll update this post thread once I've made some more progress.

[ricktendo]

Hey nitro these guys been doing a pretty good job keeping the binaries up to date: http://www.ryanvm.ne...opic.php?t=8201

[nitro322]

ricktendo64, on 07 May 2010 - 10:35 PM, said:

Hey nitro these guys been doing a pretty good job keeping the binaries up to date: http://www.ryanvm.ne...opic.php?t=8201

Cool, thanks for the heads up. I know there are a few different unofficial updates out there, but I haven't paid much attention to them (mostly because I'd prefer to be working on my own update if I had the time :-)). I'll check it out though for ideas.

Separately, I have this note in my todo file from before my extended hiatus:

fix filepicker bug that occurs when using prefs GUI to toggle history option

I can't remember exactly what that's referring to, and I'm can't find any problem with the functionality of either the filepickers or history option. Anyone else know what this might refer to? If not, I'll just write it off as an old item that's already been addressed.

[Sp0iLedBrAt]

Looking forward to it

[gora]

Hi, nitro322.

It is glad that you have decided to continue work over UE.
If you will interest, something from this, I can give source codes.

Excuse my bad English, my native language Russian.

[nitro322]

I updated to the latest version of 7-zip, which adds support for the following archive/compressed file types:

UDF, XAR, DMG/HFS
nifs, fat, vhd, mbr
mslz
APM

Out of this list, is there anything that would be particularly useful? As I said above, I'm not looking to add much in the way of new features for this update, but I can usually whip up something pretty quickly if 7-Zip supports it, so I don't mind working on this if there's any demand. There's one catch, though - I don't have any examples of the above files, so if you want me to add support you need to provide (or point me two) at least two examples of each.

Try to let me know ASAP, please.

[nitro322]

gora, on 07 May 2010 - 11:32 PM, said:

If you will interest, something from this, I can give source codes.

Thanks for the offer. Since I'm primarily focusing on bugfixes and version updates for this release, I don't think I'm going to be adding much in the way of new features. My goal is to get a final release out before the end of the weekend - otherwise it'll probably be a while again before I get back to it. More features = more time, so I'm going to keep this as short and sweet as possible. :-)

Once I get back to working on 1.7, though, I'm sure I'll take you up on your offer. Definitely appreciate it.

[gora]

Bug in 1.6:

Quote

$peidtitle = "PEiD v0.94"

By call PEiD, UE hangs, as PEiD has version 0.95

[nitro322]

gora, on 08 May 2010 - 12:10 AM, said:

Bug in 1.6:

Quote

$peidtitle = "PEiD v0.94"

By call PEiD, UE hangs, as PEiD has version 0.95

Heh, I literally just upgraded PEiD and saw this behavior. Thanks for saving me the hassle of troubleshooting. :-)

[nitro322]

nitro322, on 07 May 2010 - 10:46 PM, said:

Separately, I have this note in my todo file from before my extended hiatus:

fix filepicker bug that occurs when using prefs GUI to toggle history option

I can't remember exactly what that's referring to, and I'm can't find any problem with the functionality of either the filepickers or history option. Anyone else know what this might refer to? If not, I'll just write it off as an old item that's already been addressed.

Found it. Was previously reported here. Still present, unfortunately. Working on it now.

[nitro322]

OK, done for the night. Here's what I've knocked out so far:

  Added support for XZ compressed files and txz/tlz archives via 7-Zip
  Added support for NBH files via NBHextract
  Added TrID detection of NBH files
  Changed LZMA support to use 7-Zip for extraction
  Fixed bug that prevented picking files after toggling history option
  Fixed bug in display of history combo boxes when no items listed
  Removed lzma helper binary
  Updated 7-Zip to 9.13 beta
  Updated AutoIt to 3.3.6.1
  Updated InfoZip unzip to 6.0.0
  Updated innounp to 0.31 (supports Inno Setup 5.3.9)
  Updated InstallExplorer to 0.9.2
  Updated PEiD to 0.95
  Updated UnRAR to 3.93

I'm browsing through the old forum posts right now for bugs and "quick fix" type stuff, but again, please let me know if there are any particularly serious bugs or compatibility issues that need to be addressed. I'll be back on tomorrow night to resume (and hopefully finish) work on 1.6.1.

[gora]

Incorrect criterion of check of extraction of a file (comparison of the size of a folder before/after extraction).

For example, the first extraction has passed successfully, but at repeated extraction of the same file will be given out the error, the size of a folder has not changed, though extraction has passed successfully.

[MagicAndre1981]

awesome news I can't wait for updated version

[dencorso]

It's great to have you back at it, nitro!
I wish to remind you of this recent post of mine, about adding MsiX, which would extend the support for .msi, .msm and .msp, and should be relatively simple to add...

dencorso, on 25 April 2010 - 08:12 PM, said:

frmariam, on 12 July 2009 - 02:31 PM, said:

Needs better MSI support. The current MSI unpacking process isn't that great...

The best MSI unpacker I know is LessMSIerables which is open source but .NET... If someone could learn from the source and implement this (or port it to C/C++ and integrate it with Universal Extractor) it would be perfect... I'm not a coder so I can't be of any more help...

No. Not LessMSIerables... But MsiX.exe would be a great addition. It is able to extract files from .msi, .msm and .msp installation files, and it is a command-line console program, so I guess it'll be easy to integrate. Do give it a try!
Find it here: Heath Stewart's Patch Files Extractor

Keep on the great work! You do rock!

[nitro322]

gora, on 08 May 2010 - 03:23 AM, said:

Incorrect criterion of check of extraction of a file (comparison of the size of a folder before/after extraction).

Well, it's not exactly incorrect, but I'd agree that it's insufficient. I've noticed this problem before, but I can't think of an obvious way to fix it. Currently, UniExtract determines success based on output directory size: it checks the size before extraction and again after extraction, and if the after size is <= the before size than failure is assumed. Ideally, I'd prefer to use one of the following methods:

• check list of files in archive and compare against output files
  
• check exit code of helper binary to determine success or failure

In some specific cases, I do use the above techniques for determining if a specific file is supported and/or successfully extracted, but there's no good way to generalize the checks. Eg., if I only had to worry about verifying 7-Zip output, then I could do it easily enough as I could write some very specific checks (plus, 7-Zip reliably sets error codes, making it even easier). Unfortunately, I need to deal with 40 different helper binaries, and not all them play nice. In fact, most of them don't.

I'll give this some though to see if I can come up with a good, general, and efficient method to do better error checking, but it may need to wait until the next feature release.

Thanks for reporting - this does need to get addressed at some point.

[nitro322]

dencorso, on 08 May 2010 - 09:47 AM, said:

I wish to remind you of this recent post of mine, about adding MsiX, which would extend the support for .msi, .msm and .msp, and should be relatively simple to add...

Thanks for the suggestion. Will look into it. If it's not too tricky (MSI support is fairly ugly within UniExtract) I'll try to get it included in this release. Otherwise, it will be targeted in the next feature release.

This post has been edited by nitro322: 08 May 2010 - 11:33 AM

[gora]

I have added the following in a script:
Before unpacking stock-taking of a folder of unpacking is made. If the folder is present, the message to the user about a possible error is deduced and the offer to remove a folder before the extraction beginning. Now the user is warned about an extraction cause of error.

[nitro322]

nitro322, on 08 May 2010 - 11:32 AM, said:

dencorso, on 08 May 2010 - 09:47 AM, said:

I wish to remind you of this recent post of mine, about adding MsiX, which would extend the support for .msi, .msm and .msp, and should be relatively simple to add...

Thanks for the suggestion. Will look into it. If it's not too tricky (MSI support is fairly ugly within UniExtract) I'll try to get it included in this release. Otherwise, it will be targeted in the next feature release.

Done, for MSI and MSP files (MSM supposedly support as well, but I have none to test). Was nice and easy; I like this utility. :-)

Here's a request of my own - can someone do some testing of this against the other MSI and MSP options and see if any of them can be dropped in favor of this? I did some pretty thorough testing of all the existing options and found that they all can be useful in certain circumstances, but if MsiX can fully replace one or more of them then I'd much prefer to trim that list.

[nitro322]

gora, on 08 May 2010 - 11:42 AM, said:

Before unpacking stock-taking of a folder of unpacking is made. If the folder is present, the message to the user about a possible error is deduced and the offer to remove a folder before the extraction beginning. Now the user is warned about an extraction cause of error.

The problem with that approach is it's possible to extract files to an existing folder filled with other files. For example, I very frequently use the 'UniExtract Here...' option to extract files, and I most definitely don't want to delete the current working directory, nor even offer the option. I also may extract files directly to C:\Windows or some other such directory, depending on what specifically I'm extracting, and obviously we wouldn't want to delete that either.

This would be useful when using the 'UniExtract to Subdir...' option, but I don't think covering that one possibility alone would be worthwhile. It could help in some circumstances, but it'd also be incomplete and provide inconsistent feedback.

On the other hand, tweaking the error message to include a statement about the folder already existing would work, but there's a catch here as well - this would require an update to the translation files, which I won't be able to do for this release. It's a very time-consuming process to get support for all of the foreign languages updated. So, this option would also need to wait until the next major release.

[dencorso]

nitro322, on 08 May 2010 - 12:25 PM, said:

Done, for MSI and MSP files (MSM supposedly support as well, but I have none to test). Was nice and easy; I like this utility. :-)

Great! Thanks a lot!