A little update... It seems setting the SATA to IDE mode made things a bit easier now that I'm able to complete the installation.

However, I couldn't boot it when using the MPS Multiprocessor HAL. It halts saying no IO APIC (which I obviously had the APIC turned on in BIOS).

Given the systems nowadays are MPS 1.4 complaint, while NT 3.51 HAL officially supported only 1.1. Does it really cannot run with MPS 1.4?

The motherboard I'm using for NT 3.51 is too new to be offering the MPS version (1.1/1.4) toggle. Am I totally out of luck for making the system use more than 1 CPU core/thread?

Is there any alternative usable HAL for multiprocessing?

EDIT 4: Cleaning up the previous comments. I was probably wrong: MPS and ACPI are not really the same thing. Modern boards are ACPI complaint but it doesn't mean it's also MPS complaint. So my AMD motherboard simply can't work with MPS HALs anyway.

On the other hand, it seems some LGA775 motherboards (like RUBY-9719VG2AR) are still MPS complaint and can be correctly detected by NT 3.51 setup as a MPS Multiprocessor PC. However, I'm having issues with latest UniATA on that board.

UPDATE: As for the MPS HAL problem... looks like this answered my confusions to some extent. With ACPI, MP tables are no longer mandatory and may be invalid. Not sure if it's possible to "fix" the tables, if it's really the case.

EDIT 5: An initial inspection of the original SP5 build of HALMPS.DLL (along with the debug symbols) using IDA free version revealed that it's probably checking for the "GenuineIntel" vendor string for certain features (but not others). Need to look into this deeper to figure out what it might be doing, as it's not the only test performed during initialization, but it's not a high priority as the system is usable enough...

PS: The HALs from NT4 beta 1314, which is usable with NT3.51, indeed mention MPS 1.4 after initial inspection. However, whether or not it is compatible with AGP/PCIe (mainly concerns VBEMP) needs testing...
UPDATE: The NT4 beta HAL does not work with AGP/PCIe. VBEMP ends up in a black screen, just like HALFMV0.

It seems UniATA 0.46e8 is not fully bug-free on my target motherboard (M5A78L/USB3).
- Whichever hard drive (IDE or SATA) set as the first (boot) drive will always report having up to 8033MB free space (if less than this amount has been allocated) regardless of its actual capacity (which is correctly detected).
- If I set a SATA drive (IDE mode) as boot drive and install NT 3.51 on it, I get 0x7B (INACCESSIBLE_BOOT_DEVICE) upon startup. However, if I set the disk on the IDE port as boot drive, it'll boot fine after install.
(NOTE: Both the IDE and SATA controllers are being handled by UniATA)

None of these issues occur on VirtualBox which emulates a BusLogic controller. BusLogic driver can correctly detect the size and free space of the VBox virtual disk.

Additionally, the HALFMV0 (uniprocessor) I mentioned predates the AGP hotfix and VBEMP will not work correctly (default VGA driver still works fine). I have to use Standard PC HAL (uniprocessor) for that to work. Sadly on my board no multiprocessor HAL is going to work. Not sure about OP's X470 motherboard, though.

However, VBEMP behaves similarly to ArcaOS Panorama: With a 4K monitor I don't get 1920x1080 option but 3840x2160 (which would be overkill), though only 64k colors possible at 4K in VBEMP's case. The ideal video resolution would be 1280x800.

EDIT: I'm able to set up an environment for UniATA 0.47b mostly according to the provided building instructions. While NT4 DDK includes are required (due to some headers and definitions absent from NT3.51 DDK), if I instead link against LIBs from NT 3.51 DDK instead of NT4 DDK's, I get a binary that does not import those breaking symbols (_alldiv, _allmul, _aulldiv, _aullrem).

EDIT 2: The compiled driver seems usable. Here's the uniata.sys (0.47b) I compiled if anyone's interested. This is only the driver file and is only relevant for NT 3.51. You can use the official 0.47b package for other stuffs.

BTW: While the UniATA drivers work fine for my current NT 3.51 target motherboard (everything except multiprocessor is working now), I tried both 0.46e8 and the compiled 0.47b on my RUBY-9719VG2AR (ICH7-based) but neither worked correctly during install. The system would hang after loading text-mode drivers despite there are still ongoing activities in the HDD and optical drive as indicated by the busy LEDs. I'm using an IDE optical drive on that system and maybe UniATA is having issues with such drives.

