Would NTVDMx64 stop a USB driver from working correctly?

[FlexMcMurphy]

I successfully installed NTVDMx64 using the compiled version from the columbia.edu link (dated 13/Jan/2022).

It runs my 16-bit DOS application just fine in Windows 10 64-bit (21H1) which is very cool. However, the DOS app also needs a HASP HL Basic USB dongle to enable full functionality in the app. I have tried installing the latest drivers from the dongle vendors website but am unable to get the dongle to function and give full functionality to the DOS app.

From what I can tell that dongle driver is designed to work in Win 10 64-bit. I tried asking for support from the dongle vendor but they directed me to the DOS program vendor but they don't support this ancient program anymore. So I am out of ideas about what to try.

Is there any chance that NTVDMx64 might somehow be blocking the dongle driver?

Cheers,

Flex

[leecher1337]

It's not that NTVDMx64 blocks anything, but I think on x64, the HASP installer i.e. doesn't add the VDD NTVDM driver necessary to support the HASP-calls (and maybe other things, I cannot check this, as I don't have any dongles). As a first step, you can add the HASP VDD to the list of VDDs to load in NTVDM by adding HLVDD.DLL to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\VirtualDeviceDrivers\VDD. If you don't have any other VDDs in this key, you can use the attached .reg file to do this: hlvdd.zip

Hope that helps

Btw., when adding VDD driver on my test machine (and also when installing the dongle driver on a real 32bit machine), I do get the following error message when starting up DOS after a timeout of approx. 30 seconds:

As this also happens on a 32bit machine, I guess this is dues to the fact that I don't have a dongle or something like that and it may not happen on your machine.

[Nable80]

Hi! I also have an application that requires one of these dongles and a few years ago I tried to make it work under Win7 x86 with all updates. No luck: newer HASP drivers lack VDD component (and corresponding code in kernel driver, IIRC), old ones trigger BSODs and/or just don't work. This driver is a pile of highly-problematic stuff (with questionable code quality), especially its legacy part that emulates LPT dongle for DOS applications (it messes a lot with internal NT structures and unpredictably breaks when updates are installed), so it was deprecated for reason.

The best solution is to use a WinXP machine to make a dump of your dongle (it's possible for old HL dongles and it's known for decades) and to use a well-known software emulator. Your lawyer may be unhappy (although this is legal in some countries, especially if you don't distribute results) but using software under unsupported OS and building ntvdm using the leaked sources is questionable too, I guess it's not a concern for you but I should warn anyway.

[leecher1337]

I too think that emulating the dongle is the cleanest/easiest solution that would cause you the least amount of pain. It also ensures that you have a backup when your dongle becomes bad (they sometimes die and some greedy vendors refuse to send you a replacement, even when you send the original back to them to prove that it went bad). You do physically have the dongle as a proof of license anyway. I also once had an application with one of these dongles, emulating it was just a matter of reading the dongle and patching sproRead and sproFindFirstUnit function calls, iirc. I didn't have an dongle emulator back then, but it was just a matter of patching a few lines of assembly code.

[FlexMcMurphy]

Thank you both!

@Nable80 Are you saying that most likely @leecher1337 method won't work? If as you say the newer HASP drivers lack VDD component well then maybe this method won't work? Apparently I will need to use the latest HASP driver I linked to above because it was created to make HASP dongles work again after a recent Win 10 update somehow broke their functioning in Win 10. But I'm happy to try this method if it might work.

But I checked just now and I already have: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\VirtualDeviceDrivers\VDD in my registry. It has type: "REG_MULTI_SZ" and has "No Value" but I see your .reg file does have a value. Where does that value come from? I can try that when I'm back at work.

I have actually gone down the emulator road a few years ago and got my HASP HL dongle working with an emulator (multikey32) in XP... except the DOS program would crash every now and then so I didn't really trust the set up so we just kept using the actual dongle in Win 7 32-bit. In fact the dongle does work in Win 10 32-bit also with a HASP driver from 2006!

But now anyway we really want to move our Operating Systems to Win 10 64-bit and I have not been able to find an emulator that works on it. I tried getting the multikey64 emulator working but the devcon.exe was not able to install the driver and I was not able to sign the driver so it gave me a BSOD when I ran this command bcdedit /set loadoptions DDISABLE_INTEGRITY_CHECKS & bcdedit /set testsigning on and tried to manually install it.

If either of you could help me get my dongle emulated somehow with an emulator or in code on Win 10 64-bit that would be amazing. I have extracted the dongle password already. I used three different tools to do that and they each gave the same result so that part is done at least and I can easily follow any other instructions you might have? If you want to switch to PM/email that's all good with me.

Hope to hear from you!

Flex

[Nable80]

Are you saying that most likely @leecher1337 method won't work? If as you say the newer HASP drivers lack VDD component well then maybe this method won't work? Apparently I will need to use the latest HASP driver I linked to above because it was created to make HASP dongles work again after a recent Win 10 update somehow broke their functioning in Win 10. But I'm happy to try this method if it might work.

AFAIR, the latest driver works only with Win32 applications and lacks VDD components (Aladdin couldn't make it work with updated OS, so they just dropped it). I do remember I read a discussion about it but I don't have a link now, maybe I didn't save it. Upd: I'm speaking about 32-bit driver here, because I'm sure that 64-bit kernel driver doesn't have any interface for VDD at all, it's a different driver and its authors couldn't expect ntvdm x64 to exist. Try to list named pipes with WinObj or any tool like this, try to compare what you see under 32-bit and 64-bit OS when HASP driver is installed. HASPVDD.DLL depends on \\.\HASP and won't work if it's absent. Oh, and there's some difference between HLVDD.DLL (HardLock) and HASPVDD.DLL, different types of keys and I don't remember which one is older and was deprecated first.

I have actually gone down the emulator road a few years ago and got my HASP HL dongle working with an emulator (multikey32) in XP... except the DOS program would crash every now and then so I didn't really trust the set up so we just kept using the actual dongle in Win 7 32-bit.

I tried DOS-based emulator only: (c)1998 by MeteO This author has also published some articles about this topic.

In fact the dongle does work in Win 10 32-bit also with a HASP driver from 2006!

Old driver may work somehow but it's 32-bit and you can't load it into a 64-bit kernel, it assumes different layout of system structures. Btw, I'm curious why does it work under Win10 while even Win7 SP1 had BSODs with it, maybe we were trying different driver versions and some of them work better…

Btw, what do you think about running an old OS in a VM and using USB pass-through (or emulator)? What makes you update OS while keeping the old application? People with old industrial apps usually run them on air-gapped (or at least properly firewalled) PCs with an OS that is never updated (they say, don't fix what isn't broken). It can't be explained by security measures, OS updates can't fix bugs in old applications. So, what makes you update the OS instead of keeping a working solution (and moving it into VM when old hardware can't be repaired anymore, although it's hard for me to imagine this kind of situation)?

[leecher1337]

The VDD component (the HLVDD.DLL) gets installed with the installer provided in the link above, it's just that the value doesn't get added to the VDD key by the installer on 64bit, so all you have to do is to add it there, as I described, then the VDD component will load in NTVDMx64, I verified that. I just couldn't verify if it works correctly, because I don't have any dongle available at the moment.

But as nable80 pointed out, it could be that the interface of the VDD is a dead end, as there is no kernel component to talk to, so you need to try it out.

But I checked just now and I already have: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\VirtualDeviceDrivers\VDD in my registry. It has type: "REG_MULTI_SZ" and has "No Value" but I see your .reg file does have a value. Where does that value come from? I can try that when I'm back at work.

The VDD key gets created by NTVDM installer. All VDD extensions need to register with this key (as they do on original NTVDM). The installer on 64bit doesn't exepect that there is a NTVDM available, so it doesn't add its VDD component there (but luckily installs the VDD to SysWOW64 directory anyway). My .reg just contains the string HLVDD.DLL with a terminating \0 in the end (when manually entering in regedit, jsut ensure that you do a CR at the end of the String, this wil lgenerate the \0 terminator).

[leecher1337]

I just looked at uclhasp.zip @Nable80 mentioned and it comes with complete source code. That's good because problems can be tracked down, just in case, if you may need to emulate the dongle.

[FlexMcMurphy]

Btw, I'm curious why does it work under Win10 while even Win7 SP1 had BSODs with it, maybe we were trying different driver versions and some of them work better…

@Nable80 My DOS app runs on Win 10 32-bit. If you like I can send you on the driver to try if you have a HASP HL Basic dongle as well. I also got the DOS app running in a Virtualbox Win 10 32-bit guest on a Win 10 64 bit host and maybe that is the best solution although I think technically speaking you are meant to pay a license fee for the Extension pack. Did you post then take down a file called: uclhasp.zip? Might be helpful to me..

@leecher1337 I'll use your hlvdd.reg file and see if the dongle works with it, I won't be able to try until later today. If it doesn't work I'd like to try the emulator route. I think this site explains how to digitally sign a driver properly which I wasn't doing before, although it looks like Windows needs to be left in "Test Mode" which doesn't sound ideal.

Do you guys know if that driver I linked above is a kernel-mode or user-mode driver?

Cheers,

Flex

[leecher1337]

The dongle emulator Nable80 mentioned can be found here: http://www.woodmann.com/crackz/Tools/Dongles/Uclhasp.zip I just wanted to place a hint on how to find the mentioned emulator.

Test signing of the dongle emulator driver should work in Test signing mode. Signed some drivers myself, it's not a big problem, but your Windows has to run in Test signing mode in order to load the driver. I can play around with it (and compile the emulator driver for 64bit), if you want, but only after you can confirm that it doesn't work with the real driver, otherwise, it's useless work.

Update: I wonder why this emulator even is a kernel mode driver. Imho, with some work, this could be transformed into a usedmode VDD as well.

[leecher1337]

One thing that would be interesting: Is there a DOS-side driver for the Hasp VDD on the 32bit Machines where the dongle is working? I don't see any in the installed package. Can you post your Windows\system32\config.nt from one of the machines where the driver is working here in order to check if there is a DOS-side device driver?

[FlexMcMurphy]

Hi again,

Well I got the dongle and tried it with the DOS application but unfortunately it didn't work. Here are the things I tried:

I tried with two drivers:

1. Sentinel HASP/LDK Windows Command Line Runtime Installer 8.31 KB0018319 As of March 2022 this is the most recent driver recommended to use with Win 10.
2. Version 4.102.5.22 (January 2006) called hdd32.exe Currently I am using this driver and it makes the dongle work with my DOS app running on Windows 7 32-bit.

I tried installing the first driver from command line (which includes legacy support for older HASP dongles) and I merged the VDD reg file (from post 2 above) into the registry on win 10 64-bit installed bare metal. Unfortunately it didn't work. The Dos app would start but not get full functionality from the dongle. I tried a few reboots and cli driver re-installs to no avail.

I then uninstalled this latest driver and rebooted and then tried installing the hdd32 driver on the laptop running Win 10 64-bit bare metal. That old (2006/2007) driver is meant to work on 64 bit OSs but I'm pretty sure it won't work on recent Win 10 64-bit releases because the thalesgroup website that make drivers now for hasp dongles talk about needing latest drivers to get the dongles recognized in Win 10. Anyway what I saw was a pop up error message: 16-bit MS-DOS Subsystem hlvdd.dll. An installable virtual device driver failed DLL initialisation. Choose Close to Terminate the application. Then I had the option to "Close" or to "Ignore" Choosing close indeed shutdown the DOS app but choosing Ignore just made the pop up go away... the DOS application kept running but the dongle was not giving it full functionality.

I also have another laptop with the same DOS app. This laptop instead has Win 10 32-bit bare metal install. On this laptop I repeated the above two steps and got the same result with each driver... EXCEPT... on Win 10 32-bit installing the older hdd32.exe driver caused a BSOD every time... @Nable80 had mentioned this above. Actually as a third test I also installed the first driver above (in command line mode) on that Win 10 32-bit bare metal laptop and also merged that VDD registry file but still the dongle did not give full functionality to the DOS app.

Something frustrating and confusing for me was because in yet another test I DID manage to install that hdd32.exe driver in Win 10 32-bit running in a Virtualbox VM running on a Win 10 64-bit host. And my DOS app DOES run in that VM and get full functionality from the dongle. So why does the driver install in THAT Win 10 32-bit running in a VM and not give a BSOD but does not install when it is installed in Win 10 32-bit bare metal??

On further inspection I might have two slightly different Win 10 32-bit versions, because they look a bit different..

One I got using the 32-bit version of the Windows Media Creation Tool Version = "10.0.10240.16392" which could be an early Win10 build?? In which case maybe I should anyway NOT be using that version at all?

The other is also a 32-bit and I got it directly from the MS Win 10 download site. Version 10.0.19044 Build 19044

Maybe there is a difference between these in terms of compatibility with the old hdd32.exe driver?? It works on the older Win 10 32-bit build.

Another thing I did a bit differently the first time I installed that hdd32.exe driver (in the VM) was I right clicked on it and installed in Compatibility Mode so it installed with compatibility with Windows XP Service Pack 3. But I didn't do that on the first attempt on the Win 10 32-bit bare metal install. But another issue is that I cannot uninstall the hdd32.exe driver from the Win 10 32-bit bare metal install. If I go to Add/Remove programs it says something about... UNWISE,exe cannot find install.log I did a system wide search and there is NO install.log.

So I'm quite confused and getting a bit fed up with this now! Should I stick with the Win 10 32-bit version: 10.0.10240.16392 because it looks like I can use the hdd32.exe driver with it. I could try installing that build again bare metal. Or is it maybe too old?

I would still prefer a solution that just runs on the latest build of Win 10 64-bit for maximum security and longevity of support.

Sorry for the long post but I wanted to report all my findings! Any more ideas much appreciated.

Flex

[leecher1337]

Thanks for your detailled tests. Correct me, if I'm wrong but in conclusion we can say that:

1) The Sentinel HASP driver doesn't give full functionality to DOS programs, as it works neither on 32bit nor on 64bit versions correctly. So it's not useful. 2) The HDD32 driver does work at least on 32bit Windows, but only up to a certain Windows build, on builds above, it gives a BSOD and crashes.

Regarding Sentines HASP problem: Did you check what I previously posted, if there is a DOS .SYS driver being loaded in config.nt on the systems where you got it running successfully? Maybe the .SYS driver just isn't shipped, but necessary to provide DOS with suport for the VDD..?

Regarding BSOD: Usually, you get some Minidumps on BSODs when Windows that get collected in WINDOWS\Minidump directory in form of a .dmp file. You can send me such a dump file (Minidumps usually are small, so you can attach it here or send it via e-mail). Using WinDbg, I can analyze the stack trace of the crash, maybe this sheds some light on why it crashes on your machine.

Regarding uninstallation: Maybe it searches for C:\WINDOWS\SYSTEM32\HDD32.LOG which gets created by the installer. You can try to uninstall it by running: C:\Windows\System32\UNWISE.EXE C:\Windows\System32\HDD32.LOG

Does the BSOD happen already after installing the driver or does it crash upon access of the Dongle via your DOS application? Just asking, if I would be able to reproduce the crash without your application.

[leecher1337]

Update: From what I can see, you have a HASPDOS.SYS driver in your working installation. I also checked the HASPVDD.DLL of the Sentinel HASP driver (Option 1) and it has a compatible interface. So I suggest that you

1. Install the Sentinel HASP driver from the Sentinel HASP/LDK Windows Command Line Runtime Installer 8.31
2. Apply my .reg Patch to register the HASPVDD.DLL
3. copy the HASPDOS.SYS from your previous installation the Windows\syswow64 directory
4. Add the following line to config.nt file in SysWOW64: device=%SystemRoot%\system32\haspdos.sys

Maybe that's sufficient to get it working.

Technical background: A Virtual Device Driver for NTVDM usually consists of 2 components. One is a DOS-Level .SYS driver that provides an interface, usually via an Interrupt handler. In its dispatch routine, it BOPs out to the VDD driver via a well defined interface asking the VDD to accomplish a certain operation. The VDD is a DLL that gets loaded by the NTVDM on startup and contains a dispatch routine that gets called by the DOS driver. If either of the 2 components is missing, it's usually not working, if the VDD needs to dispatch i.e. DOS interrupts. So it would be somewhat logical if it doesn't do anything useful without the DOS .SYS driver that installs the handler routine.

[FlexMcMurphy]

Hi Leecher,

I jumped the gun a bit too quickly this morning and have already started to install that Win10 32-bit Version = "10.0.10240.16392" to see if the hdd32.exe driver installs on it bare metal and not only when that OS version was installed in a VM. So I have lost any minidumps I was getting yesterday. They were only happening in the 32-bit bare metal install. I can go back and install that other version later if needed. The BSOD was happening right when trying to install the HDD32 driver.. sometimes there was an error mentioning something about the HASPVDD.DLL file.

Regarding your two points above I'm confirming now if the hdd32 driver will install on Win 10 32-bit bare metal "10.0.10240.16392". But I think this is an early Win 10 release the Media Creation tool managed to download for me and maybe it makes no sense to use it because if connected to the internet it will probably just update itself possibly to a Win 10 version that the dongle will no longer work in anyway. However it could have value as an OS in a VM that is set up to not have internet access...

The Sentinel HASP driver.. AFAIK it should work on Win 10 and I don't understand why not except maybe as you say it's because the haspdos.sys file was not getting loaded. I will try that later today.

Regarding haspdos.sys: on a PC that the HDD32 driver and the dongle is working on haspdos.sys was stored in C:\Windows\system32\haspdos.sys and I got config.nt from C:\Windows\System32\config.nt. Where should haspdos.sys go on a new test system, in Windows\syswow64 directory or again in Windows\System32 ?

By the way, you were right, there is a hdd32.log file but it is in the C:\Windows\syswow64 directory... yesterday I tried installing the hdd32 driver on a laptop running Win 10 64-bit... and it didn't make the dongle work (not too surprising) but here is the output from C:\Windows\syswow64\hdd32.log... except that where ever the log file says C:\Windows\System32 the files (e.g: dll) were actually saved to C:\Windows\syswow64 So I guess from now on I can run the hdd32 uninstaller with something like C:\Windows\syswow64\UNWISE.EXE C:\Windows\syswow64\HDD32.LOG Maybe hdd32 driver thinks its installing on a 32-bit system? But the release notes for it say it is compatible with 64-bit OSs also... well back in 2007 it was!

***  Installation Started 03/09/2022 19:58  ***
Title: HASP Gerätetreiber Installation
Source: C:\haspdrivers\HASP4_driver_setup\hdd32.exe | 01-21-2010 | 15:08:12 | 5095398
File Overwrite: C:\Windows\System32\UNWISE.EXE | 07-26-2002 | 17:02:06 | | 153088 | 5be5019b
RegDB Key: Software\Microsoft\Windows\CurrentVersion\Uninstall\HASP Device Drivers
RegDB Val: HASP Device Drivers
RegDB Name: DisplayName
RegDB Root: 2
RegDB Old: HASP Device Drivers
RegDB Key: Software\Microsoft\Windows\CurrentVersion\Uninstall\HASP Device Drivers
RegDB Val: C:\Windows\System32\UNWISE.EXE C:\Windows\System32\HDD32.LOG
RegDB Name: UninstallString
RegDB Root: 2
RegDB Old: C:\Windows\system32\UNWISE.EXE C:\Windows\system32\HDD32.LOG
Non-System File:
File Overwrite: C:\Windows\System32\hinstd.dll | 12-20-2006 | 11:55:08 | 4.102.5.22 | 3066968 | f94b2531
Non-System File:
File Overwrite: C:\Windows\System32\haspds_windows.dll | 12-20-2006 | 10:00:16 | 5.22.1305.1 | 2511360 | 17c99ec9
Non-System File:
File Overwrite: C:\Windows\System32\hdinst_windows.dll | 12-20-2006 | 10:00:20 | 5.22.1306.1 | 671112 | 95ecc819
Non-System File:
File Overwrite: C:\Windows\System32\hasp_inst_help1.dll | 11-30-2006 | 11:06:00 | 1.0.0.0 | 69632 | ed273ed8
Non-System File:
File Overwrite: C:\Windows\System32\hdduinst.exe | 09-06-2005 | 17:07:32 | | 24576 | 8263eeeb
RegDB Key: Software\Microsoft\Windows\CurrentVersion\Uninstall\HASP Device Drivers
RegDB Val: HASP Device Drivers
RegDB Name: DisplayName
RegDB Root: 2
RegDB Old: HASP Device Drivers
RegDB Key: Software\Microsoft\Windows\CurrentVersion\Uninstall\HASP Device Drivers
RegDB Val: C:\Windows\system32\UNWISE.EXE C:\Windows\system32\HDD32.LOG
RegDB Name: UninstallString
RegDB Root: 2
RegDB Old: C:\Windows\System32\UNWISE.EXE C:\Windows\System32\HDD32.LOG
Execute Path: C:\Windows\system32\hdduinst.exe
User Rights: Admin

Lastly, for completeness and in case it is any help. After I installed the Sentinel drivers (from command line) on a laptop with Win 10 64-bit bare metal and with the HASP key inserted I ran the driver again because there is a switch where it will show you what driver files are loaded. This is a screen shot of what it gave me back:

I did the same thing on another computer that had Win 10 32-bit (21H2 build)... with the sentinel driver installed and the hasp key inserted this is what I got:

In both cases that Sentinel driver was not giving full functionality to the DOS App.

Thank you!

Cheer,

Flex

[FlexMcMurphy]

I just got done installing that ?older Win10 32-bit, Build: "10.0.10240.16392". when I then try to install hdd32 driver on it I didn't get a BSOD this time but got this error message. After that the installer still completed and said it installed successfully. This exact Win 10 version installed in a VM did not give any error when I installed the hdd32 in it and the dongle works in that VM.

Update

Apologies, the issue here was I had not enabled the NTVDM feature... I ran DISM /online /enable-feature /all /featurename:NTVDM from powershell as Admin, ran the hdd32 installer again and this time it installed without error.

Have not been able to test the dongle with this bare metal install yet. Will report back later.

[FlexMcMurphy]

Sorry @leecher1337

Just to clarify... @Nable80 mentioned above there is a difference between HASPVDD.DLL and HLVDD.DLL. The dongle I am using is a HASP HL Basic. I don't think HASPVDD.DLL comes with the Sentinel 8.31 driver but rather HLVDD.DLL which is shown in my screenshot from two posts up.

On a (32-bit) system with the dongle working using the HDD32 driver there is: C:\Windows\system32\HASPVDD.DLL

When I install the Sentinel 8.31 driver I get: C:\Windows\sysWOW64\HLVDD.DLL

Should I register HASPVDD.DLL in the registry or HLVDD.DLL as before? Does the dll need to be in C:\Windows\system32 or C:\Windows\sysWOW64?

Regarding haspdos.sys: on a PC that the HDD32 driver and the dongle is working on haspdos.sys was stored in C:\Windows\system32\haspdos.sys and I got config.nt from C:\Windows\System32\config.nt. Where should haspdos.sys go on a new test system with the Sentinel driver installed, in Windows\syswow64 directory or again in Windows\System32 ?

Cheers,

[leecher1337]

The Sentinel HASP driver.. AFAIK it should work on Win 10 and I don't understand why not except maybe as you say it's because the haspdos.sys file was not getting loaded. I will try that later today.

That would be really interesting, because call interface looks like it could work.

Regarding haspdos.sys: on a PC that the HDD32 driver and the dongle is working on haspdos.sys was stored in C:\Windows\system32\haspdos.sys and I got config.nt from C:\Windows\System32\config.nt. Where should haspdos.sys go on a new test system, in Windows\syswow64 directory or again in Windows\System32 ?

To clearify on System32 vs. SysWOW64: On a 32 bit System, there only is \System (16bit) and \System32 (32bit) On a 64 bit system, there is \System (16bit, not used), \SysWow64 (32bit) and \System32 (64bit)

Like in the registry, there is a file system redirection going on. If you launch a 32bit on 64bit Windows, it will see \SysWow64 as its \System32 directory. This is so that 64bit applications don't need to be adapterd to use yet even another directory, but can find their 64bit DLLs etc. in the well-known System32 directory. A 32bit Application also doesn't have to care, because it finds all its 32bit DLLs in the System32 directory, which in reality is the SysWOW64 directory in the file system.

As NTVDM is a 32bit application, all stuff has to go into SysWOW64, inclusing the .sys driver and the .dll and config.nt, autoexec.nt etc.

I hope this clears up the confusion about these directories and also clearifies you other question

[leecher1337]

To show the differences between HASPVDD.DLL and HLVDD.DLL, here is my technical analysis of both drivers :

HASPVDD.DLL uses the device driver \.\HASP to communicate with the kernel mode driver. HLVDD.DLL uses the device driver interface \.\FEnteDev to communicate with the kernel mode driver.

HASPVDD.DLL is plain simple, it more or less pipes through the calls to the IOCTL-Interface of the driver. (Altough this is only done in the CALLNEWVDDHASP function, which doesn't get used, the function CALLVDDHASP, that gets used, uses ReadFile() for communication and prepares the input buffer in some way.) It only supports function calls where DX register is 1:

  if (getDX() == 1 )
  {
    CALLVDDHASP(MGetVdmPointer(getDI() | (getES() << 16, getCX(), 0), 0);
    if ( fReadResult )
    {
      setCF(0);
      setCX(dwReadBytes);
    }
    else
    {
      setCF(1);
    }
    result = 1;

The HLVDD.DLL also is able to process calls with DX = 1 but wraps them to its other driver and is way more complicated:

API_DLL(MGetVdmPointer(getDI() | (getES() << 16, 256, 0));

And API_DLL function does more than just piping through to \.\HASP, as it uses a different kernel mode interface. So the question is if the FEnteDev offers HASP compatibility or not. That was the reason why I was interested if just using the DOS driver might be enough, or if there are functional differenced between both dongle drivers.

Regarding your question which one to reigster in VDD key:

When using Sentinel, use the supplied HLVDD.DLL When using HDD32 (I'm still not sure if it really works on 64 bit Windows), use the supplied HASPVDD.DLL Never use both at the same time. Both may require to load HASPDOS.SYS

[FlexMcMurphy]

As NTVDM is a 32bit application, all stuff has to go into SysWOW64

I'm sorry @leecher1337 but I'm confused. Do you mean NTVDMx64 which I thought was a 64-bit app?

Compared to yesterday, is todays goal to see if the Sentinel 8.31 driver will work but with the HASPDOS.SYS file included? And I am going to do this test with the DOS app running on a Win 10 64-bit machine with NTVDMx64 installed and the dongle connected?

If that is correct so far then are these steps also correct?

1. Register HLVDD.DLL in the registry.
2. HLVDD.DLL, HASPDOS.SYS and config.nt all go in C:/Windows/SysWOW64
3. Add a line in config.nt device=%SystemRoot%\SysWOW64\haspdos.sys
4. I thought the Sentinel 8.31 driver puts lots of things in C:/Windows/system32 ? Does that stuff need to be moved to sysWOW64 as well?
5. Anything else?

Thanks!

[leecher1337]

As NTVDM is a 32bit application, all stuff has to go into SysWOW64

I'm sorry @leecher1337 but I'm confused. Do you mean NTVDMx64 which I thought was a 64-bit app?

No, NTVDMx64 is a 32bit executable running on 64bit Windows.

Compared to yesterday, is todays goal to see if the Sentinel 8.31 driver will work but with the HASPDOS.SYS file included? And I am going to do this test with the DOS app running on a Win 10 64-bit machine with NTVDMx64 installed and the dongle connected?

If that is correct so far then are these steps also correct?

Correct!

1. Register HLVDD.DLL in the registry.
2. HLVDD.DLL, HASPDOS.SYS and config.nt all go in C:/Windows/SysWOW64

Yes, HLVDD.DLL should already be there, placed there by the Sentinel installer. config.nt is also already there, placed there by NTVDMx64 installation HASPDOS.SYS has to be copied there, as it doesn't get installed by Sentinel installer, as it seems.

3. Add a line in config.nt device=%SystemRoot%\SysWOW64\haspdos.sys

Not quite... Should be device=%SystemRoot%\System32\haspdos.sys (Keep in mind that NTVDM.EXE is a 32bit application, so redirection is being performed)

4. I thought the Sentinel 8.31 driver puts lots of things in C:/Windows/system32 ? Does that stuff need to be moved to sysWOW64 as well?

As far as I know it only communicates with the device driver interface of the driver ( .\FEnteDev), so no need to move files around.

5. Anything else?

Not yet, for a simple setup to try if just DOS driver was missing, this setup is enough.

[FlexMcMurphy]

I tried all the steps in previous message (on Win 10 64-bit with the Sentinel 8.31 driver) but unfortunately it doesn't work. The light is coming on in the dongle but it is not giving full functionality to the DOS app.

However, I tried again with a Win 10 32-bit install and the Sentinel 8.31 driver and the dongle is functioning. Just like @Nable80 predicted.

At this point I'm still disappointed because I was really hoping to have the DOS app running on Win 10 64 bit and not need to have extra Virtual machine setups and more un-necessary licenses.

Thank you,

Flex

[leecher1337]

So you say that it works on Win 10 32bit with Sentinel 8.31 driver? Does the Sentinel 8.31 driver place the haspdos.sys driver in config.nt on installation? If so, is it the same driver that you copied from the old machine or tried on x64? It could be that the 64bit Sentinel Kernel mode driver doesn't support the HASP calls, of course. But it would be interesting if the Sentinel 8.31 does install some DOS based handler or not.

[leecher1337]

Aaah, ok, I missed this "-ld" switch when testing my installation, which is the legacy device stuff you were mentioning. I cannot try it out without a dongle attached, but maybe I can at least check if it at least does something and I could compare the drivers from 32bit and 64bit installation, if there is a difference.

[Nable80]

There was a feature called "XP mode" in Win7 (Virtual PC software + WinXP image which didn't require any separate licenses), is there anything like this in Win10? I thought they care about backward compatibility a lot.

You can also use FreeDOS in VM + HASP emulator if your application can run under FreeDOS or some freeware DOS clone.

Btw, I didn't mention uclhasp.zip, I didn't remember the archive name at that moment. Today I looked for it and found that my archive is called haspx010.zip (FYI: CP866 encoding is used there), it seems to be older (1997 vs 1999) and contents are different but it was enough for me when I needed it several years ago. Thank you very much for mentioning uclhasp.zip, it provides even more information and such historical artifacts are always charming me. I don't know if I can help somehow but I'm thinking about it.

[leecher1337]

Ah, thanks for mentioning haspx010, thats also an interesting archive including sourcecode. Unfortunately, uclhasp and haspx010 are both only for MEMOHASP, not for HardLock, so I don't think it can be used for the application mentioned here, but it's still interesting to see all these HASP variants and old emulators. :)

Virtualization is always possible, but integration into an existing infrastructure isn't as good as direct interaction with the host OS.

[FlexMcMurphy]

Thanks @Nable80 Nope, Win XP mode is not included in Win 10 anymore. I got the physical dongle working in Win XP and in Win 10 32-bit running in a VM but if it was possible the ideal solution would see the dongle working directly in Win 10 64-bit.. especially since NTVDMx64 allows the DOS app to run on that OS.

I might take a look at FreeDOS out of interest although the app needs to run from a network share and print to LPT ports and I would need to figure out the emulator bit.. so I'm back to that again!

Cheers,

Flex

[leecher1337]

Solved with haspnt64 driver