🚀 go-pugleaf

In <3nef9c$580@cpcug.org> kbennett@cpcug.org (Keith Bennett) writes:

>This question pertains to the use of device monitors used to intercept and
>divert printer output.

>We have a small program that intercepts, reads, and processes printer
>(LPT1) output.  A coworker copied the code from a sample from a book
>or magazine and adapted it for our use.  I have extracted the device
>monitor code from the program and created a class that can be easily
>used by other programs.  However, I'm having some problems with it
>and have several questions.

>The code contains functions whose names contain 16:

>APIRET16 APIENTRY16 Dos16MonOpen(PSZ,PHFILE16);
>APIRET16 APIENTRY16 Dos16MonClose(HFILE16);
>APIRET16 APIENTRY16 Dos16MonReg(HFILE16,PUCHAR,PUCHAR,USHORT,USHORT);
>APIRET16 APIENTRY16 Dos16MonRead(PUCHAR,USHORT,PMONITORPACKET,PUSHORT);
>APIRET16 APIENTRY16 Dos16MonWrite(PUCHAR,PMONITORPACKET,PUSHORT);

>In PRCP.INF (dated 11/16/90), the functions are listed there but
>their names do not include "16".  Is this because the "16" was added
>for clarity after 32 bit libraries became available?

The 16 is to distinguish them from the 32 bit APIs.  No, there are no
32-bit counterpart for these APIs specifically, but the rule is a
"general" one instead.

>These prototypes must explicitly be inserted in the source code, as
>they are nowhere to be found in the compiler and toolkit header
>files.  I am told that this is because the use of them is
>discouraged.  Nevertheless they exist in the libraries, and linking
>succeeds.

This is true.

>We are currently using OS/2 2.1, but intend to upgrade to Warp.  Are
>these functions present in Warp?

Yes, they do.

>Why is use of these functions discouraged?  Are there other better
>ways to accomplish what we need to do?  The reason we need to use a
>printer monitor is this: We need to receive data from a mainframe.
>Using Comm Mgr, we can tell the mainframe that we have a printer
>connected to LPT1.  Then the mainframe "prints" to it.  We intercept
>the data and process it.  My understanding is that this approach was
>used to minimize or eliminate software development on the mainframe
>side.

The functions are discouraged for "portability to other platforms"
issues, just like the VIO APIs were removed for the same reason.

Cheers,
Q
-- 
Have you read this month's EDM/2?  Send an empty email message to
edm2-info@knex.mind.org to receive a help file on how to subscribe,
receive back issues, etc.  Send all comments, complaints, suggestions
to os2man@panix.com .