EDIT 3: I finally got NT 3.51 up and running on the other board (RUBY-9719VG2AR), by first preparing the system disk in a VBox VM (installing NT 3.51 and other stuffs), dd the prepared disk to a image file, then dd the image file into the real system disk. The system booted just fine on the real system with no apparent issues (all 4 cores visible using the MPS HAL). However, when doing the preparation work with VBox, there are indeed caveats with UniATA which may not affect real systems as much (none of these issues are observed with default IDE/Buslogic storage drivers).
- VBox can't boot NT 3.51 with more than 1 detected CPU (MPS HAL) when using UniATA. Setting the storage controller to AHCI may fix it in some (but not all) cases.
- A non-fatal CPISetup error 5 can occur during GUI mode setup process, after finish copying files, which can be safely ignored. It seems to corrupt the icon entry of certain program group icons (replaced with a generic MS-DOS icon from PROGMAN.EXE) but they can be corrected (the affected programs itself are not corrupt and will still run fine).
- Some programs/libraries can appear corrupt and unusable with UniATA. The files affected are not random. Need to test it on real PC to be sure as this might be just another VBox-specific issue like the other ones.

PS: From this experience... looks like the text/GUI mode setup process of Windows NT family indeed had some potential issues that can prevent it from going smoothly under some circumstances... that it was eventually superseded by WIM/ESD starting from Windows Vista which hopefully avoided a good amount of them.

Sorry to necro an old thread, but I was wondering if you guys could provide specific instructions on how you prepared the NT 3.51 installation to boot using UNIATA from an AHCI controller (or even a Native SATA controller). I don't need Bearwindow's slipstream instructions (I know them quite well); just the effort needed to get NT to boot from an AHCI controller using UNIATA.

I've used UNIATA for years, but only on Intel motherboards with SATA ports that the BIOS can set to "Compatible" mode. Every time I switch to the ports to Native SATA (or "Enhanced IDE") or AHCI modes in the BIOS (regardless of the Intel chipset I use), UNIATA blue screens during the boot process. Very frustrating.

Thanks in advance.

OMORES wrote on 2022-01-21, 19:24:

* 1 PCI-E 1x with gigabit card Broadcom or Intel. Intel gigabit cards work fine under Windows 3.11. If TCP/IP from Microsoft fails, you need to go with Trumpet TCP/IP which uses a packet driver. Luckily, I found a packet driver and everything else to make it work under 3.1

Wait a minute... there's a gigabit NIC with native packet driver?
Or you mean ODI+ODIPKT ?

Grzyb wrote on 2022-12-05, 03:09:

OMORES wrote on 2022-01-21, 19:24:

* 1 PCI-E 1x with gigabit card Broadcom or Intel. Intel gigabit cards work fine under Windows 3.11. If TCP/IP from Microsoft fails, you need to go with Trumpet TCP/IP which uses a packet driver. Luckily, I found a packet driver and everything else to make it work under 3.1

Wait a minute... there's a gigabit NIC with native packet driver?
Or you mean ODI+ODIPKT ?

This is the NT 3.51 thread. Sadly Gigabit ethernet support is very limited and there are very few supported devices. NT 3.51 does support a good amount of Fast ethernet, though.

On the other hand, vendors supported DOS NDIS2 for much longer. I'm not sure but I think it was possible for Win3.1x to use an existing NDIS2 driver somehow... and there's a shim for using NDIS2 drivers as packet driver also.

fosterwj03 wrote on 2022-12-05, 02:15:

Sorry to necro an old thread, but I was wondering if you guys could provide specific instructions on how you prepared the NT 3.51 installation to boot using UNIATA from an AHCI controller (or even a Native SATA controller). I don't need Bearwindow's slipstream instructions (I know them quite well); just the effort needed to get NT to boot from an AHCI controller using UNIATA.

I've used UNIATA for years, but only on Intel motherboards with SATA ports that the BIOS can set to "Compatible" mode. Every time I switch to the ports to Native SATA (or "Enhanced IDE") or AHCI modes in the BIOS (regardless of the Intel chipset I use), UNIATA blue screens during the boot process. Very frustrating.

Thanks in advance.

It seems to be chipset-specific. Some controllers may be detected by UniATA but cannot boot from it. Which chipset are you using?

