Mail Archives: djgpp/1997/05/24/13:18:46
From: | lce AT mcs DOT com (Larry Ellis)
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | cwsdpmi load failure
|
Date: | 24 May 1997 08:52:47 -0500
|
Organization: | MCSNet Services
|
Lines: | 23
|
Message-ID: | <hpkXpG9s14W8075yn@mcs.com>
|
NNTP-Posting-Host: | jupiter.mcs.net
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Under the version of Netware (sorry, don't know the version) we are using
at my workplace, DJGPP executables fail to load cwsdpmi even if it is
present in the search path.
The problem is that the stub attempts to link UMB memory in and changes
the memory allocation strategy to HI before attempting to exec CWSDPMI.
The Netware shell seems to be failing to resort to low memory to do the
exec if there is insufficient hi-memory....thus, the exec fails, and no
DPMI host is loaded.
I have considered whether I should modify the stub to avoid UMB usage
(loading CWSDPMI is not desirable because of the amount of memory it
requires).
Unfortunately, I am unclear on the steps that need to be taken to
accomplish this. I presume that best course of action would be to
rebuild the stub used by the compiler, rather than trying to patch the
executable (which of course I am prone to forget to do each time I
rebuild the app).
Can anyone help?
(email response appreciated)
- Raw text -