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

I am pretty sure there is a way with the comm manager you could do this.
(Yes, there is an API for comm manager programming).

As for why it is discouraged, I think it is because of the doomed number 16 :)

--
-------------------------------------------------------------------------------
Mustafa Soysal               (313) 741-1844 Voice                      TeamOS/2
MISTIK Systems               (313) 741-1937 Fax          Author of UnTieCom(tm)
PO Box 7064                                           Authorised ZyXEL Reseller
Ann Arbor, MI 48107-7064, USA                          os2-l@mistik.express.net
-------------------------------------------------------------------------------

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 ***

In article <3nfjgc$8hp@omega.gmd.de>, Holger Veit <veit@borneo.gmd.de> wrote:
>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.
>|> 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. Veit -

I am interested in your suggestions.

The NetBIOS server - I'm not the one who got the Comm Mgr to mainframe 
link working, so I don't know much about the connection.  I don't believe 
it's on a NetBIOS network, however.  (I could be wrong about this, I'll 
find out later today.)

Using the CM/2 Programming Kit - Are we assuming here that we could still 
use the current method of having the mainframe print to the printer?  If 
so, are there functions in the CM API that would allow intercepting this 
printer output?

Thanks for any help.
- Keith

-- 
--------------------------------------------------------------------------
Keith Bennett                             Bennett Business Solutions, Inc.
Silver Spring, MD USA                     OS/2 & DOS Software Development
kbennett@cpcug.org                        (301) 871-7696