Mail Archives: djgpp-workers/1996/09/14/10:05:17
On Fri, 13 Sep 1996, Charles Sandmann wrote:
>No assumptions on video - needs to work on a monochrome system.
TVision does that all right.
>Needs to be either all 16-bit non-DJGPP code, or needs to be multiple
> images, so that really badly configured boxes can be identified.
>PMODE binding will make the single image more portable, but PMODE is
> less stable and capable in some environments (low memory and/or
> raw memory). So if someone has memory misconfigured, a PMODE image
> won't run at all, while a CWSDPMI image can with as little as 100K
> total (ie DOS memory only) available. So if you bind with PMODE,
> you MUST have the 16-bit memory diagnostic program.
>
>> 1.> - DJGPP files present
>> 4.> - DJGPP files installed in the correct directory structure
>> 3.> - Environment variables set
>> 2.> - DJGPP version
>> 6.> - Available memory
>
>If 6) isn't set properly, 1,4,3,2 will need to be done with 16-bit image.
>
Isn't it possible to write a stub to replace the DJGPP standard one, that
would do the memory diagnostics and, depending on it, either load the DJGPP
app or continue by its own? I realise that this means doubling the code, but
if it is written portably then it might work. The only disadvantage is having
double-sized .EXE. OTOH, it is better for the novice user than having diag32
and diag16 on disk. And I guess that there MUST be a pmode diag program to
test the system's ability to work in DPMI (or p-mode in general) environment
which cannot be done from within the 16-bit RM app.
**********************************************************************
So if you ask me how do I feel inside, I could honestly tell you we've
been taken on a very long ride. And if my owners let me have free time
some day, with all good intention I would probably run away!
Clutching the short straw...
******************* http://ananke.amu.edu.pl/~grendel ****************
- Raw text -