Serial unit missing

[PascalDragon]

I did not try to access I/O-ports concurrently via userport and programs running under ntvdm. I just observed that all old 16 Bit Programs (e.g. those compiled with Turbo Pascal 6 & 7 under Windows XP and TP6 & TP7 themselves are blocked when userport.sys has been started. They do not respond to keyboard or mouse with the exception of the close-window-button, just "hang" in the entry display.

I/O port are exclusive resources. So if userport.sys reserves them then NTVDM simply can't access them, because they're already in use.

I am using Windows 32-Bit (XP on 3 PCs and Win 7 on a netbook), Linux Mint 20 on a laptop and Windows 7 64 Bit on a quadcore desktop PC. I have no (serious) problems to access the Parallel port with userport.sys under Windows XP with programs written with FPC. I just want to access the parallel just as well on my "work-horse", the quadcore 64-Bit PC.
The initial question for the serial unit arose from my arrempt to communicate with a µP-board via V24, possibly as a work-around for the denied access to the parallel port.
I am using one of those ubiquitous PCI Parallel-Port boards from Sunix. They supply certified drivers for use as Printer Port (LPTxx). But these drivers do not allow transparent control or read-out of the data/control/status-port bit values. It is in principle all there, but you don't get it.
Printing is done on this PC via USB. The sytem does not use the parallel port if I do not define it as a another printer port. So there is no danger of collision with other processes on the PC. It is no security leak as I am the only user. So no reason at all to deny access. Sunix might as well supply a certified driver to access the ports in a way as was possible during DOS-times.

That's simply not how things work in modern operating systems. It doesn't matter whether you're the only user or not, it's simply a bad thing (TM) to provide direct, unrestricted hardware access and OSes need to provide for all users, not only you. Thus you need to use suitable device drivers that provide the access of the I/O ports from kernel space to user space through some controlled API. You'll probably have to check which ports your PCI card requires and then have those ports mapped by some utility like userport.sys or whatever (I've never used them so I can't comment how they need to be configured or used).

[kaimex]

Hi MarkMLI,
I will consider upgrading to the new FPC versions in the future. In some of my programs that are still undergoing "updates" now and then I will have to look after the special exception handling that depended on internal details of V2.6.0.
None of my Windows PCs is connected to the internet or other public access. I am the only user. So I cannot see any security risk by getting access on the bit-level to the I/O-lines of the parallel port.
It is really only a question of the extra money required to get a "trusted certificate".
I have just found the package "WinIo v3.0" on the hard disk of my "workhorse" PC. It seems seems that I actually did not yet try that one for "Direct Hardware Access" under 64-bit Windows although the author assures that it works.
He explains that 64Bit-Windows only load device drivers that come with a "code signing certificate". His WinIo64.sys  is, however, signed with a "self-signed certificate" and can only be used on Windows running in a special "test" mode (with boot option "TESTSIGNING ON").
So far I could not get comfortable with that approach.
As I already said once, Sunix supplies certified drivers for use as printer port, they might as well supply drivers that grant access to the ports on the bit level for the PC/electronics-hobbyists.
Regards
Kai

@PascalDragon: As I alread explained ALL programs running "with the help" of ntvdm are blocked in their initial display , whether they access ports or not . Even the old TP6 & TP7 compilers. That need not be so. It would be totally sufficient, that concurrent port access be blocked, but not any other program excecution.

On my PCs I am "all users" together with the system. So there is no reason at all to keep me from using a parallel port that I have plugged in for hobby purposes. And, by the way, nobody talks about security issues anymore, as soon as  I have a "trusted certificate" (other words for expensive) for a driver doing just that. 
Security arguments could not explain, why access is denied on 64Bit systems and allowed without extra certificates on 32Bit systems.

[MarkMLl]

That's simply not how things work in modern operating systems. It doesn't matter whether you're the only user or not, it's simply a bad thing (TM) to provide direct, unrestricted hardware access and OSes need to provide for all users, not only you.

Where "users" in this case includes all the background stuff of which an untutored owner is unaware.

Sorry OP: you either stick with old operating systems and risk being left in the cold due to lack of security patches etc., or you learn modern programming techniques. Simple as that.

MarkMLl

[PascalDragon]

I have just found the package "WinIo v3.0" on the hard disk of my "workhorse" PC. It seems seems that I actually did not yet try that one for "Direct Hardware Access" under 64-bit Windows although the author assures that it works.
He explains that 64Bit-Windows only load device drivers that come with a "code signing certificate". His WinIo64.sys  is, however, signed with a "self-signed certificate" and can only be used on Windows running in a special "test" mode (with boot option "TESTSIGNING ON").
So far I could not get comfortable with that approach.

On the one hand you say that you don't worry on security issues, but on the other hand you don't want to enable TESTSIGNING ON despite this being the standard approach when you have unsigned or self signed drivers...

As I already said once, Sunix supplies certified drivers for use as printer port, they might as well supply drivers that grant access to the ports on the bit level for the PC/electronics-hobbyists.

Then ask Sunix.

[MarkMLl]

Hi MarkMLI,
I will consider upgrading to the new FPC versions in the future. In some of my programs that are still undergoing "updates" now and then I will have to look after the special exception handling that depended on internal details of V2.6.0.

You should not be writing code that depends on internal details like that. PascalDragon will vouch for the fact that I've historically been tied to old OSes and hardware, so I feel I'm in a good position to tell you that. So BE TOLD (please :-)

None of my Windows PCs is connected to the internet or other public access. I am the only user. So I cannot see any security risk by getting access on the bit-level to the I/O-lines of the parallel port.
It is really only a question of the extra money required to get a "trusted certificate".
I have just found the package "WinIo v3.0" on the hard disk of my "workhorse" PC. It seems seems that I actually did not yet try that one for "Direct Hardware Access" under 64-bit Windows although the author assures that it works.
He explains that 64Bit-Windows only load device drivers that come with a "code signing certificate". His WinIo64.sys  is, however, signed with a "self-signed certificate" and can only be used on Windows running in a special "test" mode (with boot option "TESTSIGNING ON").
So far I could not get comfortable with that approach.
As I already said once, Sunix supplies certified drivers for use as printer port, they might as well supply drivers that grant access to the ports on the bit level for the PC/electronics-hobbyists.

With your level of expertise and understanding you should not be getting involved with that stuff. In particular, if something which you do is considered to be abusing a certificate you'll be very unpopular with just about everybody including your bank... do you want to be blacklisted because people think you're facilitating malware?

Get yourself e.g. a USB-connected interface card and use that, see e.g. https://hackaday.com/2018/02/21/linux-adds-ch341-gpio/ for which I believe Windows drivers are available, or learn to use an "Internet of Things" device... you'll still need to familiarise yourself with a library interface but you'll find people around here will do their best to help.

MarkMLl

[avra]

I'll check the other tools that you listed, whether one of those does the job.

https://github.com/changguangyu/DelphiMSR
Did you already check this one? That code has both 64bit and 32bit reported to work just 3 years ago. I know it's about MSR registers, but if you look at https://github.com/GermanAizek/WinRing0 it seams to support direct I/O port access too (like ReadIoPortByte) which you could try to add to DelphiMSR pascal wrapper.


Btw, do you know that you need to produce 64bit application to work with 64bit driver which (for some drivers) needs to be installed first? What exact FPC/LAZ version you use while trying 64bit windows driver to work?

[kaimex]

@avra:
No, I had not yet "heard" about DelphiMSR before.
The last thing that I tried was inpout32.dll & inpoutx64.dll in mid-May. And before that userport.exe/sys, which I am presently using successfully on an old Windows XP laptop (in conjunction with programs compiled by FPC v2.20 :-) ). On the 64Bit Windows 7 Home Pemium PC this does not work.
The inpout-package installs both dlls.
I have tested with FPC v2.6.0  using the FreePascal IDE for Win32, not with Lazarus.
I am not doing any 64-Bit programming.
My test program uses functions exported by inpout32.dll. An attempt to use those of inpoutx64.dll did not work at all.
The strange thing with the inpout32.dll functions is that I/O-writes & reads initially work but after a certain number of calls I get either error 216 (general protection fault) or error 217 (unhandled exception) or even other error numbers, that are not ducumented in FPC's list. The maximum number of calls I could make was something like 53, in the last program version it was only 21. Depends somehow on the program formulation. I could not reproduce the "53-case". In 2012 people reported that it works on Win64. So far I cannot confirm that for my system.

