🚀 go-pugleaf

In article <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?

Yes and no. Basically, these functions are part of the kernel and are 
normally referred to by a number. There are special libraries, called import
libraries, that can associate these fixed numbers to arbitrary names.
Typically, the toolkit uses import libraries named os2286.lib (16 bit)
and os2386.lib (32 bit) that do this translation.
The 'generic' name of such functions is the one without 16 or 32 in the
name, e.g. DosMonOpen. In your case, these functions only have a 16-bit
version; there is no 32 bit equivalent.

|> 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.
|> 
|> We are currently using OS/2 2.1, but intend to upgrade to Warp.  Are
|> these functions present in Warp?
Yes.

|> 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, because IBM wants to remove old 16 bit API
functions, as they won't be supported for future (PowerPC) 32 bit only
architectures (same holds for 16 bit segments, in particular the well-known
IOPL segment, BTW).
If you are aiming at writing portable software, you should avoid this IMHO 
hack to intercept interfaces that surely won't be available any longer in
the future, even if it looks much easier to use them than alternatives.
Regarding your problem, it would be certainly more portable to write a
simple NetBIOS server that accepts data from the net and redirects it
to its destination. There is sample code for doing this in the 
book Orfali et al. 'Client/Server Programming with OS/2'; the CM/2
programming kit should also have similar stuff.

-- 
         Dr.-Ing. Holger Veit              | INTERNET: Holger.Veit@gmd.de
|  |   / GMD - German National Research    | Phone: (+49) 2241 14 2448
|__|  /  Center for Information Technology | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              |    Pentium - the first real
|  |/    D-53754 St. Augustin, Germany     |  processor featuring the new
                                           |    *** RISK technology ***