Jump to content

Possible Speedup Installing XP by Expanding I386

Araknis
 Share

Recommended Posts

Araknis

Araknis

Posted
  • Author
Posted

Zxian, I know that expanding the entire contents of the I386 folder may not have been that good of an idea and doing so does take up a lot of space but I just wanted to quickly test and see if it was possible to install with all of these files expand and it worked.

The files that get expanded should be optimized to what files are actually going to get installed and what ones will actually give you a possilbe speed increase.

However, this is just like how people are using hotfixes it seems that some people expand the updated files and others compress the file like the original.

I agree that a person would need to determine if expanding files is even a good idea.

Maybe, someone who knows more about the installation process such as Bâshrat the Sneaky, nuhi, or GreenMachine would know a answer.

I myself don't even know if this is that good of an idea and that is why I posted Possible. I mostly wanted to get feedback like I have been getting.

I am not even sure if a expanded installation would cause any unexpected problems with things like microsft update being able to detect and install Hotfixes. Windows File Protection, if windows keeps any of the files compressed, etc....

These Idea really needs to be examined and tested before being used in the real world.

By the way does anyone know if Longhorn will be shipped on a DVD?

If so are all the I386 files expanded, compressed, or a Hybrid?

Again Thanks for All The Feedback.

Link to comment
Share on other sites

Araknis

Araknis

Posted
  • Author
Posted

I was looking at a txtsetup.sif guide from gosh and was wondering if we would also need to edit txtsetup.sif to reflect all of the expanded files?

http://gosh.msfnhosting.com/txtsetup.htm]autofmt.exe = 1,,,,,,_x,2,0,0,,1,2

The _x means the file is not compressed on the cd.

I wonder if we are wasting some time by having the system check for the compressed file by not editing txtsetup.sif?

I don't think we would need to make any changes to dosnet.inf would we?

Does anyone know if we need to edit any other files besides txtsetup.sif?

Link to comment
Share on other sites
Araknis

Araknis

Posted
  • Author
Posted

Martin Zugec, I am assuming that you did end up testing in VMWare. I was just wondering if you did noticed any speedup?

I was also wondering if you modified the txtsetup.sif file or even think that it needs to be modified?

I was also wondering if you noticed or tested for any unexpected side effects?

Did you get any installation errors or any error logs created?

Were you able to install hotfies and regular applications after windows was installed.

Where you able to add and remove windows components IIS for example

I have not done any other testing other than my inital test, but have learned a lot from this experience thanks to Achdine and marek722.

And that is you can get a speedup just by switching your installation source to media with the Higher Transfer Rate.

For example just by switching from a CD to a DVD for my installation source on my DVD-Burner I would get a increase

Going from a 48X CD-ROM (7200 KB/sec) to a 16X DVD-ROM (21600 KB/sec) transfer rate.

However, a DVD is not always faster you could have a 48X CD-ROM (7200 KB/sec) and a 4X DVD-ROM (5400 KB/sec)

Link to comment
Share on other sites
marek722

marek722

Posted
Posted

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 ... :blink:

Link to comment
Share on other sites
Martin Zugec

Martin Zugec

Posted
Posted

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 :)

Link to comment
Share on other sites
nuhi

nuhi

Posted
Posted

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.

Link to comment
Share on other sites
Zxian

Zxian

Posted
Posted

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.

Link to comment
Share on other sites
Araknis

Araknis

Posted
  • Author
Posted

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.

We have discussed this before on nlite's forum
are you talking about this thread Decompress all Windows setup files, to speed up installation?
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.

Link to comment
Share on other sites
nuhi

nuhi

Posted
Posted (edited)

@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.

Edited by nuhi
Link to comment
Share on other sites
  • 3 weeks later...
galvanocentric

galvanocentric

Posted
Posted (edited)
I hope you are not wasting DVD's trying this and just creating a ISO image and trying in a Virtual Machine.

DVD-RW? :blink:

I'm going to try this tonight... See if I get a success story on VMWare. :D:blushing:

[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... :whistle:

Edited by galvanocentric
Link to comment
Share on other sites
  • 6 years later...
tomasz86

tomasz86

Posted
Posted

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
)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...