Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Post-HFSLIP Scripts: NOLOAD & SPEEDUP

- - - - -

  • Please log in to reply
23 replies to this topic

#1
Arie

Arie

    One Man Army

  • Member
  • PipPipPipPipPip
  • 835 posts
  • Joined 27-August 07
How to reduce text mode wait time

Question: Even after using programs to customize your unattended install, what is the most annoying part about setup?
Answer: Easy, text mode!

gosh revealed various ways to reduce the text mode wait time in his topic Forgotten Setup Secrets Revealed. Inspired by this topic, I wrote two scripts to be used with HFSLIP to reduce the text mode wait time and to speed up the boot process.

Attached File  textmode.jpg   20.2KB   223 downloads


Not loading unnessary setup files during boot process

Despite advances in customizing windows xp setup, one part has remained elusive: the beginning. How frustrating is it to cut in half the time it takes to install windows, yet you still have to sit at the text mode screen that says, "loading windows setup, loading Adaptec SCSI controller,etc". That has always annoyed me. I've never owned anything Adaptec, so why do i have to wait as windows setup loads a bunch of SCSI drivers for Adaptec??? Booting from CD could take a couple minutes as you wait for setup to load it's drivers (I counted 80 in all).

The post-HFSLIP NOLOAD script will stop setup from loading the following drivers to reduce the text mode wait time:
  • Fast FAT File System Driver
  • SCSI MiniPort Drivers
  • Compaq support
  • Toshiba floppy support
Expanding compressed setup files to speed up boot process

By default XP setup will expand any files it needs on the fly into memory. The problem with this is when you are installing from CD this could be a big performance hit on setup, and it'll take up more memory. One way to avoid this performance hit is by expanding the files setup needs.

The post-HFSLIP SPEEDUP script will expand these specific compressed setup files to speed up the boot process.


Download

Attached File  HFSLIP_POST_SCRIPTS_V0.2.ZIP   2.37KB   336 downloads
Attached File  hftools.jpg   38.64KB   235 downloads

Extract the downloaded archive to a temporary location and copy the post-HFSLIP script(s) you wish to use to your HFTOOLS folder.

Attached File  sed.jpg   37.46KB   148 downloads

The post-HFSLIP NOLOAD script makes use of sed, a stream editor to perform basic text transformations. Please download GNU sed v3.02.80 for Windows (3x, 9x, NT, 2K), extract the downloaded archive to a temporary location and copy the file sed.exe to your HFTOOLS folder.


Mirrors
- HFSLIP_POST_SCRIPTS_V0.2.ZIP
- GNU sed v3.02.80 for Windows (3x, 9x, NT, 2K)


Changelog
HFSLIP_POST_SCRIPTS_V0.2:
- Added processor architecture verification; currently only x86 is supported
- Removed some unnecessary code

HFSLIP_POST_SCRIPTS_V0.1:
- Initial public release; enjoy!


Credits
I would like to thank the following people (in alphabetical order):
- gosh
- Tomcat76
- tommyp
- Yzöwl

Edited by Arie, 28 February 2008 - 07:52 AM.

Not trying to pretend the enemy that I am.


How to remove advertisement from MSFN

#2
XibaD

XibaD

    Member

  • Member
  • PipPip
  • 141 posts
  • Joined 07-August 06
What happens with sed.exe if you run HFSLIP in a x64 enviroment? It gives an error... :s

#3
Arie

Arie

    One Man Army

  • Member
  • PipPipPipPipPip
  • 835 posts
  • Joined 27-August 07

What happens with sed.exe if you run HFSLIP in a x64 enviroment? It gives an error... :s

I have only tested this on an x86 edition of Windows XP Professional with Service Pack 2 and all the latest hotfixes. Perhaps there is a version of sed around which is x64 compatible, I don't know. I don't have the means to test it if I would come across an x64 compatible version, but I'll see what I can find.
Not trying to pretend the enemy that I am.

#4
wela

wela

    Member

  • Member
  • PipPip
  • 132 posts
  • Joined 25-September 05
