8 minutes ago, laddanator said:

Not that this info really makes a huge difference to this topic but I ran a little test applying a wimlib capture image (29gigs but 12gigs compressed). I applied the image with wimgapi in 10mins25secs and 11mins27secs with wimlib on the same exact test machine I use to test my images.  

As a matter if fact whether it makes a difference (at all) is subjective, and it depends on the context.

Shaving of 1 minute out of 10 is roughly a 10% increase of speed (objectively), but if you:

1) launch the apply and go get a short walk or a cup of coffee and come back after 15 minutes it becomes totally irrelevant.

or:

2) keep staring at the screen for 11 minutes, staring at it one minute less is a huge improvement.

jaclaz

I think his point was that both JFX and wimb said that wimlib was much faster, while laddadator's test showed that wimlib was slower.  I'm sure that any test depends on the actual circumstances, but it might be better stated that wimlib is usually much faster.

Cheers and Regards

17 minutes ago, bphlpt said:

I think his point was that both JFX and wimb said that wimlib was much faster, while laddadator's test showed that wimlib was slower.  I'm sure that any test depends on the actual circumstances, but it might be better stated that wimlib is usually much faster.

Cheers and Regards

What was said by JFX and wimb was that wimlib was faster (or better or both) for capture and that wimgapi was faster (or better or both) for apply.

A single test comparing wimlib against wimgapi for apply and showing that wimlib is slower (some 10%) doesn't seemingly change anything in what was stated earlier.

jaclaz

Edited September 18, 20196 yr by jaclaz

2 hours ago, jaclaz said:

What was said by JFX and wimb was that wimlib was faster (or better or both) for capture and that wimgapi was faster (or better or both) for apply.

A single test comparing wimlib against wimgapi for apply and showing that wimlib is slower (some 10%) doesn't seemingly change anything in what was stated earlier.

jaclaz

Yes, this is my point. wimgapi is faster at apply than wimlib (Or so on my test machine). I plan to test on an older system with low ram to see if the time gap between the two will change. 

Edited September 18, 20196 yr by laddanator

Just now, laddanator said:

Yes, this is my point. wimgapi is faster at apply than wimlib (Or so on my test machine). I plan to test on an older system with low ram to see if the time gap between the two will change. 

Actually, the point is that the point isn't yours (exclusively), as it is (partially, i.e related to apply only) the same JFX and wimb had already made (and that  you confirmed through your experiment).

jaclaz

@JFX hello!
I missed a little detail.

-What is this detail?
+When we open Help with the F1 key, the problem of sub-rankings appearing in a zigzag manner is corrected in this translation.

Could you please add this new Turkish translation?
Kind Regards.

New Turkish Lng for WinNTSetup v4.0 Beta 6.zip

@yaschir
What detail you mean?
For F1 Help text, yes it uses TAB's what is really not optimal, as it depends on the size of characters used.
It a bit tricky to get it right.

 

@laddanator
You already used an old machine, if you want to see differences use a 6 or 8 core CPU pair with a quick SSD.

I spent a capture on the same computer.
Intel Core i7 8700K
Samsung SSD 960 EVO SSD drive to another.

Size busy 51GB system
wimlib:
2.46 min, file size 31.2GB
wimgapi:
3.02 min, file size 31.5GB

Compression: xpress

Edited September 19, 20196 yr by Sergei Strelec

5 hours ago, JFX said:

@yaschir
What detail you mean?

No. The problem was caused by me. I fixed it with this last translation., thank you.

Edited September 19, 20196 yr by yaschir

Just finished a test of direct apply of UUP files (build 18980 x64).

WinNTSetup 4.0b6 performs this task with no problems (using WimgAPI 18362).
(Actually, I always wonder why a lot of people bother to convert preview UUPs to an ISO, all this effort can be spared, just use direct apply, either with WinNTSetup of Imagex).

I wanted to test the manual method as well (using imagex.exe from the command line, or actually from a gui/ script thingy), and to my surprise this still produces the errors below. So for manual use, I still use version 15063.

Any idea why this would happen?

Command line: imagex /apply pro.esd /ref: g:\uup

ImageX (any version after 15063) produces errors like this:

[ ERROR ] Restoring ....filename.... again {Error = 6)
Error restoring image.
The handle is invalid.

Once again: WinNTSetup is not to blame, just wondering what's going on here...

 

Edited September 19, 20196 yr by Atari800XL

It works here with imagex.exe 18362.1, if you put all reference esd and cab files in a folder, lets call it REF
and use a command line like abbodi1406 showed here

Thanks for looking into this!!!

Yes, it normally works all the time with the older ImageX version (have used it dozens of times).

Must be some other weird thing, but it's so strange that 15063 NEVER has those issues.

Oh well, not really WinNTSetup's fault, but as you're active in other fields relating to PE/ Deployment as well, it's always best to ask the master directly.

(Abbodi1406 told me he doesn't use PE all that much, I've always wondered about that, we could use him around <g> but that's another topic again).

Edited September 19, 20196 yr by Atari800XL

The Capture [ExclusionList] section in Tools\WimScript.ini is much shorter than in WimBootCompress.ini given by Microsoft.

What is the reason not to use a lot of entries given by Microsoft ?
Certainly useful can be entries like
\Windows\Logs\*
\Windows\Prefetch\*
\Windows\Temp\* 

Edited September 20, 20196 yr by wimb

My WimScript.ini is more or less the build in list that imagex.exe has.
Microsoft is not using the WimBootCompress.ini to create the WIM they release.

Adding to many entries could slow down the process as every filter has to be checked against every single file.

@JFX

Attached new version of Spanish Translation with some improvements.

alacran

2058.7z