Date: Mon, 29 Jan 1996 18:49:39 +0200 (EET) From: Martynas Kunigelis To: DJGPP mailing list Subject: suggestions Message-ID: MIME-Version: 1.0 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 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 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