GW> The IBM documentation says that DETACH should only be used for
 GW> programs that don't use the keyboard or the screen. As you've noticed
 GW> both EPM and VIEW both break this rule and both run happily...

I suspect that *all* PM programs break this rule.

The problem is that in reality there is no such thing as a "PM session", a
"full screen text-mode session" or a "windowed text-mode session" in OS/2. 
The documentation speaks of them, and many books over the years, even going
back to the days of OS/2 1.1, have discussed them.  But this description is
simply false.

Sessions don't actually have types in OS/2.  What sessions have are consoles.  
They either have a console, or they do not.  Run 

        [c:\]pstat /m | grep BVS

These shared memory areas are the LVBs of the consoles for the various
sessions that have them.  Write a program to dump the contents of one of these 
shared memory areas, and you will be able to see what is being displayed on a
particular console.

Individual processes are what have the types.  More importantly, the OS/2
kernel itself makes no distinction between different types of process (except
to tell a process what its parent said that its type is when it is started
up).  The type of a process, whether it is a PM process, a full-screen text
mode process, or a windowed process, is stored in the PIB in user space.  The
type is controlled by the parent process, and how it chooses to start the
child process.  Individual processes inherit the same type as their parent
process (and are made a member of the same session) if started by DosExecPgm,
or are given a new type (and made a member of a new session) if started by
DosStartSession.

The one exception to the rule is the EXEC_BACKGROUND flag to DosExecPgm.  If
this is used, the process inherits type 4 (which, strictly speaking, means
that it is a Virtual DOS Machine!) rather than the same type as its parent. 
It is still made a member of the same session, however.

What happens with Presentation Manager is that the PM DLLs, when they first
initialise, look in the PIB.  If they see a process type that they *like*,
they return success from functions such as WinCreateMsgQueue.  In the OS/2
architecture there is, in fact, no underlying reason why processes in any
session cannot link to Presentation Manager and use it to display graphics. 
It is simply the case that Presentation Manager *refuses to work* if it finds
itself running in a process whose type it doesn't like.

And it turns out that the check that Presentation Manager uses is not "if
pib->pib_ultype == PM", but rather "if pib->pib_ultype != VIO_FS &&
pib->pib_ultype != VIO_WINDOWED".  So, ironically, a process started with
DETACH, (whose type is set to "VDM", remember) can quite happily use
Presentation Manager because of a bug in the code in PM that checks for the
process type!

To be honest, I don't see any reason for keeping this check in PM, and I wish
that IBM would remove it.  It's a kludge that tries to create, with smoke and
mirrors, the effect that there are different "types" of sessions when in fact
there aren't.  OS/2 Warp would be much more useful *without* this kludge,
because programs could then use a combination of PM and text-mode if they
wanted to.  A PM program started from the command line could write messages to 
its standard output and have them appear in the text-mode window that it was
started from, rather than have them simply disappear into the ether as is the
case right now.

Indeed, you can see this in action with the 32-bit CMD.  The 32-bit CMD always 
uses DosExecPgm to run programs, which means that they inherit the same
program type as the command interpreter itself and are started in the same
session attached to the same console.  (To run a program with a *different*
type, one uses the START command, which is a wrapper around the
DosStartSession system API function.)  If you start up VIOCMD as a text-mode
program, and then run PMCMD directly by just typing its name in, PMCMD will
inherit the process type "text" from VIOCMD.  PMCMD tries to initialise
Presentation Manager, sees the error code when PM refuses to initialise
because it objects to programs with the "text" type, and prints a message to
standard output and exits:

        [C:\]ver
        VIOCMD 0.0.3 CMDAPI 0.1.24 OS/2 2.40.0
        [C:\]pmcmd
        CMD0030: The main application window could not be loaded
        [C:\]

If Presentation Manager didn't have this check in it, PMCMD would actually be
able to display graphical windows as normal, *as well as* be able to print
messages to its standard output and have them displayed on the session's
console.  There wouldn't be this artificial distinction between "text mode
programs" and "graphical programs". There would just be programs, which could
choose to use the session's console to display a textual user interface or
choose to use the Presentation Manager graphics library to display a graphical 
windowing user interface, or even choose to do both.

Ironically, the fact that there's no difference between "text mode" and
"graphical" programs on UNIX is touted as one of its advantages over OS/2. 
Behind the scenes, we find that this is in fact true of OS/2 Warp as well, but 
that a stupid kludge in the initialisation of Presentation Manager where it
explicitly refuses to work if it doesn't like the program type stored in the
PIB is hiding this fact from us.

The kludge should be removed, in my view.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
114/477
143/1