jaclaz Posted September 18, 2019 Posted September 18, 2019 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
bphlpt Posted September 18, 2019 Posted September 18, 2019 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
jaclaz Posted September 18, 2019 Posted September 18, 2019 (edited) 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, 2019 by jaclaz 1
laddanator Posted September 18, 2019 Posted September 18, 2019 (edited) 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, 2019 by laddanator
jaclaz Posted September 18, 2019 Posted September 18, 2019 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
yaschir Posted September 18, 2019 Posted September 18, 2019 @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
JFX Posted September 19, 2019 Author Posted September 19, 2019 @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.
Sergei Strelec Posted September 19, 2019 Posted September 19, 2019 (edited) 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, 2019 by Sergei Strelec
yaschir Posted September 19, 2019 Posted September 19, 2019 (edited) 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, 2019 by yaschir
Atari800XL Posted September 19, 2019 Posted September 19, 2019 (edited) 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, 2019 by Atari800XL 1
JFX Posted September 19, 2019 Author Posted September 19, 2019 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
Atari800XL Posted September 19, 2019 Posted September 19, 2019 (edited) 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, 2019 by Atari800XL
wimb Posted September 20, 2019 Posted September 20, 2019 (edited) 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, 2019 by wimb
JFX Posted September 20, 2019 Author Posted September 20, 2019 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. 1
alacran Posted September 20, 2019 Posted September 20, 2019 @JFX Attached new version of Spanish Translation with some improvements. alacran 2058.7z 1
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now