Mail Archives: djgpp/1998/07/27/05:31:07
Brett Porter wrote:
>
> >If you don't have a DPMI server resident, then the process of
> >compiling MIDAS will start with GNU make. This will start CWSDPMI.
> >Make will then shell out to 16-bit DPMI tools which will simply
> > abort,
They abort with CWSDPMI saying '16 bit DPMI not supported' or such,
because CWSDPMI doesn't need to support 16 bit apps.
>
> I can't understand why. I run pure DOS often with CWSDPMI resident
> from running it in AUTOEXEC.BAT with the -p option. Everything runs
> fine except stuff that uses DOS4GW: it doesn't sit happily with
> CWSDPMI, mostly because DOS4GW isn't a strict extender.
Could you run TASM 4 under these conditions though? That is the
problem. Because the object of the exercise is to compile MIDAS, which
is not DJGPP native, you need to run TASM to generate the assembler
code, and then convert them from .obj to COFF object code using O2C.
TASM 4 (being the first version to generate correct code for the MIDAS
project) runs as a DPMI16 process, and then things start to go astray if
a 32bit only extender (like CWSDPMI) is already present.
I was expecting it to run in realmode, but since it aborted with the
message above, evidently I was wrong.
> >and if it survives that, it will run O2Cpack which will crash under
> >CWSDPMI, plain and simple. I don't know why yet.
>
>
> I'll tell you why: whoever wrote O2Cpack (whatever that is) have been
> playing with their pointers in a way they are not meant to, such as
> dereferencing NULL's.
A NULL dereference in ring 3 code won't freeze the system solid, will
it?
O2Cpack (obj2coff) runs under original go32 v1. Now I don't remember
much about how that works (because I was using programming RTM at that
time).
I expected some compatability between go32 and CWSDPMI, but there is
obviously something going very wrong here, since the system locks.
If go32 is a VCPI client not DPMI, then it will presumably bypass
CWSDPMI altogether and use VCPI while DPMI is still present, which might
be enough to upset the applecart.
>
> I hope this clears it up a little. Poor CWSDPMI gets bashed regularly
> for being a bad server, where all it is doing is making sure that the
> program isn't attempting to totally mess up the computer.
The fact is, I was concerned that other people will have problems
compiling MIDAS.
Since at this time I am the only person in the world who is using this
particular DPMI server, I figured the windows 95 DPMI server would be
the most accessible way for other people to be able to compile it
(making use of existing tools.)
The object is not to bash CWSDPMI, but to point out the pitfalls of this
particular compilation job without another DPMI server to fall back on.
>
> cya
> Brett
> ---------------------------------------------------
> Brett Porter <blp01 AT uow DOT edu DOT au>
> http://members.xoom.com/brett_porter
>
> "I always like to do a first draft before being
> spontaneous." -- The Sandman
> ---------------------------------------------------
- Raw text -