What does InstallDriver.exe do -specifically?

[cappy2112]

Hello,

I've been reading through older posts on this forum, before posting my message, trying to get a feel for what kinds of problems people
are having on Windows systems, with the inpout32/inpoutx64 DLLS.

I came across this post which refers to InstallDriver.exe
viewtopic.php?t=444

Specifically what does this install program do? Does it make any changes to the registry?

The reason I am asking is that we have been using this program where I work- simply by copying the DLL to the C:\Windows directory,
and it has allowed us to write to the parallel port.

Thanks

[phil]

I think I just answered this in reply to your other post, but basically it loads the driver (inpoutx64.sys).
The driver is an embedded resource in the DLL (source code all on the website).
The DLL installs the driver at runtime, but requires admin (elevated) permissions.

InstallDriver.exe is a simple exe that loads the DLL and requires admin/elevation (UAC prompt) so that it ensures the driver is loaded.
Once the driver is loaded, it will be in device manger under what used to be called legacy devices/hidden devices (you need to turn on show hidden devices) but I'm not sure what the section is called these days on Win10/11, maybe "Other devices".

As for registry changes, well yeah of course to install a driver in Windows means changes to the registry, but no more than any other program running InpOut32 (in admin mode) would do. You cant install drivers without changes in the registry, and you cant use InpOut32 at all without the driver... so... yeh it changes the registry!

[cappy2112]

Having used inpout32.dll since the early 2000s, I’ve never seen the .sys file nor install driver.exe, and have been writing to the parallel port from an application.

Where can I get those missing files?

[phil]

If its working (or partially working), then no need to run installdriver.

Like I said, the driver (.sys) is embedded INSIDE the DLL. The DLL installs extracts and installs the driver whenever it is loaded.
You wont see it unless you go looking for it (it should be somewhere under system32\drivers once installed I think).
So as long as your application that uses the DLL has run (at least once) as admin (elevated) you don't need installdriver.

But you can find the files in the download package (binaries only) on the website!
InstallDriver.exe is in the 32bit folder (it will run on x64 or x86 systems and install the rele4vant driver!), Again you wont see the .sys file unless you look in the DLL resources - as its an embedded resource file.

[cappy2112]

If its working (or partially working), then no need to run installdriver.

Windows 10 is the most problematic OS from Microsoft. As of recently, we are seeing blue screens when we exit our application (but only on some systems), but haven't been able to isolate the problem.

The error code refers to "an IRQ" issue though, which makes me think that having the dll properly installed along with the registry change, might be a good idea. I wasn't aware of the registry change until your previous reply.

Also, our application hasn't been run at an elevated level, because windows allowed us to run it that way, and writing to the parallel port works.
Our application writes to the parallel port about 45,000 times in 6 days. That may not look like it would cause a problem, but we don't work for microsoft.


thanks

[phil]

If it manages to write at all (using InpOut32/x64) then the driver is there (as are the registry things).
It wont do any harm to run InstalDriver.exe but I suspect also it wont make any difference.

The last time I actually used this project myself (other than the odd little test), Windows 10 didn't event exist. And if you think 10 is bad, just wait till 11 (lol).