Also, UniATA doesn't seem to recognize SCSI-based controllers (maybe I need to use BusLogic?). A while ago I tried booting a NT351 instance prepared from VBox on a real system's SATA drive behind a LSI SAS HBA, and UniATA failed to detect the boot device unfortunately.

LSS10999 wrote on 2022-12-05, 10:37:

fosterwj03 wrote on 2022-12-05, 02:15:

Sorry to necro an old thread, but I was wondering if you guys could provide specific instructions on how you prepared the NT 3.51 installation to boot using UNIATA from an AHCI controller (or even a Native SATA controller). I don't need Bearwindow's slipstream instructions (I know them quite well); just the effort needed to get NT to boot from an AHCI controller using UNIATA.

I've used UNIATA for years, but only on Intel motherboards with SATA ports that the BIOS can set to "Compatible" mode. Every time I switch to the ports to Native SATA (or "Enhanced IDE") or AHCI modes in the BIOS (regardless of the Intel chipset I use), UNIATA blue screens during the boot process. Very frustrating.

Thanks in advance.

It seems to be chipset-specific. Some controllers may be detected by UniATA but cannot boot from it. Which chipset are you using?

Also, UniATA doesn't seem to recognize SCSI-based controllers (maybe I need to use BusLogic?). A while ago I tried booting a NT351 instance prepared from VBox on a real system's SATA drive behind a LSI SAS HBA, and UniATA failed to detect the boot device unfortunately.

I've tried UNIATA.SYS with Intel P45 (Wolfdale), Q67 (Sandy Bridge), P67 (Sandy Bridge), B75 (Ivy Bridge), and H97 (Haswell) chipsets (CPUs). It only works for me when I set the SATA ports to "Compatible" IDE mode on the Wolfdale and Sandy Bridge-based platforms. It never boots for me if I set these ports to either "Enhanced" IDE or AHCI modes (newer chipsets don't offer the "Compatible" option). This is true when I use the driver with both NT 3.51 and NT 4. I figured I'm doing something wrong with the UNIATA driver.

The UNIATA website has very few clues as to proper implementation for these chipsets. I've tried the driver as a stand-alone install and as a replacement for the basic NT IDE/ATAPI driver (ATAPI.SYS). I've also tried some of the registry settings listed on the UNIATA website, but that doesn't seem to help either (or I'm using the wrong ones).

I seem to have the same problem in VirtualBox with its AHCI controller as well. Again, I wonder if I'm missing something since it seems like other people have gotten it to work with the VirtualBox AHCI controller.

On a positive note, I have gotten UNIATA to work with a VIA 6421-based SATA/IDE controller (PCI). Unfortunately, it's not always practical to use this controller with NT 3.51 when I already use a PCI sound card, PCI video card, and PCI network card (very few modern motherboards have more than 3 native PCI slots).

fosterwj03 wrote on 2022-12-05, 23:35:

I've tried UNIATA.SYS with Intel P45 (Wolfdale), Q67 (Sandy Bridge), P67 (Sandy Bridge), B75 (Ivy Bridge), and H97 (Haswell) chi […]
Show full quote

LSS10999 wrote on 2022-12-05, 10:37:

fosterwj03 wrote on 2022-12-05, 02:15:

Sorry to necro an old thread, but I was wondering if you guys could provide specific instructions on how you prepared the NT 3.51 installation to boot using UNIATA from an AHCI controller (or even a Native SATA controller). I don't need Bearwindow's slipstream instructions (I know them quite well); just the effort needed to get NT to boot from an AHCI controller using UNIATA.

I've used UNIATA for years, but only on Intel motherboards with SATA ports that the BIOS can set to "Compatible" mode. Every time I switch to the ports to Native SATA (or "Enhanced IDE") or AHCI modes in the BIOS (regardless of the Intel chipset I use), UNIATA blue screens during the boot process. Very frustrating.

Thanks in advance.

It seems to be chipset-specific. Some controllers may be detected by UniATA but cannot boot from it. Which chipset are you using?

Also, UniATA doesn't seem to recognize SCSI-based controllers (maybe I need to use BusLogic?). A while ago I tried booting a NT351 instance prepared from VBox on a real system's SATA drive behind a LSI SAS HBA, and UniATA failed to detect the boot device unfortunately.

