Mail Archives: djgpp/1998/10/14/15:16:36
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>
>But if I'm not the only one who's ignorant, you will need to explain a
>whole lot more about this setup to get meaningful replies.
My apologies.
>In particular, what are
>those ``protected-mode applications'' that the desktop starts ``by
>loading their real-mode stub''? are they DJGPP programs?
>Also, what exactly does ``in the middle of __dpmi_int() call'' mean? Does
>GEM catch real-mode interrupts, such as Int 21h?
>If you explain all these things, I or somebody else here might be able
>to help you figure out the problems. Maybe just describing in more
>detail how it works while stating clearly what parts are compiled with
>DJGPP and what are real-mode programs, is all that's needed to
>understand the nature of your predicament.
>
>And what the heck is that GEM thingy?
OK. GEM is a 16-bit GUI for the PC, and all its functions are accessed by
INT 0EFh. At any time it can be running one "application" and up to six
"desk accessories"; the context switches between these occur during an
INT 0EFh call. Both applications and desk accessories are EXE-format files,
and GEM (since it was written in the mid-1980s) expects them all to be
real-mode programs.
My DJGPP bindings allow DJGPP programs to call GEM, using __dpmi_int() to
get at INT 0EFh. They work fine provided GEM is running at most one DJGPP
program (either as the application, or as one of the desk accessories).
When GEM loads, it first loads the desk accessories (with INT 21h function
4Bh subfunction 3). As it loads each accessory, it runs it; the accessory
will then start making INT 0EFh calls. One of the calls will be to read the
accessory's message queue; since the message queue is empty, this call will
block. GEM then regains control and loads the next accessory.
After GEM has loaded all the accessories, it starts the application with
INT 21h function 4Bh subfunction 0. The application can block in the same way
as the desk accessories.
The situation that causes trouble is:
One of the desk accessories is a DJGPP program. GEM loads this and then
lets it run. When it blocks and GEM regains control, the accessory and the
DPMI host are in a __dpmi_int() call and expecting it to return.
GEM then runs another DJGPP program (either application or desk accessory),
which crashes. My guess is that a second DJGPP program can't be started from
real mode while the first one is suspended in a __dpmi_int() call.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
- Raw text -