:hello:
Works great with german xpsp2 :thumbup
THX

#5
GrofLuigi

GrofLuigi

    GroupPolicy Tattoo Artist

  • Member
  • PipPipPipPipPipPip
  • 1,360 posts
  • Joined 21-April 05
  • OS:none specified
  • Country: Country Flag
I have some questions (please forgive me if I got something wrong, I didn't study this too much):

- Why are you uncompressing the drivers that will not be loaded?
- Why fastfat (I agree with all others)? What if user wants to install on FAT partition?
- Can this be used with something else (nLite)?

GL

#6
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • Joined 16-July 04
  • OS:Windows 7 x64
  • Country: Country Flag
It's mentioned in the other thread, but I want to point out that users can avail themselves of no-load capability by using semicolons in TXTSETUP.SIF.

For example, if you want to eliminate the Compaq array driver from loading:
[Hal.Load];sgiborg_mp     = halborg.dll

Careful, you might find that one day you'll install XP on some older, spare machine and you might run into a problem. (Okay, okay, maybe not!)

As for pre-expanding your files and renaming them back to ending an underscore, that will (if you do enough large files) cause a HUGE installation speed-up, I find.

I encourage everyone to mess with their TXTSETUP files and make note of the result(s). Just be careful with your originals - make copies.

This is my favorite method for integrating (as opposed to removing) things like drivers though it can be a hassle.

Edited by fdv, 27 February 2008 - 08:09 PM.


#7
Arie

Arie

    One Man Army

  • Member
  • PipPipPipPipPip
  • 835 posts
  • Joined 27-August 07

- Why are you uncompressing the drivers that will not be loaded?

You're referring to expanding setup files using SPEEDUP which will not be loaded due to NOLOAD. Both scripts do not depend on each other, meaning that you can use either or both scripts as you please. If you would only use SPEEDUP, you will need to expand all the setup files that my script expands. Indeed, if you use SPEEDUP in combination with NOLOAD, certain files will be expanded which don't need to be expanded. The reason for this is simply so that you can use either or both scripts. A future version should perhaps check if both scripts are used and then take the appropriate actions, but for now this is fine for me as the space "wasted" by expanding these few setup files which won't be loaded anyway isn't that much.


- Why fastfat (I agree with all others)? What if user wants to install on FAT partition?

See the topic by gosh which I mentioned in my first posting. If this is a problem for you however, you can always comment out the line which refers to FASTFAT.SYS in NOLOAD. Perhaps a future version will work with an answer file.


- Can this be used with something else (nLite)?

No, not in it's current form. These scripts are specifically written to be used with HFSLIP. By using my scripts as an example though and by reading the before mentioned topic by gosh you can make your own nLite compatible script if you want.
Not trying to pretend the enemy that I am.

#8
Sherwin

Sherwin
  • Member
  • 9 posts
  • Joined 12-March 05
hi i'm a total newbie

really confusing at first but i just downloaded everything

i had to edit the HFSLIP_POST_NOLOAD_V0.2.CMD file because the source folder was spelled sourcess not sure why?

it works now i think

ok i get error when i try in virtual box to run my iso it says NTKRNLMP.EXE is corrupt or missing

#9
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • Joined 16-July 04
  • OS:Windows 7 x64
  • Country: Country Flag

ok i get error when i try in virtual box to run my iso it says NTKRNLMP.EXE is corrupt or missing


When you get this, it means that Virtual Box, or VMWare, or MS Virtual PC, was faking out the OS by using one of the drivers you got rid of. Comment fewer of them out. And IMHO you ought to be doing this in your original source file.

#10
tain

tain

    Cyber Ops

  • Super Moderator
  • 3,682 posts
  • Joined 24-September 05
  • OS:none specified
  • Country: Country Flag

Donator

i had to edit the HFSLIP_POST_NOLOAD_V0.2.CMD file because the source folder was spelled sourcess not sure why?

The SOURCES folder is your original, unmodified source. SOURCESS is the post-HFSLIP folder. I think the extra S is for Slipstreamed.

#11
johndoe74

johndoe74

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,435 posts
  • Joined 12-March 06

i had to edit the HFSLIP_POST_NOLOAD_V0.2.CMD file because the source folder was spelled sourcess not sure why?

The SOURCES folder is your original, unmodified source. SOURCESS is the post-HFSLIP folder. I think the extra S is for Slipstreamed.



a minor correction. the source (no 's' at the end) is your original, unmodified source. the sourcess (two 's' at the end) is your slipstreamed folder

Edited by johndoe74, 18 March 2008 - 08:23 AM.

Posted Image

#12
tain

tain

    Cyber Ops

  • Super Moderator
  • 3,682 posts
  • Joined 24-September 05
  • OS:none specified
  • Country: Country Flag

Donator

Good catch. Thanks!

#13
Oleg_II

Oleg_II

    Senior Member

  • Member
  • PipPipPipPip
  • 679 posts
  • Joined 06-August 04
I want to try it on VMWare (don't think it gives much speed on virtual machine but anyway :rolleyes:

As for pre-expanding your files and renaming them back to ending an underscore, that will (if you do enough large files) cause a HUGE installation speed-up, I find.

Just to confirm - you mean if for example I expand one file say 'FILE.EX_' to 'FILE.EXT' and then rename the last letter to '_' (the file will look like 'FILE.EX_' again)?
Posted Image

#14
Arie

Arie

    One Man Army

  • Member
  • PipPipPipPipPip
  • 835 posts
  • Joined 27-August 07

I want to try it on VMWare (don't think it gives much speed on virtual machine but anyway :rolleyes:

As for pre-expanding your files and renaming them back to ending an underscore, that will (if you do enough large files) cause a HUGE installation speed-up, I find.

Just to confirm - you mean if for example I expand one file say 'FILE.EX_' to 'FILE.EXT' and then rename the last letter to '_' (the file will look like 'FILE.EX_' again)?

There is no need to rename the file after expanding it.
Not trying to pretend the enemy that I am.

#15
caps_buster

caps_buster

    Member

  • Member
  • PipPip
  • 117 posts
  • Joined 20-February 09
I'm sure this looks like a great idea. However I prefer do things "by hand" as I like FAT32 system for OS partition for speed reasons, so... So I tried to take a look how a script file can be used, but ended up in total dismay. First, this middle line looks messed up pretty bad:
REM ECHO>>HFNOLOAD.SED s/syspro_mp	  = hal.dll/syspro_mp	  = hal.dll,,noload/g
REM ECHO>>HFNOLOAD.SED s/mps_up		 = halapic.dll,,noload ,2,hal.dll/mps_up		 = halapic.dll ,2,hal.dll/g
REM DO NOT LOAD SCSI MINIPORT DRIVERS

Second - the major annoyance is the SED tool itself. It suxx beyond words to describe. I was hoped for something like...
SED --in-place -f noload.sed txtsetup.sif
or
SED -i -f noload.sed txtsetup.sif
...witch, according to the docs should perform the noload.sed script upon the unsuspecting and naked txtsetup.sif file. But it does not work at all.

`-i[SUFFIX]'
`--in-place[=SUFFIX]'
This option specifies that files are to be edited in-place. GNU
`sed' does this by creating a temporary file and sending output to
this file rather than to the standard output.(1).

This option implies `-s'.

When the end of the file is reached, the temporary file is renamed
to the output file's original name.


I probably can't read documentation at all, or something like it. Nevermind, I have to done everything by hand again. Sigh. :angry: :angry: :angry:
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.

#16
Arie

Arie

    One Man Army

  • Member
  • PipPipPipPipPip
  • 835 posts
  • Joined 27-August 07

I'm sure this looks like a great idea. However I prefer do things "by hand" as I like FAT32 system for OS partition for speed reasons, so... So I tried to take a look how a script file can be used, but ended up in total dismay. First, this middle line looks messed up pretty bad:

REM ECHO>>HFNOLOAD.SED s/syspro_mp	  = hal.dll/syspro_mp	  = hal.dll,,noload/g
REM ECHO>>HFNOLOAD.SED s/mps_up		 = halapic.dll,,noload ,2,hal.dll/mps_up		 = halapic.dll ,2,hal.dll/g
REM DO NOT LOAD SCSI MINIPORT DRIVERS

What do you mean by "messed up pretty bad"? I don't see anything wrong with the script.


Second - the major annoyance is the SED tool itself. It suxx beyond words to describe. I was hoped for something like...
SED --in-place -f noload.sed txtsetup.sif
or
SED -i -f noload.sed txtsetup.sif
...witch, according to the docs should perform the noload.sed script upon the unsuspecting and naked txtsetup.sif file. But it does not work at all.

`-i[SUFFIX]'
`--in-place[=SUFFIX]'
This option specifies that files are to be edited in-place. GNU
`sed' does this by creating a temporary file and sending output to
this file rather than to the standard output.(1).

This option implies `-s'.

When the end of the file is reached, the temporary file is renamed
to the output file's original name.


I probably can't read documentation at all, or something like it. Nevermind, I have to done everything by hand again. Sigh. :angry: :angry: :angry:

SED might not be a great tool, but there aren't many tools around which can do the job. SED does its work.
Not trying to pretend the enemy that I am.

#17
tain

tain

    Cyber Ops

  • Super Moderator
  • 3,682 posts
  • Joined 24-September 05
  • OS:none specified
  • Country: Country Flag

Donator

sed is like that because it comes from the unix world.

For anyone who has issues using sed in the context of HFSLIP and Arie's files, note that there are three different possible sed downloads on the Sourceforge. Only the DOS one works for me. YMMV, so try the others if you need to.

#18
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 802 posts
  • Joined 24-November 06
  • OS:none specified
Sorry, i don't know about in relation to this script, but the sed version that i prefer is minised, as it's about 5 times faster and 70% smaller than the normal sed implementation(GNU sed).

Personally, then i prefer gsar, as my favorite "find'n replace" tool, which also is lightning fast(the search algo is modified to treat all input files as binary), lightweight and supports in-file replacements(like the newest GNU sed versions).

Just my 2 cents :)

Edited by Martin H, 12 April 2009 - 07:53 AM.

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#19
Muppet Hunter

Muppet Hunter

    XP Hotfix List Maintainer

  • Member
  • PipPip
  • 106 posts
  • Joined 18-March 05
In my experience expanding setup files is usually not worth the hassle unless maybe you're installing on very old hardware. It's a CPU and memory issue which most hardware from the last few years can cope with. I'm not sure that the extra time spent expanding the files is worth any gains from a faster install. Has anyone benchmarked this?

I think that the noload script probably has a similar effect to using nLite to remove the unnecessary drivers so that they don't load.

#20
caps_buster

caps_buster

    Member

  • Member
  • PipPip
  • 117 posts
  • Joined 20-February 09
I believe you are mistaken. CDROM's did not get any much faster in past years and the install is hence still slow, when it need to load bunch of small files that are not need on 99% of machines. CPU power and amounts of ram does not help here. The only serious problem is the need for hacking the depacked setupapi.dll (expand setupapi.dl_ setupapi.dll) file and then apply modifype setupapi.dll -c and compress it again (makecab setupapi.dll setupapi.dl_) and then place in to your install CD.

The change, when stripped down most of the useless things, is really like 50% faster. So, if you are like wasting your time while Windows setup is loading SCSI drivers for HW you haver even seen, then you are welcome to wait "faster" on faster machine :)

Never mind.

There are a ways to not reinstall too much. DríveImage (ImageCenter today) is the answer... Just backup the fresh install and you can change and add drivers/stuff w/o reinstalling.
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.

#21
caps_buster

caps_buster

    Member

  • Member
  • PipPip
  • 117 posts
  • Joined 20-February 09
BTW, for the possibility of installing the already modified/different windows files, it is necessary to hack the setupapi.dll file (setupapi.dl_ in the i386 directory). Depecking (expand) it, hacking it, fixing the header (modifype setupapi.dll -c) and packing it with makecab again. Now there:
http://www.vorck.com...t-setupapi.html
Fred Vorck cover the need byte sequences for Windows 2000 SP4, Windows XP SP3 and Windows 2003 SP2.
While all this is worth every penny and nice, I do miss the byte sequences/offsets for Windows XP SP 1 (or rather SP1.0a) and Windows XP SP2.

Anyone know them?
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.

#22
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • Joined 16-July 04
  • OS:Windows 7 x64
  • Country: Country Flag
I believe, IIRC, that the sequence is found at the only instance of the following byte sequence in the file:

90 90 90 90 90 8B FF 55 8B EC 8B 45 2C 33 C9 3B C1

So, search for that in any version of the file, and you should only find one such sequence, and that's the one to change.

#23
caps_buster

caps_buster

    Member

  • Member
  • PipPip
  • 117 posts
  • Joined 20-February 09
Thank you, Fred, for your quite fast response. No, string "90 90 90 90 90 8B FF 55 8B EC 8B 45 2C 33 C9 3B C1" is not found in the Win XP SP1.0a version, at least not in the Czech one I'm about to try changing. You got PM with the file...

And I tried different approach. Since W2k and XP are mostly the same, I tried searching for the "55 8B EC FF 75" sequance as with the Win2k SP4 setupapi.dll case. Quess what. Also FOUR instances of it, as in the W2k SP4 setupapi.dll file. So, as in the W2k, I blindly try to modify the second instance (as with W2k) - it is at 4F17D address and report back what happend when I try install WinXP with some modified files AND this modification of the setupapi.dll :)




