Post-HFSLIP Scripts: NOLOAD & SPEEDUP

[Arie]

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.

SED might not be a great tool, but there aren't many tools around which can do the job. SED does its work.

[tain]

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.

[Martin H]

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 April 12, 2009 by Martin H

[Muppet Hunter]

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.

[caps_buster]

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.

[caps_buster]

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/windows/edit-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?

[fdv]

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.

[caps_buster]

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/board/modifying-dnsapi...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 October 14, 2009 by caps_buster

[caps_buster]

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 October 24, 2009 by dencorso
Link removed - violation of Rule # 1.b