DJGPP Frequently-Asked Questions List

Edition 2.10, for DJGPP Version 2.01

January 1997

This is the DJGPP Frequently-Asked Questions List.

Copyright (C) 1994, 1995, 1996, 1997 Eli Zaretskii

This is the second edition of the FAQ list, and is consistent with version 2.01 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.10 of the FAQ, last updated 19 January 1997, for DJGPP Version 2.01.

Another place to look for DJGPP documentation is the DJGPP Knowledge Base.

Brennan Underwood maintains a home page which is another valuable source for information about DJGPP.

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.

A previous version of this FAQ was translated into French, also available through the WWW.

The following master menu lists the major topics in this FAQ list, including all the indices.

• Urgent--If you are in a hurry.
• DJGPP--What is DJGPP?
• Requirements--Hardware and software requirements for DJGPP.
• Getting DJGPP--Where and what to download?
• Docs--Where the documentation is and how to read it.
• Trouble--When the compiler (or Make, or Info, or ...) crashes
• Compiler performance--How fast is the compiler?
• Compiling--Compile-time and link-time problems.
• Running--Running compiled programs.
• Graphics--Graphics under DJGPP.
• Floating point--Floating-point programs and FP emulation.
• Debugging--Debugging DJGPP programs.
• Profiling--Optimizing your programs.
• Performance--Run-time performance of DJGPP programs.
• Memory--Run-time memory issues.
• Command line--Command-line arguments handling in DJGPP.
• Converting--How to convert DOS code to DJGPP?
• Low-level--Low-level and hardware-oriented programming.
• Legalese--Legal aspects of programming with DJGPP.
• Help--How to get more help.
• v2--New in DJGPP Version 2.0.
• Miscellany--More...
• About--Contributors to this FAQ.
• Topic Index--Search here by a problem description.
• Program Index--Search here by a program name.

| Previous | Next | Up |

Q: I have this problem which I absolutely MUST solve NOW! What do I do?

• How to ask experienced DJGPP users for help?

  Use the DJGPP News group 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.

• What is the best configuration of my system for DJGPP?

  This depends on your hardware and software. See system configuration guidelines.

• Some files I need seem to be missing. Where do I find them?

  Check out the list of required and optional packages.

• How do I subscribe to or unsubscribe from the DJGPP mailing list?

  See subscription instructions.

• How can I search News group/mailing list traffic for some info?

  This FAQ includes the description of DJGPP archive search server, set up by DJ Delorie, which you should use whenever you have any questions or look for an information on a DJGPP-related subject.

| Previous | Next | Up |

DJ Delorie is the developer and principal maintainer of DJGPP, but anyone is welcome and encouraged to contribute.

| Previous | Next | Up |

• Minimum--You cannot run DJGPP unless you have this.
• OS/2--But it crashes under OS/2!
• Windows/NT--Is it compatible with Win/NT?
• DOSEmu--Can I run it on Linux?
• i286--Why not?
• Windows apps--Can I write Windows applications with DJGPP?
• Optimal hardware--Here is your dream machine description.
• Reasonable hardware--For the rest of us.
• Config--How to configure your system software for DJGPP.

| 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, Windows NT (on Intel CPUs), Novell NWDOS 7 and Caldera's OpenDOS (but several people have found the DPMI services of NWDOS and OpendDOS incompatible with DJGPP, so they should probably be turned off and CWSDPMI used instead), and Linux DOSEmu environment.

| Previous | Next | Up | Top |

Q: DJGPP Make crashes when I run it on OS/2!

If the above doesn't help, please post the details of the crashes you see to the DJGPP News group (see description of the DJGPP news group) or mailing list (see how to post to the mailing list), and somebody will help you.

| Previous | Next | Up | Top |

The DPMI server built into NT (and Windows 95) loses selectors with each child program that is invoked by a DJGPP program, so after about two thousand calls to functions from the spawnXX family you can see an error message like this:

       Load error: no DPMI selectors

Note that the long filename API (the special LFN-aware functions of Int 21h) for DOS box is not supported by current versions of Win/NT, so you cannot have long filenames there from DJGPP programs.

You might have problems with using the SVGA modes of your video card under Win/NT. That is because NT doesn't allow direct access to the SVGA registers, without which it is impossible to recognize the type of the SVGA and employ its capabilities. For example, a user reported that GRX functions and the MODETEST.EXE program thought that only a standard VGA was installed, whereas he had an S3 card. There is nothing you can do about this feature of Win/NT; that is the price you pay for the stability and protection you get under this OS (a runaway program that accesses hardware registers can wipe out your disk or wedge the entire system cold). However, I'm told that Win/NT 4.0 supports DirectX which is a method of accessing screen, audio and other peripherals directly, so it's possible to use full GRX graphics capabilities there.

Programs that use the "nearptr" facility of DJGPP to access absolute memory addresses (e.g., for memory-mapped devices) won't work on NT, because its DPMI server silently ignores functions that set huge limits on selectors. Since the default algorithm which allocates memory from the DPMI server needs to set such huge limit in some rare cases, there's a small probability that a program will fail or crash even if it doesn't set selector limits in user code. It is best to use the Unix-style sbrk algorithm in programs that run on Windows/NT. See the library docs for _crt0_startup_flags where the _CRT0_FLAG_UNIX_SBRK bit is explained, for more info on this issue. If you cannot switch to the Unixy sbrk (e.g., if you don't have access to its source), I'm told that sometimes such problems can be worked around if you run DJGPP programs in a full-screen session; your mileage may vary.

Some people report that NT servers cause much more problems than NT workstations of the same version and build. It seems that these problems usually mean that NT installation was done incorrectly (maybe it is much harder to get it right with a server than with a workstation?). If you have such problems, try to install a workstation, or re-install the server, and see if that helps. And if you gain some insight as to why servers like DJGPP less than workstations, please tell what you've learned.

The Cygnus Win32 project is another (unrelated to DJGPP) port of GCC and development tools to WinNT and Win95 platforms, which specifically targets development of Windows programs. It is available from the Cygnus archives or through the Web.

| Previous | Next | Up | Top |

Q: I can run DJGPP on Linux, but Make crashes with SIGFPE on even the simplest Makefiles!

You might also need to edit the RAM section of the dosemu.conf file to make it comfortable for DJGPP. I suggest setting dpmi and xms to 16MB and ems to 4MB.

Some users reported that Make, and possibly other programs which use floating point computations, crash in DOSEmu environment on systems without an FPU, even if you set the 387 and EMU387 environment variables correctly (as explained in Setting up the FP emulator, below). The only known work-around is to not use floating point or to upgrade your machine hardware. It is possible that newer versions of Linux might solve this problem too, so try upgrading your Linux software.

If your only problem is to run GNU Make, get the latest DJGPP port of Make, since ports of Make 3.75 or later can be configured to not issue FP instructions at all.

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

Another problem with RSXWDK is that the Makefiles there are written for ndmake, so they should be rewritten for GNU Make to work. Some more hacking of Makefiles might be required due to the fact that they are set to work with EMX, and assume you unpacked everything into /rsxwdk. You will also have to recompile the libraries as they were compiled with DJGPP v1.x, and hack the v2 startup file crt0.s along the same lines as the v1 version which comes with RSXWDK. (crt0.s comes with the DJGPP source distribution, djlsr201.zip.)

