This is the DJGPP Frequently-Asked Questions List.
Copyright (C) 1994, 1995, 1996 Eli Zaretskii
This is the second edition of the FAQ list, and is consistent with version 2.0 of DJGPP.
This FAQ list may be freely distributed with the DJGPP package or any part thereof, provided this copyright notice is left intact on all copies.
But because the DJGPP project is a product of a group of volunteers, there isn't always enough time (or patience, or money ;-) to produce documentation which will describe all the subtle features and pitfalls a user should know about. The documentation of DJGPP-specific utilities and issues is therefore minimal, leaving wide space for confusion, in newcomers and veterans alike, and making the DJGPP learning curve quite a steep one.
This FAQ list is an attempt to take the sting out of that learning curve, by supplying solutions for problems which are known to puzzle DJGPP users. (Another solution would be to pay to DJ Delorie and other people who developed DJGPP to produce more documentation ;-) .
This is Edition 2.0 of the FAQ, last updated 21 February 1996, for DJGPP Version 2.0.
The sources of the latest version of this FAQ list can always be found as faq200s.zip on SimTel mirrors. This
includes the source file (written in Texinfo), and all the auxiliary tools required to produce the Info, plain-ASCII, HTML, and a few other versions of the FAQ list; the FAQ in all these formats is
available in a separate ZIP archive as faq200b.zip on SimTel mirrors. Currently, this includes the Info version,
the text (ASCII) version and an HTML version as a single large .htm file. More formats will be available as the tools for their generation are developed/tested.
You can browse the HTML version of this FAQ list on line at the DJ Delorie's Web server.
If you browse this FAQ at DJ Delorie's server now, you can get the source distribution of the FAQ right here. Also available from the DJ's server: FAQ in all the supported formats.
This FAQ was also translated into French.
The following master menu lists the major topics in this FAQ list, including all the indices.
Q: I have this problem which I absolutely MUST solve NOW! What do I do?
Use the DJGPP Newsgroup or mailing list. For most questions, you will have your answer in a day or two. See the details on how to ask the gurus.
This depends on your hardware and software. See system configuration guidelines.
Check out the list of required and optional packages.
See subscription instructions.
This FAQ includes the description of DJGPP archive search servers, set up by Stephen Turnbull and DJ Delorie.
| Previous | Next | Up | Top |
Q: Will DJGPP run on my brand-new Acme i986DX7/300 PC with a SCSI-III 10-Terabyte disk drive under MulticOS/42 v7.99 operating system?
DJGPP will run under native DOS; any other operating system is OK if it includes a DPMI server. Environments known to run DJGPP besides native DOS: Windows 3.1, 3.11 DOS box, OS/2 (including Warp) DOS box, Windows 95/DOS 7, Novell NWDOS 7.x (but several people has found the DPMI services of NWDOS buggy, so they should probably be turned off and CWSDPMI used instead), and Linux dosemu environment.
| Previous | Next | Up | Top |
gcc.exe (from v1.x archives).
| Previous | Next | Up | Top |
gcc.exe (it is in the
gcc272rm.zip archive) and a real-mode Make program (like the one in the
gnuish/ directory on SimTel). Also, any DJGPP program which calls any function from the spawnXXX family to run
another DJGPP program, won't run under NT.
| Previous | Next | Up | Top |
| Previous | Next | Up | Top |
Apart from RSXWDK, you will need windows.h header file. One place to find it is with the WINE distribution.
You will also need a resource compiler.
Another way to develop Windows applications is to use the Cygnus GCC/GPP port. This one's compatible with Win32, but requires you to comply with GNU Copyleft system.
A better (but harder) way would be to volunteer to add Windows support to DJGPP.
Note that, as of this writing, nobody has reported any first-hand experience of using RSXWDK with DJGPP v2.0; the above is based on user reports under v1.x. If you try RSXWDK with v2.0, please post a summary of your experience.
| Previous | Next | Up | Top |
TMPDIR environment variable points to it (e.g., set TMPDIR=e:, if E: is the RAM drive letter);
| Previous | Next | Up | Top |
TMPDIR to your hard disk and make the disk cache larger, if you can.
SETVER.EXE, HIMEM.SYS etc.) from your CONFIG.SYS and AUTOEXEC.BAT.
TMPDIR environment variable to a directory on your hard disk. Put a sufficiently large BUFFERS=
statement into your CONFIG.SYS (I recommend setting BUFFERS=40,8) to make DOS file operations faster.
csdpmi1p.zip archive) and set the "Minimum application memory desired before 640K
paging" parameter to 512K. (Depending on how much memory you actually have, you might need further fine-tuning this parameter. This parameter defines the lowest amount of the extended memory
CWSDPMI will use; if your system doesn't have that much free extended RAM, CWSDPMI will use the conventional memory instead.)
SETVER.EXE, HIMEM.SYS) from your CONFIG.SYS and AUTOEXEC.BAT.
TMPDIR environment variable to a directory on your hard disk.
TMPDIR environment variable to a directory on your hard disk.
TMPDIR environment variable to it. If your RAM disk is less than 4 MBytes,
GCC might run out of space there for very large source files (e.g., cccp.c file from the GCC source distribution), but this shouldn't happen unless the size of the source file you are
compiling approaches 1 MByte.
| Previous | Next | Up | Top |
Note that DJGPP was recently moved to the SimTel/vendors/ directory on most SimTel mirrors. This is because SimTel claims a compilation copyright on its collection, to prevent people
from copying the CD-ROMs which are distributed by SimTel. The GNU GPL prohibits any restrictions, even on compilations. So, FSF asked for GNU and GNU-related files to be moved to a
separate directory to keep people from accidentally thinking that their rights were being reduced.
| Previous | Next | Up | Top |
djgpp subdirectory (the exact path to it might
be different on different mirrors, see the DJGPP archive path.) Then issue the binary command and download files you need (see the
list of required files) with the get command.
| Previous | Next | Up | Top |
Gopher users can access SimTel files through a Gopher client.
For those of you who have only e-mail connection to the Internet, SimTel files may be also obtained by e-mail from various ftp-mail servers or through the BITNET/EARN file servers. For details send a message to the SimTel list server with this command in the message body:
get simtel-mailserver.info
You can also get DJGPP from CD-ROM copies of SimTel collections. You can either request a CD-ROM by e-mail, or
order the SimTel CD-ROM through a WWW FORMS Interface.
| Previous | Next | Up | Top |
.zip files I need to download?
as , the GNU assembler, and ld , the GNU linker, and their docs.
djdev distribution includes two simpler debuggers, edebug and fsdb . The latter presents a user
interface similar to that of Turbo Debugger.)
00_index.txt, it contains a full list of the distribution files and a short description of every file.
| Previous | Next | Up | Top |
Execution-only environment..................300 KBytes
Developing C programs.......................10 MBytes
Developing C++ programs.....................13 MBytes
Developing Objective-C programs.............11.5 MBytes
Additional storage for C Library sources....2.7 MBytes
Additional storage for GDB..................1.1 MBytes
Additional storage for Flex.................280 KBytes
Additional storage for Bison................310 KBytes
Additional storage for Diffutils............560 KBytes
Additional storage for Make.................520 KBytes
Additional storage for Patch................120 KBytes
Additional storage for Sed..................73 KBytes
Additional storage for Graphics libraries...2.8 MBytes
In addition to the space for installing the software, you will need some free disk space for the swap file. You should leave enough free disk space to make the total virtual memory at least 20
MBytes; that will be enough for most applications. Invoke the go32-v2.exe program without arguments to see how many DPMI memory and swap space can DJGPP applications use. Depending on
your DPMI host, you might need to review its virtual memory settings in addition to leaving free disk space; CWSDPMI needs only the disk space.
Q: Pulling that much megabytes through the net from my overloaded SimTel mirror is almost impossible. Can't you prepare a ZIP archive which only includes stuff I can't do without?
To make downloading DJGPP easier, download and compile the BatchFTP program. It allows you to submit a script of FTP commands and will repeatedly try to login into the FTP site you specify until the script is successfully completed. It is smart enough to understand the messages which the FTP server sends to you (like login refused etc.) and also is nice to the remote server by sleeping for some time between login attempts. BatchFTP is free software and can be found on many FTP sites.
BatchFTP is a Unix program; those who access the net from their PC (not by dialing into some Unix host), can use a nice FTP-automating utility called AutoWinNet (get the file autownNN.zip from your nearest SimTel mirror).
| Previous | Next | Up | Top |
info/ subdirectory of your main DJGPP installation directory. You will need a program to read these docs, which are hypertext
structured files. You have several choices:
Get the file txi360b.zip, which includes INFO.EXE and its docs. Unzip it and run Info. It will
bring up a (hopefully) self-explanatory online help system. Confused? Press ? to see the list of all Info commands. Still confused? Press h to have Info take
you on a guided tour through its commands and features.
If you use Emacs, you already know about Info. (What's that? You don't? Type C-h i and you will get the top-level menu of all the Info topics.)
| Previous | Next | Up | Top |
Anthony Appleyard has translated the Info files for GNU C/C++ Compiler (gcc.iNN) and GNU C Preprocessor (cpp.iNN) into
ISO-8859 (aka plain ASCII), and Stephen Turnbull has made them available on his anonymous ftp and WWW server. You can get them as
gcc.txt and preprocessor.txt by anonymous ftp; or get them
with your Web browser.
You can also produce pure ASCII files yourself, if you have their Texinfo sources. These are usually called *.txi or *.tex and should be included with the source
distribution of every package. To produce an ASCII file foo.txt from the Texinfo file foo.txi, invoke the Makeinfo program like this:
makeinfo --no-split --no-headers --output foo.txt foo.txi
The Makeinfo program is part of the Texinfo distribution which is available in txi360b.zip.
| Previous | Next | Up | Top |
*.txi or *.tex) which you get with every *s.zip file you download. You will get
a .dvi file which you can print; or you can run a DVI-to-PostScript converter like DVIPS to produce a PostScript output. DVIPS is a free program; you can find
it with your archie client. DJGPP comes with a program called TEXI2PS which can convert *.txi files to a crude PostScript; try it if you don't care much about the appearance of the printed docs.
If TeX won't run, check that you have the file texinfo.tex which defines the TeX macros specific to Texinfo files. If you don't, get the GNU or DJGPP Texinfo
distribution which includes that file.
Note that some docs files (notably, those for GCC) will produce voluminous print-outs. You have been warned!
| Previous | Next | Up | Top |
However, some Good Samaritans from all across the Net have taken time and effort to produce the docs in PostScript format and made them available by anonymous ftp. The most full set of docs for the latest versions of GNU software is available in plain ASCII, zip and tar.gz format by anonymous ftp from phi.sinica.edu.tw; they are all for A4 paper. Other places to look for PostScript versions of GNU documentation are:
Many GNU manuals in HTML (hypertext) format, suitable for reading with your Web browser can be viewed at the DJGPP Web site.
DJGPP includes a utility called TEXI2PS which converts the Texinfo source files to crude PostScript; try it.
| Previous | Next | Up | Top |
info/ subdirectory, but I can't find docs for some of the utilities, like Sed or Gprof.
*s.zip) for that package and look inside it, usually in the directory called man or doc.
| Previous | Next | Up | Top |
foo.1 files?
foo.1 or bar.man or baz.nroff, and they seem to be written in some weird format which is very difficult to
read. How can I convert them to readable text files?
*.1 troff source files.
No matter which of the above methods you choose, you will need some kind of browser which understands how to show bold and underlined letters instead of backspace-over-typed characters. I suggest to download a DOS port of GNU Less, which uses colors to show bold and underlined letters. Another possibility is to get the latest official GNU Less distribution which can be compiled out of the box with the Microsoft C compiler (but I didn't try to do so).
Another possibility to read formatted man pages would be with an Emacs editor, if you use one. Emacs has a special command to read man pages.
Beginning with version 3.6, the stand-alone Info program can also read man pages (it invokes a subsidiary program man to format them, then displays its output; see the file
readme.dj in the DJGPP Texinfo distribution for more details on how to set this up). So if you have the DJGPP Texinfo distribution, you can read man pages with Info
already; if not, just download Texinfo.
Note that, for GNU packages, the man pages aren't always updated on a regular basis. If you need more up-to-date information, see the Info files.
| Previous | Next | Up | Top |
Q: I cannot run v2.0 applications: they all hang or reboot my system, while v1.x apps run OK. Is this what v2.0 is all about--getting me out of the DJGPP community?
Another DPMI host which is known to cause problems in DJGPP is Quarterdeck's QDPMI which comes with QEMM 7.5. It was reported to cause Info and all DJGPP debuggers to crash. If you use QDPMI, upgrade to the version 7.53 or later (patches for that version are available from the Quarterdeck's ftp site), or disable QDPMI and use CWSDPMI.
| Previous | Next | Up | Top |
lib/specs file.)
As an extreme measure, don't optimize at all, if that's the only way to make your program work. Another reason for this could be some problem with your system hardware or the BIOS (like if you set an incorrect number of wait states when accessing memory). To check, try running the same compilation on another machine, or review your BIOS settings.
| Previous | Next | Up | Top |
Q: GCC aborts with "Internal compiler error" when compiling a large C++ program.
COMPILER_PATH environment variable or
what the COMPILER_PATH line in the DJGPP.ENV file says, and make sure they point to the directory where DJGPP programs reside. Also check that the named directory has all
the required programs: cpp.exe, cc1.exe, cc1plus.exe, cxxfilt.exe, gasp.exe, as.exe, ld.exe, and (for
Objective-C) cc1obj.exe. You can use the -v switch to GCC to see what programs it invokes.
The "Internal compiler error" message usually means a genuine bug in GCC (which should be reported to FSF), but it can also happen when GCC requests additional chunk of memory, but the DPMI server
fails to allocate it because it exhausts available memory for its internal tables. CWSDPMI can fail like this if an application asks for a larger number of small memory chunks. You can enlarge the
maximum space that CWSDPMI uses if you get a CWSDPMI heap-fix patch. You can also run stubedit on
cc1plus.exe and enlarge its maximum stack size to 512K bytes (some people report that they needed to enlarge both the heap of CWSDPMI and the stack of the C++ compiler to make this
problem go away).
For a program that you wrote, another work-around is to use an alternative algorithm for sbrk, by putting the following somewhere in your program:
#include <crt0.h>
int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
| Previous | Next | Up | Top |
Q: Since a few days ago, whenever I try to run most of the DJGPP programs, they print a message "C:\DJGPP\BIN\prog.exe: not COFF" and just terminate. Help!!!
STUBIFY.EXE are infected by a virus. (This is not a joke! It did happen to a few of us and can happen even to you.) As the DOS
stub prepended to the DJGPP programs is very small, most viruses cannot attach themselves to it without overwriting the beginning of the DJGPP COFF image, therefore triggering this error from the
code in the stub that loads the COFF image.
Another possible cause of the "Unknown filetype" message is that you mix v2.0 gcc.exe driver with cc1plus.exe, cc1.exe or other programs from an old v1.x
distribution.
| Previous | Next | Up | Top |
"Error: Using XMS switched the CPU into V86 mode."
All you have to do to work around this is force QEMM to be ON whenever you run DJGPP programs so that CWSDPMI will know how to work with it properly. To do this, just turn QEMM on before running any DJGPP program, with this command:
c:\qemm\qemm on
(that assumes your QEMM directory is c:\qemm).
| Previous | Next | Up | Top |
PATH than the Make which came with DJGPP.
If you use Make compiled under DJGPP v1.x, you will also experience all kinds of trouble when invoking programs compiled under DJGPP v2.0. That's because v1.x programs cannot spawn v2.0 programs
directly (the v1.x program sees that the child is a DJGPP program and tries to call go32 to run it). The result usually will be that the child crashes. If that's your problem, be
sure to upgrade your Make to the port distributed with v2. (Note that v2.x programs generally know how to spawn both v1.x and v2.x programs.)
Some users report that v1.x programs might sometimes hang or reboot the machine when invoked from v2.0 Make, if the Makefile calls the v1.x program by a name longer than the 8+3 DOS filename restriction. To work around, truncate the filename of that program in the Makefile.
| Previous | Next | Up | Top |
DJGPP.ENV in the root of your DJGPP installation mentions the variable INFOPATH which should point
to the directory where Info looks for its files. It must find there a file named dir, the file you are trying to read, and other files with .iNN or .NN
extension, where NN is a number. Assuming the above checks OK, and all the necessary info files are indeed installed in those directories (did you remember to give that -d switch to PKUNZIP?), it might be that some of the files were edited with a DOS-based editor, which converted the Newline characters to the CR/LF pairs. Some DOS ports of Info don't like this, because this invalidates the tag tables included with the files, which Info uses to quickly find the various nodes.
To solve the problem, upgrade to the latest versions of Info ported to DJGPP, which don't have this problem (beginning from version 3.6).
If you cannot upgrade for some reason, run DTOU.EXE on the offending files, it will strip the extra CR characters to make Info happy. DTOU is in your bin/
subdirectory of the main DJGPP directory.
| Previous | Next | Up | Top |
README.* files, but when I run gcc, my machine crashes/hangs/needs cold boot. Q: When I compile my program, gcc says "Segmentation violation" and prints all kinds of funny numbers and registers.
Q: I get errors I can't figure out when I try to compile something.
| Previous | Next | Up | Top |
Q: When I add -v to the GCC command line, how can I put all the voluminous output into a file, so I don't miss anything when reporting a problem?
Q: I have this nifty graphics program which bombs from time to time, but the registers and traceback info is hidden by the graphics display. How can I see it?
COMMAND.COM, such as 4DOS, which knows how to redirect standard error stream to a file. 4DOS is shareware and can be found on
SimTel.
| Previous | Next | Up | Top |
Steve's archives can also be fast-searched. using any Web browser supporting ISINDEX capabilities. This is
faster, but supports only simple keyword searches, not regular expressions.
You can also download gzip'ed copies of DJGPP correspondence split up by months (the most recent month might not be up-to-date) from the anonymous ftp server set up by
Stephen Turnbull. They are available at turnbull.sk.tsukuba.ac.jp. If you
look for the traffic from a specific time period, you should look for files named djgpp.YYMM.gz (they are around 250K bytes each), where YY is the year and MM is the month number. E.g.,
for February 1996 traffic get the file djgpp.9602.gz. Alternatively, look for the file which holds list traffic for the year and the month you need with
your Web browser. Once you have the Newsgroup archives, or a relevant portion(s) thereof, search for your problem by using some
keywords specific to your problem, like "crash", "violation", etc. The archive is just a text file, so any text file viewer/editor with search capability can do it.
Q: I don't have time to download all these huge files, not to mention looking through them. Can't you DJGPP gurus help me? Please??
bin/ subdirectory) and save its output.
ENVIRON.LST, the output of go32-v2, the contents of your AUTOEXEC.BAT and CONFIG.SYS, and what GCC printed during
compilation with the -v switch.
| Without optimization | With -O2
-----------+------------------------+------------
C++ source | 200 | 100
-----------+------------------------+------------
C source | 430 | 250
(Btw, these numbers are about 20% faster than you will get on a 40MHz Sparc2 box.) On machines faster or slower than 486DX2-66, scale these numbers appropriately. When comparing to this table,
don't forget to count header files your program #include 's in the total line count. And don't check compilation speed on very short programs (like the classic
"Hello, world!"), because the overhead of loading the multiple passes of the compiler will completely hide the compiler performance.
If your results are close to these (deviations of a few percents are considered "close" here), then that's as fast as you can get with GCC. If they are significantly lower, you may indeed have a problem; read on.
First, check to see if GCC pages to disk when it compiles. This is manifested by a heavy disk traffic which won't go away even if you have a large write-back disk cache installed. To be sure, disable the virtual memory services for your DPMI host (for CWSDPMI, use the SWSDPR0 as your DPMI host, or get the CWSPARAM program and change the swap filename to point to a non-existent drive), then run the compilation again: if the compiler aborts with an error message saying there isn't enough memory, then it is paging.
If paging does happen, you need to free more extended memory. If you have a RAM disk, make it smaller, or don't use it at all (it only makes compiles to run about 10% faster), or make your disk cache smaller (but don't discard the disk cache altogether); if you have other programs which use extended RAM, make them use less of it. Failing all of the above, buy more RAM (see the description of reasonable configuration). Also see recommendations for optimal software configuration.
If GCC doesn't page, check settings of your disk cache. If you don't use a cache, install one--this can slash your compilation times by as much as 30%, more so when compiling a large number of small files. If you already have a cache, enable its delayed-write (aka write-back, aka staggered-write) operation.
If you had some of the beta releases of v2.0 installed during the beta-testing period, be sure to upgrade your CWSDPMI to the latest version. The memory allocation scheme has been changed halfway through the beta-testing, which made old versions of CWSDPMI awfully slow when used with programs linked against the new library versions.
It is also worthwhile to check the settings of your system BIOS. In particular, the following items should be checked against your motherboard vendor recommendations:
Internal and external CPU cache....set to Enable
CPU cache scheme...................set to Write-back, if possible
DRAM and SRAM wait states..........vendor-recommended optimal values
Incorrect or suboptimal settings of the above items can explain as much as 30% performance degradation on 486 machines, and as much as 500% (!) if you have a Pentium CPU. DJ Delorie reports that his well-tuned 90 MHz Pentium system with 32 MBytes of RAM and 4 MBytes of RAM disk compiles the entire GCC source in about 20 minutes (this takes about 45 minutes on a 40MHz Sparc2).
For very large (several MBytes) executables which are built from a large number of small source files, the link stage might be the one which needs more RAM than you have free, and thus be the bottleneck of the time it takes to build your program. Check that the size of the executable isn't larger than the amount of your free RAM. If it is, then it might make sense to use a smaller (or even no) disk cache, and allow the linker as much physical RAM as it needs. Be sure that the linker wasn't stub-edited to make its transfer buffer too small (the default 16KB should be more than enough).
This chapter explains how to solve some of those problems which tend to appear when compiling and linking your programs.
| Previous | Next | Up | Top |
DJGPP=c:/djgpp/djgpp.env
and it should point to the correct path of the file DJGPP.ENV on your system (the file itself comes with the file
djdev200.zip in the DJGPP distribution). In the above example it is assumed to be in the C:/DJGPP directory, but
you should set it as appropriate for your installation. If the DJGPP variable is set correctly, then check the following possible causes of this misbehavior:
gcc.exe driver to some other name. For example, you might be using the real-mode GCC and call it something like gcc-rm.exe, so you could use the
protected-mode version also. In this case, you should edit the file DJGPP.ENV to add a section called (in our example) [gcc-rm] which is an exact duplicate of the section
called [gcc]. DJGPP start-up code uses this file to find environment variables which it should put into environment before your main function is called, but it searches
for the relevant variables using the actual name of the program, so when you rename the executable, it can't find its section and doesn't put the necessary variables into the environment.
CONFIG.SYS is insufficient, so GCC runs out of available handles.
You should have at least FILE=15 in your CONFIG.SYS.
| Previous | Next | Up | Top |
iostream.h, _string.h and other C++ headers. Where can I find those header files?
Q: GCC complains about it being unable to find Complex.h, Regex.h and other header files which start with a capital letter, and I indeed don't see them
in my lang/cxx/ directory. Where are they?
Q: My C++ program needs header files whose filenames exceed the 8+3 DOS filename restrictions, like stdiostream.h and streambuf.h, and GCC cannot find
those files. How in the world can I write portable C++ programs??
complex.h, regex.h and the like under case-insensitive DOS. Change Complex.h
to _complex.h in your source, and GCC will find them.
If you have problems with header files with long filenames, and you run under Win95 or some other environment which allows for long filenames, try disabling the Long File Names (LFN)
support in DJGPP, by setting the LFN environment variable to No, like this:
set LFN=n
(DJGPP comes with LFN disabled by default on the DJGPP.ENV file, but you might have enabled it.) If this makes the problems to go away, then you have some conflict between the way LFN
is supported by DJGPP and your environment. Under Win95, you must rename the files which should have long filenames to those long names (as opposed to the truncated names you find in the DJGPP
archives). You must also set the option in the Win95 registry which disables name-munging of the files which have exactly 8 characters in their name part. This is how:
HKEY_LOCAL_MACHINE branch of the registry until you see in the left pane an item called HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem,
then click on it.
FileSystem key. If you don't see an item there called NameNumericTail, select "New", "Binary Value" from
the "Edit" menu, then type NameNumericTail and it will appear. Now double-click on NameNumericTail and enter a value of 0.
| Previous | Next | Up | Top |
#include <stdio.h>
int
main ()
{
printf ("%d \n" 10 //*
/ 2 //*/
1
);
return 0;
}
(While admittedly perverse, this little monstrosity was written with a the sole purpose to demonstrate that C and C++ have quite different semantics under certain circumstances.) If you must have both -ansi and C++-style comments, you can use the -lang-c-c++-comments preprocessor switch. Gcc doesn't accept the -lang-XXX switches on its command line, so you will have to use the -Wp option, like this:
gcc -c -Wp,-lang-c-c++-comments myprog.c
Alternatively, you can add -lang-c-c++-comments to the *cpp: section of your lib/specs file (but that will make it permanent). Bottom line: until the future ANSI/ISO C standard includes this as part of the C language, it's best to change those comments to C-style ones, if you really mean to write a C program. The following Sed command will convert a C program with C++-style comments into a valid C source, provided you don't have the string "//" in a character string:
sed "s?//\(.*\)?/*\1 */?" file.c > newfile.c
Sed can be found in the DJGPP distribution.
| Previous | Next | Up | Top |
PROG.CC's file format. How come a C++ compiler doesn't recognize a C++ source?? Q: I type GCC PROG.C to compile a C program which I already remember to pass compilation without a single warning, and suddenly it gives all kinds of strange error messages and unresolved externals.
PROG.C is taken as C++ program, not a C one, and PROG.CC is passed to the linker as if it were an object file. You can see what GCC does by adding
-v switch to the GCC command line; if you see it's invoking cc1plus.exe (the C++ compiler) instead of cc1.exe (the C compiler), or calling ld.exe
(the linker) on a source file, then you'd know this is your problem. If you have problems keeping up with the verbose GCC output caused by -v, see how to capture GCC
output, in this FAQ. You can override the default rules gcc uses to decide how each input file should be treated, with the help of -x LANGUAGE switch. For instance, the command
gcc -x c++ prog.c
compiles prog.c as a C++ source. See the "Overall Options" section of the "The GNU C Compiler Manual", for more info on
-x options.
| Previous | Next | Up | Top |
Q: I compile an Objective-C program, but get unresolved symbols.
Q: I can't compile the Objective-C test program which came with DJGPP.
.m extension, or use -x objective-c switch to GCC, so it will know you mean to compile with Objective C. Objective-C was broken in GCC 2.6.0. The problem manifests itself by unresolved modules. If you use that version, you'll have to upgrade to version 2.6.3 or higher.
| Previous | Next | Up | Top |
#ifdef directive to make it only visible under DJGPP?
__DJGPP__, like this:
#ifdef __DJGPP__
... DJGPP-specific code ...
#else
... not seen under DJGPP ...
#endif
__DJGPP__ has a value of the DJGPP major revision number, so you can write code fragments which have different behavior under different versions of DJGPP:
#ifdef __DJGPP__
#if __DJGPP__ > 2
.... will work only in DJGPP v3.x and later ...
#else
.... get here for DJGPP v2.x ...
#else
.... get here in DJGPP v1.x or non-DJGPP environment
#endif
Another DJGPP-specific pre-processor symbol which DJGPP defines is __GO32__ ; but it is only provided for compatibility with previous versions of DJGPP (v1.x) and its use should be
discouraged.
| Previous | Next | Up | Top |
libgcc.a and libc.a. Some functions aren't included there, so the linker can't
find them. GPL library routines, like obstack and regex packages are in libgpl.a library; append -lgpl to the link command line to use them. To use C++ classes in the
libgpp.a (it's called libg++.a on Unix systems), append -lgpp. If you only use the iostream classes and don't want your program to be affected by
the GNU Copyleft, use the libiostream.a library by appending -liostream (these are also included in the libgpp.a library). When linking C++ programs, you can use the gxx instead of gcc command; it will then instruct the linker to also scan the C++ libraries.
If your program uses a lot of floating-point math, or needs math functions beyond those specified in the ANSI/ISO standard, consider appending -lm to your link command line. The basic
math functions required by ANSI/ISO standard are included in the libc.a library, but libm.a includes higher quality versions of these functions, and also some functions not
included in the default library, like Gamma function and Bessel functions.
| Previous | Next | Up | Top |
T before their name. For example, the following is a fragment from the listing produced by nm:
c:\djgpp\lib> nm --demangle libc.a
.
.
.
stdio.o:
000000e4 b .bss
000000e4 d .data
00000000 t .text
00000098 t L12
0000001e t L3
00000042 t L6
0000004d t L7
0000006a t L9
00000000 t __gnu_compiled_c
U _filbuf
U _flsbuf
00000000 T clearerr
000000ac T feof
000000c2 T ferror
000000d8 T fileno
0000000c T getc
00000052 T getchar
0000002a T putc
0000007c T putchar
00000000 t gcc2_compiled.
.
.
.
Here we see that the module stdio.o defines the functions clearerr, feof, ferror, fileno, getc,
getchar, putc and putchar, and calls functions _filbuf and _flsbuf which aren't defined on this module.
Alternatively, you can call nm with the -s or -print-armap, which will print an index of what symbols are included in what modules. For instance, for
libc.a, we will see:
c:\djgpp\lib> nm --print-armap libc.a
.
.
.
_feof in stdio.o
_ferror in stdio.o
_fileno in stdio.o
.
.
.
which tells us that the functions feof, ferror and fileno are defined in the module stdio.o. nm is fully described in the GNU docs. See the "nm" section of the "GNU Binutils Manual".
| Previous | Next | Up | Top |
-lgpp -lgpl -lm
E.g., to link files main.o and sub.o into a C++ library, use the following command line:
gcc -o main.exe main.o sub.o -lgpp -lgpl
or, if you compile and link in one command:
gcc -o main.exe main.cc sub.cc -lgpp -lgpl -lm
If you have any libraries of your own, put them before the above system libraries, like this:
gcc -o main.exe main.cc sub.cc -lmylib -lgpp -lgpl -lm
When you use the gxx compilation driver to compile a C++ program, it names the C++ libraries in the correct order.
If your installation tree is different from the default, i.e., if you keep the libraries not in the default lib/ subdirectory, then you should add that directory to the
line in the [gcc] section of your DJGPP.ENV file which starts with LIBRARY_PATH, or put into your environment a variable called LIBRARY_PATH and
point it to the directory where you keep the libraries. Note that if you invoke the linker by itself (not through the gcc driver), then LIBRARY_PATH will have no effect, because this
variable is only known to the gcc driver. So if you must call ld from the command line, use the -L option to tell it where to look for the libraries.
| Previous | Next | Up | Top |
complex.h and iostream.h.
inline and defined on these header files. However, GCC won't inline them unless you compile with optimizations enabled, so it tries
to find the compiled version of the functions in the library. Workaround: compile with -O.
| Previous | Next | Up | Top |
libgcc.a library which lacks a module called ___pure_virtual (yes, with three leading underscores!). You
should get an updated version of that library which includes such a module. libgcc.a comes with the Gcc distribution, so look in the latest gccNNNb.zip file.
If, for some reason, you cannot find libgcc.a with that module, you can add it yourself. To this end, create a file called pure.c with this content:
#define MESSAGE "pure virtual method called\n"
void __pure_virtual()
{
write(2, MESSAGE, sizeof(MESSAGE) - 1);
_exit(-1);
}
Compile this file and put the object file into libgcc.a, like this:
gcc -c pure.c
ar rvs libgcc.a pure.o
That's all!
.exe file
static array has an effect of bloating the program image on disk by that many bytes. Surely there is a more compact way of
telling the loader to set the next N bytes of RAM to zero?
If the downside of using this switch doesn't deter you, you can even add this switch to your lib/specs file to make it permanent.
| Previous | Next | Up | Top |
Q: My v2.0 program crashes, but only under CWSDPMI; it runs OK under other DPMI hosts like Windows, OS/2 or QDPMI. Is this a bug in CWSDPMI?
malloc is always zeroed, but v2.0 doesn't behave this way, so your program might exhibit erratic behavior or crash with
SIGSEGV because of such bugs. In particular, if the program behaves differently depending on which program was run before it, you might suspect bugs of this kind.
To check whether this is the source of your grief, include the header crt0.h in your main and set _crt0_startup_flags to
_CRT0_FLAG_FILL_SBRK_MEMORY ; this will fill the memory with zeroes when it is first allocated. If the program will run OK after recompilation, then this is probably the cause of your
problem. To make spotting uninitialized memory simpler, you can set _crt0_startup_flags to _CRT0_FLAG_FILL_DEADBEAF (don't laugh!) ; this will cause the
sbrk()'ed memory to be filled with the value 0xdeadbeaf which is easy to spot with a debugger. Any variable which has this value, was used without initializing it first.
Another possible cause of problems will most probably be seen under CWSDPMI. Unlike other DPMI hosts, CWSDPMI supports some DPMI 1.0 extensions which allow DJGPP to capture and disallow illegal
dereference of pointers which point to addresses less than 1000h (aka NULL pointer protection). This feature may be disabled by setting the _CRT0_FLAG_NULLOK bit in
_crt0_startup_flags ; if this makes SIGSEGV crashes to go away, your program is using such illegal pointers.
| Previous | Next | Up | Top |
bin/ subdirectory). To this end, make sure that your program was compiled with
-g switch, linked without -s switch and not stripped, and that you have the source files available in your current directory. Now invoke
your program and do whatever it takes to make it crash. Then, with the traceback still on the screen, type this from the DOS command line:
symify your-program-name
You will see the list of source files and line numbers right next to their hex addresses. Now you can start debugging. You can ask SYMIFY to put the stack trace into a file (so you can consult it later, e.g., from your editor while fixing the bug), by giving it an output file, like this:
symify -o problem.dmp yourprog
You can also save the raw stack trace (without source info) to a disk file and submit it to SYMIFY later, like this:
symify -i core.dmp yourprog
This comes in handy when your program grabs the screen (e.g., for some graphics) and the stack trace can't be seen. You can then redirect the stack trace to a file, e.g.,
with theREDIR program which comes with DJGPP. But what if you didn't compile your program with -g, and you aren't sure how to recreate the problem which crashed it, after you recompile? Well, you can submit the stack dump after you recompile your program. Just press that PrintScreen key or otherwise save the stack trace, then submit it to SYMIFY from a file as described above, after you've recompiled the program. Be sure to give gcc all the compilation switches (sans -s) that you gave it when you originally compiled your program (in addition to -g), including the optimization switches, or else the addresses shown in the stack trace might be invalid.
| Previous | Next | Up | Top |
Q: When I read a file I get only a small portion of it.
read and write library functions. Text files get their
Newlines converted to CR-LF pairs on write and vice versa on read; reading in "text" mode stops at the first ^Z character. You must tell the system that a file is
binary through the b flag in fopen, or O_BINARY in open, or use the setmode library function.
You can also use the low-level _read and _write library functions which give you the direct interface to the DOS file I/O.
| Previous | Next | Up | Top |
fprintf, fputs and the like) functions? Then maybe your program defined a large buffer for standard
output streams. If so, the buffer is not written to screen until it's full, which might produce very unpleasant and unexpected behavior when used in interactive programs.
It is usually bad idea to use buffered I/O in interactive programs; you should instead use screen-oriented functions like cprintf and cputs . If you must use buffered
I/O, you should be sure that both stdout and stderr are line-buffered or unbuffered (you can change the buffering by calling the setvbuf library
function); another solution would be to fflush the output stream before calling any input function, which will ensure all pending output is written to the operating system. While this
will work under DOS and DJGPP, note that some operating systems (including some DOS extenders) might further buffer your output, so sometimes a call like sync would be needed to
actually cause the output be delivered to the screen.
CWSDPMI.EXE free DPMI host to the target machine and put it in the same directory as your compiled program or somewhere
along the PATH, or (2) install another DPMI host (such as QDPMI, 386Max, Windows, etc.) on the target machine. Note that the author of CWSDPMI,
Charles W Sandmann, requests a notification by mail or acknowledged e-mail in case you distribute CWSDPMI with a commercial or shareware products. If your program could be run on a machine which lacks floating-point processor, you should also distribute an emulator, or link your program with an emulator library. See floating-point emulation issues.
Future DJGPP releases might have a way to bind your executable with CWSDPMI to produce a stand-alone program. If you need such a feature now and if you need it badly, ask Charles W Sandmann to make this happen as soon as he can.
0xa0000, but get "Segmentation violation" ... Q: How can I access the text-mode video memory of my VGA?
_farpeekb and _farpokew ; they are described in the C Library reference. See more details on using "farptr" functions to access absolute addresses in
low memory, below.
For text-mode screen updates, you can also use the ScreenUpdate and ScreenUpdateLine library functions to quickly update the screen from a text buffer.
Using _farpeekX / _farpokeX paradigm to access memory isn't much slower than direct access (they compile into 2 machine instructions when optimizations are enabled). But
if you need even more fast access (and don't want to write it in assembly), See using the "nearptr" access facilities, as described below.
| Previous | Next | Up | Top |
Q: What shall I install on a target machine which lacks hardware floating-point support?
libemu.a emulation library (add
-lemu to your link command line) or be allowed to dynamically load the emu387.dxe file at run-time if needed. Linking with libemu makes distribution simpler at a price of
adding about 20KB to the size of the program .exe file (the emulator functions will be used only if no hardware floating point support is detected at runtime). You should
always do one of the above when you distribute floating-point programs. A few users reported that the emulation won't work for them unless they explicitly tell DJGPP there is no x87 hardware, like this:
set 387=N
set emu387=c:/djgpp/bin/emu387.dxe
There is an alternative FP emulator called WMEMU (get the file v2misc/wmemu2b.zip). It mimics a real coprocessor more closely, but is larger in size and is distributed under
the GNU General Public License (which generally means you need to distribute its source if you distribute wmemu387.dxe, or distribute the source or objects to your entire program, if you
link it with libwmemu.a). Its advantage is that with WMEMU, you can debug FP apps on a non-FPU machine.
| Previous | Next | Up | Top |
AUTOEXEC.BAT, but DJGPP-compiled floating point programs still doesn't work. Why?
| Previous | Next | Up | Top |
| Previous | Next | Up | Top |
| Previous | Next | Up | Top |
_control87 which can be used from within a program to set the coprocessor to a non-default state.
atan function. So if you use atan(1.) to get the value of Pi, that might be your problem. Solution: make Pi a constant, as God intended. The
header file includes the constant M_PI which you can use; or get the value of Pi from the net.
| Previous | Next | Up | Top |
gcc -Wall -c -g -O myfile.c
gcc -Wall -O2 -g -o myprog mymain.c mysub1.c mysub2.c -lm
gcc -g -o myprog myprog.o mysub.o
(Note that with gcc, you can use optimization switches when compiling with -g.)
Then, to debug the program, use a command line like this (here for gdb):
gdb myprog
You can use on of several available debuggers with DJGPP:
gdb.ini instead of .gdbinit which is illegal filename under MS-DOS.
<debugger-name> <program> <args...>
| Previous | Next | Up | Top |
qdpmi off
| Previous | Next | Up | Top |
.exe program. GDB needs to be called with the name of un-stubbed COFF executable as its argument. To get both a
.exe and a COFF file, you should make your link command line to look this way:
gcc -o foo foo.o
instead of
gcc -o foo.exe foo.o
(the latter will only produce foo.exe, while the former produces both foo, the COFF executable which gdb needs, and foo.exe).
To produce a COFF file from a .exe program, use the EXE2COFF program which comes with DJGPP, like this:
exe2coff foo.exe
| Previous | Next | Up | Top |
To work around this, don't step with the debugger through your functions which use the transfer buffer.
If all of the above doesn't make sense for you, don't worry: if you don't know what the transfer buffer is, and you only trace into your own functions, then you won't hit this problem.
| Previous | Next | Up | Top |
gdb myprog > prn
This will only work if the program itself doesn't write to stdout (this is usually the case with graphics programs); otherwise the debugger output will get mixed up with your program's output. The FSDB debugger can switch between the application screen and the debugger screen, so you might use it, at a price of working with low-level debugger. Press Alt-F5 to switch between the two screens.
As yet another possibility, consider using the MSHELL program which will redirect I/O from any program to the monochrome, monitor at the BIOS level, so you can use it even with GDB. MSHELL was written by DJ Delorie and is available as mshell10.zip.
| Previous | Next | Up | Top |
.cc source
file.cc: No such file or directory.
The source file is there, but it's called file.cpp, not file.cc. Why does this happen?
.cc extension. Until this bug is corrected in some future version of GCC, you're better
off calling your C++ files *.cc. If this is unacceptable, then you can work around this bug by invoking cc1plus and the assembler pass manually. The bug in GCC manifests
itself in that cc1plus is called with the option -dumpbase file.cc. If you replace this with -dumpbase file.cpp (or whatever your extension is), the debugger
will happily find your sources.
Q: I cannot debug any program which catches signals!!??
Q: I compiled my program with -pg switch, and now I cannot debug it...
symify can identify; programs using alarm or setitimer can't be debugged, either. You can't hook the keyboard interrupt in a debugged
program, and you can't debug a program which uses floating point on a machine without an FP hardware (unless you use WMEMU as your emulator). If your program catches signals, the
debugger will catch them instead and they won't get passed to the debuggee. At least some of these limitations will be fixed in future versions of DJGPP. For now, the only work-around that's available is for the case that you need a Ctrl-C keypress to go to the debuggee instead of the debugger: use the Alt-Numeric-3 (that is, simultaneously press the Alt key and the 3 key on the numeric keypad, then release the Alt key).
| Previous | Next | Up | Top |
gprof myprog
(change myprog to whatever name your program is). This will print an execution profile. Gprof is part of GNU Binutils distribution.
| Previous | Next | Up | Top |
Q: I run Gprof on my program, and it says: "bad format".
.exe file instead, it will be most
unhappy. The way to produce the COFF output is explained in the section dealing with GDB, above.
| Previous | Next | Up | Top |
Q: I can't figure out some of the info in Gprof report ...
gprof.1. If you don't have one, you will have to look for it in the
Binutils distribution.
__dpmi_int so heavy used?
__dpmi_int . Can't you guys make
your library right?
__dpmi_int . So what the profile really says is that the running time of your program is governed by time-consuming operations such as disk I/O.
| Previous | Next | Up | Top |
Q: Won't my program run much slower when compiled by DJGPP, due to all those CPU cycles wasted in switches between protected and real mode?
| Previous | Next | Up | Top |
Q: I tried to improve DJGPP I/O throughput by defining a 64KB-large buffer for buffered I/O with a call to setvbuf, but that had no effect. Why is that?
That said, I would like to point out that waiting another 0.5sec for reading a 2 MByte file isn't that bad: it is indeed about 25% longer than you can do under DOS, but it's only half a second... Besides, most programs read and write files which are only a few hundreds of kilobytes, and those will suffer only a negligible slow-down.
You can tell how much your program switches to real mode by profiling your program. In the profile, look at the proportion of time your program spends in low-level library functions called
__dpmi_int (which calls real-mode DOS/BIOS services) and __dj_movedata (which moves data between the transfer buffer and your program). If this proportion is large, try
rewriting your program to minimize use of those functions which require a mode switch, even at a price of more computation (a mode switch usually eats up hundreds of CPU cycles).
| Previous | Next | Up | Top |
malloc(50*1024*1024) some day.
With other DPMI hosts, your mileage may vary. Quarterdeck's QDPMI, for instance, has a bug in some of its versions which effectively disables virtual memory under DJGPP (described under
QDPMI VM bug, below), so you only have whatever free physical RAM is left. Under Windows 3.x, the amount of virtual memory you get depends on various virtual memory settings
in the Control Panel and on the .pif file settings for the program you run (see Windows allocation subtleties, below).
| Previous | Next | Up | Top |
malloc / free don't affect virtual memory...
malloc(50*1024*1024), but didn't see any paging happen, and I only have 8 MBytes of RAM on my machine. Is this virtual memory thing for real?
Q: I malloc 'ed a large chunk of memory, but when I check values returned by _go32_remaining_physical_memory or
__dpmi_get_memory_information, I don't see any change...
Q: When I free allocated RAM, _go32_remaining_physical_memory reports there was no change in the available RAM.
malloc it, but don't actually access it, it won't grab
those pages. Try calloc and see the big difference.
When you call free, DJGPP library doesn't return memory to the system, it just adds it to its internal pool of free pages. So, from the system point of view, these pages are not
"free".
| Previous | Next | Up | Top |
malloc returns a NULL pointer, or I get some cryptic error message like this:
DPMI: Not enough memory (0x00860000 bytes)
or like this:
QDPMI: Memory Paging Violation: Illegal Page Reference [PTE=0000-0000h]
[CR2=8006-3000h at 00E7h:0000-4936h]
QDPMI: Unrecoverable Exception: 000Eh at 00E7h:0000-4936h. Error Code = 0006h
This bug was corrected in QDPMI version 1.10 or later, distributed with QEMM beginning with version 8.0, so upgrading to the latest version of QEMM might also be a solution. With QEMM 6.x, make sure
your programs don't override the default type of sbrk behavior by setting _crt0_startup_flags to _CRT0_FLAG_UNIX_SBRK (QEMM 8.0 and later can allocate
virtual memory with both types of sbrk algorithm).
If you use another DPMI host, make sure that virtual memory is enabled. E.g., for 386Max, include the swapfile= parameter to establish a virtual memory swap file; you can make it permanent (this will speed up DJGPP start-up) with the /p option.
| Previous | Next | Up | Top |
NULL pointer from malloc / calloc !
With some DPMI providers, this behavior might be triggered by a small overhead of each malloc call: you might ask for half of available memory, but the DJGPP implementation of
malloc adds the overhead and then rounds the amount of memory to the next power of 2 before calling sbrk ; thus malloc(8MB + 1) will actually request
16MBytes from the DPMI host. When in doubt, call sbrk directly, especially if you don't plan to free that memory during execution.
| Previous | Next | Up | Top |
PageOverCommit=n
in the [386Enh] section of your SYSTEM.INI file. The parameter n is 4 by default, but can be set to be as large as 20.
| Previous | Next | Up | Top |
Q: I have 5 MBytes of free RAM on my machine, but DJGPP programs start paging after only 256KBytes of memory were used??
If your programs start paging after only 256KBytes of memory were used, most probably you are using EMM386 and CWSDPMI, and your CONFIG.SYS specifies no amount of memory when it installs
EMM386. EMM386 defaults to 256K in this case; you should tell EMM386 explicitly how much memory should it take over. You can use the go32-v2 program to see what amount of extended
memory your DJGPP programs will get.
| Previous | Next | Up | Top |
system call?
system (like in recursive invocation of Make) eats up about 18K (16K for the transfer buffer and 2K for the PSP and environment) for most DPMI servers; a
notable exception is QDPMI which needs 97K bytes of low memory for the subsequent calls too. If you change the size of the transfer buffer (with STUBEDIT ), the amount of free
conventional RAM will change accordingly.
Extended memory management is left to the DPMI server; DJGPP does nothing special about XMS when system is called. This means that all the extended memory used by the parent program
is not freed when the child program starts; if the child requests more memory than is physically free, the DPMI server is expected to page some of the parent out to honor the
request. (This is unlike DJGPP v1.x, where the go32 extender would completely page out the parent before starting the child.) The advantage of this is that spawning a child or
shelling out is much faster in v2.0 than it used to be with v1.x.
Q: How much stack space do I have in my program?
Q: My program crashes with SIGSEGV, but the traceback makes no sense: it points to something called ___djgpp_exception_table... When I try to debug this, the traceback mysteriously changes to some innocent library function, like getc(). The same program works flawlessly when compiled with DJGPP v1.x What's going on??
_stklen in your program. Example:
extern unsigned _stklen = 1048576;
Setting _stklen makes sure your program always works, but wastes memory, since the 256K stack originally allocated must be discarded. The best bet is to do both--setting
_stklen in your program will ensure it works, but also using STUBEDIT to set a slightly (by a few KB) larger amount than the value of _stklen, will ensure
the original stack won't have to be reallocated, and you will save the wasted memory.
Programs which needs an unusually large stack might crash with bogus stack trace, because parts of the heap get overwritten by the overflowing stack. To see if that is the cause of such crashes, run
stubedit on your program and crank up the stack size to a large value (like 4MBytes). If that makes the problem go away, tune the stack limit to the minimum value your program can live
with, then set _stklen to an appropriate value as explained above. (Some DPMI hosts will actually allocate the stack, even if not all of it is used, so leaving it at unnecessarily
large value will hurt the program on low-memory machines.)
Some users have reported that they needed to enlarge the stack size of the C++ compiler, cc1plus.exe, to prevent it from crashing when compiling some exceedingly large and complex C++
programs. Another program that was reported to need a stack larger than the default is bccbgi.exe from the BCC2GRX package.
After you've used STUBEDIT to change the stack size, run it again to make sure it displays as default the value you thought you entered. This is because STUBEDIT will sometimes silently set the stack size to 0 (and then you will get the default 256K stack) if it doesn't like the value you type.
Under Windows, be sure you've allocated a sufficiently large swap file (let's say, 40MBytes) from the Windows' Control Panel.
You should also make sure the .PIF file for your program doesn't have too low limit on EMS/XMS usage (better make them both -1). What's that? You don't have a .PIF file
for this program? Then Windows uses the default DOSPROMPT.PIF, which almost surely defines very low limits on these two, and your program can't get the memory it needs for its stack.
| Previous | Next | Up | Top |
Q: I call my program with an argument x*y and it complains about something called xyzzy??...
main function is called. Unlike other DOS-based compilers, where you must link your
program with a special object module if you want the program to get expanded filenames, in DJGPP this is considered normal behavior and performed by default on behalf of every DJGPP program. The
x*y above was expanded to a file called xyzzy which was probably present in the current working directory. (If you don't want the default expansion, see
how to disable globbing.) In DJGPP, filename globbing works like in Unix, which is more general than the usual DOS wildcard expansion. It understands the following constructs with special meta-characters:
An argument which cannot be expanded (no filenames matching that particular pattern) will be passed to the program verbatim. This is different from what you might see under Unix, where some shells (like csh) would say something like "No match" and won't call your program at all. DJGPP's behavior in this case is like shells of the Bourne legacy (sh, ksh, and bash).
| Previous | Next | Up | Top |
__crt0_glob_function and make it always return a NULL
pointer. See the documentation of this function in the library reference.
| Previous | Next | Up | Top |
Q: How do I pass a command-line argument which contains double quotes?
Q: How do I pass an argument which begins with the @ character?
main (see description of
filename expansion), and the quote characters serve to protect the arguments from expansion. You should escape-protect the quote characters with a backslash. For example, if you have a file
called myfile.c'v, type it as myfile.c\'v when you call your program. If you have single quotes in your program arguments and you don't want those arguments to
be expanded, then surround them by double quotes, like this: "*.c\'v". The program will get the string *.c'v with the double quotes stripped away. Note that backslashes are only special if they are in front of a quote, whitespace, or backslash (they also serve as DOS directory separators, remember?).
The @ character serves to signal a response file (see the description of response file method), so it's also special. To pass an argument whose first character is @, surround that argument with single or double quotes, otherwise it will be taken as a name of a response file which holds the actual command line.
| Previous | Next | Up | Top |
Q: I have a Makefile of Unix origin which contains some very long command lines. Will it work with DJGPP?
This method is suitable only for invoking DJGPP programs from other DJGPP programs. You don't have to do anything special to use this method, it is all done automagically for you by the library
functions like system, spawnXX and execXX on the parent program side, and by the start-up code on the child side.
Note: In case you wonder, the name !proxy comes from the the string which identifies the use of this method: instead of getting the actual command line, the program gets !proxy followed by the address of the actual command line.
_argc, _argv0, _argv1, etc. Note that the variables' names are indeed all-lowercase, which means you cannot use this method
from DOS COMMAND.COM prompt.
This method is suitable for invoking DJGPP programs from GNUish ports of GNU software, like
real-mode Make program found on SimTel mirrors, some ports of Unix shells (like
ms_sh), etc. You can also use it in your real-mode programs by creating the above environment variables.
Note that DJGPP programs can only use this method, but they don't generate GNUish-style environment variables, so you cannot use this method to pass long
command lines between DJGPP and non-DJGPP programs, unless your program explicitly creates these variables before calling execXX / spawnXX .
Note that this method makes @ special when it is the first (or the only) character of a command-line argument, which should be escape-protected if you want to use it verbatim (see how to pass the @ character).
| Previous | Next | Up | Top |
This limit depends on the size of the transfer buffer, so check how large is the value recorded in the stub header of any program before you pass it extremely long command lines. The linker
(ld.exe) is the first program you should worry about, because it usually gets long command lines (they include the list of all the object files and libraries to be linked).
SHELL = command.com statements, or for commands which include pipe or redirection characters like >, |, etc. If
Make sees any such statements, it will invoke COMMAND.COM to run GCC, and COMMAND.COM can't pass more than 126 characters to GCC. To work around, comment-out the
SHELL= line, and change your commands to work without redirection/pipe characters.
| Previous | Next | Up | Top |
as.exe), or Gas, called by GCC accepts AT&T syntax which is different from Intel syntax. Notable differences
between the two syntaxes are:
$ ; Intel immediate operands are undelimited (Intel push 4 is AT&T pushl $4 ).
% ; Intel register operands are undelimited. AT&T absolute (as opposed to PC-relative) jump / call operands are
prefixed by * ; they are undelimited in Intel syntax.
add eax, 4 is addl $4, %eax in AT&T syntax.
The source, dest convention is maintained for compatibility with previous Unix assemblers, so that GCC won't care about the assembler with which it is configured, as part of GCC
installations don't use GNU Binutils.
b, w, and l specify byte
(8-bit), word (16-bit), and long (32-bit) memory references. Intel syntax accomplishes this by prefixing memory operands ( not the opcodes themselves) with `byte ptr',
`word ptr', and `dword ptr' . Thus, Intel mov al, byte ptr FOO is movb FOO, %al in AT&T syntax.
lcall/ljmp $SECTION, $OFFSET in AT&T syntax; the Intel syntax is call/jmp far SECTION:OFFSET . Also, the far return
instruction is lret $STACK-ADJUST in AT&T syntax; Intel syntax is ret far STACK-ADJUST .
SECTION:[BASE + INDEX*SCALE + DISP]
is translated into the AT&T syntax
SECTION:DISP(BASE, INDEX, SCALE)
Intel: [ebp - 4] AT&T: -4(%ebp)
Intel: [foo + eax*4] AT&T: foo(,%eax,4)
Intel: [foo] AT&T: foo(,1)
Intel: gs:foo AT&T: %gs:foo
For a complete description of the differences, get and unzip the files named as.iN (where N is a digit) from the
bnu252b.zip archive, then See the "i386-Dependent" section of
the "GNU assembler documentation". If you don't read this FAQ with an Info browser, type at the DOS prompt:
info as machine i386
You will see a menu of Gas features specific to x86 architecture.
| Previous | Next | Up | Top |
movl instead of mov, even if you're sure the arguments are 32-bit wide. The fact that you use byte registers doesn't seem to matter
with Gas.
.byte constants, not as e.g. %cs:. According to Charles Sandmann, Gas uses
the current phase of the moon in deciding whether to ignore your prefixes. So unless you know exactly what is the phase of the moon at the moment of assembly, use .byte
constants.
| Previous | Next | Up | Top |
.lib library, then extracting them as COFF files.
Note: If you use MASM or LIB32, please post your experiences to the comp.os.msdos.djgpp, so that I could make the above instructions less vague.
Keep in mind that syntax is only one of the aspects of converting code written for DOS to DJGPP. You should also make sure your code doesn't violate any rules for protected-mode programming (see next question).
| Previous | Next | Up | Top |
Here is a short list of some of the techniques found in many real-mode programs, which will trigger protection violation or erratic behavior in protected mode:
INT NN instruction.
| Previous | Next | Up | Top |
.obj or .lib code with DJGPP
.obj format, but no source code. Can I use them with my DJGPP program?
Q: I have this ACMELUXE.LIB library of functions which I want to use. I've extracted all the .obj files, but when I try to link them with my program,
GCC complains: "File format not recognized". Can't I use these object files?
Q: I've got a bunch of .obj files I want to use. I've ran AR to make a GCC-style .a object library, but got an error message from GCC saying "couldn't
read symbols: No symbols". How can I link them with my code?
.obj files which other DOS-based compilers/assemblers emit. Unless you
can get the source of those functions, convert it to protected-mode, flat-address model code and compile them with GCC, you most probably won't be able to use them. Lately, an automated conversion
tool called OBJ2COFF was written by Jan Oonk which can be used to convert .obj object files and .lib libraries to
COFF format, provided that the original .obj files must have been written for flat-address memory model. (You can also try using LIB32 librarian from Microsoft C8 to
convert object files to COFF.) The main problem, of course, is that most such object files were written for real-mode programs in memory models other than flat, and without extensive modifications
would crash your program anyway... (See previous question.) OBJ2COFF is available from the OULU repository and from the DJ Delorie's ftp server.
.obj files. Are you really sure there is
nothing I can do??
spawnXX function call. You can also call 16-bit functions directly with the library function called
__dpmi_simulate_real_mode_procedure_retf, provided the 16-bit program passes the CS:IP values of these functions to the 32-bit program. You can even put your 16-bit code as binary
instructions into a buffer allocated in low memory and call it with __dpmi_simulate_real_mode_procedure_retf (but if you can do that, you probably can also disassembly the code into a
source form and submit it to Gas). Now will you consider to stick with DJGPP? Please??...
| Previous | Next | Up | Top |
int86
int86 or intdos functions to invoke a
software interrupt?
int86 family of functions in the DJGPP library should
reissue the INT instruction after the mode switch. However, some services require pointers to memory buffers. Real-mode DOS/BIOS functions can only access buffers in conventional memory, so
int86 has to move data between your program and low memory to transparently support these services. But this means it should know about all these services to perform these chores
correctly, because each service has its own layout and size of the buffer(s). While int86 supports many of these services, it doesn't support all of them. The supported functions are
listed in the library reference. See the "int86" section of the "libc.a reference". For those it doesn't support, you
will have to call the __dpmi_int library function instead. It is also documented in the library reference, See
the "__dpmi_int" section of the "libc.a reference". __dpmi_int requires that you set up all the data as
required by the service you are calling, including moving the data to and from low memory (See how to use buffers with DOS/BIOS services, below).
| Previous | Next | Up | Top |
int86x or intdosx for a DOS or BIOS function supported by them, then just put the address of your buffer into the register which expects
the offset ( regs.x.di ) and forget about the segment. These functions are processed specially by the library, which will take care of the rest.
If you call __dpmi_int, then you must put into that register pair an address of some buffer in conventional memory (in the first 1 MByte). If the size of that buffer
doesn't have to be larger than the size of transfer buffer used by DJGPP (16KB by default), then the easiest way is to use the transfer buffer. (Library functions don't assume its contents to be
preserved across function calls, so you can use it freely.) That buffer is used for all DOS/BIOS services supported by DJGPP, and it resides in conventional memory. DJGPP makes the address and the
size of the transfer buffer available for you in the _go32_info_block external variable, which is documented the library reference. Check the size of the buffer (usually, 16K bytes),
and if it suits you, use its linear address this way:
dpmi_regs.x.di =
_go32_info_block.linear_address_of_transfer_buffer & 0x0f;
dpmi_regs.x.es =
(_go32_info_block.linear_address_of_transfer_buffer >> 4) & 0xffff;
For your convenience, the header file defines a macro __tb which is an alias for _go32_info_block.linear_address_of_transfer_buffer .
If the size of the transfer buffer isn't enough, you will have to allocate your own buffer in conventional memory with a call to the __dpmi_allocate_dos_memory library function. It
returns you the segment of the allocated block (the offset is zero). If you only need a small number of such buffers which can be allocated once, then you don't have to worry about freeing them:
they will be freed by DOS when your program calls exit .
For bullet-proof code, you should test the size of the transfer buffer at runtime and act accordingly. This is because its size can be changed by the STUBEDIT program without your knowledge.
| Previous | Next | Up | Top |
__dpmi_simulate_real_mode_interrupt .
__dpmi_regs structure before you call that function. Random values in these fields can cause your program to behave
erratically. The fields in point are SS, SP and FLAGS. When SS and SP are zeroed, the DPMI host will provide a stack for the
interrupt handler which is at least 30-word long (most DPMI hosts provide much larger stack); this is usually enough, but if it isn't, then you should point SS and SP to a
larger buffer in conventional memory (possibly part of the transfer buffer). If SS:SP isn't zero, they will be used as the address of the stack you want to be used by the interrupt handler, so if they have random values, your program will crash. A non-zero FLAGS field can also make the processor do all kinds of weird things (e.g., imagine that the single-step or the debug bit is set!).
If you don't have any reason to set SS:SP to your stack, it's easier to call __dpmi_int library function, which zeroes out the stack pointer and the FLAGS
fields for you (and also doesn't force you to type long names!).
| Previous | Next | Up | Top |
Q: How do I access my peripheral card which is memory-mapped to an address between 640K and 1M?
Q: How can I read or change a value of one of the variables in the BIOS data area?
Q: How can I peek at an address whose far pointer I get from an INT 21h call?
header file. You should convert any
real-mode far pointer segment:offset pair into a linear address (i.e., segment*16 + offset), and use _dos_ds macro to get the selector which allows access to conventional
memory, like this:
unsigned char value = _farpeekb(_dos_ds, segment*16 + offset);
Use _farpeekw to peek at 16-bit shorts and _farpeekl to peek at 32-bit longs. If you need to access several (non-contiguous) values in a loop, use corresponding
_farnspeekX functions which allow you to set the selector only once, as opposed to passing it with every call (but be sure the loop doesn't call any function that itself sets the
selector; see the library reference for more details).
There is a corresponding set of _farpokeX and _farnspokeX functions to poke (change the values of) such memory locations.
These functions have an advantage of emitting inline assembly code when you compile with optimizations, so they are very fast. See the library reference Info file for further details about these functions.
dosmemget and dosmemput library functions. They also require that you convert the segment:offset pair into a
linear address, but they don't need the conventional memory selector, as they can only be used to access the conventional memory.
Note that some memory-mapped peripheral devices might require 16-bit word accesses to work properly, so if dosmemXXX yields garbled results, try dosmemXXXw or "farptr"
functions.
movedata library function. It requires that you pass selector and offset for both the conventional memory
address and for the buffer in your program's address space. Use the _my_ds macro to get the selector of any variable in your program, and use its address as its "offset" or linear
address. movedata is faster because it moves by 32-bit longs, but be careful with its use when moving data to and from peripheral cards: many of them only support 8- or 16-bit wide
data path, so moving data 4 bytes at a time won't gain you much, and might even get you in trouble with some buggy BIOSes. The functions movedatab and movedataw are
provided for moving by bytes and by 16-bit words, respectively.
header; see library reference
for more details. Also see the description of how to get the fastest direct access to peripheral devices, below.
| Previous | Next | Up | Top |
movedata to pass data between my program and the transfer buffer, but get bogus values or General Protection Fault.
_go32_info_block.linear_address_of_transfer_buffer (or its
alias, __tb ) is not guaranteed to have the higher 12 bits zeroed, and movedata doesn't mask those high bits, because it can also be used to move data between 2
protected-memory locations. Be sure to mask off the high 12 bits of the value returned by various ..._linear_address_... fields in DJGPP structures, whenever that address references a
conventional memory location, before you call any of the functions from the movedataX family, the "farptr" or the "nearptr" functions.
| Previous | Next | Up | Top |
Surgeon General's WARNING: The description below uses the "Fat DS hack", a steroid derivative which gives your program great strength, a thick neck, baldness, and is known to be closely linked with the Alzheimer's disease.
Having said that, here is the trick: you change the limit of the segment descriptor stored in DS to 0xffffffff (i.e., -1), using function 8 of the DPMI interrupt 31h.
After that, you have access to all the memory which is currently mapped in. You then use the 32-bit wrap-around in the linear address space to access memory at, say, linear address 0xa0000 (which
belongs to the VGA), or any other address on your memory-mapped device.
You should know up front that this trick won't work with every DPMI host, and some events break this scheme even for those DPMI hosts which will silently allow you to set such a huge limit on the
memory segment. CWSDPMI, QDPMI, Win 3.x all allow this; Linux's DOSEMU and, probably, OS/2 Warp don't. A call to malloc or any other library function which calls sbrk might sometimes
change the base address of DS selector and break this method unless the base address is recomputed after sbrk call. (The "nearptr" functions support this recomputation by
providing you with the __djgpp_conventional_base variable, but it is your responsibility to use it.) The same change happens when you call system, and as result of some
other events external to the executing code thread, like multitasking or debugger execution.
If you are aware of these limitations, and don't need your code to run under all DPMI hosts, it might be the fix to your problems.
Confused about how exactly should you go about using this technique in your program? Look at the docs of the "nearptr" functions, See the "__djgpp_nearptr_enable" section of the "libc.a reference".
| Previous | Next | Up | Top |
__dpmi_physical_address_mapping library function. It returns a linear address which can be used to access a given absolute physical address. You can
then use the functions from __dpmi__XXX wrappers in the DJGPP library.
| Previous | Next | Up | Top |
_go32_dpmi_allocate_real_mode_callback_retf or the _go32_dpmi_allocate_real_mode_callback_iret library function, as required by the real-mode service you want to hook,
and pass the `segment' and `offset' fields it returns to the service you want (in the above example, Int 33h function 0Ch) by calling __dpmi_int . See the docs in the library reference
Info file for further details about allocating wrapper function.
| Previous | Next | Up | Top |
First, some background. Hardware interrupts can occur when the processor is either in real mode (like when your program calls some DOS service) or in protected mode. When your program runs under a DPMI host, hardware interrupts are always passed to protected mode first, and only if unhandled, they are reflected to real mode. Therefore, in DPMI mode you can get away with installing only a protected-mode handler. However, if the interrupts happen at a high frequency (say, more than 10 KHz), then the overhead of the interrupt reflection from real to protected mode might be too painful, and you might consider installing a real-mode interrupt handler in addition to the protected-mode one. If you do, you must hook the PM interrupt first, then the RM one (because hooking the PM interrupt modifies the RM one). Also, you should know that some DPMI hosts don't allow you to hook the RM interrupt (CWSDPMI does); the only way to be sure is to try.
To install a protected-mode interrupt handler, you do this:
__dpmi_get_protected_mode_interrupt_vector and save the structure it returns (to restore the previous handler address before your program exits).
__dpmi_lock_linear_region .
__dpmi_set_protected_mode_interrupt_vector passing it the pointer to a __dpmi_paddr structure filled with _my_cs in the
selector field and the address of your function in the offset32 field.
_go32_dpmi_XXX functions instead of the bare-bones API wrappers whose names start with
__dpmi_ . Specifically:
_go32_dpmi_get_protected_mode_interrupt_vector . This function puts the selector and offset of the specified interrupt vector into the pm_selector and
pm_offset fields of the structure pointed to by its second argument. This data should be saved and later passed to _go32_dpmi_get_protected_mode_interrupt_vector to
restore the vector on exit.
_go32_dpmi_allocate_iret_wrapper passing it the address of your functions as the pm_offset field and the value of _my_cs in the
pm_offset field. The pm_offset field will get replaced with the address of the wrapper function which is a small assembler function that handles everything an interrupt
handler should do on entry and before exit (and what the code GCC generates for an ordinary C function doesn't include); the effect is similar to using interrupt or _interrupt keyword
in some DOS-based compilers.
_go32_dpmi_chain_protected_mode_interrupt_vector . This will set up a wrapper function which, when called, will call
your handler, then jump to the previous handler after your handler returns. Put the address of your handler into the pm_offset field and the value of _my_cs into the
pm_selector field of the _go32_dpmi_seginfo structure and pass a pointer to it to this function.
_go32_dpmi_set_protected_mode_interrupt_vector with the address of the _go32_dpmi_seginfo structure you got either from
_go32_dpmi_allocate_iret_wrapper or from _go32_dpmi_chain_protected_mode_interrupt_vector .
The problem with writing handlers in C as above is that the wrappers aren't locked, and in practice you can't lock all of memory the handler itself uses, either. Thus, this approach is generally unsuitable for production-quality software and should be used only when the program is known to not page (i.e., only the physical memory is used). (You might consider disabling virtual memory to make sure your program doesn't page.)
To install a real-mode interrupt handler, you do this:
__dpmi_get_real_mode_interrupt_vector and save the structure it returns (to restore the previous handler address before your program exits).
__dpmi_allocate_dos_memory and put the code of your handler there with dosmemput function. (You could also call one of the
functions which allocate real-mode call-back, but these will cause a mode switch on every interrupt which you want to avoid, otherwise there is no point in installing a real-mode handler, right?)
__dpmi_allocate_dos_memory returned into a __dpmi_raddr structure (the lower 4 bits into offset16 field, the rest into
segment field), then call __dpmi_set_real_mode_interrupt_vector .
For examples of installing and using hardware interrupt handlers, see the files sb05_dj2.zip (Sound Blaster interrupt-driven functions) (also available on OULU repository).
| Previous | Next | Up | Top |
One cause of your problems might be that your interrupt handler or some memory location it uses get paged out because of the virtual memory mechanism, or because your program spawned a child program.
In that case, the interrupt might cause a call to a non-existent service routine, with the obvious results. You should lock all the memory pages that your handler accesses by calling the
__dpmi_lock_linear_region library function. This also means in practice that you should write your handler in assembly, as described in how to set an
interrupt handler, above. You can disable virtual memory, or put _CRT0_FLAG_LOCK_MEMORY into _crt0_startup_flags to make sure nothing is paged out (but then your
program might not have enough memory to run, unless you run on memory-abundant system).
Another problem might be that the hardware peripheral you use generates a lot of interrupts. Due to specifics of hardware interrupts handling in protected mode, there is a substantial overhead involved with reflection of interrupts between real and protected modes. For instance, on a 486DX/33 this reflection might consume up to 3000 clocks; on a 386SX/16, even a 1KHz clock might eat up 1/2 of available cycles. If your hardware fires too much interrupts, your CPU might not be able to keep up. In that case, consider reducing the interrupt frequency, or move some of the processing done inside interrupt handler to some other place. If your handler is written in C, write it in assembly and make sure it doesn't chain. If that doesn't help, install a real-mode handler.
Some losing memory managers, notably EMM386, were reported to induce a high interrupt handling overhead. In one case, a user reported an increase in the interrupt rate from 2 KHz to 6 KHz after uninstalling EMM386.
Still another possibility is that you use a non-default sbrk algorithm in your program (check if the header file crt0.h is included anywhere in the program, and if so, is
the _CRT0_FLAG_UNIX_SBRK bit in the _crt0_startup_flags variable set by the program. If it is, then a hardware interrupt which happens at the wrong time could crash
your machine, especially if you run under Windows 3.x.
If the above still doesn't explain your problem, then post your code on the comp.os.msdos.djgpp or the
djgpp mailing list, tell us how does it fail and somebody will usually have a solution for you.
inp and outp functions. But I hear they aren't available in DJGPP?
#include <pc.h> and you get their prototypes. The functions themselves are in the default library. Note that there are also
size-specific versions for byte- word- and dword-long access (e.g., inportl for reading a 32-bit dword), as well as functions to read/write sequences of bytes and words, like
inportsb and outportsw; these are DJGPP-specific.
| Previous | Next | Up | Top |
Q: Can I write commercial programs with DJGPP?
libiostr.a) which comes with DJGPP allows you to use it binary-wise (i.e., without changing library sources) in your C++ programs
without restrictions , unless you compile your programs with a compiler other than Gcc (which won't happen if you work with DJGPP). The library of additional C++ classes
(libgpp.a) also allows you to link it freely with your applications, but requires that you provide your customers with source or object code of the application, so they could relink the
application with future or modified versions of the C++ library. (If you intend to distribute commercial programs linked with the libgpp.a library, you are strongly advised to read the
GNU Library General Public License which comes with the library, for rigorous definition of its terms.)
Note that libiostream.a library is special in that it doesn't place your program under GPL or LGPL, so if you only use C++ classes included in that library, make your compilations use it
instead of libgpp.a. (That's the only reason of having libiostream.a as a separate file, because libgpp.a includes everything libiostream.a does,
so you never need both of them.)
Two GNU packages, Flex and Bison, are also special in that using them to produce your programs doesn't place your programs under GPL or LGPL. In other words, lexers produced by Flex and parsers produced by Bison do not imply GPL/LGPL.
If you do use in your program any of the FSF sources that fall under GPL/LGPL (like some of the GCC's sources, or the GNU getopt or regex packages which come with many GNU programs), then you must comply with the terms of GNU licenses when distributing your programs; in this case your entire application becomes GPL. If that is unacceptable to you, consider using the versions of regex and getopt from the DJGPP C library (which is free).
You may ship any of the utilities developed specifically for DJGPP (e.g., the floating-point emulator or the CWSDPMI DPMI host) as distributed by DJ Delorie with your program with no other requirement besides telling your customers how to get DJGPP for themselves.
Q: I run a business that sells shareware for distribution costs. Can I include djgpp on my CD-ROM?
Q: I want to include djgpp in a product that happens to need a compiler provided with it. Can I do this?
Q: Is DJGPP GNU software?
Q: Is DJGPP public domain software?
Q: Is DJGPP shareware?
When you redistribute parts of DJGPP itself (as opposed to your programs compiled with DJGPP), you must comply to the conditions applicable to whatever you distribute. The parts which are in public domain are, of course freely distributable. Other parts of DJGPP fall under the DJGPP copyright which allows you to redistribute everything provided you follow these rules:
In addition, it would be a courtesy to inform DJ Delorie that you are including DJGPP in your product, in case this information is obsolete. A token sample of your distribution would be nice also.
| Previous | Next | Up | Top |
| Previous | Next | Up | Top |
| Previous | Next | Up | Top |
subscribeIf you only want to receive announcements of new versions and ported software, but don't want to see any other DJGPP mail traffic, subscribe to djgpp-announce mailing list:djgpp
subscribeThe announcements which go to djgpp-announce get reflected to djgpp, so you don't have to subscribe to both these lists.djgpp-announce
The DJGPP mailing list is available in the daily and weekly digest forms. To subscribe to one of these, send this one-line message to the above list server:
subscribeordjgpp-digest-daily
subscribeYou can also subscribe to DJGPP-related mailing lists through DJ Delorie's WWW server.djgpp-digest-weekly
Note that you don't have to subscribe to djgpp mailing list if you don't want to get all the traffic in your mailbox (typically, about 30 messages per day). You can ask questions on the list even if you are not a subscriber, because people usually answer both to your e-mail address and to the list (well, actually, the mailer program does it automatically and most people don't bother to change that). If you want to be sure the mail gets to you directly, say in your message that you don't subscribe to the list, and ask people to answer directly.
If you have a Usenet feed, consider reading the comp.os.msdos.djgpp instead, so that the load on the DJ's list server will get lower. There is also a possibility of reading the Newsgroup (but not posting to it) through the Mercury Gopher server at Michigan State University
| Previous | Next | Up | Top |
Q: I've been trying for days to unsubscribe from the djgpp mailing list. What am I doing wrong?
unsubscribeIf you have done that and it didn't help, write to the DJ Delorie and ask him to help you.djgpp
You can also unsubscribe yourself from any of the DJGPP-related mailing lists through DJ Delorie's WWW server.
| Previous | Next | Up | Top |
| Previous | Next | Up | Top |
If indeed you get more than one copy of a message addressed to the list, it is possible that you have added yourself to the list several times. (This could happen if your site supports a mail exploder which re-mails DJGPP to you, and you also have subscribed yourself directly.) One way to check this would be to unsubscribe and see if you keep getting mail. Another way is to check your subscription through DJ's server. Look out for multiple subscriptions, possibly under different names/addresses. You could also write to a DJ Delorie, and ask him to investigate.
Another thing to do, especially if you think it's not your fault, is to write to a user named POSTMASTER at the address of each of the machines whose names you find in the Received: headers of the bouncing messages (these are people responsible for the operation of the mail software at their sites) and ask them politely to help.
Many times this kind of problems is caused by excessive load on the list server, so everybody who can, please switch to reading the comp.os.msdos.djgpp and unsubscribe from the list.
| Previous | Next | Up | Top |
If you want to help in further v2.0 development, check out the list of features which have yet to be done and volunteer to implement some of them.
main functions us called (the stub will also load CWSDPMI if no other DPMI host is detected). All the other custom code required to process BIOS- and
DOS-related calls from protected-mode is now built into the library functions which your program calls, so there is no need for a special extender, because the application just issues DPMI calls
serviced by the DPMI host. CWSDPMI can be loaded as a TSR, even loaded HIGH into the HMA/UMB, which will make the applications load much faster.
| Previous | Next | Up | Top |
Q: How do I fix a bug/add a feature to one of the DJGPP programs?
*s.zip in the DJGPP distribution. The C Library sources are in djlsr200.zip. Some sources are too big, and
might be split into multiple zips, all of which must be unzipped to get a complete source distribution, like this:
All sources are shipped in ready-to-build form. The diffs in the diffs/ directory have already been applied.
Next, try to build the program without changing it. Some packages will have a CONFIGUR.BAT file; if so, run it first. If there is a MAKE.BAT file, run it; if not, look for
a file named MAKEFILE.DJ or MAKEFILE.DJG; sometimes these will be in a subdirectory called dos/, or msdos/, or pc/. If there is such
a file, then type, e.g., make -f makefile.djg, if not, just say make and see what happens. (The reason for an apparent lack of a standards here is that different packages were
ported to DJGPP by different people, as best as they saw fit.) After you've succeeded to build the program, make your fixes and build the program the same way you did before.
Note that generally you must have GNU Make program to build these programs (get the file mak373b.zip), and some
makefiles require that you install additional utilities, like Sed (get sed118b.zip). Sometimes the makefiles won't even run under
COMMAND.COM (they require a smarter shell). In that case, either get a better shell, convert the makefile to be runnable by COMMAND, or do the required steps manually. If
the Makefile is too complex for you and you can't figure out what are the necessary commands, invoke make with -n switch and see what it would have done.
If your machine lacks floating-point hardware (like a 386 without a 387, or a 486SX), then you should know that current versions of GNU Sed and GNU Make issue floating point instructions, so you will
have to make provisions for loading an emulator, see above, FP Emulation.
| Previous | Next | Up | Top |
Here is a short list of places you might look into for examples of frequently needed code fragments, or for packages people keep asking about:
sbXX.zip from any SimTel mirror, in the msdos/sound directory.
| Previous | Next | Up | Top |
Q: I have this program that behaves differently depending on the name it's called. Under Unix, I just create symbolic links to achieve that, but DOS doesn't support links. Do I have to put several identical programs under different names on my disk??
stubify.exe program),
call it by the name of the link you want, then edit its header to run another program. For example, let's say the real program is dj1.exe and we want to make a link called
dj2.exe that really calls dj1.exe. First, generate a stub under the name dj2.exe. Next, run STUBEDIT to modify the new programs' stub info block
to change the name of the executable it runs. In this case, we'd change it to dj1:
C:\USR\BIN> stubify -g dj2.exe
C:\USR\BIN> stubedit dj2.exe runfile=dj1
Voila! Now, when you run dj2, it tells the stub to load the image of dj1, but pass "dj2" in argv[0] .
| Previous | Next | Up | Top |
At the OULU repository of PC-specific programming info.
The DPMI 1.0 specs are available by anonymous ftp from the Intel anonymous ftp site. (The file dpmiv1p.zip at the
same location is the PostScript version of this spec.)
Some information about the DPMI API is also found in the Ralf Brown's Interrupt List. Look at the functions of Interrupt 31h, or search the files for the word DPMI.
| Previous | Next | Up | Top |
To visit, point your Web browser to the DJGPP Web site.
| Previous | Next | Up | Top |
Q: I found and corrected a bug in one of the programs distributed with DJGPP. Where should I put it?
If the compressed file is larger than, say, 50K bytes, it's best to upload it to a public site where everybody can get it. You can upload your contribution to a special directory on the
DJ Delorie's FTP server. This directory is write-only, and it gets purged every couple of days, so be sure to write to
DJ Delorie about your upload; he will then move it to the /pub/djgpp/contrib directory. (There used to be another place, a directory on
omnigate.clarkson.edu which was writable by anonymous, but it was being used for malicious purposes and the sysadmins there decided to close it :-(.)
If you decide to upload, please send mail to djgpp-announce list with a brief description of your program/patch. (The message will get reflected to both the newsgroup and the DJGPP mailing list, so you don't have to cross-post there, but it also goes to people who only subscribe to djgpp-announce list because they only want to get announcements.)
If your program is more than a patch or a beta version, you might consider uploading it to SimTel. If you decide to do it, write to DJ Delorie and ask him for uploading instructions. Material uploaded there gets automatically distributed to all of the SimTel mirrors throughout the world, which makes it easier to get.
| Previous | Next | Up | Top |
Q: I want to build GCC as a Unix-to-DOS cross-compiler. What should I do?
For building GCC as a Unix-to-DOS cross-compiler, here are the instructions on how to do it. (Unfortunately, "make install" in the Gcc distribution does exactly the wrong thing by default, so you end up copying a lot of stuff around manually.)
Unpack Gcc and Binutils into a directory, let's call it X/. Thus, you have, say, X/gcc-2.7.0 and X/binutils-2.5.2. The following sequence of commands should
make the job:
mkdir $X/dos-binu
cd $X/dos-binu
--target=i386-coff-go32
make CFLAGS=-O
mkdir -p /usr/local/i386-go32-msdos/bin
cd binutils
cp ar c++filt objcopy objdump size /usr/local/i386-go32-msdos/bin
cp nm.new /usr/local/i386-go32-msdos/bin/nm
cp strip.new /usr/local/i386-go32-msdos/bin/strip
cd ../gas
cp as.new /usr/local/i386-go32-msdos/bin/as
cp gasp.new /usr/local/i386-go32-msdos/bin/gasp
cd ../ld
cd ld.new /usr/local/i386-go32-msdos/bin/ld
mkdir $X/dos-gcc
cd $X/dos-gcc
--target=i386-go32-msdos
make LANGUAGES=c CFLAGS=-O
cp xgcc /usr/local/bin/gcc-dos
cp cc1 /usr/local/i386-go32-msdos/bin/cc1
cp cccp /usr/local/i386-go32-msdos/bin/cpp
Unzip the DJDev and Gcc distributions in, say, /usr/local/djgpp. Ideally, build libgcc.a on a DOS machine. Remove all ^M characters from include files (you can compile DTOU.c on the Unix box to make this easier). Alternatively, use the -a switch to UnZip when unzipping the archives.
Change lib/djgpp.lnk to use "coff-i386" instead of "coff-go32" and remove the ^M characters from that file also.
mkdir -p /usr/local/lib/gcc-lib/i386-go32-msdos/2.7.0
cd /usr/local/lib/gcc-lib/i386-go32-msdos/2.7.0
ln -s /usr/local/djgpp/include .
ln -s /usr/local/djgpp/lib/* .
Build stubify and install it in /usr/local/i386-go32-msdos/bin. That's it! To build a program for DOS, say something like this:
gcc-dos hello.c -o hello.exe
| Previous | Next | Up | Top |
i = 0xfe+0x20;
Ain't it silly that such a great compiler would fail so miserably?
struct my_struct {
char name[7];
unsigned long offset;
double quality;
};
To make such a struct use the least number of bytes, rearrange the fields, like this:
struct my_struct {
double quality;
unsigned long offset;
char name[7];
};
If the layout of the structure cannot be changed (e.g., when it must match some external specification, like a block of data returned by some system call), you can use the
__attribute__((packed)) extension of GCC (See the "Type Attributes" section of the "GNU C/C++ Manual".) to prevent
GCC from padding the structure fields; this will make accesses to some of the fields slower.
Beginning from version 2.7.0, GCC has a command-line option -fpack-struct which causes GCC to pack all members of all structs together without any holes, just as if you used
__attribute__((packed)) on every struct declaration in the source file you compile with that switch. If you use this switch, be sure that source files which you compile with it don't
use any of the structures defined by library functions, or you will get some fields garbled (because the library functions weren't compiled with that switch).
This FAQ is Copyright (C) 1994, 1995, 1996 by Eli Zaretskii. It may be freely redistributed with the DJGPP package or any part thereof, provided that you don't prevent anybody else from redistributing it on the same terms, and that this copyright notice is left intact.
Comments about, suggestions for, or corrections to this FAQ list are welcome. Please make sure to include in your mail the version number of the document to which your comments apply (you can find the version at the beginning of this FAQ list).
Much of the info in this FAQ list was taken from the DJGPP mailing list/newsgroup traffic, so many of you have (unbeknownst to you) contributed to this list. The following people read this list in its previous versions and provided useful feedback, comments, information and/or suggestions:
Anthony Appleyard
John Bodfish
Bill Davidson
DJ Delorie
Juergen Erhard
Gordon Hogenson
Pieter Kunst
Alexander Lehmann
Steve Salter
Charles Sandmann
Terrel Shumway
Stephen Turnbull
Santiago Vila
Morten Welinder
Anthony Edward Wesley