Hi IVAN,

 you wrote at 13.11.98  02:30 to ALL :

I removed all quotes to become a little more room for the answer. :-)

I will simlify so god as I can. 

Multitasking

The Multitasking/Threading is done by the kernel. The problem to *show* it
is the misbehavior of the single PM messagequeue.

Run programs in background (detached!) and you will have a fine
syncronisized multitasking/threading. Run the same program in foreground
and the multitasking is syncronised by pmshell.exe (first instance).

PM and single message queue

The PM is a userprogram at its own. It shares memory between *all* PM
applications and display-, Mouse- and keyboard driver to become more
performance.

The problem is the unchangeable structure of system message handling. The
PM process (pmshell.exe) is the process that receives *all* events from
keyboard and mouse. It generates messages for the PM application (in
detail: for the window the focus is active) and sends this message into the
application own messagequeue. This means that the thread receiving the
event holds until the message is returned from the application. This is
done to serialize the keyboard/mouse events. If you change this behavior
you'll lose the portabiltity of *all* existent PM programs. If you would
create more than 1 system messagequeue (more than 1 instance that can
receive mouse/keyboard events) it's possible that souch events my recived
out of sequence by an application.

Each application, exactly each PM thread) has its own message queue. It is
possible and will often done that 1 window sends messages to another and
this window sends messages back.

Show a primitive graphik:

mouse (ring 0) -> pmshell (1. instance) -> icon representing drive A:

This icon is a simple bitmap painted in a window. This windows is owned by
pmshell (2. instance). So the window (desktop) receives the event (assuming
a double klick) and pmshell (1. instance) waits for a return of this
message.

The wanted action is to open a view onto the diskette placed in drive A:

The wps (excatly the window named desktop) received the message and locates
the icon, finds that this is a object to show. For this action it has to
create a lot of windows (icon-, tree- or details view) (frame, title-,
menubar, ..., read the directory from disk and insert for each entry a new
created object (icons and text) that represents the content of the
directory.

To do that it has to send a lot of messages to pmshell (1. instance) and to
wait of answers for each one. After it has drawn all the objects in the
view it returns the message initiated from pmshell (1. instance).

Some of the actions to display the directory is done in an separate thread
- but not all can made later. A possible response to the action (double
klick) is a error box: 'drive a: not ready'. This error should be displayed
*before* the next action is accepted becouse the user my irritated if this
comes a lot of actions later.
		
Therfore the directory must be readed in before the action can comleted. 
The drawing of the view can and is done by an separate thread of pmshell
(2. instance). For this time is the WPS (pmshell 2) busy and is unable to
receive other events.


A simple! flow of the system event in full:

PM means pmshell.exe 1. instance
WPS means pmshell.exe 2. instance
GPI is a part of PM and does the primitive drawing of points, lines,
rectangles on screen


system -> PM -> WPS -> PM -> WPS -> GPI
			     WPS -> GPI
			     :
			     :
		WPS <- PM
		WPS -> PM
:
:
:
	PM <- WPS
system <- PM

now can rhe next event go


To check the real multitasking do this:

start a program (e.g. e.exe or epm.exe) then

- open with double klick drive A: (insert a good diskette before!)
- change the focus to the program so quick as you can and klick on inside
the edit window
- type some keys on your keyboard

You'll seen that your typeing results in some chars in the window before
the view of the drive is shown.

The WPS itself ist locked until the view is shown but the program you has
started before is ready for work.

Tschau/Bye

Herbert


--- Sqed/32 1.14/development  24: