20 replies to this topic

[allanf]

.

[Wonko the Sane]

Not particularly interesting ... ... But, if anyone feels like testing on different OSes, post back the results!

Am I allowed to ask something?

Some time ago pscEX (peter) made a little tool to manage the WIM filter (useful on non Windows 7 systems).
Here:
http://nativeex.boot...x/WimCaptEx.htm
http://reboot.pro/9765/

It may help to understand if the speed is "connected" to DISM or to the actual WIMFLTR/whatever "underlying" service:
http://reboot.pro/11276/


Wonko

[steve6375]

Only anecdotal, but I found that the more Windows Explorer windows you have open, the slower DISM/ImageX was at dismounting. Closing all Explorer Windows made quite a difference. Maybe you could prove/disprove this?

[ChrisR]

thank you for the batch and result ,
I had previously done similar tests with also the WimUtil tools and with or without antivirus.
My result: 1.Imagex, 1b.WimUtil (similar result), 3.Dism (whatever the WAIK version used.)
I have not tested with or without Explorer Windows.


Caution, we can't use wimfltr (and imagex, wimgapi of waik < 2.0) anymore with Win7 SP1 wim files .
M$ seems to have changed a bit the WIM format,
So if you mount these wim files with wimfltr you will have some files that are hard linked to a wrong file
By cons, wimfltr can be used without problem with Win7 SP0 and with mount/unmount much faster .


The latest version of the redistribuable http://theoven.org/index.php?topic=101.msg1236#msg1236 written by Homes32 gives almost the same result as ImageX, according to wimgapi and wimfltr or wimmount drivers used.
WimUtil uses the same drivers as imageX (wimfltr or wimmount), and it seems that speed or slow depends on these drivers.

[sbaeder]

The latest version of the redistribuable http://theoven.org/index.php?topic=101.msg1236#msg1236 written by Homes32 gives almost the same result as ImageX, according to wimgapi and wimfltr or wimmount drivers used.
WimUtil uses the same drivers as imageX (wimfltr or wimmount), and it seems that speed or slow depends on these drivers.

which makes a lot of sense, since they are the routines doing all the work...And some of the discussion on speed is (as Chris stated) a bit moot, since as things move forward, M$ is free to change (and has changed) the formats so that only specific version work with the latest WIM files.

[steve6375]

FYI: One bug I reported to MS ages ago was the problem of total corruption when you deleted 2 images from a wim file in succession (one after the other).

Create a wim file with 3 images (or more), delete 2 images from it in succession, now try to add or use the remaining wim file image - quite often the whole wim file is totally corrupt! I don't know if this is fixed yet, but at the time we made the decision not to use multiple image wim files because image deletion was too buggy.

[Wonko the Sane]

VERY good .

Can we conclude that WimCaptEx is almost as fast as Imagex and that the actual feature peter could look into to make it "perfect" is "MOUNTRW"?

However, even "as is" it is simply a class by itself when compared with Wimutil and Dism.


Wonko

Attached Files

•  performance_wim.jpg   53.3KB   14 downloads

[ChrisR]

Good and nice batch

To be more precise, it would be nice to know the driver used with each tool or do a test with Waik 1.1 (wimfltr) and a second with WAIK 2.0 (wimmount).
The driver seems to be the origin of performance.

[Wonko the Sane]

In my dinosaur's view, anything that is smaller and does ONLY the needed things (and nothing else) will always be faster.
OT, but not much:
http://www.msfn.org/...ize-of-bootsdi/

Any chance that some of the good guys like Sha0 or karyonix (or some other programmer) with experience in driver development can have a look at (say) 7-zip source code and/or to the completely UNLIKE finished thing by #booty1:
http://reboot.pro/5308/
http://wimtool.svn.s...rogram/WimTool/
http://wimtool.svn.s.../Documentation/




Wonko

[pscEx]

Dism and Imagex have primitive-looking progress indicators that run in the CMD window. WimCaptEx has nothing - not a dot! Is that why it is quicker?

Are the cmd windows NOTHING?
 WimCaptEx_mount.gif   8.13KB   17 downloads
Your way to say just anything, so that the reader accepts the same as truth, is something not mature enough.
BTW: For me, it vmakes no sence to explain here, why it is quicker. IMHO you'll never understand ...


Peter

Attached Files

•  WimCaptEx_store.gif   8.2KB   15 downloads

[ChrisR]

I haven't forgotten the caution about using WimFltr on Win7 SP1. I can't think of any way to test it, other than to try and reproduce how you found the hard-linking faults. How does it occur? ... When copying files from a mounted image? Which files? What happens?

