someitguy wrote on 2024-02-04, 01:09:

BTW you can easily slipstream ntfs.sys from NT4 SP6 into nt3.51 ISO. In fact there is an nt 3.51 w SP5 includd ISO that uses the WIn2K bootloader. Use WinISO and swap the ntfs.sys in the i386 folder. 3.51 will happily use the newer NTFS format zero issues.

STOP! DON'T DO THAT.

NT 3.51 lacks many symbols commonly used by NT 4.0 and onwards. The new drivers will not even run.

Try running Dependency Walker from inside NT 3.51 and check the new ntfs.sys with it, and you'll know why.

On the other hand, Win2K bootloader (NTLDR) has nothing to do with the kernel and other stuffs, just that it is the last bootloader version that still has the ability to boot a NT 3.51 install, with improved functionality compared to original NT 3.x/4.x NTLDR. That's why you can use Win2K NTLDR for NT 3.51, but that's it.

LSS10999 wrote on 2024-02-04, 01:30:

STOP! DON'T DO THAT. […]
Show full quote

someitguy wrote on 2024-02-04, 01:09:

BTW you can easily slipstream ntfs.sys from NT4 SP6 into nt3.51 ISO. In fact there is an nt 3.51 w SP5 includd ISO that uses the WIn2K bootloader. Use WinISO and swap the ntfs.sys in the i386 folder. 3.51 will happily use the newer NTFS format zero issues.

STOP! DON'T DO THAT.

NT 3.51 lacks many symbols commonly used by NT 4.0 and onwards. The new drivers will not even run.

Try running Dependency Walker from inside NT 3.51 and check the new ntfs.sys with it, and you'll know why.

On the other hand, Win2K bootloader (NTLDR) has nothing to do with the kernel and other stuffs, just that it is the last bootloader version that still has the ability to boot a NT 3.51 install, with improved functionality compared to original NT 3.x/4.x NTLDR. That's why you can use Win2K NTLDR for NT 3.51, but that's it.

I take that back. Apparently I had not hit save on the ISO. <HEADDESK> I checked my 2 installs v4 vs v3.51 on the ntfs.sys. However, I have NT4 SP6 on D and NT3.51 SP5 on C: and wrote to C: from NT4 w/o issue. NT 3.51 sees the folder and zero issues. See if that still happens once I add 2000. Probably safest solution is FAT16 for boot part. Add FAT32 driver for shared data. I haven't had any issues so far though. I am testing a multi boot setup in a QEMU VM as Pentium CPU before I try w/ a k6-3+.

https://bearwindows.zcm.com.au/winnt351.htm#p5 That might be useful for some folks. They include FAT32 driver and LBA versions for 3.51.

someitguy wrote on 2024-02-04, 07:15:

https://bearwindows.zcm.com.au/winnt351.htm#p5 That might be useful for some folks. They include FAT32 driver and LBA versions for 3.51.

I know about that fastfat driver. I think there's only one such version for enabling FAT32 on NT 3.51.

It's just that NT 3.51 itself doesn't appear to understand extended partitions with LBA flag, and recognizing extended partitions has nothing to do with fastfat. I ended up converting the logical FAT32 partition to primary using a disk utility that could safely do it, and now it's properly accessible.

LSS10999 wrote on 2024-02-05, 06:25:

someitguy wrote on 2024-02-04, 07:15:

https://bearwindows.zcm.com.au/winnt351.htm#p5 That might be useful for some folks. They include FAT32 driver and LBA versions for 3.51.

I know about that fastfat driver. I think there's only one such version for enabling FAT32 on NT 3.51.

It's just that NT 3.51 itself doesn't appear to understand extended partitions with LBA flag, and recognizing extended partitions has nothing to do with fastfat. I ended up converting the logical FAT32 partition to primary using a disk utility that could safely do it, and now it's properly accessible.

You need the uni ata replacement driver to solve the LBA issue. That is a different issue than FAT32. That solved the extended parts on LBA.

https://alter.org.ua/en/soft/win/uni_ata/

someitguy wrote on 2024-02-05, 15:20:

You need the uni ata replacement driver to solve the LBA issue. That is a different issue than FAT32.

https://alter.org.ua/en/soft/win/uni_ata/

I'm already using UniATA. It's mandatory for large disks after all.

LSS10999 wrote on 2024-02-05, 15:36:

someitguy wrote on 2024-02-05, 15:20:

You need the uni ata replacement driver to solve the LBA issue. That is a different issue than FAT32.

https://alter.org.ua/en/soft/win/uni_ata/

I'm already using UniATA. It's mandatory for large disks after all.

Hmm ok. I must had a patched atapi.sys.

Don't know if anyone has experience with UniATA about this: How to reorder drive letters as defined by BIOS "Hard disk drives" order?

From my current tests it seems UniATA (or perhaps FAT32-enabled fastfat) does not honor BIOS hard disk order and would instead assign drive letters by physical port order. As a result, the system drive letter may be moved (e.g. from C: to D:) if you install another disk with a visible FAT/FAT32 primary partition to a port/controller ordered before the one with NT 3.51 installed.

