Jump to content

HFSLIP 1.7.8 annoyances


caps_buster

Recommended Posts

I remember that HFSLIP helped me to integrate DX9.0c easily into Windows - just put the bdant.cab and dxnt.cab into the HFCABS folder and that it is! Copy the whole Windows CD into the SOURCE directory and run HFSLIP again and find the result into the SOURCESS directory...

Well, I run it on already integrated Win2k SP4 Czech install, because I see little point gathering the Service pack file and depacking (W2KSP4.EXE -x) it and using the Update.exe -s to update the contents of the i386 dir, when I already did that before and have just stored the unmodified Windows 2000 SP4 Czech on CD.

When run, HFSLIP complained about missing or/and unable to open LNG.TXT ... No idea where to get this file.

A line before that was PRODSPEC.INI and some failure about identification, well, PRODSPEC.INI contents are:

;
;Upozornění pro uživatele: NEZMĚŇTE ANI NESMAŽTE TENTO SOUBOR.
;
[SMS Inventory Identification]
Version=1.0

[Product Specification]
Product=Windows 2000 Professional

Version=5.0
Localization=Czech
ServicePackNumber=0
BitVersion=40
[Version]
DriverVer=03/08/2000,5.00.2195.1

After that is says that all was intergrated into the sourcess and:

Remember to reboot your machine after installing

from the SOURCESS folder.

FINDSTR: Nelze otevřít AMPME.TXT

FINDSTR: Nelze otevřít TTEST.TXT

FINDSTR: Nelze otevřít TTEST.TXT

FINDSTR: Nelze otevřít TTEST.TXT

Interesting.

Directory SOURCESS is nonexisting anyway.

Link to comment
Share on other sites


First error is this:

FINDSTR: Nelze otevřít SOURCE\I386\PRODSPEC.INI
FINDSTR: Nelze otevřít SOURCE\I386\PRODSPEC.INI
HFSLIP was unable to determine the language of your source OS. As a result,
some updates such as the Windows Update Agent cannot be slipstreamed properly.

Then:

All hotfixes integrated into a folder called SOURCESS.

Remember to reboot your machine after installing
from the SOURCESS folder.


HFSLIP run time: 1m33s

But it is a lie, SOURCESS directory in the root of my D drive did not even exist!

So, let me repeat what I did:

1) copy whole Win2k SP4 CD into the SOURCE directory, i386 dir including, of course

2) copy bdant.cab and dxnt.cab into HFCABS for DirectX 9.0c

3) place wmfdist.exe into the HF dir for WMV9/10 codecs

4) copy these files into the REPLACE dir:

comctl32.oc_
comdlg32.dl_
comdlg32.oc_
desk.cp_
fsutil.ex_
gdiplus.dl_
libeay32.dl_
libssl32.dl_
mfc71.dl_
mpeg2dmx.ax_
msadds32.ax_
mscomctl.oc_
mscoree.dl_
msvcp60.dl_
msvcp71.dl_
msvcr70.dl_
msvcr71.dl_
msvcr90.dl_
msvcrtd.dl_
mswinsck.oc_
notepad.ex_
notepad.in_
NTDETECT.COM
ntldr
ntoskrnl.ex_
ping.ex_
powercfg.ex_
quartz.dl_
sfc.dl_
sfcfiles.dl_
shell32.dl_
sysinfo.oc_
sysoc.in_
tabctl32.oc_

5) prepare the HFTOOLS dir, using these files:

bbie.exe
cmdow.exe
EXTRACT.EXE
mkisofs.exe
modifyPE.exe

6) fit registry fixed I use into the HFSVCPACK directory, files are named 1.reg to 7.reg

7) other directories are empty

8) hack the setupapi.dll, fix it's CRC and fix the CRC of the sfc.dll file, and replace the originals back in the SOURCE dir, compressing them as they was, of course as described there: http://www.vorck.com/windows/2ksp5.html

9) run HJSLIP for the second time...

WOW, it works now!

After few minutes of thinking I realize what it was - my way of protecting the batch files to run on my computer kicked in :) It is a great way to protect himself from harm, but one have to ocassionally disable this :)))

;CMD path set - make batch files not working, unless manually started!!!

[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]

"Autorun"="CD /d D:\\"

!!!

Link to comment
Share on other sites

Now I still have one question. The files I put in the REPLACE dir are into the root directory of the CD - eg. directly in the SOURCESS result dir. Is that normal? Should I keep them there and burn the whole SOUCRESS into a bootable CD? With these files in ROOT of the CD?

Is not better manually replace them in the i386 dir?

Link to comment
Share on other sites

Whoa, dude... next time put the word "solved" or something at the top because I was racking my brain trying to follow and troubleshoot in my mind as I read! :lol:

Files in REPLACE should end up in the correct dir, it is not normal that they went into the root.

But to save some trouble anyway, if you are POSITIVE that you want to replace the files, I personally would just go ahead and put them into the original SOURCES/I386 and replace the originals (maybe name the old ones .bak). I personally have done this with many files in my win2k.

Something I just noticed, are some of those files in REPLACE not in 2k normally? As in, they are not all replacing existing files?

Link to comment
Share on other sites

Oh, sorry! My register trick played tricks on myself also :)

So it is okay for these to be in the root dir? Good then. Replacing them by hand is possible and preffered by you? So I do it as well. WFP is disabled by hacked SFC.dll + 4k big SFCfiles.dll as well, so, there should be no problemo. Also the setupapi.dll is hacked, so I did not expect any problems. I try to burn the install and install it fresh on testing PC and report back then :hello:

And yes, many of these files are NONSTANDARD and nonexistant in Windows 2000, so, they are not exactly "replaced". These that don't get replaced might not even work - eg. not end where they should be, unless I specify to copy them in (witch file?)...? Is that where you thoughts are aiming for?

Link to comment
Share on other sites

I use replace\i386 to replace files inside teh i386 folder. The replace may be a better option for replacing too. If a hotfix binariy has a newer date than what you manually replaced, the files you want may not be in the sourcess. A safer bet is to use the replace folder where the files will overwrite irregardless of filedates. The replace actions happen at the tail end of hfslip, just before it makes the iso.

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
  • Recently Browsing   0 members

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