nanogui: Thread: Multiple Mwin Apps

Greg wrote:
>You can't run multiple mwin win32 apps at the present time.  All
>apps must be bound into the same "server".  I've been thinking about
>a shared library solution to this problem, which would be fairly
>straightfwd,
>but it would still run all the apps in the same process space.

How is this done in "original MS Windows"?

--------------------------------------------------------------------------------------------------------
Martin Döring, Systemtechnik (IDT)
MAN Nutzfahrzeuge AG
Dachauerstraße 667
D-80995 München

Tel.:   +49(0)89 / 1580 - 1199
Fax:   +49(0)89 / 1580 - 91-1199
E-Mail: ####@####.####

> Greg wrote:
> >You can't run multiple mwin win32 apps at the present time.  All
> >apps must be bound into the same "server".  I've been thinking about
> >a shared library solution to this problem, which would be fairly
> >straightfwd,
> >but it would still run all the apps in the same process space.
>
> How is this done in "original MS Windows"?

all the API calls are kernel calls, so they can access your program's memory
directly.

Rob

> Greg wrote:
> >You can't run multiple mwin win32 apps at the present time.  All
> >apps must be bound into the same "server".  I've been thinking about
> >a shared library solution to this problem, which would be fairly
> >straightfwd,
> >but it would still run all the apps in the same process space.

I hope you remember what my suggested solution to the problem was, waaaay
back... you have every program doing their own drawing to the screen (with some
sort of region manager process managing where processes have the right to draw
to), then you can have all the API calls executed entirely within that process,
no need for  mashalling at all. the only difficulty is whether a process has to
be root to write to the screen. (one really cool solution is to have the region
manager as a device the the programs use to write to the screen as well and you
have one secure and very fast system... !)


2p...


Rob Taylor
Flying Pig Systems

: >but it would still run all the apps in the same process space.
: 
: How is this done in "original MS Windows"?

In the Win32 world, SendMessage to an hwnd not in
the current process space causes a task switch, with
the arguments copied to a local stack before switching.
The sending task then waits in an internal loop waiting
for the receiving task to return from the sendmessage
call.  All this happens only when the receiving task
happens to be sitting in GetMessage().

Regards,

Greg

: I hope you remember what my suggested solution to the problem was, waaaay
: back... you have every program doing their own drawing to the screen (with
some
: sort of region manager process managing where processes have the right to draw
: to), then you can have all the API calls executed entirely within that
process,
: no need for  mashalling at all. the only difficulty is whether a process has
to
: be root to write to the screen. (one really cool solution is to have the
region
: manager as a device the the programs use to write to the screen as well and
you
: have one secure and very fast system... !)

Yes.  This is a cool solution.  Certainly the client apps need to
open /dev/fb0 multiple times, which is a problem, but a bigger
one remains:  having shared access to the clipping data
structures that the "region manager" that you refer to maintains.
Then, all src/engine/dev*.c draw routines would reside
in a shared library, used by all processes, but having the data
segment for dev*.c routines shared between all processes (
or referenced thru a master psd) with complicated mutex
access between them.

One of these days I ought to try to get that working...

Regards,

Greg




:
:
: 2p...
:
:
: Rob Taylor
: Flying Pig Systems
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
:

> : I hope you remember what my suggested solution to the problem was, waaaay
> : back... you have every program doing their own drawing to the screen (with
> some
> : sort of region manager process managing where processes have the
> right to draw
> : to), then you can have all the API calls executed entirely within that
> process,
> : no need for  mashalling at all. the only difficulty is whether a process has
> to
> : be root to write to the screen. (one really cool solution is to have the
> region
> : manager as a device the the programs use to write to the screen as well and
> you
> : have one secure and very fast system... !)
>
> Yes.  This is a cool solution.  Certainly the client apps need to
> open /dev/fb0 multiple times, which is a problem, but a bigger
> one remains:  having shared access to the clipping data
> structures that the "region manager" that you refer to maintains.
> Then, all src/engine/dev*.c draw routines would reside
> in a shared library, used by all processes, but having the data
> segment for dev*.c routines shared between all processes (
> or referenced thru a master psd) with complicated mutex
> access between them.

I don't quite see why the data segement needs to be shared.
devclip would work by only knowing it's own clipping region (asks the server)
devdraw doesnt need any shared information between processes (well, maybe
colourdepth. the current foreground, etc would be local to the process)
devfont, devimage, as per devdraw

devkbd, devmouse.. ah the difficult ones. basically you need the region server
to do the actual reading of the mouse/keyb and to stick events into pipes for
the processes to read out of. this is the really icky bit that requires some
though (as is recall the GGI project had a nice  solution, but I may be wrong)

devpal* bla, doesn't really have data attached.
devrgn* lives in region manager. on client side is an ipc interface to the
region manager.

Rob

>In the Win32 world, SendMessage to an hwnd not in
>the current process space causes a task switch, with
>the arguments copied to a local stack before switching.
>The sending task then waits in an internal loop waiting
>for the receiving task to return from the sendmessage
>call.

I think thats what happens for interprocess emssages, but between threads in
the same process I believe that the WindowProc is called in the context of
the SendMessage thread.


--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.8 Preview 4, on September 7, 2000, in
Win95 4.10
	http://www.blackpaw.com/