I've tried UNIATA.SYS with Intel P45 (Wolfdale), Q67 (Sandy Bridge), P67 (Sandy Bridge), B75 (Ivy Bridge), and H97 (Haswell) chipsets (CPUs). It only works for me when I set the SATA ports to "Compatible" IDE mode on the Wolfdale and Sandy Bridge-based platforms. It never boots for me if I set these ports to either "Enhanced" IDE or AHCI modes (newer chipsets don't offer the "Compatible" option). This is true when I use the driver with both NT 3.51 and NT 4. I figured I'm doing something wrong with the UNIATA driver.

The UNIATA website has very few clues as to proper implementation for these chipsets. I've tried the driver as a stand-alone install and as a replacement for the basic NT IDE/ATAPI driver (ATAPI.SYS). I've also tried some of the registry settings listed on the UNIATA website, but that doesn't seem to help either (or I'm using the wrong ones).

I seem to have the same problem in VirtualBox with its AHCI controller as well. Again, I wonder if I'm missing something since it seems like other people have gotten it to work with the VirtualBox AHCI controller.

On a positive note, I have gotten UNIATA to work with a VIA 6421-based SATA/IDE controller (PCI). Unfortunately, it's not always practical to use this controller with NT 3.51 when I already use a PCI sound card, PCI video card, and PCI network card (very few modern motherboards have more than 3 native PCI slots).

In my case, UniATA corrupts data with VBox if assigned with more than 1 CPU cores and is using the default IDE controller, which usually triggers BSoD during boot. However, I do not have the issue on real hardware that have proper MPS support to enable more than 1 core.

It does work okay with VBox AHCI controller, though in my case it just works without any additional configuration. Haven't really tested my own systems with AHCI, though. Note that the OS profile you choose for your VM affects some parameters under the hood, which can affect certain functionality. For these parameters you need to manually look at your VM configuration (.vbox) file.

If you only intend to use legacy OSes on a system, there's little benefit in using AHCI. IDE is more ideal in such use cases.

LSS10999 wrote on 2022-12-06, 02:47:

In my case, UniATA corrupts data with VBox if assigned with more than 1 CPU cores and is using the default IDE controller, which […]
Show full quote

fosterwj03 wrote on 2022-12-05, 23:35:

I've tried UNIATA.SYS with Intel P45 (Wolfdale), Q67 (Sandy Bridge), P67 (Sandy Bridge), B75 (Ivy Bridge), and H97 (Haswell) chi […]
Show full quote

LSS10999 wrote on 2022-12-05, 10:37:

It seems to be chipset-specific. Some controllers may be detected by UniATA but cannot boot from it. Which chipset are you using?

Also, UniATA doesn't seem to recognize SCSI-based controllers (maybe I need to use BusLogic?). A while ago I tried booting a NT351 instance prepared from VBox on a real system's SATA drive behind a LSI SAS HBA, and UniATA failed to detect the boot device unfortunately.

I've tried UNIATA.SYS with Intel P45 (Wolfdale), Q67 (Sandy Bridge), P67 (Sandy Bridge), B75 (Ivy Bridge), and H97 (Haswell) chipsets (CPUs). It only works for me when I set the SATA ports to "Compatible" IDE mode on the Wolfdale and Sandy Bridge-based platforms. It never boots for me if I set these ports to either "Enhanced" IDE or AHCI modes (newer chipsets don't offer the "Compatible" option). This is true when I use the driver with both NT 3.51 and NT 4. I figured I'm doing something wrong with the UNIATA driver.

The UNIATA website has very few clues as to proper implementation for these chipsets. I've tried the driver as a stand-alone install and as a replacement for the basic NT IDE/ATAPI driver (ATAPI.SYS). I've also tried some of the registry settings listed on the UNIATA website, but that doesn't seem to help either (or I'm using the wrong ones).

I seem to have the same problem in VirtualBox with its AHCI controller as well. Again, I wonder if I'm missing something since it seems like other people have gotten it to work with the VirtualBox AHCI controller.

On a positive note, I have gotten UNIATA to work with a VIA 6421-based SATA/IDE controller (PCI). Unfortunately, it's not always practical to use this controller with NT 3.51 when I already use a PCI sound card, PCI video card, and PCI network card (very few modern motherboards have more than 3 native PCI slots).

