Here is the procedure I went through:

- copy contents of win2k (original edition) to hard drive, at d:\w2k
- from command line, run w2ksp51.exe -integrate:d:\w2k

(integration is performed and proclaimed as a success here)

- copy d:\w2k to a new computer at d:\w2ksp51 (new computer is partitioned)
- put msdos onto new computer's c: drive - it boots up fine
- after booting up new computer, execute d:\w2ksp5\i386\winnt.exe

after some file copying, this produces the following:



now i've done a lot of slipstreaming and installations before, and this error message has only ever appeared to me when i've slipstreamed a service pack into win2k, have neglected to update the txtsetup.sif contained in the bootdisk images, and then used the bootdisk image to install (txtsetup.sif mismatch between bootdisk and i386 folder).

the only conclusion i can think of is that the integration silently failed and corrupted the txtsetup.sif file. it's definitely present, has a large number of [files.xxx] entries and isn't visibly corrupt.

if i replace the d:\w2ksp51 folder with the vanilla w2k cd contents, or a w2ksp4 build, they both install fine. same computer, same msdos host, same install location, the only variable that causes failure is usp51 being slipstreamed.

any ideas? here's the md5 of the txtsetup.sif that was generated: fc2c314a1d96d7108a58235148dc6e8e

2 ideas,

1 use checksum on the w2ksp51.exe - might be a corupted download.....
2 retry the slipstreming....

reperformed slipstream 4 times now, off 2 different win2k masters. download is a-ok, checksums and extraction verify it.

for whatever reason, slipstreaming corrupts the working w2k install files.

how about this - i can post a before/after list of md5 sums for the entire i386 directory. if someone else can do the same, and my installation matches a working one, that means it's the new computer that's causing the grief.

i used md5summer to create these:

before and after md5 listings of virgin w2k and usp5.1 w2k

these could be compared against someone else's list with something like winmerge.

rehack, I could be wrong, but I think windows setup will reformat C:drive to NTFS and assign it a new drive letter before copying
its folder over to boot drive $win_nt$.~ before rebooting.
You need to get a look at the winnt.inf that is copied to the boot drive.
Also, do you spec the source file loc with the winnt command?

The working win2k installs ask you whether you'd like to convert C: to NTFS or leave it FAT32, after they've successfully copied the files over. I'll compare the files dumped and see what we have.

In all cases, failure to specify source file location makes setup prompt you and ask the location, which it guesses right.

I just don't understand why w2k and w2ksp4 work fine, but w2ksp51 fails from a dos install.

OK, I misunderstood. I thought you had a FAT boot partition. So which option do you choose?
And if it see's your D: drive as D: drive, then the source loc isn't changing midway through...
So lets start with the more obvious...
Since the complaint is about the "[FILES]" section, it could be referring to the dosnet.inf file.
Neither winnt.sif (if you use it) nor txtsetup.sif have a section with that title.
Does it exist on your integrated install, how about when copied to the new D:drive?
Open it in notepad and have a look. If every thing is good there, I doubt it would be damaged while being copied to the new C: drive during install.

Step by step. btw, my own build is so tweaked that I doubt a MD5 chksum check would be worthwhile.

Oh - C: and D: are both FAT32, C: has DOS 7 installed (whatever win98 came with), whenever winnt.exe is ran it says "Please supply setup with windows setup files location" or some such, which it always correctly guesses as D:\w2ksp5\i386\. The working w2k's copy files to C:, execute them from there, and prompt afterwards whether to change C: to NTFS, the usp5.1 version never gets that far.

I'll spend some time tomorrow comparing what's copied to C: by the various versions.

I'll look into this - it really ought to work.

G

I'v reproduced the problem. It might be related to DOSNET.INF somehow. I'm looking into it.

Sorry for the inconvenience.

/G

I appreciate you looking into it.

I actually got very interested in how something like the usp was put together, and started doing diffs to see how to automate adding multiple fixes with overlapping file versions. But once I saw how much trouble it was to integrate packages that prefer manual installs (dx, ie, wmp..) I figured I'd leave it to someone who's already gone through that hell =)

Yeah - it's not always as easy as one would imagine

Anyway - I got to the bottom of the problem - it has a lot of time, but I needed to know myself:

1 - There is in fact a syntax error in DOSNET.INF - the line "d1.nntpfs.dll" should of course be "d1,nntpfs.dll". This is the error that WINNT.EXE reports. This bug is mine, and it will be fixed now.

2 - WINNT.EXE (16-bit) sometimes has problems with VFAT it seems - although VFAT entries ("long file names") are not supposed to be accessible in pure DOS mode, their presence seems to confuse WINNT.EXE. I have no idea why (best bet is that this is a bug in DOS), but it's best to keep all filenames in upper case. Silly, really. There's nothing I can do about this.

3 - In TXTSETUP.SIF I refer to the disk label file "disk1", but it's not listed in the [Files] section of DOSNET.INF. This is mine, and it will be fixed now.

4 - In case WINNT.EXE decides to prepare a Local Source ($WIN_NT$.~LS), it gets confused because some files have multiple destinations in TXTSETUP.SIF. This is a limitation of WINNT.EXE, and it generates a lot of warnings. MS never need to have multiple destinations for any file in TXTSETUP.SIF - but this is only because they can sign their own catalogs. But I won't even try to explain this, because it's painfully complicated. It's possible to create a DOSNET.INF/TXTSETUP.INF that does work perfectly with WINNT.EXE - only problem is, that this breaks the Add/Remove Windows Components feature once Windows is installed.

5 - If any hotfixes are integrated into a W2K SP4 the documented way, WINNT.EXE won't work either.

Best regards,
Gurgelmeyer

Fixed. Add/remove Components also works like it should now.

Thanks again for pointing it out

/G

Are these fixes going into 5.1 SR-1 ?
I just downloaded the file from softpedia and looked for the errors you pointed out and I found them in the dosnet.inf file.
If you wouldn't mind could you post instructions on exactly what I need to change to fix the syntax problem, the add/remove issue, and the [Label] problem you mentioned earlier.

Thank you!

stupid qwestion but, would disabling WFP be a 'working' way around it (for now),

//(didn't test it)

You talking to me? Or the thread creator?

I would say it has nothing to do with that. WFP is something that only activates after you install, not while your installing.

@-I- - nope - these errors occur only in real mode DOS and in the text mode part of Setup, so WFP isn't installed yet.

/G