Mail Archives: djgpp/1996/01/29/11:57:54
Here are my suggestions for DJGPP v2 beta 5:
o functions filelength() and chsize() should be included in the C library for
compatibility. `filelength' already exists under the name of `__filelength',
so I just added `#define filelength __filelength' to <io.h> and a small .o
file containing "_filelength: jmp ___filelength" to libc.a. `chsize' is
identical to `ftruncate', so I identically added `#define chsize ftruncate'
to <io.h> and "_chsize: jmp _ftruncate" to libc.a.
o current implementation of malloc() really isn't the best one. It's fast, ok.
But it can allocate only blocks of size 2^n-sizeof(block_header), i.e.
malloc(1024) allocates 2048 bytes. Well, this is quite harmless for blocks
500 or 2000 bytes long, but if you want 33Kb, 64Kb gets allocated. If you
want 66Kb, 128Kb is allocated. What if I want 2.5Mb? 1.5Mb will be wasted.
o if compiling with the -v switch, you can notice, that all the paths
generated by gcc.exe are appended with a DOS-style slash. Well, this works
ok, but does not look pretty for me, e.g:
"e:/djgpp/bin\cc1 -O3 -s e:/djgpp/tmp\ccaaaa etc. etc."
^ these are just driving ^ me crazy!
Same thing happens when ld pops up an unresolved external message and so on.
I am positive that this is caused by a pseudo-bug left in gcc.c. Could this
get fixed, please?..
o since I compiled and now use GCC 2.7.2, I also changed the cpp source, so
that it wastes no time and looks for include files only in /djgpp/include or
/djgpp/lang/cxx or whatever specified by the environment vars. I think this
should be done in beta 5 also, because I'm sure very few of us have
directories like /local/usr/include or something like that. DOS isn't Linux.
(what a pity!) BTW: I never got gcc.c to compile and work. It can't find the
specs file. So I'm using the 2.7.1 version of the driver.
o also I think it would be nice to have `getopt.h' in the include dir and
`getopt.o' in libc.a. They could be taken from GCC source package.
o (optional) Just for myself, I changed the specs file and now my GCC accepts
several new options: -nocoff, -noexe and -nowce. -nocoff means 'no COFF
executable after compilation, just EXE'. -noexe means, that STUBIFY is not
invoked. And finally, -nowce means 'no wildcards and environment', i.e.
command line wildcard expansion and GCC-related environment loading code is
not linked in. I had to change stubify.c to accept a new option -r to remove
the COFF after conversion. I also put a new file 'nowce.o' to my lib dir,
which contains "fake" __crt0.. functions. If anyone is interested, I could
mail you the necessary files...
And finally, what are all those rumors about QUAKE? Is it out yet? Is it really
built with DJGPP? I heard it's going to be a 100% 3D game. With 3D monsters and
stuff... Is that true? Man, what CPU speed will it need?
See ya all on the list!
Martynas Kunigelis
- Raw text -