www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/04/01/05:32:46

Message-Id: <199604011022.FAA04015@delorie.com>
Date: Mon, 01 Apr 96 12:01:29 LIT
From: Martynas Kunigelis <martynas DOT kunigelis AT VM DOT KTU DOT LT>
Subject: DPMI q's
To: DJGPP mailing list <djgpp AT delorie DOT com>

 Hi there. Some questions bout DPMI.

[] what happens to the real mode program which started a DPMI process when
   the latter terminates? I think DPMI terminates it, but correct me if I'm
   wrong.

[] why is virtual memory impossible when running in CPL 0? And how much
   speed degradation programs suffer running in CPL 3 (i.e. under DPMI)?

[] what is actually used as a real mode transfer buffer in v2.00? As far
   as I understand the stub.asm, it's the stub's code segment, shrinked to
   an appropriate size. Is that right? If so, is the PSP left untouched for
   termination purposes?


 I have been dreaming about GCC compiles as small in size as possible and
with that Borland/Watcom type of "near" pointers (i.e. 0xa0000 is VGA buf.).
I have been thinking of a way to implement this and checking how Watcom
compiles work. So now I state, that every Watcom/Borland compled 32 bit
DOS application has its DS/ES limit set to 4GB and still run under OS/2 Warp
and, I suppose, Linux. I read an article, that DPMI 1.0 in future should
refuse such segment linmits, but the author said, that we don't need to
worry bout that, since if it happenned, *most* DOS extended applications
(except DJGPP 2 apps!!) would start to choke. So nearptr approach is ok.
But what to do about the zero base. An ideal way would be to set up a
selector with base 1MB lower that the actual image address and map the 1st
megaybte to the 1st physical megabyte. Then the 4GB limit would not be
necessary. Well, DPMI 0.9 does not support such kind of mapping. Another
way would be (as it is implemented by Bugland/Watcom) to re-locate the
image with respect to its linear address and set its segment base to zero.
Well, a segment limit should be adjusted too, it could get really big,
depending on the linear addr and size of the image. But damnit, I think
ld is unable to produce relocatable COFF executables. Or is it? This is my
last question.


Good luck to everyone and thanks for any help!
Martynas

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019