@PascalDragon:
The recommendation to ask Sunix for a driver appears inadequately unfriendly to me.
My positive approach to the desire to make parallel ports available for uses other than the classical printer connection would be to engage some knowledgeable people to write a suitable driver and gather money from the FPC community to be able to afford a signed/trusted certificate.

Regards Kai

[avra]

For the last time:

you need to produce 64bit application to work with 64bit driver

[kaimex]

Thank you for emphasizing that, but it is not in line with my intentions:
For my applications I do not need 64Bit programming/drivers.
I just need 32Bit drivers working on 64Bit Windows.
The 32Bit drivers written for Windows XP (and above but below Windows 7) do not work on 64Bit Windows due to the extra restrictons Microsoft has introduced.
May be it's just the missing certificate. That's why I am inclined to call that ransom.

Thank you for your valuable hints to other driver candidates that I might try.
Regards Kai

[Re-searcher]

@kaimex

Hi Kai,
Have also worked with serial and parallelport on pc with 8bit,16bit,32bit and 64bit

Go to the BIOS from your PC
Place the parallelport on bidirectional

I have found this  for you :

http://www.sunix.com/en/support.php?item=dd
https://drp.su/en/devices/chipset/sunix

good luck

Regards,
Erik

[PascalDragon]

The recommendation to ask Sunix for a driver appears inadequately unfriendly to me.

You were the one who was complaining that Sunix does not provide suitable drivers for direct port access. Well, they know their hardware and they are probably able to sign their drivers. So for me it is a logical step to at least ask them directly.

Thank you for emphasizing that, but it is not in line with my intentions:
For my applications I do not need 64Bit programming/drivers.
I just need 32Bit drivers working on 64Bit Windows.
The 32Bit drivers written for Windows XP (and above but below Windows 7) do not work on 64Bit Windows due to the extra restrictons Microsoft has introduced.
May be it's just the missing certificate. That's why I am inclined to call that ransom.

That has nothing to do with "restrictions Microsoft has introduced". Kernel mode code on a 64-bit OS can only run 64-bit code. Thus if you have a 32-bit driver that simply can not work. It's essentially as if you'd try to run ARM code on a x86. For user mode you can use 32-bit code, cause there the OS can switch that user task into a virtual 32-bit mode (it's more complex than that, but it sums it up rather well).
So, no, it's not "just the missing certificate". You need to use a 64-bit driver. There is no way around this.

(Though I do not agree with avra that a 64-bit user space utility is necessarily required; if the driver is designed correctly it can work with both 32- and 64-bit user space applications)

[kaimex]

Hi,
in the meantime I have tried the WinRing0 stuff that avra made me aware of.
It behaves very much similar to the inpout32.dll aproach:
Depending on details of the code I can make 25 (1 write, 2 reads) or 34 (1 write, 1 read) or 51 (1 write) read/writes to the data- and status-port of the parallel port (Base-address C010) until I get an "file not open" (5) or "file not found" (2) error. The behaviour also depends on whether debug-output ist written just by writeln or by "writeln(f," (where f has been created by assigncrt(f)) to the cmd-window.
It appears as if somebody in the background is counting IO-accesses as file-IO and lifts the stop sign after a certain number. Another strange thing is that after GetDllVersion & GetDriverVersion an attempt to output the result in hex format leads to a crash with error 217.
The same happens after reads to the base-address +1...7
So a little bit works, but it is not really usable.
So far I have no idea, how to get rid of the file-related crashes.
This test was done with the WinReg0.dll. I have put WinReg0.dll, WinReg0.sys, WinReg0x64.dll and WinReg0x64.sys into the application directory, without any further registration or installation.

@PascalDragon: Is a FPC 64 Bit version available that I could try to test your understanding of the subject ?

@Erik: Thank you for your hints. I'll look into that. I have read the Sunix information about installion as printer interface. There was a section about Multi-function-adapter, but not really helpful apart from this info : "LPT3, IO-range:C010-C017 & C000-C007". As far as I remember I could switch the data port from output to input already under inpout32.dll, but just as narrated above only for a limited amount of calls.

Regards Kai 

[jamie]

Limited calls to me sounds more like wrong calling convention or not handling the HANLDES to resource correctly..

[kaimex]

@jamie: I am just using the exported DLL-functions. There are no handles involved, that is buried in the Dll.

It is not clear to me. whether registration of the DLL might make a difference. The author of the package does not talk about that. He writes about a WinReg0.lib that is nowhere in the package nor on the GitHub DelphiMSR pages.

@Erik: I have looked into the 2 Sunix-links. Their driver-package has no driver for my card.
It seems to be an (PAR)4008T ver 2.1 with a SUN1888 chip, several (or more :-) ) years old.
Their site lists PAR4008A, PAR4008AL, PAR4008B & PAR4008BL, but has no drivers for them.
The driver package behaves very brutal: irrespectively of whether you opt for driver installation ("we will speed up your computer") or something else, its GUI captures the whole screen and "analyzes the system" or "prepares installation" until the progress bar has reached about 95%, then it hangs. Luckily the seeminly dead window can be closed . Sunix seems to be one of the companies that only support their current or most recent cards.

I have not yet looked into the BIOS with respect to "bidirectional" because I am listening to music played from this PC. I'll do that later.

Regards Kai

[kaimex]

Go to the BIOS from your PC
Place the parallelport on bidirectional

I have looked into the BIOS, cannot find anything about the Parallel Card.
To my knowledge Parallel_Port cards have been bidirectional since PS2_days (for more than 20 years now). The direction of the data_port is controlled by bit 5 (of 0-7) of the control_port (base_address+2). It is not the job of the BIOS to handle that.

Regards Kai