Open oigamire opened 6 months ago
rderooy
commented
6 months ago You are right, dosbox-x should not crash, it should instead ignore your request to access the IO port, and thereby avoid the access violation.
Using IO ports only ever worked when running DOSBox on very old Windows versions (assuming you can get it to run...). Or using a 3rd party utility, which also requires a very old Windows version.
dbjh
commented
6 months ago Using IO ports only ever worked when running DOSBox on very old Windows versions (assuming you can get it to run...). Or using a 3rd party utility, which also requires a very old Windows version.
It is a bit disheartening to see this coming from you, but alas. No, parallel port pass-through works on Windows versions from Windows 95 all the way to Windows 11. The used configuration could be correct assuming that the ECP Extended Control register's address is D502 (hexadecimal), but that may well be inconsequential for the set up used by @oigamire.
The issue could be that in order to install the kernel driver of inpout32.dll or inpoutx64.dll, DOSBox-X has to be (successfully) started as Administrator, once. After that, the kernel driver will be installed and DOSBox-X can be started as usual. It is also possible to manually install the kernel driver of inpout32.dll/inpoutx64.dll, but you will need to do that as Administrator too and is more of a hassle.
oigamire
commented
6 months ago Thank you dbjh for your interest in my problem. I have started DOSBox-X as Administrator successfully, but I don't see that inpoutx64.dll has been installed and I still have the same problems. I have also tried to install it manually with SC CREATE...\drivers\inpoutx64.dll ...TYPE=KERNEL and it creates the OK service, but SC START gives an error because it cannot verify the digital signature. I'm probably missing something. Could you help me?
dbjh
commented
6 months ago Thank you dbjh for your interest in my problem. I have started DOSBox-X as Administrator successfully, but I don't see that inpoutx64.dll has been installed and I still have the same problems.
You're welcome. inpout32.dll contains a 32-bit and a 64-bit embedded kernel driver, inpoutx64.dll contains a 64-bit embedded kernel driver. Depending on the Windows version, after being loaded the DLL will install either the 32-bit or the 64-bit driver (if absent), provided that the DLL has been granted the required privileges.
I have also tried to install it manually with SC CREATE...\drivers\inpoutx64.dll ...TYPE=KERNEL and it creates the OK service, but SC START gives an error because it cannot verify the digital signature.
I have not tried using sc, but it should not be necessary anyway. However, you would need to refer to the kernel driver, not the DLL. In case of 64-bit Windows, the kernel driver is inpoutx64.sys.
I'm probably missing something. Could you help me?
I'm not sure you are missing anything -- I was not able to reproduce your crash. However, there are a couple of things you can try.
Parallel1: BASE 378h Pass-through I/O caused exception. Right driver required (inpout32.dll or inpoutx64.dll). Using driver inpoutx64.dll. parallel1: The parallel port at 0xd100 (ECR=0xd502) was not detected as supporting ECP. Pass-through I/O enabled.
On your PC in addition to realbase you will probably also want to specify ecpbase.
Please let us know about your results.
oigamire
commented
6 months ago First of all, dbjh, thank you again for your very complete response. I have continued working on it and I can tell you:
inputx64 Before your answer I had already installed inpoutx64.sys with InstallDriver.exe and also registered inpoutx64.sys in the kernel (not .dll. Typo). I have also managed to start the service:
c:\Windows\System32\drivers>sc query inpoutx64 NOMBRE_SERVICIO: inpoutx64 TIPO : 1 KERNEL_DRIVER ESTADO : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) CÓD_SALIDA_WIN32 : 0 (0x0) CÓD_SALIDA_SERVICIO: 0 (0x0) PUNTO_COMPROB. : 0x0 INDICACIÓN_INICIO : 0x0
But DOSBox-X does not start, closes and leaves the following message about the parallel port in the logfile:
LoadMessageFile: Loaded language file: es_ES VOODOO LFB now at d0000000 Serial1: BASE 3f8h Serial2: BASE 2f8h Parallel1: BASE 378h Pass-through I/O caused exception. Right driver required (inpout32.dll or inpoutx64.dll).
giveio64 After installing a service in the kernel with giveio.sys and start it:
c:\Windows\System32\drivers>sc query giveio NOMBRE_SERVICIO: giveio TIPO : 1 KERNEL_DRIVER ESTADO : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) CÓD_SALIDA_WIN32 : 0 (0x0) CÓD_SALIDA_SERVICIO: 0 (0x0) PUNTO_COMPROB. : 0x0 INDICACIÓN_INICIO : 0x0
DOSBox-X starts normally, accepting the address D100 for parallel1 with the following message in the logfile:
LoadMessageFile: Loaded language file: es_ES VOODOO LFB now at d0000000 Serial1: BASE 3f8h Serial2: BASE 2f8h Parallel1: BASE 378h parallel1: The parallel port at 0xd100 (ECR=0xd502) was not detected as supporting ECP. Pass-through I/O enabled.
I think this is what was originally expected and represents a substantial change. At the moment the program protected by a Hasp dongle in LPT does not work for me but at least I have the door open to the dongle and maybe I can find a solution. Once again, thank you for your interest and knowledge, which makes it possible for me to continue with DOSBox-X. At least for now. I am at your disposal. Best regards,
oigamire
commented
6 months ago After starting DOSBox-X as Administrator, is there a file C:\Windows\System32\drivers\inpoutx64.sys?
NO. In none of my numerous tests have I succeeded. Only with InstallDriver it is created in ...\drivers\inpoutx64.sys (size 15,008 bytes)
dbjh
commented
6 months ago First of all, dbjh, thank you again for your very complete response.
Thank you too for sharing your results.
I have continued working on it and I can tell you:
inputx64 Before your answer I had already installed inpoutx64.sys with InstallDriver.exe and also registered inpoutx64.sys in the kernel (not .dll. Typo). I have also managed to start the service:
c:\Windows\System32\drivers>sc query inpoutx64 NOMBRE_SERVICIO: inpoutx64 TIPO : 1 KERNEL_DRIVER ESTADO : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) CÓD_SALIDA_WIN32 : 0 (0x0) CÓD_SALIDA_SERVICIO: 0 (0x0) PUNTO_COMPROB. : 0x0 INDICACIÓN_INICIO : 0x0
Thanks. Earlier you wrote:
SC START gives an error because it cannot verify the digital signature
However, when I created and started the service through sc I did not see any error about being unable to validate the signature. Your output above suggests that you no longer have that problem either since the service is clearly running. I am curious what changed. I am suspicious about the integrity of your copy of inpoutx64.sys, inpoutx64.dll and perhaps even your hard disk.
But DOSBox-X does not start, closes and leaves the following message about the parallel port in the logfile:
LoadMessageFile: Loaded language file: es_ES VOODOO LFB now at d0000000 Serial1: BASE 3f8h Serial2: BASE 2f8h Parallel1: BASE 378h Pass-through I/O caused exception. Right driver required (inpout32.dll or inpoutx64.dll).
If that was the last line in the log file, and given the results with giveio64, it suggests that inpoutx64.dll caused the crash. However, that is not confirmed by the call stack you provided (it suggests the crash happened in dosbox-x.exe). Maybe it can be explained by inpoutx64.dll being corrupted.
giveio64 After installing a service in the kernel with giveio.sys and start it:
c:\Windows\System32\drivers>sc query giveio NOMBRE_SERVICIO: giveio TIPO : 1 KERNEL_DRIVER ESTADO : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) CÓD_SALIDA_WIN32 : 0 (0x0) CÓD_SALIDA_SERVICIO: 0 (0x0) PUNTO_COMPROB. : 0x0 INDICACIÓN_INICIO : 0x0
DOSBox-X starts normally, accepting the address D100 for parallel1 with the following message in the logfile:
LoadMessageFile: Loaded language file: es_ES VOODOO LFB now at d0000000 Serial1: BASE 3f8h Serial2: BASE 2f8h Parallel1: BASE 378h parallel1: The parallel port at 0xd100 (ECR=0xd502) was not detected as supporting ECP. Pass-through I/O enabled.
That is good news.
I think this is what was originally expected and represents a substantial change. At the moment the program protected by a Hasp dongle in LPT does not work for me but at least I have the door open to the dongle and maybe I can find a solution. Once again, thank you for your interest and knowledge, which makes it possible for me to continue with DOSBox-X. At least for now. I am at your disposal. Best regards,
You're welcome. The next thing I would address is specifying a correct value for ecpbase. Note the comment in the reference DOSBox-X config file, i.e. that ecpbase should be the address of the ECP Extended Control register which is the ECP base address plus 2. You can find the base address in Windows' Device Manager. Your PCIe parallel port card most likely supports ECP, so you will be able to tell that ecpbase likely has a correct value if DOSBox-X reports that your parallel port was detected as supporting ECP. You will know for sure if your port works as expected (which may be the same as when your program works).
dbjh
commented
6 months ago At the moment the program protected by a Hasp dongle in LPT does not work for me but at least I have the door open to the dongle and maybe I can find a solution.
I think I realized why it currently does not work: you specified the ECP base address as address for the "SPP" base address (realbase). Your parallel port card should have 2 I/O ranges: a 4-byte range and an 8-byte range. The 4-byte range is the ECP range; the 8-byte range is the "SPP" range. So, for ecpbase use D102. Check Windows' Device Manager for the correct value for realbase. I am really curious about the results!
oigamire
commented
6 months ago Thanks again for your help. I think there is more going on here than it seems, but we are going to look for solutions.
Regarding the card
I attach two files with images that refer to the address range of my parallel PCIe card.
a) From device manager
b) From msinfo32
It can be seen that there is only one range of addresses, which suggests that there are no ECP addresses. However, the seller says that it has IEEE 1284 multimode features (SPP, PS2, EPP, ECP).
Regarding inpoutx64.sys amd giveio.sys The behavior of inpoutx64 remains the same: DOSBox-X doesn't even start. With giveio it always works with or without card installed???. It's as if anyone can always pass by but where? I can put D200 in the .conf, which also accepts it with and without a card. It's like there's no validation. From logfile: "Parallel1: BASE 378h parallel1: The parallel port at 0xd200 (ECR=0xd602) was not detected as supporting ECP. Pass-through I/O enabled."
I am in contact with the seller to get technical information or return the card. All this seems to cause some confusion, but I hope it will be clarified soon. Kind regards
dbjh
commented
6 months ago Thanks again for your help. I think there is more going on here than it seems, but we are going to look for solutions.
Regarding the card I attach two files with images that refer to the address range of my parallel PCIe card. a) From device manager
Yes, that is strange. I guess it's a limitation of Device Manager.
b) From msinfo32 It can be seen that there is only one range of addresses, which suggests that there are no ECP addresses. However, the seller says that it has IEEE 1284 multimode features (SPP, PS2, EPP, ECP).
I would recommend to go for a fully IEEE 1284 compliant card -- not some IEEE 1284 features. They can be bought for as little as €10. However, let's see if we can get this one working too. Thank you for adding the screenshot of msinfo32. You overlooked one range: D000 - D0FF. There had to be a range in addition to D100 - D103, because of what is possible with EPP and ECP (32-bit data transfers from I/O port base + 4). So, I assume that the right value for realbase is D000. However, it is a guess. It could be anywhere in the range D000 - D0FF. For example, D0F8.
Regarding inpoutx64.sys amd giveio.sys The behavior of inpoutx64 remains the same: DOSBox-X doesn't even start. With giveio it always works with or without card installed???. It's as if anyone can always pass by but where? I can put D200 in the .conf, which also accepts it with and without a card. It's like there's no validation. From logfile: "Parallel1: BASE 378h parallel1: The parallel port at 0xd200 (ECR=0xd602) was not detected as supporting ECP. Pass-through I/O enabled."
It is confusing, but expected behavior. There is only a little bit of feedback possible and that is through the ECP Extended Control register. That is one of the reasons why I kept mentioning it :-P The other feedback is of course the parallel port itself. I/O to unmapped addresses simply has no effect. However, if you would specify an address in one of the ranges listed by msinfo32 you could cause real trouble. That is why the parallel port pass-through code will reject addresses in known dangerous ranges, like hard disk controllers.
I am in contact with the seller to get technical information or return the card. All this seems to cause some confusion, but I hope it will be clarified soon. Kind regards
It does not seem that confusing to me :-) My bet is on:
parallel1 = reallpt realbase:D000 ecpbase:D102
oigamire
commented
6 months ago I'm going to try. I just received technical information that seems to support the specifications of the card and downloaded new drivers.
oigamire
commented
6 months ago Nothing. Everything the same with all new attempts (including D000/D102). Always giveio. Inpoutx64 has never allowed me to start up DOSBox-X except parallel1=printer.
The new drivers are the same. And this is the approach to the architecture of my PCIe card:
Do you have any reference to a more conventional ECP card?
dbjh
commented
6 months ago Nothing. Everything the same with all new attempts (including D000/D102). Always giveio. Inpoutx64 has never allowed me to start up DOSBox-X except parallel1=printer. The new drivers are the same. And this is the approach to the architecture of my PCIe card:
The schematic is not very informative, but it appears to have all the features of an IEEE 1284 compliant parallel port.
Too bad about the results, but I have not given up yet. Forget about inpoutx64 -- it is not working on your machine and I have no way to solve it remotely. So, I assume you use giveio64.
parallel1=printer "disables" the pass-through code, including the code that loads and uses inpoutx64.dll, so it obviously cannot cause trouble.
Drivers should not make a difference, because DOSBox-X performs direct I/O without a driver in between.
I think it is safe to assume that ecpbase:D102 is correct.
I do not think it is safe to assume your dongle (or the software that uses it) is working properly. We are working with 2 variables here (value for realbase and whether the dongle (or the software that uses it) is working properly). If things are not working how can we tell which of the two is the cause of the failure? So, it would help if you can independently establish that the dongle is working (unlikely) or if you can use different hardware that connects to a parallel port of which you have determined that it works. It's likely you cannot do either, but I wanted to have at least mentioned it.
Assuming the dongle (software) works, I suggest to check the entire range. You have already tried realbase:D000. It makes no sense to check all remaining 255 values within the range. It is likely that the parallel port registers are aligned to an 8-byte boundary. So, the actual adress is likely one of D008, D010, D018, D020, etc. So, apart from D000 31 different values to test. I would actually start from the end: realbase:D0F8.
Do you have any reference to a more conventional ECP card?
No. I would check Amazon or AliExpress and choose a cheap one.
oigamire
commented
6 months ago I have gone to the beginning of everything. I have prepared a test model on the old PC with Windows XP 32 bits, with parallel output of origin and its MB is starting to fail and that is why I am looking for another solution. If possible in Windows 10. In the times that I can get this PC to work, I have installed the same release of DOSBox-X (3.1.2024) and I have put the dongle in the parallel port. I have used two models to make the sw work:
1- DOSBox-X in its most basic mode (Base 378h) in terms of LPT (that is, I even removed inpout32.dll from the folder. I have also tried enabling inpout32) and the dongle in the parallel port. IT DOES NOT WORK. You don't know the dongle. From filelog: "LoadMessageFile: Loaded language file: en_ES VOODOO LFB now at d0000000 Serial1: BASE 3f8h Serial2: BASE 2f8h Parallel1: BASE 378h MPU-401 Registering I/O ports as if IBM PC MPU-401 at base 330h"
2- I run the program in an XP 32 CMD window and the dongle in the parallel port. WORKS CORRECTLY. It recognizes the dongle and I can develop and run normally.
I'm not losing faith, but I need someone to assure me that DOSBox-X can see the parallel port. Could it be a problem with this release? Thanks, dbjh
dbjh
commented
6 months ago I have gone to the beginning of everything. I have prepared a test model on the old PC with Windows XP 32 bits, with parallel output of origin and its MB is starting to fail and that is why I am looking for another solution. If possible in Windows 10. In the times that I can get this PC to work, I have installed the same release of DOSBox-X (3.1.2024) and I have put the dongle in the parallel port. I have used two models to make the sw work:
Thank you for providing some context.
1- DOSBox-X in its most basic mode (Base 378h) in terms of LPT (that is, I even removed inpout32.dll from the folder. I have also tried enabling inpout32) and the dongle in the parallel port. IT DOES NOT WORK. You don't know the dongle. From filelog: "LoadMessageFile: Loaded language file: en_ES VOODOO LFB now at d0000000 Serial1: BASE 3f8h Serial2: BASE 2f8h Parallel1: BASE 378h MPU-401 Registering I/O ports as if IBM PC MPU-401 at base 330h"
On (32-bit) Windows XP you will need inpout32.dll or AllowIO, which is part of the PortTalk package. Like giveio64, AllowIO will create a context such that accessing I/O ports does not generate CPU exceptions.
The output you sent suggests that you did not add a line with parallel1 = reallpt to the DOSBox-X configuration file, because it shows not even an attempt was made to access the parallel port.
If you cannot get your program (and dongle) to work in this environment then we have no reason to expect that it will work on your newer PC. It is fortunate that you still have this environment.
Please check the values for realbase and ecpbase on your old machine, update the DOSBox-X configuration file and share your results, including the relevant lines of the log. I suggest to first try AllowIO, before trying inpout32.dll, just to avoid issues with inpout32.dll.
2- I run the program in an XP 32 CMD window and the dongle in the parallel port. WORKS CORRECTLY. It recognizes the dongle and I can develop and run normally.
That is great to hear.
I'm not losing faith, but I need someone to assure me that DOSBox-X can see the parallel port. Could it be a problem with this release? Thanks, dbjh
DOSBox-X should be able to "see" it if you will tell it to (in the config file). You're welcome :-)
oigamire
commented
6 months ago About my context Everything we have covered until yesterday (experiments with the old 32-bit XP) has been with a modern PC (without LPT) with Windows 10 that works very well and to which I want to transport the application. The mobo of the old PC (maybe capacitors in bad condition) allows me very small temporary windows before hanging up. I find it difficult to experiment and I am trying to do a mobo "transplant" in order to have a more consistent platform, although with little future.
Test on XP
I give you information about one of my attempts yesterday, with XP that can follow the guidelines you indicate and that DID NOT WORK. I used inpout32.dll and the device manager initial address values for realbase and ecpbase. I put image:
In the .conf file: parallel1 = reallpt realbase:0378 ecpbase:0778
And this is from logfile: "Serial2: BASE 2f8h Parallel1: BASE 378h Pass-through I/O caused exception. Right driver required (inpout32.dll). Using driver inpout32.dll. parallel1: The parallel port at 0x378 (ECR=0x778) was detected as supporting ECP. Pass-through I/O enabled."
I haven't tried in XP with giveio (and now with allowio), but I will. My old PC gives me very little time to be "conscious". Always grateful
dbjh
commented
6 months ago About my context Everything we have covered until yesterday (experiments with the old 32-bit XP) has been with a modern PC (without LPT) with Windows 10 that works very well and to which I want to transport the application. The mobo of the old PC (maybe capacitors in bad condition) allows me very small temporary windows before hanging up. I find it difficult to experiment and I am trying to do a mobo "transplant" in order to have a more consistent platform, although with little future.
Got it.
Test on XP I give you information about one of my attempts yesterday, with XP that can follow the guidelines you indicate and that DID NOT WORK. I used inpout32.dll and the device manager initial address values for realbase and ecpbase.
You had experiences with inpoutx64.dll that were new to me. As I suggested in my previous message, please use AllowIO in an attempt to avoid some new problem with inpout32.dll.
In the .conf file: parallel1 = reallpt realbase:0378 ecpbase:0778
ECP base address + 2. So, ecpbase:077A. However, this is a standard value for the ECP base address, so in this case you need not specify it.
And this is from logfile: "Serial2: BASE 2f8h Parallel1: BASE 378h Pass-through I/O caused exception. Right driver required (inpout32.dll). Using driver inpout32.dll. parallel1: The parallel port at 0x378 (ECR=0x778) was detected as supporting ECP. Pass-through I/O enabled."
Right. Thanks. Good to know. That is why I was using the word likely and not definitely. There is hardware mapped to 0x778 (the first ECP configuration register), but it is not the ECP extended control register.
I haven't tried in XP with giveio (and now with allowio), but I will. My old PC gives me very little time to be "conscious". Always grateful
Yes, please do. The command should be something like allowio /a dosbox-x.exe. You can probably specify the path to dosbox-x.exe. giveio64 works only on 64-bit Windows. AllowIO works only on 32-bit Windows (NT, XP and higher).
I am familiar with the situation you are dealing with. Hopefully your old PC has enough life in it to complete these tests.
You are welcome.
dbjh
commented
5 months ago @oigamire Have you been able to make any progress?
oigamire
commented
5 months ago Hi dbjh, I am preparing a very powerful platform to investigate what is happening. My old PC died (it was because of the chipset) and my new development board has a native LPT (0378h) configurable from the BIOS (5 different modes). From there I hope to be able to scale to Windows 10 or end up doing reverse engineering. You can be sure that I will keep you informed of my progress. Greetings
oigamire
commented
5 months ago Hi dbjh First success! My system recognizes the dongle and the environment is fully operational.
HW 64-bit Asus mobo with i5 and native parallel port 0378h without the need to define ECP in BIOS, although it is possible.
SW Windows 7 32-bit + inpout32.sys running. DOSBox-x.conf: parallel1 =reallpt realbase:0378.
My application works very well and fast. I'll see how far I can scale in SW and HW. Keep reporting.
Greetings
dbjh
commented
5 months ago @oigamire That is great to hear :-) Thanks for sharing!
oigamire
commented
5 months ago Hi again dbjh
Second success case! The system also recognizes the dongle and works correctly. This time it was:
HW 64-bit Asus mobo with i5 and native parallel port 0378h without the need to define ECP in BIOS, although it is possible. Same as above.
SW 64-bit Windows 11 + giveio.sys running. DOSBox-x.conf: parallel1 =reallpt realbase:0378. Impossible to get it working with Inpoutx64.sys.
Works great.
Regards
dbjh
commented
5 months ago Hi again dbjh
Second success case! The system also recognizes the dongle and works correctly. This time it was:
HW 64-bit Asus mobo with i5 and native parallel port 0378h without the need to define ECP in BIOS, although it is possible. Same as above.
SW 64-bit Windows 11 + giveio.sys running.
Wow! That is an unexpected result. I wonder if the author of giveio64 knows it can run on Windows 11 without crashing the entire system.
DOSBox-x.conf: parallel1 =reallpt realbase:0378. Impossible to get it working with Inpoutx64.sys.
Even when using InstallDriver.exe? I would like to understand how you can have 2 machines on which inpoutx64.dll fails. I guess we'll never find out. Regardless, I am glad you managed to get your set up working.
Works great.
Regards
Thanks again for sharing your results. It is valuable when people come back to report success.
mhazan01
commented
1 month ago wow, thanks @dbjh and @oigamire, following your instructions and trials i was able to get the lpt port working on my windows 7 64b machine using giveio and your scripts to access a security dongle plugged into a pcie lpt card and making some old dos software work for an old CNC machine, saving me from hunting winxp era hardware :)
oigamire
commented
1 month ago I'm glad it works for you! Finally I also (in addition to the native 0378h) managed to make it work with LPT on a PCIe card on the Asus MB, both in Win 7 32+inpout32 and in Win11+giveio. On the Gigabyte MB (Win10 64 without native LPT) the system recognizes the card but DOSBox-X doesn't see it. I think it's a PCI address assignment conflict on that MB.
Describe the bug
I have installed a PCIe card with a parallel port on my PC running Windows 10. I have a dongle-protected program. The system has assigned it the address D100 (-D103). In [parallel] of the configuration file I have put "parallel1= reallpt realbase:D100", but DOSBox-X crashes when starting and suggests debugging with Visual Studio, where this appears: "Unhandled exception at 0x00007FF721EDD5A8 in dosbox-x.exe: 0xC0000005: Access violation while reading location 0x0000000000000000." "Module info: 2022.12.26.0" when my version is the latest 2024.03.01. No matter how much I change things, I can't get it to work. I need help, please! Thanks DOSBox-X is great
Steps to reproduce the behaviour
DOSbox-X crashes on startup
Expected behavior
DOSbox-X starts normally
What operating system(s) this bug have occurred on?
Windows 10 Pro
What version(s) of DOSBox-X have this bug?
DOSBox-X 2024.03.01
Used configuration
Output log
No response
Additional information
Have you checked that no similar bug report(s) exist?
Code of Conduct & Contributing Guidelines