From:	greve AT rs1 DOT thch DOT uni-bonn DOT de (Thomas Greve)
Subject:	emm, vcpi and go32 (was: GCC with DOS)
To:	gordon AT Minsk DOT DoCS DOT UU DOT SE (Gordon Beaton)
Date:	Fri, 22 May 92 13:35:35 NFT
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Status:	O

> 
> However, if I add one of the following lines I get the v86 error from
> go32 (note the absence of 'noems' or 'ram'):
> 
> device=cemm.exe
> -or-
> device=emm386.exe
[...]
> Now if I change the shell back to command.com, it runs in real mode, and
> go32 is happy.
> 
> Until, that is, I run 4Dos.com, after which go32 complains and
> InfoSpotter once again tells me that the processor is in protected
> mode. Even AFTER EXITING 4Dos.com.
(see below.)

[...]
> And although it probably doesn't belong in this forum, if there's 
> anyone who can explain why the mere presence of emm386 (or Compaq's 
> cemm.exe) causes 4dos to behave this way, I would be interested to know.

Maybe, i can. 
- 4Dos itself has nothing to do with v86 or not, but it does swapping
  `somewhere' (see below).
- the emm has.
- vcpi states, that the v86 must become active, *only* after an EMS
  allocation.

So this is what happens (probably:)
- emm starts in real mode
- emm converts *ALL* XMS to EMS.
- 4dos swaps to EMS as there's no XMS left to swap to.
- this has emm switch to v86
- command does not swap to EMS or XMS, so emm rests in peace ah, in
  real mode.
- emm stays in v86 mode, once it has switched to it, weather EMS is
  needed or not.
So: *any* program allocating EMS will switch emm to v86, thus making
go32 not accepting it.

There is one question left open: why doesn't go32 accept emm386 in
v86 mode? emm should provide a vcpi interface, shouldn't it?

				- Thomas

   greve AT rs1 DOT thch DOT uni-bonn DOT de
   unt145 AT dbnrhrz1

- Raw text -