Apart from RSXWDK, you will need a windows.h header file. One place to find it is with the WINE distribution (you'll have to add -DWINELIB to CFLAGS when compiling). However, be warned that this is a complete rewrite of the original, and might produce error messages when used to compile Windows apps. I don't know about a better solution except using windows.h from a commercial compiler, which might get you into legal trouble.

You will also need a help compiler, or try at the Microsoft ftp site. I'm told that, legally, you must already have purchased a help compiler from Microsoft to use either one of these.

A resource compiler is also required. RSXNT (below) includes one such, but I didn't yet hear any success stories using it. Anybody?

Note that, according RSXWDK's author, that package is meant for those who already have working debugged Windows applications and are simply looking to port them to 32-bit code. Therefore, some crucial parts of a development environment (like a debugger) are missing there. The author of RSX has recently discontinued his support of the package and switched to RSXNT project that targets Win32 (Win9x and WinNT) platforms (below).

As of this writing, nobody has reported any first-hand experience of using RSXWDK with DJGPP v2; the above is based on user reports under v1.x. If you try RSXWDK with v2.x, please post a summary of your experience.

There is also a newer Windows development tool-chain by the author of RSXWDK called RSXNT. This is targeted for Win32 platforms (Win95 and WinNT); it does have debugging tools included and has better support for DJGPP v2.x, but it needs to be registered (for a fee) if you want to develop commercial or shareware applications with it. It can be found on the same sites as RSXWDK and comes with header files from Cygnus. You can find the DJGPP-specific version of RSXNT on SimTel mirrors. The sources of all the RSXNT utilities can be found in rsxnt1.zip archive on Cica mirrors, in the win95/programr/ directory. Note that currently, due to limitations of DJGPP, you cannot produce DLLs or programs that will run on Win32s platforms with RSXNT.

Another way to develop Windows applications is to use the Cygnus GCC/GPP port. You can also download it via anonymous ftp. This one's compatible with Win32 (Win95 or WinNT, not Win32s), but requires you to comply with the GNU Copyleft system. The Cygnus distribution includes development environments which run on WinNT and Linux, targeting WinNT and Win95 platforms. Note that, as of this writing, the Cygnus port is still in early beta phase, and some nasty bugs are bound to be there. Contact Steve Chamberlain, for more details.

A better (but harder) way would be to volunteer to add Windows support to DJGPP.

| Previous | Next | Up | Top |

• Hardware:
  • the fastest CPU you can find (a 200 MHz Pentium-Pro as of this writing);
  • at least 512KB second-level (off-chip) cache memory;
  • 128 MByte RAM;
  • motherboard built around fast 32-bit-wide bus (VLB or PCI);
  • SCSI-II hard disk with bus-mastering controller;
• Software:
  • DOS, device drivers and TSRs all loaded HIGH, leaving only 5K DOS footprint in lower (under 640K) memory;
  • 8 MByte RAM disk installed, TMPDIR environment variable points to it (e.g., set TMPDIR=e:, if E: is the RAM drive letter);
  • 8 MByte of disk cache, set to delayed-write operation;

| Previous | Next | Up | Top |

• CPU: 486DX2-66 with 256 KB off-chip cache;
• RAM: 16 MByte;
• Disk: 12 ms IDE with VLB controller, or SCSI;
• 4 MByte RAM disk;
• 3 MByte disk cache;

| Previous | Up | Top |

1. If you have 2 MBytes or less RAM installed:
   • Don't use any memory manager.
   • Use of CWSDPMI as your DPMI host is highly recommended.
   • Remove any TSR and device drivers you don't absolutely need (like SETVER.EXE, HIMEM.SYS etc.) from your CONFIG.SYS and AUTOEXEC.BAT.
   • Do not install disk cache or RAM disk; point your 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.
   • If you use CWSDPMI as your DPMI host, get the CWSPARAM program (from the csdpmi3b.zip archive) and set the "Minimum application memory desired before 640K paging" parameter to 512K or larger. Depending on how much memory you actually have, you might need to further fine-tune this parameter. This parameter defines the lowest amount of extended memory CWSDPMI will use; if your system doesn't have that much free extended RAM, CWSDPMI will use conventional memory instead, where usually there should be around 600K of free RAM.
   • If you run under Windows, be sure to set the maximum amount of extended memory on your PIF file for the DOS box to a reasonable value.
   With this configuration, GCC will run out of free physical RAM and start paging when compiling almost any C program and all C++ programs. If you are serious about DJGPP development, you need to buy more RAM urgently.
2. If you have 2-4 MBytes of RAM installed:
   • Don't use any memory manager.
   • Remove any TSR and device driver you don't absolutely need (like SETVER.EXE, HIMEM.SYS) from your CONFIG.SYS and AUTOEXEC.BAT.
   • Get a disk cache which works from conventional memory and configure it to 256K size at most, or don't use a cache at all.
   • Do not install a RAM disk; point your TMPDIR environment variable to a directory on your hard disk.
   • If you run under Windows, be sure to set the maximum amount of extended memory on your PIF file for the DOS box to a reasonable value.
   With this configuration, GCC will still run out of free physical RAM and start paging when compiling large C programs and most C++ programs. Plan to buy more RAM as soon as you can.
3. If you have 5-8 MBytes of RAM installed:
   • Use a memory manager such as EMM386 or QEMM386. Try using the FRAME=NONE parameter of the memory manager. This will disable Expanded Memory (EMS) services as far as most programs are concerned; if you must use DJGPP together with any program which needs EMS, try to configure that program to use Extended Memory (XMS) instead.
   • Load DOS, device drivers and TSRs HIGH.
   • Give your disk cache 1 MByte of RAM. Enable its delayed-write (aka write-back) feature.
   • Do not install a RAM disk; point your TMPDIR environment variable to a directory on your hard disk.
   • If, after configuring your system as above, you still have more than 2.5 MBytes of free RAM left (4 MBytes, if you plan to program in C++ a lot), enlarge the disk cache size.
   • If you run under Windows, be sure to set the maximum amount of extended memory on your PIF file for the DOS box to a reasonable value.
4. If you have more than 8 MBytes of RAM:
   • Use a memory manager to load DOS, TSRs and device drivers HIGH.
   • Install at least a 2-MByte-large disk cache, configured to use the delayed- write feature. If you have plenty of RAM, you can give your cache as much as 8 MBytes of memory.
   • If you have more than 5 MBytes left, install a RAM disk with a size of at least 1.5 MBytes and point your 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.

A tutorial is available on how to set up and get started with DJGPP.

| Previous | Next | Up |

• Where to find--Pick up from your nearest SimTel mirror.
• CCT--Or look on one of the CCT mirrors.
• How to download--Anonymous FTP, of course!
• DJGPP by WWW--For those who use Netscape/Mosaic only.
• What to download--Look here to decide what packages you need.
• Disk space--How much disk storage do you need?
• DJGPP = Fatware--Can I do with less MBytes?

| Previous | Next | Up | Top |

Lately, there has been considerable confusion caused by the fact that the repository which was long known by the name SimTel is no longer called that; its new name is CCT. The name SimTel has moved (along with its originator and long-time manager, Keith Petersen) to another distribution network which uses almost the same ftp sites, but in different subdirectories. The name SimTel is copyrighted by this new distribution network, and so CCT will have to discontinue its use of that name. Experience shows that SimTel.NET (not CCT) is better managed and updates propagate there much faster, so I advise you to try using SimTel mirrors first, and fall back to CCT only if a SimTel site is unavailable to you. In particular, DJGPP version 2.01 and later wasn't even uploaded to CCT sites.

This section lists the SimTel.NET mirrors; see below, for the list of CCT sites.

The primary SimTel.NET site is:

ftp.simtel.net

Note: ftp.simtel.net is actually several ftp sites arranged in a rotating pattern of IP addresses to help balance the load and to avoid access problems due to network outages and simultaneous user limits.

Here is a list of hosts by countries that offer mirror sites:

Argentina

ftp.satlink.com

Newcastle, Australia:

ftp.iniaccess.net.au

Australia:

ftp.tas.gov.au

Australia:

sunsite.anu.edu.au

Vienna, Austria:

ftp.univie.ac.at

Brussels, Belgium:

ftp.linkline.be

Aarshot, Belgium:

ftp.tornado.be

Sao Paulo, Brazil:

ftp.unicamp.br

Brazil:

ftp.iis.com.br

Bulgaria:

ftp.eunet.bg

Ottawa, Canada:

ftp.crc.doc.ca

Vancouver, Canada:

ftp.direct.ca

Chile:

sunsite.dcc.uchile.cl

Beijing, China:

ftp.pku.edu.cn

Czech Republic:

ftp.eunet.cz

Prague, Czech Republic:

pub.vse.cz

Czech Republic:

ftp.zcu.cz

Espoo, Finland:

ftp.funet.fi

Neuilly, France:

ftp.grolier.fr

Paris, France:

ftp.ibp.fr

Germany:

ftp.mpi-sb.mpg.de

Bochum, Germany:

ftp.rz.ruhr-uni-bochum.de

Chemnitz, Germany:

ftp.tu-chemnitz.de

Heidelberg, Germany:

ftp.uni-heidelberg.de

Magdeburg, Germany:

ftp.uni-magdeburg.de

Paderborn, Germany:

ftp.uni-paderborn.de

Trier, Germany:

ftp.uni-trier.de

Wuerzburg, Germany:

ftp.rz.uni-wuerzburg.de

Athens, Greece:

ftp.ntua.gr

Hong Kong:

sunsite.ust.hk

Hong Kong:

ftp.hkstar.com

Hong Kong:

ftp.cs.cuhk.hk

Ireland:

ftp.iol.ie

Jerusalem, Israel:

ftp.huji.ac.il

Naples, Italy:

ftp.unina.it

Italy:

cis.utovrm.it

Italy:

ftp.flashnet.it

Italy:

mcftp.mclink.it

Saitama, Japan:

ftp.saitama-u.ac.jp

Saitama, Japan:

ftp.riken.go.jp

Japan:

ftp.iij.ad.jp

Japan:

ftp.u-aizu.ac.jp

Japan:

ring.aist.go.jp

Japan:

ring.asahi-net.or.jp

Japan:

ftp.web.ad.jp

Latvia:

ftp.lanet.lv

Malaysia:

ftp.jaring.my

Malaysia:

ftp.mimos.my

Mexico:

ftp.gdl.iteso.mx

Netherlands:

ftp.euro.net

Utrecht, Netherlands:

ftp.nic.surfnet.nl

Wellington, New Zealand:

ftp.vuw.ac.nz

Bergen, Norway:

ftp.bitcon.no

Krakow, Poland:

ftp.cyf-kr.edu.pl

Poznan, Poland:

ftp.man.poznan.pl

Warsaw, Poland:

ftp.icm.edu.pl

Aveiro, Portugal:

ftp.ua.pt

Portugal:

ftp.ip.pt

Romania:

ftp.sorostm.ro

Singapore:

ftp.nus.sg

Slovakia:

ftp.uakom.sk

Slovenia:

ftp.arnes.si

Johannesburg, South Africa:

ftp.is.co.za

Stellenbosch, South Africa:

ftp.sun.ac.za

Seoul, South Korea:

ftp.nuri.net

South Korea:

ftp.sogang.ac.kr

South Korea:

sunsite.snu.ac.kr

Spain:

ftp.rediris.es

Stockholm, Sweden:

ftp.sunet.se

Zurich, Switzerland:

sunsite.cnlab-switch.ch

Chung-Li, Taiwan:

ftp.ncu.edu.tw

Taipei, Taiwan:

nctuccca.edu.tw

Nonthaburi, Thailand:

ftp.nectec.or.th

Edinburgh, UK:

emwac.ed.ac.uk

Lancaster, UK:

micros.hensa.ac.uk

London, UK:

sunsite.doc.ic.ac.uk

London, UK:

ftp.demon.co.uk

Suffolk, UK:

ftp.flexnet.net

Concord, California, USA:

ftp.cdrom.com

California, USA:

ftp.digital.com

California, USA:

ftp.lib.sonoma.edu

Urbana, Illinois, USA:

uarchive.cso.uiuc.edu

Massachusets, USA

ftp.bu.edu

Rochester, Michigan, USA:

OAK.Oakland.Edu

New York, NY, USA:

ftp.rge.com

Oklahoma, USA:

ftp.ou.edu

Corvallis, Oregon, USA:

ftp.orst.edu

Pennsylvania, USA:

ftp.epix.net

Utah, USA:

ftp.cyber-naut.com

Virginia, USA:

mirrors.aol.com

| Previous | Next | Up | Top |

The primary CCT site is in Detroit, Michigan, USA:

ftp.coast.net.

Here is a list of hosts by countries that offer mirror sites:

Canberra, Australia:

archie.au

Edmonton, AB, Canada:

ftp.agt.net

Prague, Czech Republic:

pub.vse.cz

London, England:

src.doc.ic.ac.uk

Liverpool, England:

ftp.mersinet.co.uk

London, England:

ftp.demon.co.uk

Chemnitz, Germany:

ftp.tu-chemnitz.de

Mainz, Germany:

ftp.uni-mainz.de

Tuebingen, Germany:

ftp.uni-tuebingen.de

Hong Kong:

ftp.cs.cuhk.hk

Hong Kong:

sunsite.ust.hk

Dublin, Ireland:

ftp.hea.ie

Haifa, Israel:

ftp.technion.ac.il

Naples, Italy:

ftp.unina.it

Pisa, Italy:

cnuce-arch.cnr.it

Rome, Italy:

ftp.flashnet.it

Rome, Italy:

cis.utovrm.it

Tokyo, Japan:

ftp.crl.go.jp

Tokyo, Japan:

ftp.web.ad.jp

Tokyo, Japan:

ring.aist.go.jp

Tokyo, Japan:

ring.asahi-net.or.jp

Seoul, Korea:

ftp.kornet.nm.kr

Seoul, Korea:

ftp.nowcom.co.kr

Utrecht, Netherlands:

ftp.nic.surfnet.nl

Poznan, Poland:

ftp.man.poznan.pl

Warsaw, Poland:

ftp.icm.edu.pl

Moscow, Russia:

ftp.radio-msu.net

Singapore:

ftp.singnet.com.sg

Slovak Republic:

ftp.uakom.sk

Taipei, Taiwan:

nctuccca.edu.tw

Bangkok, Thailand:

ftp.bu.ac.th

Sunnyvale, CA, USA:

ftp.drcdrom.com

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

• The main SimTel.NET site.
• The main CCT site.
• The CCT mirror in Rochester, MI.
• The CCT mirror in St. Louis, MO.

Gopher users can access CCT files through a Gopher client.

For those of you who only have an e-mail connection to the Internet, CCT 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 CCT list server with this command in the message body:

      get simtel-mailserver.info

| Previous | Next | Up | Top |

• To only run DJGPP-compiled programs, you MUST download all of these:

  Note: The version numbers of the packages below might not be up to date. For the latest versions, check out the DJGPP Mini-FAQ posted weekly to the comp.os.msdos.djgpp news group.

  v2/readme.1st

  This explains how to install DJGPP and get started with using it.

  v2/faq210b.zip

  The latest edition of this FAQ list. Use it whenever you have problems installing and using DJGPP.

  v2misc/csdpmi3b.zip

  CWSDPMI, the DJGPP free DPMI server. (If you can get DPMI services in your environment, like if you run under Windows, QDPMI, or OS/2, you don't need CWSDPMI, but I recommend downloading it nonetheless so you can try it in case you have trouble with other DPMI servers.)

  v2misc/pmode11b.zip

  This is an alternative DPMI server, PMODE/DJ. Its memory footprint is smaller than CWSDPMI and it can be bundled with DJGPP programs to make a stand-alone executable that doesn't require a DPMI server to run. PMODE/DJ doesn't support virtual memory and its implementation of the DPMI spec is a bit more restricted than that of CWSDPMI.

• For developing C programs (no C++), you MUST download all of the above, plus the following:

  v2gnu/bnu27b.zip

  The GNU Binutils, including as , the GNU assembler; ld , the GNU linker; and their docs.

  v2/djdev201.zip

  C header files and libraries, library reference, minimal development environment, DJGPP-specific utilities and their documentation.

  v2gnu/gcc2721b.zip

  The GNU C Compiler binaries and docs (including the docs for the C++ compiler).

  v2gnu/txi390b.zip

  Info, a stand-alone program to read GNU hypertext documentation files, and an environment to produce such files. Without info, you cannot read the C library reference and the docs included with the ported GNU software packages.

• For developing C++ programs, you will need all of the above, plus the following:

  v2gnu/gpp2721b.zip

  The GNU C++ compiler binary (the docs are part of the gccNNNb.zip package, see above).

  v2gnu/lgp271b.zip

  The C++ header files, the GNU C++ class libraries, and their docs.

  v2gnu/obc2721b.zip

  If you want to develop Objective-C programs, you will need this file, which includes the Objective-C compiler and header files.

• The following are some optional packages which you might want:
  • Debugging:

    v2gnu/gdb416b.zip

    GDB, the GNU Debugger and its docs. (Note that the djdev distribution includes two simpler debuggers, edebug and fsdb. The latter presents a user interface similar to that of Turbo Debugger.)

  • Additional development tools (consider getting at least the Make distribution):

    v2gnu/mak375b.zip

    GNU Make program with its docs. You should install Make 3.75 if you use DJGPP v2.01 (previous ports of Make have subtle incompatibilities with v2.01 tools). The port of Make 3.75 supports Unix-style shells (as well as DOS COMMAND.COM and its 4DOS/NDOS replacements) and can be used to run Unix Makefiles if you install a Unix-style shell (e.g., bash) and auxiliary utilities. It also supports long filenames on Windows 9x and MSDOS pathnames with drive letters.

    v2apps/rhide10b.zip

    The RHIDE integrated development environment for DJGPP (similar to Borland's IDE), written by Robert Hoehne. The latest version features an integrated debugger, based on GDB code; a stand-alone version of GDB with a Turbo Vision interface (but not all GDB features can be used); and support for user interface in languages other than English (using a port of GNU Gettext library).

    v2/djlsr201.zip

    The sources of the DJGPP C library and utilities written specifically for DJGPP. If you can afford the disk space (it requires about 10MB), I recommend installing or at least downloading it, so you can easily fix possible library bugs.

    v2gnu/bsh1147b.zip

    Bash (Borne-Again SHell), the GNU shell, and its docs. If you mostly work in Unix environment, you will feel right at home using bash as your interactive shell. It is also great as a batch shell for running Unix-born shell scripts and Makefiles when these are too complex to convert them to MSDOS. If you install bash, you should also install auxiliary utilities (Fileutils, Textutils, Sh-utils, Grep, Diffutils, Findutils, Sed and Gawk) as these are usually invoked from many shell scripts and Makefiles.

    v2gnu/bsn124b.zip

    Bison, a Yacc-like parser generator, and its docs.

    v2gnu/dif271b.zip

    GNU Diffutils (diff, cmp, diff3, sdiff), and their docs. If you need to submit patches or changes to DJGPP or GNU sources, you will need the GNU diff program from this package.

    v2gnu/emacs.README

    v2gnu/em1934*.zip

    GNU Emacs, the most powerful, customizable, extensible programmer's editor known today. The DJGPP port supports mouse, menu bar, pop-up menus, color syntax highlighting, reading Info documentation and compilation from within the editor, long filenames on Windows 9x, and much more. Emacs can and should be used as an integrated development environment (another alternative is RHIDE, see above). Please read the file emacs.README before you begin downloading the rest.

    v2gnu/fil313b.zip

    GNU Fileutils, including ls, rm, cp, mv, and others. Highlights of the latest port: ls supports colorization of files (like on Linux), ln -s knows about DJGPP-style "symlinks" (see symlink feature of DJGPP, elsewhere in this document), install -s will strip executables on the fly, and all the utilities support long filenames on Windows 9x and numbered backups (even on plain DOS). This package is a must if you want to run Unix shell scripts, as they use some of these utilities a lot .

    v2gnu/flx252b.zip

    Flex, a Lex-like lexical analyzer generator, and its docs.

    v2gnu/grep20b.zip

    GNU Grep package and its docs. You need this if you use Emacs (which has commands that invoke Grep) or if you want to run Unix shells and Makefiles.

    v2gnu/pat21b.zip

    GNU Patch program and docs. Required to apply patches to DJGPP sources.

    v2gnu/sed118b.zip

    GNU Sed (a batch editor) program and its docs. Many ported packages require it during the build process on MSDOS.

    v2gnu/shl112b.zip

    GNU Sh-utils. A must if you use the port of bash or want to run Unix Makefiles, but some utilities (such as env or test) can also be very useful on their own right.

    v2gnu/txt119b.zip

    GNU Textutils. Includes many useful programs, such as sort, wc, cat, join, paste, od, and uniq. Unix shell scripts and Makefiles call some of these a lot , so you should install this package if you run them.

  • Developing text-mode and graphics GUI applications:

    v2tk/grx20.zip

    The DJGPP graphics library.

    v2tk/bcc2grx.zip

    The interface library to convert Borland graphics calls to GRX library calls.

    v2tk/pdc22.zip

    Public-domain Curses library.

  For description of additional files not mentioned here, get the file 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.......................13  MBytes
     Developing C++ programs.....................17  MBytes
     Developing Objective-C programs.............15  MBytes
     Additional storage for RHIDE................2.5 MBytes
     Additional storage for DJGPP sources........10  MBytes
     Additional storage for GDB..................1.1 MBytes
     Additional storage for Emacs................30  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...4   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 much DPMI memory and swap space DJGPP applications can use. Depending on your DPMI host, you might need to review its virtual memory settings in addition to leaving free disk space; CWSDPMI requires only that enough free disk space be available, but other DPMI hosts have special settings to specify how much virtual memory they let their clients use, as explained below.

| Previous | Up | Top |

Q: Pulling that many megabytes through the net from my overloaded SimTel.NET 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 with a shell account), can use a nice FTP-automating utility called AutoWinNet (get the file autownNN.zip from your nearest CCT mirror).

As for the minimal DJGPP installation, volunteers are welcome to prepare such an archive and make it publicly available, in the same spirit as EZ-GCC did for DJGPP v1.x.

| Previous | Next | Up |

• Where is the docs--Where to find the docs and how to read them.
• No Info--For those who can't stand Info.
• Printed docs--How to produce a printed manual.
• Ready PS--Where to find printer-ready manuals.
• Can't find docs--For some programs it's tricky ...
• Man pages--How to read these.
• Last resort--Look in the source, of course!

| Previous | Next | Up | Top |

1. Use the stand-alone Info reader.

   Get the file txi390b.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.

2. Use the Info command of your favorite editor.

   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.) RHIDE also has an integrated Info reader, which is the core of its help system.

| 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

If you prefer reading the docs through the Web, point your Web browser to the docs page of the DJGPP Web site.

| Previous | Next | Up | Top |

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 latest GNU or DJGPP Texinfo distribution which includes that file.

If you'd like to produce printed docs of the library reference, TeX might complain that it cannot find a file named libc2.tex. This file is generated from all the *.txh files in the DJGPP source distribution (djlsr201.zip). In order to build this file, you need to install djlsr201.zip, then go to the src/libc directory and type this from the DOS command prompt:

       make -C ../mkdoc
       make doc

Note that some documentation 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:

In European A4 format.

In US letter format.

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 |

| Previous | Next | Up | Top |

• Get and install a DOS port of the groff package, or port it yourself (a very difficult task). The latest groff distribution can be found on the GNU ftp archive or any of its mirrors. A port of (an old version of) Groff to (an old version of) DJGPP can be downloaded from the DJGPP ftp server.
• Get and install CAWF, a DOS program which knows about most of the troff formatting commands. CAWF can be found on one of the CCT mirrors.
• Write or port a man clone. Source for one such clone was posted to the DJGPP news group, so you can get it there. You can also download this port from the DJGPP ftp server.
• Format the file on any Unix machine, and download the results to your PC. On Unix, typing catman -p will print the commands which are required to do this; you can then run those commands on your *.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 DJGPP port of GNU Less, which uses colors to show bold and underlined letters. Alternatively, you can get the latest official GNU Less distribution which can be compiled out of the box with the Borland C compiler. (Future versions of Less will also compile with DJGPP.)

Another possibility for reading formatted man pages would be with an Emacs editor, if you use one. Emacs has a special command to read man pages, but it requires a port or a clone of a Unix man command, described above.

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.djgpp 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 | Up | Top |

| Previous | Next | Up |

• No DPMI--You must have or install a DPMI server.
• Buggy DPMI--It might crash all of your v2.x programs.
• GCC optimizations--GCC sometimes crashes when optimizing.
• Fatal signal--GCC says "Fatal signal X".
• Unknown filetype--GCC says "Unknown filetype".
• QEMM AUTO--Can't use this with DJGPP.
• Make hangs--Compiler hangs, but only under Make.
• Info can't find "Top"--Info won't display some files.
• General trouble--Look here for any problem not covered above.
• Redirect--How to redirect GCC messages to a file.
• Deja vu--Look up your problem in the comp.os.msdos.djgpp archives.
• Totally lost--When nothing seems to help, ask on the net.

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

Q: I cannot run v2 applications: they all hang or reboot my system, while v1.x apps run OK. Is this what v2 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.

Yet another cause of crashes in Info might be trailing whitespace in the DJGPP.ENV file. The telltale signs of this failure are a stack dump that is bogus or doesn't start with your `main' function, or a series of SIGSEGV that won't stop. Actually, this is a bug in the DJGPP v2.0 startup code, so any v2.0 program could crash in this way, but since the last section of stock DJGPP.ENV belongs to Info, it is the one which suffers most from this bug. Make sure your DJGPP.ENV doesn't have a ^Z character at the end (some DOS editors put it if you edit the file), and doesn't end with a blank line. Alternatively, upgrade to DJGPP v2.01 or later, where that bug is fixed.

| Previous | Next | Up | Top |

Q: The compiler prints "Virtual memory exhausted" and dies while compiling some long functions with some optimization options, such as -funroll-loops or -fforce-addr.

GCC 2.6.0 was known to crash when optimizing, especially when compiling C++ programs, but it can also happen for later versions, especially if your code has some syntactic or semantic bug. (This is usually a genuine GCC bug, not something special to DJGPP.) Upgrade to the latest version of GCC. If that doesn't help, then narrow the offending code fragment using the #if 0 ... #endif paradigm. If this fragment includes an error, correct it and try again; if it is syntactically and semantically correct, then rewrite it as equivalent, but syntactically different one.

If GCC reports that it has exhausted virtual memory, you should first see if your swap space is large enough (run go32-v2 with no arguments) and make more free space on your disk if so. Some users have reported that GCC seems to run out of virtual memory if TMPDIR environment variable points to a RAM disk which doesn't have enough free space. Changing TMPDIR to point to a hard disk would reportedly save the day in those cases.

An undocumented GCC switch can sometimes help you zero in on the code fragment that causes GCC to crash. If you add -Q to the GCC command line, it will print the name of every function it compiles. The function that makes it crash is probably the one whose name is the last one printed, or the one after that.

You can also try to disable the strength-reduction optimizations of GCC by using the -fno-strength-reduce switch. GCC has a known bug in that type of optimization which goes back as far as version 2.5.8 and is only corrected in GCC 2.7.2.1 or later; this bug raises its ugly head on rare occasions, but is notoriously hard to hunt down when it does. (The stock v2.0 distribution should by default disable this kind of optimizations on the lib/specs file, and v2.01 comes with GCC 2.7.2.1 where that bug is fixed.)

As an extreme measure, don't optimize at all, if that's the only way to make your program compile.

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.

Yet another cause for such crashes can be connected with excess memory usage that GCC needs when compiling certain programs, which makes some DPMI hosts fail. For details about this, see CWSDPMI allocation problems, in the next section.

| Previous | Next | Up | Top |

Q: When I try compiling a program, GCC aborts saying "Installation problem, cannot exec `as': No such file". What does that mean?

Q: GCC aborts with "Internal compiler error" when compiling a large C++ program.

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, and the DPMI server fails to allocate it because it exhausts available memory for its internal tables. Release 1 of CWSDPMI can fail like this if an application asks for a large number of small memory chunks. If you use release 1 of CWSDPMI, you can enlarge the maximum space that CWSDPMI uses if you get a CWSDPMI heap-fix patch. Beginning with release 2, CWSDPMI defines a larger (6KB) default heap that is configurable by CWSPARAM program to be anywhere between 3K and 40K bytes, without recompiling CWSDPMI. You should upgrade to the latest CWSDPMI if you experience such problems.

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). If you see such problems when compiling a C program, stubedit cc1.exe.

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!!!

