On Sunday, 15 November 1998,
     DENIS TONN wrote to IVAN TODOROSKI about the PM message queue

IT>>    I have heard that this is because the PM has a single serialized
IT>>    message queue for all applications, and no application can receive
IT>>    messages while another is processing its message. A solution to
IT>>    this would be multiple asynchronous message queues for each
IT>>    application.

 DT>  Yes, this is the dreaded synchronous input queue
"problem". (single
 DT> input queue is a misnomer).

  Thanks for the correction.

 DT>  Take a look at the PM programmer's reference and pay particular
 DT> attention to the above 2 API's. That is the core of the whole
 DT> difference between a synchronous and an asynchronous design.

  I don't have the reference handy, since its gone with the hard disk
  (I'll have it after I reinstall the compilers), but I do remember
  reading about these two API functions, and if I recall correctly, they
  take the same arguments, and have the same return type.

  What I don't understand is this: if the PM sent a message to a window
  with WinPostMsg, the call to this API would return immediately. How
  would the PM receive the return value from the message then?

  Let's say the PM sent a WM_ERASEBACKGROUND message to a window via
  WinPostMsg. The window has to respond with TRUE or FALSE, depending on
  whether it wants its background redrawn or not. But the WinPostMsg
  call would return immediately, without waiting for the window to
  respond. How and when will the PM get the reply from the window, and
  erase (or not erase) its background?

 DT>  Win3.1 used WinSendMsg to deliver events to applications, as does
 DT> OS/2's PM. If you look closely at the design of a synchronous input
 DT> delivery mechanism, you will quickly see that multiple threads in the
 DT> application are a requirement. A thread to handle the user input and
 DT> one (or more) threads to do the "work". The problem in
Win 3.1 is that

         Yes... took me a few PM hangs to realize this :)

 DT> applications could not have multiple threads, so all the
"work" had to
 DT> be done on the only unit of execution the application had. This lead
 DT> to certain programming habits for Windows programmers. Habits that
 DT> were carried to OS/2 (all the work done at event reception) and Win32.

       Quite a nasty habit... and dangerous too!

 DT>  MS decided they couldn't retrain all those programmers, so in Win32
 DT> (NT and Win9x) they used a WinPostMsg style API to deliver messages to
 DT> the apps..

         [...]

 DT>  There are advantages and disadvantages to each model. The "system"
 DT> will stay more responsive to the user in an asynchronous model no
 DT> matter how poorly the application progranmmer builds his app, but good
 DT> programmers will *still* use multiple threads so the *app* stays
 DT> responsive even in the async model. And when you get to more complex
 DT> apps with interacting message processing threads the sync model is
 DT> much simpler for the programmer to implement on.

  Thanks for this in depth explanation. It cleared up a lot!

IT>>    Apparently XFree86/OS2 also has multiple message queues, since you
IT>>    can always click around the desktop and switch windows no matter
IT>>    which application is loading and what it is doing. So, it can be
IT>>    done on OS/2!

 DT>  Sure it can. See the differences above between WinSendMsg and
 DT> WinPostMsg. If you want to build a "front end" to all the
events (IE:
 DT> your app needs to understand which underlying "app" the
event needs to
 DT> be delivered to) you can deliver via WinPostMsg.

  Well I got kind off interested in this, and decided to grep the whole
  \OS2\DLL directory for the string "winpostmsg", and found that this
  function is mentioned in PMWIN.DLL.

  I don't know anything about the structure of OS/2 DLL's, (and indeed
  about many other things internal to OS/2, but that's changing thanks
  to you :), but by looking at PMWIN.DLL with an ASCII editor that can
  show the ASCII value of the character under the cursor, I noticed that
  there are a bunch of API function names at the start of the DLL.

  Before every name there is a byte which holds the length of the name,
  and after every name there is a two-byte number which increases by one
  after each name (it is not always by one, there are some jumps, e.g.
  from 250 it jumps directly to 264), so I guess this is the ordinal
  number of the function in the DLL.

  So, this must be the table for associating names with ordinal numbers
  and vice versa. Logic dictates that there must be some other table
  further in the DLL which associates ordinal numbers with entry points
  in the DLL, but I wasn't able to find anything like it due to the
  limitations of the tools I had to work with (basically an OS/2 port of
  the unix grep and the FTE editor)

  This questions must seem very basic to you, but please bear with me.
  Some of you have used OS/2 for years, but only 6 months ago I didn't
  even know what OS/2 is, and thought of IBM as "this big company from
  the past"! I only became interested in OS/2 programming about 2 months
  ago, and only documents I had to learn from were the API reference
  (which is extremely dry, and just lists functions in alphabetical
  order without giving much information on how to use them best) and
  some examples from Hobbes. I managed to cover all of the base API and
  most of the PM API. I still have GPI, SOM and some other stuff left.
  Try to imagine what a shock this must be for a DOS programmer used to
  hooking interrupts and poking at MCB's (Memory Control Blocks)
  directly under DOS...

 Anyway, if this kind of table exists, wouldn't it be possible then to
 simply exchange the entry point pointers for WinSendMsg and WinPostMsg,
 thus forcing the PM to use WinPostMsg instead of WinSendMsg for sending
 messages?

  I know that this would probably make the system unbootable, but anyway,
  I would like to try this and see what breaks. Could you give some info
  on the DLL structure, or tell me where can I find some info?
  Downloadable form is prefered. :)

IT>>   Is there a patch, a FixPak or a workaround that would fix this, or is
IT>>   there a third party solution which can make the PM use multiple
IT>>   asynchronous queues?

 DT>  It would take a fairly major change to PM (and other parts of the
 DT> system, WPS is a prime example) to implement. You would also break
 DT> any apps that depend on the sync model (all the examples I know of are
 DT> from corporate custom apps).

  But what about simple single window - single queue applications? If I
  understood correctly your explanation above, they should be
  unaffected, right?

IT>>    Is there ANY way for programmers outside of IBM to do this, is it a
IT>>    matter of rewriting and replacing a PM DLL(s), where is the problem?

 DT>  The only way for programmers outside of IBM is via the XFree86
 DT> method. Essentially replacing the input model with their own, and it
 DT> would *only* work for apps that understood (or didn't care) about an
 DT> async model.

   Too bad... PM applications don't work under XFree86/OS2. An
   application has to be specifically writen to work with it. It's not
   much of a solution. :(

                                                            - Ivan -

.!. What if there were no hypothetical situations?
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