Date: Fri, 8 Apr 94 13:58:09 JST From: Stephen Turnbull To: dj AT ctron DOT com Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: uploads to cygnus - dll, farptr, V2.0 src DJ must have been very busy recently, 'cause he said: I've just uploaded to ftp.cygnus.com:pub/dj the following files: -rw-r--r-- 1 97 20 9025 Apr 7 15:39 dll-940219.zip -rw-r--r-- 1 97 20 2794 Apr 7 15:36 farptr.zip -rw-r--r-- 1 97 20 477620 Apr 7 15:39 src200.zip.940407 [dll-940219.zip and farptr.zip descriptions deleted] --- src200.zip.940407: This is the current working copy of the sources to djgpp version 2.0. It does not include any executables, and no sources for any GNU programs. Just the stub loader, libraries, and includes, plus a few utilities. This is only for people who want to help work on V2.0 and is not intended to be an official release. You can use 1.11's development tools to build this, and use this to build running programs (no extender or BCC required!). V2.0 apps require DPMI at the moment. I looked in src200 for a theory of operation, and didn't find any such. I suppose that what will happen is that (1) the stub loader sets up the necessary DPMI info, loads the program, enters protected mode, and starts the program (2) the program runs as usual for GO32 programs until it requires DOS services or virtual memory, at which point (3) services that GO32 used to provide are provided directly through the library using DPMI, and then we are returned to the program. Questions: Does this mean that under DPMI there will be nothing left of GO32 in real memory (or only a very small stub), as opposed to the current situation where GO32 has a 130KB footprint, plus an additional requirement of of 50KB of scratch or other pageable space for a new GO32? Is it also true that output of the compiler and GNU assembler will be the same .o files as the current DJGPP, and that difference is entirely in the libraries? That is, with the same compilation, if I link with LIBRARY_PATH=/djgpp/lib-1.11 I'll get a GO32 v1.11 app, and with LIBRARY_PATH=/djgpp/lib-2.0 I'll get a GO32-less DJGPP 2.0 beta app? And finally, can I therefore hope to build Make and/or GCC under 2.0, and thus avoid the out of memory condition that plagues RAM-crammed systems when we use make, especially for recursive makefiles? (I would probably continue to use the current compiler suite otherwise, or rebuild it too, depending on how stable 2.00 is.) Or is 2.00 just not stable enough to hope for this yet? My motivation is that I have removed the Japanese language support from my system because it takes up about 65KB of real memory, and this gave me too little to run Make, GCC, and a compiler, let alone a recursive make. So when I want to use Japanese I must either reboot, or use an editor I don't like via X Windows. (Due to a bug in DESQview/X, I occasionally get the reboot anyway. :-( ) Now that classes have started, I'll need the Japanese frequently enough that I'd rather avoid the "reboot with a different CONFIG.SYS" step. I don't need to build lots of 2.0 apps yet, I'd just like Make and GCC to take up less real memory. Just out of curiosity, does the "DPMI *at the moment*" clause mean that you (DJ) plan to supply a DPMI server in the future? Or that some alternative protected mode interface will be provided? Or just wishful thinking? As usual, many thanks from your grateful public for the ongoing development of DJGPP! +-----------------------------------------------------------------------+ | Stephen Turnbull | | University of Tsukuba, Institute of Socio-Economic Planning | | Tennodai 1-chome 1--1, Tsukuba, Ibaraki 305 JAPAN | | Phone: +81 (298) 53-5091 Fax: +81 (298) 55-3849 | | Email: turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp | | | | Founder and CEO, Skinny Boy Associates | | Mechanism Design and Social Engineering | | REAL solutions to REAL problems of REAL people in REAL time! REALLY. | | Phone: +81 (298) 56-2703 | +-----------------------------------------------------------------------+