A little hard to see the errors between Win7 SP1 and wimfltr driver.
When we mount an image everything seems OK.
When building a PE project everything seems OK too.

Wimfltr with Sp1 produced some broken links, with /mount, but not always the same.
I tried several times to build with this driver (Much Muuuuch faster), same for JFX and others.
And each time on some options, there are some incorrect links, unfortunately .

 wimfltr_error.jpg   198.88KB   6 downloads

I hope in the future, good programmers will write a new wim filter drivers independent of M$ and faster than wimmount.

For now with SP1, personally, I prefer to use 7-zip to extract the wim files and then use those extracted wim folders for the building
A little long first extraction, and then only bonus.

[Wonko the Sane]

BTW: For me, it vmakes no sence to explain here, why it is quicker. IMHO you'll never understand ...

Maybe someone else may understand...

Come on , peter, let's see if we can better things instead of losing time in small quarrels...

Is the MOUNTRW time only dependent on the actual driver used?
Or can it be bettered in the actual WimCaptEx code?


Wonko

[paraglider]

7 zip does not extract the hard links - it replaces them with the files being linked to.

[pscEx]

Is the MOUNTRW time only dependent on the actual driver used?
Or can it be bettered in the actual WimCaptEx code?

The original WimCaptEx is written with read-only mounting. There was no practical reason to allow write access.

I see something unlogical to offer a "commit" for unmount in this case. I'll change to have also something like /MOUNTRW.

I only use functions of wimgapi.dll. I have no knowledge whether wimgapi.dll uses some drivers.

Peter

[pecd.net]

7 zip does not extract the hard links - it replaces them with the files being linked to.

ok, but that has never beed a problem for me so far...build with 7zip extraced wims für over a year...

[homes32]

I only use functions of wimgapi.dll. I have no knowledge whether wimgapi.dll uses some drivers.

wimgapi.dll uses wimfltr.sys/wimmount.sys (depending on version) for mounting & unmounting only.

[paraglider]

I think all it shows is that you either use the vista wimgapi version and its fast or you use the slower win7 wimgapi. If you use the win7 wimgapi it does not really matter which program you use. They all come out approximately the same.

[homes32]

Unfortunately WimUtil using the WimFltr jammed up on the Apply test and had to be terminated. (It failed each time on the same file - a SxS file ...wsapi...?)

did you try with the /hide switch or without?
the with wimgapi 6.1.x the apply command is multi-threaded and autoit has serious issues with multi-threaded callbacks for the GUI progress. ;( I haven't had issues using the /hide switch though, because the callback is not registered.

I think all it shows is that you either use the vista wimgapi version and its fast or you use the slower win7 wimgapi. If you use the win7 wimgapi it does not really matter which program you use. They all come out approximately the same.

only logical since ALL of them use the same driver for mount/unmount.

[paraglider]

If you want to see how 7-zip messes up look at the 'Documents and Settings' in the root. It should be a link. 7-zip expands it.Same in the Users folder - All Users and Default User should be links. Same with Users\Administrator. There are several links in the folder. They all get expanded.

Of course it may not make any difference as winbuilder cannot copy links anyway. It expands them in the same way. xxcopy is one of the few programs that can copy hardlinks.

[Wonko the Sane]

Of course it may not make any difference as winbuilder cannot copy links anyway. It expands them in the same way. xxcopy is one of the few programs that can copy hardlinks.

Well, there are more (if needed), but most of the ones on 7 should be junctions/symbolic links .

AFAIK it's a new kind of "soft links" introduced with Vista :
http://en.wikipedia....S_reparse_point

Some (hard links related):
http://schinagl.priv.at/nt/ln/ln.html
http://schinagl.priv...nkshellext.html
http://www.softpedia...TFS-Links.shtml

These are very useful to see junctions/symbolic links:
http://www.nirsoft.n...links_view.html
http://technet.micro...s/bb896768.aspx

More (oldish):
http://elsdoerfer.name/ntfslink
http://www.gdps.dk/p.../freeware.shtml

This is a nice Auto-it thingy that uses mklink:
http://www.autohotke...topic30402.html

Just for the record, there is this nice thingy here in the works:
http://reboot.pro/11340/


Wonko

[dog]

Another autoit junction backup / restore option is junctionbox:
http://www.iwr.cc/junctionbox
although it failed to restore a 2k8 "All Users" as dir /al reported <SYMLINKD> rather than <JUNCTION>