[marek722]

ok, here the result of my speed test:

expanded install: 29:50
normal install: 29:37

tested with wxp sp2 unattended, no other modifications
system:
- virtual pc on Athlon XP 2800+, 320MB RAM for virtual machine
- source on DVD+RW 4x, linear read speed ~5MB/s (starting quite slow with 3x), Toshiba DVD-Rom 1702

when copying files from source there are still some cpu-cycles unused with normal install, that means the impact of this modification on current systems is very little. If you use a slower CPU expanded install could be faster than normal install with same read speed of source. Faster reading of source would improove performance of expanded install only if cpu can't cope with the amount of data to expand while normal install ...

The conclusion is only suitable when using UDMA (or nearly no CPU cycles for source reading -> some LAN-adapters can consume lot of CPU ...). Measurement must not be correct because of usage of windows drivers for accessing source while booting setup from CD/DVD - i think this process acts differently on real install.

The example with the P200MMX laptop with 10x cd-rom earlier in this thread lacks information about IDE-mode for the cd-rom, but it seams copying is a rather slow process compared to expansion of data in that example ... and it is 'only' a 200MHz CPU ...

[Martin Zugec]

Yep, as I said this method depends probably on scenario. Because optic mechanics are slow, I think compressed method is better for them.

However for network/image (under image I mean iso in VM) could be faster... I am really looking forward when I will give it a try

[nuhi]

If I may pop in.

We have discussed this before on nlite's forum and came to a conclusion that compressing files into few big CAB's like driver.cab or sp2.cab would significantly speedup copy process from CD.

Something like that is done in Longhorn, if you take a look at it you'll see that it has almost all setup files in one big one which is expanded during first phase.

Since CPU's are faster today compression in this scale doesn't matter, so less to copy, compressed file, is better, in my opinion of course.

[Zxian]

Thanks for the input nuhi!

I was thinking along the same lines. Decompression almost always takes less time than compression, and with any computer that can handle XP, the decompression is faster than file transfer.

[riverrm]

long horn installs using a sysprep'd image for initial install and therfore skips textmode completly.

[Araknis]

nuhi Thank you very much for popping in, All and any feedback is welcome.
Not only that but I was not aware of a previous descussion on this, Thanks for the info.

nuhi, on Jul 22 2005, 01:54 PM, said:

We have discussed this before on nlite's forum

are you talking about this thread Decompress all Windows setup files, to speed up installation?

nuhi continnued... said:

and came to a conclusion that compressing files into few big CAB's like driver.cab or sp2.cab would significantly speedup copy process from CD.

I also noticed in that thread that it suggested by you and talked about between fdv, Sereby but did Sereby or anyone figure out how to do it and what were the results?

nuhi, also in your forums in this thread UPX source compression? it was suggested to use UPX on all of its supported file types then compress and cab. Again, what were the results? Did this provide any possibe gain?

nuhi, I also wanted to thank you for popping in and giving the CAB idea by sharing with you and others a program I found browsing the net.
I am not sure if you were aware of the program or even need it but Less MSIérables lets you extract files and view msi tables.

Oh, one quick thing nuhi I know you are programing in C# and that is what the above program is written in. What I think you will find most usefull about the above program is that it comes with the source code that you could possibly use in nLite.

[nuhi]

@riverrm, true, only point was that it's in one big file...that helps with continuity and cd copy speed. I may be off with that first phase but it does copy eventually.

@Araknis, that's the one.

Don't know of the results...basically I'm not doing it because than you need to edit inf's and put entry to locate files in cab...not so needed to be worth breaking signature of particular inf.

Upx works, but I don't use it myself since it slows things down after install and space is not what i'm after even though it may seem otherwise.
I'm just interested in freeing the memory from unneeded processes, thus removing components.

Msi thing read in nlite's forum and replied to.

This post has been edited by nuhi: 23 July 2005 - 02:43 PM

[galvanocentric]

Araknis, on Jul 21 2005, 05:06 AM, said:

I hope you are not wasting DVD's trying this and just creating a ISO image and trying in a Virtual Machine.
<{POST_SNAPBACK}>

DVD-RW?
I'm going to try this tonight... See if I get a success story on VMWare.

[EDIT]
Just thought about what Nuhi's been saying... Hell, maybe I shouldn't bother. I think there'd be little if any difference. I've got an excellent hard drive so transferring all the decompressed files would be a snap. However I've also got an excellent processor so decompression shouldn't take any time at all.
However if somebody with say a SATA1 Raptor and a crappy processor would like to test this...

This post has been edited by galvanocentric: 07 August 2005 - 10:48 PM

[tomasz86]

This is an old topic but I just want to say that the script posted in #1 is wrong. You can't just unpack files and remove their packed versions because there are some files that unpack to different filenames, ex. "wic.dl_" will be unpacked to "windowscodecs.dll".

To have it done correctly the unpacked version must be renamed to its original name so "windowscodecs.dll" should be renamed (not packed!) to "wic.dl_".

This is the script to do it automatically:

FOR /F %%I IN ('DIR/A-D/B/S i386\*.*_') DO (
   MD TEMP
   EXPAND -R %%I TEMP\
   MOVE TEMP\* %%I
   RD/Q/S TEMP
)