From: JP Morris Newsgroups: comp.os.msdos.djgpp Subject: Re: Sound libs 4 DJGPP Date: Mon, 27 Jul 1998 10:16:40 +0100 Message-ID: <35BC4578.ED4CFDD2@calderauk.com> References: <35B58218 DOT BA040281 AT logic-gate DOT com> <35B5AAB0 DOT 459BF813 AT calderauk DOT com> <6p4btq$bre$1 AT star DOT cs DOT vu DOT nl> <35B5EB2A DOT 613262FD AT calderauk DOT com> <35b93e27 DOT 2422004 AT news DOT uow DOT edu DOT au> Reply-To: b52g AT usa DOT net NNTP-Posting-Host: no-dns-yet.demon.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 75 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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 > http://members.xoom.com/brett_porter > > "I always like to do a first draft before being > spontaneous." -- The Sandman > ---------------------------------------------------