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


juliogonzalezAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Steve KnightIT ConsultancyCommented:
Only a quick thought from something I did some while back.  The DOS program should be able to talk to a printer on LPT1: without having it installed in Windows so maybe you could change the port in the program to use LPT1: instead of COM1: (hoping it is editable...) and use a MODE LPT1:=COM1: type command to redirect it?

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
0
juliogonzalezAuthor Commented:
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
0
juliogonzalezAuthor Commented:
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

0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

juliogonzalezAuthor Commented:
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
http://www.experts-exchange.com/Programming/Programming_Platforms/Win_Prog/Q_20803035.html

Regards

Julio


0
Steve KnightIT ConsultancyCommented:
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
0
LunchyCommented:
Closed, 500 points refunded.
Lunchy
Friendly Neighbourhood Community Support Moderator
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 2000

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.