Another possible cause of the "Unknown filetype" message is that you mix a 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

| Previous | Next | Up | Top |

If you use Make compiled under DJGPP v1.x, you will also experience all kinds of trouble when invoking programs compiled under DJGPP v2. That's because v1.x programs cannot spawn v2 programs directly (the v1.x program sees that the child is a DJGPP program and tries to call go32 to run it, but v1's go32 cannot run v2 programs). The result usually will be that the child either crashes or silently exits. 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.) You can use go32-v2 to work around this limitation (see description of go32-v2, below), but I suggest doing that only if you absolutely cannot upgrade to v2's Make.

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 (that is usual for Makefiles that come from Unix). To work around, truncate the filename of that program in the Makefile.

| Previous | Next | Up | Top |

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 old 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 with 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 the bin/ subdirectory of your main DJGPP directory.

| Previous | Next | Up | Top |

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.

Another cause of such problems might be that your system is set up inefficiently. If GCC gets too few free RAM, it will run very slowly, and you might think it crashed when in fact it didn't. (This kind of problem usually happens on memory-starved machines.) Check out the system configuration advice, in this FAQ list and configure your system accordingly.

| 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 are hidden by the graphics display. How can I see it?

1. You can use a shell smarter then COMMAND.COM, such as 4DOS or bash, which knows how to redirect standard error stream to a file. 4DOS is shareware and can be found on CCT mirrors, while bash is available from the DJGPP archives.
2. You can also run your program under any one of the programs which save all screen output of programs they spawn in a file. I suggest using a program called SCRIPT, which is similar to its Unix namesake. It has an advantage of saving everything which goes to screen and showing it on the screen at the same time. You can find SCRIPT on CCT mirrors.
3. Or you can use the REDIR program which comes with DJGPP. It also redirects standard output and/or standard error to a file, but you don't get a chance to look at the output while the program runs. Here's how to run GCC with REDIR:

   
          redir -o gcc.log -eo gcc -v ...
   
   

   (put the rest of the GCC command line instead of the dots). The messages printed by GCC will be written to the file gcc.log.