NT 3.51's Disk Administrator doesn't understand FAT32 drives, even with the patched fastfat driver, so there's no way to change it there. I wonder if UniATA has any option/flag to allow it to honor BIOS disk order, or perhaps this needs to be handled somewhere else?

Sorry for another bump... I just migrated an existing system with NT 3.51 to another board with a X99 chipset and now it can't start, complaining about INACCESSIBLE_BOOT_DEVICE.

On the other hand, it seems most Intel chipsets including current ones are MPS-complaint to some extent as the MPS Multiprocessor PC HAL I previously used worked on this new system.

Looking at UniATA source code and I found out that for some reasons IDE entries (8d00, 8d08 and 8d60) for X99 (Wellsburg) were left out similar to a few other chipsets -- only AHCI/RAID ones listed. I'm not sure why and I'm currently trying to figure out how to correctly add them. I already tried adding the entries mimicking other chipsets that do have IDE mode mentions, but no avail. I even replaced scsiport.sys with the one from scsifix and still no good...

EDIT: AFAIK I never really succeeded in booting NT 3.51 from something attached to a SATA controller, be it IDE or AHCI. All success cases I have with UniATA always booted from PATA controllers... Am I missing something important about UniATA, that I need to configure it somewhere?

Well, NT 3.51 is still doing fine even on newer hardware like Intel 13th Gen CPU and an Asus H610 motherboard. (this board has MPS 1.4 support that works 100% OK with NT4)

I can confirm that NT 3.51 runs completely fine, 100% stable, with standard kernel. This was a surprise, but runs with MultiProcessor Kernel too! (YouTube video that I recommend to watch)

On both situations (uni and multiprocessor kernel) it runs from SATA SSD using UniATA 0.46e8 drivers.

When running through MPS 1.4 it looks like there are some issues with PCI devices. A PCI ALS4000 sound card that installs perfectly fine with standard kernel - didn't get discovered by its own drivers. Also official NT 3.51 drivers for an ATI Rage II didn't worked either. After some fiddling this ATI Rage card worked with VBE drivers. After VBE video drivers got installed, magically... the sound card was discovered by it's own drivers and the installation completed successfully - except I get no sound. 😀 MPS 1.4 is reported as MPS 1.1 by NT 3.51. And MPS 1.4 brought PCI support.

Going back to UniATA and SSD I must mention that I didn't perform any fresh NT 3.51 installation this thread was created in 2021. I recycled the same NT 3.51 installation on multiple configurations and it simply works.

OMORES wrote on Yesterday, 17:15:

Well, NT 3.51 is still doing fine even on newer hardware like Intel 13th Gen CPU and an Asus H610 motherboard. (this board has M […]
Show full quote

Well, NT 3.51 is still doing fine even on newer hardware like Intel 13th Gen CPU and an Asus H610 motherboard. (this board has MPS 1.4 support that works 100% OK with NT4)

I can confirm that NT 3.51 runs completely fine, 100% stable, with standard kernel. This was a surprise, but runs with MultiProcessor Kernel too! (YouTube video that I recommend to watch)

On both situations (uni and multiprocessor kernel) it runs from SATA SSD using UniATA 0.46e8 drivers.

When running through MPS 1.4 it looks like there are some issues with PCI devices. A PCI ALS4000 sound card that installs perfectly fine with standard kernel - didn't get discovered by its own drivers. Also official NT 3.51 drivers for an ATI Rage II didn't worked either. After some fiddling this ATI Rage card worked with VBE drivers. After VBE video drivers got installed, magically... the sound card was discovered by it's own drivers and the installation completed successfully - except I get no sound. 😀 MPS 1.4 is reported as MPS 1.1 by NT 3.51. And MPS 1.4 brought PCI support.

Going back to UniATA and SSD I must mention that I didn't perform any fresh NT 3.51 installation this thread was created in 2021. I recycled the same NT 3.51 installation on multiple configurations and it simply works.

I suppose all Intel boards have good MPS tables allowing the HAL to work... or maybe it's just that NT 3.51's MPS HAL only understands Intel chipset and not others (I remembered seeing "GenuineIntel" mentioned in the HAL binary).

EDIT: The amount of CPUs usable is determined by a registry key. Theoretically up to 8 CPUs can be used from what I've tested on VirtualBox. BearWindows supposedly had a kernel patch allowing using up to 32 CPUs, but it's not public. I wonder if anyone had contacted him about the patch before...

Personally I never succeeded in booting NT 3.51 across several systems when installed into disks attached to SATA controllers (all failed with INACCESSIBLE_BOOT_DEVICE). Only when it's connected to a PATA controller did it work. Setting SATA controller to IDE or AHCI didn't matter, and one of the systems I tried NT 3.51 on was AMD (760G chipset, using Standard PC HAL since MPS cannot be used).

Again... I must have missed something very important...