Not much more I can suggest, as I said, InpOut32 is legacy and I am not putting any time/effort into it (I didn't write it after all, just ported the Logix4U (who does not appear to exist anymore) code to x64 many years ago). I do not have the capabilities to support it (as an individual developer I can not even purchase the driver signing certificates required, even if I could justify the $400+ to do so) so its pretty much a dead project. Someone here said they had created a new version of it in 2021, but I don't know how reliable that is (presume its all open source as I think he linked to the github page).

Any IO stuff I do these days myself is either via USB attached devices or on dedicated hardware (Arduino or Pi).

[cappy2112]

Not much more I can suggest, as I said, InpOut32 is legacy and I am not putting any time/effort into it (I didn't write it after all, just ported the Logix4U

Our application is 32-bit (we are in the process of migrating it to 64-bit), however we are running on Windows 10 64-bit.
Elsewhere in this forum, I read that if the application is 32-bit, then it must load the 32-bit DLL.

I haven't actually tried loading the 64-bit dll, but I will follow the rules until we fully migrate to 64-bit land.

Thanks for all of your input

[phil]

Our application is 32-bit (we are in the process of migrating it to 64-bit), however we are running on Windows 10 64-bit.
Elsewhere in this forum, I read that if the application is 32-bit, then it must load the 32-bit DLL.

Correct. 32bit applications work with the 32bit DLL (they can not load 64bit DLLs at all)
64 bit applications can not load 32bit DLLs so must load the 64bit (x64) DLL.

However, the 32bit DLL has to install and use a 64bit driver on 64bit (x64) Windows, or the 32bit driver on 32bit (x86) Windows (Windows drivers must match the 'bitness' of Windows itself). So the 32bit DLL has two version of the driver, 32bit and 64bit embedded and it chooses which to install at runtime based on the current Windows architecture.

The 64bit DLL only has the 64bit driver, as it can not be used on 32bit (x86) windows.

NOTE: If you use .NET, which can run in "ANY CPU" mode it will also choose at runtime to use x86 or x64 (in that case, you need to work out which is the correct DLL to load at runtime (I think the example do this) or just force the .NET compiler to output x86 or x64 explicitly.

[cappy2112]

Our application is 32-bit (we are in the process of migrating it to 64-bit), however we are running on Windows 10 64-bit.
Elsewhere in this forum, I read that if the application is 32-bit, then it must load the 32-bit DLL.

Correct. 32bit applications work with the 32bit DLL (they can not load 64bit DLLs at all)
64 bit applications can not load 32bit DLLs so must load the 64bit (x64) DLL.

However, the 32bit DLL has to install and use a 64bit driver on 64bit (x64) Windows, or the 32bit driver on 32bit (x86) Windows (Windows drivers must match the 'bitness' of Windows itself). So the 32bit DLL has two version of the driver, 32bit and 64bit embedded and it chooses which to install at runtime based on the current Windows architecture.

The 64bit DLL only has the 64bit driver, as it can not be used on 32bit (x86) windows.

NOTE: If you use .NET, which can run in "ANY CPU" mode it will also choose at runtime to use x86 or x64 (in that case, you need to work out which is the correct DLL to load at runtime (I think the example do this) or just force the .NET compiler to output x86 or x64 explicitly.

Do you know what the name of the registry entry will be after running InstallDriver?
I've searched for inpout32 before and after running it, there was no entry in both cases.
What is the purpose of writing to the registry?

Thanks

[phil]

Do you know what the name of the registry entry will be after running InstallDriver?
I've searched for inpout32 before and after running it, there was no entry in both cases.
What is the purpose of writing to the registry?

Thanks

No, sorry not something I know (nor have any control over), but the purpose (is clear isn't it) is to install the driver in windows.
All that stuff is in the registry somewhere! At a quick guess, it will be under HKLM\system\CurrentControlSet\ somewhere.
But as I don't have InpOut32 installed, I cant quickly search for it it. It's all done by the WIndows driver installation calls, nothing that InpOutxxx has any control over directly.

I guess if you use install driver on a fresh system with something like ProcMon to monitor all registry calls you can find it, if you really need to. But you don't need to do you, because if the driver is installed, you know it worked - and if you can call the driver without error to read/write, you know it worked... (even if it only works 1% of the time).

[cappy2112]

don't need to do you, because if the driver is installed, you know it worked - and if you cant call the driver without error to read/write, you know it

I want to know how the registry is being used and why due to a recent problem we have been seeing related to writing to the parallel port.
Since we haven't used (and didn't know about) installdriver.exe, the missing write(s) to the registry might help us understand the problem we are seeing.

[phil]

No, I think you are completely missing what I am trying to say!

• InstallDriver.exe DOES NOT WRITE to the registry itself, nor does the DLL nor does the driver.
• Windows itself does the registry writes when installing the driver!
• InstallDriver.exe is a very simple C/C++ stub program that simply loads InpOut32/x64.DLL.

When the DLL loads, the first thing it does (in DllMain :: DLL_PROCESS_ATTACH) is try and open the driver. If it fails to open the driver (most likely because it has not yet been installed) it will call the DLL function inst64() or inst32() (depending on the Windows platform) which in turn will extract the relevant driver embedded resource file and store it in c:\windows\system32\drivers\[inpout32.sys (Windows x86) or inpoutx64.sys (Windows x64)] and then call the Windows API to install said driver (which requires admin permissions to succeed and does any registry writes associated with installing drivers).

InstallDriver.exe then calls IsInpOutDriverOpen()...

Code: Select all

BOOL bResult = IsInpOutDriverOpen();

... to verify if the driver was successfully installed an opened and presents a message saying it was successful or unsuccessful!
The whole source file for installdriver.cpp is only 35 lines long, most of which is boilerplate, not rocket science, and the source for the DLL is reasonably easy to follow too - not too much in there. The driver source is small and reasonably simple, but compiling it and signing it is a different matter!

So, you don't *need* to do any of that with InstallDriver.exe so long as something (your program) has triggered the DLL to install the driver (by loading the DLL) and at the time that was done it was done with enough privileges for Windows to install the driver (maybe you launch your program from an installer the first time it runs for example).
Loading the DLL by any means at any time will do the same thing as InstallDriver.exe (without the confirmation message that it was installed or not) but does require admin privileges to successfully install the driver if it is not already installed. So ALL InstallDriver.exe does (other than the 35 lines described above) is turn on the flag in the manifest file to FORCE it to ask (popup the UAC window) for admin privileges if they are not available to the user by default in the current session.

If you have opened (loaded) the DLL and managed to call any of the API functions to read/write a port then the driver IS installed and the registry entries will have been written to do that.

Moving forward, the whole point about this being open source, is that ALL of the source code is available available on my website for anyone to study and see what is going on.

It's been over 10 years since I last looked at it in any detail, but doing so just now I was able to give you the above information in a few minutes as there is so little there. Perhaps for clarity you could have a look through that to see exactly what it does (and does not do). I'm not sure if you are familiar with C and C++ or not but even if not it should be fairly self explanatory to anyone dealing with writing hardware at a low level!

NOTE: The DRIVER source code and DLL source code + the InstallDriver.exe source code are separate links on the website.

TLDR I don't think the use (or lack of use) of InstallDriver.exe will make any difference to your problem.

Regards
Phil

[cappy2112]

No, I think you are completely missing what I am trying to say!

• InstallDriver.exe DOES NOT WRITE to the registry itself, nor does the DLL nor does the driver.
• Windows itself does the registry writes when installing the driver!
• InstallDriver.exe is a very simple C/C++ stub program that simply loads InpOut32/x64.DLL.

When the DLL loads, the first thing it does (in DllMain :: DLL_PROCESS_ATTACH) is try and open the driver. If it fails to open the driver (most likely because it has not yet been installed) it will call the DLL function inst64() or inst32() (depending on the Windows platform) which in turn will extract the relevant driver embedded resource file and store it in c:\windows\system32\drivers\[inpout32.sys (Windows x86) or inpoutx64.sys (Windows x64)] and then call the Windows API to install said driver (which requires admin permissions to succeed and does any registry writes associated with installing drivers).

InstallDriver.exe then calls IsInpOutDriverOpen()...

Code: Select all

BOOL bResult = IsInpOutDriverOpen();

... to verify if the driver was successfully installed an opened and presents a message saying it was successful or unsuccessful!
The whole source file for installdriver.cpp is only 35 lines long, most of which is boilerplate, not rocket science, and the source for the DLL is reasonably easy to follow too - not too much in there. The driver source is small and reasonably simple, but compiling it and signing it is a different matter!

So, you don't *need* to do any of that with InstallDriver.exe so long as something (your program) has triggered the DLL to install the driver (by loading the DLL) and at the time that was done it was done with enough privileges for Windows to install the driver (maybe you launch your program from an installer the first time it runs for example).
Loading the DLL by any means at any time will do the same thing as InstallDriver.exe (without the confirmation message that it was installed or not) but does require admin privileges to successfully install the driver if it is not already installed. So ALL InstallDriver.exe does (other than the 35 lines described above) is turn on the flag in the manifest file to FORCE it to ask (popup the UAC window) for admin privileges if they are not available to the user by default in the current session.

If you have opened (loaded) the DLL and managed to call any of the API functions to read/write a port then the driver IS installed and the registry entries will have been written to do that.

Moving forward, the whole point about this being open source, is that ALL of the source code is available available on my website for anyone to study and see what is going on.

It's been over 10 years since I last looked at it in any detail, but doing so just now I was able to give you the above information in a few minutes as there is so little there. Perhaps for clarity you could have a look through that to see exactly what it does (and does not do). I'm not sure if you are familiar with C and C++ or not but even if not it should be fairly self explanatory to anyone dealing with writing hardware at a low level!

NOTE: The DRIVER source code and DLL source code + the InstallDriver.exe source code are separate links on the website.

TLDR I don't think the use (or lack of use) of InstallDriver.exe will make any difference to your problem.

Regards
Phil

Go it, thanks!