In my case, UniATA corrupts data with VBox if assigned with more than 1 CPU cores and is using the default IDE controller, which usually triggers BSoD during boot. However, I do not have the issue on real hardware that have proper MPS support to enable more than 1 core.

It does work okay with VBox AHCI controller, though in my case it just works without any additional configuration. Haven't really tested my own systems with AHCI, though. Note that the OS profile you choose for your VM affects some parameters under the hood, which can affect certain functionality. For these parameters you need to manually look at your VM configuration (.vbox) file.

If you only intend to use legacy OSes on a system, there's little benefit in using AHCI. IDE is more ideal in such use cases.

I hoped to use UNIATA with the B75 chipset to get better performance out of the motherboard's controller. I can boot into NT 3.51 using the basic ATAPI.SYS driver from NT4 SP6, but UNIATA blue screens in both "IDE" mode and AHCI on the B75 board. The basic driver is super slow on the B75. It's a wonder that it works at all.

can you give your files with UniATA

Gorden Malcom wrote on 2023-12-04, 14:37:

can you give your files with UniATA

You can simply use the uniata.sys file I built (see attachments in previous posts) with the other files from the official package.

I did not build nor change anything else. It's just that newer uniata.sys imports a few symbols that do not exist in 3.51 when built with the libs shipped with NT4 DDK. If substituting them with libs from NT3.51 DDK I get a usable build that do not import them. I built it using a Windows 2000 VM.

Version 0.46e8 works out-of-box. As for newer versions, not sure what's changed but I don't see any noticeable difference regarding bugs I'm having.

Thank you for your reply LSS10999 ,
I want to install Windows 2000 on a Gigabyte b450 Aorus pro wifi MotherBord. But the thing is I don't have any fancy PCI or PCIe sata or IDE card. So I left with the option of installing in VM and install UniATA driver and write the VHD to a physical hard drive (or) SSD. but I didn't manage to install the UniATA driver in VM, I used method from the official website, but that didn't work. but one guy managed to do that but he didn't reply to my message, So I don't know the method. can you tell me how to install the UniATA driver in VM PLEASE?

Gorden Malcom wrote on 2023-12-06, 10:31:

Thank you for your reply LSS10999 ,
I want to install Windows 2000 on a Gigabyte b450 Aorus pro wifi MotherBord. But the thing is I don't have any fancy PCI or PCIe sata or IDE card. So I left with the option of installing in VM and install UniATA driver and write the VHD to a physical hard drive (or) SSD. but I didn't manage to install the UniATA driver in VM, I used method from the official website, but that didn't work. but one guy managed to do that but he didn't reply to my message, So I don't know the method. can you tell me how to install the UniATA driver in VM PLEASE?

For NT 3.51 I used an image that has UniATA slipstreamed into it. You probably need to do the same for Win2K as well.

Again, if you're using Win2K then you don't really need my uniata.sys build. You can just use the official version.

A note, however, is that UniATA is not PAE-aware in general. If you have more than 4GB of RAM, are using a Server SKU and has PAE enabled, then it'll BSOD.

Thank you for your reply LSS10999,
And God Bless You, Brother.

fosterwj03 wrote on 2022-12-05, 02:15:

Sorry to necro an old thread, but I was wondering if you guys could provide specific instructions on how you prepared the NT 3.51 installation to boot using UNIATA from an AHCI controller (or even a Native SATA controller). I don't need Bearwindow's slipstream instructions (I know them quite well); just the effort needed to get NT to boot from an AHCI controller using UNIATA.

I've used UNIATA for years, but only on Intel motherboards with SATA ports that the BIOS can set to "Compatible" mode. Every time I switch to the ports to Native SATA (or "Enhanced IDE") or AHCI modes in the BIOS (regardless of the Intel chipset I use), UNIATA blue screens during the boot process. Very frustrating.

Thanks in advance.

Coming across this discussion a bit late, but the problem you describe is likely due to a bug with PCI bus enumeration in NT 3.51 and 4.0's SCSIPORT.SYS component that often surfaces on relatively modern chipsets. Bearwindows describes it here:

https://bearwindows.zcm.com.au/winnt351.htm#18

