[Apply regtweaks (also HKCU) and install apps for ALL users]

By manual I just mean doing everything directly via dism and whatnot, as opposed to using something like rt7lite to automate it. Ie: mount the wim file, manually unpack, patch, and apply the service pack, manually apply other packages, etc. It's been kind of a pain in the rear to get everything setup, but I have a pretty good process worked out now that I've automated with an autoit script. I'll be happy to share the autoit script if you're interested, but it really wasn't developed with redistribution in mind, so it's rather specific in how it does things.

[Apply regtweaks (also HKCU) and install apps for ALL users]

Huh. I just did yet another complete rebuild, and now the sysprep and everything works, even with IE9 slipstreamed. Not that I'm complaining, but man, weird. Now to figure out why Windows Update is prompting me to install IE9 again even though it's already installed via slipstream...

[Apply regtweaks (also HKCU) and install apps for ALL users]

In that case, why not simply use your "manual build process" (please enlighten me, I don't have a clue) and install IE9 unattendedly using Setupcomplete.cmd (wich will run right after useraccount creation but before first login)?

Because I'd rather slipstream it and not waste the extra time to install it after the OS is installed. That's kind of the whole point to all of this. For stuff I can't slipstream I do exactly that, but if it can be slipstreamed, then that's the goal.

[Apply regtweaks (also HKCU) and install apps for ALL users]

I have this sysprep problem as well. The process described by SmokingRope seems sound, but something about the sysprep step is rather fragile. I initially started looking into this because I had the same issue with preinstalled apps/configuration settings not being applied to the default user. I was using rt7lite originally as well, and couldn't get the sysprep step to take; it'd just fail in the same way as described above. I then tried switching to a manual build process, and that worked! ... until I tried slipstreaming IE9. Then it failed again. I've since rebuilt my image without IE9, and it still fails, no matter what I do.

This really rather sucks. It shouldn't be so difficult to apply default user settings. This is my last major stumbling block, so I'd be really interested to hear any workarounds or alternative solutions. I've been hammering away at this myself on-and-off for about three weeks now, but I've not had any (reliable) success.

[UniExtract 1.6.1 in development - info requested]

This line will not go mad completely in a window:

PREFS_LABEL2 = "Ýòè îïöèè ìîãóò áûòü èçìåíåíû ïîñëå èíñòàëëÿöèè ïóò¸ì ïðàâêè ôàéëà UniExtract.ini."

File name (UniExtract.ini) is cut off.

Cool, thanks. That's what I was thinking based on the screenshot, but I wanted to verify I wasn't missing anything else.

[Universal Extractor Feature Requests]

The Microsoft setup detection seems to work now. Even works with Windows Mobile Rom updates like WinRAR did (even though it initially recognizes the setups as being Install Shield... if you select it isn't Install Shield it'll detect the correct type and extract).

InstallShield issue comes from TrID - it has an extremely high false-positive rate, and I haven't been able to find a good programmatic way to deal with it.

(I already posted this in bug reports, but I'm not sure where this should go, so I'm posting it here as well)

Thanks. This is actually the better thread for this kind of request, but I saw it in the bug reports thread first so I commented there.

[Universal Extractor 1.6 Bug Reports]

U.E. 1.6.1 can extract files from .imz and .ima image files, but can't extract files from winimage sfx archives (upx compressed).

I've uploaded an example:

Support is there, but it's not detecting the file properly. It's trying to unpack it as a FEAD file, same as the other commenter posted about the Firefox installer. This is another consequence of shuffling around 7-Zip.

I think I caught a bug in UniExtract 1.6.1.

When extracting Firefox 3.6.3 Installer, it used to extract correctly as a 7-zip package in 1.6

But in 1.6.1, it extracts as a FEAD package, which is incorrect.

Confirmed - thanks for the report.

AspackDie could be replaced or complemented with Anti-ASPack - http://www.woodmann.com/crackz/Unpackers/Antiasp.zip

BareBones OOZ could be replaced or complemented with UnZoo - http://archives.math.utk.edu/software/multi-platform/gap/util/unzoo.exe

This is a freely redistributable unpacker for PECompact: http://ap0x.jezgra.net/RL!dePeCompact 2.x.rar

I'm always up for checking out newer/better alternatives. Thanks for the links.

UnUHARC should be removed, as you have stated that a legitimate source cannot be found.

I can't find a legit download source now, but the binaries themselves, best I can tell, are freely redistributable. As a result, there shouldn't be a problem keeping them included.

Your program cannot extract installers created with JGSoft DeployMaster (http://www.deploymaster.com)

When I extract one, it just creates a file called [~0].

That's 7-Zip's new generic .exe resource extraction at work. It doesn't seem to work all that well, though, and it's definitely causing me other problems with file type detection and extraction order, as discussed previously. You might be able to extract files from the 0 file by renaming it to include a few different extensions (0.exe, 0.cab, etc.) and running UniExtract on i. I have seen that work once before, but mostly not.

Thanks for the installer examples. I'll add them to the list to check out.

[UniExtract 1.6.1 in development - info requested]

The bug remained:

<SNIP>

After little change:

splashtexton($title, t('TERM_TESTING') & ' InstallExplorer ' & t('TERM_INSTALLER'), 350, 50, -1, $height, 16)

Noted.

1 the file name was not located

2,4 it is not translated

3 it is too low checkbox

Can you clarify point 1? You say the file name is not located, but I don't know what file you're referring to. From the image it looks like the text is too wide for the screen, which would be more difficult to fix in Inno Setup than UniExtract itself.

2,4 - noted

3 - this is a known problem. Unfortunately, there's no easy fix (best I can tell) as it'll require completely rewriting that custom Inno Setup options page. I'm going to try to get that fixed for the next release.

Is not extract:

adblockpro.exe, ccsetup227.exe, install_flash_player_ax.exe, IEPro2.4.9.exe

adblockpro.exe seems to work for me, but it suffers from the problem described here, where Install Explorer isn't being used instead of 7-zip to extract it.

others - same problem, but Install Explorer is failing, and it's not falling back to 7-zip like it should. Definitely needs to be fixed.

[Universal Extractor Feature Requests]

WinZIP sfx example: http://download.winz...om/wzipse40.exe

Tried already with winrar, 7-zip and Universal Extractor 1.6.1.

This is two bugs in one:

1. It [em]should[/em] work in 1.6.1. To be honest, I'm not sure why it's failing. It should attempt to extract with unzip first (which it's doing), then, if it fails, attempt to extract with 7-zip (which it's not). I don't know why that's failing at the moment; the condition logic looks correct.

2. I (thought I) modified that same condition logic to try 7-zip if unzip's exit code was anything other than a 0 or 1. I even added this change to the changelog. However, I must have inadvertently undid that change at some point and didn't catch it, as the release version is only looking for an exit code of 0. Don't know what happened there, but I'll need to fix it. This is a more general problem, though - unzip reports and exit code of 9 for the winzip file you posted, which should trigger 7-zip regardless.

Thanks for the report. Adding these issues to my todo file.

[Universal Extractor 1.6 Bug Reports]

Extracting nsis-2.46-setup.exe by UniExtract 1.6.1 legroom (New) the extraction fail

It works for me. I did notice a potential problem, though. As mentioned in the changelog, I now have 7-zip try extracting files last, as recent versions can incorrectly unpack some .exe files that other utilities correctly unpack. A side-effect is that Install Explorer is used to extract NSIS files by default now rather than 7-zip. InstExpl can better support NSIS 1.x files, but 7-zip, from what I've seen, better supports newer NSIS 2.x files. I'll need to shuffle some things around again to make 7-zip default for NSIS without affecting other file types. Will add to my todo file.

The registry of legroom UniExtract 1.6.1 is also very bulky.Two extra i.e; EXTRACT_FILES,EXTRACT_HERE command are occasionally needed may be removed.

I don't know what you mean by this. Can you please clarify?

[UniExtract 1.6.1 in development - info requested]

With Latest Stable Version - 1.6.1 these problems are not present.

Awesome, thanks for the update.

[UniExtract 1.6.1 in development - info requested]

1.6.1 is done. Download links and final changelog for the release version is available in the announcement thread. Thanks to everyone that provided feedback.

After a window 2 I see in a folder %TMP% 2 files of the identical size:

<SNIP>

In version 1.6 of such problems is not present, log file opens normally.

gora, I'm afraid I still can't replicate this, or even offer an explanation as to why it happens. You should never see that second _temp log; it only gets written very briefly in the event of a failed extraction, then gets moved back to the main debug file. This should happen pretty much instantly, and it happens before the Extraction Failed prompt is even displayed. That it doesn't happen with 1.6 is even weirder, because I didn't change anything at all in that part of the script.

Maybe I'm having trouble replicating your problem because I changed something between beta2 and the final version. I did make a few more tweaks, but nothing in particular that I can think of that might cause this. Go ahead and try the final version and let me know if you see any difference at all. If you do still have the problem, please provide the contents of your UniExtract.ini file (so I can try to match your environment as much as possible) and let me know what specific file you're trying to extract (direct download link would be a big help).

Everyone else - are you experiencing the same behavior gora reported? Please let me know.

[UniExtract 1.6.1 in development - info requested]

The text in last screenshot: "Specified the file does not exist. To open as a new file?"

Weird. I tried downloading adblockpro.exe, but I can't replicate the problem. Repeated extractions exit successfully. Regardless, though, there will be cases where this fails; as I mentioned in the changelog, detection isn't perfect due to a number of factors.

As for the "file does not exist" problem, I can't think of what may cause that. The file should always be there. Even for formats that I can't log (including 7-Zip now) it should at least contain a line stating something like "Extraction of 7-Zip archives cannot be logged." Can you do me a favor? Repeat the test that failed, then manually check to see if the debug file exists. Maybe it's an issue with the path (are you using an environmental variable in the debug location?), or maybe your editor isn't liking the way it's being called.

Edit: The debug file is launched with a ShellExecute command, which should open it in whatever edit Windows opens .txt files in by default. If the debug file does exist, try pasting the full path of it into the run box (just the file path, no editor command) and verify that Windows opens it properly in your editor.

Extraction with acknowledgement became less convenient, many additional operations:

I agree that this can be less convenient, but it's safer and more accurate. This is actually how I intended extractions with 7-Zip to function all along, the previous behavior was implemented because of this bug in 7-Zip. Since I couldn't log, I told 7-zip to force skipping existing files. After giving that decision a lot of additional thought, plus with the need to better handle overwrite detection, for the release I decided that it's more important to have full feedback and overwrite prompts for 7-Zip than debug logging. Once Igor fixes the issue in 7-Zip I'm going to add logging again, but the user prompt behavior will stay.

It's a feature, not a bug, although it may annoy some people.

Until I get a better system in place of handling i/o, the separate cmd Windows are the best option available. The primary goal for v2.0, whenever that may happen, is a revamped UI that integrates cmd output and prompts into the main UniExtract window. At that point the inconvenience factor will drop significantly, but until then the cmd windows are here to stay.

[UniExtract 1.6.1 in development - info requested]

The Russian text more long also is not located in single line (two lines turn out) and the second line is visible not completely on a vertical.

Òåñòèðîâàíèå InstallExplorer
èíñòàëëÿòîðà

What means "merge module"? An example?

Alright, I'll look into this.

Merge modules (in this context) are Windows Installer components. Details: http://msdn.microsoft.com/en-us/library/aa369820%28VS.85%29.aspx

[UniExtract 1.6.1 in development - info requested]

At unpacking NSIS installer (7z910.exe), flashes the window in which text too is not located, but it is impossible to make a screenshot. Look at it, please.

If you're referring to the splash text windows (eg., "Extracting files from: NullSoft Installer installer"), I actually increased the width of these last night. I don't remember if it was before or after I released the beta, though. Give it a shot with beta2 and let me know how it looks. It seems ok to me.

[UniExtract 1.6.1 in development - info requested]

OK, just for the record, this has not been a quick and easy update. But, I think it'll be worthwhile at least, and I hope all of you agree.

I found a few more concerns while working on the code earlier tonight, and so I decided to do my full regression testing after all. Good thing I did - I found quite a few problems, mostly in edge cases, but still... I want this to be as stable as possible. I fixed all of the problems I found and added a few more enhancements here and there as I thought of them.

I'm also pleased to say that I was able to work in the "better success criteria" previously discussed. It's not perfect, but it's a big step forward. The way I ended up doing it was actually pretty simple once it came to me - if extracting to an existing directory, check the timestamp before and after extraction and then compare it. If they match, the extraction (probably) failed. It's not exact, though - it'll catch most files if they are overwritten, but not if the user decides to skip the files. It'll also fail if all files are extracted into subdirectories (since the parent directory is never modified), and, for whatever reason, some utilities just don't seem to update the directory modification time, even though files in that directory seem to be getting overwritten. Anyway, like I said, it's not perfect, but it's an improvement. Suggestions for future improvement are welcome.

I still have some concerns about the new 7-Zip .exe resource extraction. I ended up reordering 7-zip extraction; it's now pushed back until the end of the External PEiD scan (which itself comes after the Deep and Hardcore scans). This should hopefully give other, more appropriate utilities the chance to operate first before 7-Zip rips it up.

With all these changes, I'm posting one more beta. If at all possible, please download it, throw as many test files at it as you can, and let me know how it works (good or bad). Pending any negative feedback, the only thing I have left to do is include some translation updates (gora - I can include your Russion translation if you send it my way), which I'll take care of tomorrow night, then package and upload the final release.

Here's the new beta link:

http://www.legroom.net/public/uniextract161beta2_noinst.rar

And the list of final changes (might be some dupes):

  Changed 7-Zip unpacking behavior;
          now attempts brute force extraction only after External PEiD scan;
          change due to aggressive .exe resource extraction in new versions
  Changed following formats to call 7z by name (also see 7-Zip debug comment):
          bz2, chm, gz, tar, Z
  Fixed InstallShield 5.x regression from 1.6 preventing successful extraction
  Fixed bug in extraction of non-TAR LZW compressed files
  Removed Windows NT 4.0 support from installer
  Removed debug output for 7-Zip, arj, hlp;
          buffers output, preventing proper user feedback and input prompts
  Updated success/fail detection to check output directory timestamp;
          can detect cases where files are overwritten, which old method missed;
          will still consider failed if user chooses not to overwrite files,
          or if all files are written to a subdirectory of the output directory
  Updated RPM and DEB support to extract interim CPIO and TAR files
  Updated FEAD support to workaround read-only permission issue
  Updated some UniExtract window sizes for better internationalization support
  Updated AutoIt to 3.3.6.1 and replaced deprecated _ArrayCreate UDF
  Updated MSI WCX to 1.2.1

Thanks for the feedback everyone. Please stick with me one more day so we can get this wrapped up.

[UniExtract 1.6.1 in development - info requested]

Yes, the horizontal, but also on a vertical too is not enough place. The text should be compressed to the detriment of grammar.

OK, gotcha. I added another 10 pixels in between, added some padding to the English to test a fifth line, and it looks good now. Thanks for the feedback.

[UniExtract 1.6.1 in development - info requested]

On the second screenshot I have selected red, that was not located in "standard" window UE.

Oh, are you talking about the horizontal space to the left of the OK and Cancel buttons? If you want me to increase that for translated text, yes, I can do that. I thought you were referring to the vertical space where I removed the MSXML link.

Edit: How's this?

[UniExtract 1.6.1 in development - info requested]

Some lines while translating are not located in the place taken away by it in windows:

<SNIP>

Whether it is possible to increase a few a window?

Sorry, gora, I don't quite follow you. I did remove that line on purpose, because msi2xml is the only thing that depended on MSXML and I've removed msi2xml. I also removed the extra padding I included in that GUI so that it'd match the other MethodSelect GUIs (this is the only one that had the extra download line). I'm not sure what you mean about whether it's possible to "increase a few a window".

Investigation has shown that AspackDie.exe was is taken from this assemblage

Thanks, I'll check it out.

[UniExtract 1.6.1 in development - info requested]

Apearances can mislead.... So it's more tenuous, but I bet it's really is an update, too.

I don't disagree with you, but I prefer to stick with official versions where possible. And yes, I know "official" itself is a somewhat tenuous description of some of the utilities included in UniExtract (aspackdie included), but still... if I can't track back the package to a somewhat official source (or in this case any source), and there's no clear advantage to using the "newer" versions, then I'd rather stick with what I have and know works. Feel free to call me paranoid.

[UniExtract 1.6.1 in development - info requested]

Unfortunately, I cannot specify the reference to all these components, they have been found by me and other users UE in a network.

Download msi.wcx under the reference specified by you and look at a file pluginst.inf. There version 1.2.1 is specified. Probably silent updating.

OK. thanks for the info. I'll dig around a bit and see if I can find the sources myself. Would be helpful going forward as well.

After some additional research:

aspackdie - appears to be 1.41, which is the same version I have included in UniExtract

stuffit expander - can't find any indication that this allows free redistribution; witholding for now

msi.wcx - updated, good catch

unlzx - appears to be 2.12, whereas I have 2.16 already included in UniExtract

[UniExtract 1.6.1 in development - info requested]

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'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.

I have good news and bad news here. The good news is that I think I found a good way to do this. The bad news is that I can't implement it do to a long standing bug in the interaction between 7z.exe and tee.exe that I've never been able to work around. I'll give it one more crack tomorrow night to see if I can get 7z to play nicely with tee. If so, I think this should work. If not, well, this'll have to wait. I'll provide some details, though, if anyone else wants to take a crack at it.

[UniExtract 1.6.1 in development - info requested]

Unfortunately, I cannot specify the reference to all these components, they have been found by me and other users UE in a network.

Download msi.wcx under the reference specified by you and look at a file pluginst.inf. There version 1.2.1 is specified. Probably silent updating.

OK. thanks for the info. I'll dig around a bit and see if I can find the sources myself. Would be helpful going forward as well.

[UniExtract 1.6.1 in development - info requested]

Some updated files for UE here.

Thanks. Have a few questions, though:

aspackdie - what version, and where did you download it? Latest version I could find is 1.41, which is already included, and official site seems dead

stuffit expander - can you please provide source? As far as I'm aware, 6.x was the last freely-redistributable version. If I can update to 7.x, that'd be great, but I need to verify the license.

msi.wcx - again, can you please provide the source? According to http://www.totalcmd.net/plugring/msi.html, 1.2 is the latest version, which I already have included.

pea zip - version 2.x didn't behave correctly (didn't implement GUI controls correctly, breaking UniExtract automation), so I had to stick with 1.6. I have not tested v3.x as support is ugly and I didn't want to spend a lot of time messing with it. Will check out for next major update.

unlzx - version and source, please? This doesn't seem to match up with what's available from the main page: http://xavprods.free.fr/lzx/

[UniExtract 1.6.1 in development - info requested]

Why file TrIDDefs.TRD has the size of less original (1158820 vs 1596626) here?

because I'm still using the old definition set from the 1.6 release, plus some new tweaks and additions. Swapping out the TrID defs file can have a major impact on file detection, and I didn't have time for this release cycle to do the thorough regression testing I normally do.