Possible Speedup Installing XP by Expanding I386 Expand all files in the I386 folder
Posted 22 July 2005 - 06:38 AM
expanded install: 29:50
normal install: 29:37
tested with wxp sp2 unattended, no other modifications
- 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 ...
Posted 22 July 2005 - 06:46 AM
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
Posted 22 July 2005 - 01:54 PM
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.
Posted 23 July 2005 - 05:25 AM
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:
nuhi continnued... said:
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.
Posted 23 July 2005 - 02:42 PM
@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
Posted 07 August 2005 - 10:33 PM
Araknis, on Jul 21 2005, 05:06 AM, said:
I'm going to try this tonight... See if I get a success story on VMWare.
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
Posted 21 June 2012 - 04:10 AM
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 )
- ← How to guides on deploying Windows XP WIM Images
- Unattended Windows 2000/XP/2003
- Windows 2000 Microcode Update Driver Patch →