| Previous | Next | Up | Top |

| Previous | Up | Top |

Q: I don't have time to download all these messages, not to mention looking through them. Can't you DJGPP gurus help me? Please??

• At the DOS command prompt, type set > environ.lst, then press Enter.
• Invoke the go32-v2 program (it's in your bin/ subdirectory) and save its output.
• Post to the comp.os.msdos.djgpp news group or write to the DJGPP mailing list and put into your message the description of your calamity, the contents of the file 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 (if your problem is that GCC won't work).
• If your problem involves a program that crashes and prints a stack dump, please post that stack dump. It's best to run symify on the stack dump, and post the output of symify :

  
         symify -o dumpfile yourprog
  
  

  (See detailed description of symify, for more details about symify. )
• Allow for 2-3 days (more on weekends) for all the reply messages to come in, then act according to what they recommend.

| Previous | Next | Up |

• Slow compiler--Are your compiles slow?
• Slow linker--How to boost the linking speed.

| Previous | Next | Up | Top |

                 |  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 accordingly. 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 percent 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 CWSDPR0 as your DPMI host, or use the CWSPARAM program to point the swap file to a non-existent drive), or use PMODE/DJ as the DPMI host, then run the compilation again; if the compiler aborts with an error message saying there isn't enough memory, then it was paging in your original environment.

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 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 the 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. Some people disable the delayed-write feature for safety reasons, to avoid losing files due to system crashes. If you are worried about this, you can usually gain performance without sacrificing safety by enabling delayed-write together with an option that causes the cache to flush the write-behind data before the system returns to the DOS prompt. (For SmartDrv disk cache, this is achieved by specifying /N/F switches instead of /X.) GCC usually gains a lot when you set up your cache in such a way, because each compiler pass (pre-processor, compiler, assembler) must write temporary files that are used by the following passes.

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 versions of the library.

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

DJ Delorie reports that his well-tuned 166 MHz Pentium system with 32 MBytes of RAM and 4 MBytes of RAM disk compiles the entire GCC source in under 10 minutes (this takes about 45 minutes on a 40MHz Sparc2).

| Previous | Up | Top |

A few users have reported that they got much faster linking after they've stub-edited ld.exe to change the transfer buffer size to 64KB. This speedup effect is usually seen when DJGPP is installed on a networked drive, or on a compressed disk; when DJGPP is installed on a local disk drive, linking speed is not affected by the size of transfer buffer.

If you use a disk cache, make sure you enable its write-back (aka delayed-write) operation. Some people disable the delayed-write feature for safety reasons, to avoid losing files due to system crashes. If you are worried about this, you can usually gain performance without sacrificing safety by enabling delayed-write together with an option that causes the cache to flush the write-behind data before the system returns to the DOS prompt. For SmartDrv disk cache, this is achieved by specifying /N/F switches instead of /X.

For very large (several MBytes) executables which are built from a large number of small source files, the link (as opposed to the compilation) 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. Make sure that the linker wasn't stub-edited to make its transfer buffer too small.

Another reason for slow linking might be that the DJGPP.ENV file by default sets TMPDIR to a tmp/ subdirectory of the main DJGPP installation directory; if DJGPP is installed on a networked drive, this means all your temporary files go back and forth through the network (and networked disks are usually not cached on your PC). In such cases, setting TMPDIR to a directory on your local drive, or to a RAM disk, would probably make linking faster.

| Previous | Next | Up |

This chapter explains how to solve some of those problems which tend to appear when compiling and linking your programs.

• Missing headers/libraries--GCC can't find header files/libraries.
• Missing C++ headers--GCC can't find C++ header files.
• C++ comments--Avoid C++ comments in C programs.
• Which language--GCC resolves it by looking at filename extensions.
• Objective C--Can't use ObjC 2.6.0.
• DJGPP-specific--How to write DJGPP-specific fragments.
• Unresolved externals--Where are those library functions?
• Which library--Which library has which functions?
• Libraries' order--Which libraries to put first?
• Still unresolved--C++ misses complex and iostream functions.
• Class Complex--It is now a complex template class.
• Pure virtual--Problems with pure virtual functions in C++.
• djgpp_first_ctor--Why are these unresolved?
• Large image--Static arrays bloat C++ program image.
• Large executable--Why is DJGPP .EXE so large?
• Linker script--Problems with it can cause linker to fail.
• No EXE--Novell Netware fails STUBIFY.
• Large object files--Linker fails for large objects/libraries.
• Allegro--Problems building Allegro library.

| Previous | Next | Up | Top |

Q: When I link my programs, ld.exe complains that it cannot open crt0.o, although that file exists in the lib subdirectory...

      set DJGPP=c:/djgpp/djgpp.env

Sometimes, people make errors in their AUTOEXEC.BAT that cause the DJGPP variable to be defined incorrectly, or not defined at all (some of the more common errors are listed below). To check what is the actual setting, type from the DOS prompt:

      set > env.lst

      DJGPP=c:/djgpp/djgpp.env

Many problems with setting DJGPP happen when people put excess blanks around the = character, which has the effect of defining "DJGPP " (with the blank) which is not the same as "DJGPP" (without blanks). You should make sure there are no such excess blanks, or DJGPP won't find its files.

Another possible cause of DJGPP variable not being set is that you invoke another batch file from your AUTOEXEC.BAT before the line that sets DJGPP. Make sure such batch files are invoked with the CALL statement, because otherwise the subsidiary batch file will never return to process the rest of AUTOEXEC.BAT (that's a "feature" of DOS batch file processing).

The code that processes DJGPP.ENV assumes that this file resides in the main DJGPP installation directory. If that assumption is wrong, the compiler (and some other DJGPP programs) might fail to find some of the files or auxiliary programs they need. Do NOT move DJGPP.ENV to any other directory!

Note that if you run DJGPP under Win95, WinNT or any other environment that supports long filenames (e.g., if DJGPP is installed on a networked drive whose network redirector supports long filenames), you cannot use long names of the directories in the pathname of DJGPP.ENV when you set the above variable in the environment; you should use their 8+3 aliases instead. First, some of these systems (such as WinNT) do not even support the LFN API for DOS programs. But even if LFN API is supported, e.g. on Win95, DJGPP won't know that it should support LFN until after it read DJGPP.ENV--it's a chicken-and-egg problem. For example, the following setting won't work because Development is longer than 8 characters:

      set DJGPP=c:/Programs/Development/Djgpp/djgpp.env

• You have edited the file DJGPP.ENV in a way that invalidated some of the settings there; try restoring the original file from the distribution to see if that fixes your problems. Be sure you are familiar with the syntax of DJGPP.ENV before you edit it. The DJGPP server has a page with a description of the DJGPP.ENV syntax. The syntax of DJGPP.ENV is also described in the DJGPP Knowledge Base, which comes with the djdev distribution.
• Some older versions of Novell Netware cause the linker to fail if the libraries or the startup file crt0.o reside on a networked drive. This is due to a peculiarity of Novell that happens to fail the library function stat in some cases. The exact reason of the failure has been identified, and the library which comes with DJGPP v2.01 includes a version of stat that works around that problem, so the linker from v2.01 is free of this bug, and upgrading will solve this. Another solution would be to upgrade your Novell software; version 4.x is reportedly free of this problem, even if you use DJGPP v2.0.
• You renamed the gcc.exe driver to some other name. In this case, you should edit the file DJGPP.ENV to add a section named after the new name of GCC, 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 the environment before the 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.
• Your FILES= setting in CONFIG.SYS is insufficient, so GCC runs out of available handles.

  You should have at least FILE=15 in your CONFIG.SYS.

• Your DJGPP directory is on a networked drive, and the network redirector doesn't have enough available handles in its configuration.

  Presumably, there should be a parameter in some configuration file or a command-line argument to one of the network drivers which sets the number of files that can be open simultaneously on a networked drive; you should set it to be at least 15.

• You passed the -B switch to GCC. This overrides the default location of crt0.o and if you follow -B with a directory other than that where crt0.o resides, the linker won't find it.

  You should not need to use the -B or -L switches at all if your installation is correct and the DJGPP variable points to the main installation directory, because GCC should be able to figure out all the linker switches itself. If linking fails without explicit -L or -B, check out above for the possible causes.

| Previous | Next | Up | Top |

Q: GCC complains about 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??

Another possible cause for problems with C++ include files is that your source file has a .c extension. GCC then thinks that this is a C program and doesn't instruct the preprocessor to search the include directories specific to C++. Rename your file to .cc or .cpp extension, or call GCC with the -x c++ switch, and the header files will be found. A full list of extension rules which GCC uses to determine the source language can be found in the list of language-specific suffixes, elsewhere in this FAQ.

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

• From the "Start" menu select "Run" and type regedit, to start the Registry Editor.
• Expand the 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.
• The right pane now shows the list of values assigned to the 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.
• Restart Windows 95.

| Previous | Next | Up | Top |

         #include <stdio.h>
     
         int
         main ()
         {
           printf ("%d \n" 10    //*
     		     / 2    //*/
     		       1
     		       );
           return 0;
         }

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

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

| Previous | Next | Up | Top |

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.

.cc

.C

.cxx

.cpp

C++ source (passed through cpp).

.c

C source that must be passed through cpp first.

.i

Raw C source (no cpp pass).

.ii

Raw C++ source (not to be preprocessed).

.m

Objective-C source.

.S

Assembler that must be passed through cpp first.

.s

Raw assembler source (no cpp pass).

In the examples above, PROG.C is taken as a 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 the -v switch to the GCC command line; if you see that 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 the -x LANGUAGE switch. For instance, the command

      gcc -x c++ prog.c

| 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.

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 __DJGPP__
         ... DJGPP-specific code ...
         #else
         ... not seen under DJGPP ...
         #endif

         #ifdef __DJGPP__
         #if __DJGPP__ > 2
         .... will work only in DJGPP v3.x and later ...
         #else
         .... get here for DJGPP v2.x ...
         #endif
         #else
         .... get here in DJGPP v1.x or non-DJGPP environment
         #endif

| Previous | Next | Up | Top |

When linking C++ programs, you can use the gxx command instead of gcc; it will then instruct the linker to also scan the C++ libraries automatically, so you don't have to remember doing that yourself.

Note that the first release of DJGPP v2.0 didn't include gxx.exe and the C++ STL library libstdcx.a. If you cannot find them on your machine, download the latest gcc272b.zip and lgp271b.zip archives that are dated 22-Feb-96 or later, or upgrade to DJGPP v2.01.

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 |

         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.
         .
         .
         .

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
         .
         .
         .

nm is fully described in the GNU docs. See the "nm" section of the "GNU Binutils Manual".

| Previous | Next | Up | Top |

      -lgpp -lstdcxx -lm

      gcc -o main.exe main.o sub.o -lgpp -lstdcxx

      gcc -o main.exe main.cc sub.cc -lgpp -lstdcxx -lm

      gcc -o main.exe main.cc sub.cc -lmylib -lgpp -lstdcxx -lm

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 directly, use the -L option to tell it where to look for the libraries.

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

Q: I looked into libgpp.a and there aren't any references to any Complex class functions. I also didn't find complex.cc source file in the source of Libg++ library. Where did the Complex class go?

As long as the C++ Standard is not officially published, C++ is still a moving target, and Libg++ releases that try to track it sometimes have no other alternative but to break existing code. If you use C++, you have to accept this as a fact of life.

| Previous | Next | Up | Top |

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);
     }

             gcc -c pure.c
             ar rvs libgcc.a pure.o

