JdBP>> To be honest, I don't see any reason for keeping this check in
 JdBP>> PM, and I wish that IBM would remove it.  It's a kludge that
 JdBP>> tries to create, with smoke and mirrors, the effect that there
 JdBP>> are different "types" of sessions when in fact there aren't. 
 JdBP>> OS/2 Warp would be much more useful *without* this kludge,
 JdBP>> because programs could then use a combination of PM and
 JdBP>> text-mode if they wanted to. 

 HR> They can!
 HR>
 HR> The only thing a programmer has to do is to
 HR>
 HR> - write a multithreaded VIO program
 HR> - link with a PM DLL
 HR>
 HR> then if he would any PM ineraction he starts a thread that calls the
 HR> DLL and this can interact with PM as it likes. 

Maybe you should have tried this before posting.  If you had, you would have
found that WinCreateMsgQueue() returns an error if Presentation Manager
detects that the process type in the PIB is for a windowed or full-screen VIO
process.  WinInitialize() will create an anchor block, but a text-mode
process, because of this check, will fail if it tries to do anything that
involves sending messages at any stage, because it doesn't have a message
queue.

So, in fact, programs cannot use a combination of PM and text.  Try it and see 
for yourself.

What you describe is how things *should* happen and how I, for one, *want*
them to happen.  But currently they do not happen this way, because of a
purely arbitrary check on the process type made by the Presentation Manager
library during initialisation.

For those unfamiliar with the mechanisms of PM, this can have surprising
results.  WinQueryWindowText() doesn't work when used by a text-mode
application, for instance.  This is surprising to the PM novice, until he
reads the PM reference and finds that WinQueryWindowText() simply calls
WinSendMsg() with WM_QUERYWINDOWPARAMS behind the scenes.  The WinSendMsg()
fails, of course, because the text-mode application doesn't have a message
queue.

This is one of the reasons why I made WINSIGHT, in the OS/2 Command Line
Utilities version 2.0, a graphical program.  (WINSIGHT displays a tree
comprising all of the PM windows in the system, including their handles, owner 
threads, window classes, and window text.) I couldn't make WINSIGHT a
text-mode program because any attempt it made to query the text for a window
would fail in that case.

There is a well-known technique known as "process morphing" that can bypass
the check that PM makes, by the simple tecnique of writing a different value
into the PIB.  But this renders the information in the PIB worthless, and
brings us back to my point that this check in PM should be removed.  If the
process type field in the PIB can be any arbitrary value, why is PM even
checking it in the first place ?

As I said before:

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

A text-mode WINSIGHT program would be trivial in this case.

You responded to the above paragraph by saying

 HR> It is a problem of PM (pmshell.exe) to hold full control over screen,
 HR> mouse, keyboard not of OS/2.

Again, from this /non sequitur/ it is clear that you really don't understand
what Presentation Manager is.  Let me re-iterate, just to drive the point
home:

        PMSHELL.EXE *is* *not* *Presentation* *Manager*.

Who said that it *was* an OS/2 problem, anyway ?  Nowhere in anything that I
wrote did I say that this was anything at all to do with the OS/2 kernel. 
Indeed, I explicitly made the point that the OS/2 kernel itself makes *no*
distinction whatsoever between "text mode" and "graphical" processes.  This
was the whole point that I was making.  That's why the distinction made by PM
is so arbitrary.

As I keep saying, the problem is a check in Presentation Manager, that imposes 
an artificial distinction where there is no *actual* distinction, and that
should be removed.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
143/1