It went in at about 2.7.1, I think it sat in Mantis for quite a while after I submitted it. I forget the precise sequence of what went on 10+ years ago, but it's reasonable to expect that since it was in the development 2.7.1 it was backported into the (fixes release) 2.6.2, particularly if I was hassling people about it on the mailing list :-)
P.S.: What I would very much wellcome, would be a unit to access an "old-time" 8-Bit-Parallel Port (Data, Control & Status) for interfacing to DIY-equipment under Win32 and Win64.You should redirect your Delphi component search at Torry's first. Here is everything for direct port access: https://torry.net/pages.php?id=227.
I don't see any solution that is supposed to work under 64-Bit Windows.All these can be found from that page and all work under 64bit:
after userport.exe has started its port-access driver, all old 16-Bit programs running under ntvdm won't workSo you expect that ntvdm and direct port driver both work while trying to race for direct access to the same physical port? Highly unlikely without them cooperating and using single gateway for port access, which doesn't seam to happen. Did you try to run your old 16-bit programs under dosbox or virtualbox instead?
I could not find a solution that works under Windows 7 Home Premium 64 Bit. Even tools that others have reported to do it, did not in my environment.Then move to Windows 32 bit or Linux if that is so important. Alternatively, you could use some Arduino (or similar) for direct access and talk to it from your x64 pc os via serial/usb, bluetooth or ethernet. Some FTDI chips have fast GPIO which can be also used. Take a look at bit banging example here: https://ftdichip.com/software-examples/code-examples/delphi-examples/
I have taken the latest version. It compiles with V 2.6.0, but so far does not "wait for answer", as it announces.
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 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.
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.
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.
I'll check the other tools that you listed, whether one of those does the job.https://github.com/changguangyu/DelphiMSR
you need to produce 64bit application to work with 64bit driver
The recommendation to ask Sunix for a driver appears inadequately unfriendly to me.
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.
Go to the BIOS from your PCI have looked into the BIOS, cannot find anything about the Parallel Card.
Place the parallelport on bidirectional
@PascalDragon: Is a FPC 64 Bit version available that I could try to test your understanding of the subject ?
Look for fpcupdeluxe. Yes it is possible to handle more than one fpc/Lazarus on one PC without a problem. But you must have a little knowledge about the things you do.
Another question:
Can FPC v3.2.2 coexist with older versions on the same PC ?
In other words: are FPC installations independent ?
If yes, I would like to keep the old v2.6.0 version .
Thank you for directing my attention to fpcupdeluxe.On windows you can set fpc and lazarus on a bare metal pc with fpcupdeluxe. For the installation a connetion to the internet is a must have, because fpcupdeluxe load all need tool, software, components by itself down. After you finish your installation, offline work is possible. fpcupdeluxe, fpc and lazarus need no connection to the internet. Offline work is no problem, only if you want to update your installation you have to go online, because svn or git need it to synchronize the sources.
Does this hint mean, that without the use of fpcupdeluxe two different installations of FPC would interfere ?
Additional question:
Does fpcupdeluxe organize offline installation such that 2 or more FPC installations can coexist,
or does it require internet connection for online installations ?
I can only use Windows tools suitable for offline work.
Regards Kai
Does this hint mean, that without the use of fpcupdeluxe two different installations of FPC would interfere ?
you can download the combined FPC 3.2.2 for i386 and x86_64 (named fpc.3.2.2.win32.and.win64.exe from here (https://sourceforge.net/projects/freepascal/files/Win32/3.2.2/). For older versions we provide a cross compiler for x86_64 as well that you can install additionally to the i386 one.On the SourceForge site I see the combined fpc-3.2.2.win32.and.win64.exe and a cross compiler for the same version : fpc-3.2.2.i386-win32.cross.x86_64-win64.exe.
you can download the combined FPC 3.2.2 for i386 and x86_64 (named fpc.3.2.2.win32.and.win64.exe from here (https://sourceforge.net/projects/freepascal/files/Win32/3.2.2/). For older versions we provide a cross compiler for x86_64 as well that you can install additionally to the i386 one.On the SourceForge site I see the combined fpc-3.2.2.win32.and.win64.exe and a cross compiler for the same version : fpc-3.2.2.i386-win32.cross.x86_64-win64.exe.
I wonder why.
Starting from the FPC download page I am offered the choice of SourceForge & Download mirrors in Hungary and Canada.
The latter two sites both state:
"Download native compiler
There is no native compiler available for x86_64 Win64. You have to use a cross-compiler.
Download cross-compiler running on another host
This cross-compiler runs on another host and needs the corresponding native compiler as a prerequisite."
This confuses me. Is this outdated information ?
By the way: do I have to use Lazarus or can I stay with the old textmode IDE ?