| Previous | Next | Up | Top |

Another reason might be that you have edited your DJGPP.ENV file in a way that prevents the linker from finding its djgpp.djl script.

Mixing an old v1.x installation with a v2.x one can also cause such problems. Be sure to delete the entire v1.x tree, or rename it, before installing the v2.x distribution.

| Previous | Next | Up | Top |

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: How come I recompile my programs with v2, and my executables become larger by some 20-30 KBytes? Isn't the latest version supposed to be better?

In general, v2 programs are about 20-30K larger on disk, but use 50-120K less memory at run-time, than v1.x programs. The larger disk image is due to two main factors:

• Part of the code that used to be inside go32 DOS extender in v1.x is now part of the library and thus gets linked into every program.
• The v2 startup code is much more powerful, but also larger.

Apart from getting to protected-mode, the DJGPP startup code also includes such functionality as wildcard expansion, long command-line support, and loading the environment from a disk file; these usually aren't available with other DOS protected-mode compilers. Exception and signal handling (not available at all in v1.x), FPU detection and emulator loading (which were part of go32 in v1.x), are now also part of the startup code.

If your program doesn't need parts of the startup code, it can be made smaller by defining certain functions with empty bodies. These functions are __crt0_glob_function , __crt0_load_environment_file , and __crt0_setup_arguments. By defining empty substitutes for all three of these, you can make the "Hello" program be 18KB on disk. These functions are documented in the DJGPP libc reference, which see.

You can make your program image still smaller by compressing it with DJP which is a DJGPP-specific executable compressor. It is fast and has no memory overhead. It also supports DJGPP Dynamically Loaded Module (DLM) technology.

Another cause for differences in executable sizes between v1.x and v2 might be the code generated by GCC: DJGPP v2 uses a newer version of GCC. Usually, the code size is quite similar, but in some cases GCC 2.7.2 has been seen to produce code which is 50% larger or 50% smaller than GCC 2.6.3 included with v1.12.

| Previous | Next | Up | Top |

Q: When I try to link a program, I get an error message which says that linker script file djgpp.lnk cannot be open. What gives?

Another possible cause of such problems is RSXNTDJ. When you install it, it replaces some of the files which come with DJGPP by its customized versions, but since version 1 of RSXNTDJ is consistent with DJGPP v2.0, these customized files still specify djgpp.lnk as the linker script, whereas DJGPP v2.01 and later has renamed that file to djgpp.djl. Please look into your rsxntdj/lib/specs file and see if it has a line like so:

       %{L*} %D %{T*} %o -Tdjgpp.lnk\

| Previous | Next | Up | Top |

Q: I run STUBIFY on a networked drive under Novell, but it doesn't produce a .EXE file. How come?

1. You can remove the other files, rename them, or move them to another directory that isn't searched by Novell.
2. You can rename the program you are trying to link.
3. You can change the way Novell searches for files (aka the search mode), so that it won't look in the directories on your PATH.
4. You can change your access rights to the directory on the PATH where the other files reside, so that you won't have write privileges to that directory.
5. You can change the search mode for STUBIFY and the linker (or for any other program that gives you that trouble) by running commands like these:

   
          SMODE stubify.exe 2
          SMODE ld.exe 2
   
   

| Previous | Next | Up | Top |

Q: I have some large libraries that I cannot link because the linker fails on them with a message saying "memory exhausted". I have plenty of virtual memory on my system, so why would ld fail?

• In case of a large library, split it into several smaller ones.
• For a module that defines large data structures, move some of the static data to other files, or allocate the space at runtime with calloc.

| Previous | Up | Top |

Q: It seems I miss one of the source files from the Allegro distribution, because Make cannot find it when I try to build Allegro.

| Previous | Next | Up |

• v2.x crash--Program which was OK in v1.x bombs in v2.0.
• Crash traceback--How to make sense out of stack dumps.
• File data corrupted--The DOS TEXT / BINARY file issue.
• Screen I/O--Beware of the buffering!
• Distributing--DJGPP programs are not self-contained.

| Previous | Next | Up | Top |

Q: My v2 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?

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 ( -559838801 in decimal) 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 only under CWSDPMI; its telltale sign is a message "Page fault at ..." that is printed when a program crashes, and an error code of 6. 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 can be disabled by setting the _CRT0_FLAG_NULLOK bit in _crt0_startup_flags ; if this makes SIGSEGV crashes go away, your program is using such illegal pointers; the stack trace printed when the program crashes should be a starting point to debug this.

An insufficient stack size can also be a cause of your program's demise, see setting the stack size, below.

| Previous | Next | Up | Top |

      symify your-program-name

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

      symify -i core.dmp yourprog

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: My program crashes when I read data files, but the same program on Unix works OK.

Q: When I read a file I get only a small portion of it.

Note that the above distinction between binary and text files is written into the ANSI/ISO C standard, so programs that rely on the Unix behavior whereby there's no such distinction, are strictly speaking not portable.

You can also use the low-level _read and _write library functions which give you the direct interface to the DOS file I/O; they always use binary I/O.

| Previous | Next | Up | Top |

Q: Help! I cannot make `gotoxy' work! The text I print appears on the screen in incorrect locations after I use `gotoxy'!

Q: Why does the text appear in the default colors even though I call `textcolor' and `textbackground'?

It is usually a 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 generally work under DOS and DJGPP, note that in some cases the operating system might further buffer your output, so sometimes a call like sync would be needed to actually cause the output be delivered to the screen.

The functions that set text attributes only affect the screen-oriented output (aka conio) functions ( cputs , cprintf etc.), the text written by fprintf and other stdio functions doesn't change. This is unlike some 16-bit DOS compilers where stdio functions can also print colored text.

| Previous | Up | Top |

If your program could be run on a machine which lacks a 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, write to Charles Sandmann and ask him about a modified stub code that creates an image of CWSDPMI if none is found first time the program is run.

You can bind PMODE/DJ with your program, but remember that PMODE/DJ doesn't support virtual memory, so such programs will only run on machines with enough free physical RAM.

| Previous | Next | Up |

A tutorial is available on graphics programming with DJGPP.

• Which driver--What driver to use with your SVGA?
• Direct access--Under protected-mode it is (almost) forbidden.
• GRX and Windows--Windows can mess up your graphics screen.

| Previous | Next | Up | Top |

Q: How do I tell GRX which driver to use with my SVGA?

       set GRX20DRV=et4000 gw 1024 gh 768 nc 256

ati28800

The ATi 28800 chip-set.

cl5426

Cirrus Logic CL-GD5426 or higher (like CL-GD5428) chip-set.

et4000

Tzeng Labs ET4000 chip-set.

mach64

The ATi Mach-64 SVGA.

stdega

The standard EGA adapter.

stdvga

The standard VGA adapter.

VESA

For any VESA-compatible adapter.

If your chip-set is not one of the above, try the VESA driver because many adapters support the VESA BIOS extensions. If yours doesn't, try installing a VESA BIOS emulator, like UNIVBE.

| Previous | Next | Up | Top |

Q: How can I access the text-mode video memory of my VGA?

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 the _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 faster access (and don't want to write it in assembly), See using the "nearptr" access facilities, as described below.

If your video card supports the VBE 2.0 standard, you can access the linear frame buffer as a normal array in memory. For an example of such a technique, see the VBE example code by Charles Sandmann. You can also reach this file via the Web.

| Previous | Up | Top |

The only reasonable thing to do is to dedicate a "hotkey" in your application (e.g., Alt-R) whose action is to redraw the entire screen. If you do that, it's best to start all the way from the beginning, with a call to GrSetMode , as there are a few bad Windows video drivers which do not restore SVGA graphics modes properly upon the switch back.

| Previous | Next | Up |

• Emulation--What are your emulation options.
• Other emulators--You can't use them.
• OS/2 emulation--It doesn't serve DJGPP programs.
• -msoft-float--This GCC switch isn't supported.
• Numeric exceptions--Don't give us these NaN's!
• Emulator accuracy--Not always as good as we'd like.
• SIGFPE with ObjC--Objective C cannot run without FPU.
• SIGFPE in ldexp--Some libm functions bomb.

| Previous | Next | Up | Top |

Q: What shall I install on a target machine which lacks hardware floating-point support?

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. (But you will need to get the sources and recompile it, since it was compiled with a beta release of DJGPP and will cause unresolved externals if you try linking against libwmemu.a without recompiling it.) Note, however, that even WMEMU doesn't solve all the problems of debugging FP programs on a non-FPU machine (e.g., emulating flags doesn't work).

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

