Moving from PortTalk to InpOut32

[karinK3UU]

I am removing PortTalk code from an application I previously had running on a Windows XP machine. It worked OK for me on that machine. I have recently migrated over to a new machine running Windows 11. I have downloaded and installed Visual Studio 2022. I have migrated the source code from my old project over to VS2022. It upgraded the code all Ok, and I was able to compile successfully the basic code. I am now in the process of installing two parallel port PCIe and PCI cards. The parallel port PCI card is identified correctly as LPT1 in Device manager and it functions to output signals using another software application which I did not write. That application uses InpOut32 for access to the parallel port.
Initially when testing MY code with the parallel port PCI card I could not get it to work with my software using PortTalk. I don't know this to be true, but I am assuming that PortTalk will not work with a Windows 11 machine. I don't know for sure. So in the process of trying to the parallel port card working I am modifying my code to use InpOut32 since it seems to work with the other application. My question is related to some of my required modifications to my code. Using the example code for InpOut32 I was able to compile it successfully and it does run, Beeper and all. Windows 11 assigns very large port numbers to the parallel ports (ie:0xDFE8 for LPT1). Looking at the source code for the example, in the [DllImport("inpout32.dll")] sections, for the Inp32 and Out32 functions, which I assume are used to either input or output data to the parallel port, the PortAddress is defined as a signed short variable. Why is this??????? Also because the Windows 11 address for LPT1 is a 32 bit number shouldn't InpOut32 use a different type for the variable?? In fact all of the functions in the example code use "short" for the variables. Since I can't have access to the DLL unless I recompile from the source code this seems to be a stumbling block for me. Any help would be appreciated.
Regards,
Karin Anne Johnson

[phil]

Sorry, I ported InpOut32 to x64 many many years ago. I did not write it so I can tell you why whoever wrote it decided to use signed shorts.
I haven't got the time, reason, or ability to maintain/modify InpOut32 - In order to build the driver, you need a driver signing certificate which is only available to legally registered companies (not hobbyists) and it not exactly cheap either! So InpOur32 is basically a dead project and has been for years). Of course, the source code is available for anyone to use/change as they wish etc. I'm a little surprised it still works with Windows 11 TBH (what with all the new driver security and all that).

However when I ported InpOut32, I also added the calls from DLPortIO which was an alternative DLL that some other software used - so I made InpOut32 compatible with DLPortIO calls (and I'm fairly sure that wasn't limited to signed short (but I could be wrong). Should all be there in the DLL interface header file!

But hold on a second.. You may still be able to use the signed short version, after all, 0xDFE8 is still only 16bit number so it will fit - it just depends what is done inside - which of course you could check as easily as I could)

[karinK3UU]

Hello Again:
Interesting observation. I am using Visual Studio 2022 Professional to compile the Example code. In the Properties for the project if I select "AnyCPU" in the Build/General/Platform target section. I get errors when the program runs. Specifically in the Beep function at line 241. "System.BadImageformatException"
On the other hand if I chose "x86" in the Build/General/Platform target section the code runs fine.
any suggestions. Or maybe I should not be too worried.
I am trying to understand the operation of the DLL and the required resources so that I can do a pretty big re-write of some code that used to use PortTalk.

Karin

[karinK3UU]

I think I the Example app figured out. Since my LPT1 address is not of the "short" type the only option is to use the Read LONG button. If I enter 57320 (which is decimal for hex 0xDFE8) then use Read LONG the value returned in the text box is decimal, which is equivalent to the value of the bits in the LPT1 port data register.
This seems to work fine. I am using Doug Brown's parallel port tester program to set and reset various bits and the Example program running in Debug mode in VS2022 returns the correct values. But now I have a problem
If I try to use the Write LONG button I cannot access the LPT1 port to change values. The bits in the LPT1 data port do not change value.
Karin

[phil]

If I recall correctly, there is a long standing bug in the long call inside the driver itself. I can not fix it as I don't have the ability to sign the driver even if I wanted to! A search of the forums should find more info.

But you seem to have missed/conveniently ignored my comment that I can not support this old project.
Do you really want to port code over to a dead library?? Unless you are willing to fix the issues in the driver and rebuild/re-sign it I really don't see the point of continuing with this rather ancient port InpOut32?

Regarding the .Net AnyCPU/X86/X64 options - you need to write the interop code in .Net to call the correct DLL (x86 or x64) for the bit-ness you are running. I think there are some examples of that. I was fairly sure my .net samples did handle that but they were written in VS 2005/2008 era ! As I said, its been many years since I even looked so I could be wrong.

[karinK3UU]

OK fair enough.
I do understand, I'm sort of grasping at straws here.
I do need to find an application that will allow me Read and Write to parallel ports.
The application that Doug Brown wrote "Parallel Port Tester" seems able to both read and write to my parallel ports, both of them. And I believe that he has his code using InpOut32. I don't know how he is doing it.
Also another application I have uses InpOut32 also and that works OK too. So there must be a workaround
for it.
I realize that you are far removed from this project, Phil.
Thank you for your time.

I will try to search around the internet to see if there is an application more current that will me access to the parallel ports using PCI and PCIe cards.
Thanks for your time.

Karin

[phil]

Good luck - maybe you could get in touch with Doug? It must be possible with InpOut if that is what he is using - maybe he can advise how he is able to write to the higher address ports?

Id be a bit wary still of relying on InpOut32 with the driver requirements of Windows getting tighter every release, it surely cant be long before it will fail to load the driver without it having a newer signature - but maybe I'm wrong. I haven't used it myself for years now (and when I did it wasn't for parallel ports but setting custom (completely weird) baud rates on serial ports lol). I pretty much keep the website and these forums up for others really (and because I use them for my other software that does not need drivers). If I could get hold of a driver signing certificate then maybe I would update it (although even getting it to build with the newest DDK could be a problem).

[karinK3UU]

A bit of feedback.
Thank you so much Phil for your time.
It made a world of difference in providing some much needed motivation on my part to solve my issues.
The solution was staring me in the face all the time. When I was creating a Visual Studio solution, it was creating a different name for InpOut32 DLL. I did not see this at first then, I was not including the real DLL in the program path. On top of that the issue of writing to ports some how got fixed, probably because I was not calling the correct code. Anyway all is well here.

Thanks so much again.

Karin Anne Johnson