From: jce AT seasip DOT demon DOT co DOT uk (John Elliott) Newsgroups: comp.os.msdos.djgpp Subject: Re: Running multiple DJGPP apps from 16-bit Date: Wed, 14 Oct 1998 20:11:18 GMT Message-ID: <908392312.2282.1.nnrp-04.c2de7091@news.demon.co.uk> References: NNTP-Posting-Host: seasip.demon.co.uk X-NNTP-Posting-Host: seasip.demon.co.uk:194.222.112.145 X-Trace: news.demon.co.uk 908392312 nnrp-04:2282 NO-IDENT seasip.demon.co.uk:194.222.112.145 X-Complaints-To: abuse AT demon DOT net X-Newsreader: skim 0.8.4 Lines: 55 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii 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 :-------------------------------------------------------------------------)