| Previous | Up | Top |

| Previous | Next | Up |

• How to debug--What should you do to debug a program.
• Old QDPMI--Some QDPMI versions will crash the debugger.
• GDB needs COFF--GDB can't use the .exe program.
• Transfer buffer--Beware--debuggers use the transfer buffer.
• Debug graphics--Debugging GUI programs.
• GDB and C++ source--Problems with non- .cc extensions.
• C++ classes in GDB--Class members' names in GDB.
• Included source--Debuggers have problems with included files.
• Debugging woes--Some programs which cannot be debugged.

| 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

      gdb myprog.exe

      gdb myprog

1. RHIDE, the DJGPP IDE by Robert Hoehne (available from the DJGPP archives). It includes an integrated source-level debugger based on GDB code and presents a user interface like that of Borland's IDE or Turbo Debugger.
2. RHGDB, a stand-alone version of GDB with a Turbo Vision user interface. RHGDB is part of the RHIDE distribution; it only supports part of GDB features.
3. FSDB, the full-screen debugger, from the djdev distribution. This presents a user interface like that of Borland's Turbo Debugger, but unlike TD, it isn't a source-level debugger (although it will show the source code together with the machine instructions). It also supports data-write breakpoints: a powerful feature for hunting down code which overwrites data it shouldn't touch. Another advantage of FSDB is that you can easily debug programs that grab the screen, because it can switch between the debugger screen and the application screen. The main disadvantage of FSDB is that you cannot easily examine the contents of complex data structures. Remember to prepend an underscore _ to the names of C identifiers when you use them with FSDB; for C++ programs you will have to find out the mangled names of static class variables and methods to make FSDB understand them.
4. The GNU Debugger, GDB (get the file gdb416b.zip. This is a powerful source-level debugger, but it uses a line-oriented user interface. People who are familiar with using GDB on Unix should know about the following important differences in its operation on MS-DOS:
   • The command-line arguments can be only passed to the debuggee from within the debugger (use the set args or run commands), not from the GDB command line.
   • You cannot rerun the debuggee when it exits. You must exit GDB and restart it.
   • GDB is currently configured for DJGPP in a way that makes loading a program and reading a source file when a breakpoint is hit exceedingly slow: it can take more than a minute for a very large program. Be patient and don't decide that GDB is wedged unless you've waited several minutes. A source-level patch to GDB was posted to the DJGPP News group, which corrects this problem; you can get this patch by searching the DJGPP mail archives.
   • GDB doesn't know about PC-specific keys, so you cannot use the arrow keys for command history editing. Use ASCII control keys instead (^F for forward character, ^B for backward character, ^P for previous line, ^N for next line, etc.).
   • The debugger and the debuggee share their file handles. This means that if your program redirects or closes its stdin or stdout , you will be unable to communicate with GDB.
   • The initial commands are read from a file named gdb.ini instead of .gdbinit which isn't a legal filename under MS-DOS.
   • GDB uses the GNU readline package for its input. The readline init file (~/.inputrc on Unix) is called /inputrc on MS-DOS and should be in the root directory of the current drive.
5. EDEBUG32 is the most basic debugger you can use with DJGPP. One case when you would need to use it is when you debug a DXE module (see explanation of what a DXE is), because GDB doesn't support debugging DXEs.

      <debugger-name> <program> <args...>

| Previous | Next | Up | Top |

      qdpmi off

| Previous | Next | Up | Top |

      gcc -o foo foo.o

      gcc -o foo.exe foo.o

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

The FSDB debugger can switch between the application screen and the debugger screen, so you might use it, at a price of working with a low-level debugger. Press Alt-F5 to switch between the two screens. Stock FSDB as distributed with DJGPP can only do this with text screens, but a modified version of FSDB with graphics support is available that knows about many graphics modes (it can also be found on the Oulu repository).

Future versions of RHIDE might allow debugging graphics programs, so try to find out whether such a version is available.

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. Be sure that you don't have some other TSR installed that catches screen writes and bypasses the BIOS functions, or else MSHELL won't help you. For example, changing the code page (with the DOS CHCP or MODE commands) might do this.

| Previous | Next | Up | Top |

      file.cc: No such file or directory.

| Previous | Next | Up | Top |

       b 'CMPForward::go'

However, there are some cases where you won't be able to get GDB to demangle C++ function names no matter how hard you try. This is due to a lack of sufficient debugging information in the COFF files with SDB debug data. There's simply not enough info there for GDB to detect the source language and use C++-specific support. If you need a description of the GNU style of mangling C++ names (so you could demangle them yourself), look in the GDB or Libg++ source distribution, in the libiberty directory, for a file named cplus-demangle.c. If you really need full C++ support in DJGPP, you will have to recompile GCC with stabs debugging support. Robert Hoehne, who did that, reports that it is only necessary to change the configuration file go32.h in the GCC sources and rebuild cc1.exe and cc1plus.exe. Caveat emptor: FSDB and EDEBUG32 don't understand stabs, so you will have to compile with -gcoff option to use these debuggers.

Note that, as the debugger built into RHIDE uses GDB code, it will also sometimes have such problems with debugging C++ programs.

| Previous | Next | Up | Top |

Q: I cannot debug code produced by Flex, or Bison, or F2C, because GDB somehow messes up all the source file and line number info!

| Previous | Up | Top |

Q: I cannot debug any program which catches signals!!??

Q: I compiled my program with -pg switch, and now I cannot debug it...

Q: When my program hits a breakpoint in GDB, the debugger reports SIGSEGV, but only under Windows...

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 where 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). Some programs (but not Emacs) will also treat the Ctrl-2 keypress as Ctrl-C.

Another known problem is that GDB GP Faults when the program hits a breakpoint under Windows 3.x (Windows 9x doesn't have this problem). This is because the breakpoint instruction causes a software interrupt (as opposed to an exception) under Windows 3.x, and the DJGPP debug support currently only catches debug exceptions. The only work-around is to use the hardware breakpoints (which use the special debug registers of the i386 and higher CPUs, and which do work with DJGPP on Windows 3), and never have more than 4 of them active at the same time. FSDB will automatically use the hardware breakpoints for the first 4 breakpoints (so it works on Windows 3.x unless you set more than 4 breakpoints simultaneously), but with GDB, you will have to explicitly use the hbreak and thbreak (instead of break and hbreak) commands which set hardware breakpoints. This works with DJGPP ports of GDB 4.16 and later. Note that GDB uses the ordinary breakpoints to implement the step, next and similar commands, so you can't use these on Windows 3.x; use the temporary hardware breakpoints instead. The above is also true for watchpoints (which watch for variables to change value): you need to use hardware watchpoints with GDB (the total number of breakpoints and watchpoints cannot exceed 4). Same considerations apply to the debugger built into RHIDE.

| Previous | Next | Up |

• How to profile--What should you do to profile a program.
• Profiled crash--Programs compiled with -pg crash.
• Gprof needs COFF--Gprof doesn't like .exe executable.
• Gprof docs--Look on Gprof man page for its docs.
• I/O bound programs--How their profiles look.
• No profile--Where is the profile?

| Previous | Next | Up | Top |

      gprof myprog

Gprof is part of GNU Binutils distribution.

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

Q: I run Gprof on my program, and it says: "bad format".

| Previous | Next | Up | Top |

Q: I can't figure out some of the info in the Gprof report ...

| Previous | Next | Up | Top |

| Previous | Up | Top |

• You didn't compile and/or link your program with the -pg switch. Note that both compilation and link need to be done with -pg, because the functions that actually write the results to gmon.out are only linked in when gcc sees -pg on the link command line.
• You have called ld.exe directly to link your program and forgot to mention the files and switches necessary for the profiled program operation. You should use gcc to link your program instead of calling the linker directly; a -pg switch to gcc is all that it takes to make sure that the linker will get all the necessary arguments.

  Note: If you absolutely need to call ld.exe directly, invoke gcc once with a -v switch and you will see what the arguments are that you should pass to the linker in your case.

• Your program exited abnormally. The function which generates gmon.out is registered with the atexit library function, and won't be called if the program was terminated in an abnormal way. Make sure that your program exits with a call to exit library function or with a return statement in your main function. For example, if your program dies with an exception or a signal, install a signal handler and make it call exit.

| Previous | Next | Up |

• How fast--What code quality should you expect.
• Faster v1--Is v1.x faster than v2?
• Pentium--DJGPP programs on a Pentium.
• I/O speed--Is I/O really so slow in protected mode?
• Slow-down--What if your ported program runs slower?

| 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 timed a test program and it seems that DJGPP v2.01 produces slower executables than v2.0, which in turn was slower than v1.x. Why are we giving up so much speed as we get newer versions?

Comparison between GCC 2.7.2 (in v2.0) and 2.7.2.1 (in v2.01) shows that 2.7.2.1 optimizes just as well as 2.7.2, but it takes a different combination of the optimization-related options to achieve the greatest speed in each compiler version. The default optimization options has also changed; for example, -force-mem is switched on by -O2 in 2.7.2.1; it wasn't before. GCC offers a plethora of optimization options which might make your code faster or slower (see the GCC docs for a complete list); the best way to find the correct combination for a given program is to profile and experiment. Elliott Oti suggests the following tips:

• Compile your code with the ordinary compilation switches -O2 -m486 -fomit-frame-pointer -ffast-math.
• Profile your code and check which functions are "hot spots". Disassemble them, or compile with -S, and examine the machine code.
• If the disassenbly shows there aren't too many memory accesses inside the inner loops, try adding -fforce-addr option; it helps a lot if a couple of pointers are used heavily within a single loop. If there are a lot of memory references, try adding -fno-force-mem, to prevent GCC from repeatedly copying variables from memory into registers.
• Try adding -funroll-loops and -funroll-all-loops and profile the effect.
• If different time-critical functions exhibit different behavior under some of the optimization options, try compiling them with the best combination for each one of them.

| Previous | Next | Up | Top |

Q: I run the same program on a 486 and on a Pentium, and it's slower on a Pentium!!

A program might sometimes run slower on a Pentium due to alignment problems in DJGPP. GCC makes assumptions about how GAS (the assembler) handles alignment, but when GAS is built with the default DJGPP configuration, it treats alignment in a way that's different from what GCC assumes. The outcome of this is that longs are word-aligned, doubles are dword-aligned, etc. Depending on the DJGPP version, link order, library differences, you might get lucky (or unlucky) with a 50/50 chance to get an improper alignment. Different CPUs have different penalties for unaligned accesses, which may explain differences in speed.

You might consider adding some slack static variables to induce changes in alignment; if any of the changes suddenly cause a significant change in the runtime performance, then alignment might be the reason.

| 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?

Some programs which only copy data between two files might gain significantly if you write your custom low-level I/O functions that avoid moving data to extended memory (only to move them back to the transfer buffer). However, these cases are rare.

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.

| Previous | Up | Top |

1. Your program extensively calls services other than I/O which require mode switch (like BIOS Int 10h, mouse services, etc.). 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).
2. Your program uses library functions/classes which are implemented less efficiently by GCC. Or you might be a heavy user of functions which other compilers convert to inline code, while GCC doesn't inline most library functions. If this is the case, you will see those functions as "hot spots" on the program histogram produced by the Gprof profiler. If you find this to be the problem, write your own, optimized versions of those functions. It's best to write them as inline assembly functions, for maximum performance. If you find library functions which are inefficient, please inform the DJGPP news group by posting to the comp.os.msdos.djgpp news group, so this could be fixed by people who maintain the library.
3. If your program spends most of its time in a certain innermost loop, you should try enabling some of the optimization options which aren't enabled by default.

