From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Why did ID choose DJGPP for Quake? Date: Fri, 31 Dec 1999 0:28:25 Organization: Aspen Technology, Inc. Lines: 35 Message-ID: <386bf8a9.sandmann@clio.rice.edu> NNTP-Posting-Host: dcloan.aco.aspentech.com X-NewsEditor: ED-1.5.8 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com From someone who talked with them before they made the decision, and during the development: 1) Cross development. They wanted fast stable boxes (Unix) to do development on with minimal effort to migrate. 2) Possibility to ship the compiler. 3) Source availabiltiy and the libc sources - including DJ's commercial policy and willingness to provide lightning fast response to questions. 4) Verbal assurances the development team would make DJGPP work for them. The commercial quake was built with V2.0 beta 3 - not the final release - using unixy sbrk, prototype near pointers, and some ugly memory management code to make sure the arena never moved. Once their code was stable with beta 3 - they released with it and didn't want to upgrade - it would have required changes to the memory management code. I remember discussing this with one of their partner developers adding drivers or porting about 6 months after the release. A minor fix. Quake did drive some DJGPP development. Near pointers is the most obvious. Near pointers don't work under NT - which was a huge disappointment to iD and generated some conference calls to Microsoft. The result of those calls was that this was a protection feature of NT and was not going to be fixed. If NT had been a bigger market at the time - I was going to provide the dynamic fixup runtime linker (the basis of the DXE code) in the stub to make the base of memory at 0000000 be an option which would have allowed near pointers to work under NT. This would have delayed release about a month or so - and so it didn't happen. Win95 has a huge buggy hack at the time - in beta - and the biggest grief was getting Quake to run reliably under the W95 DPMI provider. CWSDPR0 is a Quake development special - they wanted ring 0 access for the pentium instruction timing opcodes when hand crafting the final assembler performance.