and has fixes available here: https://bearwindows.zcm.com.au/scsifix.rar. As far as I can tell, Microsoft never addressed this bug in a Knowledge Base article nor fixed it in any NT 4.0 hotfix. Would you believe that only a single byte of executable code in SCSIPORT.SYS (plus the header checksum) needed to be patched to fix this? (Suffice to say it's straightforward enough to fix it yourself in other builds of the file using a hex editor and checksum utility.)

Also, UniATA's AHCI compatibility is a bit buggy. The 0.47 release fixed a bug where attempting to do a full/non-quick format of a partition on an AHCI drive would hang, but the latest 0.47b release still causes the system to hang if you attempt to retrieve a drive's SMART status with SIV or another utility, and attempting to run a program directly from an AHCI optical drive apparently triggers data corruption (causing the program to hang or crash when starting). "Native" SATA (or "ATA"/"Enhanced IDE") mode is problem-free in my experience (with NT 4.0), and may perform just as fast, so I recommend using it instead on systems that offer it.

Beginning with 0.47, Alter apparently migrated his build environment to WINE on Linux, and this apparently messed up the packaging part of the build process as the root "Release_Dist" folder in the RAR package now contains a bunch of extraneous and outdated files compared to the earlier releases (and broke the TGZ packaging altogether). Make sure you use the INF file in the appropriate OS subfolder (NT351/NT4/2K/etc.), not the ones in the root folder. I reported this along with the AHCI bugs in an email to Alter a couple of years back, but he didn't respond; hopefully he'll eventually fix them in a future release.

loblolly986 wrote on 2024-01-14, 19:39:

Coming across this discussion a bit late, but the problem you describe is likely due to a bug with PCI bus enumeration in NT 3.5 […]
Show full quote

fosterwj03 wrote on 2022-12-05, 02:15:

Sorry to necro an old thread, but I was wondering if you guys could provide specific instructions on how you prepared the NT 3.51 installation to boot using UNIATA from an AHCI controller (or even a Native SATA controller). I don't need Bearwindow's slipstream instructions (I know them quite well); just the effort needed to get NT to boot from an AHCI controller using UNIATA.

I've used UNIATA for years, but only on Intel motherboards with SATA ports that the BIOS can set to "Compatible" mode. Every time I switch to the ports to Native SATA (or "Enhanced IDE") or AHCI modes in the BIOS (regardless of the Intel chipset I use), UNIATA blue screens during the boot process. Very frustrating.

Thanks in advance.

Coming across this discussion a bit late, but the problem you describe is likely due to a bug with PCI bus enumeration in NT 3.51 and 4.0's SCSIPORT.SYS component that often surfaces on relatively modern chipsets. Bearwindows describes it here:

https://bearwindows.zcm.com.au/winnt351.htm#18

and has fixes available here: https://bearwindows.zcm.com.au/scsifix.rar. As far as I can tell, Microsoft never addressed this bug in a Knowledge Base article nor fixed it in any NT 4.0 hotfix. Would you believe that only a single byte of executable code in SCSIPORT.SYS (plus the header checksum) needed to be patched to fix this? (Suffice to say it's straightforward enough to fix it yourself in other builds of the file using a hex editor and checksum utility.)

Also, UniATA's AHCI compatibility is a bit buggy. The 0.47 release fixed a bug where attempting to do a full/non-quick format of a partition on an AHCI drive would hang, but the latest 0.47b release still causes the system to hang if you attempt to retrieve a drive's SMART status with SIV or another utility, and attempting to run a program directly from an AHCI optical drive apparently triggers data corruption (causing the program to hang or crash when starting). "Native" SATA (or "ATA"/"Enhanced IDE") mode is problem-free in my experience (with NT 4.0), and may perform just as fast, so I recommend using it instead on systems that offer it.

Beginning with 0.47, Alter apparently migrated his build environment to WINE on Linux, and this apparently messed up the packaging part of the build process as the root "Release_Dist" folder in the RAR package now contains a bunch of extraneous and outdated files compared to the earlier releases (and broke the TGZ packaging altogether). Make sure you use the INF file in the appropriate OS subfolder (NT351/NT4/2K/etc.), not the ones in the root folder. I reported this along with the AHCI bugs in an email to Alter a couple of years back, but he didn't respond; hopefully he'll eventually fix them in a future release.

I think NT 3.51's text mode installer has some issues. I originally tried loading UniATA driver via F6 but never succeeded that way. You need to manually slipstream uniata.sys, change related SIF files to include UniATA and make sure that driver will get loaded (that is, without specifying "noload").

