SweetLow wrote on 2025-11-20, 13:20:

red-ray wrote on 2025-11-20, 13:05:

So if the NVMe9x driver supported IDE Passthrough then SMARTVSD should work.

My friend, they are DIFFERENT Passthroughs 😀 The first as I said is IOR_IDE_PASS_THROUGH request available for .PDR (native for Windows 9x) type of storage drivers only and unavailable for *.MPD without help of additional VSD layer driver. The second is NT specific IOCTLs like IOCTL_IDE_PASS_THROUGH. And the third is SCSI SAT. And the SMARTVSD "knows" about the first only.

red-ray wrote on 2025-11-20, 14:50:

My reading is that the SMART reporting program does SMART_RCV_DRIVE_DATA + IDE_COMMAND_IDENTIFY/IDE_COMMAND_SMART to SMARTVSD which then does the IOCTL_ IOR_IDE_PASS_THROUGH to the vendor supplied driver.

Again I was and am asking if I make calls to SMARTVSD will these get passed down to the NVMe driver as IOR_IDE_PASS_THROUGH and if not why not/do you plan address this?

If this was the situation then ALL programs that report SMART via SMARTVSD should "just work" with NVMe drives. That said using ATA SMART on NVMe drives is not ideal, it would be far better to use NVMe SMART. This is easy enough on NT, but I do not know how this would be done on W9x, I guess ASPI32, but I have never programmed for ASPI32 and as AFAIK it's not there by default so would prefer not to use it.

SweetLow wrote on 2025-11-20, 20:43:

@red-ray >IOCTL_IDE_PASS_THROUGH >do the IOCTLs
May be you don't understand well, but NT IOCTL interface does NOT work on Windows 9x. That's why I said "NT specific". So no matter what you know about NT - all you knowlege your knowledge has zero meaning for Windows 9x. Am I clear enough now? You can use SMARTVSD interface and ASPI32 interface under Windows 9x and that is all available for user mode apps.

Yes, it's clear you can't address specific statements without making incorrect assumptions and going off at a tangent.

He already said that works only for *.PDR type drivers and not *.MPD. It's in the very post you quoted.

SweetLow wrote on 2025-11-20, 13:20:

unavailable for *.MPD without help of additional VSD layer driver.

maxtherabbit wrote on 2025-11-23, 23:55:

He already said that works only for *.PDR type drivers and not *.MPD. It's in the very post you quoted.

Yes and no, for all I know he could have an "additional VSD layer driver"

Release:

https://github.com/LordOfMice/Tools/blob/master/nvme9x.zip
https://github.com/LordOfMice/Tools/blob/master/nvment.zip
https://github.com/LordOfMice/Tools/blob/mast … /nvme2k-src.zip

readme:
NVMe driver for Windows 9x.

Base: nvme2k 1.0.0.2 https://github.com/techomancer/nvme2k
Changes: Port for Windows 9x, 64-bit LBA & Fixes

1. Generic
- added SCSI 64-bit LBA commands processing (large drives support).
Tested on Windows 9x ONLY
- fixed controler shutdown code
- speed up of command queueing and it is less CPU consuming
- fixed enormously low speed or false positive errors on executing
of large size requests
- various code rectifications

2. Windows 9x specific
- port with 2 bug fixes
- install script nvme9x.inf written

Install and uninstall as usual hardware, nothing specific.

red-ray wrote on 2025-11-23, 20:50:

Again I was and am asking if I make calls to SMARTVSD will these get passed down to the NVMe driver as IOR_IDE_PASS_THROUGH and if not why not/do you plan address this?

I assume you still underestimate who am I and so don't hear my answers. Althought googling immediately will give this knowlege for you.
User-mode:
https://github.com/LordOfMice/Tools/blob/master/aspiinfo.zip
- ASPI32 using
https://github.com/LordOfMice/Tools/blob/master/atainfo.zip
- SMARTVSD using
https://github.com/LordOfMice/Tools/blob/master/devsize.zip
- your lovely NT IOCTLs

all written more than decade ago

And now the MAIN, kernel-mode species (not all, of course):
https://github.com/LordOfMice/Tools/blob/master/atanames.zip
- IOR_IDE_PASS_THROUGH using
https://github.com/LordOfMice/Tools/blob/master/ramdrv4m.zip
- one of the two .PDRs written in the last decade
http://sweetlow.orgfree.com/download/esdi_506.zip
- IOR_IDE_PASS_THROUGH implementation
http://sweetlow.orgfree.com/download/smartvsd.zip
The most interesting thing for you - I know how this code works because I read and changed it even.

SweetLow wrote on 2025-11-24, 07:17:

I assume you still underestimate who am I and so don't hear my answers. Althought googling immediately will give this knowlege f […]
Show full quote

red-ray wrote on 2025-11-23, 20:50:

Again I was and am asking if I make calls to SMARTVSD will these get passed down to the NVMe driver as IOR_IDE_PASS_THROUGH and if not why not/do you plan address this?

I assume you still underestimate who am I and so don't hear my answers. Althought googling immediately will give this knowlege for you.
User-mode:
https://github.com/LordOfMice/Tools/blob/master/aspiinfo.zip
- ASPI32 using
https://github.com/LordOfMice/Tools/blob/master/atainfo.zip
- SMARTVSD using
https://github.com/LordOfMice/Tools/blob/master/devsize.zip
- your lovely NT IOCTLs

all written more than decade ago

And now the MAIN, kernel-mode species (not all, of course):
https://github.com/LordOfMice/Tools/blob/master/atanames.zip
- IOR_IDE_PASS_THROUGH using
https://github.com/LordOfMice/Tools/blob/master/ramdrv4m.zip
- one of the two .PDRs written in the last decade
http://sweetlow.orgfree.com/download/esdi_506.zip
- IOR_IDE_PASS_THROUGH implementation
http://sweetlow.orgfree.com/download/smartvsd.zip
The most interesting thing for you - I know how this code works because I read and changed it even.

Too much information! I overestimated your ability to give a simple answer to what I feel is a simple question about SMARTVSD support for nvme9x NVMe drives on W9x .

All I am asking is when a utility reads SMART (DeviceIoControl() SMART_RCV_DRIVE_DATA + IDE_COMMAND_IDENTIFY/IDE_COMMAND_SMART) on W9x via SMARTVSD will this work for nvme9x NVMe drives? If not will you be fixing this? If not then I probably won't bother to get SIV to report them on W9x.

I only ever meant to ask about W9x and never intentionally mentioned NT, it's you that keep bringing up NT and mudding the waters, why?

I have almost zero knowledge of W9x driver development and zero interest leaning how to develop W9x drivers. I am way more interested in getting NVMe2K working on XP-64 and Itanium, I have built the drivers and now just need to update then test the .INF file. I may even try and get it working on my PowerPC given an NVMe drive shows up on it's PCI bus, strangely the PCI to PCIe bridge does not.

All the drivers I was paid to develop are WDM and KMDF drivers for Windows 2000 and later. Obviously developed the SIV driver which runs well on NT 3.51 and later and includes support for PowerPC + Alpha + Itanium in addition to the expected x32 and x64. I Microsoft Windows Hardware Compatibility sign the x32 + x64 drivers which AFAIK meet all the latest Windows 11 recommendations/requirements such as having 4KB section alignment, using NonPagedPoolNx on W10 and later from 13-Dec-2021, use MmMapIoSpaceEx() when it's available (Threshold and later) from 13-Jul-2022, etc.. I am considering making a Microsoft Windows Hardware Compatibility signed NVMe2K driver publicly available, but before I did this I will need to be 100% sure that it too meets all these requirements.

Note: I too can easily post way more information than is helpful!

@red-ray
>All I am asking is when a utility reads SMART (DeviceIoControl() SMART_RCV_DRIVE_DATA + IDE_COMMAND_IDENTIFY/IDE_COMMAND_SMART) on W9x via SMARTVSD will this work for nvme9x NVMe drives?
I already gave you more generic answer - no one .MPD driver works. Other participant extracted info from my answer and gave this you too. And you continue to ask already answered question. Too much information!

>If not will you be fixing this? If not then I probably won't bother to get SIV to report them on W9x.
No. But you (traditionally) ignored the second interface that i recommend you too - ASPI32. Althougth this is about passing SCSI requests directly to driver.

>I only ever meant to ask about W9x and never intentionally mentioned NT
Of course you mentioned (no matter intentionally or not, I can't read your mind). I quoted NT references that you did few times.

My previous question may have been drowned out, so I hope nobody minds me asking this again:

How feasible would it be to add support for the NVMe revision 1.3 features that would make the driver more virtualization-friendly, specifically support for (shadow) doorbell buffers?

From what I understand this feature would make Windows clients with this driver perform optimally in VMs.

Thanks again for all your efforts working on this!

digger wrote on 2025-11-24, 10:49:

My previous question may have been drowned out, so I hope nobody minds me asking this again: […]
Show full quote

My previous question may have been drowned out, so I hope nobody minds me asking this again:

How feasible would it be to add support for the NVMe revision 1.3 features that would make the driver more virtualization-friendly, specifically support for (shadow) doorbell buffers?

From what I understand this feature would make Windows clients with this driver perform optimally in VMs.

Thanks again for all your efforts working on this?

This is posssible probably, but your request is TOO early. Usually you get PoTC, then make it stable and widened to maximal area, then start to add new features (and your feature is restricted as it is applicable not for all cases). I suppose we are in second stage.

SweetLow wrote on 2025-11-24, 11:01:

This is posssible probably, but your request is TOO early. Usually you get PoTC, then make it stable and widened to maximal area, then start to add new features (and your feature is restricted as it is applicable not for all cases). I suppose we are in second stage.

Fair point. Glad to know that this is probably possible to add in a future version, once the basic functionality has been implemented. Thanks.

If my feature request came off as impatient, it's just the enthusiasm about the fact that these drivers are being developed. Really happy that you guys are working on this! 😁

red-ray wrote on 2025-11-24, 00:25:

SweetLow wrote on 2025-11-20, 13:20:

unavailable for *.MPD without help of additional VSD layer driver.

maxtherabbit wrote on 2025-11-23, 23:55:

He already said that works only for *.PDR type drivers and not *.MPD. It's in the very post you quoted.

Yes and no, for all I know he could have an "additional VSD layer driver"

I don't buy it. I went back and checked your original response to that post:

red-ray wrote on 2025-11-20, 14:50:

SweetLow wrote on 2025-11-20, 13:20:

red-ray wrote on 2025-11-20, 13:05:

So if the NVMe9x driver supported IDE Passthrough then SMARTVSD should work.

My friend, they are DIFFERENT Passthroughs 😀 The first as I said is IOR_IDE_PASS_THROUGH request available for .PDR (native for Windows 9x) type of storage drivers only and unavailable for *.MPD without help of additional VSD layer driver. The second is NT specific IOCTLs like IOCTL_IDE_PASS_THROUGH. And the third is SCSI SAT. And the SMARTVSD "knows" about the first only.

Yes and so what? *snip*

Either you misread sweetlow's post and are now saying it was ambiguous to save face, despite asking for no specific clarification in your first reply, or you did understand it and are choosing to be combative for fun, which is it?

digger wrote on 2025-11-24, 10:49:

My previous question may have been drowned out, so I hope nobody minds me asking this again: […]
Show full quote

My previous question may have been drowned out, so I hope nobody minds me asking this again:

How feasible would it be to add support for the NVMe revision 1.3 features that would make the driver more virtualization-friendly, specifically support for (shadow) doorbell buffers?

From what I understand this feature would make Windows clients with this driver perform optimally in VMs.

Thanks again for all your efforts working on this!

It would require probably more uncached extension ram. Very low on my list of priorities but if anyone takes a stab and sends a merge request, contributions are always welcome.

Tested the NVMe 9x drivers on an AM4 B550M AORUS ELITE - everything works fine so far. I’m curious whether they’ll finally work on my AM5 X670 board, since earlier versions definitely didn’t.

On the same B550M, I also tried a PCIe-to-IDE adapter with a JMicron JMB368 (previously shown in this Windows Me on Ryzen 9900x video).

The IDE controller was detected perfectly in Windows 98 with no errors. This doesn’t happen on other configurations, where the card only works via INT 13h/BIOS. I’m assuming it works cleanly here because I used a 120 MB WD Caviar IDE drive from 1992, which doesn’t use DMA.

@SweetLow — sorry for the delay. I put the drive in a “safe place” and then forgot where that was. 😀

Attached is the IDENTIFY DEVICE dump. I’m wondering if this could be used to trick WDCTRL.386 in Windows 3.x.

I ran an x64 NVMe2K on Windows 11 26H1 just to see what would happen, it all started so well, but..., I tried again and this time W11 played nicely

Native NVMe

It does OK on Vista-x64.

OMORES wrote on 2025-12-03, 20:04:

Tested the NVMe 9x drivers on an AM4 B550M AORUS ELITE - everything works fine so far.

You should try the SIV Menu->File->Transfer Rate with 4 x 32MB transfers and a Transfer Count of 14. Set it up, press [Save] then [ OK ] finally press [ Do Bytes ], this is what I did below.

With the very latest NVMe2K it works well on W2K-x32 + WXP-x32, 2003/XP-x64 still have issues, it's pretty good on Vista-x64 + W7-x64. The W7-x64 is PCIe 1 x4.

You can also see NVMe SMART is working well. The driver is M$ Signed and I don't know why W7 thinks otherwise, NVMe2Kx64.sys must be otherwise it would never load, W11 + W10 say it is M$ Singed.

The ideal test for W7-x64 would be to hit it with 64 x 128 MB, but my system only had 8GB so I settled for 48 x 128 MB

OMORES wrote on 2025-12-03, 20:04:

Tested the NVMe 9x drivers on an AM4 B550M AORUS ELITE - everything works fine so far.L.386 in Windows 3.x.

red-ray wrote on 2025-12-03, 21:07:

You should try the SIV Menu->File->Transfer Rate with 4 x 32MB transfers and a Transfer Count of 14. Set it up, press [Save] then [ OK ] finally press [ Do Bytes ], this is what I did below.

Oops, Menu->File->Transfer Rate does not work on W9x/WMe as it uses overlapped I/O which I just discovered only works on COM ports.

It was easy enough to fix, but as overlapped reads are not possible on W9x/WMe I had to limit the transfer depth to 1, but at least it should work from SIV V5.85 Beta-02.

1. Why is the W9x NVMe2K driver so much slower than the WXP NVMe2K driver when running of the same hardware?
2. Does W9x driver report ATA SMART via SMARTVSD? If not will it be updated to do this and if so when?
3. Note the NVMe drive is PCIe 3 x4 and connected via a PCI-66 to PCIe 1 x1 bridge.

Do any of you know how likely the NVMe2k driver would be to work with ReactOS? And if it does, perhaps the ReactOS developers might be open to including it in the OS distribution?

And if it doesn't (yet) work, perhaps they can figure out which improvements need to be made to the OS to allow the driver to work with it?

digger wrote on 2025-12-04, 15:26:

Do any of you know how likely the NVMe2k driver would be to work with ReactOS? And if it does, perhaps the ReactOS developers might be open to including it in the OS distribution?

And if it doesn't (yet) work, perhaps they can figure out which improvements need to be made to the OS to allow the driver to work with it?

It is a question for ReactOS devs. I was always discouraged from trying ReactOS because it is kind of picky about which hardware it runs on. If they want to include nvme2k in their project they have my blessings.

0xDEADBEEF wrote on 2025-12-04, 15:59:

It is a question for ReactOS devs. I was always discouraged from trying ReactOS because it is kind of picky about which hardware it runs on. If they want to include nvme2k in their project they have my blessings.

Interesting. There is an existing (closed) issue on the ReactOS Jira site (CORE-16363) with the request to integrate another open source Windows NVMe driver into ReactOS.

It's some kind of reference driver published years ago by the OpenFabrics Alliance. The original Subversion repo page returned a 404, but it's still mirrored on GitHub.

Are you aware of these driver sources? Would any of those source be useful for improving the NVMe2k driver? Does it have a license that's compatible with NVMe2k? From what I can make out from the headers of the source file, it's a basic permissive license that looks like the 2-clause BSD license, but I'm not sure.

The ReactOS Jira issue was closed, because they couldn't get the driver to work. However, the people who responded in the ticket showed an openness to revisiting the request once it can be made to work. I'd like to create an issue to consider NVMe2k for inclusion in ReactOS, but I don't currently have a Jira account there. Maybe I can request one.

Maybe this is old information for you and you actually used these existing sources as a basis for NVMe2k and NVMe9x, but I'm sharing this info here, just in case.

These pages provide some additional information about the OpenFabrics NVMe driver:

• https://winraid.level1techs.com/t/win-10-stan … e-drivers/31599
• https://nvmexpress.org/open-fabrics-alliance- … ecember-8-2014/