Link to home
Start Free TrialLog in
Avatar of juliogonzalez
juliogonzalez

asked on

Conflict between an application that programatically controls a serial printer and the printer driver 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 api 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 and 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


 
Avatar of bbao
bbao
Flag of Australia image

just want to make some things clear before further comments:

1. how many printer drivers you have installed for TM-H5000 on you w2k box? one or two?
2. TM-H5000 has two interfaces connect to your box? one is parallel, one is serial?
3. does TM-H5000 has native support on w2k, its w2k driver is available?

thanks,
bbao
Avatar of juliogonzalez
juliogonzalez

ASKER

Hi bbao

Hope this answers your questions

1. only one
2. no parallel, only serial
3. a coworker downloaded the latest driver from the web, I´ll find out if its native or general purpose.

By the way, let me explain this: I was testing my win32 interface not directly form the 16 bit app. bat from a test pgm. which ia a win32 console app. The pitfall was thar 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)

Thanks

Julio


thanks

julio
oh, i think you should call windows printing API to access the printer, not the traditional way to access serial or parallel port directly. in fact, windows, especiall for windows nt/2k/xp, does not allow such operations that access hardware directly. the following is quoted from MSDN's SDK doucmentation - Windows GDI/Printing and Print Spooler:

One of the chief features of the printing functions is their support of device independence. Instead of issuing device-specific commands to draw output on a particular printer or plotter, an application calls high-level functions from the graphics device interface (GDI). For example, to print a bitmapped image, an application can call the BitBlt function, supplying the coordinates for the bitmap as well as handles identifying the source and destination device contexts (DCs). The call to BitBlt is then converted to raw device commands by a printer device driver. A device driver is a dynamic-link library (DLL) that supports the device driver interface (DDI). A device driver generates raw device commands when it processes calls to DDI functions made by the graphics engine. The commands are processed by the printer when it prints the image. The syntax, number, and type of these commands vary from device to device.

for more information, you may visit MSDN or your lib reference of your development language.

hope it helps,
bbao
yes, I know that would be the best approach, but that would be for a brand new app. The current app. does intensive use of escape sequences that are not hard coded but are embedded in the data it gets. Adding the interface the ability to parse the strings and compose the output is way beyond the time and budget available for this project. I mean programming and migration.
I think i´ll have to settle down to what i ´ve already got.

tanks


julio
ok, if i understand your scenario correctly: you have to run a 16-bit DOS application on w2k, the program uses its dedicated way to access printer port or mapped port directly, right? if i am afraid you can not do that under w2k. could you tell me that why you upgraded it from win95 to w2k?
well, it is rather like this:

1.- I have a 16 bit windows app. thas accesses the serial port directly - this program is the one I´m working on.
2.- I also have two other programs, that are 16-bit DOS and are currently printing thru the printer driver. I have no access to the sources of neither of them. Both will be replaced by newer win32 versions - provided by their vendors - to run on w2k.
3.- Upgrading from w95 to w2k is because a new app. that needs w2k will be installed on the same pc´s,  and also because w95 is now an unsupported product.

Thanks
 
if so, only one we should concern is the problem 1.

1.- I have a 16 bit windows app. thas accesses the serial port directly - this program is the one I´m working on.

windows app? that sounds it should work. dont know if you have tried install TM-H5000's w2k driver. have a try.

quoted from: Windows 2000 Server Operations Guide | Part 1 - Storage, File System and Printing | Chapter 4 - Network Printing

Windows 3.x-based (16-bit) applications running on Windows 2000 use the Win16-on-Win32 (WOW) layer, which interacts with the applications through the GDI and with printer drivers through the device driver interface (DDI). The WOW layer translates 16-bit print and display APIs to 32-bit Microsoft® Win32® services. The GDI also provides services to the printer driver, including caching, client/server communications, and ANSI-to-Unicode conversion.

i also have another compromise way that should work. keep a machine running windows 9x with old printers and dirvers, share the old printers on the net, run your new applications on w2k box, to use the network printers shared by windows 9x box.

i also suggest you read windows 2000 server manual before your final decision, the chapter of "Files and Printers".

hope it helps,
bbao
Hi,

I think bbao was very interested in helping and gave me lots of information he cutted and pasted from MSDN. All this I appreciatte. But he insisted to lead me to rewrite the 16 bit windows app to write through the GDI, failing to get the message that the escape sequences were all embedded within the data to be printed, what makes that advise unapplicable.

Besides, this problem got solved since my comment dated 12/15/2003 11:48AM PET above (the 2nd one) when I told bbao the problem was over :

"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. "
 
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

ASKER CERTIFIED SOLUTION
Avatar of Lunchy
Lunchy
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial