Mail Archives: djgpp/1994/04/08/04:28:40
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 |
+-----------------------------------------------------------------------+
- Raw text -