juliogonzalez
asked on
How can 2 applications share a serial port in Windows 2000 ?
Hi experts,
I am migrating an old 16 bit windows app. thas does direct serial port handling in order to take full advantage of a specialized printer. I have already programmed an interface using Win32 apis that takes care of this.
There is also a DOS application, running on a DOS window, that prints thru the system printer, which happens to be the same serial printer. So, it requires the printer driver to be installed.
It is mandatory to have both applications running on the same machine.
The problem is that whenever the driver is installed, the port seems to be unavailable for my interface, which gets an "invalid_operation" return code for all of its requests. As soon as I remove the printer driver from the system, my interface works OK.
So far I have tried to set the serial port as a multiport ans as a regular port, but the problem remains the same.
The question is what more settings can I try to fix the problem, or if there is any other printer driver that doesn´t block the port
Here is some specific information:
old environment: Pentium I w/Windows 95
new environment: Pentium IV w/Windows 2000
serial printer: Epson TM - H5000
Best regards
I am migrating an old 16 bit windows app. thas does direct serial port handling in order to take full advantage of a specialized printer. I have already programmed an interface using Win32 apis that takes care of this.
There is also a DOS application, running on a DOS window, that prints thru the system printer, which happens to be the same serial printer. So, it requires the printer driver to be installed.
It is mandatory to have both applications running on the same machine.
The problem is that whenever the driver is installed, the port seems to be unavailable for my interface, which gets an "invalid_operation" return code for all of its requests. As soon as I remove the printer driver from the system, my interface works OK.
So far I have tried to set the serial port as a multiport ans as a regular port, but the problem remains the same.
The question is what more settings can I try to fix the problem, or if there is any other printer driver that doesn´t block the port
Here is some specific information:
old environment: Pentium I w/Windows 95
new environment: Pentium IV w/Windows 2000
serial printer: Epson TM - H5000
Best regards
ASKER
Hi Steve,
I´ll find out if the DOS program can switch to LPT1: and try with the mode command.
As for the Windows app, it´s very hard to make it change its printer approach because it dinamically loads data containing ESC sequences, a legacy from an earlier DOS version.
Thanks
Julio
I´ll find out if the DOS program can switch to LPT1: and try with the mode command.
As for the Windows app, it´s very hard to make it change its printer approach because it dinamically loads data containing ESC sequences, a legacy from an earlier DOS version.
Thanks
Julio
ASKER
Hi Steve,
Unfortunately, this DOS pgm. is a black box and doesn´t let me switch it to LPT1
I´ve found something weird, but helpful to me I didn´t make it clear before, but I was testing my win32 interface not directly from the 16 bit app. but from a test pgm. which ia a win32 console app. The pitfall was that this program was prompting the user in order to let me select COM1 or COM2 by using the C function getch(), which now seems to be the conflictive one. After commenting all getch()s, the test program started printing and the conflict with the driver is over.
I still get the INVALID_OPERATION return code for all api calls other than cretefile, readfile and writefile, and even the readfile ends alvays in timeout, but the printer is printing both ways (direct and driver).
Yet, I´m still interested having successfull readfile calls to get the printer status (paper out, etc), but I can live without this.
The compiler I am using is VC++ .Net.
Regards
Julio
Unfortunately, this DOS pgm. is a black box and doesn´t let me switch it to LPT1
I´ve found something weird, but helpful to me I didn´t make it clear before, but I was testing my win32 interface not directly from the 16 bit app. but from a test pgm. which ia a win32 console app. The pitfall was that this program was prompting the user in order to let me select COM1 or COM2 by using the C function getch(), which now seems to be the conflictive one. After commenting all getch()s, the test program started printing and the conflict with the driver is over.
I still get the INVALID_OPERATION return code for all api calls other than cretefile, readfile and writefile, and even the readfile ends alvays in timeout, but the printer is printing both ways (direct and driver).
Yet, I´m still interested having successfull readfile calls to get the printer status (paper out, etc), but I can live without this.
The compiler I am using is VC++ .Net.
Regards
Julio
ASKER
Hi,
To me, this problem got solved when I realized what I explain on my comment
dated 12/17/2003 12:05PM PET above. To be more specific, the conflict generated by the C function getch().
"After commenting all getch()s, the test program started printing and the conflict with the driver is over".
The complete code of the test program can fe found under the following question :
SERIAL PORT WORKS ON WIN/NT AND NOT IN WIN2K
https://www.experts-exchange.com/questions/20803035/SERIAL-PORT-WORKS-ON-WIN-NT-AND-NOT-IN-WIN2K.html
Regards
Julio
To me, this problem got solved when I realized what I explain on my comment
dated 12/17/2003 12:05PM PET above. To be more specific, the conflict generated by the C function getch().
"After commenting all getch()s, the test program started printing and the conflict with the driver is over".
The complete code of the test program can fe found under the following question :
SERIAL PORT WORKS ON WIN/NT AND NOT IN WIN2K
https://www.experts-exchange.com/questions/20803035/SERIAL-PORT-WORKS-ON-WIN-NT-AND-NOT-IN-WIN2K.html
Regards
Julio
As a passer by expert I didn't help at all here but the asker's own comments must be worth a PAQ/REFUND?
Steve
Steve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Alternatively could the Windows App not talk to the printer driver rather than direct to the serial port, I assume you are saying that the Windows program is the one that isn't working when the driver is installed, not the DOS one?
I was only passing through this TA looking for a solution to something myself, will keep an eye on this one though as I'm curious!
Steve