| Previous | Next | Up |

• How much memory--How much can you use?
• Confusing alloc--Allocation mechanism peculiarities.
• QDPMI VM--QDPMI doesn't provide virtual memory.
• QDPMI alloc--QDPMI/Win 95 memory allocation peculiarities.
• Windows alloc--VM issues under Windows 3.x.
• Win9x alloc--VM peculiarities under Win9x.
• EMM386 alloc--Some versions of EMM386 are limited to 32 MBytes.
• Swap out--How much VM do spawned program have?
• Stack size--How large is the stack and how to enlarge it?

| Previous | Next | Up | Top |

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 in 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). Under Windows 9x, the memory settings of the DOS Applications' Property Sheet define how much virtual memory a DJGPP program will get (see Win9x allocation details, below).

| Previous | Next | Up | Top |

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.

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 |

     DPMI: Not enough memory (0x00860000 bytes)

     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 |

Q: Why is my program dying with SIGSEGV under CWSDPMI when allocating a chunk of memory?

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) 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.

If your program asks for memory in lots of small allocations, then it might crash when you use CWSDPMI as your DPMI host. This is because CWSDPMI runs out of its tables where it tracks memory allocations. If you use release 1 of CWSDPMI, you can enlarge the maximum space that CWSDPMI uses if you get a CWSDPMI heap-fix patch. Beginning with release 2, CWSDPMI defines a larger (6KB) default heap that is configurable by CWSPARAM program to be anywhere between 3K and 40K bytes, without recompiling CWSDPMI. You should upgrade to the latest CWSDPMI if you experience such problems.

| Previous | Next | Up | Top |

      PageOverCommit=n

| Previous | Next | Up | Top |

Note that you cannot allocate more than half the available memory in one chunk under Windows 9x, exactly as the things are under Win3.x, and you cannot have more than 64 MBytes of virtual memory available to DJGPP programs running on Windows.

| 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 it should 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 |

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 than it used to be with v1.x, except on machines with low amounts of installed RAM. A disadvantage is that if you spawn a real-mode program that uses XMS, the extended memory used up by your DJGPP program will be unavailable to it, unless you use a memory manager (as opposed to when CWSDPMI uses raw XMS or HIMEM). The only way around this problem is to buy more RAM, or to install a real memory manager.

Note that if you use a memory manager such as EMM386 or QEMM386 with the NOEMS parameter, CWSDPMI will use the XMS (as opposed to VCPI) services to allocate extended memory, and will allocate all of the available XMS memory for itself. So if, while your DJGPP program runs, some resident software such as device driver or TSR will try to allocate XMS, the allocation will fail.

| Previous | Up | Top |

Q: How much stack space do I have in my program?

Q: My program seems to overflow the stack, but only when I run it under a debugger...

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 is going on??

      unsigned _stklen = 1048576;  /* need a 1MB stack */

Programs which need an unusually large stack might crash with bogus stack traces, because part of the heap gets 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 and recompile the program. (Some DPMI hosts will actually allocate the entire 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 (e.g. if it has a wrong syntax).

When you run a program as an un-stubbed COFF image under a debugger, the stack size comes from the debugger. So if your program needs a large stack and you run it under gdb , be sure to stubedit gdb to enlarge its stack to at least the value your program needs to run safely.

Under Windows, be sure you've allocated a sufficiently large swap file (let's say, 40MBytes) from the Windows' Control Panel, and 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 file DOSPRMPT.PIF, which almost surely defines very low limits on these two, and your program might have problems getting the memory it needs for its stack.

DJGPP v2.0 has a subtle bug in its startup code that is seen very rarely, and that manifests itself by a program crashing with Page Fault or SIGSEGV. If you are using v2.0 and enlarging the stack and the CWSDPMI heap size didn't help, try adding some (e.g., 4KB) static data to your program and see if that helps. But the best way to overcome this is to upgrade to DJGPP v2.01 or later.

| Previous | Next | Up |

• Filename globbing--Wildcard expansion under DJGPP
• Disable globbing--You can disable globbing if you don't need it.
• Special chars--How to pass arguments with special chars.
• Long commands--DJGPP can pass very long command lines.
• How long--Look here to find out how long.
• Makefiles--Makefiles can disable long command lines.

| Previous | Next | Up | Top |

Q: I call my program with an argument x*y and it complains about something called xyzzy??...

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:

?

any single character.

*

zero or more arbitrary characters, including a dot `.'

[aA_]

any one of characters `a', `A', or `_'.

[a-d]

any one of characters `a', `b', `c', or `d'.

[!a-z]

anything but a lowercase letter.

...

all the subdirectories, recursively (VMS aficionados, rejoice!).

