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 2024-04-27, 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...

Back around 1995 the Pentium 75 thru 100mhz was popular for running WinNT-351
It was the CPU used to Network the World and cloud run just about anything.
From Data bases, Web sites, Servers, Server Clusters, etc.

We used these CPUs in Computer education school classrooms and they ran everything with NO problems.

LSS10999 wrote on 2024-04-28, 01:01:

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 under […]
Show full quote

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...

A little update. I managed to build a debug version of UniATA 0.47b and enabled it to print everything it could on the boot screen via a registry value. I did so by making the changes to the registry from the VM before moving the modified system folder to my actual system. The log output scrolls very fast so I have to first do a video capture from my phone then analyze its contents frame-by-frame.

The debug log had mentions of my SATA controller, which is currently in AHCI mode (8086:8d02), and it did find my controller at its intended location (00:1f.2). After a lot of fast-scrolling outputs UniATA's DriverEntry exited with a status code of 0xc00000c0 (per ScsiPortInitialize), then the 7B bugcheck happens with fastfat.sys (I'm using the FAT32-enabled one) listed on top of the stack.

I couldn't find any useful info on the meanings of the value returned by ScsiPortInitialize at the moment so I don't know whether this means a successful init. UniATA's output, at least the parts that I could figure out when analyzing the video capture, did not appear to explicitly suggest errors on the part regarding SATA/AHCI controllers, though it did print some apparently failed output when detecting ISA and MCA controllers (which I think should be expected).

If the output value suggests a successful init, then maybe it's really the FAT32-enabled fastfat.sys that was to blame for the boot failure here. On the other hand, I also attempted running Windows 3.11 on the same system and so far only Standard Mode worked. All attempts to get 386-enhanced mode working were not successful. So... maybe my disk/partition layout is a bit problematic for those OSes?

PS: From UniATA's debug output, the driver apparently detects VMs such as VirtualBox during its init. Haven't looked into the details, though.