If you configured the setup files correctly you'll see UniATA automatically gets picked as the driver for your controllers.

I'm not sure about AHCI, as I configured my system as IDE for better compatibility with DOS and others. It may be relevant for more modern systems on which IDE is no longer available.

NOTE: DO NOT USE the official 0.47 driver builds. They import symbols not present on NT 3.51 thus text-mode setup will consider the driver "corrupted". 0.46e8 is the last known good version that can be used out-of-box. If you want to use 0.47 check the attachment in my previous posts.

LSS10999 wrote on 2024-01-15, 02:48:

I think NT 3.51's text mode installer has some issues. I originally tried loading UniATA driver via F6 but never succeeded that way. You need to manually slipstream uniata.sys, change related SIF files to include UniATA and make sure that driver will get loaded (that is, without specifying "noload").

Early revisions of NT 4.0 have a bug where the floppy drive is inaccessible on later Intel chipsets, at least with a large (>256 or >512 MiB) amount of memory installed, thus breaking the F6 setup feature. I think KB article 268830 is the relevant one; it specifically mentions Intel 810e, 815, and 830 motherboards but I've personally encountered this bug on much later (Core 2 era) hardware. I would suspect the same is true for NT 3.51, and am not sure off-hand if it was ever fixed for that OS. (I only have experience installing/using NT 4.0 on bare metal.) Building a custom CD with UniATA slipstreamed is indeed a good workaround. (In the case of NT 4.0, at least, I personally view making a CD with just the SP6a files and a patched SCSIPORT.SYS slipstreamed (and loading UniATA the official way from a floppy) as enough to make life easier when installing on newer hardware—provided said hardware includes a standard floppy drive, of course.)

Thanks for sharing your NT 3.51-compatible build of UniATA 0.47b, by the way. I'd guess the compatibility was another thing broken when Alter migrated his build environment.

Hey, can anyone make a full detailed video about installing UniATA?

Whenever I try to install UniATA it simply gives me a bluescreen or it doesn't install at all.

Or else can we install UniATA using VirtualBox (or) VMware?

This is the only option for me, However, I tried installing Windows 2000 on my old business PC which is HP SFF-8300 it works with Windows 2000 when I emulate Sata as IDE.

But when I install UniATA, it starts to give me a bluescreen. I need to install UniATA because I want to use Windows 2000 on my Gigabyte B450 Aorus Pro WIFI Motherboard.

Bluescreen: Inaccessible Boot Device

Please Help Me.

A little maybe off-topic bug I found out about NT 3.51's disk capability.

It seems NT 3.51 simply doesn't understand LBA extended partitions. As such, even with the FAT32-enabled fastfat, you cannot access any logical partition created inside such extended partitions. Primary partitions are fine.

On the other hand, Disk Administrator would show everything it doesn't know as "Unknown", including automatically assigned FAT32 partitions. LBA extended partitions are also presented as a big Unknown without its contents.

EDIT: Some other bugs.

1. It seems copying files, especially with folders, using File Manager, can sometimes end up bugged, with the copied files being inoperable. Copying the same files again would usually fix them. I wonder if this was the "corruption" issue some people were talking about back in the days. In any case, take care when copying stuffs inside NT 3.51.

2. Probably due to the above issue, the dialog for replacing existing driver files when installing sound drivers appears to be broken, with "New" option often silently fail to replace existing driver files, leading to unexpected results. So it is advised to delete whatever related driver files before installing drivers to avoid issues, particularly with drivers reporting the files "may be missing" due to using a DLL incompatible with NT 3.51, which I'll explain later.

3. Looks like audio drivers that can actually work on NT 3.51 turned out to be very uncommon. Not many manufacturers actually targeted Windows NT 3.51, and while NT4 shared the same driver model as the older NT, there's a notorious breakage among those from several manufacturers -- _alldiv. I once looked into the driver binaries of several vendors (via IDA or Ghidra) and found especially the DLL part contains procedure that "divides something by 10000", leading to the import of _alldiv if not explicitly targeting NT 3.51. It's advised to actually check the driver sys and dll files with Dependency Walker before actually installing them, as if the DLL part was indeed importing those incompatible symbols, you'll encounter the the driver files "may be missing" error, and you most likely will need to delete the old files before installing a correct version (if exists).

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.