Contents
========
* About
* DJGPP C library reference
* DJGPP mirrors
* DJGPP SIGSEGV debugging
* DJGPP bash versus FreeDOS
* DJGPP wattcp regressions
* DJGPP kb handler bug: double arrow-keys (drunken keys)
* FreeDOS LFN vs DJGPP
* How to produce .com files (NO LIBC)
* Watcom
DJGPP Porting Notes
===================
* #include <getopt.h> or <libgen.h>
* #include <poll.h>
* CFLAGS=-fPIC
* fmemopen()
* getline()
* iswprint()
* setlocale() / nl_langinfo()
* wcschr()
* wcslen()
* getopt_long()
* wcwidth()
* chasonr/djgpp-lib
* strptime()
* See also
About
=====
This is Rugxulo's floppy-sized distribution of DJGPP,
which is the GNU C Compiler (GCC) for DOS.
I can no longer access the original site, which was:
<
https://sites.google.com/site/rugxulo/DJGPP203.7Z>
For a full copy of DJGPP, see following DJGPP mirrors section.
DJGPP C library reference
=========================
<
https://www.delorie.com/djgpp/doc/libc/>
DJGPP mirrors
=============
Archive.org does not reliably archive the .zip files on delorie.com.
<
http://www.delorie.com/pub/djgpp/>
<
ftp://ftp.mirrorservice.org/sites/ftp.delorie.com/pub/djgpp/>
<
http://mirrors.meowr.net/djgpp/>
<
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/
repositories/1.3/devel/>
DJGPP SIGSEGV debugging
=======================
Note: if you get inconsistent SIGSEGV, and it doesn't happen when the
program is run in GDB, then it is probably Linux code that assumes
GLIBC malloc() zeroes out the freed memory. Classic C runtimes in
BSD, DOS, etc, don't do this. You may need to hunt down the
offending data structions and memset(ptr, 0, size); after each
ptr = malloc();
DJGPP has a program called SYMIFY that reads the stack trace from
video memory, then reads the symbols from the executable, and
produces a human-readable stack trace. If your executable lacks
debugging symbols, you can still use SYMIFY to read the stack trace
from video memory and save it to a file for later analysis. Also, in
DOSBox-X, you can use Ctrl-F5 to copy the entire screen to the host
system clipboard.
See the following links for details about SYMIFY.
<
http://delorie.com/djgpp/v2faq/faq9_3.html>
<
http://delorie.com/djgpp/v2faq/faq12_2.html>
DJGPP bash versus FreeDOS
=========================
The latest DJGPP bash (bsh205bbr4.zip) breaks pipes under FreeDOS.
Use the older version bash204b.zip instead.
Title: "Re: GPC with gcc-4.[23]"
Date: 2011-07-23
Author: Maurice Lombardi
> - the latest bash bsh204br3 had a bug (not present in older bsh204b): it
> failed to delete temporary files in the TMPDIR directory with an EACCES
> error message, when bash uses a pipe | (which is used silently many
> times during a make). The compilation continued nevertheless, but it
> made the very long bootstrapped compilation of gpc to fail before the end.
> When running bash under gdb 7.2, I found that bash used bison.simple,
> which is no more present in modern bison (I had bison 2.3 installed when
> recompiling bsh204sr3 with debug information conserved), probably
> somewhat emulated now. Installing the old bison 1.28 which had a genuine
> bison.simple, I recompiled bsh204br3 from sources and the bug
> disappeared, enabling seamless compilation of gpc.
> May be others have not noticed that because they use more modern OSes
> than Win98. In that case it would be better to upload to djgpp a
> modified bsh204br3
From: <
http://www.delorie.com/djgpp/mail-archives/browse.cgi?
p=djgpp/2014/03/03/01:45:14>
DJGPP wattcp regressions
========================
Watt32 2.2.10
<
http://www.delorie.com/pub/djgpp/deleted/v2tk/wat3222br6.zip>
Watt32 2.2.11
<
http://www.delorie.com/pub/djgpp/current/v2tk/wat3211b.zip>
From gopherus-1.2/build.txt:
> The DOS versions rely on the Watt32 library for all network operations.
> I use Watt32 2.2.10 even though the 2.2.11 is available because the latter
> appears to have regressions when used with 16 bit code (crashes).
DJGPP kb handler bug: double arrow-keys (drunken keys)
======================================================
The arrow keys move twice for one keypress in many programs.
<
https://sourceforge.net/p/freedos/bugs/291/>
This happens in qemu but not VirtualBox. I think VirtualBox patched
their BIOS against this DJGPP bug.
* * *
See thread below for a DJGPP fix.
<
https://www.vogons.org/viewtopic.php?f=61&t=71459>
I applied this fix to my cross-compiler and stored a copy in kbfix/
* * *
See post below for a QEMU workaround:
If you use QEMU, you can add to the QEMU command line:
-global i8042.kbd-throttle=on
<
https://sourceforge.net/p/freedos/mailman/message/59162940/>
FreeDOS LFN vs DJGPP
====================
doslfn causes utime() to unconditionally fail with EIO, which
breaks the touch command. This is documented in the following
thread.
<
https://sourceforge.net/p/freedos/mailman/message/8335155/>
How to produce .com files (NO LIBC)
===================================
<
https://nullprogram.com/blog/2014/12/09/>
Watcom
======
<
gopher://tilde.pink/0/~bencollver/dos/watcom.txt>
#include <getopt.h> or <libgen.h>
=================================
Replace with #include <unistd.h>
#include <poll.h>
=================
Replace with #include <sys/poll.h>
CFLAGS=-fPIC
============
Remove -fPIC from CFLAGS.
fmemopen()
==========
Comment that shit out.
getline()
=========
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define GETLINE_BUFFER_SIZE 8192
ssize_t getline(char **lineptr, size_t *n, FILE *stream)
{
ssize_t retval = -1;
size_t s = *n;
char *result;
if (*lineptr == NULL || s < GETLINE_BUFFER_SIZE) {
s = GETLINE_BUFFER_SIZE;
*lineptr = realloc(*lineptr, s);
}
if (*lineptr == NULL) {
*n = 0;
} else {
result = fgets(*lineptr, s, stream);
if (result == NULL) {
free(*lineptr);
*lineptr = NULL;
*n = 0;
} else {
*n = retval = strlen(result);
}
}
return retval;
}
OR
OLD: size_t s = 0;
OLD: ssize_t n = getline(&input, &s, source);
OLD: if (n == -1) {
NEW: size_t s = 8192;
NEW: ssize_t n = 0;
NEW: input = malloc(s);
NEW: char *res = fgets(input, s, source);
NEW: if (result == NULL) {
NEW: free(input);
..
NEW: n = strlen(input);
From: <
https://c-for-dummies.com/blog/?p=1112>
iswprint()
==========
See code in Angband for DOS
setlocale() / nl_langinfo()
===========================
Comment that shit out.
If you really need it, see TCL for DOS contrib/djgpp/langinfo.c
wcschr()
========
See code in Angband for DOS
wcslen()
========
See code in Angband for DOS
getopt_long()
=============
When i ported calcurse, i used NetBSD's getopt code, which has:
"Gnu like getopt_long() and BSD4.4 getsubopt()/optreset extensions"
I saved this getopt code under getopt_l.zip
wcwidth()
=========
See code in following file
<
https://git.savannah.gnu.org/cgit/texinfo.git/plain/info/pcterm.c>
#ifndef HAVE_WCWIDTH
/* A replacement for wcwidth. The Gnulib version calls setlocale for
every character Info is about to display, which makes display of
large nodes annoyingly slow.
Note that the Gnulib version is still compiled and put into
libgnu.a, because the configure script doesn't know about this
replacement. But the linker will not pull the Gnulib version into
the binary, because it resolves the calls to this replacement
function. */
int
wcwidth (wchar_t wc)
{
return wc == 0 ? 0 : iswprint (wc) ? 1 : -1;
}
#endif
chasonr/djgpp-lib
=================
This repository continues development of the DJGPP run time library.
<
gopher://tilde.club/7/~freet/gophhub/?https://github.com/chasonr/djgpp-lib>
strptime()
==========
See jq/src/util.c or libclamav/others_common.c for DJGPP
implementations of the strptime() function
See also
========
<
https://www.cgsecurity.org/wiki/Compile_DOS>