.../*

all the files in all subdirectories, recursively.

Note that *.* only picks up files that actually have an extension. This is contrary to the usual DOS practice where it means all the files, with or without extension.

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 |

• Surround your arguments with single or double quotes (this is what you would do under a Unix shell).
• Disable globbing for your program by linking it with your custom version of the function with the special name __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?

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?). This is also different from what you get under a Unix shell.

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?

• The !proxy method. If you invoke the program from within another DJGPP program (like Make or Gcc compilation driver), it gets the address of the memory block where the actual command line is stored. The start-up code will detect this and use that info to retrieve the command-line arguments.

  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.

• The environment method. This is the same as the !proxy method above, but the information about the long command line is stored in an environment variable called " !proxy" (with the leading blank and in lower-case). The reason for two similar, but different methods is that command-line arguments passed by system library functions should be globbed by the child, while the arguments passed by spawnXX and execXX family of functions should not; thus the former uses the environment method while the latter use the !proxy method.
• The response file method. Any argument which starts with a @ character (like in myprog @file) will cause the named file to be read and its contents used as command-line arguments, like in many DOS-based compilers and linkers. If you invoke your DJGPP program from the DOS command line, this would be the only method available for you to pass long command lines (like when calling Gawk or Sed without -f option).

  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 |

The above limit depends on the size of the transfer buffer, so check the size of the value recorded in the stub header of the parent program before you pass extremely long command lines to its children. GCC is the first program you should worry about, because the linker (ld.exe) usually gets long command lines from GCC (they include the list of all the object files and libraries to be linked).

| Previous | Up | Top |

       frobnicate foo.bar > myfile.tmp

       redir -o myfile.tmp frobnicate foo.bar

| Previous | Next | Up |

• Syntax--The (AT&T) syntax of Gas is different.
• Gas bugs--Don't trust Gas!
• Converting ASM--Automated conversion tool.
• ASM GPF--When converted code crashes.
• OBJ and LIB--You can't use them with GCC.
• 16-bit code--...or can you?
• NEAR and FAR--How to convert these to DJGPP.
• Pseudo-registers--Converting _AX to DJGPP code.

| Previous | Next | Up | Top |

• AT&T immediate operands are preceded by $ ; Intel immediate operands are undelimited (Intel push 4 is AT&T pushl $4 ).
• AT&T register operands are preceded by % ; 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.
• AT&T and Intel syntax use the opposite order for source and destination operands. Intel 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 some of GCC installations (on systems other than MS-DOS) don't use GNU Binutils.
• In AT&T syntax, the size of memory operands is determined from the last character of the opcode name. Opcode suffixes of 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.
• Immediate form long jumps and calls are 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.
• The AT&T assembler does not provide support for multiple-section (aka multi-segment) programs. Unix style systems expect all programs to be single-section.
• An Intel syntax indirect memory reference of the form

  
        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

      info as machine i386

A guide is available which was written by Brennan Mr. Wacko Underwood; it describes how to use inline assembly programming with DJGPP and includes a tutorial on the AT&T assembly syntax. Check out the DJGPP inline assembly tutorial. Many people who used Intel syntax and then converted to the AT&T style say that they like the AT&T variant more. However, if you prefer to stick with the Intel syntax, download and install NASM, which is a free portable assembler. It is compatible with DJGPP and accepts a syntax which is almost 100% compatible with the Intel style.

| Previous | Next | Up | Top |

1. Use explicit sizing. E.g., use 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.
2. Write code segment overrides as .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 the phase of the moon is at the moment of assembly, use .byte constants.
3. Make sure the operands match the instructions. Don't assume that if they don't, you'll get an error message from the assembler.

| Previous | Next | Up | Top |

Alternatively, here is what you can do to make your code linkable with DJGPP programs:

• Get and install NASM, a portable x86 assembler which supports most of the Intel syntax and can generate DJGPP-compatible COFF object files (as well as lots of other formats, such as Microsoft 16-bit OBJ and Win32, a.out, and ELF). It also supports Pentium and Pentium Pro opcodes. NASM is free for non-commercial use (see the docs for commercial use restrictions) and can be compiled with DJGPP. You can get NASM from sunsite mirrors. A pre-compiled MSDOS binary is available from SimTel.NET sites. The author and maintainer of NASM is Simon Tatham.
• For a small number of relatively short files, consider converting them with a smart editor (like Emacs or its work-alikes).
• Obtain a copy of Microsoft MASM 6.11. It has a -coff option to generate object code in COFF format which can be submitted to GCC, so you can compile your original source. You can also use the LIB32 librarian from Microsoft C8 to convert object files to COFF by putting them into a .lib library, then extracting them as COFF files.

  Note: If you use MASM or LIB32, please post your experiences to comp.os.msdos.djgpp news group, so that I can make the above instructions less vague.

• Use a disassembler to disassemble the object code, then convert it to the AT&T format either by hand or using TA2AS. One place to look for such a disassembler is on SimTel.NET mirrors.

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 of the 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:

• Loading arbitrary values into segment registers, then using them to reference code or data.
• Referencing code with data segment register, or vice versa.
• Assuming certain locations (like BIOS area or video memory) will be found at certain absolute addresses.
• Calling DOS or BIOS services with INT NN instruction.

| Previous | Next | Up | Top |

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?

Note: Note that mixing object files from different compilers usually won't work either, even if they both are in the .obj format.

Lately, an automated conversion tool called OBJ2COFF was written by the SPiRiT team, which can be used to convert .obj object files and .lib libraries to COFF format, provided that the original .obj files 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 DJ Delorie's ftp server. If you have any problems with it or questions about it, send them to its author, Rico or to George van Venrooij. Note that the authors of OBJ2COFF have explicitly prohibited commercial use, so you shouldn't use OBJ2COFF for converting commercial object files.

Another conversion tool you might try is EMXAOUT from the emx/gcc package. It also requires the code to be written for the flat-address memory model and will reportedly complain if you feed it with code written for segmented memory models. EMXAOUT is available from the SciTech Software FTP site. If you need, you should be able to compile it with DJGPP; however, a precompiled binary is available in the above archive. Or you can get EMXAOUT from the EMX archives and the RSX extender (for running EMXAOUT under DPMI) from the RSX archives.

Note that EMXAOUT produces object files in a.out format, whose support in DJGPP is not as full as that of COFF . For example, ld.exe (as of Binutils 2.7) doesn't support a.out object files inside .a libraries, so you will have to link them as .o files.

| Previous | Next | Up | Top |

Now will you consider sticking with DJGPP? Please??...

| Previous | Next | Up | Top |

Q: A program written for a 16-bit compiler uses the MK_FP or _MK_FP macro, but DJGPP doesn't seem to have it. How should I port it?

       #define far
       #define near
       #define huge
       #define _far
       #define _near
       #define _huge

       gcc -Dfar -Dnear -Dhuge -c myprog.c

       #include <sys/nearptr.h>
       #include <crt0.h>
     
       void * MK_FP (unsigned short seg, unsigned short ofs)
       {
         if ( !(_crt0_startup_flags & _CRT0_FLAG_NEARPTR) )
           if (!__djgpp_nearptr_enable ())
             return (void *)0;
         return (void *) (seg*16 + ofs + __djgpp_conventional_base);
       }

Macros that extract the segment and the offset from a far pointer (called FP_SEG and FP_OFF ) are required in 16-bit code to pass addresses in registers when calling real-mode DOS or BIOS services, like functions of interrupt 21h. See How to call real-mode interrupt functions, which describes how that should be done in DJGPP; here, too, you won't need to port the macros but instead rewrite the code that calls the DOS or BIOS service.

| Previous | Up | Top |

• When calling real-mode interrupt services. To port such code to DJGPP, use the fields of the __dpmi_regs structure (declared on the dpmi.h header file) to set the register values, and library function __dpmi_int to invoke the interrupt service. For example, consider the following code snippet:

  
         #include <dos.h>
         void _highcolor (void)
         {
           _AH = 0x10;
           _AL = 0x03;
           _BL = 0;
           geninterrupt (0x10);
         }
  
  

  Note: This calls the video BIOS interrupt 10h to allow bright background colors to be used instead of blinking characters. DJGPP has a library function, called intensevideo , to do that, but let's assume we have reasons not to use it.

  Here's one way to express this in DJGPP:

  
         #include <dpmi.h>
         void _highcolor (void)
         {
           __dpmi_regs r;
       
           r.h.ah = 0x10;
           r.h.al = 0x03;
           r.h.bl = 0;
           __dpmi_int (0x10, &r);
         }
  
  

  Please read How to call real-mode interrupt functions, elsewhere in this document, for further details on how call real-mode services from DJGPP programs.
• Immediately before or after an inline assembly code. GCC features extensive inline assembly facilities which allow you to assign values to, or read values from registers from the inline assembly code. See Inline Assembly code with GCC, for further info.

| Previous | Next | Up |

• int86--It doesn't always work.
• Pointer segment--Some interrupts require it, but how do you get it?
• Zero SP--If you don't, your program crashes.
• Xfer--Moving data to and from conventional memory.
• 20 bits--You should mask off the upper 12 bits when unused.
• Fat DS--Fast direct access to memory-mapped devices.
• Above 1MB--Interact with memory-mapped devices above 1MB.
• RMCB--How to let DOS/BIOS call your code.
• Hardware interrupts--How to hook HW interrupts from DJGPP.
• _go32 vs __dpmi--Which functions should you use?
• HW Int pitfalls--Does your machine wedge? Here are some reasons.
• Ports--Reading and writing I/O ports in DJGPP.
• Inline Asm--How to write inline assembly with GCC.

| Previous | Next | Up | Top |

| Previous | Next | Up | Top |

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 (at least 2KB, 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, but it can be made as small as 2KB), 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;

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 to 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 (however, it can never be less than 2KB, the size of the stub, because memory used by the stub is reused for the transfer buffer).

| Previous | Next | Up | Top |

Note: The DPMI spec indicates that you should not use the default stack if your procedure/interrupt handler uses more that 60 bytes, or 1/8 of the total stack space available by default.

In these cases you should point SS and SP to a larger buffer which is in conventional memory (possibly part of the transfer buffer).

If SS:SP isn't zero, it will be used as the address of the stack for the interrupt handler, so if it points to a random location, your program will most certainly 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 a user-defined stack, it's easier to call the __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 function 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?

• Use the selector that DJGPP creates for itself to access conventional memory. DJGPP makes this selector available to you via the _dos_ds macro (defined on header file). This selector has base address of 0 and a limit of 1MB, so you can use it to access any address in the conventional memory, but the relatively large limit allows a buggy program to overwrite portions of DOS memory.

  Note: Original release of DJGPP v2.01 makes the limit of _dos_ds be 4GB, which effectively disables memory protection when you use that selector. However, since no memory outside the first 1MB is properly mapped into your program's address space without additional DPMI calls, and the DPMI host is then free to put memory-mapped devices, such as Weitek I/O space or the linear frame buffer of an SVGA, on any address it sees fit, that huge limit is an unjustified security hole.

  The advantage of _dos_ds is obviously that you don't have to create it, and that it is good for accessing every region in the first MByte range.

• Create your own selector that spans only the region of memory that you want to access, and use that selector instead of _dos_ds . For example, here's a code snippet to set up a selector which provides access to 64KB of text-mode video memory at 0xB800:0000 , courtesy of Bill Currie:

  
         int TxtVRAMSetupSelector (void)
         {
            static char selectorData[8] = {
              0xff, 0xff, 0x00, 0x80,
              0x0b, 0xf3, 0x40, 0x00
            };
            int screenSelector = __dpmi_allocate_ldt_descriptors (1);
            if (__dpmi_set_descriptor (screenSelector, selectorData) < 0)
              abort ();
            return screenSelector;
         }
  
  

  The advantages of this method are that (1) you can set up the selector limit such that it only covers the memory region that you need, thus protection of the rest of memory is retained; and (2) you may set the base address to point to the beginning of the specific memory region you need to access, so that you don't have to add the base address for every access, making the access faster. For details about the contents of the 8-byte selector descriptor, see the documentation of the __dpmi_get_descriptor function in the library reference Info file.
• Use the DPMI service which creates a selector to access a specific real-mode segment address. The DJGPP library has a function __dpmi_segment_to_descriptor which is a wrapper around that DPMI service. It is easier to use than the __dpmi_set_descriptor function above, since you don't have to mess with the 8-byte descriptor buffer, but it always defines a 64KB limit by default. Here is an example of code which gets a selector to access 64KB of video RAM beginning at 0xA000:0000 :

  
         short video = __dpmi_segment_to_descriptor(0xa000);
  
  

  Note that descriptors created by this function should never be modified or freed. For this reason, you should use this function sparingly. For instance, if your program needs to examine various real mode addresses using the same selector, you should allocate a descriptor and change the base using the __dpmi_set_segment_base_address library function instead of using __dpmi_segment_to_descriptor to allocate separate descriptor for each address.

• If you want to access a byte, a 16-bit word, or a 32-bit double word, use the "far pointer" functions declared on the 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 or any other 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 the 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.

• If you need to access more than 4 contiguous bytes, use dosmemget and dosmemput library functions. They also require you to 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 (they use _dos_ds internally).

  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.

• For moving buffers to selectors other than _dos_ds (e.g., created by one of the methods explained above), use the movedata library function. It requires that you pass a selector and an offset for both the conventional memory address and for the buffer in your program's address space. Use the _my_ds function (note that it's a function, not a variable!) to get the selector of any variable in your program, and use the address of the variable (cast to an int ) as its "offset" or linear address. movedata is fast because it moves by 32-bit longs, but be careful with its use when moving data to and from peripheral cards: some 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.

  For example, here is a code snippet that combines one of the methods for allocating a descriptor for video RAM access with a call to movedata to move a buffer to the graphics screen:

  
         short video = __dpmi_segment_to_descriptor(0xa000);
         movedata(_my_ds(), buffer, video, 0, 320*200);
  
  

• For the fastest access to memory outside your usual address space, you might consider using the "nearptr" functions declared on the header; see the 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 |

| 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. Linux's DOSEmu and Win/NT won't allow you to set such a huge limit on the memory segment, because these operating systems take memory protection seriously; in these cases __djgpp_nearptr_enable will return zero--a sign of a failure. CWSDPMI, QDPMI, Win 3.x and Win 9x all allow this technique (OS/2 Warp seems to allow it too, at least as of version 8.200), but some events break this scheme even for those DPMI hosts which will allow it. A call to malloc or any other library function which calls sbrk might sometimes change the base address of the 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 a result of some other events external to the executing code thread, like multitasking or debugger execution.

You should also know that the __djgpp_nearptr_enable function in DJGPP v2.0 didn't verify that the limit was properly set. So if the DPMI server would fail the call silently, the function won't detect it and will not return a failure indication. DJGPP v2.01 corrects this omission by always verifying that the DPMI host has honored the request, and returns a failure indication if it hasn't.

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".

Another possibility is to use the DPMI function 0x508 that can map any range of physical memory addresses into a block that you allocate. Note that this is a DPMI 1.0 functionality which is not supported by most DPMI 0.9 hosts (CWSDPMI does support it). There is a helper function __djgpp_map_physical_memory in the DJGPP C library that you can use to call these services.

| Previous | Next | Up | Top |

       #include <dpmi.h>
       #include <go32.h>
     
       static __dpmi_regs        callback_regs;
       static _go32_dpmi_seginfo callback_info;
     
       int install_mouse_handler (unsigned mask,
                                  void (*func)(__dpmi_regs *))
       {
         __dpmi_regs r;
     
         callback_info.pm_offset = (long)func;
         if (_go32_dpmi_allocate_real_mode_callback_retf(&callback_info,
                                                         &callback_regs))
           return -1;  /* failure */
     
         r.x.ax = 0xc;
         r.x.cx = mask;
         __dpmi_int (0x33, &r);
         return (r.x.flags & 1) ? -1 : 0;
       }

       info gcc "C Extensions" "Extended Asm"

      C:\USR\BIN> stubify -g dj2.exe
      C:\USR\BIN> stubedit dj2.exe runfile=dj1

      ln -s dj1.exe dj2.exe

     mkdir X/dos-binutils
     cd X/dos-binutils
     configure --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
     cp ld.new /usr/local/i386-go32-msdos/bin/ld
     
     cd ../../..
     mkdir X/dos-gcc
     cd X/dos-gcc
     configure --target=i386-go32-msdos
     # Note: this produces errors building libgcc.a.  Ignore them.
     # The libraries will come from the cross-compiler kit.
     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

     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/* .

       #include <sys/types.h> 
       #include <unistd.h> 

      gcc-dos hello.c -o hello.exe

      i = 0xfe+0x20;

       struct my_struct {
         char name[7];
         unsigned long offset;
         double quality;
       };

       struct my_struct {
         double quality;
         unsigned long offset;
         char name[7];
       };

       struct {
         char name[7];
         unsigned long offset;
         double quality;
       } __attribute__ ((packed));

       #ifdef __cplusplus
       #pragma pack(1)
       #endif
       .
       .
       .
       #ifdef __cplusplus
       #pragma pack()
       #endif

       makefile:10: *** missing separator.  Stop.

      set TZ=c:/djgpp/zoneinfo/israel

      set TZ=c:/djgpp/zoneinfo/us/alaska

     John M. Aldrich
     Anthony Appleyard
     John Bodfish
     Francois Charton
     Bill Currie
     Bill Davidson
     DJ Delorie
     Tom Demmer
     Juergen Erhard
     Jeremy Filliben
     James W. Haefner
     Koen Van Herck
     Robert Hoehne
     Gordon Hogenson
     Harry Johnston
     Martynas Kunigelis
     Pieter Kunst
     Y. Lazarovitch
     Alexander Lehmann
     Marty Leisner
     Dave Love
     Rob Nader
     Eric Nicolas
     Elliott Oti
     Esa A E Peuha
     Walter Prins
     Steve Salter
     Charles Sandmann
     Terrel Shumway
     Andrew Szymkowiak
     Launey Thomas
     Chris Tilbury
     Stephen Turnbull
     Santiago Vila
     Ronan Waide
     Morten Welinder
     Anthony Edward Wesley
     Mark H. Wood