Brief preliminary report
Failure - first it worked well, but at the end of the file copy phase, before the 1st reboot it complained that sfc_os.dll file is not winblows file, so for next try I have it modifyPE -c it and hopefully no messages anymore.
After reboot everything seems to be good, but after the setups and CD key and so on it get to the network install. And there it just stop. The progress indicator is halted, the right down "working" indicator is moving, but that it is. CD detection work too, but it looks like that adding my 63kBy hosts file with blocked all M$ domains ( http://www.msfn.org/...i...61.html&hl= ) is way too much for the network setup. Next try with standard hosts file.

So, failure, tough both problems can be explained by other way and MAYBE the suggested modification of the setupapi.dll file for Windows 2000 SP4 on your site, Fred, is applicable to XP SP1.0a Windows. Just the address where to modify (witch of the strings, the second one...) is 4F17D - at least for Czech version of these XP Windows.

Status - unconfirmed yet.

Edited by caps_buster, 14 October 2009 - 05:18 PM.

Disclaimer: Any errors in spelling, tact, or fact are transmission errors.

#24
caps_buster

caps_buster

    Member

  • Member
  • PipPip
  • 117 posts
  • Joined 20-February 09
After some battling with the not working XP install without the scsi drive support (not finding any drives) I managed to win and observed this:
- after the modifyPE was used on the sfc_os.dll file, no warning message anymore (good)
- after reboot, everything is installing well, until come the networking. It progress to about 50, maybe 60% and then stop and wait there forever (well, I waited about 5 or 8 minutes, but it is clearly not working)

Conclusion - the hack I did "blind" to the setupapi.dll file is NOT working at all. Using the originall hosts file it hang too, so it was NOT my hosts file (that is a good news also), but the hack.

As far as the 90 90 90 90 90 8B FF 55 8B EC 8B 45 2C 33 C9 3B C1 string goes, Fred, it is NOT FOUND in the setupapi.dll file my Windows XP SP1.0a Czech use. Any help?

The file is for everyone awailable there to look that the string is nonpresent:
[Link removed.]
(BTW, it looks way more like the Windows 2000 SP4 file, that string matches - except the position...)


Help?

Edited by dencorso, 23 October 2009 - 10:09 PM.
Link removed - violation of Rule # 1.b

Disclaimer: Any errors in spelling, tact, or fact are transmission errors.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN