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 Yesterday, 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 Yesterday, 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 Today, 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 Yesterday, 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 Today, 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 Today, 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! 😁