home *** CD-ROM | disk | FTP | other *** search
/ PC Extra Super CD 1998 January / PCPLUS131.iso / DJGPP / V2 / FAQ210B.ZIP / info / djgppfaq.info
Encoding:
GNU Info File  |  1997-01-17  |  404.3 KB  |  8,936 lines
  1. This is Info file djgppfaq.info, produced by Makeinfo version 1.67 from the
  2. input file djgppfaq.num.
  3.  
  4. START-INFO-DIR-ENTRY
  5. * FAQ: (djgppfaq).           The DJGPP FAQ list.
  6. END-INFO-DIR-ENTRY
  7.  
  8. This is the DJGPP Frequently-Asked Questions List.
  9.  
  10. Copyright (C) 1994, 1995, 1996, 1997 Eli Zaretskii
  11.  
  12. This is the second edition of the FAQ list,
  13. and is consistent with version 2.01 of DJGPP.
  14.  
  15. This FAQ list may be freely distributed with the DJGPP package or any part
  16. thereof, provided this copyright notice is left intact on all copies.
  17.  
  18. 
  19. File: djgppfaq.info,  Node: Top,  Next: Urgent,  Prev: (dir),  Up: (dir)
  20.  
  21. DJGPP FAQ List
  22. **************
  23.  
  24.   In DJGPP (*note DJGPP overview: DJGPP.), a 32-bit compiler and programming
  25. environment, originally written for Unix machines, meet a 16-bit MS-DOS
  26. operating system.  Programmers who work in this environment have to master a
  27. large body of knowledge from both Unix and MS-DOS, especially if they want to
  28. use some advanced features, like interrupt handling, directly accessing
  29. peripheral devices, etc.
  30.  
  31.   But because the DJGPP project is a product of a group of volunteers, there
  32. isn't always enough time (or patience, or money ;-) to produce documentation
  33. which will describe all the subtle features and pitfalls a user should know
  34. about.  The documentation of DJGPP-specific utilities and issues is therefore
  35. minimal, leaving wide space for confusion, in newcomers and veterans alike,
  36. and making the DJGPP learning curve quite a steep one.
  37.  
  38.   This FAQ list is an attempt to take the sting out of that learning curve, by
  39. supplying solutions for problems which are known to puzzle DJGPP users.
  40. (Another solution would be to pay to DJ Delorie and other people who
  41. developed DJGPP to produce more documentation ;-).
  42.  
  43.   This is Edition 2.10 of the FAQ, last updated 17 January 1997, for DJGPP
  44. Version 2.01.
  45.  
  46.   Another place to look for DJGPP documentation is the DJGPP Knowledge Base, at
  47. this URL:
  48.  
  49.      http://www.delorie.com/djgpp/doc/kb/
  50.  
  51.   Brennan Underwood <brennan@mack.rt66.com> maintains a home page which is
  52. another valuable source for information about DJGPP, at this URL:
  53.  
  54.      http://brennan.home.ml.org/djgpp
  55.  
  56.   You can browse the HTML version of this FAQ list on line at the DJ Delorie's
  57. Web server, at this URL:
  58.  
  59.      http://www.delorie.com/djgpp/v2faq/faq.html
  60.  
  61.   If you browse this FAQ at DJ Delorie's server now, you can get the source
  62. distribution of the FAQ right here, at this URL:
  63.  
  64.      http://www.delorie.com/djgpp/v2faq/faq210s.zip
  65.  
  66. Also available from the DJ's server: FAQ in all the supported formats, at
  67. this URL:
  68.  
  69.      http://www.delorie.com/djgpp/v2faq/faq210b.zip
  70.  
  71.   A previous version of this FAQ was translated into French, e.g.
  72. ftp://ftp.delorie.com/pub/djgpp/v2faq/frfaq.zip, also available through the
  73. WWW, at this URL:
  74.  
  75.      http://www.delorie.com/djgpp/v2faq/frfaq.zip
  76.  
  77.   The following master menu lists the major topics in this FAQ list, including
  78. all the indices.
  79.  
  80. * Menu:
  81.  
  82. * Urgent::                If you are in a hurry.
  83. * DJGPP::                 What is DJGPP?
  84. * Requirements::          Hardware and software requirements for DJGPP.
  85. * Getting DJGPP::         Where and what to download?
  86. * Docs::                  Where the documentation is and how to read it.
  87. * Trouble::               When the compiler (or Make, or Info, or ...) crashes
  88. * Compiler performance::  How fast is the compiler?
  89. * Compiling::             Compile-time and link-time problems.
  90. * Running::               Running compiled programs.
  91. * Graphics::              Graphics under DJGPP.
  92. * Floating point::        Floating-point programs and FP emulation.
  93. * Debugging::             Debugging DJGPP programs.
  94. * Profiling::             Optimizing your programs.
  95. * Performance::           Run-time performance of DJGPP programs.
  96. * Memory::                Run-time memory issues.
  97. * Command line::          Command-line arguments handling in DJGPP.
  98. * Converting::            How to convert DOS code to DJGPP?
  99. * Low-level::             Low-level and hardware-oriented programming.
  100. * Legalese::              Legal aspects of programming with DJGPP.
  101. * Help::                  How to get more help.
  102. * v2::                    New in DJGPP Version 2.0.
  103. * Miscellany::            More...
  104. * About::                 Contributors to this FAQ.
  105. * Topic Index::           Search here by a problem description.
  106. * Program Index::         Search here by a program name.
  107.  
  108. 
  109. File: djgppfaq.info,  Node: Urgent,  Next: DJGPP,  Prev: Top,  Up: Top
  110.  
  111. 1. If You Are In a Hurry
  112. ************************
  113.  
  114. **Q*: Do you really mean I have to read this looongish FAQ list to get my
  115. answers?*
  116.  
  117. **Q*: I have this problem which I absolutely MUST solve NOW!  What do I do?*
  118.  
  119. *A* : No, you don't need to read *all* of the FAQ unless you want to
  120. (although this is by all means recommended).  The questions in this document
  121. are listed, as much as possible, in the order they appear when one goes
  122. through getting DJGPP, installing it and using it.  To quickly find an answer
  123. to your question, first look at the *Note Table of Contents: Top.  If that
  124. doesn't help, try the indices at the end of this manual.  You can either look
  125. up your question *Note by program name: Program Index, or *Note by topic
  126. name: Topic Index.  If you don't find anything appropriate, search this FAQ
  127. for words which are pertinent to your problem.  For those in a *real* hurry,
  128. here are some pointers to the most important topics in this FAQ list:
  129.  
  130.    * How to ask experienced DJGPP users for help?
  131.  
  132.      Use the DJGPP News group or mailing list.  For most questions, you will
  133.      have your answer in a day or two.  *Note the details on how to ask the
  134.      gurus: Totally lost.
  135.  
  136.    * What is the best configuration of my system for DJGPP?
  137.  
  138.      This depends on your hardware and software.  *Note system configuration
  139.      guidelines: Config.
  140.  
  141.    * Some files I need seem to be missing.  Where do I find them?
  142.  
  143.      Check out the *Note list of required and optional packages: What to
  144.      download.
  145.  
  146.    * How do I subscribe to or unsubscribe from the DJGPP mailing list?
  147.  
  148.      *Note subscription instructions: Subscribing.
  149.  
  150.    * How can I search News group/mailing list traffic for some info?
  151.  
  152.      This FAQ includes the *Note description of DJGPP archive search server:
  153.      Deja vu, set up by DJ Delorie <dj@delorie.com>, which you should use
  154.      whenever you have any questions or look for an information on a
  155.      DJGPP-related subject.
  156.  
  157. 
  158. File: djgppfaq.info,  Node: DJGPP,  Next: Requirements,  Prev: Urgent,  Up: Top
  159.  
  160. 2. What is DJGPP?
  161. *****************
  162.  
  163. **Q*: What is DJGPP?*
  164.  
  165. *A* :  DJGPP is a port of GNU C/C++ compiler and development tools to 32-bit,
  166. protected-mode environment on Intel 32-bit CPUs running MS-DOS and compatible
  167. operating systems, by DJ Delorie <dj@delorie.com> and friends.  Starting from
  168. v2.0, DJGPP programs do not need a separate extender program, only a DPMI
  169. server to run; DJGPP includes a free 32-bit DPMI server which allows for a
  170. 32-bit, 4 GByte flat address space and up to 256 MBytes of virtual memory, a
  171. compiler which produces 32-bit protected-mode code, and a suite of GNU
  172. development tools ported to MS-DOS.  These provide for a development
  173. environment which specifically favors porting Unix programs, but is also
  174. suitable for writing new code (for example, the DOS version of the well-known
  175. game `Quake' by id Software was compiled with DJGPP).  With a few exceptions
  176. (notably, some of the C++ class libraries), DJGPP is *free* which makes it
  177. deal for developing free and commercial software alike.
  178.  
  179. DJ Delorie <dj@delorie.com> is the developer and principal maintainer of
  180. DJGPP, but anyone is welcome and encouraged to contribute.
  181.  
  182. 
  183. File: djgppfaq.info,  Node: Requirements,  Next: Getting DJGPP,  Prev: DJGPP,  Up: Top
  184.  
  185. 3.  Hardware and Software Requirements
  186. **************************************
  187.  
  188.   This chapter describes what are the hardware and software which will allow
  189. you to use DJGPP.  Minimum, "reasonable" and optimal system configurations
  190. are listed.
  191.  
  192. * Menu:
  193.  
  194. * Minimum::             You cannot run DJGPP unless you have this.
  195. * OS/2::                But it crashes under OS/2!
  196. * Windows/NT::          Is it compatible with Win/NT?
  197. * DOSEmu::              Can I run it on Linux?
  198. * i286::                Why not?
  199. * Windows apps::        Can I write Windows applications with DJGPP?
  200. * Optimal hardware::    Here is your dream machine description.
  201. * Reasonable hardware:: For the rest of us.
  202. * Config::              How to configure your system software for DJGPP.
  203.  
  204. 
  205. File: djgppfaq.info,  Node: Minimum,  Next: OS/2,  Prev: Requirements,  Up: Requirements
  206.  
  207. 3.1 The minimum system requirements for using DJGPP
  208. ===================================================
  209.  
  210. **Q*: What are the minimum system requirements for using DJGPP?*
  211.  
  212. **Q*: Will DJGPP run on my brand-new Acme i986DX7/300 PC with a SCSI-III
  213. 10-Terabyte disk drive under MulticOS/42 v7.99 operating system?*
  214.  
  215. *A* :  DJGPP requires at least 386SX CPU and between 15 and 35 MB of free
  216. disk space (*note more details on this below: Disk space.), including space
  217. for the software installation and some swap space.  A minimum of 64K of
  218. system memory is enough for DJGPP to run with the CWSDPMI free DPMI host
  219. (most other DPMI hosts will require much more), but at least 2.5MB of free
  220. extended RAM is recommended for reasonably fast compilation of large source
  221. files (4MB for compiling large C++ programs); you might see painfully slow
  222. compiles for large sources if you don't have at least that much.  If your
  223. machine doesn't have a numeric co-processor, you will need to install an
  224. emulator to run floating-point code (DJGPP provides such an emulator) or link
  225. your applications with a special emulator library (also provided with DJGPP).
  226.  
  227. DJGPP will run under native DOS; any other operating system is OK if it
  228. includes a DPMI server.  Environments known to run DJGPP besides native DOS:
  229. Windows 3.1 & 3.11 DOS box, OS/2 (including Warp) DOS box, Windows 95/DOS 7,
  230. Windows NT (on Intel CPUs), Novell NWDOS 7 and Caldera's OpenDOS (but several
  231. people have found the DPMI services of NWDOS and OpendDOS incompatible with
  232. DJGPP, so they should probably be turned off and CWSDPMI used instead), and
  233. Linux DOSEmu environment.
  234.  
  235. 
  236. File: djgppfaq.info,  Node: OS/2,  Next: Windows/NT,  Prev: Minimum,  Up: Requirements
  237.  
  238. 3.2 Does it really work under OS/2?
  239. ===================================
  240.  
  241. **Q*: You tell me it will work under OS/2, but I'm experiencing strange
  242. crashes after several compilations ...*
  243.  
  244. **Q*: DJGPP Make crashes when I run it on OS/2!*
  245.  
  246. *A* :  There was a bug in the DPMI server of the old OS/2 versions, which was
  247. triggered by spawning child processes (like GCC does when it invokes the
  248. various compiler passes).  Current versions of OS/2 don't have that bug, so
  249. DJGPP programs should run fine under OS/2.  If you can't make this happen,
  250. chances are that your setup is incorrect.  One system parameter that can
  251. cause problems with DJGPP (reportedly, Make crashes if it isn't set
  252. correctly) is `DPMI_DOS_API.'  Setting it to `ENABLED' instead of the default
  253. `AUTO' should solve the problem.  I'm also told that experimenting with the
  254. value of `DPMI_MEMORY_LIMIT' sometimes solves problems on OS/2.
  255.  
  256. If the above doesn't help, please post the details of the crashes you see to
  257. the DJGPP News group (*note description of the DJGPP news group: Newsgroup.)
  258. or mailing list (*note how to post to the mailing list: Mailing list.), and
  259. somebody will help you.
  260.  
  261. 
  262. File: djgppfaq.info,  Node: Windows/NT,  Next: DOSEmu,  Prev: OS/2,  Up: Requirements
  263.  
  264. 3.3 Will it work under Windows/NT?
  265. ==================================
  266.  
  267. **Q*: What about Windows NT?*
  268.  
  269. *A* :  Current Windows NT versions support DPMI programs in the DOS box, so
  270. DJGPP programs should in general run fine under NT (but see the list of
  271. possible problems below).  Therefore, beginning with DJGPP v2.0, the
  272. distribution doesn't include real-mode `gcc.exe' anymore, as it is not needed.
  273.  
  274. The DPMI server built into NT (and Windows 95) loses selectors with each
  275. child program that is invoked by a DJGPP program, so after about two thousand
  276. calls to functions from the `spawnXX' family you can see an error message
  277. like this:
  278.  
  279.        Load error: no DPMI selectors
  280.  
  281. This problem is likely to afflict only DJGPP ports of Unix shells (such as
  282. `bash'), since no other DJGPP program, not even `Make', is likely to call so
  283. many child programs before it exits.  The only known work-around is to exit
  284. the shell every now and then, because when all the available selectors are
  285. exhausted, the DOS box will crash.  I'm told that `Make' was seen crashing on
  286. long `Makefiles' on Windows 95, where the selectors are lost at even higher
  287. rate than on NT.  If you ever run a very long `Makefile' and see `Make' crash,
  288. just run `Make' again, and it will pick up where the crashed session has left
  289. off.
  290.  
  291. Note that the long filename API (the special LFN-aware functions of Int 21h)
  292. for DOS box is not supported by current versions of Win/NT, so you cannot
  293. have long filenames there from DJGPP programs.
  294.  
  295. You might have problems with using the SVGA modes of your video card under
  296. Win/NT.  That is because NT doesn't allow direct access to the SVGA
  297. registers, without which it is impossible to recognize the type of the SVGA
  298. and employ its capabilities.  For example, a user reported that GRX functions
  299. and the `MODETEST.EXE' program thought that only a standard VGA was
  300. installed, whereas he had an S3 card.  There is nothing you can do about this
  301. feature of Win/NT; that is the price you pay for the stability and protection
  302. you get under this OS (a runaway program that accesses hardware registers can
  303. wipe out your disk or wedge the entire system cold).  However, I'm told that
  304. Win/NT 4.0 supports "DirectX" which is a method of accessing screen, audio
  305. and other peripherals directly, so it's possible to use full GRX graphics
  306. capabilities there.
  307.  
  308. Programs that use the "nearptr" facility of DJGPP to access absolute memory
  309. addresses (e.g., for memory-mapped devices) won't work on NT, because its
  310. DPMI server silently ignores functions that set huge limits on selectors.
  311. Since the default algorithm which allocates memory from the DPMI server needs
  312. to set such huge limit in some rare cases, there's a small probability that a
  313. program will fail or crash even if it doesn't set selector limits in user
  314. code.  It is best to use the Unix-style `sbrk' algorithm in programs that run
  315. on Windows/NT.  See the library docs for `_crt0_startup_flags' where the
  316. `_CRT0_FLAG_UNIX_SBRK' bit is explained, for more info on this issue.  If you
  317. cannot switch to the Unixy `sbrk' (e.g., if you don't have access to its
  318. source), I'm told that sometimes such problems can be worked around if you
  319. run DJGPP programs in a full-screen session; your mileage may vary.
  320.  
  321. Some people report that NT servers cause much more problems than NT
  322. workstations of the same version and build.  It seems that these problems
  323. usually mean that NT installation was done incorrectly (maybe it is much
  324. harder to get it right with a server than with a workstation?).  If you have
  325. such problems, try to install a workstation, or re-install the server, and
  326. see if that helps.  And if you gain some insight as to why servers like DJGPP
  327. less than workstations, please tell what you've learned.
  328.  
  329. The Cygnus Win32 project is another (unrelated to DJGPP) port of GCC and
  330. development tools to WinNT and Win95 platforms, which specifically targets
  331. development of Windows programs.  It is available from the Cygnus archives,
  332. e.g. ftp://ftp.cygnus.com/pub/sac/win32/ or through the Web, at this URL:
  333.  
  334.      http://www.cygnus.com/misc/gnu-win32/
  335.  
  336. 
  337. File: djgppfaq.info,  Node: DOSEmu,  Next: i286,  Prev: Windows/NT,  Up: Requirements
  338.  
  339. 3.4 Can it run under Linux?
  340. ===========================
  341.  
  342. **Q*: You say it works on Linux, but I seem to be unable to run the compiler
  343. from within Make...*
  344.  
  345. **Q*: I can run DJGPP on Linux, but Make crashes with SIGFPE on even the
  346. simplest Makefiles!*
  347.  
  348. *A* :  Versions of Linux which were released before 13 March 1996 need a
  349. patch to be able to reliably run nested DJGPP programs.  That patch was
  350. posted to the DJGPP mailing list and is available from the DJGPP mail
  351. archives, at this URL:
  352.  
  353.      http://www.delorie.com/djgpp/mail-archives/djgpp/1996/02/26/13:28:52
  354.  
  355. If you prefer to download that patch via ftp, you can find it on the DJGPP
  356. ftp server, e.g.
  357. ftp://ftp.delorie.com/pub/djgpp/contrib/dpmi-dosemu-djgpp.mail.
  358.  
  359. You might also need to edit the RAM section of the `dosemu.conf' file to make
  360. it comfortable for DJGPP.  I suggest setting `dpmi' and `xms' to 16MB and
  361. `ems' to 4MB.
  362.  
  363. Some users reported that `Make', and possibly other programs which use
  364. floating point computations, crash in DOSEmu environment on systems without
  365. an FPU, even if you set the 387 and EMU387 environment variables correctly
  366. (as explained in *Note Setting up the FP emulator: Emulation, below).  The
  367. only known work-around is to not use floating point or to upgrade your
  368. machine hardware.  It is possible that newer versions of Linux might solve
  369. this problem too, so try upgrading your Linux software.
  370.  
  371. If your only problem is to run GNU Make, get the latest DJGPP port of Make,
  372. since ports of Make 3.75 or later can be configured to not issue FP
  373. instructions at all.
  374.  
  375. 
  376. File: djgppfaq.info,  Node: i286,  Next: Windows apps,  Prev: DOSEmu,  Up: Requirements
  377.  
  378. 3.5 Can I run it on a 286?
  379. ==========================
  380.  
  381. **Q*: Why can't I run DJGPP on my 286?  It has protected mode also...*
  382.  
  383. *A* :  True, but the protected mode isn't an issue here.  Gcc doesn't care
  384. much about memory protection, but it does care to run on a 32-bit processor,
  385. which the 286 isn't.  A 386 or better CPU really *is* required.
  386.  
  387. 
  388. File: djgppfaq.info,  Node: Windows apps,  Next: Optimal hardware,  Prev: i286,  Up: Requirements
  389.  
  390. 3.6 MS-Windows applications and DJGPP
  391. =====================================
  392.  
  393. **Q*: Can I write MS-Windows applications with DJGPP?*
  394.  
  395. *A* : Currently, you can only run DJGPP programs under Windows as DOS apps
  396. (i.e. inside DOS Box).  If you need to write true Windows apps, you will have
  397. to use auxiliary tools.  One possibility is to use the RSX extender with EMX
  398. port of GCC and RSXWDK kit for Windows.  You can get RSX by anonymous ftp,
  399. e.g. ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc/.  People who tried
  400. using this package with DJGPP report that you must download and unzip the
  401. RSXWDK2 source archive, not only the binaries (otherwise you'll get General
  402. Protection Faults when you try to run DJGPP programs).  If you cannot reach
  403. the above site (some people say that it has closed its anonymous access), try
  404. looking on an alternative site, e.g.
  405. ftp://hermes.hrz.uni-bielefeld.de/pub/systems/msdos/misc/.  Other locations
  406. to look are RSXWDK on Cica mirrors, e.g.
  407. ftp://ftp.winsite.com/pub/pc/win3/programr/rsxwdk2s.zip, or RSXWDK on any of
  408. the TeX Archive Network sites, e.g.
  409. ftp://ftp.shsu.edu/tex-archive/systems/msdos/dpmigcc/.
  410.  
  411. Another problem with RSXWDK is that the Makefiles there are written for
  412. `ndmake', so they should be rewritten for GNU Make to work.  Some more
  413. hacking of Makefiles might be required due to the fact that they are set to
  414. work with EMX, and assume you unpacked everything into `/rsxwdk.'  You will
  415. also have to recompile the libraries as they were compiled with DJGPP v1.x,
  416. and hack the v2 startup file `crt0.s' along the same lines as the v1 version
  417. which comes with RSXWDK.  (`crt0.s' comes with the DJGPP source distribution,
  418. `djlsr201.zip'.)
  419.  
  420. Apart from RSXWDK, you will need a `windows.h' header file.  One place to
  421. find it is with the WINE distribution, e.g.
  422. ftp://ftp.cdrom.com/pub/FreeBSD/distfiles/ (you'll have to add -DWINELIB to
  423. CFLAGS when compiling).  However, be warned that this is a complete rewrite
  424. of the original, and might produce error messages when used to compile
  425. Windows apps.  I don't know about a better solution except using `windows.h'
  426. from a commercial compiler, which might get you into legal trouble.
  427.  
  428. You will also need a help compiler, e.g.
  429. ftp://ftp.aiai.ed.ac.uk/pub/packages/tex2rtf/rtfutils/hcp505.zip, or try at
  430. the Microsoft ftp site, e.g.
  431. ftp://ftp.microsoft.com/Softlib/MSFILES/HC305.EXE.  I'm told that, legally,
  432. you must already have purchased a help compiler from Microsoft to use either
  433. one of these.
  434.  
  435. A resource compiler is also required.  RSXNT (below) includes one such, but I
  436. didn't yet hear any success stories using it.  Anybody?
  437.  
  438. Note that, according RSXWDK's author, that package is meant for those who
  439. already have working debugged Windows applications and are simply looking to
  440. port them to 32-bit code.  Therefore, some crucial parts of a development
  441. environment (like a debugger) are missing there.  The author of RSX has
  442. recently discontinued his support of the package and switched to RSXNT
  443. project that targets Win32 (Win9x and WinNT) platforms (below).
  444.  
  445. As of this writing, nobody has reported any first-hand experience of using
  446. RSXWDK with DJGPP v2; the above is based on user reports under v1.x.  If you
  447. try RSXWDK with v2.x, please post a summary of your experience.
  448.  
  449. There is also a newer Windows development tool-chain by the author of RSXWDK
  450. called RSXNT.  This is targeted for Win32 platforms (Win95 and WinNT); it
  451. does have debugging tools included and has better support for DJGPP v2.x, but
  452. it needs to be registered (for a fee) if you want to develop commercial or
  453. shareware applications with it.  It can be found on the same sites as RSXWDK
  454. and comes with header files from Cygnus.  You can find the DJGPP-specific
  455. version of RSXNT on SimTel mirrors, e.g.
  456. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/rsxntdj1.zip.  The sources
  457. of all the RSXNT utilities can be found in `rsxnt1.zip' archive on Cica
  458. mirrors, in the `win95/programr/' directory.  Note that currently, due to
  459. limitations of DJGPP, you cannot produce DLLs or programs that will run on
  460. Win32s platforms with RSXNT.
  461.  
  462. Another way to develop Windows applications is to use the Cygnus GCC/GPP
  463. port, at this URL:
  464.  
  465.      http://www.cygnus.com/gnu-win32/
  466.  
  467. You can also download it via anonymous ftp, e.g.
  468. ftp://ftp.cygnus.com/pub/sac/win32/.  This one's compatible with Win32 (Win95
  469. or WinNT, not Win32s), but requires you to comply with the GNU Copyleft
  470. system.  The Cygnus distribution includes development environments which run
  471. on WinNT and Linux, targeting WinNT and Win95 platforms.  Note that, as of
  472. this writing, the Cygnus port is still in early beta phase, and some nasty
  473. bugs are bound to be there.  Contact Steve Chamberlain <sac@rtl.cygnus.com>,
  474. for more details.
  475.  
  476. A better (but harder) way would be to volunteer to add Windows support to
  477. DJGPP.
  478.  
  479. 
  480. File: djgppfaq.info,  Node: Optimal hardware,  Next: Reasonable hardware,  Prev: Windows apps,  Up: Requirements
  481.  
  482. 3.7 What you *should* buy ...
  483. =============================
  484.  
  485. **Q*: What is the optimal system configuration for running DJGPP?*
  486.  
  487. *A* :  Here is the description of your dream machine (at least for the next 6
  488. months :-):
  489.  
  490.    * Hardware:
  491.  
  492.         - the fastest CPU you can find (a 200 MHz Pentium-Pro as of this
  493.           writing);
  494.  
  495.         - at least 512KB second-level (off-chip) cache memory;
  496.  
  497.         - 128 MByte RAM;
  498.  
  499.         - motherboard built around fast 32-bit-wide bus (VLB or PCI);
  500.  
  501.         - SCSI-II hard disk with bus-mastering controller;
  502.  
  503.    * Software:
  504.  
  505.         - DOS, device drivers and TSRs all loaded HIGH, leaving only 5K DOS
  506.           footprint in lower (under 640K) memory;
  507.  
  508.         - 8 MByte RAM disk installed, `TMPDIR' environment variable points to
  509.           it (e.g., `set TMPDIR=e:', if E: is the RAM drive letter);
  510.  
  511.         - 8 MByte of disk cache, set to delayed-write operation;
  512.  
  513. 
  514. File: djgppfaq.info,  Node: Reasonable hardware,  Next: Config,  Prev: Optimal hardware,  Up: Requirements
  515.  
  516. 3.8 What most of us will *actually* buy ...
  517. ===========================================
  518.  
  519. **Q*: OK, I don't have this much money.  What is the *reasonable*
  520. configuration?*
  521.  
  522. *A* :  If you have the following machine, you should be able to stop worrying
  523. about memory and compilation performance:
  524.  
  525.    - CPU: 486DX2-66 with 256 KB off-chip cache;
  526.  
  527.    - RAM: 16 MByte;
  528.  
  529.    - Disk: 12 ms IDE with VLB controller, or SCSI;
  530.  
  531.    - 4 MByte RAM disk;
  532.  
  533.    - 3 MByte disk cache;
  534.  
  535. This will leave you with about 8 MBytes of free extended RAM.  Note that the
  536. RAM disk must be 4 MBytes to hold the output of the preprocessor for some
  537. exceedingly large source files (notably, some GCC source files).  If you
  538. don't have that much RAM to spare and still want to compile *very* large
  539. source files, either reduce the disk cache so you can give more to RAM disk,
  540. or point `TMPDIR' to your hard disk and make the disk cache larger, if you
  541. can.
  542.  
  543. 
  544. File: djgppfaq.info,  Node: Config,  Prev: Reasonable hardware,  Up: Requirements
  545.  
  546. 3.9 How to configure your system for DJGPP?
  547. ===========================================
  548.  
  549. **Q*: How do I configure my system to get optimal performance under DJGPP?*
  550.  
  551. *A* :  That depends on the amount of RAM you have installed in your machine.
  552. Below are some guidelines to help you.
  553.  
  554.   a. If you have 2 MBytes or less RAM installed:
  555.  
  556.         * Don't use *any* memory manager.
  557.  
  558.         * Use of `CWSDPMI' as your DPMI host is highly recommended.
  559.  
  560.         * Remove any TSR and device drivers you don't absolutely need (like
  561.           `SETVER.EXE', `HIMEM.SYS' etc.) from your `CONFIG.SYS' and
  562.           `AUTOEXEC.BAT.'
  563.  
  564.         * Do *not* install disk cache or RAM disk; point your `TMPDIR'
  565.           environment variable to a directory on your hard disk.  Put a
  566.           sufficiently large `BUFFERS=' statement into your `CONFIG.SYS' (I
  567.           recommend setting `BUFFERS=40,8') to make DOS file operations
  568.           faster.
  569.  
  570.         * If you use `CWSDPMI' as your DPMI host, get the `CWSPARAM' program
  571.           (from the `csdpmi3b.zip' archive) and set the "Minimum application
  572.           memory desired before 640K paging" parameter to 512K or larger.
  573.           Depending on how much memory you actually have, you might need to
  574.           further fine-tune this parameter.  This parameter defines the
  575.           lowest amount of extended memory CWSDPMI will use; if your system
  576.           doesn't have that much free extended RAM, CWSDPMI will use
  577.           conventional memory instead, where usually there should be around
  578.           600K of free RAM.
  579.  
  580.         * If you run under Windows, be sure to set the maximum amount of
  581.           extended memory on your PIF file for the DOS box to a reasonable
  582.           value.
  583.  
  584.      With this configuration, GCC will run out of free physical RAM and start
  585.      paging when compiling almost any C program and all C++ programs.  If you
  586.      are serious about DJGPP development, you need to buy more RAM *urgently*.
  587.  
  588.   b. If you have 2-4 MBytes of RAM installed:
  589.  
  590.         * Don't use *any* memory manager.
  591.  
  592.         * Remove any TSR and device driver you don't absolutely need (like
  593.           `SETVER.EXE', `HIMEM.SYS') from your `CONFIG.SYS' and
  594.           `AUTOEXEC.BAT.'
  595.  
  596.         * Get a disk cache which works from conventional memory and configure
  597.           it to 256K size at most, or don't use a cache at all.
  598.  
  599.         * Do *not* install a RAM disk; point your `TMPDIR' environment
  600.           variable to a directory on your hard disk.
  601.  
  602.         * If you run under Windows, be sure to set the maximum amount of
  603.           extended memory on your PIF file for the DOS box to a reasonable
  604.           value.
  605.  
  606.      With this configuration, GCC will still run out of free physical RAM and
  607.      start paging when compiling large C programs and most C++ programs.
  608.      Plan to buy more RAM as soon as you can.
  609.  
  610.   c. If you have 5-8 MBytes of RAM installed:
  611.  
  612.         * Use a memory manager such as EMM386 or QEMM386.  Try using the
  613.           FRAME=NONE parameter of the memory manager.  This will disable
  614.           Expanded Memory (EMS) services as far as most programs are
  615.           concerned; if you must use DJGPP together with any program which
  616.           needs EMS, try to configure that program to use Extended Memory
  617.           (XMS) instead.
  618.  
  619.         * Load DOS, device drivers and TSRs *HIGH*.
  620.  
  621.         * Give your disk cache 1 MByte of RAM.  Enable its delayed-write (aka
  622.           write-back) feature.
  623.  
  624.         * Do *not* install a RAM disk; point your `TMPDIR' environment
  625.           variable to a directory on your hard disk.
  626.  
  627.         * If, after configuring your system as above, you still have more
  628.           than 2.5 MBytes of free RAM left (4 MBytes, if you plan to program
  629.           in C++ a lot), enlarge the disk cache size.
  630.  
  631.         * If you run under Windows, be sure to set the maximum amount of
  632.           extended memory on your PIF file for the DOS box to a reasonable
  633.           value.
  634.  
  635.   d. If you have more than 8 MBytes of RAM:
  636.  
  637.         * Use a memory manager to load DOS, TSRs and device drivers *HIGH*.
  638.  
  639.         * Install at least a 2-MByte-large disk cache, configured to use the
  640.           delayed- write feature.  If you have plenty of RAM, you can give
  641.           your cache as much as 8 MBytes of memory.
  642.  
  643.         * If you have more than 5 MBytes left, install a RAM disk with a size
  644.           of at least 1.5 MBytes and point your `TMPDIR' environment variable
  645.           to it.  If your RAM disk is less than 4 MBytes, GCC might run out
  646.           of space there for *very* large source files (e.g., cccp.c file
  647.           from the GCC source distribution), but this shouldn't happen unless
  648.           the size of the source file you are compiling approaches 1 MByte.
  649.  
  650. Some people disable the delayed-write feature for safety reasons, to avoid
  651. losing files due to system crashes.  If you are worried about this, you can
  652. usually gain performance without sacrificing safety by enabling delayed-write
  653. together with an option that causes the cache to flush the write-behind data
  654. before the system returns to the DOS prompt.  For a `SmartDrv' disk cache,
  655. this is achieved by specifying `/N/F' switches instead of `/X'.
  656.  
  657. A tutorial is available on how to set up and get started with DJGPP, at this
  658. URL:
  659.  
  660.      http://remus.rutgers.edu/~avly/djgpp.html
  661.  
  662. 
  663. File: djgppfaq.info,  Node: Getting DJGPP,  Next: Docs,  Prev: Requirements,  Up: Top
  664.  
  665. 4. Where and What to Download?
  666. ******************************
  667.  
  668.   This chapter explains where and how can you get DJGPP, and recommends which
  669. parts of the archive you should download.
  670.  
  671. * Menu:
  672.  
  673. * Where to find::             Pick up from your nearest SimTel mirror.
  674. * CCT::                       Or look on one of the CCT mirrors.
  675. * How to download::           Anonymous FTP, of course!
  676. * DJGPP by WWW::              For those who use Netscape/Mosaic only.
  677. * What to download::          Look here to decide what packages you need.
  678. * Disk space::                How much disk storage do you need?
  679. * DJGPP = Fatware::           Can I do with less MBytes?
  680.  
  681. 
  682. File: djgppfaq.info,  Node: Where to find,  Next: CCT,  Prev: Getting DJGPP,  Up: Getting DJGPP
  683.  
  684. 4.1 Where can I get DJGPP?
  685. ==========================
  686.  
  687. **Q*: Where can I get DJGPP?*
  688.  
  689. *A* : Look on any SimTel.NET mirror in the pub/simtelnet/gnu/djgpp/
  690. subdirectory.
  691.  
  692. Lately, there has been considerable confusion caused by the fact that the
  693. repository which was long known by the name "SimTel" is no longer called
  694. that; its new name is "CCT".  The name SimTel has moved (along with its
  695. originator and long-time manager, Keith Petersen <w8sdz@Simtel.Net>) to
  696. another distribution network which uses almost the same ftp sites, but in
  697. different subdirectories.  The name SimTel is copyrighted by this new
  698. distribution network, and so CCT will have to discontinue its use of that
  699. name.  Experience shows that SimTel.NET (not CCT) is better managed and
  700. updates propagate there much faster, so I advise you to try using SimTel
  701. mirrors first, and fall back to CCT only if a SimTel site is unavailable to
  702. you.  In particular, DJGPP version 2.01 and later wasn't even uploaded to CCT
  703. sites.
  704.  
  705. This section lists the SimTel.NET mirrors; see *Note below: CCT, for the list
  706. of CCT sites.
  707.  
  708. The primary SimTel.NET site is:
  709.      ftp.simtel.net, directory /pub/simtelnet/gnu/djgpp
  710.  
  711.      (1) (*note Where to find-Footnotes::)
  712.  
  713. Here is a list of hosts by countries that offer mirror sites:
  714. Argentina
  715.      ftp.satlink.com, directory /pub/mirrors/simtelnet/gnu/djgpp
  716.  
  717. Newcastle, Australia:
  718.      ftp.iniaccess.net.au, directory /pub/simtelnet/gnu/djgpp
  719.  
  720. Australia:
  721.      ftp.tas.gov.au, directory /pub/simtelnet/gnu/djgpp
  722.  
  723. Australia:
  724.      sunsite.anu.edu.au, directory /pub/simtelnet/gnu/djgpp
  725.  
  726. Vienna, Austria:
  727.      ftp.univie.ac.at, directory /mirror/simtelnet/gnu/djgpp
  728.  
  729. Brussels, Belgium:
  730.      ftp.linkline.be, directory /mirror/simtelnet/gnu/djgpp
  731.  
  732. Aarshot, Belgium:
  733.      ftp.tornado.be, directory /pub/simtelnet/gnu/djgpp
  734.  
  735. Sao Paulo, Brazil:
  736.      ftp.unicamp.br, directory /pub/simtelnet/gnu/djgpp
  737.  
  738. Brazil:
  739.      ftp.iis.com.br, directory /pub/simtelnet/gnu/djgpp
  740.  
  741. Bulgaria:
  742.      ftp.eunet.bg, directory /pub/simtelnet/gnu/djgpp
  743.  
  744. Ottawa, Canada:
  745.      ftp.crc.doc.ca, directory /systems/ibmpc/simtelnet/gnu/djgpp
  746.  
  747. Vancouver, Canada:
  748.      ftp.direct.ca, directory /pub/simtelnet/gnu/djgpp
  749.  
  750. Chile:
  751.      sunsite.dcc.uchile.cl, directory /pub/Mirror/simtelnet/gnu/djgpp
  752.  
  753. Beijing, China:
  754.      ftp.pku.edu.cn, directory /pub/simtelnet/gnu/djgpp
  755.  
  756. Czech Republic:
  757.      ftp.eunet.cz, directory /pub/simtelnet/gnu/djgpp
  758.  
  759. Prague, Czech Republic:
  760.      pub.vse.cz, directory /pub/simtelnet/gnu/djgpp
  761.  
  762. Czech Republic:
  763.      ftp.zcu.cz, directory /pub/simtelnet/gnu/djgpp
  764.  
  765. Espoo, Finland:
  766.      ftp.funet.fi, directory /mirrors/ftp.simtel.net/pub/simtelnet/gnu/djgpp
  767.  
  768. Neuilly, France:
  769.      ftp.grolier.fr, directory /pub/simtelnet/gnu/djgpp
  770.  
  771. Paris, France:
  772.      ftp.ibp.fr, directory /pub/simtelnet/gnu/djgpp
  773.  
  774. Germany:
  775.      ftp.mpi-sb.mpg.de, directory /pub/simtelnet/gnu/djgpp
  776.  
  777. Bochum, Germany:
  778.      ftp.rz.ruhr-uni-bochum.de, directory /pub/simtelnet/gnu/djgpp
  779.  
  780. Chemnitz, Germany:
  781.      ftp.tu-chemnitz.de, directory /pub/simtelnet/gnu/djgpp
  782.  
  783. Heidelberg, Germany:
  784.      ftp.uni-heidelberg.de, directory /pub/simtelnet/gnu/djgpp
  785.  
  786. Magdeburg, Germany:
  787.      ftp.uni-magdeburg.de, directory /pub/simtelnet/gnu/djgpp
  788.  
  789. Paderborn, Germany:
  790.      ftp.uni-paderborn.de, directory /pub/simtelnet/gnu/djgpp
  791.  
  792. Trier, Germany:
  793.      ftp.uni-trier.de, directory /pub/pc/mirrors/simtelnet/gnu/djgpp
  794.  
  795. Wuerzburg, Germany:
  796.      ftp.rz.uni-wuerzburg.de, directory /pub/pc/simtelnet/gnu/djgpp
  797.  
  798. Athens, Greece:
  799.      ftp.ntua.gr, directory /pub/pc/simtelnet/gnu/djgpp
  800.  
  801. Hong Kong:
  802.      sunsite.ust.hk, directory /pub/simtelnet/gnu/djgpp
  803.  
  804. Hong Kong:
  805.      ftp.hkstar.com, directory /pub/simtelnet/gnu/djgpp
  806.  
  807. Hong Kong:
  808.      ftp.cs.cuhk.hk, directory /pub/simtelnet/gnu/djgpp
  809.  
  810. Ireland:
  811.      ftp.iol.ie, directory /pub/simtelnet/gnu/djgpp
  812.  
  813. Jerusalem, Israel:
  814.      ftp.huji.ac.il, directory /pub/simtelnet/gnu/djgpp
  815.  
  816. Naples, Italy:
  817.      ftp.unina.it, directory /pub/simtelnet/gnu/djgpp
  818.  
  819. Italy:
  820.      cis.utovrm.it, directory /simtelnet/gnu/djgpp
  821.  
  822. Italy:
  823.      ftp.flashnet.it, directory /pub/simtelnet/gnu/djgpp
  824.  
  825. Italy:
  826.      mcftp.mclink.it, directory /pub/simtelnet/gnu/djgpp
  827.  
  828. Saitama, Japan:
  829.      ftp.saitama-u.ac.jp, directory /pub/simtelnet/gnu/djgpp
  830.  
  831. Saitama, Japan:
  832.      ftp.riken.go.jp, directory /pub/simtelnet/gnu/djgpp
  833.  
  834. Japan:
  835.      ftp.iij.ad.jp, directory /pub/simtelnet/gnu/djgpp
  836.  
  837. Japan:
  838.      ftp.u-aizu.ac.jp, directory /pub/PC/simtelnet/gnu/djgpp
  839.  
  840. Japan:
  841.      ring.aist.go.jp, directory /pub/simtelnet/gnu/djgpp
  842.  
  843. Japan:
  844.      ring.asahi-net.or.jp, directory /pub/simtelnet/gnu/djgpp
  845.  
  846. Japan:
  847.      ftp.web.ad.jp, directory /pub/simtelnet/gnu/djgpp
  848.  
  849. Latvia:
  850.      ftp.lanet.lv, directory /pub/mirror/simtelnet/gnu/djgpp
  851.  
  852. Malaysia:
  853.      ftp.jaring.my, directory /pub/simtelnet/gnu/djgpp
  854.  
  855. Malaysia:
  856.      ftp.mimos.my, directory /pub/simtelnet/gnu/djgpp
  857.  
  858. Mexico:
  859.      ftp.gdl.iteso.mx, directory /pub/simtelnet/gnu/djgpp
  860.  
  861. Netherlands:
  862.      ftp.euro.net, directory /d5/simtelnet/gnu/djgpp/
  863.  
  864. Utrecht, Netherlands:
  865.      ftp.nic.surfnet.nl, directory
  866.      /mirror-archive/software/simtelnet/gnu/djgpp
  867.  
  868. Wellington, New Zealand:
  869.      ftp.vuw.ac.nz, directory /pub/simtelnet/gnu/djgpp
  870.  
  871. Bergen, Norway:
  872.      ftp.bitcon.no, directory /pub/simtelnet/gnu/djgpp
  873.  
  874. Krakow, Poland:
  875.      ftp.cyf-kr.edu.pl, directory /pub/mirror/Simtel.Net/gnu/djgpp
  876.  
  877. Poznan, Poland:
  878.      ftp.man.poznan.pl, directory /pub/simtelnet/gnu/djgpp
  879.  
  880. Warsaw, Poland:
  881.      ftp.icm.edu.pl, directory /pub/simtelnet/gnu/djgpp
  882.  
  883. Aveiro, Portugal:
  884.      ftp.ua.pt, directory /pub/simtelnet/gnu/djgpp
  885.  
  886. Portugal:
  887.      ftp.ip.pt, directory /pub/simtelnet/gnu/djgpp
  888.  
  889. Romania:
  890.      ftp.sorostm.ro, directory /pub/simtelnet/gnu/djgpp
  891.  
  892. Singapore:
  893.      ftp.nus.sg, directory /pub/simtelnet/gnu/djgpp
  894.  
  895. Slovakia:
  896.      ftp.uakom.sk, directory /pub/simtelnet/gnu/djgpp
  897.  
  898. Slovenia:
  899.      ftp.arnes.si, directory /software/simtelnet/gnu/djgpp
  900.  
  901. Johannesburg, South Africa:
  902.      ftp.is.co.za, directory /pub/simtelnet/gnu/djgpp
  903.  
  904. Stellenbosch, South Africa:
  905.      ftp.sun.ac.za, directory /pub/simtelnet/gnu/djgpp
  906.  
  907. Seoul, South Korea:
  908.      ftp.nuri.net, directory /pub/simtelnet/gnu/djgpp
  909.  
  910. South Korea:
  911.      ftp.sogang.ac.kr, directory /pub/simtelnet/gnu/djgpp
  912.  
  913. South Korea:
  914.      sunsite.snu.ac.kr, directory /pub/simtelnet/gnu/djgpp
  915.  
  916. Spain:
  917.      ftp.rediris.es, directory /mirror/simtelnet/gnu/djgpp
  918.  
  919. Stockholm, Sweden:
  920.      ftp.sunet.se, directory /pub/simtelnet/gnu/djgpp
  921.  
  922. Zurich, Switzerland:
  923.      sunsite.cnlab-switch.ch, directory /mirror/simtelnet/gnu/djgpp
  924.  
  925. Chung-Li, Taiwan:
  926.      ftp.ncu.edu.tw, directory /Packages/simtelnet/gnu/djgpp
  927.  
  928. Taipei, Taiwan:
  929.      nctuccca.edu.tw, directory /PC/simtelnet/gnu/djgpp
  930.  
  931. Nonthaburi, Thailand:
  932.      ftp.nectec.or.th, directory /pub/mirrors/simtelnet/gnu/djgpp
  933.  
  934. Edinburgh, UK:
  935.      emwac.ed.ac.uk, directory /mirror/simtelnet/gnu/djgpp
  936.  
  937. Lancaster, UK:
  938.      micros.hensa.ac.uk, directory /pub/simtelnet/gnu/djgpp
  939.  
  940. London, UK:
  941.      sunsite.doc.ic.ac.uk, directory /packages/simtelnet/gnu/djgpp
  942.  
  943. London, UK:
  944.      ftp.demon.co.uk, directory /pub/simtelnet/gnu/djgpp
  945.  
  946. Suffolk, UK:
  947.      ftp.flexnet.net, directory /pub/simtelnet/gnu/djgpp
  948.  
  949. Concord, California, USA:
  950.      ftp.cdrom.com, directory /pub/simtelnet/gnu/djgpp
  951.  
  952. California, USA:
  953.      ftp.digital.com, directory /pub/simtelnet/gnu/djgpp/
  954.  
  955. California, USA:
  956.      ftp.lib.sonoma.edu, directory /pub/simtelnet/gnu/djgpp/
  957.  
  958. Urbana, Illinois, USA:
  959.      uarchive.cso.uiuc.edu, directory /pub/systems/pc/simtelnet/gnu/djgpp
  960.  
  961. Massachusets, USA
  962.      ftp.bu.edu, directory /pub/mirrors/simtelnet/gnu/djgpp/
  963.  
  964. Rochester, Michigan, USA:
  965.      OAK.Oakland.Edu, directory /pub/simtelnet/gnu/djgpp
  966.  
  967. New York, NY, USA:
  968.      ftp.rge.com, directory /pub/systems/simtelnet/gnu/djgpp/
  969.  
  970. Oklahoma, USA:
  971.      ftp.ou.edu, directory /pub/simtelnet/gnu/djgpp/
  972.  
  973. Corvallis, Oregon, USA:
  974.      ftp.orst.edu, directory /pub/simtelnet/gnu/djgpp
  975.  
  976. Pennsylvania, USA:
  977.      ftp.epix.net, directory /pub/simtelnet/gnu/djgpp
  978.  
  979. Utah, USA:
  980.      ftp.cyber-naut.com, directory /pub/simtelnet/gnu/djgpp
  981.  
  982. Virginia, USA:
  983.      mirrors.aol.com, directory /pub/simtelnet/gnu/djgpp/
  984.  
  985. 
  986. File: djgppfaq.info,  Node: Where to find-Footnotes,  Up: Where to find
  987.  
  988. (1)  ftp.simtel.net is actually several ftp sites arranged in a rotating
  989. pattern of IP addresses to help balance the load and to avoid access problems
  990. due to network outages and simultaneous user limits.
  991.  
  992. 
  993. File: djgppfaq.info,  Node: CCT,  Next: How to download,  Prev: Where to find,  Up: Getting DJGPP
  994.  
  995. 4.2 CCT sites
  996. =============
  997.  
  998. **Q*: Where can I find the nearest CCT site?*
  999.  
  1000. *A* :  Look up the site nearest to you in the list below:
  1001.  
  1002. Note that the copyright to the name "SimTel" is owned by Walnut Creek which
  1003. sponsors the SimTel.NET repository, so the CCT mirrors are in the process of
  1004. renaming their directories to `Coast'.  Therefore, if you don't find the
  1005. directories listed below, replace "SimTel" by "Coast" and try again.
  1006.  
  1007. The primary CCT site is in Detroit, Michigan, USA:
  1008.      ftp.coast.net, directory /Coast/vendors/djgpp/.
  1009.  
  1010. Here is a list of hosts by countries that offer mirror sites:
  1011. Canberra, Australia:
  1012.      archie.au, directory /micros/pc/SimTel/vendors/djgpp
  1013.  
  1014. Edmonton, AB, Canada:
  1015.      ftp.agt.net, directory /pub/SimTel/vendors/djgpp
  1016.  
  1017. Prague, Czech Republic:
  1018.      pub.vse.cz, directory /pub/simtel/vendors/djgpp
  1019.  
  1020. London, England:
  1021.      src.doc.ic.ac.uk, directory /pub/packages/simtel/vendors/djgpp
  1022.  
  1023. Liverpool, England:
  1024.      ftp.mersinet.co.uk, directory /pub/ibmpc/coast/vendors/djgpp
  1025.  
  1026. London, England:
  1027.      ftp.demon.co.uk, directory /pub/mirrors/simtel/vendors/djgpp
  1028.  
  1029. Chemnitz, Germany:
  1030.      ftp.tu-chemnitz.de, directory /pub/simtel/vendors/djgpp
  1031.  
  1032. Mainz, Germany:
  1033.      ftp.uni-mainz.de, directory /pub/pc/mirrors/simtel/vendors/djgpp
  1034.  
  1035. Tuebingen, Germany:
  1036.      ftp.uni-tuebingen.de, directory /pub/simtel/vendors/djgpp
  1037.  
  1038. Hong Kong:
  1039.      ftp.cs.cuhk.hk, directory /pub/simtel/vendors/djgpp
  1040.  
  1041. Hong Kong:
  1042.      sunsite.ust.hk, directory /pub/simtel/vendors/djgpp
  1043.  
  1044. Dublin, Ireland:
  1045.      ftp.hea.ie, directory /pub/simtel/vendors/djgpp
  1046.  
  1047. Haifa, Israel:
  1048.      ftp.technion.ac.il, directory /pub/unsupported/simtel/vendors/djgpp
  1049.  
  1050. Naples, Italy:
  1051.      ftp.unina.it, directory /pub/simtel/vendors/djgpp
  1052.  
  1053. Pisa, Italy:
  1054.      cnuce-arch.cnr.it, directory /pub/msdos/simtel/vendors/djgpp
  1055.  
  1056. Rome, Italy:
  1057.      ftp.flashnet.it, directory /mirror/simtel/vendors/djgpp
  1058.  
  1059. Rome, Italy:
  1060.      cis.utovrm.it, directory /SimTel/vendors/djgpp
  1061.  
  1062. Tokyo, Japan:
  1063.      ftp.crl.go.jp, directory /pub/pc/archives/simtel/vendors/djgpp
  1064.  
  1065. Tokyo, Japan:
  1066.      ftp.web.ad.jp, directory /pub/mirrors/Coast/vendors/djgpp
  1067.  
  1068. Tokyo, Japan:
  1069.      ring.aist.go.jp, directory /pub/coast/vendors/djgpp
  1070.  
  1071. Tokyo, Japan:
  1072.      ring.asahi-net.or.jp, directory /pub/coast/vendors/djgpp
  1073.  
  1074. Seoul, Korea:
  1075.      ftp.kornet.nm.kr, directory /pub/SimTel/vendors/djgpp
  1076.  
  1077. Seoul, Korea:
  1078.      ftp.nowcom.co.kr, directory /pub/SimTel/vendors/djgpp
  1079.  
  1080. Utrecht, Netherlands:
  1081.      ftp.nic.surfnet.nl, directory
  1082.      /mirror-archive/software/simtel-vendors/djgpp
  1083.  
  1084. Poznan, Poland:
  1085.      ftp.man.poznan.pl, directory /mirror/simtel/vendors/djgpp
  1086.  
  1087. Warsaw, Poland:
  1088.      ftp.icm.edu.pl, directory /pub/simtel/vendors/djgpp
  1089.  
  1090. Moscow, Russia:
  1091.      ftp.radio-msu.net, directory /mirror/Coast/vendors/djgpp
  1092.  
  1093. Singapore:
  1094.      ftp.singnet.com.sg, directory /pub/mirrors/SimTel/vendors/djgpp
  1095.  
  1096. Slovak Republic:
  1097.      ftp.uakom.sk, directory /pub/SimTel/vendors/djgpp
  1098.  
  1099. Taipei, Taiwan:
  1100.      nctuccca.edu.tw, directory /PC/simtel/vendors/djgpp
  1101.  
  1102. Bangkok, Thailand:
  1103.      ftp.bu.ac.th, directory /pub/SimTel/vendors/djgpp
  1104.  
  1105. Sunnyvale, CA, USA:
  1106.      ftp.drcdrom.com, directory /Coast/vendors/djgpp
  1107.  
  1108. Note that DJGPP was moved to the `SimTel/vendors/' directory on most CCT
  1109. mirrors about a year ago.  This is because CCT claims a compilation copyright
  1110. on its collection, to prevent people from copying the CD-ROMs which are
  1111. distributed by CCT.  The GNU GPL prohibits *any* restrictions, even on
  1112. compilations.  So, FSF asked for GNU and GNU-related files to be moved to a
  1113. separate directory to keep people from accidentally thinking that their
  1114. rights were being reduced.
  1115.  
  1116. 
  1117. File: djgppfaq.info,  Node: How to download,  Next: DJGPP by WWW,  Prev: CCT,  Up: Getting DJGPP
  1118.  
  1119. 4.3 How do I download DJGPP?
  1120. ============================
  1121.  
  1122. **Q*: How do I download files from these sites?*
  1123.  
  1124. *A* :  FTP to the nearest site, log in as `anonymous', give your full e-mail
  1125. address as password, and chdir to the `djgpp' subdirectory (the exact path to
  1126. it might be different on different mirrors, check out *Note the DJGPP archive
  1127. path: Where to find, for your nearest mirror.).  Then issue the `binary'
  1128. command and download files you need (*note the list of required files: What
  1129. to download.) with the `get' or `mget' commands.
  1130.  
  1131. 
  1132. File: djgppfaq.info,  Node: DJGPP by WWW,  Next: What to download,  Prev: How to download,  Up: Getting DJGPP
  1133.  
  1134. 4.4 What if I don't know what `FTP' is?
  1135. =======================================
  1136.  
  1137. **Q*: What is that `FTP' thing?  I only use `Mosaic' for Internet access.*
  1138.  
  1139. *A* :  OK, here are some URLs for your Web browser:
  1140.  
  1141.    - The main SimTel.NET site, at this URL:
  1142.  
  1143.           http://www.simtel.net/simtel.net/gnu/djgpp/
  1144.  
  1145.    - The main CCT site, at this URL:
  1146.  
  1147.           http://www.coast.net/Coast/vendors/djgpp/
  1148.  
  1149.    - The CCT mirror in Rochester, MI, at this URL:
  1150.  
  1151.           http://www.acs.oakland.edu/oak/SimTel/vendors/djgpp/
  1152.  
  1153.    - The CCT mirror in St. Louis, MO, at this URL:
  1154.  
  1155.           http://wuarchive.wustl.edu/systems/msdos/simtel/vendors/djgpp/
  1156.  
  1157. You can also convert any of the mirrors' addresses listed in *Note the list
  1158. of SimTel.NET mirrors: Where to find, above to a valid URL by prepending
  1159. `ftp://' to it.  For example, here is the URL for FTP from the primary CCT
  1160. FTP site, e.g. ftp://ftp.coast.net/Coast/vendors/djgpp/.
  1161.  
  1162. Gopher users can access CCT files through a Gopher client,
  1163. gopher://gopher.oakland.edu.
  1164.  
  1165. For those of you who only have an e-mail connection to the Internet, CCT
  1166. files may be also obtained by e-mail from various ftp-mail servers or through
  1167. the BITNET/EARN file servers.  For details send a message to the CCT list
  1168. server <listserv@Coast.NET> with this command in the message body:
  1169.  
  1170.       get simtel-mailserver.info
  1171.  
  1172. 
  1173. File: djgppfaq.info,  Node: What to download,  Next: Disk space,  Prev: DJGPP by WWW,  Up: Getting DJGPP
  1174.  
  1175. 4.5 What Files to Download?
  1176. ===========================
  1177.  
  1178. **Q*: What's the minimum set of `.zip' files I need to download?*
  1179.  
  1180. *A* :  This depends on what you are planning to use DJGPP for.
  1181.  
  1182.    * To only run DJGPP-compiled programs, you MUST download all of these: (1)
  1183.      (*note What to download-Footnotes::)
  1184.  
  1185.     `v2/readme.1st'
  1186.           This explains how to install DJGPP and get started with using it.
  1187.  
  1188.     `v2/faq210b.zip'
  1189.           The latest edition of this FAQ list.  Use it whenever you have
  1190.           problems installing and using DJGPP.
  1191.  
  1192.     `v2misc/csdpmi3b.zip'
  1193.           CWSDPMI, the DJGPP free DPMI server.  (If you can get DPMI services
  1194.           in your environment, like if you run under Windows, QDPMI, or OS/2,
  1195.           you don't need CWSDPMI, but I recommend downloading it nonetheless
  1196.           so you can try it in case you have trouble with other DPMI servers.)
  1197.  
  1198.     `v2misc/pmode11b.zip'
  1199.           This is an alternative DPMI server, PMODE/DJ.  Its memory footprint
  1200.           is smaller than CWSDPMI and it can be bundled with DJGPP programs
  1201.           to make a stand-alone executable that doesn't require a DPMI server
  1202.           to run.  PMODE/DJ doesn't support virtual memory and its
  1203.           implementation of the DPMI spec is a bit more restricted than that
  1204.           of CWSDPMI.
  1205.  
  1206.    * For developing C programs (no C++), you MUST download all of the above,
  1207.      plus the following:
  1208.  
  1209.     `v2gnu/bnu27b.zip'
  1210.           The GNU Binutils, including `as', the GNU assembler; `ld', the GNU
  1211.           linker; and their docs.
  1212.  
  1213.     `v2/djdev201.zip'
  1214.           C header files and libraries, library reference, minimal development
  1215.           environment, DJGPP-specific utilities and their documentation.
  1216.  
  1217.     `v2gnu/gcc2721b.zip'
  1218.           The GNU C Compiler binaries and docs (including the docs for the C++
  1219.           compiler).
  1220.  
  1221.     `v2gnu/txi390b.zip'
  1222.           Info, a stand-alone program to read GNU hypertext documentation
  1223.           files, and an environment to produce such files.  Without `info',
  1224.           you cannot read the C library reference and the docs included with
  1225.           the ported GNU software packages.
  1226.  
  1227.    * For developing C++ programs, you will need all of the above, plus the
  1228.      following:
  1229.  
  1230.     `v2gnu/gpp2721b.zip'
  1231.           The GNU C++ compiler binary (the docs are part of the gccNNNb.zip
  1232.           package, see above).
  1233.  
  1234.     `v2gnu/lgp271b.zip'
  1235.           The C++ header files, the GNU C++ class libraries, and their docs.
  1236.  
  1237.     `v2gnu/obc2721b.zip'
  1238.           If you want to develop Objective-C programs, you will need this
  1239.           file, which includes the Objective-C compiler and header files.
  1240.  
  1241.    * The following are some optional packages which you might want:
  1242.  
  1243.         - Debugging:
  1244.  
  1245.          `v2gnu/gdb416b.zip'
  1246.                GDB, the GNU Debugger and its docs.  (Note that the `djdev'
  1247.                distribution includes two simpler debuggers, `edebug' and
  1248.                `fsdb.'  The latter presents a user interface similar to that
  1249.                of Turbo Debugger.)
  1250.  
  1251.         - Additional development tools (consider getting at least the Make
  1252.           distribution):
  1253.  
  1254.          `v2gnu/mak375b.zip'
  1255.                GNU Make program with its docs.  You should install Make 3.75
  1256.                if you use DJGPP v2.01 (previous ports of Make have subtle
  1257.                incompatibilities with v2.01 tools).  The port of Make 3.75
  1258.                supports Unix-style shells (as well as DOS `COMMAND.COM' and
  1259.                its `4DOS/NDOS' replacements) and can be used to run Unix
  1260.                Makefiles if you install a Unix-style shell (e.g., `bash') and
  1261.                auxiliary utilities.  It also supports long filenames on
  1262.                Windows 9x and MSDOS pathnames with drive letters.
  1263.  
  1264.          `v2apps/rhide10b.zip'
  1265.                The RHIDE integrated development environment for DJGPP
  1266.                (similar to Borland's IDE), written by Robert Hoehne
  1267.                <Robert.Hoehne@Mathematik.TU-Chemnitz.DE>.  The latest version
  1268.                features an integrated debugger, based on GDB code; a
  1269.                stand-alone version of GDB with a Turbo Vision interface (but
  1270.                not all GDB features can be used); and support for user
  1271.                interface in languages other than English (using a port of GNU
  1272.                `Gettext' library).
  1273.  
  1274.          `v2/djlsr201.zip'
  1275.                The sources of the DJGPP C library and utilities written
  1276.                specifically for DJGPP.  If you can afford the disk space (it
  1277.                requires about 10MB), I recommend installing or at least
  1278.                downloading it, so you can easily fix possible library bugs.
  1279.  
  1280.          `v2gnu/bsh1147b.zip'
  1281.                Bash (`Borne-Again SHell'), the GNU shell, and its docs.  If
  1282.                you mostly work in Unix environment, you will feel right at
  1283.                home using `bash' as your interactive shell.  It is also great
  1284.                as a batch shell for running Unix-born shell scripts and
  1285.                Makefiles when these are too complex to convert them to MSDOS.
  1286.                If you install `bash', you should also install auxiliary
  1287.                utilities (Fileutils, Textutils, Sh-utils, Grep, Diffutils,
  1288.                Findutils, Sed and Gawk) as these are usually invoked from
  1289.                many shell scripts and Makefiles.
  1290.  
  1291.          `v2gnu/bsn124b.zip'
  1292.                Bison, a Yacc-like parser generator, and its docs.
  1293.  
  1294.          `v2gnu/dif271b.zip'
  1295.                GNU Diffutils (diff, cmp, diff3, sdiff), and their docs.  If
  1296.                you need to submit patches or changes to DJGPP or GNU sources,
  1297.                you will need the GNU `diff' program from this package.
  1298.  
  1299.          `v2gnu/emacs.README'
  1300.          `v2gnu/em1934*.zip'
  1301.                GNU Emacs, the most powerful, customizable, extensible
  1302.                programmer's editor known today.  The DJGPP port supports
  1303.                mouse, menu bar, pop-up menus, color syntax highlighting,
  1304.                reading Info documentation and compilation from within the
  1305.                editor, long filenames on Windows 9x, and much more.  Emacs
  1306.                can and should be used as an integrated development
  1307.                environment (another alternative is `RHIDE', see above).
  1308.                Please read the file `emacs.README' before you begin
  1309.                downloading the rest.
  1310.  
  1311.          `v2gnu/fil313b.zip'
  1312.                GNU Fileutils, including `ls', `rm', `cp', `mv', and others.
  1313.                Highlights of the latest port: `ls' supports colorization of
  1314.                files (like on Linux), `ln -s' knows about DJGPP-style
  1315.                "symlinks" (see *Note symlink feature of DJGPP: Symlinks,
  1316.                elsewhere in this document), `install -s' will strip
  1317.                executables on the fly, and all the utilities support long
  1318.                filenames on Windows 9x and numbered backups (even on plain
  1319.                DOS).  This package is a must if you want to run Unix shell
  1320.                scripts, as they use some of these utilities *a lot*.
  1321.  
  1322.          `v2gnu/flx252b.zip'
  1323.                Flex, a Lex-like lexical analyzer generator, and its docs.
  1324.  
  1325.          `v2gnu/grep20b.zip'
  1326.                GNU Grep package and its docs.  You need this if you use Emacs
  1327.                (which has commands that invoke Grep) or if you want to run
  1328.                Unix shells and Makefiles.
  1329.  
  1330.          `v2gnu/pat21b.zip'
  1331.                GNU Patch program and docs.  Required to apply patches to
  1332.                DJGPP sources.
  1333.  
  1334.          `v2gnu/sed118b.zip'
  1335.                GNU Sed (a batch editor) program and its docs.  Many ported
  1336.                packages require it during the build process on MSDOS.
  1337.  
  1338.          `v2gnu/shl112b.zip'
  1339.                GNU Sh-utils.  A must if you use the port of `bash' or want to
  1340.                run Unix Makefiles, but some utilities (such as `env' or
  1341.                `test') can also be very useful on their own right.
  1342.  
  1343.          `v2gnu/txt119b.zip'
  1344.                GNU Textutils.  Includes many useful programs, such as `sort',
  1345.                `wc', `cat', `join', `paste', `od', and `uniq'.  Unix shell
  1346.                scripts and Makefiles call some of these *a lot*, so you
  1347.                should install this package if you run them.
  1348.  
  1349.         - Developing text-mode and graphics GUI applications:
  1350.  
  1351.          `v2tk/grx20.zip'
  1352.                The DJGPP graphics library.
  1353.  
  1354.          `v2tk/bcc2grx.zip'
  1355.                The interface library to convert Borland graphics calls to GRX
  1356.                library calls.
  1357.  
  1358.          `v2tk/pdc22.zip'
  1359.                Public-domain Curses library.
  1360.  
  1361.      For description of additional files not mentioned here, get the file
  1362.      `00_index.txt'; it contains a full list of the distribution files and a
  1363.      short description of every file.
  1364.  
  1365. 
  1366. File: djgppfaq.info,  Node: What to download-Footnotes,  Up: What to download
  1367.  
  1368. (1)  The version numbers of the packages below might not be up to date.  For
  1369. the latest versions, check out the DJGPP Mini-FAQ posted weekly to the
  1370. comp.os.msdos.djgpp news group.
  1371.  
  1372. 
  1373. File: djgppfaq.info,  Node: Disk space,  Next: DJGPP = Fatware,  Prev: What to download,  Up: Getting DJGPP
  1374.  
  1375. 4.6 How much disk space will I need?
  1376. ====================================
  1377.  
  1378. **Q*: Wow, that's a lot of files.  How much disk storage will I need?*
  1379.  
  1380. *A* :  The following lists the approximate disk space required for several
  1381. major configurations, and additional storage required for some optional
  1382. packages:
  1383.  
  1384.      Execution-only environment..................300 KBytes
  1385.      Developing C programs.......................13  MBytes
  1386.      Developing C++ programs.....................17  MBytes
  1387.      Developing Objective-C programs.............15  MBytes
  1388.      Additional storage for RHIDE................2.5 MBytes
  1389.      Additional storage for DJGPP sources........10  MBytes
  1390.      Additional storage for GDB..................1.1 MBytes
  1391.      Additional storage for Emacs................30  MBytes
  1392.      Additional storage for Flex.................280 KBytes
  1393.      Additional storage for Bison................310 KBytes
  1394.      Additional storage for Diffutils............560 KBytes
  1395.      Additional storage for Make.................520 KBytes
  1396.      Additional storage for Patch................120 KBytes
  1397.      Additional storage for Sed..................73  KBytes
  1398.      Additional storage for Graphics libraries...4   MBytes
  1399.  
  1400. Note that the above lists only approximate numbers.  In particular, the disk
  1401. cluster size can significantly change the actual disk space required by some
  1402. of the distributions (those with a large number of files).  The numbers above
  1403. are for disks up to 512MB which have 8KB-long clusters.
  1404.  
  1405. In addition to the space for installing the software, you will need some free
  1406. disk space for the swap file.  You should leave enough free disk space to
  1407. make the total virtual memory at least 20 MBytes; that will be enough for
  1408. most applications.  Invoke the `go32-v2.exe' program without arguments to see
  1409. how much DPMI memory and swap space DJGPP applications can use.  Depending on
  1410. your DPMI host, you might need to review its virtual memory settings in
  1411. addition to leaving free disk space; `CWSDPMI' requires only that enough free
  1412. disk space be available, but other DPMI hosts have special settings to
  1413. specify how much virtual memory they let their clients use, as *Note
  1414. explained below: How much memory.
  1415.  
  1416. 
  1417. File: djgppfaq.info,  Node: DJGPP = Fatware,  Prev: Disk space,  Up: Getting DJGPP
  1418.  
  1419. 4.7 Can I get away with less megabytes?
  1420. =======================================
  1421.  
  1422. **Q*: The above table means that I need more than 17 MBytes for C/C++
  1423. development environment; that's about 7 1.44MB diskettes to hold even the
  1424. compressed archive!!  Seems to me DJGPP is afflicted by the *fatware*
  1425. disease...*
  1426.  
  1427. **Q*: Pulling that many megabytes through the net from my overloaded
  1428. SimTel.NET mirror is almost impossible.  Can't you prepare a ZIP archive
  1429. which only includes stuff I can't do without?*
  1430.  
  1431. *A* : There are a number of shareware/freeware programs floating around which
  1432. allow formatting DOS diskettes to almost twice their usual capacity, so you
  1433. can use less floppies.  One such program is 2M, available from CCT mirrors as
  1434. 2mNN.zip, e.g. ftp://ftp.coast.net/Coast/msdos/diskutil/2m30.zip.
  1435.  
  1436. To make downloading DJGPP easier, download and compile the `BatchFTP'
  1437. program.  It allows you to submit a script of FTP commands and will
  1438. repeatedly try to login into the FTP site you specify until the script is
  1439. successfully completed.  It is smart enough to understand the messages which
  1440. the FTP server sends to you (like `login refused' etc.) and also is nice to
  1441. the remote server by sleeping for some time between login attempts.
  1442. `BatchFTP' is free software and can be found on many FTP sites, e.g.
  1443. ftp://oak.oakland.edu/pub/unix-c/networks/batchftp.tar.Z.
  1444.  
  1445. `BatchFTP' is a Unix program; those who access the net from their PC (not by
  1446. dialing into some Unix host with a shell account), can use a nice
  1447. FTP-automating utility called `AutoWinNet' (get the file autownNN.zip from
  1448. your nearest CCT mirror, e.g.
  1449. ftp://ftp.coast.net/Coast/win3/winsock/autown19.zip).
  1450.  
  1451. As for the minimal DJGPP installation, volunteers are welcome to prepare such
  1452. an archive and make it publicly available, in the same spirit as `EZ-GCC' did
  1453. for DJGPP v1.x.
  1454.  
  1455. 
  1456. File: djgppfaq.info,  Node: Docs,  Next: Trouble,  Prev: Getting DJGPP,  Up: Top
  1457.  
  1458. 5. The DJGPP Documentation
  1459. **************************
  1460.  
  1461.   This chapter explains where to find and how to read DJGPP documentation, and
  1462. how to solve occasional problems with the docs system.
  1463.  
  1464. * Menu:
  1465.  
  1466. * Where is the docs::          Where to find the docs and how to read them.
  1467. * No Info::                    For those who can't stand Info.
  1468. * Printed docs::               How to produce a printed manual.
  1469. * Ready PS::                   Where to find printer-ready manuals.
  1470. * Can't find docs::            For some programs it's tricky ...
  1471. * Man pages::                  How to read these.
  1472. * Last resort::                Look in the source, of course!
  1473.  
  1474. 
  1475. File: djgppfaq.info,  Node: Where is the docs,  Next: No Info,  Prev: Docs,  Up: Docs
  1476.  
  1477. 5.1 Where are the documentation files?
  1478. ======================================
  1479.  
  1480. **Q*: I don't see any documentation files...*
  1481.  
  1482. *A* :  The documentation files are in the `info/' subdirectory of your main
  1483. DJGPP installation directory.  You will need a program to read these docs,
  1484. which are hypertext structured files.  You have several choices:
  1485.  
  1486.   a. Use the stand-alone `Info' reader.
  1487.  
  1488.      Get the file txi390b.zip, e.g.
  1489.      ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/txi390b.zip, which
  1490.      includes `INFO.EXE' and its docs.  Unzip it and run `Info.'  It will
  1491.      bring up a (hopefully) self-explanatory online help system.  Confused?
  1492.      Press `?' to see the list of all Info commands.  Still confused?  Press
  1493.      `h' to have `Info' take you on a guided tour through its commands and
  1494.      features.
  1495.  
  1496.   b. Use the `Info' command of your favorite editor.
  1497.  
  1498.      If you use Emacs, you already know about `Info.'  (What's that?  You
  1499.      don't?  Type `C-h <i>' and you will get the top-level menu of all the
  1500.      Info topics.)  RHIDE also has an integrated Info reader, which is the
  1501.      core of its help system.
  1502.  
  1503.  
  1504. 
  1505. File: djgppfaq.info,  Node: No Info,  Next: Printed docs,  Prev: Where is the docs,  Up: Docs
  1506.  
  1507. 5.2 How to read the docs without `Info?'
  1508. ========================================
  1509.  
  1510. **Q*: I'm too old/lazy/busy to learn yet another browser, and I despise
  1511. uGNUsable programs like Emacs.  How in the world can I read the DJGPP docs??*
  1512.  
  1513. *A* :  Info files are almost plain ASCII files, so you should be able to view
  1514. them with your favorite text file browser or editor.  You will lose the
  1515. hypertext structure and you might have a hard time finding the next chapter
  1516. (hint: look up the name of the Next node at the beginning of this node, then
  1517. use the search commands of the browser, or the Grep program, to find that
  1518. name), but other than that you will see all the text.
  1519.  
  1520. Anthony Appleyard <A.APPLEYARD@fs2.mt.umist.ac.uk> has translated the Info
  1521. files for GNU C/C++ Compiler (`gcc.iNN') and GNU C Preprocessor (`cpp.iNN')
  1522. into ISO-8859 (aka plain ASCII), and Stephen Turnbull
  1523. <turnbull@shako.sk.tsukuba.ac.jp> has made them available on his anonymous
  1524. ftp and WWW server.  You can get them as `gcc.txt' and `preprocessor.txt' by
  1525. anonymous ftp, e.g. ftp://turnbull.sk.tsukuba.ac.jp/pub/djgpp/doc/; or get
  1526. them with your Web browser, at this URL:
  1527.  
  1528.      http://turnbull.sk.tsukuba.ac.jp/pub/djgpp/doc/
  1529.  
  1530. You can also produce pure ASCII files yourself, if you have their Texinfo
  1531. sources.  These are usually called `*.txi' or `*.tex' and should be included
  1532. with the source distribution of every package.  To produce an ASCII file
  1533. `foo.txt' from the Texinfo file `foo.txi', invoke the `Makeinfo' program like
  1534. this:
  1535.  
  1536.       makeinfo --no-split --no-headers --output foo.txt foo.txi
  1537.  
  1538. The `Makeinfo' program is part of the Texinfo distribution which is available
  1539. in txi390b.zip, e.g.
  1540. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/txi390b.zip.
  1541.  
  1542. If you prefer reading the docs through the Web, point your Web browser to the
  1543. docs page of the DJGPP Web site, at this URL:
  1544.  
  1545.      http://www.delorie.com/gnu/docs/
  1546.  
  1547. 
  1548. File: djgppfaq.info,  Node: Printed docs,  Next: Ready PS,  Prev: No Info,  Up: Docs
  1549.  
  1550. 5.3 How to print the docs?
  1551. ==========================
  1552.  
  1553. **Q*: I like my docs the old way: printed on paper, stacked near my
  1554. workplace.  How can I print the documentation files which come with DJGPP?*
  1555.  
  1556. *A* :  You will need to get and install a program called TeX or its
  1557. work-alike, like LaTeX or emTeX.  (They are NOT part of DJGPP.) Then run your
  1558. TeX work-alike on the docs' *source* files (called `*.txi' or `*.tex') which
  1559. you get with the source distribution of every package you download.  You will
  1560. get a `.dvi' file which you can print; or you can run a DVI-to-PostScript
  1561. converter such as `DVIPS' to produce a PostScript output.  `DVIPS' is a free
  1562. program; you can find it on SimTel.NET mirrors, e.g.
  1563. ftp://ftp.simtel.net/pub/simtelnet/msdos/postscrp/dvips558.zip.
  1564.  
  1565. DJGPP comes with a program called `TEXI2PS' which can convert *.txi files to
  1566. a crude PostScript; try it if you don't care much about the appearance of the
  1567. printed docs.
  1568.  
  1569. If TeX won't run, check that you have the file `texinfo.tex' which defines
  1570. the TeX macros specific to Texinfo files.  If you don't, get the latest GNU
  1571. or DJGPP Texinfo distribution which includes that file.
  1572.  
  1573. If you'd like to produce printed docs of the library reference, TeX might
  1574. complain that it cannot find a file named `libc2.tex'.  This file is
  1575. generated from all the `*.txh' files in the DJGPP source distribution
  1576. (`djlsr201.zip').  In order to build this file, you need to install
  1577. `djlsr201.zip', then go to the `src/libc' directory and type this from the DOS
  1578. command prompt:
  1579.  
  1580.        make -C ../mkdoc
  1581.        make doc
  1582.  
  1583. If the above command fails due to unresolved externals, you will need to edit
  1584. the file `makefile' in the `mkdoc' directory.  It has a line which calls `ld'
  1585. (the linker), where you should change `-lgcc -lc' into `-lgcc -lc -lgcc'.
  1586. Save `makefile' and try the above commands again.
  1587.  
  1588. Note that some documentation files (notably, those for GCC) will produce
  1589. voluminous print-outs.  You *have* been warned!
  1590.  
  1591. 
  1592. File: djgppfaq.info,  Node: Ready PS,  Next: Can't find docs,  Prev: Printed docs,  Up: Docs
  1593.  
  1594. 5.4 Where can I find docs in PostScript?
  1595. ========================================
  1596.  
  1597. **Q*: I don't have all these fancy packages, and I don't have disk space to
  1598. install them in the first place.  Can't you guys just include with DJGPP a
  1599. set of ready-to-print PostScript files?*
  1600.  
  1601. *A* :  They are *very* large and would eat up too much storage (much more
  1602. than the fancy packages you don't want to install).  Most of the people read
  1603. the docs on-line and never print them anyway.  Sorry.
  1604.  
  1605. However, some *Good Samaritans* from all across the Net have taken time and
  1606. effort to produce the docs in PostScript format and made them available by
  1607. anonymous ftp.  The most full set of docs for the latest versions of GNU
  1608. software is available in plain ASCII, `zip' and `tar.gz' format by anonymous
  1609. ftp from phi.sinica.edu.tw, e.g. ftp://phi.sinica.edu.tw/pub/aspac/gnu/; they
  1610. are all for A4 paper.  Other places to look for PostScript versions of GNU
  1611. documentation are:
  1612.  
  1613. In European A4 format, e.g. ftp://liasun.epfl.ch/pub/gnu/ps-doc/.
  1614. In US letter format, e.g. ftp://primus.com/pub/gnu-ps/.
  1615. Many GNU manuals in `HTML' (hypertext) format, suitable for reading with your
  1616. Web browser, can be viewed at the DJGPP Web site, at this URL:
  1617.  
  1618.      http://www.delorie.com/gnu/docs/
  1619.  
  1620. DJGPP includes a utility called `TEXI2PS' which converts the Texinfo source
  1621. files to crude PostScript; try it.
  1622.  
  1623. 
  1624. File: djgppfaq.info,  Node: Can't find docs,  Next: Man pages,  Prev: Ready PS,  Up: Docs
  1625.  
  1626. 5.5 Some docs are nowhere to be found...
  1627. ========================================
  1628.  
  1629. **Q*: I looked in my `info/' subdirectory, but I can't find docs for some of
  1630. the utilities, like `Sed' or `Gprof.'*
  1631.  
  1632. *A* :  Download the source archive (`*s.zip') for that package and look
  1633. inside it, usually in the directory called `man' or `doc.'
  1634.  
  1635. 
  1636. File: djgppfaq.info,  Node: Man pages,  Next: Last resort,  Prev: Can't find docs,  Up: Docs
  1637.  
  1638. 5.6 What are these `foo.1' files?
  1639. =================================
  1640.  
  1641. **Q*: Some docs files are called `foo.1' or `bar.man' or `baz.nroff', and
  1642. they seem to be written in some weird format which is very difficult to read.
  1643. How can I convert them to readable text files?*
  1644.  
  1645. *A* :  That weird format is the `troff' format which is used for writing Unix
  1646. manual pages.  The Unix command `man' converts them to formatted text files
  1647. which are usually displayed with a program like `more' or `less' (and here
  1648. `less' is considered to be more than `more' :-)).  The formatted file
  1649. includes bold and underlined letters produced by over-typing using Backspace
  1650. characters.  To format these files, you can choose one of these methods:
  1651.  
  1652.    * Get and install a DOS port of the `groff' package, or port it yourself
  1653.      (a very difficult task).  The latest `groff' distribution can be found
  1654.      on the GNU ftp archive, e.g. ftp://ftp.gnu.ai.mit.edu/pub/gnu/ or any of
  1655.      its mirrors.  A port of (an old version of) Groff to (an old version of)
  1656.      DJGPP can be downloaded from the DJGPP ftp server, e.g.
  1657.      ftp://ftp.delorie.com/pub/djgpp/contrib/groff.zip.
  1658.  
  1659.    * Get and install `CAWF', a DOS program which knows about most of the
  1660.      `troff' formatting commands.  `CAWF' can be found on one of the CCT
  1661.      mirrors, e.g. ftp://ftp.coast.net/Coast/msdos/textutil/cawf404.zip.
  1662.  
  1663.    * Write or port a `man' clone.  Source for one such clone was posted to
  1664.      the DJGPP news group, so you can get it there, at this URL:
  1665.  
  1666.           http://www.delorie.com/djgpp/mail-archives/djgpp/1995/06/19/12:57:43
  1667.  
  1668.      You can also download this port from the DJGPP ftp server, e.g.
  1669.      ftp://ftp.delorie.com/pub/djgpp/contrib/man-pc.zip.
  1670.  
  1671.    * Format the file on any Unix machine, and download the results to your PC.
  1672.      On Unix, typing `catman -p' will print the commands which are required
  1673.      to do this; you can then run those commands on your `*.1' `troff' source
  1674.      files.
  1675.  
  1676. No matter which of the above methods you choose, you will need some kind of
  1677. browser which understands how to show bold and underlined letters instead of
  1678. backspace-over-typed characters.  I suggest to download a DJGPP port of GNU
  1679. Less, e.g. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/lss321b.zip,
  1680. which uses colors to show bold and underlined letters.  Alternatively, you
  1681. can get the latest official GNU Less distribution, e.g.
  1682. ftp://ftp.gnu.ai.mit.edu/pub/gnu/less-321.tar.gz which can be compiled out of
  1683. the box with the Borland C compiler.  (Future versions of `Less' will also
  1684. compile with DJGPP.)
  1685.  
  1686. Another possibility for reading formatted man pages would be with an Emacs
  1687. editor, if you use one.  Emacs has a special command to read man pages, but
  1688. it requires a port or a clone of a Unix `man' command, described above.
  1689.  
  1690. Beginning with version 3.6, the stand-alone `Info' program can also read man
  1691. pages (it invokes a subsidiary program `man' to format them, then displays
  1692. its output; see the file `README.djgpp' in the DJGPP Texinfo distribution for
  1693. more details on how to set this up).  So if you have the DJGPP Texinfo
  1694. distribution, you can read man pages with `Info' already; if not, just
  1695. download Texinfo, e.g.
  1696. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/txi390b.zip.
  1697.  
  1698. Note that, for GNU packages, the man pages aren't always updated on a regular
  1699. basis.  If you need more up-to-date information, see the Info files.
  1700.  
  1701. 
  1702. File: djgppfaq.info,  Node: Last resort,  Prev: Man pages,  Up: Docs
  1703.  
  1704. 5.7 What if the docs don't say enough?
  1705. ======================================
  1706.  
  1707. **Q*: OK, I've got the docs and have read them, but I still can't figure out
  1708. some details.*
  1709.  
  1710. *A* :  Some ported packages include DJGPP-specific or MSDOS-specific `README'
  1711. files (named `README.dj', `README.dos' or some such), which explain
  1712. DOS-specific issues; you should read them before any serious use of the
  1713. package, or in case of any problems.  If this doesn't help, download the
  1714. sources and look there, or ask on the net--either the DJGPP News group or
  1715. appropriate GNU News groups.
  1716.  
  1717. 
  1718. File: djgppfaq.info,  Node: Trouble,  Next: Compiler performance,  Prev: Docs,  Up: Top
  1719.  
  1720. 6. When the Compiler (or `Make', or `Info', or ...) Crashes...
  1721. **************************************************************
  1722.  
  1723.   This chapter explains how to deal with certain problems which may prevent
  1724. DJGPP programs from running on your machine.  The first 8 items on the next
  1725. menu describe specific problems; if yours isn't solved with these techniques,
  1726. read the description of *Note the general debugging procedure: General
  1727. trouble.
  1728.  
  1729. * Menu:
  1730.  
  1731. * No DPMI::                  You must have or install a DPMI server.
  1732. * Buggy DPMI::               It might crash all of your v2.x programs.
  1733. * GCC optimizations::        GCC sometimes crashes when optimizing.
  1734. * Fatal signal::             GCC says *"Fatal signal X"*.
  1735. * Unknown filetype::         GCC says *"Unknown filetype"*.
  1736. * QEMM AUTO::                Can't use this with DJGPP.
  1737. * Make hangs::               Compiler hangs, but only under Make.
  1738. * Info can't find "Top"::  Info won't display some files.
  1739. * General trouble::          Look here for any problem not covered above.
  1740. * Redirect::                 How to redirect GCC messages to a file.
  1741. * Deja vu::                  Look up your problem in the
  1742.                                *comp.os.msdos.djgpp* archives.
  1743. * Totally lost::             When nothing seems to help, ask on the net.
  1744.  
  1745. 
  1746. File: djgppfaq.info,  Node: No DPMI,  Next: Buggy DPMI,  Prev: Trouble,  Up: Trouble
  1747.  
  1748. 6.1 GCC says "No DPMI"
  1749. ======================
  1750.  
  1751. **Q*: I'm trying to run `gcc', but all I get is a message saying "Load error:
  1752. no DPMI".  What am I doing wrong?*
  1753.  
  1754. *A* :  You don't have a DPMI server installed, and DJGPP v2 requires it to
  1755. run.  You can either use one of the commercial DPMI servers (e.g., run `gcc'
  1756. in a DOS box from Windows) or download and install CWSDPMI
  1757. (`v2misc/csdpmi3b.zip' from SimTel.NET mirrors) which is a free DPMI server
  1758. written for DJGPP.
  1759.  
  1760. 
  1761. File: djgppfaq.info,  Node: Buggy DPMI,  Next: GCC optimizations,  Prev: No DPMI,  Up: Trouble
  1762.  
  1763. 6.2 Buggy DPMI host or junk in DJGPP.ENV can crash v2.x programs
  1764. ================================================================
  1765.  
  1766. **Q*: When I try to run Info, it crashes immediately...*
  1767.  
  1768. **Q*: I cannot run v2 applications: they all hang or reboot my system, while
  1769. v1.x apps run OK.  Is this what v2 is all about--getting me out of the DJGPP
  1770. community?*
  1771.  
  1772. *A* : No, believe it or not, we don't want to oust you.  Your problems might
  1773. be caused by a buggy "DPMI" (*note DOS Protected Mode Interface: DPMI Spec.)
  1774. host installed on your machine.  One DPMI host which is particularly known to
  1775. be a source of trouble is the one which comes with Novell NWDOS (and also
  1776. Caldera's OpenDOS, which is a derivative of NWDOS).  Please see if v2.0
  1777. programs run when you disable DPMI services of your usual configuration
  1778. (DJGPP programs will then use the CWSDPMI host supplied with DJGPP).  To turn
  1779. off the DPMI host built into Novell NWDOS and Caldera's OpenDOS, either
  1780. remove the `DPMI=TRUE' parameter from the EMM386 command line, or type `DPMI
  1781. OFF' from the DOS command prompt.
  1782.  
  1783. Another DPMI host which is known to cause problems in DJGPP is Quarterdeck's
  1784. QDPMI which comes with QEMM 7.5.  It was reported to cause `Info' and all
  1785. DJGPP debuggers to crash.  If you use QDPMI, upgrade to the version 7.53 or
  1786. later (patches for that version are available from the Quarterdeck's ftp
  1787. site), or disable QDPMI and use CWSDPMI.
  1788.  
  1789. Yet another cause of crashes in `Info' might be trailing whitespace in the
  1790. `DJGPP.ENV' file.  The telltale signs of this failure are a stack dump that
  1791. is bogus or doesn't start with your `main' function, or a series of SIGSEGV
  1792. that won't stop.  Actually, this is a bug in the DJGPP v2.0 startup code, so
  1793. any v2.0 program could crash in this way, but since the last section of stock
  1794. `DJGPP.ENV' belongs to `Info', it is the one which suffers most from this
  1795. bug.  Make sure your `DJGPP.ENV' doesn't have a `^Z' character at the end
  1796. (some DOS editors put it if you edit the file), and doesn't end with a blank
  1797. line.  Alternatively, upgrade to DJGPP v2.01 or later, where that bug is
  1798. fixed.
  1799.  
  1800. 
  1801. File: djgppfaq.info,  Node: GCC optimizations,  Next: Fatal signal,  Prev: Buggy DPMI,  Up: Trouble
  1802.  
  1803. 6.3 GCC can crash during optimization
  1804. =====================================
  1805.  
  1806. **Q*: When I compile my program, the compiler crashes, but the problem seems
  1807. to go away if I compile without optimization.*
  1808.  
  1809. **Q*: The compiler prints "Virtual memory exhausted" and dies while compiling
  1810. some long functions with some optimization options, such as -funroll-loops or
  1811. -fforce-addr.*
  1812.  
  1813. *A* :  For some programs, this can be caused by an insufficient stack.  Some
  1814. source files make `cc1.exe' or `cc1plus.exe' need preposterously large
  1815. amounts of stack space, but only when you turn on optimizations.  (One user
  1816. reported that an innocent-looking C source file required 700KB of stack
  1817. before `cc1.exe' was able to compile it with optimizations!)  Try stubediting
  1818. the compiler to enlarge its stack, as described elsewhere in this FAQ, *Note
  1819. how to enlarge the stack: Fatal signal, before you try any other remedies in
  1820. this section.
  1821.  
  1822. GCC 2.6.0 was known to crash when optimizing, especially when compiling C++
  1823. programs, but it can also happen for later versions, especially if your code
  1824. has some syntactic or semantic bug.  (This is usually a genuine GCC bug, not
  1825. something special to DJGPP.)  Upgrade to the latest version of GCC.  If that
  1826. doesn't help, then narrow the offending code fragment using the `#if 0 ...
  1827. #endif' paradigm.  If this fragment includes an error, correct it and try
  1828. again; if it is syntactically and semantically correct, then rewrite it as
  1829. equivalent, but syntactically different one.
  1830.  
  1831. If GCC reports that it has exhausted virtual memory, you should first see if
  1832. your swap space is large enough (run `go32-v2' with no arguments) and make
  1833. more free space on your disk if so.  Some users have reported that GCC seems
  1834. to run out of virtual memory if TMPDIR environment variable points to a RAM
  1835. disk which doesn't have enough free space.  Changing TMPDIR to point to a
  1836. hard disk would reportedly save the day in those cases.
  1837.  
  1838. An undocumented GCC switch can sometimes help you zero in on the code
  1839. fragment that causes GCC to crash.  If you add `-Q' to the GCC command line,
  1840. it will print the name of every function it compiles.  The function that
  1841. makes it crash is probably the one whose name is the last one printed, or the
  1842. one after that.
  1843.  
  1844. You can also try to disable the strength-reduction optimizations of GCC by
  1845. using the `-fno-strength-reduce' switch.  GCC has a known bug in that type of
  1846. optimization which goes back as far as version 2.5.8 and is only corrected in
  1847. GCC 2.7.2.1 or later; this bug raises its ugly head on rare occasions, but is
  1848. notoriously hard to hunt down when it does.  (The stock v2.0 distribution
  1849. should by default disable this kind of optimizations on the `lib/specs' file,
  1850. and v2.01 comes with GCC 2.7.2.1 where that bug is fixed.)
  1851.  
  1852. As an extreme measure, don't optimize at all, if that's the only way to make
  1853. your program compile.
  1854.  
  1855. Another reason for this could be some problem with your system hardware or
  1856. the BIOS (like if you set an incorrect number of wait states when accessing
  1857. memory).  To check, try running the same compilation on another machine, or
  1858. review your BIOS settings.
  1859.  
  1860. Yet another cause for such crashes can be connected with excess memory usage
  1861. that GCC needs when compiling certain programs, which makes some DPMI hosts
  1862. fail.  For details about this, see *Note CWSDPMI allocation problems: Fatal
  1863. signal, in the next section.
  1864.  
  1865. 
  1866. File: djgppfaq.info,  Node: Fatal signal,  Next: Unknown filetype,  Prev: GCC optimizations,  Up: Trouble
  1867.  
  1868. 6.4 What does "Fatal signal X" mean?
  1869. ====================================
  1870.  
  1871. **Q*: I get "fatal signal 2" when I run GCC.*
  1872.  
  1873. **Q*: When I try compiling a program, GCC aborts saying "Installation
  1874. problem, cannot exec `as': No such file".  What does that mean?*
  1875.  
  1876. **Q*: GCC aborts with "Internal compiler error" when compiling a large C++
  1877. program.*
  1878.  
  1879. *A* : When GCC reports a "signal", it really means that an error occurred
  1880. trying to run one of the compiler passes.  The "signal" number is the DOS
  1881. error code, and 2 means "file not found" (dust off your DOS reference for
  1882. other error codes).  This (and the more explicit "cannot exec" message) means
  1883. GCC couldn't find some program it needs to run to compile your source.  Check
  1884. the `COMPILER_PATH' environment variable or what the `COMPILER_PATH' line in
  1885. the `DJGPP.ENV' file says, and make sure they point to the directory where
  1886. DJGPP programs reside.  Also check that the named directory has all the
  1887. required programs: `cpp.exe', `cc1.exe', `cc1plus.exe', `cxxfilt.exe',
  1888. `gasp.exe', `as.exe', `ld.exe', and (for Objective-C) `cc1obj.exe.'  A
  1889. typical case is when people fail to install the Binutils package, e.g.
  1890. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bnu27b.zip and GCC cannot
  1891. find `as.exe' (the assembler) and `ld.exe' (the linker).  You can use the
  1892. `-v' switch to GCC to see what programs it invokes and which one of them
  1893. causes the fatal error.
  1894.  
  1895. The "Internal compiler error" message usually means a genuine bug in GCC
  1896. (which should be reported to FSF), but it can also happen when GCC requests
  1897. additional chunk of memory, and the DPMI server fails to allocate it because
  1898. it exhausts available memory for its internal tables.  Release 1 of CWSDPMI
  1899. can fail like this if an application asks for a large number of small memory
  1900. chunks.  If you use release 1 of CWSDPMI, you can enlarge the maximum space
  1901. that CWSDPMI uses if you get a CWSDPMI heap-fix patch, e.g.
  1902. ftp://ftp.neosoft.com/pub/users/s/sandmann/csdpmi1heapfix.zip.  Beginning
  1903. with release 2, CWSDPMI defines a larger (6KB) default heap that is
  1904. configurable by CWSPARAM program to be anywhere between 3K and 40K bytes,
  1905. without recompiling CWSDPMI.  You should upgrade to the latest CWSDPMI if you
  1906. experience such problems.
  1907.  
  1908. You can also run `stubedit' on `cc1plus.exe' and enlarge its maximum stack
  1909. size to 512K bytes (some people report that they needed to enlarge both the
  1910. heap of CWSDPMI and the stack of the C++ compiler to make this problem go
  1911. away).  If you see such problems when compiling a C program, stubedit
  1912. `cc1.exe.'
  1913.  
  1914. For a program that you wrote, another work-around is to use an alternative
  1915. algorithm for `sbrk', by putting the following somewhere in your program:
  1916.  
  1917.        #include <crt0.h>
  1918.        int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
  1919.  
  1920. Note that the Unix algorithm for `sbrk' might cause trouble in programs that
  1921. install hardware interrupts handlers.
  1922.  
  1923. 
  1924. File: djgppfaq.info,  Node: Unknown filetype,  Next: QEMM AUTO,  Prev: Fatal signal,  Up: Trouble
  1925.  
  1926. 6.5 What does "Unknown filetype" mean?
  1927. ======================================
  1928.  
  1929. **Q*: I get error messages saying "Unknown filetype" from GCC.*
  1930.  
  1931. **Q*: Since a few days ago, whenever I try to run most of the DJGPP programs,
  1932. they print a message "C:\DJGPP\BIN\prog.exe: not COFF" and just terminate.
  1933. Help!!!*
  1934.  
  1935. *A* :  It might be that your DJGPP programs and/or `STUBIFY.EXE' are infected
  1936. by a virus.  (This is *not* a joke!  It did happen to a few of us and can
  1937. happen even to you.)  As the DOS stub prepended to the DJGPP programs is very
  1938. short, most viruses cannot attach themselves to it without overwriting the
  1939. beginning of the DJGPP COFF image which specifies vital information such as
  1940. location and length of various program sections, therefore triggering this
  1941. error from the code in the stub that loads the COFF image.
  1942.  
  1943. Another possible cause of the "Unknown filetype" message is that you mix a
  1944. v2.0 `gcc.exe' driver with `cc1plus.exe', `cc1.exe' or other programs from an
  1945. old v1.x distribution.
  1946.  
  1947. 
  1948. File: djgppfaq.info,  Node: QEMM AUTO,  Next: Make hangs,  Prev: Unknown filetype,  Up: Trouble
  1949.  
  1950. 6.6 You can't use `QEMM' auto/off mode with DJGPP
  1951. =================================================
  1952.  
  1953. **Q*: Why do I get error message from `CWSDPMI' if I keep QEMM in auto/off
  1954. mode and run DJGPP?*
  1955.  
  1956. *A* :  When QEMM is in auto/off mode and there isn't anything in the system
  1957. that is using any of QEMM's features, the CPU remains in real mode.
  1958. Normally, when CWSDPMI finds the CPU in real mode, it will try to use raw XMS
  1959. services to access the extended memory.  Unfortunately, when some program
  1960. requests XMS services, it will cause QEMM to turn on.  So if CWSDPMI tries to
  1961. switch into protected mode, QEMM will trap it and give a protection violation
  1962. warning.  To avoid this unfortunate event (which requires a system reboot to
  1963. fix), CWSDPMI first checks to see if enabling XMS caused the CPU to switch
  1964. into v86 mode (meaning QEMM just turned on).  If so, CWSDPMI gracefully exits
  1965. after telling you it can't work in this set-up, like this:
  1966.  
  1967.       "Error: Using XMS switched the CPU into V86 mode."
  1968.  
  1969. All you have to do to work around this is force QEMM to be ON whenever you
  1970. run DJGPP programs so that CWSDPMI will know how to work with it properly.
  1971. To do this, just turn QEMM on before running any DJGPP program, with this
  1972. command:
  1973.  
  1974.       c:\qemm\qemm on
  1975.  
  1976. (that assumes your QEMM directory is `c:\qemm').
  1977.  
  1978. 
  1979. File: djgppfaq.info,  Node: Make hangs,  Next: Info can't find "Top",  Prev: QEMM AUTO,  Up: Trouble
  1980.  
  1981. 6.7 Compiler hangs, but only when invoked from Make
  1982. ===================================================
  1983.  
  1984. **Q*: My compiles run OK from the command line, but hang when I invoke the
  1985. compiler from Make.*
  1986.  
  1987. *A* :  Be sure you are invoking the correct Make program.  Borland Make was
  1988. reported to cause trouble when you invoke GCC with it (because Borland's
  1989. programs are 16-bit DPMI clients, and the DPMI 0.9 spec doesn't allow mixing
  1990. them with 32-bit DPMI clients such as DJGPP programs).  It might be that
  1991. another program called `make.exe' is found earlier on your `PATH' than the
  1992. Make which came with DJGPP.
  1993.  
  1994. If you use Make compiled under DJGPP v1.x, you will also experience all kinds
  1995. of trouble when invoking programs compiled under DJGPP v2.  That's because
  1996. v1.x programs cannot spawn v2 programs directly (the v1.x program sees that
  1997. the child is a DJGPP program and tries to call `go32' to run it, but v1's
  1998. `go32' cannot run v2 programs).  The result usually will be that the child
  1999. either crashes or silently exits.  If that's your problem, be sure to upgrade
  2000. your `Make' to the port distributed with v2. (Note that v2.x programs
  2001. generally know how to spawn both v1.x and v2.x programs.)  You can use
  2002. `go32-v2' to work around this limitation (*note description of go32-v2:
  2003. go32-v2., below), but I suggest doing that only if you absolutely cannot
  2004. upgrade to v2's `Make.'
  2005.  
  2006. Some users report that v1.x programs might sometimes hang or reboot the
  2007. machine when invoked from v2.0 Make, if the Makefile calls the v1.x program
  2008. by a name longer than the 8+3 DOS filename restriction (that is usual for
  2009. Makefiles that come from Unix).  To work around, truncate the filename of
  2010. that program in the Makefile.
  2011.  
  2012. 
  2013. File: djgppfaq.info,  Node: Info can't find "Top",  Next: General trouble,  Prev: Make hangs,  Up: Trouble
  2014.  
  2015. 6.8 Info doesn't like some files
  2016. ================================
  2017.  
  2018. **Q*: When I run the Info browser, it tells me it cannot find the node "Top".*
  2019.  
  2020. *A* :  Check your installation of info files.  The file `DJGPP.ENV' in the
  2021. root of your DJGPP installation mentions the variable `INFOPATH' which should
  2022. point to the directory where Info looks for its files.  It must find there a
  2023. file named `dir', the file you are trying to read, and other files with
  2024. `.iNN' or `.NN' extension, where `NN' is a number.
  2025.  
  2026. Assuming the above checks OK, and all the necessary info files are indeed
  2027. installed in those directories (did you remember to give that `-d' switch to
  2028. `PKUNZIP?'), it might be that some of the files were edited with a DOS-based
  2029. editor, which converted the <Newline> characters to the <CR>/<LF> pairs.
  2030. Some old DOS ports of Info don't like this, because this invalidates the tag
  2031. tables included with the files which Info uses to quickly find the various
  2032. nodes.
  2033.  
  2034. To solve the problem, upgrade to the latest versions of Info ported to DJGPP,
  2035. which don't have this problem (beginning with version 3.6).
  2036.  
  2037. If you cannot upgrade for some reason, run `DTOU.EXE' on the offending files;
  2038. it will strip the extra <CR> characters to make Info happy.  DTOU is in the
  2039. `bin/' subdirectory of your main DJGPP directory.
  2040.  
  2041. 
  2042. File: djgppfaq.info,  Node: General trouble,  Next: Redirect,  Prev: Info can't find "Top",  Up: Trouble
  2043.  
  2044. 6.9 My problem isn't mentioned above!
  2045. =====================================
  2046.  
  2047. **Q*: I've installed DJGPP just like explained in the `README.*' files, but
  2048. when I run gcc, my machine crashes/hangs/needs cold boot.*
  2049.  
  2050. **Q*: When I compile my program, gcc says "Segmentation violation" and prints
  2051. all kinds of funny numbers and registers.*
  2052.  
  2053. **Q*: I get errors I can't figure out when I try to compile something.*
  2054.  
  2055. *A* :  Add the `-v' switch to the GCC command line and run it again.  It will
  2056. print all the subprograms (compiler passes) it is running.  Then you can see
  2057. which subprogram caused the error, or where your machine crashes.  This might
  2058. give you a hint on what's wrong.
  2059.  
  2060. Another cause of such problems might be that your system is set up
  2061. inefficiently.  If GCC gets too few free RAM, it will run very slowly, and
  2062. you might think it crashed when in fact it didn't.  (This kind of problem
  2063. usually happens on memory-starved machines.)  Check out the *Note system
  2064. configuration advice: Config, in this FAQ list and configure your system
  2065. accordingly.
  2066.  
  2067. 
  2068. File: djgppfaq.info,  Node: Redirect,  Next: Deja vu,  Prev: General trouble,  Up: Trouble
  2069.  
  2070. 6.10 I can't keep up with the error messages
  2071. ============================================
  2072.  
  2073. **Q*: I want to read all the error messages that GCC throws at me, but there
  2074. are so many that I can't keep up.  How can I redirect them to a file?*
  2075.  
  2076. **Q*: When I add `-v' to the GCC command line, how can I put all the
  2077. voluminous output into a file, so I don't miss anything when reporting a
  2078. problem?*
  2079.  
  2080. **Q*: I have this nifty graphics program which bombs from time to time, but
  2081. the registers and traceback info are hidden by the graphics display.  How can
  2082. I see it?*
  2083.  
  2084. *A* :  Error messages are usually written to `stderr', and stock
  2085. `COMMAND.COM' cannot redirect it.  There are several alternatives to do that:
  2086.  
  2087.   a. You can use a shell smarter then `COMMAND.COM', such as `4DOS' or
  2088.      `bash', which knows how to redirect standard error stream to a file.
  2089.      4DOS is shareware and can be found on CCT mirrors, e.g.
  2090.      ftp://ftp.coast.net/Coast/msdos/4dos/, while `bash' is available from the
  2091.      DJGPP archives, e.g.
  2092.      ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bsh1147b.zip.
  2093.  
  2094.   b. You can also run your program under any one of the programs which save
  2095.      all screen output of programs they spawn in a file.  I suggest using a
  2096.      program called `SCRIPT', which is similar to its Unix namesake.  It has
  2097.      an advantage of saving everything which goes to screen *and* showing it
  2098.      on the screen at the same time.  You can find SCRIPT on CCT mirrors,
  2099.      e.g. ftp://ftp.coast.net/Coast/msdos/screen/script11.zip.
  2100.  
  2101.   c. Or you can use the `REDIR' program which comes with DJGPP.  It also
  2102.      redirects standard output and/or standard error to a file, but you don't
  2103.      get a chance to look at the output while the program runs.  Here's how
  2104.      to run GCC with `REDIR':
  2105.  
  2106.             redir -o gcc.log -eo gcc -v ...
  2107.  
  2108.      (put the rest of the GCC command line instead of the dots).  The
  2109.      messages printed by GCC will be written to the file `gcc.log'.
  2110.  
  2111.  
  2112. 
  2113. File: djgppfaq.info,  Node: Deja vu,  Next: Totally lost,  Prev: Redirect,  Up: Trouble
  2114.  
  2115. 6.11 How to search DJGPP archives for similar problems
  2116. ======================================================
  2117.  
  2118. **Q*: OK, I have all this voluminous output of `gcc -v', but I still have no
  2119. clue.*
  2120.  
  2121. *A* :  Your problem might be one which has already been posted and solved on
  2122. the DJGPP News group.  DJ Delorie <dj@delorie.com> has set up a searchable
  2123. News group archive on his Web server, at this URL:
  2124.  
  2125.      http://www.delorie.com/djgpp/mail-archives/
  2126.  
  2127. You can search the *entire* mailing list archives in just a few seconds.
  2128. DJ's archives are always up to date, as they receive and store all posted
  2129. messages automatically, but the index is updated every 24 hours, so the last
  2130. day might not be searchable yet.  To search the DJGPP archives, point your
  2131. Web browser to the above URL and specify a list of keywords pertinent to your
  2132. problem.  You will get a list of messages which include those keywords;
  2133. clicking on any of the messages will get the full text of that message.
  2134.  
  2135. 
  2136. File: djgppfaq.info,  Node: Totally lost,  Prev: Deja vu,  Up: Trouble
  2137.  
  2138. 6.12 How to ask DJGPP gurus for help
  2139. ====================================
  2140.  
  2141. **Q*: I've searched the news group archives, but didn't find anything
  2142. helpful.  I am totally lost.  *Help!!!**
  2143.  
  2144. **Q*: I don't have time to download all these messages, not to mention
  2145. looking through them.  Can't you DJGPP gurus help me?  *Please??**
  2146.  
  2147. *A* :  DJGPP News group is famous for its outstanding user support.  To get a
  2148. fast and effective solution to your problem, you will have to supply the
  2149. relevant info about your system, and describe exactly how things went wrong
  2150. for you.  To gather this info, do the following:
  2151.  
  2152.    * At the DOS command prompt, type `set > environ.lst', then press <Enter>.
  2153.  
  2154.    * Invoke the `go32-v2' program (it's in your `bin/' subdirectory) and save
  2155.      its output.
  2156.  
  2157.    * Post to the comp.os.msdos.djgpp news group or write to the DJGPP mailing
  2158.      list <djgpp@delorie.com> and put into your message the description of
  2159.      your calamity, the contents of the file `ENVIRON.LST', the output of
  2160.      `go32-v2', the contents of your `AUTOEXEC.BAT' and `CONFIG.SYS', and
  2161.      what GCC printed during compilation with the `-v' switch (if your
  2162.      problem is that GCC won't work).
  2163.  
  2164.    * If your problem involves a program that crashes and prints a stack dump,
  2165.      please post that stack dump.  It's best to run `symify' on the stack
  2166.      dump, and post the output of `symify':
  2167.  
  2168.             symify -o dumpfile yourprog
  2169.  
  2170.      (*Note detailed description of symify: Crash traceback, for more details
  2171.      about `symify.')
  2172.  
  2173.    * Allow for 2-3 days (more on weekends) for all the reply messages to come
  2174.      in, then act according to what they recommend.
  2175.  
  2176. Be warned that you might get several dozen messages in reply to your request;
  2177. this is not meant to overflow your mailbox or sabotage your relationship with
  2178. your system manager, it's just the usual friendly response of fellow
  2179. DJGPP'ers to your lonely cry for help.  Some of the replies might suggest
  2180. what you already checked and reported in your original message, or even miss
  2181. the point altogether.  Be ready for this and don't flame us for trying to
  2182. help you as much as we can.
  2183.  
  2184. 
  2185. File: djgppfaq.info,  Node: Compiler performance,  Next: Compiling,  Prev: Trouble,  Up: Top
  2186.  
  2187. 7. Compiler and Linker Performance
  2188. **********************************
  2189.  
  2190.   This chapter deals with speed of compilation and linking under DJGPP, and how
  2191. they could be improved.
  2192.  
  2193.   If you already know whether the compiler or the linker is the slow part, go
  2194. to the appropriate section; if not, add `-v' to your GCC command line and run
  2195. it again.  With the `-v' switch, GCC will print all the programs it invokes,
  2196. and you will be able to tell which one is taking most of the time.
  2197.  
  2198. * Menu:
  2199.  
  2200. * Slow compiler::               Are your compiles slow?
  2201. * Slow linker::                 How to boost the linking speed.
  2202.  
  2203. 
  2204. File: djgppfaq.info,  Node: Slow compiler,  Next: Slow linker,  Prev: Compiler performance,  Up: Compiler performance
  2205.  
  2206. 7.1 Slow Compilation
  2207. ====================
  2208.  
  2209. **Q*: Why GCC is compiling sooo slooowww?*
  2210.  
  2211. *A* :  That depends on what you mean by "slow".  The following table gives
  2212. "normal" gcc compilation speed, in source lines per second, on a 486DX2-66:
  2213.  
  2214.                  |  Without optimization  |  With -O2
  2215.       -----------+------------------------+------------
  2216.       C++ source |        200             |   100
  2217.       -----------+------------------------+------------
  2218.       C   source |        430             |   250
  2219.  
  2220. (Btw, these numbers are about 20% faster than you will get on a 40MHz Sparc2
  2221. box.)  On machines faster or slower than 486DX2-66, scale these numbers
  2222. accordingly.  When comparing to this table, don't forget to count header
  2223. files your program `#include's' in the total line count.  And *don't* check
  2224. compilation speed on very short programs (like the classic `"Hello,
  2225. world!"'), because the overhead of loading the multiple passes of the
  2226. compiler will completely hide the compiler performance.
  2227.  
  2228. If your results are close to these (deviations of a few percent are
  2229. considered "close" here), then that's as fast as you can get with GCC.  If
  2230. they are *significantly* lower, you may indeed have a problem; read on.
  2231.  
  2232. First, check to see if GCC pages to disk when it compiles.  This is
  2233. manifested by a heavy disk traffic which won't go away even if you have a
  2234. large write-back disk cache installed.  To be sure, disable the virtual
  2235. memory services for your DPMI host (for `CWSDPMI', use the `CWSDPR0' as your
  2236. DPMI host, or use the `CWSPARAM' program to point the swap file to a
  2237. non-existent drive), or use `PMODE/DJ' as the DPMI host, then run the
  2238. compilation again; if the compiler aborts with an error message saying there
  2239. isn't enough memory, then it *was* paging in your original environment.
  2240.  
  2241. If paging does happen, you need to free more extended memory.  If you have a
  2242. RAM disk, make it smaller, or don't use it at all (it only makes compiles run
  2243. about 10% faster), or make your disk cache smaller (but don't discard the
  2244. disk cache altogether); if you have other programs which use extended RAM,
  2245. make them use less of it.  Failing all of the above, buy more RAM (*note the
  2246. description of reasonable configuration: Reasonable hardware.).  Also see
  2247. *Note recommendations for optimal software configuration: Config.
  2248.  
  2249. If GCC doesn't page, check the settings of your disk cache.  If you don't use
  2250. a cache, install one--this can slash your compilation times by as much as
  2251. 30%, more so when compiling a large number of small files.  If you already
  2252. have a cache, enable its delayed-write (aka write-back, aka staggered-write)
  2253. operation.  Some people disable the delayed-write feature for safety reasons,
  2254. to avoid losing files due to system crashes.  If you are worried about this,
  2255. you can usually gain performance without sacrificing safety by enabling
  2256. delayed-write together with an option that causes the cache to flush the
  2257. write-behind data before the system returns to the DOS prompt.  (For
  2258. `SmartDrv' disk cache, this is achieved by specifying `/N/F' switches instead
  2259. of `/X'.)  GCC usually gains a lot when you set up your cache in such a way,
  2260. because each compiler pass (pre-processor, compiler, assembler) must write
  2261. temporary files that are used by the following passes.
  2262.  
  2263. If you had some of the beta releases of v2.0 installed during the
  2264. beta-testing period, be sure to upgrade your `CWSDPMI' to the latest version.
  2265. The memory allocation scheme has been changed halfway through the
  2266. beta-testing, which made old versions of `CWSDPMI' *awfully* slow when used
  2267. with programs linked against the new versions of the library.
  2268.  
  2269. It is also worthwhile to check the settings of your system BIOS.  In
  2270. particular, the following items should be checked against your motherboard
  2271. vendor recommendations:
  2272.  
  2273.      Internal and external CPU cache....set to Enable
  2274.      CPU cache scheme...................set to Write-back, if possible
  2275.      DRAM and SRAM wait states..........vendor-recommended optimal values
  2276.  
  2277. Incorrect or suboptimal settings of the above items can explain as much as
  2278. 30% performance degradation on 486 machines, and as much as 500% (!) if you
  2279. have a Pentium CPU.
  2280.  
  2281. DJ Delorie <dj@delorie.com> reports that his well-tuned 166 MHz Pentium
  2282. system with 32 MBytes of RAM and 4 MBytes of RAM disk compiles the entire GCC
  2283. source in under 10 minutes (this takes about 45 minutes on a 40MHz Sparc2).
  2284.  
  2285. 
  2286. File: djgppfaq.info,  Node: Slow linker,  Prev: Slow compiler,  Up: Compiler performance
  2287.  
  2288. 7.2 Slow Linking
  2289. ================
  2290.  
  2291. **Q*: The compiler finishes in a few seconds, but then the linker grinds away
  2292. for more than a minute, even on a very short program...*
  2293.  
  2294. *A* :  Try linking the trivial `"Hello, world!"' program; it should take no
  2295. more than 7-10 seconds on a 486, 3-5 seconds on a Pentium.  If you see much
  2296. slower linking on your system, then the following advice might help you.
  2297.  
  2298. A few users have reported that they got much faster linking after they've
  2299. stub-edited `ld.exe' to change the transfer buffer size to 64KB.  This
  2300. speedup effect is usually seen when DJGPP is installed on a networked drive,
  2301. or on a compressed disk; when DJGPP is installed on a local disk drive,
  2302. linking speed is not affected by the size of transfer buffer.
  2303.  
  2304. If you use a disk cache, make sure you enable its write-back (aka
  2305. delayed-write) operation.  Some people disable the delayed-write feature for
  2306. safety reasons, to avoid losing files due to system crashes.  If you are
  2307. worried about this, you can usually gain performance without sacrificing
  2308. safety by enabling delayed-write together with an option that causes the
  2309. cache to flush the write-behind data before the system returns to the DOS
  2310. prompt.  For `SmartDrv' disk cache, this is achieved by specifying `/N/F'
  2311. switches instead of `/X'.
  2312.  
  2313. For very large (several MBytes) executables which are built from a large
  2314. number of small source files, the link (as opposed to the compilation) stage
  2315. might be the one which needs more RAM than you have free, and thus be the
  2316. bottleneck of the time it takes to build your program.  Check that the size
  2317. of the executable isn't larger than the amount of your free RAM.  If it is,
  2318. then it might make sense to use a smaller (or even no) disk cache, and allow
  2319. the linker as much physical RAM as it needs.  Make sure that the linker
  2320. wasn't stub-edited to make its transfer buffer too small.
  2321.  
  2322. Another reason for slow linking might be that the `DJGPP.ENV' file by default
  2323. sets `TMPDIR' to a `tmp/' subdirectory of the main DJGPP installation
  2324. directory; if DJGPP is installed on a networked drive, this means all your
  2325. temporary files go back and forth through the network (and networked disks
  2326. are usually not cached on your PC).  In such cases, setting `TMPDIR' to a
  2327. directory on your local drive, or to a RAM disk, would probably make linking
  2328. faster.
  2329.  
  2330. 
  2331. File: djgppfaq.info,  Node: Compiling,  Next: Running,  Prev: Compiler performance,  Up: Top
  2332.  
  2333. 8. Compile-time and Link-time Problems
  2334. **************************************
  2335.  
  2336.   Being of a Unix origin, GCC has a somewhat different flavor of command-line
  2337. syntax and its peculiar compilation and link algorithms.  It also has a
  2338. plethora of optional switches, some of them obscure or semi-documented.
  2339. These are known to confuse users, especially those who had previous
  2340. experience with DOS-based C compilers.
  2341.  
  2342.   This chapter explains how to solve some of those problems which tend to
  2343. appear when compiling and linking your programs.
  2344.  
  2345. * Menu:
  2346.  
  2347. * Missing headers/libraries::  GCC can't find header files/libraries.
  2348. * Missing C++ headers::        GCC can't find C++ header files.
  2349. * C++ comments::               Avoid C++ comments in C programs.
  2350. * Which language::             GCC resolves it by looking at filename
  2351.                                  extensions.
  2352. * Objective C::                Can't use ObjC 2.6.0.
  2353. * DJGPP-specific::             How to write DJGPP-specific fragments.
  2354. * Unresolved externals::       Where are those library functions?
  2355. * Which library::              Which library has which functions?
  2356. * Libraries' order::           Which libraries to put first?
  2357. * Still unresolved::           C++ misses complex and iostream functions.
  2358. * Class Complex::              It is now a complex template class.
  2359. * Pure virtual::           Problems with pure virtual functions in C++.
  2360. * djgpp_first_ctor::           Why are these unresolved?
  2361. * Large image::                Static arrays bloat C++ program image.
  2362. * Large executable::           Why is DJGPP .EXE so large?
  2363. * Linker script::              Problems with it can cause linker to fail.
  2364. * No EXE::                     Novell Netware fails STUBIFY.
  2365. * Large object files::         Linker fails for large objects/libraries.
  2366. * Allegro::                    Problems building Allegro library.
  2367.  
  2368. 
  2369. File: djgppfaq.info,  Node: Missing headers/libraries,  Next: Missing C++ headers,  Prev: Compiling,  Up: Compiling
  2370.  
  2371. 8.1 GCC can't find headers or libraries
  2372. =======================================
  2373.  
  2374. **Q*: When I run the compiler it says it couldn't find header files and/or
  2375. libraries.  But the headers and libraries are all there, so why won't it find
  2376. them?*
  2377.  
  2378. **Q*: When I link my programs, ld.exe complains that it cannot open crt0.o,
  2379. although that file exists in the lib subdirectory...*
  2380.  
  2381. *A* :  In order for the compiler to find its include files, libraries and
  2382. other stuff it can't do without, you should have the following variable set
  2383. in your environment:
  2384.  
  2385.       set DJGPP=c:/djgpp/djgpp.env
  2386.  
  2387. and it should point to the correct path of the file `DJGPP.ENV' on your
  2388. system (the file itself comes with the file djdev201.zip, e.g.
  2389. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/djdev201.zip in the DJGPP
  2390. distribution).  In the above example it is assumed to be in the `C:/DJGPP'
  2391. directory, but you should set it as appropriate for your installation.
  2392.  
  2393. Sometimes, people make errors in their `AUTOEXEC.BAT' that cause the DJGPP
  2394. variable to be defined incorrectly, or not defined at all (some of the more
  2395. common errors are listed below).  To check what is the actual setting, type
  2396. from the DOS prompt:
  2397.  
  2398.       set > env.lst
  2399.  
  2400. then examine the contents of the file `env.lst'.  You should see there a line
  2401. like this:
  2402.  
  2403.       DJGPP=c:/djgpp/djgpp.env
  2404.  
  2405. If a line such as this isn't there, you should investigate the cause for this
  2406. (see below for some of the possibilities).
  2407.  
  2408. Many problems with setting DJGPP happen when people put excess blanks around
  2409. the `=' character, which has the effect of defining "DJGPP " (with the blank)
  2410. which is not the same as "DJGPP" (without blanks).  You should make sure
  2411. there are no such excess blanks, or DJGPP won't find its files.
  2412.  
  2413. Another possible cause of DJGPP variable not being set is that you invoke
  2414. another batch file from your `AUTOEXEC.BAT' before the line that sets DJGPP.
  2415. Make sure such batch files are invoked with the `CALL' statement, because
  2416. otherwise the subsidiary batch file will never return to process the rest of
  2417. `AUTOEXEC.BAT' (that's a "feature" of DOS batch file processing).
  2418.  
  2419. The code that processes `DJGPP.ENV' assumes that this file resides in the
  2420. main DJGPP installation directory.  If that assumption is wrong, the compiler
  2421. (and some other DJGPP programs) might fail to find some of the files or
  2422. auxiliary programs they need.  *Do NOT move DJGPP.ENV to any other directory!*
  2423.  
  2424. Note that if you run DJGPP under Win95, WinNT or any other environment that
  2425. supports long filenames (e.g., if DJGPP is installed on a networked drive
  2426. whose network redirector supports long filenames), you *cannot* use long
  2427. names of the directories in the pathname of `DJGPP.ENV' when you set the
  2428. above variable in the environment; you should use their 8+3 aliases instead.
  2429. First, some of these systems (such as WinNT) do not even support the LFN API
  2430. for DOS programs.  But even if LFN API *is* supported, e.g. on Win95, DJGPP
  2431. won't know that it should support LFN until *after* it read `DJGPP.ENV'--it's
  2432. a chicken-and-egg problem.  For example, the following setting *won't work*
  2433. because `Development' is longer than 8 characters:
  2434.  
  2435.       set DJGPP=c:/Programs/Development/Djgpp/djgpp.env
  2436.  
  2437. If the DJGPP variable is set correctly, then check the following possible
  2438. causes of this misbehavior:
  2439.  
  2440.    * You have edited the file `DJGPP.ENV' in a way that invalidated some of
  2441.      the settings there; try restoring the original file from the
  2442.      distribution to see if that fixes your problems.  Be sure you are
  2443.      familiar with the syntax of `DJGPP.ENV' before you edit it.  The DJGPP
  2444.      server has a page with a description of the `DJGPP.ENV' syntax, at this
  2445.      URL:
  2446.  
  2447.           http://www.delorie.com/djgpp/doc/kb/kb_7.html#SEC7
  2448.  
  2449.      The syntax of `DJGPP.ENV' is also described in the DJGPP Knowledge Base,
  2450.      *Note (kb.inf)DJGPP.ENV::, which comes with the `djdev' distribution.
  2451.  
  2452.    * Some older versions of Novell Netware cause the linker to fail if the
  2453.      libraries or the startup file `crt0.o' reside on a networked drive.
  2454.      This is due to a peculiarity of Novell that happens to fail the library
  2455.      function `stat' in some cases.  The exact reason of the failure has been
  2456.      identified, and the library which comes with DJGPP v2.01 includes a
  2457.      version of `stat' that works around that problem, so the linker from
  2458.      v2.01 is free of this bug, and upgrading will solve this.  Another
  2459.      solution would be to upgrade your Novell software; version 4.x is
  2460.      reportedly free of this problem, even if you use DJGPP v2.0.
  2461.  
  2462.    * You renamed the `gcc.exe' driver to some other name.  In this case, you
  2463.      should edit the file `DJGPP.ENV' to add a section named after the new
  2464.      name of GCC, which is an exact duplicate of the section called `[gcc].'
  2465.      DJGPP start-up code uses this file to find environment variables which
  2466.      it should put into the environment before the `main' function is called,
  2467.      but it searches for the relevant variables using the actual name of the
  2468.      program, so when you rename the executable, it can't find its section
  2469.      and doesn't put the necessary variables into the environment.
  2470.  
  2471.    * Your `FILES=' setting in `CONFIG.SYS' is insufficient, so GCC runs out
  2472.      of available handles.
  2473.  
  2474.      You should have at least `FILE=15' in your `CONFIG.SYS.'
  2475.  
  2476.    * Your DJGPP directory is on a networked drive, and the network redirector
  2477.      doesn't have enough available handles in its configuration.
  2478.  
  2479.      Presumably, there should be a parameter in some configuration file or a
  2480.      command-line argument to one of the network drivers which sets the number
  2481.      of files that can be open simultaneously on a networked drive; you should
  2482.      set it to be at least 15.
  2483.  
  2484.    * You passed the `-B' switch to GCC.  This overrides the default location
  2485.      of `crt0.o' and if you follow `-B' with a directory other than that
  2486.      where `crt0.o' resides, the linker won't find it.
  2487.  
  2488.      You should not need to use the `-B' or `-L' switches at all if your
  2489.      installation is correct and the `DJGPP' variable points to the main
  2490.      installation directory, because GCC should be able to figure out all the
  2491.      linker switches itself.  If linking fails without explicit `-L' or `-B',
  2492.      check out above for the possible causes.
  2493.  
  2494. 
  2495. File: djgppfaq.info,  Node: Missing C++ headers,  Next: C++ comments,  Prev: Missing headers/libraries,  Up: Compiling
  2496.  
  2497. 8.2 GCC can't find C++ headers
  2498. ==============================
  2499.  
  2500. **Q*: I installed all the packages, but GCC complains it can't find
  2501. `iostream.h', `_string.h' and other C++ headers.  Where can I find those
  2502. header files?*
  2503.  
  2504. **Q*: GCC complains about being unable to find `Complex.h', `Regex.h' and
  2505. other header files which start with a capital letter, and I indeed don't see
  2506. them in my `lang/cxx/' directory.  Where are they?*
  2507.  
  2508. **Q*: My C++ program needs header files whose filenames exceed the 8+3 DOS
  2509. filename restrictions, like `stdiostream.h' and `streambuf.h', and GCC cannot
  2510. find those files.  How in the world can I write portable C++ programs??*
  2511.  
  2512. *A* :  C++ include files are in the file lgp271b.zip, e.g.
  2513. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/lgp271b.zip, so if you
  2514. didn't install it, GCC won't find them.  Files whose names usually start with
  2515. a capital letter, on MS-DOS have an underscore `_' prepended so they can be
  2516. distinguished from `complex.h', `regex.h' and the like under case-insensitive
  2517. DOS.  Change `Complex.h' to `_complex.h' in your source, and GCC will find
  2518. them.
  2519.  
  2520. Another possible cause for problems with C++ include files is that your
  2521. source file has a `.c' extension.  GCC then thinks that this is a C program
  2522. and doesn't instruct the preprocessor to search the include directories
  2523. specific to C++.  Rename your file to `.cc' or `.cpp' extension, or call GCC
  2524. with the `-x c++' switch, and the header files will be found.  A full list of
  2525. extension rules which GCC uses to determine the source language can be found
  2526. in the *Note list of language-specific suffixes: Which language, elsewhere in
  2527. this FAQ.
  2528.  
  2529. If you have problems with header files with long filenames, and you run under
  2530. Win95 or some other environment which allows for long filenames, try
  2531. disabling the "Long File Names" (LFN) support in DJGPP, by setting the `LFN'
  2532. environment variable to `No', like this:
  2533.  
  2534.        set LFN=n
  2535.  
  2536. (DJGPP comes with LFN disabled by default on the `DJGPP.ENV' file, but you
  2537. might have enabled it.)  If this makes the problems go away, then you have
  2538. some conflict between the way LFN is supported by DJGPP and your environment.
  2539. Under Win95, you must rename the files which should have long filenames to
  2540. those long names (as opposed to the truncated names you find in the DJGPP
  2541. archives).  You must also set the option in the Win95 registry which disables
  2542. name-munging of the files which have exactly 8 characters in their name part.
  2543. This is how:
  2544.  
  2545.    * From the "Start" menu select "Run" and type `regedit', to start the
  2546.      Registry Editor.
  2547.  
  2548.    * Expand the `HKEY_LOCAL_MACHINE' branch of the registry until you see in
  2549.      the left pane an item called
  2550.      `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem', then
  2551.      click on it.
  2552.  
  2553.    * The right pane now shows the list of values assigned to the `FileSystem'
  2554.      key.  If you don't see an item there called `NameNumericTail', select
  2555.      "New", "Binary Value" from the "Edit" menu, then type `NameNumericTail'
  2556.      and it will appear.  Now double-click on `NameNumericTail' and enter a
  2557.      value of 0.
  2558.  
  2559.    * Restart Windows 95.
  2560.  
  2561. If the `NameNumericTail' set to 0 breaks some programs, you can restore its
  2562. original setting after you've renamed the files as described above.
  2563. `NameNumericTail' only affects the short names of new files being created, it
  2564. has no effect on the files that already exist.
  2565.  
  2566. 
  2567. File: djgppfaq.info,  Node: C++ comments,  Next: Which language,  Prev: Missing C++ headers,  Up: Compiling
  2568.  
  2569. 8.3 GCC barfs on C++-style comments in C programs
  2570. =================================================
  2571.  
  2572. **Q*: My C program compiles OK with Borland's C, but GCC complains about
  2573. "parse error before `/' " at a line where I have a "//"-style comment.*
  2574.  
  2575. *A* :  That's because // isn't a comment neither in ANSI C nor in K&R C.
  2576. Borland and Microsoft C compilers support it as an extension.  GCC also
  2577. supports this extension (beginning with version 2.7.0), but using the `-ansi'
  2578. or `-traditional' switches to GCC disables this extension.  In general, it's
  2579. a bad practice to use this extension in a portable program until such time as
  2580. the ANSI C standard includes it.  If it's a C++ program, then rename it to
  2581. have a suffix which will cause gcc to compile it as such (*note list of
  2582. language-specific suffixes: Which language.), or use `-x c++' switch.  If
  2583. it's a C program, but you want to compile it as C++ anyway, try `-x c++'; it
  2584. can help, but can also get you in more trouble, because C++ has its own
  2585. rules.  For example, the following program will print 10 if compiled as a C
  2586. program, but 5 if compiled as C++:
  2587.  
  2588.          #include <stdio.h>
  2589.      
  2590.          int
  2591.          main ()
  2592.          {
  2593.            printf ("%d \n" 10    //*
  2594.                   / 2    //*/
  2595.                     1
  2596.                     );
  2597.            return 0;
  2598.          }
  2599.  
  2600. (While admittedly perverse, this little monstrosity was written with the sole
  2601. purpose of demonstrating that C and C++ have quite different semantics under
  2602. certain circumstances.)
  2603.  
  2604. If you must have both `-ansi' and C++-style comments, you can use the
  2605. `-lang-c-c++-comments' preprocessor switch.  Gcc doesn't accept the
  2606. `-lang-XXX' switches on its command line, so you will have to use the `-Wp'
  2607. option, like this:
  2608.  
  2609.       gcc -c -Wp,-lang-c-c++-comments myprog.c
  2610.  
  2611. Alternatively, you can add `-lang-c-c++-comments' to the `*cpp:' section of
  2612. your `lib/specs' file (but that will make it permanent).
  2613.  
  2614. Bottom line: until the future ANSI/ISO C standard includes this as part of
  2615. the C language, it's best to change those comments to C-style ones, if you
  2616. really mean to write a C program.  The following `Sed' command will convert a
  2617. C program with C++-style comments into a valid C source, provided you don't
  2618. have the string "//" in a character string:
  2619.  
  2620.       sed "s?//\(.*\)?/*\1 */?" file.c > newfile.c
  2621.  
  2622. Sed can be found in the DJGPP distribution, e.g.
  2623. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/sed118b.zip.
  2624.  
  2625. 
  2626. File: djgppfaq.info,  Node: Which language,  Next: Objective C,  Prev: C++ comments,  Up: Compiling
  2627.  
  2628. 8.4 How does GCC recognize the source language?
  2629. ===============================================
  2630.  
  2631. **Q*: I type `GCC PROG.CC' and GCC complains that it can't recognize
  2632. `PROG.CC''s file format.  How come a C++ compiler doesn't recognize a C++
  2633. source??*
  2634.  
  2635. **Q*: I type `GCC PROG.C' to compile a C program which I already remember to
  2636. pass compilation without a single warning, and suddenly it gives all kinds of
  2637. strange error messages and unresolved externals.*
  2638.  
  2639. *A* :  That's because you typed your source file extension in *upper* case.
  2640. GCC is *not* case-insensitive about filenames like DOS is, and it uses the
  2641. file's extension to determine how to compile a file.  Valid extensions are:
  2642.  
  2643. `.cc'
  2644. `.C'
  2645. `.cxx'
  2646. `.cpp'
  2647.      C++ source (passed through cpp).
  2648.  
  2649. `.c'
  2650.      C source that must be passed through cpp first.
  2651.  
  2652. `.i'
  2653.      Raw C source (no cpp pass).
  2654.  
  2655. `.ii'
  2656.      Raw C++ source (not to be preprocessed).
  2657.  
  2658. `.m'
  2659.      Objective-C source.
  2660.  
  2661. `.S'
  2662.      Assembler that must be passed through cpp first.
  2663.  
  2664. `.s'
  2665.      Raw assembler source (no cpp pass).
  2666.  
  2667. Any other file is passed to the linker, under the assumption that it's an
  2668. object file.
  2669.  
  2670. In the examples above, `PROG.C' is taken as a C++ program, not a C one, and
  2671. `PROG.CC' is passed to the linker as if it were an object file.  You can see
  2672. what GCC does by adding the `-v' switch to the GCC command line; if you see
  2673. that it's invoking `cc1plus.exe' (the C++ compiler) instead of `cc1.exe' (the
  2674. C compiler), or calling `ld.exe' (the linker) on a source file, then you'd
  2675. know this is your problem.  If you have problems keeping up with the verbose
  2676. GCC output caused by `-v', see *Note how to capture GCC output: Redirect, in
  2677. this FAQ.
  2678.  
  2679. You can override the default rules gcc uses to decide how each input file
  2680. should be treated, with the help of the `-x LANGUAGE' switch.  For instance,
  2681. the command
  2682.  
  2683.       gcc -x c++ prog.c
  2684.  
  2685. compiles `prog.c' as C++ source.  *Note -x LANGUAGE switch description:
  2686. (gcc)Overall Options, for more info on `-x' options.
  2687.  
  2688. 
  2689. File: djgppfaq.info,  Node: Objective C,  Next: DJGPP-specific,  Prev: Which language,  Up: Compiling
  2690.  
  2691. 8.5 Problems with Objective C
  2692. =============================
  2693.  
  2694. **Q*: How do I tell gcc my .cc file is to be compiled as Objective-C source?*
  2695.  
  2696. **Q*: I compile an Objective-C program, but get unresolved symbols.*
  2697.  
  2698. **Q*: I can't compile the Objective-C test program which came with DJGPP.*
  2699.  
  2700. *A* :  Give your sources the `.m' extension, or use `-x objective-c' switch
  2701. to GCC, so it will *know* you mean to compile with Objective C.
  2702.  
  2703. Objective-C was broken in GCC 2.6.0.  The problem manifests itself by
  2704. unresolved modules.  If you use that version, you'll have to upgrade to
  2705. version 2.6.3 or higher.
  2706.  
  2707. 
  2708. File: djgppfaq.info,  Node: DJGPP-specific,  Next: Unresolved externals,  Prev: Objective C,  Up: Compiling
  2709.  
  2710. 8.6 Writing codes fragments which are specific to DJGPP
  2711. =======================================================
  2712.  
  2713. **Q*: I must put a DJGPP-specific code fragment into my program.  What symbol
  2714. should I use in the `#ifdef' directive to make it only visible under DJGPP?*
  2715.  
  2716. *A* :  Use `__DJGPP__', like this:
  2717.  
  2718.          #ifdef __DJGPP__
  2719.          ... DJGPP-specific code ...
  2720.          #else
  2721.          ... not seen under DJGPP ...
  2722.          #endif
  2723.  
  2724. `__DJGPP__' has the value of the DJGPP major revision number, so you can
  2725. write code fragments which have different behavior under different versions
  2726. of DJGPP:
  2727.  
  2728.          #ifdef __DJGPP__
  2729.          #if __DJGPP__ > 2
  2730.          .... will work only in DJGPP v3.x and later ...
  2731.          #else
  2732.          .... get here for DJGPP v2.x ...
  2733.          #endif
  2734.          #else
  2735.          .... get here in DJGPP v1.x or non-DJGPP environment
  2736.          #endif
  2737.  
  2738. Another DJGPP-specific pre-processor symbol which DJGPP defines is
  2739. `__GO32__'; but it is only provided for compatibility with previous versions
  2740. of DJGPP (v1.x) and its use should be discouraged.
  2741.  
  2742. 
  2743. File: djgppfaq.info,  Node: Unresolved externals,  Next: Which library,  Prev: DJGPP-specific,  Up: Compiling
  2744.  
  2745. 8.7 Unresolved externals when linking programs
  2746. ==============================================
  2747.  
  2748. **Q*: Why do I get so many unresolved symbols when linking my programs?*
  2749.  
  2750. *A* :  By default, GCC instructs the linker to only look in two libraries:
  2751. `libgcc.a' and `libc.a.'  Some functions aren't included there, so the linker
  2752. can't find them.  If you need to link against some optional library, say
  2753. `libxy.a', put the library into the DJGPP `lib/' subdirectory and append a
  2754. `-lxy' to the link command line.  To use C++ classes in the `libgpp.a' (it's
  2755. called `libg++.a' on Unix systems), append `-lgpp.'  The Standard C++
  2756. Template classes are in `libstdcx.a' (it's called `libstdc++.a' on Unix);
  2757. append `-lstdcxx.'
  2758.  
  2759. When linking C++ programs, you can use the `gxx' command instead of `gcc'; it
  2760. will then instruct the linker to also scan the C++ libraries automatically,
  2761. so you don't have to remember doing that yourself.
  2762.  
  2763. Note that the first release of DJGPP v2.0 didn't include `gxx.exe' and the
  2764. C++ STL library `libstdcx.a.'  If you cannot find them on your machine,
  2765. download the latest `gcc272b.zip' and `lgp271b.zip' archives that are dated
  2766. 22-Feb-96 or later, or upgrade to DJGPP v2.01.
  2767.  
  2768. If your program uses a lot of floating-point math, or needs math functions
  2769. beyond those specified in the ANSI/ISO standard, consider appending `-lm' to
  2770. your link command line.  The basic math functions required by ANSI/ISO
  2771. standard are included in the `libc.a' library, but `libm.a' includes higher
  2772. quality versions of these functions, and also some functions not included in
  2773. the default library, like Gamma function and Bessel functions.
  2774.  
  2775. 
  2776. File: djgppfaq.info,  Node: Which library,  Next: Libraries' order,  Prev: Unresolved externals,  Up: Compiling
  2777.  
  2778. 8.8 How not to lose your head with all these libraries
  2779. ======================================================
  2780.  
  2781. **Q*: I'm lost with all those different libraries.  How in the world can I
  2782. find out which functions are included in which library?*
  2783.  
  2784. *A* :  You can use the `nm' program to check what functions are included in a
  2785. library.  Run it with the `-C' option and with the library as its argument
  2786. and look in the output for the name of your function (the `-C', or
  2787. `--demangle' option makes the function names look closer to what they are
  2788. called in the source file).  Functions which have their code included in the
  2789. library have a capital `T' before their name.  For example, the following is
  2790. a fragment from the listing produced by `nm':
  2791.  
  2792.          c:\djgpp\lib> nm --demangle libc.a
  2793.          .
  2794.          .
  2795.          .
  2796.          stdio.o:
  2797.          000000e4 b .bss
  2798.          000000e4 d .data
  2799.          00000000 t .text
  2800.          00000098 t L12
  2801.          0000001e t L3
  2802.          00000042 t L6
  2803.          0000004d t L7
  2804.          0000006a t L9
  2805.          00000000 t __gnu_compiled_c
  2806.               U _filbuf
  2807.               U _flsbuf
  2808.          00000000 T clearerr
  2809.          000000ac T feof
  2810.          000000c2 T ferror
  2811.          000000d8 T fileno
  2812.          0000000c T getc
  2813.          00000052 T getchar
  2814.          0000002a T putc
  2815.          0000007c T putchar
  2816.          00000000 t gcc2_compiled.
  2817.          .
  2818.          .
  2819.          .
  2820.  
  2821. Here we see that the module `stdio.o' defines the functions `clearerr',
  2822. `feof', `ferror', `fileno', `getc', `getchar', `putc' and `putchar', and
  2823. calls functions `_filbuf' and `_flsbuf' which aren't defined on this module.
  2824.  
  2825. Alternatively, you can call `nm' with the `-s' or `--print-armap', which will
  2826. print an index of what symbols are included in what modules.  For instance,
  2827. for `libc.a', we will see:
  2828.  
  2829.          c:\djgpp\lib> nm --print-armap libc.a
  2830.          .
  2831.          .
  2832.          .
  2833.          _feof in stdio.o
  2834.          _ferror in stdio.o
  2835.          _fileno in stdio.o
  2836.          .
  2837.          .
  2838.          .
  2839.  
  2840. which tells us that the functions `feof', `ferror' and `fileno' are defined
  2841. in the module `stdio.o.'
  2842.  
  2843. `nm' is fully described in the GNU docs. *Note the Binutils package docs:
  2844. (binutils)nm.
  2845.  
  2846. 
  2847. File: djgppfaq.info,  Node: Libraries' order,  Next: Still unresolved,  Prev: Which library,  Up: Compiling
  2848.  
  2849. 8.9 DJGPP uses a one-pass linker
  2850. ================================
  2851.  
  2852. **Q*: I give all the libraries to gcc, but I still get unresolved externals
  2853. when I link.  What gives?*
  2854.  
  2855. *A* :  `Ld' is a one-pass linker:  it only scans each library once looking
  2856. for unresolved externals it saw *until that point*.  This means the relative
  2857. position of object files and libraries' names on the command line is
  2858. significant.  You should put all the libraries *after* all the object files,
  2859. and in this order:
  2860.  
  2861.       -lgpp -lstdcxx -lm
  2862.  
  2863. E.g., to link files main.o and sub.o into a C++ library, use the following
  2864. command line:
  2865.  
  2866.       gcc -o main.exe main.o sub.o -lgpp -lstdcxx
  2867.  
  2868. or, if you compile and link in one command:
  2869.  
  2870.       gcc -o main.exe main.cc sub.cc -lgpp -lstdcxx -lm
  2871.  
  2872. If you have any libraries of your own, put them *before* the above system
  2873. libraries, like this:
  2874.  
  2875.       gcc -o main.exe main.cc sub.cc -lmylib -lgpp -lstdcxx -lm
  2876.  
  2877. When you use the `gxx' compilation driver to compile a C++ program, it names
  2878. the C++ libraries in the correct order.
  2879.  
  2880. If your installation tree is different from the default, i.e., if you keep
  2881. the libraries *not* in the default `lib/' subdirectory, then you should add
  2882. that directory to the line in the `[gcc]' section of your `DJGPP.ENV' file
  2883. which starts with `LIBRARY_PATH', or put into your environment a variable
  2884. called `LIBRARY_PATH' and point it to the directory where you keep the
  2885. libraries.  Note that if you invoke the linker by itself (not through the gcc
  2886. driver), then `LIBRARY_PATH' will have no effect, because this variable is
  2887. only known to the gcc driver.  So if you must call `ld' directly, use the
  2888. `-L' option to tell it where to look for the libraries.
  2889.  
  2890. 
  2891. File: djgppfaq.info,  Node: Still unresolved,  Next: Class Complex,  Prev: Libraries' order,  Up: Compiling
  2892.  
  2893. 8.10 C++ functions still not found
  2894. ==================================
  2895.  
  2896. **Q*: I put all the libraries in the above order, but the linker still can't
  2897. find some C++ functions from `complex.h' and `iostream.h.'*
  2898.  
  2899. *A* :  These functions are declared `inline' and defined on these header
  2900. files.  However, GCC won't inline them unless you compile with optimizations
  2901. enabled, so it tries to find the compiled version of the functions in the
  2902. library.  Workaround: compile with `-O.'
  2903.  
  2904. 
  2905. File: djgppfaq.info,  Node: Class Complex,  Next: Pure virtual,  Prev: Still unresolved,  Up: Compiling
  2906.  
  2907. 8.11 Where is class Complex?
  2908. ============================
  2909.  
  2910. **Q*: I cannot use class Complex in v2!  My C++ program compiled fine with
  2911. DJGPP v1.x, but in v2 the linker complains that it cannot find Complex class
  2912. definitions in the library.  Where are they?*
  2913.  
  2914. **Q*: I looked into libgpp.a and there aren't any references to any Complex
  2915. class functions.  I also didn't find complex.cc source file in the source of
  2916. Libg++ library.  Where did the Complex class go?*
  2917.  
  2918. *A* :  The latest Draft C++ Standard has changed its notion of complex
  2919. numbers, and the latest versions of Libg++ have followed suit.  Instead of
  2920. `class Complex' there is now a *template* `class complex<double>', and
  2921. `Complex' is now a typedef which uses that template class.  Look into the
  2922. headers `lang/cxx/_complex.h' and `lang/cxx/std/complext.h' and you will see
  2923. that change.  Part of the code found previously on `complex.cc' in the Libg++
  2924. source distribution is now found on `cdinst.cc' source file in the STL
  2925. sources (look inside `libstdcx.a'), another part is scattered between the
  2926. various files included at compile time (such as `lang/cxx/std/dcomplex.h' and
  2927. `lang/cxx/std/complext.cc'), while the rest is generated by the compiler
  2928. itself.  Therefore, there aren't any predefined functions of class Complex in
  2929. `libgpp.a.' Programs that use class Complex need to be edited to replace every
  2930. instance of `class Complex' to either just `Complex' or `class
  2931. complex<double>.'
  2932.  
  2933. As long as the C++ Standard is not officially published, C++ is still a
  2934. moving target, and Libg++ releases that try to track it sometimes have no
  2935. other alternative but to break existing code.  If you use C++, you have to
  2936. accept this as a fact of life.
  2937.  
  2938. 
  2939. File: djgppfaq.info,  Node: Pure virtual,  Next: djgpp_first_ctor,  Prev: Class Complex,  Up: Compiling
  2940.  
  2941. 8.12 The linker complains about __pure_virtual function.
  2942. ========================================================
  2943.  
  2944. **Q*: When I link a C++ program, the linker complains about "__pure_virtual"
  2945. being an unresolved symbol.  What should I do?*
  2946.  
  2947. *A* :  This problem is caused by a `libgcc.a' library which lacks a module
  2948. called `___pure_virtual' (yes, with *three* leading underscores!).  You
  2949. should get an updated version of that library which includes such a module.
  2950. `libgcc.a' comes with the Gcc distribution, so look in the latest
  2951. `gccNNNb.zip' file.
  2952.  
  2953. If, for some reason, you cannot find `libgcc.a' with that module, you can add
  2954. it yourself.  To this end, create a file called `pure.c' with this content:
  2955.  
  2956.      #define MESSAGE "pure virtual method called\n"
  2957.      
  2958.      void __pure_virtual()
  2959.      {
  2960.          write(2, MESSAGE, sizeof(MESSAGE) - 1);
  2961.          _exit(-1);
  2962.      }
  2963.  
  2964. Compile this file and put the object file into `libgcc.a', like this:
  2965.  
  2966.              gcc -c pure.c
  2967.              ar rvs libgcc.a pure.o
  2968.  
  2969. That's all!
  2970.  
  2971. 
  2972. File: djgppfaq.info,  Node: djgpp_first_ctor,  Next: Large image,  Prev: Pure virtual,  Up: Compiling
  2973.  
  2974. 8.13 Unresolved djgpp_first_ctor
  2975. ================================
  2976.  
  2977. **Q*: I do everything like your praised FAQ says, but the linker complains
  2978. about unresolved symbols with strange names like `djgpp_first_ctor',
  2979. `djgpp_last_dtor', etc.  I looked in every library with `nm', and I cannot
  2980. find these creatures.  Where in the world are they??*
  2981.  
  2982. *A* : These symbols are defined by the `djgpp.djl' linker script that should
  2983. be in your `lib/' subdirectory.  When you call `gcc' to link a program, it
  2984. invokes `ld.exe' with the option `-Tdjgpp.djl.'  If you invoke `ld' directly
  2985. (this is generally not recommended), be sure to include that switch.  If you
  2986. did invoke it through `gcc', maybe your linker is set up incorrectly.  Add
  2987. `-v' to the GCC switches and check that the command line that GCC gives to LD
  2988. includes that switch, that your `lib/' subdirectory includes that script
  2989. file, and that the script file is intact and includes the definition of the
  2990. above symbols.
  2991.  
  2992. Another reason might be that you have edited your `DJGPP.ENV' file in a way
  2993. that prevents the linker from finding its `djgpp.djl' script.
  2994.  
  2995. Mixing an old v1.x installation with a v2.x one can also cause such problems.
  2996. Be sure to delete the entire v1.x tree, or rename it, before installing the
  2997. v2.x distribution.
  2998.  
  2999. 
  3000. File: djgppfaq.info,  Node: Large image,  Next: Large executable,  Prev: djgpp_first_ctor,  Up: Compiling
  3001.  
  3002. 8.14 C++ programs yield large `.exe' file
  3003. =========================================
  3004.  
  3005. **Q*: It seems that declaring a large `static' array has the effect of
  3006. bloating the program image on disk by that many bytes.  Surely there is a
  3007. more compact way of telling the loader to set the next N bytes of RAM to
  3008. zero?*
  3009.  
  3010. *A* :  This only happens in C++ programs and is a (mis-)feature of GCC.  You
  3011. can use the `-fconserve-space' switch to GCC to prevent this from happening,
  3012. but it also turns off the diagnostics of duplicate definitions, which, if
  3013. uncaught, might cause your program to crash.  Thus, this switch isn't
  3014. recommended for programs which haven't been completely debugged (if there is
  3015. such a creature).  The `-fconserve-space' switch is described in the GCC
  3016. docs, *Note GNU C Compiler docs: (gcc)C++ Dialect Options.
  3017.  
  3018. If the downside of using this switch doesn't deter you, you can even add this
  3019. switch to your `lib/specs' file to make it permanent.
  3020.  
  3021. 
  3022. File: djgppfaq.info,  Node: Large executable,  Next: Linker script,  Prev: Large image,  Up: Compiling
  3023.  
  3024. 8.15 Why are DJGPP `.exe' files so large?
  3025. =========================================
  3026.  
  3027. **Q*: I compiled a trivial "Hello world" program and got a 60KB executable
  3028. file.  That's ridiculously bloated!*
  3029.  
  3030. **Q*: How come I recompile my programs with v2, and my executables become
  3031. larger by some 20-30 KBytes?  Isn't the latest version supposed to be better?*
  3032.  
  3033. *A* :  Did you link with `-s' switch to `gcc', or run `strip' on the output
  3034. of the linker?  If not, the executable includes the debugging symbols, which
  3035. makes it quite a lot larger.  (It is not recommended to strip the symbols
  3036. except when distributing production programs, because this makes debugging
  3037. very hard indeed; that is why `-s' is not passed to gcc by default.)
  3038.  
  3039. In general, v2 programs are about 20-30K larger on disk, but use 50-120K less
  3040. memory at run-time, than v1.x programs.  The larger disk image is due to two
  3041. main factors:
  3042.  
  3043.    * Part of the code that used to be inside `go32' DOS extender in v1.x is
  3044.      now part of the library and thus gets linked into every program.
  3045.  
  3046.    * The v2 startup code is much more powerful, but also larger.
  3047.  
  3048. Judging code sizes by looking at the size of "Hello" programs is meaningless,
  3049. since most of the power of protected-mode programming goes wasted in such
  3050. programs.  There is no point in switching the processor to protected mode
  3051. (which requires a lot of code) just to print a 15-byte string and exit.  The
  3052. overhead induced by the code needed to set up the protected-mode environment
  3053. is additive; the larger the program, the smaller the overhead relative to the
  3054. program size.
  3055.  
  3056. Apart from getting to protected-mode, the DJGPP startup code also includes
  3057. such functionality as wildcard expansion, long command-line support, and
  3058. loading the environment from a disk file; these usually aren't available with
  3059. other DOS protected-mode compilers.  Exception and signal handling (not
  3060. available at all in v1.x), FPU detection and emulator loading (which were
  3061. part of `go32' in v1.x), are now also part of the startup code.
  3062.  
  3063. If your program doesn't need parts of the startup code, it can be made
  3064. smaller by defining certain functions with empty bodies.  These functions are
  3065. `__crt0_glob_function', `__crt0_load_environment_file', and
  3066. `__crt0_setup_arguments.' By defining empty substitutes for all three of
  3067. these, you can make the "Hello" program be 18KB on disk.  These functions are
  3068. documented in the DJGPP libc reference, which see.
  3069.  
  3070. You can make your program image still smaller by compressing it with `DJP'
  3071. which is a DJGPP-specific executable compressor, e.g.
  3072. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2misc/mlp105b.zip.  It is fast
  3073. and has no memory overhead.  It also supports DJGPP "Dynamically Loaded
  3074. Module" (DLM) technology.
  3075.  
  3076. Another cause for differences in executable sizes between v1.x and v2 might
  3077. be the code generated by GCC: DJGPP v2 uses a newer version of GCC.  Usually,
  3078. the code size is quite similar, but in some cases GCC 2.7.2 has been seen to
  3079. produce code which is 50% larger or 50% smaller than GCC 2.6.3 included with
  3080. v1.12.
  3081.  
  3082. 
  3083. File: djgppfaq.info,  Node: Linker script,  Next: No EXE,  Prev: Large executable,  Up: Compiling
  3084.  
  3085. 8.16 Linker complains about `djgpp.lnk'
  3086. =======================================
  3087.  
  3088. **Q*: I run DJGPP under Windows 95, but the linker complains about
  3089. `djgpp.lnk' file...*
  3090.  
  3091. **Q*: When I try to link a program, I get an error message which says that
  3092. linker script file djgpp.lnk cannot be open.  What gives?*
  3093.  
  3094. *A* :  Do you use DJGPP v2.0 on Windows 9x and have a shortcut to DJGPP in
  3095. your current directory?  If so, and if you call that shortcut `djgpp',
  3096. Windows will create a file `djgpp.lnk' in your working directory.  In that
  3097. case, when `ld.exe' looks for its linking script, it will find this shortcut
  3098. instead, and will be totally confused by its format and contents.  In DJGPP
  3099. v2.01 and later, the linker script is called `djgpp.djl', so that this
  3100. conflict doesn't exist after you upgrade.
  3101.  
  3102. Another possible cause of such problems is RSXNTDJ.  When you install it, it
  3103. replaces some of the files which come with DJGPP by its customized versions,
  3104. but since version 1 of RSXNTDJ is consistent with DJGPP v2.0, these
  3105. customized files still specify `djgpp.lnk' as the linker script, whereas
  3106. DJGPP v2.01 and later has renamed that file to `djgpp.djl'.  Please look into
  3107. your `rsxntdj/lib/specs' file and see if it has a line like so:
  3108.  
  3109.        %{L*} %D %{T*} %o -Tdjgpp.lnk\
  3110.  
  3111. If so, you should change `-Tdjgpp.lnk' into `-Tdjgpp.djl', and see if that
  3112. solves the problem, or look for a version of RSXNTDJ which is compatible with
  3113. your release of DJGPP.  You should also compare the rest of the RSXNTDJ
  3114. `specs' file with the one which comes with DJGPP and check for other
  3115. inconsistencies.
  3116.  
  3117. 
  3118. File: djgppfaq.info,  Node: No EXE,  Next: Large object files,  Prev: Linker script,  Up: Compiling
  3119.  
  3120. 8.17 Linker fails to produce the EXE program under Novell
  3121. =========================================================
  3122.  
  3123. **Q*: When I link my program, it fails to produce the .EXE executable, but
  3124. only if I do this on a networked drive...*
  3125.  
  3126. **Q*: I run STUBIFY on a networked drive under Novell, but it doesn't produce
  3127. a .EXE file.  How come?*
  3128.  
  3129. *A* :  You might have another copy of the file with the same name that GCC is
  3130. creating in another directory somewhere on your networked drive.  If that
  3131. other directory is on your PATH, it is searched by Novell when the linker and
  3132. `STUBIFY' try to create the executable file, because that file doesn't exist
  3133. in the current directory.  So what might actually happen is that the linker
  3134. and `STUBIFY' are overwriting the files they find on your PATH instead of
  3135. creating new files in the current directory.
  3136.  
  3137. You can verify that this indeed is the problem by searching your networked
  3138. disks for files with the same name as those you are trying to build, and
  3139. looking at their time stamps.  If that is indeed the problem, then you have
  3140. several possible ways of solving it:
  3141.  
  3142.   1. You can remove the other files, rename them, or move them to another
  3143.      directory that isn't searched by Novell.
  3144.  
  3145.   2. You can rename the program you are trying to link.
  3146.  
  3147.   3. You can change the way Novell searches for files (aka "the search
  3148.      mode"), so that it won't look in the directories on your PATH.
  3149.  
  3150.   4. You can change your access rights to the directory on the PATH where the
  3151.      other files reside, so that you won't have write privileges to that
  3152.      directory.
  3153.  
  3154.   5. You can change the search mode for `STUBIFY' and the linker (or for any
  3155.      other program that gives you that trouble) by running commands like
  3156.      these:
  3157.  
  3158.             SMODE stubify.exe 2
  3159.             SMODE ld.exe 2
  3160.  
  3161.  
  3162. 
  3163. File: djgppfaq.info,  Node: Large object files,  Next: Allegro,  Prev: No EXE,  Up: Compiling
  3164.  
  3165. 8.18 Linker fails for large object files or large libraries
  3166. ===========================================================
  3167.  
  3168. **Q*: Whenever I define very large static arrays in my program, the linker
  3169. fails saying "could not read symbols: Bad value".  Huh??*
  3170.  
  3171. **Q*: I have some large libraries that I cannot link because the linker fails
  3172. on them with a message saying "memory exhausted".  I have plenty of virtual
  3173. memory on my system, so why would ld fail?*
  3174.  
  3175. *A* :  This is a known bug in `ld.exe' from GNU Binutils 2.5.2.  Please
  3176. upgrade to DJGPP v2.01 which comes with Binutils 2.7.  If you can't upgrade,
  3177. or if the latest `ld.exe' exhibits such bugs, these are your alternatives for
  3178. a work-around:
  3179.  
  3180.    * In case of a large library, split it into several smaller ones.
  3181.  
  3182.    * For a module that defines large data structures, move some of the static
  3183.      data to other files, or allocate the space at runtime with `calloc.'
  3184.  
  3185. `ld.exe' from GNU Binutils 2.7 (which comes with DJGPP v2.01) doesn't have
  3186. most of these problems, but there are still some cases where you might see
  3187. such messages.  One such case is the `POVRAY' package, where the failure is
  3188. caused by an object file called `_pmlite.o' in the library.  The problem here
  3189. is that `_pmlite.o' is a TASM-compiled file, processed by `EMXAOUT'.
  3190. `EMXAOUT' produces `a.out' object files which `ld.exe' cannot link if they
  3191. are in a library.  Either taking that object file out of the library, or
  3192. processing the original `_pmlite.obj' with another tool (such as `OBJ2COFF')
  3193. will solve these problems.  Note however, that the authors of `OBJ2COFF' have
  3194. explicitly forbidden commercial use of their tool.
  3195.  
  3196. 
  3197. File: djgppfaq.info,  Node: Allegro,  Prev: Large object files,  Up: Compiling
  3198.  
  3199. 8.19 Building Allegro library fails
  3200. ===================================
  3201.  
  3202. **Q*: When I try to build the Allegro library, liballeg.a, I get some cryptic
  3203. message about register-opcode mismatch.  What am I doing wrong?*
  3204.  
  3205. **Q*: It seems I miss one of the source files from the Allegro distribution,
  3206. because Make cannot find it when I try to build Allegro.*
  3207.  
  3208. *A* :  You should get the latest version 2.11 of Allegro from SimTel.NET,
  3209. e.g. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/alleg211.zip or from
  3210. Shawn Hargreaves' site, at this URL:
  3211.  
  3212.      http://www.talula.demon.co.uk/allegro/
  3213.  
  3214. Version 2.1 of Allegro and some uploads of 2.11 to sites other than
  3215. SimTel.NET are known to have bugs such as above.
  3216.  
  3217. 
  3218. File: djgppfaq.info,  Node: Running,  Next: Graphics,  Prev: Compiling,  Up: Top
  3219.  
  3220. 9. Running Compiled Programs
  3221. ****************************
  3222.  
  3223.   This chapter discusses various problems which may happen when running DJGPP
  3224. programs under different environments, and gives solutions to them.
  3225.  
  3226. * Menu:
  3227.  
  3228. * v2.x crash::                Program which was OK in v1.x bombs in v2.0.
  3229. * Crash traceback::           How to make sense out of stack dumps.
  3230. * File data corrupted::       The DOS *TEXT*/*BINARY* file issue.
  3231. * Screen I/O::                Beware of the buffering!
  3232. * Distributing::              DJGPP programs are *not* self-contained.
  3233.  
  3234. 
  3235. File: djgppfaq.info,  Node: v2.x crash,  Next: Crash traceback,  Prev: Running,  Up: Running
  3236.  
  3237. 9.1 My program crashes only in v2.0!
  3238. ====================================
  3239.  
  3240. **Q*: I have this program which runs fine when compiled with DJGPP v1.12, but
  3241. crashes and burns in v2.  Isn't it obvious that you guys blew it with v2?*
  3242.  
  3243. **Q*: My v2 program crashes, but only under CWSDPMI; it runs OK under other
  3244. DPMI hosts like Windows, OS/2 or QDPMI.  Is this a bug in CWSDPMI?*
  3245.  
  3246. *A* :  Not necessarily so, it could still be a bug in your program which just
  3247. went unnoticed until now.  One area where such things can happen is use of
  3248. uninitialized memory.  In v1.x, memory first allocated to the stack or by a
  3249. call to `malloc' is always zeroed, but v2 doesn't behave this way, so your
  3250. program might exhibit erratic behavior or crash with `SIGSEGV' because of
  3251. such bugs.  In particular, if the program behaves differently depending on
  3252. which program was run before it, you might suspect bugs of this kind.
  3253.  
  3254. To check whether this is the source of your grief, include the header
  3255. `crt0.h' in your `main' and set `_crt0_startup_flags' to
  3256. `_CRT0_FLAG_FILL_SBRK_MEMORY'; this will fill the memory with zeroes when it
  3257. is first allocated.  If the program will run OK after recompilation, then
  3258. this is probably the cause of your problem.  To make spotting uninitialized
  3259. memory simpler, you can set `_crt0_startup_flags' to
  3260. `_CRT0_FLAG_FILL_DEADBEAF' (don't laugh!); this will cause the sbrk()'ed
  3261. memory to be filled with the value `0xdeadbeaf' (`-559838801' in decimal)
  3262. which is easy to spot with a debugger.  Any variable which has this value was
  3263. used without initializing it first.
  3264.  
  3265. Another possible cause of problems will most probably be seen only under
  3266. CWSDPMI; its telltale sign is a message "Page fault at ..." that is printed
  3267. when a program crashes, and an error code of 6.  Unlike other DPMI hosts,
  3268. CWSDPMI supports some DPMI 1.0 extensions which allow DJGPP to capture and
  3269. disallow illegal dereference of pointers which point to addresses less than
  3270. 1000h (aka "NULL pointer protection").  This feature can be disabled by
  3271. setting the `_CRT0_FLAG_NULLOK' bit in `_crt0_startup_flags'; if this makes
  3272. SIGSEGV crashes go away, your program is using such illegal pointers; the
  3273. stack trace printed when the program crashes should be a starting point to
  3274. debug this.
  3275.  
  3276. An insufficient stack size can also be a cause of your program's demise, see
  3277. *Note setting the stack size: Stack size, below.
  3278.  
  3279. 
  3280. File: djgppfaq.info,  Node: Crash traceback,  Next: File data corrupted,  Prev: v2.x crash,  Up: Running
  3281.  
  3282. 9.2 What is that gibberish printed when my program crashes?
  3283. ===========================================================
  3284.  
  3285. **Q*: My program dies with a cryptic message like "Segmentation violation" or
  3286. "Unsupported DOS request" or "General Protection Fault" and prints some
  3287. funny-looking numbers.  Can't I get some decent human-readable traceback
  3288. information, so I could pinpoint where in the program did the problem happen?*
  3289.  
  3290. *A* :  Those "funny-looking numbers" *are* the traceback.  They describe the
  3291. sequence of function calls which led to the fatal error by giving you the
  3292. addresses where each function was called.  You can have these addresses
  3293. translated to source line numbers by using the `SYMIFY' program (it is
  3294. included in the djdev201.zip, e.g.
  3295. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/djdev201.zip, and should be
  3296. in your `bin/' subdirectory).  To this end, make sure that your program was
  3297. compiled with the `-g' switch, linked *without* the `-s' switch and *not*
  3298. stripped, and that you have the source files available in your current
  3299. directory.  Now invoke your program and do whatever it takes to make it
  3300. crash.  Then, with the traceback still on the screen, type this from the DOS
  3301. command line:
  3302.  
  3303.       symify your-program-name
  3304.  
  3305. You will see the list of source files and line numbers right next to their
  3306. hex addresses.  Now you can start debugging.
  3307.  
  3308. You can ask `SYMIFY' to put the stack trace into a file (so you can consult
  3309. it later, e.g., from your editor while fixing the bug), by giving it an
  3310. output file, like this:
  3311.  
  3312.       symify -o problem.dmp yourprog
  3313.  
  3314. You can also save the raw stack trace (without source info) to a disk file
  3315. and submit it to `SYMIFY' later, like this:
  3316.  
  3317.       symify -i core.dmp yourprog
  3318.  
  3319. This comes in handy when your program grabs the screen (e.g., for some
  3320. graphics) and the stack trace can't be seen.  You can then *Note redirect the
  3321. stack trace to a file: Redirect, e.g., with the `REDIR' program which comes
  3322. with DJGPP.
  3323.  
  3324. But what if you *didn't* compile your program with `-g', and you aren't sure
  3325. how to recreate the problem which crashed it, after you recompile?  Well, you
  3326. can submit the stack dump *after* you recompile your program.  Just press
  3327. that PrintScreen key or otherwise save the stack trace, then submit it to
  3328. `SYMIFY' from a file as described above, after you've recompiled the program.
  3329. Be sure to give gcc all the compilation switches (sans `-s') that you gave
  3330. it when you originally compiled your program (in addition to `-g'), including
  3331. the optimization switches, or else the addresses shown in the stack trace
  3332. might be invalid.
  3333.  
  3334. 
  3335. File: djgppfaq.info,  Node: File data corrupted,  Next: Screen I/O,  Prev: Crash traceback,  Up: Running
  3336.  
  3337. 9.3 Reading and writing binary files
  3338. ====================================
  3339.  
  3340. **Q*: I'm reading/writing data files, but the data gets corrupted.*
  3341.  
  3342. **Q*: My program crashes when I read data files, but the same program on Unix
  3343. works OK.*
  3344.  
  3345. **Q*: When I read a file I get only a small portion of it.*
  3346.  
  3347. *A* :  Are your data files binary?  The default file type in DOS is "text",
  3348. even when you use the `read' and `write' library functions.  Text files get
  3349. their Newlines converted to <CR>-<LF> pairs on write and vice versa on read;
  3350. reading in "text" mode stops at the first <^Z> character.  You must tell the
  3351. system that a file is binary through the `b' flag in `fopen', or `O_BINARY' in
  3352. `open', or use the `setmode' library function.
  3353.  
  3354. Note that the above distinction between binary and text files is written into
  3355. the ANSI/ISO C standard, so programs that rely on the Unix behavior whereby
  3356. there's no such distinction, are strictly speaking not portable.
  3357.  
  3358. You can also use the low-level `_read' and `_write' library functions which
  3359. give you the direct interface to the DOS file I/O; they always use binary I/O.
  3360.  
  3361. 
  3362. File: djgppfaq.info,  Node: Screen I/O,  Next: Distributing,  Prev: File data corrupted,  Up: Running
  3363.  
  3364. 9.4 Buffered screen I/O surprises
  3365. =================================
  3366.  
  3367. **Q*: My program prompts the user to enter data from the keyboard, then reads
  3368. its response.  When compiled with a 16-bit compiler like BCC or MSC it works
  3369. as expected, but with gcc the prompt doesn't show, or is printed much later
  3370. in the program.*
  3371.  
  3372. **Q*: Help!  I cannot make `gotoxy' work!  The text I print appears on the
  3373. screen in incorrect locations after I use `gotoxy'!*
  3374.  
  3375. **Q*: Why does the text appear in the default colors even though I call
  3376. `textcolor' and `textbackground'?*
  3377.  
  3378. *A* :  Do you write to screen using buffered I/O (`fprintf', `fputs' and the
  3379. like) functions, or send your output to the C++ `cout' stream?  Then what you
  3380. see is the effect of the buffering of the standard output streams.  The
  3381. buffer is not written to screen until it's full, or until a Newline is
  3382. output, which might produce very unpleasant and unexpected behavior when used
  3383. in interactive programs.
  3384.  
  3385. It is usually a bad idea to use buffered I/O in interactive programs; you
  3386. should instead use screen-oriented functions like `cprintf' and `cputs.'  If
  3387. you must use buffered I/O, you should be sure that both `stdout' and `stderr'
  3388. are line-buffered or unbuffered (you can change the buffering by calling the
  3389. `setvbuf' library function); another solution would be to `fflush' the output
  3390. stream before calling any input function, which will ensure all pending
  3391. output is written to the operating system.  While this will generally work
  3392. under DOS and DJGPP, note that in some cases the operating system might
  3393. further buffer your output, so sometimes a call like `sync' would be needed
  3394. to actually cause the output be delivered to the screen.
  3395.  
  3396. The functions that set text attributes only affect the screen-oriented output
  3397. (aka "conio") functions (`cputs', `cprintf' etc.), the text written by
  3398. `fprintf' and other "stdio" functions doesn't change.  This is unlike some
  3399. 16-bit DOS compilers where `stdio' functions can also print colored text.
  3400.  
  3401. 
  3402. File: djgppfaq.info,  Node: Distributing,  Prev: Screen I/O,  Up: Running
  3403.  
  3404. 9.5 What do DJGPP programs need to run?
  3405. =======================================
  3406.  
  3407. **Q*: When I copy my DJGPP application program to another PC where no DJGPP
  3408. is installed, I can't run it.  It complains that it cannot find DPMI (??).
  3409. Do I really need all of your multi-megabyte installation to run compiled
  3410. programs?*
  3411.  
  3412. *A* :  No, you don't.  You can either (1) bring the `CWSDPMI.EXE' free DPMI
  3413. host to the target machine and put it in the same directory as your compiled
  3414. program or somewhere along the `PATH', or (2) install another DPMI host (such
  3415. as QDPMI, 386Max, Windows, etc.) on the target machine.  Note that the author
  3416. of CWSDPMI, Charles Sandmann <sandmann@clio.rice.edu>, requests a
  3417. notification by mail or acknowledged e-mail in case you distribute CWSDPMI
  3418. with a commercial or shareware product.
  3419.  
  3420. If your program could be run on a machine which lacks a floating-point
  3421. processor, you should also distribute an emulator, or link your program with
  3422. an emulator library.  *Note floating-point emulation issues: Emulation.
  3423.  
  3424. Future DJGPP releases might have a way to bind your executable with `CWSDPMI'
  3425. to produce a stand-alone program.  If you need such a feature *now* and if
  3426. you need it *badly*, write to Charles Sandmann <sandmann@clio.rice.edu> and
  3427. ask him about a modified stub code that creates an image of CWSDPMI if none
  3428. is found first time the program is run.
  3429.  
  3430. You can bind `PMODE/DJ' with your program, but remember that `PMODE/DJ'
  3431. doesn't support virtual memory, so such programs will only run on machines
  3432. with enough free physical RAM.
  3433.  
  3434. 
  3435. File: djgppfaq.info,  Node: Graphics,  Next: Floating point,  Prev: Running,  Up: Top
  3436.  
  3437. 10. Writing and Running Graphics Programs
  3438. *****************************************
  3439.  
  3440.   This chapter discusses some problems and explains some subtle points related
  3441. to graphics programming under DJGPP.
  3442.  
  3443. A tutorial is available on graphics programming with DJGPP, at this URL:
  3444.  
  3445.      http://remus.rutgers.edu/~avly/djgpp.html
  3446.  
  3447. * Menu:
  3448.  
  3449. * Which driver::         What driver to use with your SVGA?
  3450. * Direct access::        Under protected-mode it is (almost) forbidden.
  3451. * GRX and Windows::      Windows can mess up your graphics screen.
  3452.  
  3453. 
  3454. File: djgppfaq.info,  Node: Which driver,  Next: Direct access,  Prev: Graphics,  Up: Graphics
  3455.  
  3456. 10.1 What GRX driver to use with your SVGA
  3457. ==========================================
  3458.  
  3459. **Q*: Why won't GRX work with my SVGA adapter in any resolution but the
  3460. standard VGA?*
  3461.  
  3462. **Q*: How do I tell GRX which driver to use with my SVGA?*
  3463.  
  3464. *A* :  In order for GRX to work with your SVGA, you should set the `GRX20DRV'
  3465. environment variable, like this:
  3466.  
  3467.        set GRX20DRV=et4000 gw 1024 gh 768 nc 256
  3468.  
  3469. To set that variable, you need to know the chip-set on your adapter; refer to
  3470. your SVGA documentation.  Currently, GRX supports the following chip-sets:
  3471.  
  3472. `ati28800'
  3473.      The ATi 28800 chip-set.
  3474.  
  3475. `cl5426'
  3476.      Cirrus Logic CL-GD5426 or higher (like CL-GD5428) chip-set.
  3477.  
  3478. `et4000'
  3479.      Tzeng Labs ET4000 chip-set.
  3480.  
  3481. `mach64'
  3482.      The ATi Mach-64 SVGA.
  3483.  
  3484. `stdega'
  3485.      The standard EGA adapter.
  3486.  
  3487. `stdvga'
  3488.      The standard VGA adapter.
  3489.  
  3490. `VESA'
  3491.      For any VESA-compatible adapter.
  3492.  
  3493. After you set the `GRX20DRV' variable, run `modetest.exe' to see what modes
  3494. you have available.
  3495.  
  3496. If your chip-set is not one of the above, try the `VESA' driver because many
  3497. adapters support the VESA BIOS extensions.  If yours doesn't, try installing
  3498. a VESA BIOS emulator, like UNIVBE, e.g.
  3499. ftp://ftp.coast.net/Coast/msdos/graphics/univbe51.zip.
  3500.  
  3501. 
  3502. File: djgppfaq.info,  Node: Direct access,  Next: GRX and Windows,  Prev: Which driver,  Up: Graphics
  3503.  
  3504. 10.2 Accessing the video memory
  3505. ===============================
  3506.  
  3507. **Q*: I try to access the video memory at `0xa0000', but get "Segmentation
  3508. violation" ...*
  3509.  
  3510. **Q*: How can I access the text-mode video memory of my VGA?*
  3511.  
  3512. *A* :  Absolute addresses of memory-mapped devices are mapped differently
  3513. under DJGPP than what you might be used to under other DOS development
  3514. environments.  That's because DJGPP is a protected-mode environment, in which
  3515. you can't just poke any address:  that's what protected mode is all about!
  3516. To access such absolute addresses, use the so-called "farptr" functions like
  3517. `_farpeekb' and `_farpokew'; they are described in the C Library reference.
  3518. *Note more details on using "farptr" functions to access absolute addresses
  3519. in low memory: Xfer, below.
  3520.  
  3521. For text-mode screen updates, you can also use the `ScreenUpdate' and
  3522. `ScreenUpdateLine' library functions to quickly update the screen from a text
  3523. buffer.
  3524.  
  3525. Using the `_farpeekX/_farpokeX' paradigm to access memory isn't much slower
  3526. than direct access (they compile into 2 machine instructions when
  3527. optimizations are enabled).  But if you need even faster access (and don't
  3528. want to write it in assembly), *Note using the "nearptr" access facilities:
  3529. Xfer, as described below.
  3530.  
  3531. If your video card supports the VBE 2.0 standard, you can access the linear
  3532. frame buffer as a normal array in memory.  For an example of such a
  3533. technique, see the VBE example code by Charles Sandmann, e.g.
  3534. ftp://ftp.neosoft.com/pub/users/s/sandmann/vbe.zip.  You can also reach this
  3535. file via the Web, at this URL:
  3536.  
  3537.      http://www.rt66.com/~brennan/djgpp/vbe.zip
  3538.  
  3539. 
  3540. File: djgppfaq.info,  Node: GRX and Windows,  Prev: Direct access,  Up: Graphics
  3541.  
  3542. 10.3 Graphics screen restoring under Windows
  3543. ============================================
  3544.  
  3545. **Q*: When I switch away from my DJGPP program under Windows, then switch
  3546. back to it, graphics mode is down, or my screen is all messed up.  Why?*
  3547.  
  3548. *A* :  Windows only saves the VGA screen in standard VGA modes (1..13h) when
  3549. you task-switch away from a DOS application.  In any other mode it only
  3550. saves/restores the video mode *number*, but not the actual screen contents.
  3551. Your application is most likely still in the proper video mode (if not, it's
  3552. probably the fault of the Windows driver for your SVGA card), but the video
  3553. memory is messed up.  The beauty of all this is that your program has no way
  3554. of knowing that the screen has been taken away and then returned to it.
  3555.  
  3556. The only reasonable thing to do is to dedicate a "hotkey" in your application
  3557. (e.g., `Alt-R') whose action is to redraw the entire screen.  If you do that,
  3558. it's best to start all the way from the beginning, with a call to
  3559. `GrSetMode', as there are a few bad Windows video drivers which do not
  3560. restore SVGA graphics modes properly upon the switch back.
  3561.  
  3562. 
  3563. File: djgppfaq.info,  Node: Floating point,  Next: Debugging,  Prev: Graphics,  Up: Top
  3564.  
  3565. 11. Floating Point Issues and FP Emulation
  3566. ******************************************
  3567.  
  3568.   This chapter deals with issues pertaining to floating-point code and
  3569. floating-point emulation under DJGPP.
  3570.  
  3571. * Menu:
  3572.  
  3573. * Emulation::             What are your emulation options.
  3574. * Other emulators::       You can't use them.
  3575. * OS/2 emulation::        It doesn't serve DJGPP programs.
  3576. * -msoft-float::          This GCC switch isn't supported.
  3577. * Numeric exceptions::    Don't give us these NaN's!
  3578. * Emulator accuracy::     Not always as good as we'd like.
  3579. * SIGFPE with ObjC::      Objective C cannot run without FPU.
  3580. * SIGFPE in ldexp::       Some libm functions bomb.
  3581.  
  3582. 
  3583. File: djgppfaq.info,  Node: Emulation,  Next: Other emulators,  Prev: Floating point,  Up: Floating point
  3584.  
  3585. 11.1 Floating code without 80387
  3586. ================================
  3587.  
  3588. **Q*: I don't have an 80387.  How do I compile and run floating point
  3589. programs?*
  3590.  
  3591. **Q*: What shall I install on a target machine which lacks hardware
  3592. floating-point support?*
  3593.  
  3594. *A* :  Programs which use floating point computations and could be run on
  3595. machines without an 80387 should either be linked with the `libemu.a'
  3596. emulation library (add `-lemu' to your link command line) or be allowed to
  3597. dynamically load the `emu387.dxe' file at run-time if needed.  Linking with
  3598. libemu makes distribution simpler at a price of adding about 20KB to the size
  3599. of the program `.exe' file (the emulator functions will be used only if no
  3600. hardware floating point support is detected at runtime).  You should *always*
  3601. do one of the above when you distribute floating-point programs.
  3602.  
  3603. A few users reported that the emulation won't work for them unless they
  3604. explicitly tell DJGPP there is no x87 hardware, like this:
  3605.  
  3606.        set 387=N
  3607.        set emu387=c:/djgpp/bin/emu387.dxe
  3608.  
  3609. This is probably due to some subtle bug in the emulator setup code.  This
  3610. code is hard to debug, because the people who developed it have machines with
  3611. hardware FP processors.  Volunteers with FPU-less machines are needed to help
  3612. debug the above problem.  If you have access to a system without an FPU and
  3613. are willing to fix this problem, write to Charles Sandmann
  3614. <sandmann@clio.rice.edu> and ask him for guidance.
  3615.  
  3616. There is an alternative FP emulator called `WMEMU' (get the file
  3617. `v2misc/wmemu2b.zip').  It mimics a real coprocessor more closely, but is
  3618. larger in size and is distributed under the GNU General Public License (which
  3619. generally means you need to distribute its source if you distribute
  3620. `wmemu387.dxe', or distribute the source or objects to your entire program,
  3621. if you link it with `libwmemu.a').  Its advantage is that with `WMEMU', you
  3622. can debug FP apps on a non-FPU machine.  (But you will need to get the
  3623. sources and recompile it, since it was compiled with a beta release of DJGPP
  3624. and will cause unresolved externals if you try linking against `libwmemu.a'
  3625. without recompiling it.)  Note, however, that even `WMEMU' doesn't solve all
  3626. the problems of debugging FP programs on a non-FPU machine (e.g., emulating
  3627. flags doesn't work).
  3628.  
  3629. 
  3630. File: djgppfaq.info,  Node: Other emulators,  Next: OS/2 emulation,  Prev: Emulation,  Up: Floating point
  3631.  
  3632. 11.2 Other FP emulators cannot be used with DJGPP
  3633. =================================================
  3634.  
  3635. **Q*: I have an 80387 emulator installed in my `AUTOEXEC.BAT', but
  3636. DJGPP-compiled floating point programs still doesn't work.  Why?*
  3637.  
  3638. *A* :  DJGPP switches the CPU to *protected* mode, and the information needed
  3639. to emulate the 80387 is different.  Not to mention that the exceptions never
  3640. get to the real-mode handler.  You *must* use emulators which are designed
  3641. for DJGPP.  Apart of `emu387' and `WMEMU', the only other emulator known to
  3642. work with DJGPP is `Q87' from QuickWare.  `Q87' is shareware and is available
  3643. from the QuickWare Web site, at this URL:
  3644.  
  3645.      http://www.weblane.com/quickware
  3646.  
  3647. 
  3648. File: djgppfaq.info,  Node: OS/2 emulation,  Next: -msoft-float,  Prev: Other emulators,  Up: Floating point
  3649.  
  3650. 11.3 Floating-point emulation under OS/2
  3651. ========================================
  3652.  
  3653. **Q*: I run DJGPP in an OS/2 DOS box, and I'm told that OS/2 will install its
  3654. own emulator library if the CPU has no FPU, and will transparently execute
  3655. FPU instructions.  So why won't DJGPP run floating-point code under OS/2 on
  3656. my machine?*
  3657.  
  3658. *A* :  OS/2 installs an emulator for native OS/2 images, but does not provide
  3659. FPU emulation for DOS sessions.
  3660.  
  3661. 
  3662. File: djgppfaq.info,  Node: -msoft-float,  Next: Numeric exceptions,  Prev: OS/2 emulation,  Up: Floating point
  3663.  
  3664. 11.4 DJGPP doesn't support `-msoft-float'
  3665. =========================================
  3666.  
  3667. **Q*: I've read in the GCC Info file that gcc has a `-msoft-float' option
  3668. which is said to generate library calls for floating point support.  Can this
  3669. facility be used for FP emulation on a machine without x87?*
  3670.  
  3671. *A* :  The GCC Info file also says that the library required by
  3672. `-msoft-float' is *not* part of the GNU C compiler.  As nobody wrote such a
  3673. library for DJGPP (yet), this option currently isn't supported.
  3674.  
  3675. 
  3676. File: djgppfaq.info,  Node: Numeric exceptions,  Next: Emulator accuracy,  Prev: -msoft-float,  Up: Floating point
  3677.  
  3678. 11.5 Numeric exceptions--sometimes
  3679. ==================================
  3680.  
  3681. **Q*: I have a program which works with FP emulation, but dies with "Numeric
  3682. Exception" when run on a machine with a co-processor.  It also runs OK when
  3683. compiled with Microsoft C.  Can't you people make your floating-point code
  3684. right?*
  3685.  
  3686. *A* : This might be still a problem with your program.  Under DJGPP, the
  3687. 80x87 control word is set up so that it generates an exception when your
  3688. program feeds it with a "NaN" ("Not a Number"), while the emulator doesn't
  3689. have this behavior.  You should make sure that your program doesn't generate
  3690. NaNs, or set the 80x87 control word to a different value.  A library function
  3691. called `_control87' can be used from within a program to set the coprocessor
  3692. to a non-default state.
  3693.  
  3694. 
  3695. File: djgppfaq.info,  Node: Emulator accuracy,  Next: SIGFPE with ObjC,  Prev: Numeric exceptions,  Up: Floating point
  3696.  
  3697. 11.6 Floating point inaccuracies when using emulator
  3698. ====================================================
  3699.  
  3700. **Q*: I am experiencing inaccurate results in some floating point
  3701. calculations, sometimes in the 2nd or 3rd significant digit (like getting
  3702. 118.401 instead of 120.0).  This is really unacceptable!  (And no, I'm *not*
  3703. using a buggy Pentium CPU.)*
  3704.  
  3705. *A* :  Are you using the emulator?  If so, it might be that the emulator
  3706. isn't as accurate as you expect.  One particular known problem is that it
  3707. does a bad job when computing the `atan' function.  So if you use `atan(1.)'
  3708. to get the value of `Pi', that might be your problem.  Solution: make `Pi' a
  3709. constant, as God intended.  The header file `<math.h>' includes the constant
  3710. `M_PI' which you can use; or get the value of Pi from the net, at this URL:
  3711.  
  3712.      http://www.diku.dk/~terra/pi.html
  3713.  
  3714. 
  3715. File: djgppfaq.info,  Node: SIGFPE with ObjC,  Next: SIGFPE in ldexp,  Prev: Emulator accuracy,  Up: Floating point
  3716.  
  3717. 11.7 Floating point exception in Objective-C programs
  3718. =====================================================
  3719.  
  3720. **Q*: When I run my Objective-C programs on a machine without an FPU, it dies
  3721. with a floating point exception, even though I installed the emulator as the
  3722. docs say...*
  3723.  
  3724. *A* : There is a bug in GCC 2.7.2 whereby it sometimes emits Objective-C code
  3725. that crashes ObjC programs.  A patch that fixes it was posted to the DJGPP
  3726. news group and can be found in the DJGPP mail archives, at this URL:
  3727.  
  3728.      http://www.delorie.com/djgpp/mail-archives/djgpp/1996/05/05/11:05:21
  3729.  
  3730. You will have to get the GCC source distribution `gcc2721s.zip', install the
  3731. above patch, rebuild `cc1obj.exe', and then recompile `libobjc.a' to make the
  3732. problem go away.
  3733.  
  3734. 
  3735. File: djgppfaq.info,  Node: SIGFPE in ldexp,  Prev: SIGFPE with ObjC,  Up: Floating point
  3736.  
  3737. 11.8 Floating point exception in libm functions
  3738. ===============================================
  3739.  
  3740. **Q*: When I use the `ldexp' function, my program crashes with SIGFPE.
  3741. What's wrong?*
  3742.  
  3743. *A* : There is a bug in the scaling code in `libm.a' library released with
  3744. DJGPP v2.0 which affects several library functions such as `ldexp'.  A
  3745. work-around is to link without `-lm' switch; this will cause `GCC' to use
  3746. math functions from `libc.a'.  If you need math functions which are only in
  3747. `libm.a', or if you need `libm.a' for better numerical performance, a patched
  3748. version of libm is available, e.g.
  3749. ftp://ftp.lstm.ruhr-uni-bochum.de/pub/djgpp/libm.zip, courtesy of Tom Demmer
  3750. <Demmer@LStM.Ruhr-Uni-Bochum.De>.  DJGPP v2.01 corrects this bug, so upgrade
  3751. to that version if you can.
  3752.  
  3753. 
  3754. File: djgppfaq.info,  Node: Debugging,  Next: Profiling,  Prev: Floating point,  Up: Top
  3755.  
  3756. 12. Debugging DJGPP Programs
  3757. ****************************
  3758.  
  3759.   This chapter discusses the debuggers you can use with DJGPP and answers some
  3760. of the questions you might have when debugging DJGPP programs.
  3761.  
  3762. * Menu:
  3763.  
  3764. * How to debug::              What should you do to debug a program.
  3765. * Old QDPMI::                 Some QDPMI versions will crash the debugger.
  3766. * GDB needs COFF::            GDB can't use the .exe program.
  3767. * Transfer buffer::           Beware--debuggers use the transfer buffer.
  3768. * Debug graphics::            Debugging GUI programs.
  3769. * GDB and C++ source::        Problems with non-.cc extensions.
  3770. * C++ classes in GDB::        Class members' names in GDB.
  3771. * Included source::           Debuggers have problems with included files.
  3772. * Debugging woes::            Some programs which cannot be debugged.
  3773.  
  3774. 
  3775. File: djgppfaq.info,  Node: How to debug,  Next: Old QDPMI,  Prev: Debugging,  Up: Debugging
  3776.  
  3777. 12.1 How to run a DJGPP program under debugger
  3778. ==============================================
  3779.  
  3780. **Q*: How do I debug my programs?*
  3781.  
  3782. *A* : First, remember to use the `-g' switch when you compile and link.  This
  3783. puts debugging information into your executable.  When linking, don't use the
  3784. `-s' switch.  Here are a few examples of compilation and link command lines
  3785. when you intend to debug a program:
  3786.  
  3787.       gcc -Wall -c -g -O myfile.c
  3788.      
  3789.       gcc -Wall -O2 -g -o myprog mymain.c mysub1.c mysub2.c -lm
  3790.      
  3791.       gcc -g -o myprog myprog.o mysub.o
  3792.  
  3793. (Note that with `gcc', you can use optimization switches when compiling with
  3794. `-g.')
  3795.  
  3796. Then, to debug the program, use a command line like this (here for `gdb'):
  3797.  
  3798.       gdb myprog.exe
  3799.  
  3800. Beginning with v2.01, DJGPP debuggers can debug both unstubbed COFF images
  3801. and DOS-style .exe executables (v2.0 only supported COFF files).  To debug a
  3802. COFF file, name it without the .exe extension, like so:
  3803.  
  3804.       gdb myprog
  3805.  
  3806. You can use one of several available debuggers with DJGPP:
  3807.  
  3808.   a. `RHIDE', the DJGPP IDE by Robert Hoehne (available from the DJGPP
  3809.      archives, e.g.
  3810.      ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2apps/rhide10b.zip).  It
  3811.      includes an integrated source-level debugger based on GDB code and
  3812.      presents a user interface like that of Borland's IDE or Turbo Debugger.
  3813.  
  3814.   b. `RHGDB', a stand-alone version of GDB with a Turbo Vision user
  3815.      interface.  `RHGDB' is part of the RHIDE distribution; it only supports
  3816.      part of GDB features.
  3817.  
  3818.   c. `FSDB', the full-screen debugger, from the `djdev' distribution.  This
  3819.      presents a user interface like that of Borland's Turbo Debugger, but
  3820.      unlike TD, *it isn't a source-level debugger* (although it will show the
  3821.      source code together with the machine instructions).  It also supports
  3822.      data-write breakpoints: a powerful feature for hunting down code which
  3823.      overwrites data it shouldn't touch.  Another advantage of `FSDB' is that
  3824.      you can easily debug programs that grab the screen, because it can
  3825.      switch between the debugger screen and the application screen.  The main
  3826.      disadvantage of `FSDB' is that you cannot easily examine the contents of
  3827.      complex data structures.  Remember to prepend an underscore `_' to the
  3828.      names of C identifiers when you use them with `FSDB'; for C++ programs
  3829.      you will have to find out the mangled names of static class variables
  3830.      and methods to make `FSDB' understand them.
  3831.  
  3832.   d. The GNU Debugger, `GDB' (get the file gdb416b.zip, e.g.
  3833.      ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/gdb416b.zip.  This is
  3834.      a powerful source-level debugger, but it uses a line-oriented user
  3835.      interface.  People who are familiar with using `GDB' on Unix should know
  3836.      about the following important differences in its operation on MS-DOS:
  3837.  
  3838.         * The command-line arguments can be only passed to the debuggee from
  3839.           within the debugger (use the `set args' or `run' commands), not
  3840.           from the `GDB' command line.
  3841.  
  3842.         * You cannot rerun the debuggee when it exits.  You must exit `GDB'
  3843.           and restart it.
  3844.  
  3845.         * `GDB' is currently configured for DJGPP in a way that makes loading
  3846.           a program and reading a source file when a breakpoint is hit
  3847.           *exceedingly* slow: it can take more than a minute for a very large
  3848.           program.  Be patient and don't decide that `GDB' is wedged unless
  3849.           you've waited several minutes.  A source-level patch to GDB was
  3850.           posted to the DJGPP News group, which corrects this problem; you
  3851.           can get this patch by searching the DJGPP mail archives.
  3852.  
  3853.         * `GDB' doesn't know about PC-specific keys, so you cannot use the
  3854.           arrow keys for command history editing.  Use ASCII control keys
  3855.           instead (`^F' for forward character, `^B' for backward character,
  3856.           `^P' for previous line, `^N' for next line, etc.).
  3857.  
  3858.         * The debugger and the debuggee share their file handles.  This means
  3859.           that if your program redirects or closes its `stdin' or `stdout',
  3860.           you will be unable to communicate with `GDB.'
  3861.  
  3862.         * The initial commands are read from a file named `gdb.ini' instead
  3863.           of `.gdbinit' which isn't a legal filename under MS-DOS.
  3864.  
  3865.         * `GDB' uses the GNU `readline' package for its input.  The
  3866.           `readline' init file (`~/.inputrc' on Unix) is called `/inputrc' on
  3867.           MS-DOS and should be in the root directory of the current drive.
  3868.  
  3869.   e. `EDEBUG32' is the most basic debugger you can use with DJGPP.  One case
  3870.      when you would need to use it is when you debug a DXE module (*note
  3871.      explanation of what a DXE is: DXE.), because `GDB' doesn't support
  3872.      debugging DXEs.
  3873.  
  3874.  
  3875. You invoke any debugger like this:
  3876.  
  3877.       <debugger-name> <program> <args...>
  3878.  
  3879. Note that the `argv[0]' parameter under the debugger is *not* the full
  3880. pathname of the debuggee, so programs which use `argv[0]' for their operation
  3881. might behave differently under a debugger.
  3882.  
  3883. 
  3884. File: djgppfaq.info,  Node: Old QDPMI,  Next: GDB needs COFF,  Prev: How to debug,  Up: Debugging
  3885.  
  3886. 12.2 You need QEMM 7.53 or later
  3887. ================================
  3888.  
  3889. **Q*: Whenever I call any DJGPP debugger to debug my program, it crashes
  3890. immediately.*
  3891.  
  3892. *A* :  Are you running under Quarterdeck's QDPMI?  Then you should upgrade to
  3893. QEMM 7.5 patch-level #3 or later.  That patch corrects a subtle problem in
  3894. QDPMI which was triggered by DJGPP debuggers.  If you cannot or wouldn't
  3895. upgrade, for money or love, turn OFF the DPMI services of QDPMI and use
  3896. `CWSDPMI' as your DPMI host.  To disable QEMM DPMI services either uninstall
  3897. QDPMI, or go to the QEMM directory and issue the following command:
  3898.  
  3899.       qdpmi off
  3900.  
  3901. 
  3902. File: djgppfaq.info,  Node: GDB needs COFF,  Next: Transfer buffer,  Prev: Old QDPMI,  Up: Debugging
  3903.  
  3904. 12.3 GDB won't debug unless it sees COFF output
  3905. ===============================================
  3906.  
  3907. **Q*: I try invoking GDB on my program, but it says: "not in executable
  3908. format: File format not recognized."  Huh?*
  3909.  
  3910. *A* :  Most probably, you've invoked GDB from DJGPP v2.0 on a `.exe' program.
  3911. That version of GDB needs to be called with the name of un-stubbed COFF
  3912. executable as its argument.  To get both a `.exe' and a COFF file, you should
  3913. make your link command line look this way:
  3914.  
  3915.       gcc -o foo foo.o
  3916.  
  3917. instead of
  3918.  
  3919.       gcc -o foo.exe foo.o
  3920.  
  3921. (the latter will only produce `foo.exe', while the former produces both
  3922. `foo', the COFF executable which gdb needs, and `foo.exe').
  3923.  
  3924. To produce a COFF file from a `.exe' program, use the `EXE2COFF' program
  3925. which comes with DJGPP, like this:
  3926.  
  3927.       exe2coff foo.exe
  3928.  
  3929. Debuggers which come with DJGPP v2.01 can debug COFF and .exe programs alike,
  3930. so upgrading to v2.01 should solve this problem.
  3931.  
  3932. 
  3933. File: djgppfaq.info,  Node: Transfer buffer,  Next: Debug graphics,  Prev: GDB needs COFF,  Up: Debugging
  3934.  
  3935. 12.4 Debuggers use the transfer buffer.
  3936. =======================================
  3937.  
  3938. **Q*: My program corrupts files and screen writes, and otherwise behaves
  3939. strangely when run under a debugger.*
  3940.  
  3941. *A* :  Do you use the transfer buffer to move data between your program and
  3942. conventional (under 1 MByte) memory?  Then it might be that the debugger
  3943. corrupts your I/O.  The debugger itself uses the transfer buffer for disk
  3944. read requests and screen writes.  If you single step through any of your app
  3945. routines which use the transfer buffer, the debugger might overwrite its
  3946. contents, which may alter the correct behavior.
  3947.  
  3948. To work around this, don't step with the debugger through your functions
  3949. which use the transfer buffer.
  3950.  
  3951. If all of the above doesn't make sense for you, don't worry: if you don't
  3952. know what the transfer buffer is, and you only trace into your own functions,
  3953. then you won't hit this problem.
  3954.  
  3955. 
  3956. File: djgppfaq.info,  Node: Debug graphics,  Next: GDB and C++ source,  Prev: Transfer buffer,  Up: Debugging
  3957.  
  3958. 12.5 How to debug a graphics program
  3959. ====================================
  3960.  
  3961. **Q*: How can I debug a graphics program?  The debugger runs my program fine,
  3962. but when a breakpoint is hit with the screen in a graphics mode I can't read
  3963. the text printed by the debugger.*
  3964.  
  3965. *A* :  Redirect the debugger output to your printer, like this:
  3966.  
  3967.       gdb myprog > prn
  3968.  
  3969. This will only work if the program itself doesn't write to stdout (graphics
  3970. programs usually don't); otherwise the debugger output will get mixed up with
  3971. your program's output.
  3972.  
  3973. The FSDB debugger can switch between the application screen and the debugger
  3974. screen, so you might use it, at a price of working with a low-level debugger.
  3975. Press `Alt-F5' to switch between the two screens.  Stock FSDB as distributed
  3976. with DJGPP can only do this with text screens, but a modified version of FSDB
  3977. with graphics support, e.g.
  3978. ftp://ftp.delorie.com/pub/djgpp/contrib/gnudebug.zip is available that knows
  3979. about many graphics modes (it can also be found on the Oulu repository, e.g.
  3980. ftp://x2ftp.oulu.fi/pub/msdos/programming/djgpp2/gnudebug.zip).
  3981.  
  3982. Future versions of RHIDE might allow debugging graphics programs, so try to
  3983. find out whether such a version is available.
  3984.  
  3985. As yet another possibility, consider using the `MSHELL' program which will
  3986. redirect I/O from any program to the monochrome monitor at the BIOS level, so
  3987. you can use it even with GDB.  `MSHELL' was written by DJ Delorie
  3988. <dj@delorie.com> and is available as mshell10.zip, e.g.
  3989. ftp://ftp.delorie.com/pub/djgpp/ofc/mshell10.zip.  Be sure that you don't
  3990. have some other TSR installed that catches screen writes and bypasses the
  3991. BIOS functions, or else `MSHELL' won't help you.  For example, changing the
  3992. code page (with the DOS `CHCP' or `MODE' commands) might do this.
  3993.  
  3994. 
  3995. File: djgppfaq.info,  Node: GDB and C++ source,  Next: C++ classes in GDB,  Prev: Debug graphics,  Up: Debugging
  3996.  
  3997. 12.6 GDB finds only `.cc' source
  3998. ================================
  3999.  
  4000. **Q*: When I try to debug my C++ programs, the debugger claims it can't find
  4001. the source file:*
  4002.  
  4003.       file.cc: No such file or directory.
  4004.  
  4005. *The source file *is* there, but it's called `file.cpp', not `file.cc.'  Why
  4006. does this happen?*
  4007.  
  4008. *A* :  It's a bug in GCC.  It erroneously assumes that a C++ source always
  4009. has a `.cc' extension.  Until this bug is corrected in some future version of
  4010. GCC, you're better off calling your C++ files `*.cc.'  If this is
  4011. unacceptable, then you can work around this bug by invoking `cc1plus' and the
  4012. assembler pass manually.  The bug in GCC manifests itself in that `cc1plus'
  4013. is called with the option `-dumpbase file.cc.'  If you replace this with
  4014. `-dumpbase file.cpp' (or whatever your extension is), the debugger will
  4015. happily find your sources.
  4016.  
  4017. 
  4018. File: djgppfaq.info,  Node: C++ classes in GDB,  Next: Included source,  Prev: GDB and C++ source,  Up: Debugging
  4019.  
  4020. 12.7 Can GDB print class members?
  4021. =================================
  4022.  
  4023. **Q*: It seems that GDB doesn't recognize C++ class members by their
  4024. original, unmangled names.  Do I really need to figure out the mangled names
  4025. of all my class variables and methods to be able to debug them?*
  4026.  
  4027. *A* :  No, you don't.  `GDB' *does* allow you to use the original names, it's
  4028. just that it usually treats the `::' in their names as word delimiters.
  4029. Include the name of the method or a class static variable in single quotes,
  4030. and `GDB' will recognize them as a single word.  For example, if your class
  4031. `CMPForward' has a method named `go' which you need to put a breakpoint in,
  4032. use the following command:
  4033.  
  4034.        b 'CMPForward::go'
  4035.  
  4036. Other `GDB' features that might be useful in this context are the various
  4037. demangling options, like `set print demangle', `set demangle-style' etc.;
  4038. look them up in the GDB on-line docs.
  4039.  
  4040. However, there are some cases where you won't be able to get GDB to demangle
  4041. C++ function names no matter how hard you try.  This is due to a lack of
  4042. sufficient debugging information in the COFF files with SDB debug data.
  4043. There's simply not enough info there for GDB to detect the source language
  4044. and use C++-specific support.  If you need a description of the GNU style of
  4045. mangling C++ names (so you could demangle them yourself), look in the GDB or
  4046. Libg++ source distribution, in the libiberty directory, for a file named
  4047. `cplus-demangle.c'.  If you really need full C++ support in DJGPP, you will
  4048. have to recompile GCC with stabs debugging support.  Robert Hoehne
  4049. <Robert.Hoehne@Mathematik.tu-chemnitz.de>, who did that, reports that it is
  4050. only necessary to change the configuration file `go32.h' in the GCC sources
  4051. and rebuild `cc1.exe' and `cc1plus.exe'.  Caveat emptor: `FSDB' and
  4052. `EDEBUG32' don't understand stabs, so you will have to compile with `-gcoff'
  4053. option to use these debuggers.
  4054.  
  4055. Note that, as the debugger built into RHIDE uses GDB code, it will also
  4056. sometimes have such problems with debugging C++ programs.
  4057.  
  4058. 
  4059. File: djgppfaq.info,  Node: Included source,  Next: Debugging woes,  Prev: C++ classes in GDB,  Up: Debugging
  4060.  
  4061. 12.8 GDB cannot list source that was #include'd
  4062. ===============================================
  4063.  
  4064. **Q*: My source file #include's another source file, but I cannot set a
  4065. breakpoint in that included code, because GDB says there is no such line, or
  4066. no such source file...*
  4067.  
  4068. **Q*: I cannot debug code produced by Flex, or Bison, or F2C, because GDB
  4069. somehow messes up all the source file and line number info!*
  4070.  
  4071. *A* :  This is a genuine limitation of the COFF format used by DJGPP.  It can
  4072. only handle a single source file for a given object file.  It does include
  4073. correct line numbers, but the name of the source file is wrong, so debugging
  4074. such files just doesn't work.
  4075.  
  4076. For source files that include other source files, you can work around this by
  4077. just inserting the included source with your editor while you debug the
  4078. program.  For code produced by other programs, like `F2C' or `Bison', you
  4079. will have to delete the `#line' directives from the generated C source, and
  4080. debug the generated code as regular C program.
  4081.  
  4082. 
  4083. File: djgppfaq.info,  Node: Debugging woes,  Prev: Included source,  Up: Debugging
  4084.  
  4085. 12.9 Debuggers choke on some programs ...
  4086. =========================================
  4087.  
  4088. **Q*: I cannot debug Emacs (or any program that requests raw keyboard input):
  4089. when I press Ctrl-C, any debugger I tried reported SIGINT.  But I cannot
  4090. operate the debugged program without Ctrl-C (in Emacs, it's necessary to exit
  4091. the editor)!*
  4092.  
  4093. **Q*: I cannot debug any program which catches signals!!??*
  4094.  
  4095. **Q*: I compiled my program with `-pg' switch, and now I cannot debug it...*
  4096.  
  4097. **Q*: When my program hits a breakpoint in GDB, the debugger reports SIGSEGV,
  4098. but only under Windows...*
  4099.  
  4100. *A* : There are currently a few limitations in debugging programs which use
  4101. interrupts or exceptions.  Programs compiled for profiling may crash under a
  4102. debugger with SIGSEGV or a GPF, with no addresses that `symify' can identify;
  4103. programs using `alarm' or `setitimer' can't be debugged, either.  You can't
  4104. hook the keyboard interrupt in a debugged program, and you can't debug a
  4105. program which uses floating point on a machine without FP hardware (unless
  4106. you use `WMEMU' as your emulator, but even WMEMU doesn't solve all the
  4107. problems).  The reason for all these problems is that any exceptions or
  4108. signals that happen when your program runs under a debugger will be caught by
  4109. the debugger instead, and they won't get passed to the debuggee.  To debug
  4110. programs which hook hardware interrupts, you will have to chain the old
  4111. real-mode interrupt handler to your new handler, which requires to write
  4112. special debug version of the program.
  4113.  
  4114. At least some of these limitations will be fixed in future versions of DJGPP.
  4115. For now, the only work-around that's available is for the case where you
  4116. need a `Ctrl-C' keypress to go to the debuggee instead of the debugger: use
  4117. the `Alt-Numeric-3' (that is, simultaneously press the `Alt' key and the `3'
  4118. key on the numeric keypad, then release the `Alt' key).  Some programs (but
  4119. not Emacs) will also treat the `Ctrl-2' keypress as `Ctrl-C'.
  4120.  
  4121. Another known problem is that `GDB' GP Faults when the program hits a
  4122. breakpoint under Windows 3.x (Windows 9x doesn't have this problem).  This is
  4123. because the breakpoint instruction causes a software interrupt (as opposed to
  4124. an exception) under Windows 3.x, and the DJGPP debug support currently only
  4125. catches debug exceptions.  The only work-around is to use the *hardware*
  4126. breakpoints (which use the special debug registers of the i386 and higher
  4127. CPUs, and which do work with DJGPP on Windows 3), and never have more than 4
  4128. of them active at the same time.  `FSDB' will automatically use the hardware
  4129. breakpoints for the first 4 breakpoints (so it works on Windows 3.x unless
  4130. you set more than 4 breakpoints simultaneously), but with `GDB', you will
  4131. have to explicitly use the `hbreak' and `thbreak' (instead of `break' and
  4132. `hbreak') commands which set hardware breakpoints.  This works with DJGPP
  4133. ports of GDB 4.16 and later.  Note that `GDB' uses the ordinary breakpoints
  4134. to implement the `step', `next' and similar commands, so you can't use these
  4135. on Windows 3.x; use the temporary hardware breakpoints instead.  The above is
  4136. also true for watchpoints (which watch for variables to change value): you
  4137. need to use hardware watchpoints with GDB (the total number of breakpoints and
  4138. watchpoints cannot exceed 4).  Same considerations apply to the debugger
  4139. built into RHIDE.
  4140.  
  4141. 
  4142. File: djgppfaq.info,  Node: Profiling,  Next: Performance,  Prev: Debugging,  Up: Top
  4143.  
  4144. 13. Profiling DJGPP Programs
  4145. ****************************
  4146.  
  4147.   This chapter explains how to optimize your program for speed using the
  4148. profiler, and discusses some problems you might have with it.
  4149.  
  4150. * Menu:
  4151.  
  4152. * How to profile::           What should you do to profile a program.
  4153. * Profiled crash::           Programs compiled with -pg crash.
  4154. * Gprof needs COFF::         Gprof doesn't like .exe executable.
  4155. * Gprof docs::               Look on Gprof man page for its docs.
  4156. * I/O bound programs::       How their profiles look.
  4157. * No profile::               Where is the profile?
  4158.  
  4159. 
  4160. File: djgppfaq.info,  Node: How to profile,  Next: Profiled crash,  Prev: Profiling,  Up: Profiling
  4161.  
  4162. 13.1 How to profile a DJGPP program
  4163. ===================================
  4164.  
  4165. **Q*: How can I profile my program to see where it spends most of its run
  4166. time?*
  4167.  
  4168. *A* :  DJGPP includes a profiling facility.  To use it, compile and link with
  4169. `-pg' option, run your program as you usually would, then run a program
  4170. called `gprof':
  4171.  
  4172.       gprof myprog
  4173.  
  4174. (change `myprog' to whatever name your program is).  This will print an
  4175. execution profile.
  4176.  
  4177. `Gprof' is part of GNU Binutils distribution, e.g.
  4178. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bnu27b.zip.
  4179.  
  4180. 
  4181. File: djgppfaq.info,  Node: Profiled crash,  Next: Gprof needs COFF,  Prev: How to profile,  Up: Profiling
  4182.  
  4183. 13.2 Programs compiled with -pg crash when run
  4184. ==============================================
  4185.  
  4186. **Q*: I cannot profile my program: when I compile it with -pg, it crashes or
  4187. wedges my machine!*
  4188.  
  4189. *A* :  DJGPP v2.01 has a bug in one of its library functions which is only
  4190. linked into your program when it is compiled with the `-pg' option.  A patch
  4191. was posted to the DJGPP News group; you can find it by searching the DJGPP
  4192. mail archives.  A work-around is to run the program compiled with `-pg' on
  4193. vanilla DOS configuration (no memory managers such as EMM386 or QEMM, and no
  4194. Windows).
  4195.  
  4196. 
  4197. File: djgppfaq.info,  Node: Gprof needs COFF,  Next: Gprof docs,  Prev: Profiled crash,  Up: Profiling
  4198.  
  4199. 13.3 Gprof won't work unless it can find COFF executable
  4200. ========================================================
  4201.  
  4202. **Q*: When I run `Gprof', it complains that it cannot find my program.  But
  4203. I've just run it!!*
  4204.  
  4205. **Q*: I run `Gprof' on my program, and it says: "bad format".*
  4206.  
  4207. *A* :  `Gprof' from DJGPP v2.0 needs the original COFF file the linker
  4208. produced.  If you delete it, or feed `Gprof' with the `.exe' file instead, it
  4209. will be most unhappy.  The way to produce the COFF output is explained in the
  4210. *Note section dealing with GDB: GDB needs COFF, above.  Alternatively,
  4211. upgrade to DJGPP v2.01, where all Binutils programs know about .exe
  4212. executables.
  4213.  
  4214. 
  4215. File: djgppfaq.info,  Node: Gprof docs,  Next: I/O bound programs,  Prev: Gprof needs COFF,  Up: Profiling
  4216.  
  4217. 13.4 Where is Gprof docs?
  4218. =========================
  4219.  
  4220. **Q*: What about all those `Gprof' options?  Where can I find their docs?*
  4221.  
  4222. **Q*: I can't figure out some of the info in the `Gprof' report ...*
  4223.  
  4224. *A* :  `Gprof' is only documented on a man page, `gprof.1.'  If you don't
  4225. have one, you will have to look for it in the Binutils distribution, e.g.
  4226. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bnu27b.zip.
  4227.  
  4228. 
  4229. File: djgppfaq.info,  Node: I/O bound programs,  Next: No profile,  Prev: Gprof docs,  Up: Profiling
  4230.  
  4231. 13.5 Why is `__dpmi_int' so heavily used?
  4232. =========================================
  4233.  
  4234. **Q*: I've profiled my program and found that the routine which takes 60% of
  4235. the running time is some obscure library function called `__dpmi_int.'  Can't
  4236. you guys make your library right?*
  4237.  
  4238. *A* :  Does your program use I/O or other real-mode services (like BIOS)
  4239. extensively?  All those services are invoked through a DPMI service call
  4240. which is issued by `__dpmi_int.'  So what the profile really says is that the
  4241. running time of your program is governed by time-consuming operations such as
  4242. disk I/O.
  4243.  
  4244. 
  4245. File: djgppfaq.info,  Node: No profile,  Prev: I/O bound programs,  Up: Profiling
  4246.  
  4247. 13.6 `gprof' doesn't produce output
  4248. ===================================
  4249.  
  4250. **Q*: Every time I run the profiler it says "gmon.out: no such file or
  4251. directory" and no profile is produced.  What is this `gmon.out' and why won't
  4252. `gprof' compute the profile?*
  4253.  
  4254. *A* :  `gmon.out' is the file with raw execution counts and timing info that
  4255. `gprof' needs to produce the profile.  The file is written by the profiled
  4256. program when it exits.  If the file isn't created, it might be because one of
  4257. the following reasons:
  4258.  
  4259.    * You didn't compile and/or link your program with the `-pg' switch.  Note
  4260.      that *both* compilation and link need to be done with `-pg', because the
  4261.      functions that actually write the results to `gmon.out' are only linked
  4262.      in when `gcc' sees `-pg' on the link command line.
  4263.  
  4264.    * You have called `ld.exe' directly to link your program and forgot to
  4265.      mention the files and switches necessary for the profiled program
  4266.      operation.  You should use `gcc' to link your program instead of calling
  4267.      the linker directly; a `-pg' switch to `gcc' is all that it takes to
  4268.      make sure that the linker will get all the necessary arguments. (1)
  4269.      (*note No profile-Footnotes::)
  4270.  
  4271.    * Your program exited abnormally.  The function which generates `gmon.out'
  4272.      is registered with the `atexit' library function, and won't be called if
  4273.      the program was terminated in an abnormal way.  Make sure that your
  4274.      program exits with a call to `exit' library function or with a `return'
  4275.      statement in your `main' function.  For example, if your program dies
  4276.      with an exception or a signal, install a signal handler and make it call
  4277.      `exit.'
  4278.  
  4279. 
  4280. File: djgppfaq.info,  Node: No profile-Footnotes,  Up: No profile
  4281.  
  4282. (1)  If you absolutely need to call `ld.exe' directly, invoke `gcc' once with
  4283. a `-v' switch and you will see what the arguments are that you should pass to
  4284. the linker in your case.
  4285.  
  4286. 
  4287. File: djgppfaq.info,  Node: Performance,  Next: Memory,  Prev: Profiling,  Up: Top
  4288.  
  4289. 14. Run-time Performance of DJGPP Programs
  4290. ******************************************
  4291.  
  4292.   This chapter deals with issues pertinent to run-time performance of DJGPP
  4293. programs.
  4294.  
  4295. * Menu:
  4296.  
  4297. * How fast::                 What code quality should you expect.
  4298. * Faster v1::                Is v1.x faster than v2?
  4299. * Pentium::                  DJGPP programs on a Pentium.
  4300. * I/O speed::                Is I/O *really* so slow in protected mode?
  4301. * Slow-down::                What if your ported program runs slower?
  4302.  
  4303. 
  4304. File: djgppfaq.info,  Node: How fast,  Next: Faster v1,  Prev: Performance,  Up: Performance
  4305.  
  4306. 14.1 How efficient is DJGPP-generated code?
  4307. ===========================================
  4308.  
  4309. **Q*: How does DJGPP compare with other DOS-based C compilers in terms of
  4310. efficiency of generated code?*
  4311.  
  4312. **Q*: Won't my program run *much* slower when compiled by DJGPP, due to all
  4313. those CPU cycles wasted in switches between protected and real mode?*
  4314.  
  4315. *A* :  The quality of code generated by GCC with optimization turned on
  4316. (`-O2' switch to the compiler) is generally at least as good as what you will
  4317. get from top commercial products, like Borland, Microsoft and Watcom.  Mode
  4318. switches indeed have a certain performance hit, but in most programs it is
  4319. negligibly small, because only DOS and BIOS services require such a switch,
  4320. and most programs spend most of their time doing other things.
  4321.  
  4322. 
  4323. File: djgppfaq.info,  Node: Faster v1,  Next: Pentium,  Prev: How fast,  Up: Performance
  4324.  
  4325. 14.2 Comparing v2 with DJGPP v1.x
  4326. =================================
  4327.  
  4328. **Q*: I switched to v2 and my programs now run slower than when compiled with
  4329. v1.x...*
  4330.  
  4331. **Q*: I timed a test program and it seems that DJGPP v2.01 produces slower
  4332. executables than v2.0, which in turn was slower than v1.x.  Why are we giving
  4333. up so much speed as we get newer versions?*
  4334.  
  4335. *A* :  In general, GCC 2.7.2 which comes with DJGPP v2.0 generates tighter,
  4336. faster code, than GCC 2.6.3 which came with v1.x.  But it sometimes produces
  4337. buggy code when "strength reduction" optimizations are enabled.  So DJGPP
  4338. v2.0 by default disables this kind of optimization, which might sometimes
  4339. yield slower code.  If you need extra speed, first debug your program with
  4340. default optimization options, and then recompile with `-fstrength-reduce'
  4341. switch to see if that makes any difference; or upgrade to DJGPP v2.01 where
  4342. GCC doesn't have this bug.
  4343.  
  4344. Comparison between GCC 2.7.2 (in v2.0) and 2.7.2.1 (in v2.01) shows that
  4345. 2.7.2.1 optimizes just as well as 2.7.2, but it takes a different combination
  4346. of the optimization-related options to achieve the greatest speed in each
  4347. compiler version.  The default optimization options has also changed; for
  4348. example, `--force-mem' is switched on by `-O2' in 2.7.2.1; it wasn't before.
  4349. GCC offers a plethora of optimization options which might make your code
  4350. faster or slower (see the GCC docs for a complete list); the best way to find
  4351. the correct combination for a given program is to profile and experiment.
  4352. Elliott Oti <e.oti@stud.warande.ruu.nl> suggests the following tips:
  4353.  
  4354.    * Compile your code with the ordinary compilation switches `-O2 -m486
  4355.      -fomit-frame-pointer -ffast-math'.
  4356.  
  4357.    * Profile your code and check which functions are "hot spots".
  4358.      Disassemble them, or compile with `-S', and examine the machine code.
  4359.  
  4360.    * If the disassenbly shows there aren't too many memory accesses inside
  4361.      the inner loops, try adding `-fforce-addr' option; it helps a lot if a
  4362.      couple of pointers are used heavily within a single loop.  If there are
  4363.      a lot of memory references, try adding `-fno-force-mem', to prevent GCC
  4364.      from repeatedly copying variables from memory into registers.
  4365.  
  4366.    * Try adding `-funroll-loops' and `-funroll-all-loops' and profile the
  4367.      effect.
  4368.  
  4369.    * If different time-critical functions exhibit different behavior under
  4370.      some of the optimization options, try compiling them with the best
  4371.      combination for each one of them.
  4372.  
  4373. 
  4374. File: djgppfaq.info,  Node: Pentium,  Next: I/O speed,  Prev: Faster v1,  Up: Performance
  4375.  
  4376. 14.3 DJGPP programs on a Pentium
  4377. ================================
  4378.  
  4379. **Q*: Does DJGPP support Pentium-specific optimizations?*
  4380.  
  4381. **Q*: I run the same program on a 486 and on a Pentium, and it's slower on a
  4382. Pentium!!*
  4383.  
  4384. *A* : DJGPP doesn't add to, or otherwise change the compiler features offered
  4385. by GCC.  DJGPP is just a port of GCC to MSDOS.  Since GCC (as of version
  4386. 2.7.2.1) doesn't support Pentium-specific optimizations, neither does DJGPP.
  4387.  
  4388. A program might sometimes run slower on a Pentium due to alignment problems
  4389. in DJGPP.  GCC makes assumptions about how GAS (the assembler) handles
  4390. alignment, but when GAS is built with the default DJGPP configuration, it
  4391. treats alignment in a way that's different from what GCC assumes.  The
  4392. outcome of this is that longs are word-aligned, doubles are dword-aligned,
  4393. etc.  Depending on the DJGPP version, link order, library differences, you
  4394. might get lucky (or unlucky) with a 50/50 chance to get an improper
  4395. alignment.  Different CPUs have different penalties for unaligned accesses,
  4396. which may explain differences in speed.
  4397.  
  4398. You might consider adding some slack static variables to induce changes in
  4399. alignment; if any of the changes suddenly cause a significant change in the
  4400. runtime performance, then alignment might be the reason.
  4401.  
  4402. 
  4403. File: djgppfaq.info,  Node: I/O speed,  Next: Slow-down,  Prev: Pentium,  Up: Performance
  4404.  
  4405. 14.4 My program's I/O is so slow!
  4406. =================================
  4407.  
  4408. **Q*: I measured the time required to read a 2 MByte file in DJGPP and in
  4409. Borland C.  It took the DJGPP program 2.5 seconds to do it, while Borland did
  4410. it in just under 2.  Isn't that *horribly* slow performance??*
  4411.  
  4412. **Q*: I tried to improve DJGPP I/O throughput by defining a 64KB-large buffer
  4413. for buffered I/O with a call to `setvbuf', but that had no effect.  Why is
  4414. that?*
  4415.  
  4416. *A* :  Doing I/O from protected-mode programs requires that low-level library
  4417. functions move the data between the extended memory and low memory under the
  4418. 1 MByte mark, where real-mode DOS can get at it.  That area in the low memory
  4419. is called the "transfer buffer".  This data shuffling means that some I/O
  4420. speed degradation is inevitable in any protected-mode program which runs
  4421. under DOS (including, for example, Windows programs when Windows is set to
  4422. 386-Enhanced mode).  By default, DJGPP moves data in chunks of 16 KB, so
  4423. defining a buffer larger than that won't gain anything.  The size of transfer
  4424. buffer is customizable up to a maximum of 64 KB, so if your program really
  4425. reads a lot of large files, you might be better off enlarging it (with the
  4426. `STUBEDIT' program).
  4427.  
  4428. Some programs which only copy data between two files might gain significantly
  4429. if you write your custom low-level I/O functions that avoid moving data to
  4430. extended memory (only to move them back to the transfer buffer).  However,
  4431. these cases are rare.
  4432.  
  4433. That said, I would like to point out that waiting another 0.5sec for reading
  4434. a 2 MByte file isn't that bad: it is indeed about 25% longer than you can do
  4435. under DOS, but it's only half a second...  Besides, most programs read and
  4436. write files which are only a few hundreds of kilobytes, and those will suffer
  4437. only a negligible slow-down.
  4438.  
  4439. 
  4440. File: djgppfaq.info,  Node: Slow-down,  Prev: I/O speed,  Up: Performance
  4441.  
  4442. 14.5 My ported program runs much slower!
  4443. ========================================
  4444.  
  4445. **Q*: How come my program, which I ported from Borland/MS C and which doesn't
  4446. use much I/O, still runs much slower under DJGPP? *
  4447.  
  4448. *A* :  Explore the following possible causes for this:
  4449.  
  4450.   a. Your program extensively calls services other than I/O which require mode
  4451.      switch (like BIOS Int 10h, mouse services, etc.).
  4452.  
  4453.      You can tell how much your program switches to real mode by profiling
  4454.      your program.  In the profile, look at the proportion of time your
  4455.      program spends in low-level library functions called `__dpmi_int' (which
  4456.      calls real-mode DOS/BIOS services) and `__dj_movedata' (which moves data
  4457.      between the transfer buffer and your program).  If this proportion is
  4458.      large, try rewriting your program to minimize use of those functions
  4459.      which require a mode switch, even at a price of more computation (a mode
  4460.      switch usually eats up hundreds of CPU cycles).
  4461.  
  4462.   b. Your program uses library functions/classes which are implemented less
  4463.      efficiently by GCC.  Or you might be a heavy user of functions which
  4464.      other compilers convert to inline code, while GCC doesn't inline most
  4465.      library functions.  If this is the case, you will see those functions as
  4466.      "hot spots" on the program histogram produced by the `Gprof' profiler.
  4467.      If you find this to be the problem, write your own, optimized versions of
  4468.      those functions.  It's best to write them as inline assembly functions,
  4469.      for maximum performance.  If you find library functions which are
  4470.      inefficient, please inform the DJGPP news group by posting to the
  4471.      comp.os.msdos.djgpp news group, so this could be fixed by people who
  4472.      maintain the library.
  4473.  
  4474.   c. If your program spends most of its time in a certain innermost loop, you
  4475.      should try enabling some of the optimization options which aren't
  4476.      enabled by default.
  4477.  
  4478.  
  4479. 
  4480. File: djgppfaq.info,  Node: Memory,  Next: Command line,  Prev: Performance,  Up: Top
  4481.  
  4482. 15. Run-Time Memory Issues
  4483. **************************
  4484.  
  4485.   This chapter answers questions which are related to DJGPP run-time memory
  4486. allocation.
  4487.  
  4488. * Menu:
  4489.  
  4490. * How much memory::        How much can you use?
  4491. * Confusing alloc::        Allocation mechanism peculiarities.
  4492. * QDPMI VM::               QDPMI doesn't provide virtual memory.
  4493. * QDPMI alloc::            QDPMI/Win 95 memory allocation peculiarities.
  4494. * Windows alloc::          VM issues under Windows 3.x.
  4495. * Win9x alloc::            VM peculiarities under Win9x.
  4496. * EMM386 alloc::           Some versions of EMM386 are limited to 32 MBytes.
  4497. * Swap out::               How much VM do spawned program have?
  4498. * Stack size::             How large is the stack and how to enlarge it?
  4499.  
  4500. 
  4501. File: djgppfaq.info,  Node: How much memory,  Next: Confusing alloc,  Prev: Memory,  Up: Memory
  4502.  
  4503. 15.1 How much virtual memory do you have?
  4504. =========================================
  4505.  
  4506. **Q*: How much virtual memory can I use in DJGPP programs?*
  4507.  
  4508. *A* :  That depends on the DPMI host you are using.  CWSDPMI (the free DPMI
  4509. host which comes with DJGPP) will let you use all available conventional and
  4510. extended memory (up to 128M) and up to 128M of disk space, for a grand total
  4511. of 256M of virtual memory for your application.  Try a `malloc(50*1024*1024)'
  4512. some day.
  4513.  
  4514. With other DPMI hosts, your mileage may vary.  Quarterdeck's QDPMI, for
  4515. instance, has a bug in some of its versions which effectively disables
  4516. virtual memory under DJGPP (described in *Note QDPMI VM bug: QDPMI VM,
  4517. below), so you only have whatever free physical RAM is left.  Under Windows
  4518. 3.x, the amount of virtual memory you get depends on various virtual memory
  4519. settings in the Control Panel and on the `.pif' file settings for the program
  4520. you run (see *Note Windows allocation subtleties: Windows alloc, below).
  4521. Under Windows 9x, the memory settings of the DOS Applications' Property Sheet
  4522. define how much virtual memory a DJGPP program will get (see *Note Win9x
  4523. allocation details: Win9x alloc, below).
  4524.  
  4525. 
  4526. File: djgppfaq.info,  Node: Confusing alloc,  Next: QDPMI VM,  Prev: How much memory,  Up: Memory
  4527.  
  4528. 15.2 It seems `malloc'/`free' don't affect virtual memory...
  4529. ============================================================
  4530.  
  4531. **Q*: I did `malloc(50*1024*1024)', but didn't see any paging happen, and I
  4532. only have 8 MBytes of RAM on my machine.  Is this virtual memory thing for
  4533. real?*
  4534.  
  4535. **Q*: I `malloc''ed a large chunk of memory, but when I check values returned
  4536. by `_go32_remaining_physical_memory' or `__dpmi_get_memory_information', I
  4537. don't see any change...*
  4538.  
  4539. **Q*: When I `free' allocated RAM, `_go32_remaining_physical_memory' reports
  4540. there was no change in the available RAM.*
  4541.  
  4542. *A* :  CWSDPMI (and, possibly, other DPMI hosts) only pages in memory when it
  4543. is actually accessed.  If you only `malloc' it, but don't actually access it,
  4544. it won't grab those pages.  Try `calloc' and see the *big* difference.
  4545.  
  4546. When you call `free', DJGPP library doesn't return memory to the system, it
  4547. just adds it to its internal pool of free pages.  So, from the system point
  4548. of view, these pages are not "free".
  4549.  
  4550. 
  4551. File: djgppfaq.info,  Node: QDPMI VM,  Next: QDPMI alloc,  Prev: Confusing alloc,  Up: Memory
  4552.  
  4553. 15.3 Failure to get more memory than is physically installed
  4554. ============================================================
  4555.  
  4556. **Q*: When I try to access more memory than the free physical RAM, `malloc'
  4557. returns a `NULL' pointer, or I get some cryptic error message like this:*
  4558.  
  4559.      DPMI: Not enough memory (0x00860000 bytes)
  4560.  
  4561. *or like this:*
  4562.  
  4563.      QDPMI: Memory Paging Violation: Illegal Page Reference [PTE=0000-0000h]
  4564.             [CR2=8006-3000h at 00E7h:0000-4936h]
  4565.      
  4566.      QDPMI: Unrecoverable Exception: 000Eh at 00E7h:0000-4936h.  Error Code = 0006h
  4567.  
  4568. *A* :  This is typical of Quarterdeck's DPMI host called QDPMI which comes
  4569. with QEMM386 version 7.53 and earlier.  Some versions of QDPMI (those which
  4570. come with QEMM v6.x) fail to resize memory blocks when the new size is more
  4571. than the available physical RAM, even though virtual memory services are
  4572. enabled; other versions (those which come with QEMM v7.x) just don't let you
  4573. allocate more memory than is physically available.  If you must use more RAM
  4574. than is physically available, *Note disable or uninstall QDPMI: Old QDPMI,
  4575. and use CWSDPMI instead.
  4576.  
  4577. This bug was corrected in QDPMI version 1.10 or later, distributed with QEMM
  4578. beginning with version 8.0, so upgrading to the latest version of QEMM might
  4579. also be a solution.  With QEMM 6.x, make sure your programs don't override
  4580. the default type of `sbrk' behavior by setting `_crt0_startup_flags' to
  4581. `_CRT0_FLAG_UNIX_SBRK' (QEMM 8.0 and later can allocate virtual memory with
  4582. both types of `sbrk' algorithm).
  4583.  
  4584. If you use another DPMI host, make sure that virtual memory is enabled.
  4585. E.g., for 386Max, include the `swapfile=' parameter to establish a virtual
  4586. memory swap file; you can make it permanent (this will speed up DJGPP
  4587. start-up) with the `/p' option.
  4588.  
  4589. 
  4590. File: djgppfaq.info,  Node: QDPMI alloc,  Next: Windows alloc,  Prev: QDPMI VM,  Up: Memory
  4591.  
  4592. 15.4 Memory allocation fails before all memory is used
  4593. ======================================================
  4594.  
  4595. **Q*: OK, I've changed my program to never allocate more memory than is
  4596. physically available, to work around that *Note QDPMI VM bug: QDPMI VM, but
  4597. my program still gets a `NULL' pointer from `malloc/calloc'!*
  4598.  
  4599. **Q*: Why is my program dying with SIGSEGV under CWSDPMI when allocating a
  4600. chunk of memory?*
  4601.  
  4602. *A* :  Another peculiarity of QDPMI which came with QEMM before version 8.0:
  4603. it will never let you allocate a chunk which is larger than half of what's
  4604. available.  The Windows 3.x behaves in the same way, and several people
  4605. reported the same to be true under Windows 95.
  4606.  
  4607. With some DPMI providers, this behavior might be triggered by a small
  4608. overhead of each `malloc' call: you might ask for half of available memory,
  4609. but the DJGPP implementation of `malloc' adds the overhead and then rounds
  4610. the amount of memory to the next power of 2 before calling `sbrk'; thus
  4611. `malloc(8MB)' will actually request 16MBytes from the DPMI host.  When in
  4612. doubt, call `sbrk' directly, especially if you don't plan to free that memory
  4613. during execution.
  4614.  
  4615. If your program asks for memory in lots of small allocations, then it might
  4616. crash when you use CWSDPMI as your DPMI host.  This is because CWSDPMI runs
  4617. out of its tables where it tracks memory allocations.  If you use release 1
  4618. of CWSDPMI, you can enlarge the maximum space that CWSDPMI uses if you get a
  4619. CWSDPMI heap-fix patch, e.g.
  4620. ftp://ftp.neosoft.com/pub/users/s/sandmann/csdpmi1heapfix.zip.  Beginning
  4621. with release 2, CWSDPMI defines a larger (6KB) default heap that is
  4622. configurable by CWSPARAM program to be anywhere between 3K and 40K bytes,
  4623. without recompiling CWSDPMI.  You should upgrade to the latest CWSDPMI if you
  4624. experience such problems.
  4625.  
  4626. 
  4627. File: djgppfaq.info,  Node: Windows alloc,  Next: Win9x alloc,  Prev: QDPMI alloc,  Up: Memory
  4628.  
  4629. 15.5 Memory allocation fails under Windows
  4630. ==========================================
  4631.  
  4632. **Q*: I'm running under Windows 3.x DOS box, but DJGPP complains about there
  4633. not being enough DPMI memory, although virtual memory is enabled.*
  4634.  
  4635. *A* :  You must make sure the size of your Windows swap file can be at least
  4636. 2 times the largest virtual memory size you need.  Check if you have enough
  4637. free disk space; if you do, run a defragger (Windows needs the swap file to
  4638. be contiguous).  This size is normally limited by the the "virtual = 4 times
  4639. free physical" rule, but you can change that by inserting the line
  4640.  
  4641.       PageOverCommit=n
  4642.  
  4643. in the `[386Enh]' section of your `SYSTEM.INI' file.  The parameter `n' is 4
  4644. by default, but can be set to be as large as 20.
  4645.  
  4646. 
  4647. File: djgppfaq.info,  Node: Win9x alloc,  Next: EMM386 alloc,  Prev: Windows alloc,  Up: Memory
  4648.  
  4649. 15.6 Memory allocation peculiarities under Windows 9x
  4650. =====================================================
  4651.  
  4652. **Q*: I seem to be unable to get more than 16 MBytes of virtual memory under
  4653. Windows 95, even though I have 32 MBytes of RAM installed on my machine, and
  4654. a lot of disk space...*
  4655.  
  4656. *A* :  You must set the maximum amount of DPMI memory to 65535K in the DOS
  4657. applications' property sheet.  If you leave that setting at the default
  4658. "Auto", you only get 16 MBytes.  You must actually type 65535 inside the
  4659. dialog box, as checking out the values from the list Windows offers will
  4660. never get you past 16384 (i.e., 16MB).
  4661.  
  4662. Note that you cannot allocate more than half the available memory in one
  4663. chunk under Windows 9x, exactly as the things are under Win3.x, and you
  4664. cannot have more than 64 MBytes of virtual memory available to DJGPP programs
  4665. running on Windows.
  4666.  
  4667. 
  4668. File: djgppfaq.info,  Node: EMM386 alloc,  Next: Swap out,  Prev: Win9x alloc,  Up: Memory
  4669.  
  4670. 15.7 Memory allocation fails under EMM386 or HIMEM
  4671. ==================================================
  4672.  
  4673. **Q*: My machine has 48 MBytes of RAM, but when I run DJGPP programs, they
  4674. start paging after 32 MBytes have been used...*
  4675.  
  4676. **Q*: I have 5 MBytes of free RAM on my machine, but DJGPP programs start
  4677. paging after only 256KBytes of memory were used??*
  4678.  
  4679. *A* :  This might be caused by some old versions of the memory manager
  4680. installed in your machine (like HIMEM or EMM386 from an old version of DOS),
  4681. which were limited to 32 MBytes of expanded memory.  Try running without them
  4682. (CWSDPMI can use raw extended memory), or upgrade to a newer version of DOS.
  4683.  
  4684. If your programs start paging after only 256KBytes of memory were used, most
  4685. probably you are using EMM386 and CWSDPMI, and your `CONFIG.SYS' specifies no
  4686. amount of memory when it installs EMM386.  EMM386 defaults to 256K in this
  4687. case; you should tell EMM386 explicitly how much memory it should take over.
  4688. You can use the `go32-v2' program to see what amount of extended memory your
  4689. DJGPP programs will get.
  4690.  
  4691. 
  4692. File: djgppfaq.info,  Node: Swap out,  Next: Stack size,  Prev: EMM386 alloc,  Up: Memory
  4693.  
  4694. 15.8 How much memory do parent DJGPP programs leave for their child?
  4695. ====================================================================
  4696.  
  4697. **Q*: How much memory is available when I call the `system' library function?*
  4698.  
  4699. *A* :  In the conventional (below 640K mark) memory, you are left with
  4700. everything which was free before your program started, except what the DPMI
  4701. host uses.  The amount of conventional memory required by the DPMI host
  4702. depends heavily on the host you use.  For the first DJGPP program, QDPMI uses
  4703. about 97K, CWSDPMI uses about 70K, Windows 3.x only 18 KBytes.  Each
  4704. subsidiary call to `system' (like in recursive invocation of `Make') eats up
  4705. about 18K (16K for the transfer buffer and 2K for the PSP and environment)
  4706. for most DPMI servers; a notable exception is QDPMI which needs 97K bytes of
  4707. low memory for the subsequent calls too.  If you change the size of the
  4708. transfer buffer (with `STUBEDIT'), the amount of free conventional RAM will
  4709. change accordingly.
  4710.  
  4711. Extended memory management is left to the DPMI server; DJGPP does nothing
  4712. special about XMS when `system' is called.  This means that all the extended
  4713. memory used by the parent program is *not* freed when the child program
  4714. starts; if the child requests more memory than is physically free, the DPMI
  4715. server is expected to page some of the parent out to honor the request.
  4716. (This is unlike DJGPP v1.x, where the `go32' extender would completely page
  4717. out the parent before starting the child.)  The advantage of this is that
  4718. spawning a child or shelling out is much faster in v2 than it used to be with
  4719. v1.x, except on machines with low amounts of installed RAM.  A disadvantage
  4720. is that if you spawn a real-mode program that uses XMS, the extended memory
  4721. used up by your DJGPP program will be unavailable to it, unless you use a
  4722. memory manager (as opposed to when CWSDPMI uses raw XMS or HIMEM).  The only
  4723. way around this problem is to buy more RAM, or to install a real memory
  4724. manager.
  4725.  
  4726. Note that if you use a memory manager such as EMM386 or QEMM386 with the
  4727. NOEMS parameter, CWSDPMI will use the XMS (as opposed to VCPI) services to
  4728. allocate extended memory, and will allocate all of the available XMS memory
  4729. for itself.  So if, while your DJGPP program runs, some resident software
  4730. such as device driver or TSR will try to allocate XMS, the allocation will
  4731. fail.
  4732.  
  4733. 
  4734. File: djgppfaq.info,  Node: Stack size,  Prev: Swap out,  Up: Memory
  4735.  
  4736. 15.9 How much stack can I have in DJGPP programs?
  4737. =================================================
  4738.  
  4739. **Q*: My program bombs when I use very large automatic arrays.*
  4740.  
  4741. **Q*: How much stack space do I have in my program?*
  4742.  
  4743. **Q*: My program seems to overflow the stack, but only when I run it under a
  4744. debugger...*
  4745.  
  4746. **Q*: My program crashes with SIGSEGV, but the traceback makes no sense: it
  4747. points to something called ___djgpp_exception_table...  When I try to debug
  4748. this, the traceback mysteriously changes to some innocent library function,
  4749. like getc().  The same program works flawlessly when compiled with DJGPP v1.x
  4750. What is going on??*
  4751.  
  4752. *A* : DJGPP v2 programs get fixed-size stack which is allocated by the
  4753. startup code and then stays fixed for the entire lifetime of the program;
  4754. this is a bug/feature of the DPMI 0.9 specification.  By default, you have a
  4755. 256KB-long stack, but some programs which use large automatic arrays, or are
  4756. deeply recursive, might need more.  If the default stack size is not enough,
  4757. you can change it with the `STUBEDIT' program (change the parameter "Minimum
  4758. amount of stack space"), or by setting the global variable `_stklen' in your
  4759. program.  Example:
  4760.  
  4761.       unsigned _stklen = 1048576;  /* need a 1MB stack */
  4762.  
  4763. The DJGPP startup code checks both the value in the stub info and the value
  4764. of `_stklen', and uses the larger of these two.  Therefore, programs that are
  4765. known to require large stack size should set `_stklen' to make sure they will
  4766. always work, even if somebody stub-edits them to a lower value.  This
  4767. technique is also safer when you need to debug your program with `gdb' (see
  4768. below).  However, you might need to use `STUBEDIT' with programs for which
  4769. you don't have the sources.
  4770.  
  4771. Programs which need an unusually large stack might crash with bogus stack
  4772. traces, because part of the heap gets overwritten by the overflowing stack.
  4773. To see if that is the cause of such crashes, run `STUBEDIT' on your program
  4774. and crank up the stack size to a large value (like 4MBytes).  If that makes
  4775. the problem go away, tune the stack limit to the minimum value your program
  4776. can live with, then set `_stklen' to an appropriate value as explained above
  4777. and recompile the program.  (Some DPMI hosts will actually allocate the
  4778. entire stack, even if not all of it is used, so leaving it at unnecessarily
  4779. large value will hurt the program on low-memory machines.)
  4780.  
  4781. Some users have reported that they needed to enlarge the stack size of the
  4782. C++ compiler, `cc1plus.exe', to prevent it from crashing when compiling some
  4783. exceedingly large and complex C++ programs.  Another program that was
  4784. reported to need a stack larger than the default is `bccbgi.exe' from the
  4785. `BCC2GRX' package.
  4786.  
  4787. After you've used `STUBEDIT' to change the stack size, run it again to make
  4788. sure it displays as default the value you thought you entered.  This is
  4789. because `STUBEDIT' will sometimes silently set the stack size to 0 (and then
  4790. you will get the default 256K stack) if it doesn't like the value you type
  4791. (e.g. if it has a wrong syntax).
  4792.  
  4793. When you run a program as an un-stubbed COFF image under a debugger, the
  4794. stack size comes from the debugger.  So if your program needs a large stack
  4795. and you run it under `gdb', be sure to stubedit `gdb' to enlarge its stack to
  4796. at least the value your program needs to run safely.
  4797.  
  4798. Under Windows, be sure you've allocated a sufficiently large swap file (let's
  4799. say, 40MBytes) from the Windows' Control Panel, and make sure the `.PIF' file
  4800. for your program doesn't have too low limit on EMS/XMS usage (better make
  4801. them both -1).  What's that?  You don't have a `.PIF' file for this program?
  4802. Then Windows uses the default file `DOSPRMPT.PIF', which almost surely
  4803. defines very low limits on these two, and your program might have problems
  4804. getting the memory it needs for its stack.
  4805.  
  4806. DJGPP v2.0 has a subtle bug in its startup code that is seen very rarely, and
  4807. that manifests itself by a program crashing with Page Fault or SIGSEGV.  If
  4808. you are using v2.0 and enlarging the stack and the CWSDPMI heap size didn't
  4809. help, try adding some (e.g., 4KB) static data to your program and see if that
  4810. helps.  But the best way to overcome this is to upgrade to DJGPP v2.01 or
  4811. later.
  4812.  
  4813. 
  4814. File: djgppfaq.info,  Node: Command line,  Next: Converting,  Prev: Memory,  Up: Top
  4815.  
  4816. 16. Command-line Arguments Handling in DJGPP
  4817. ********************************************
  4818.  
  4819.   DJGPP handles command-line arguments differently from most DOS-based
  4820. compilers, to make it closer to Unix platforms (so that porting of Unix
  4821. programs will be easier).  This chapter answers some questions about this
  4822. aspect of DJGPP.
  4823.  
  4824. * Menu:
  4825.  
  4826. * Filename globbing::         Wildcard expansion under DJGPP
  4827. * Disable globbing::          You can disable globbing if you don't need it.
  4828. * Special chars::             How to pass arguments with special chars.
  4829. * Long commands::             DJGPP can pass very long command lines.
  4830. * How long::                  Look here to find out how long.
  4831. * Makefiles::                 Makefiles can disable long command lines.
  4832.  
  4833. 
  4834. File: djgppfaq.info,  Node: Filename globbing,  Next: Disable globbing,  Prev: Command line,  Up: Command line
  4835.  
  4836. 16.1 Filename wildcards expansion under DJGPP
  4837. =============================================
  4838.  
  4839. **Q*: Can I do filename globbing with DJGPP?*
  4840.  
  4841. **Q*: I call my program with an argument `x*y' and it complains about
  4842. something called `xyzzy'??...*
  4843.  
  4844. *A* :  The filename globbing in DJGPP is done by the start-up code, before
  4845. your `main' function is called.  Unlike other DOS-based compilers, where you
  4846. must link your program with a special object module if you want the program
  4847. to get expanded filenames, in DJGPP this is considered normal behavior and
  4848. performed by default on behalf of every DJGPP program.  The `x*y' above was
  4849. expanded to a file called `xyzzy' which was probably present in the current
  4850. working directory.  (If you don't want the default expansion, see *Note how
  4851. to disable globbing: Disable globbing.)
  4852.  
  4853. In DJGPP, filename globbing works like in Unix, which is more general than
  4854. the usual DOS wildcard expansion.  It understands the following constructs
  4855. with special meta-characters:
  4856.  
  4857. `?'
  4858.      any single character.
  4859.  
  4860. `*'
  4861.      zero or more arbitrary characters, including a dot `.'
  4862.  
  4863. `[aA_]'
  4864.      any one of characters `a', `A', or `_'.
  4865.  
  4866. `[a-d]'
  4867.      any one of characters `a', `b', `c', or `d'.
  4868.  
  4869. `[!a-z]'
  4870.      anything *but* a lowercase letter.
  4871.  
  4872. `...'
  4873.      all the subdirectories, recursively (VMS aficionados, rejoice!).
  4874.  
  4875. `.../*'
  4876.      all the files in all subdirectories, recursively.
  4877.  
  4878. Unlike DOS, the `*' and `?' meta-characters can appear *anywhere* in the
  4879. filename pattern, like in `[a-z]*[0-9].*pp.' You can also use `*' instead of
  4880. directories, like in `*/*/*.c', but *not* on drive letters (e.g., `[a-c]:/'
  4881. won't work).
  4882.  
  4883. Note that `*.*' only picks up files that actually have an extension.  This is
  4884. contrary to the usual DOS practice where it means *all* the files, with or
  4885. without extension.
  4886.  
  4887. An argument which cannot be expanded (no filenames matching that particular
  4888. pattern) will be passed to the program verbatim.  This is different from what
  4889. you might see under Unix, where some shells (like `csh') would say something
  4890. like "No match" and won't call your program at all.  DJGPP's behavior in this
  4891. case is like shells of the Bourne legacy (`sh', `ksh', and `bash').
  4892.  
  4893. 
  4894. File: djgppfaq.info,  Node: Disable globbing,  Next: Special chars,  Prev: Filename globbing,  Up: Command line
  4895.  
  4896. 16.2 How to disable filename wildcards expansion
  4897. ================================================
  4898.  
  4899. **Q*: OK, but I don't want my program to glob its arguments (they aren't
  4900. files at all, but they include characters like `*' and `?').  What should I
  4901. do?*
  4902.  
  4903. *A* :  You have these alternatives:
  4904.  
  4905.    * Surround your arguments with single or double quotes (this is what you
  4906.      would do under a Unix shell).
  4907.  
  4908.    * Disable globbing for your program by linking it with your custom version
  4909.      of the function with the special name `__crt0_glob_function' and make it
  4910.      always return a `NULL' pointer.  See the documentation of this function
  4911.      in the library reference.
  4912.  
  4913. 
  4914. File: djgppfaq.info,  Node: Special chars,  Next: Long commands,  Prev: Disable globbing,  Up: Command line
  4915.  
  4916. 16.3 How to pass command-line arguments with quotes or <@>
  4917. ==========================================================
  4918.  
  4919. **Q*: I have a file with a single quote in its name, but the quote seems to
  4920. be stripped away when I pass it to my program ...*
  4921.  
  4922. **Q*: How do I pass a command-line argument which contains double quotes? *
  4923.  
  4924. **Q*: How do I pass an argument which begins with the <@> character?*
  4925.  
  4926. *A* :  These special characters on the command-line arguments are handled by
  4927. the filename expansion ("globbing") code before they are passed to the `main'
  4928. function (*note description of filename expansion: Filename globbing.), and
  4929. the quote characters serve to protect the arguments from expansion.  You
  4930. should escape-protect the quote characters with a backslash in order for them
  4931. to be treated as literal characters.  For example, if you have a file called
  4932. `myfile.c'v', type it as `myfile.c\'v' when you call your program.  If you
  4933. have single quotes in your program arguments *and* you don't want those
  4934. arguments to be expanded, then surround them by double quotes, like this:
  4935. `"*.c'v".'  The program will get the string `*.c'v' with the double quotes
  4936. stripped away.
  4937.  
  4938. Note that backslashes are only special if they are in front of a quote,
  4939. whitespace, or backslash (they also serve as DOS directory separators,
  4940. remember?).  This is also different from what you get under a Unix shell.
  4941.  
  4942. The <@> character serves to signal a "response file" (*note the description
  4943. of response file method: Long commands.), so it's also special.  To pass an
  4944. argument whose first character is <@>, surround that argument with single or
  4945. double quotes, otherwise it will be taken as a name of a response file which
  4946. holds the actual command line.
  4947.  
  4948. 
  4949. File: djgppfaq.info,  Node: Long commands,  Next: How long,  Prev: Special chars,  Up: Command line
  4950.  
  4951. 16.4 How to pass command lines longer than 126 characters
  4952. =========================================================
  4953.  
  4954. **Q*: Can I invoke my program with a command line longer than the infamous
  4955. DOS 126-character limit?*
  4956.  
  4957. **Q*: I have a Makefile of Unix origin which contains some *very* long
  4958. command lines.  Will it work with DJGPP?*
  4959.  
  4960. *A* :  Yes and yes.  DJGPP supports several methods of passing command-line
  4961. arguments which allow it to work around the DOS 126-character limit.  These
  4962. are:
  4963.  
  4964.    * The `!proxy' method.  If you invoke the program from within another
  4965.      DJGPP program (like Make or Gcc compilation driver), it gets the address
  4966.      of the memory block where the actual command line is stored.  The
  4967.      start-up code will detect this and use that info to retrieve the
  4968.      command-line arguments.
  4969.  
  4970.      This method is suitable only for invoking DJGPP programs from other DJGPP
  4971.      programs.  You don't have to do anything special to use this method, it
  4972.      is all done automagically for you by the library functions like
  4973.      `system', `spawnXX' and `execXX' on the parent program side, and by the
  4974.      start-up code on the child side.  (1) (*note Long commands-Footnotes::)
  4975.  
  4976.    * The environment method.  This is the same as the `!proxy' method above,
  4977.      but the information about the long command line is stored in an
  4978.      environment variable called " !proxy" (with the leading blank and in
  4979.      lower-case).  The reason for two similar, but different methods is that
  4980.      command-line arguments passed by `system' library functions should be
  4981.      globbed by the child, while the arguments passed by `spawnXX' and
  4982.      `execXX' family of functions should not; thus the former uses the
  4983.      environment method while the latter use the `!proxy' method.
  4984.  
  4985.    * The response file method.  Any argument which starts with a <@>
  4986.      character (like in `myprog @file') will cause the named `file' to be
  4987.      read and its contents used as command-line arguments, like in many
  4988.      DOS-based compilers and linkers.  If you invoke your DJGPP program from
  4989.      the DOS command line, this would be the only method available for you to
  4990.      pass long command lines (like when calling `Gawk' or `Sed' without `-f'
  4991.      option).
  4992.  
  4993.      Note that this method makes <@> special when it is the first (or the
  4994.      only) character of a command-line argument, which should be
  4995.      escape-protected if you want to use it verbatim (*note how to pass the @
  4996.      character: Special chars.).
  4997.  
  4998. Of course, if the start-up code doesn't see any of the above methods, it will
  4999. use the command line by default.
  5000.  
  5001. 
  5002. File: djgppfaq.info,  Node: Long commands-Footnotes,  Up: Long commands
  5003.  
  5004. (1)  In case you wonder, the name `!proxy' comes from the the string which
  5005. identifies the use of this method: instead of getting the actual command
  5006. line, the program gets `!proxy' followed by the address of the actual command
  5007. line.
  5008.  
  5009. 
  5010. File: djgppfaq.info,  Node: How long,  Next: Makefiles,  Prev: Long commands,  Up: Command line
  5011.  
  5012. 16.5 What is the maximum length of command line under DJGPP
  5013. ===========================================================
  5014.  
  5015. **Q*: What is the longest command line I can pass to gcc when it is invoked
  5016. by `Make'?*
  5017.  
  5018. *A* :  The arguments are passed to DOS Exec call (Int 21h function 4Bh) via
  5019. the transfer buffer which is 16KB-long.  Apart of the command line, it is
  5020. also used to pass other info, such as the `!proxy' parameters and the copy of
  5021. the environment for the child program (let's say, less than 2000 bytes in
  5022. most cases, but your mileage may vary).  This leaves at least 13K bytes for
  5023. arguments (including a separating blank between any two arguments).  So
  5024. unless your arguments span more than 160 screen lines, you shouldn't worry.
  5025. However, if your environment is *very* large (some people need as much as 6KB
  5026. to accommodate for all the variables used by the various packages installed
  5027. on their machine), be sure to stub-edit the programs that spawn other
  5028. programs to larger transfer buffer, or else they could fail.
  5029.  
  5030. The above limit depends on the size of the transfer buffer, so check the size
  5031. of the value recorded in the stub header of the *parent program* before you
  5032. pass extremely long command lines to its children.  GCC is the first program
  5033. you should worry about, because the linker (`ld.exe') usually gets long
  5034. command lines from GCC (they include the list of all the object files and
  5035. libraries to be linked).
  5036.  
  5037. 
  5038. File: djgppfaq.info,  Node: Makefiles,  Prev: How long,  Up: Command line
  5039.  
  5040. 16.6 Why Make passes only 126 characters to programs?
  5041. =====================================================
  5042.  
  5043. **Q*: I use Make to compile with GCC, but GCC gets only the first 126
  5044. characters of its command line.  Didn't you just explain in so many words
  5045. that invoking a DJGPP program (GCC) from another DJGPP program (Make) can
  5046. safely pass up to 13K characters of command-line arguments using the `!proxy'
  5047. method?*
  5048.  
  5049. *A* :  If you use Make 3.73, check your Makefile for `SHELL = command.com'
  5050. statements, or for commands which include pipe or redirection characters like
  5051. `>', `|', etc.  If Make sees any such statements, it will invoke
  5052. `COMMAND.COM' to run GCC, and `COMMAND.COM' can't pass more than 126
  5053. characters to GCC.  To work around, comment-out the `SHELL=' line, and change
  5054. your commands to work without redirection/pipe characters.  One easy way to
  5055. get rid of redirection characters without losing their effect is to use the
  5056. `redir' program which comes with DJGPP.  For example, the following command:
  5057.  
  5058.        frobnicate foo.bar > myfile.tmp
  5059.  
  5060. can be re-written instead like this:
  5061.  
  5062.        redir -o myfile.tmp frobnicate foo.bar
  5063.  
  5064. The port of Make 3.75 which comes with DJGPP v2.01 doesn't call `COMMAND.COM'
  5065. in the above cases, but rather emulates pipes and redirection internally, so
  5066. upgrading to v2.01 will solve such problems.  If you think about using Make
  5067. 3.75 with DJGPP v2.0, don't: invoking v2.0 programs from v2.01 programs will
  5068. cause subtle and hard-to-debug problems due to incompatibilities between
  5069. these two versions regarding the methods of invoking child programs (in
  5070. particular, v2.0 doesn't support the environment method of passing long
  5071. command lines described above).
  5072.  
  5073. 
  5074. File: djgppfaq.info,  Node: Converting,  Next: Low-level,  Prev: Command line,  Up: Top
  5075.  
  5076. 17. Converting DOS Programs/Libraries to DJGPP
  5077. **********************************************
  5078.  
  5079.   If you have a program or a library developed under some other DOS-based
  5080. compiler, which you want to port to DJGPP, read this chapter.
  5081.  
  5082. * Menu:
  5083.  
  5084. * Syntax::                  The (AT&T) syntax of Gas is different.
  5085. * Gas bugs::                Don't trust Gas!
  5086. * Converting ASM::          Automated conversion tool.
  5087. * ASM GPF::                 When converted code crashes.
  5088. * OBJ and LIB::             You can't use them with GCC.
  5089. * 16-bit code::             ...or can you?
  5090. * NEAR and FAR::            How to convert these to DJGPP.
  5091. * Pseudo-registers::        Converting _AX to DJGPP code.
  5092.  
  5093. 
  5094. File: djgppfaq.info,  Node: Syntax,  Next: Gas bugs,  Prev: Converting,  Up: Converting
  5095.  
  5096. 17.1 GCC/Gas won't accept valid assembly code ...
  5097. =================================================
  5098.  
  5099. **Q*: I have some code written in assembly which compiles under `MASM' and
  5100. `TASM', but GCC gives me a long list of error messages.*
  5101.  
  5102. *A* :  The GNU Assembler (`as.exe'), or `Gas' called by GCC accepts "AT&T"
  5103. syntax, which is different from "Intel" syntax.  Notable differences between
  5104. the two syntaxes are:
  5105.  
  5106.    * AT&T immediate operands are preceded by `$'; Intel immediate operands
  5107.      are undelimited (Intel `push 4' is AT&T `pushl $4').
  5108.  
  5109.    * AT&T register operands are preceded by `%'; Intel register operands are
  5110.      undelimited.  AT&T absolute (as opposed to PC-relative) `jump'/`call'
  5111.      operands are prefixed by `*'; they are undelimited in Intel syntax.
  5112.  
  5113.    * AT&T and Intel syntax use the opposite order for source and destination
  5114.      operands.  Intel `add eax, 4' is `addl $4, %eax' in AT&T syntax.
  5115.  
  5116.      The `source, dest' convention is maintained for compatibility with
  5117.      previous Unix assemblers, so that GCC won't care about the assembler with
  5118.      which it is configured, as some of GCC installations (on systems other
  5119.      than MS-DOS) don't use GNU Binutils.
  5120.  
  5121.    * In AT&T syntax, the size of memory operands is determined from the last
  5122.      character of the opcode name.  Opcode suffixes of `b', `w', and `l'
  5123.      specify byte (8-bit), word (16-bit), and long (32-bit) memory
  5124.      references.  Intel syntax accomplishes this by prefixing memory operands
  5125.      (*not* the opcodes themselves) with ``byte ptr'', ``word ptr'', and
  5126.      ``dword ptr'.'  Thus, Intel `mov al, byte ptr FOO' is `movb FOO, %al' in
  5127.      AT&T syntax.
  5128.  
  5129.    * Immediate form long jumps and calls are `lcall/ljmp $SECTION, $OFFSET'
  5130.      in AT&T syntax; the Intel syntax is `call/jmp far SECTION:OFFSET.'
  5131.      Also, the far return instruction is `lret $STACK-ADJUST' in AT&T syntax;
  5132.      Intel syntax is `ret far STACK-ADJUST.'
  5133.  
  5134.    * The AT&T assembler does not provide support for multiple-section (aka
  5135.      multi-segment) programs.  Unix style systems expect all programs to be
  5136.      single-section.
  5137.  
  5138.    * An Intel syntax indirect memory reference of the form
  5139.  
  5140.            SECTION:[BASE + INDEX*SCALE + DISP]
  5141.  
  5142.      is translated into the AT&T syntax
  5143.  
  5144.            SECTION:DISP(BASE, INDEX, SCALE)
  5145.  
  5146. Examples:
  5147.  
  5148.          *Intel:*  [ebp - 4]         *AT&T:*  -4(%ebp)
  5149.          *Intel:*  [foo + eax*4]     *AT&T:*  foo(,%eax,4)
  5150.          *Intel:*  [foo]             *AT&T:*  foo(,1)
  5151.          *Intel:*  gs:foo            *AT&T:*  %gs:foo
  5152.  
  5153. For a complete description of the differences, get and unzip the files named
  5154. `as.iN' (where `N' is a digit) from the bnu27b.zip, e.g.
  5155. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/bnu27b.zip archive, then
  5156. see *Note i386-dependent features: (as)i386-Dependent.  If you don't read
  5157. this FAQ with an Info browser, type at the DOS prompt:
  5158.  
  5159.       info as machine i386
  5160.  
  5161. You will see a menu of `Gas' features specific to x86 architecture.
  5162.  
  5163. A guide is available which was written by Brennan Mr. Wacko Underwood
  5164. <brennan@mack.rt66.com>; it describes how to use inline assembly programming
  5165. with DJGPP and includes a tutorial on the AT&T assembly syntax.  Check out
  5166. the DJGPP inline assembly tutorial, at this URL:
  5167.  
  5168.      http://www.rt66.com/~brennan/djgpp/djgpp_asm.html
  5169.  
  5170. Many people who used Intel syntax and then converted to the AT&T style say
  5171. that they like the AT&T variant more.  However, if you prefer to stick with
  5172. the Intel syntax, download and install NASM, e.g.
  5173. ftp://ftp.simtel.net/pub/simtelnet/msdos/asmutl/nasm091.zip, which is a free
  5174. portable assembler.  It is compatible with DJGPP and accepts a syntax which
  5175. is almost 100% compatible with the Intel style.
  5176.  
  5177. 
  5178. File: djgppfaq.info,  Node: Gas bugs,  Next: Converting ASM,  Prev: Syntax,  Up: Converting
  5179.  
  5180. 17.2 Double-check code produced by Gas
  5181. ======================================
  5182.  
  5183. **Q*: My assembly code gets corrupted by `Gas'!*
  5184.  
  5185. *A* :  When writing assembly code, you should remember *to not trust Gas!*
  5186. You should always check that it does what you expect it to do.  GNU Assembler
  5187. can currently be trusted only when it assembles code produced by GCC.  All
  5188. other code--yours--is subject to the introduction of subtle errors.  To be
  5189. sure, use a debugger to check the code (even `objdump' from GNU Binutils
  5190. doesn't always treat segment overrides correctly).  The following lists some
  5191. guidelines for safer machine-language programming with `Gas':
  5192.  
  5193.   a. Use explicit sizing.  E.g., use `movl' instead of `mov', even if you're
  5194.      sure the arguments are 32-bit wide.  The fact that you use byte
  5195.      registers doesn't seem to matter with `Gas.'
  5196.  
  5197.   b. Write code segment overrides as `.byte' constants, not as e.g.  `%cs:.'
  5198.      According to Charles Sandmann <sandmann@clio.rice.edu>, `Gas' uses the
  5199.      current phase of the moon in deciding whether to ignore your prefixes.
  5200.      So unless you know *exactly* what the phase of the moon is at the moment
  5201.      of assembly, use `.byte' constants.
  5202.  
  5203.   c. Make sure the operands match the instructions.  Don't assume that if they
  5204.      don't, you'll get an error message from the assembler.
  5205.  
  5206. 
  5207. File: djgppfaq.info,  Node: Converting ASM,  Next: ASM GPF,  Prev: Gas bugs,  Up: Converting
  5208.  
  5209. 17.3 Converting Intel ASM syntax to AT&T syntax
  5210. ===============================================
  5211.  
  5212. **Q*: Where can I find an automated conversion tool to convert my
  5213. `Intel'-style assembly code into a code acceptable by `Gas'?*
  5214.  
  5215. *A* :  A `Sed' script which should do most of the conversion was posted to
  5216. the DJGPP news group in the past.  You can find it in the DJGPP archives, at
  5217. this URL:
  5218.  
  5219.      http://www.delorie.com/djgpp/mail-archives/djgpp/1995/06/06/05:48:34
  5220.  
  5221. A conversion program called `TA2AS' which can convert TASM assembly source to
  5222. the AT&T format, can be found on the DJGPP server, e.g.
  5223. ftp://ftp.delorie.com/pub/djgpp/contrib/ta2asv08.zip and on the Oulu
  5224. repository, e.g. ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/ta2as.zip.
  5225. `TA2AS' was written by Jan Oonk <jan@stack.urc.tue.nl>.
  5226.  
  5227. Alternatively, here is what you can do to make your code linkable with DJGPP
  5228. programs:
  5229.  
  5230.    * Get and install NASM, a portable x86 assembler which supports most of
  5231.      the Intel syntax and can generate DJGPP-compatible COFF object files (as
  5232.      well as lots of other formats, such as Microsoft 16-bit OBJ and Win32,
  5233.      a.out, and ELF).  It also supports Pentium and Pentium Pro opcodes.
  5234.      NASM is free for non-commercial use (see the docs for commercial use
  5235.      restrictions) and can be compiled with DJGPP.  You can get NASM from
  5236.      sunsite mirrors, e.g.
  5237.      ftp://sunsite.unc.edu/pub/Linux/devel/lang/asm/nasm-0.90.tar.gz.  A
  5238.      pre-compiled MSDOS binary is available from SimTel.NET sites, e.g.
  5239.      ftp://ftp.simtel.net/pub/simtelnet/msdos/asmutl/nasm091.zip.  The author
  5240.      and maintainer of NASM is Simon Tatham <sgt20@cam.ac.uk>.
  5241.  
  5242.    * For a small number of relatively short files, consider converting them
  5243.      with a smart editor (like Emacs or its work-alikes).
  5244.  
  5245.    * Obtain a copy of Microsoft MASM 6.11. It has a `-coff' option to
  5246.      generate object code in COFF format which can be submitted to GCC, so you
  5247.      can compile your original source.  You can also use the `LIB32'
  5248.      librarian from Microsoft C8 to convert object files to COFF by putting
  5249.      them into a `.lib' library, then extracting them as COFF files.  (1)
  5250.      (*note Converting ASM-Footnotes::)
  5251.  
  5252.    * Use a disassembler to disassemble the object code, then convert it to
  5253.      the AT&T format either by hand or using `TA2AS'.  One place to look for
  5254.      such a disassembler is on SimTel.NET mirrors, e.g.
  5255.      ftp://ftp.simtel.net/pub/simtelnet/msdos/disasm/.
  5256.  
  5257. Keep in mind that syntax is only one of the aspects of converting code
  5258. written for DOS to DJGPP.  You should also make sure your code doesn't
  5259. violate any of the rules for protected-mode programming (*note next question:
  5260. ASM GPF.).
  5261.  
  5262. 
  5263. File: djgppfaq.info,  Node: Converting ASM-Footnotes,  Up: Converting ASM
  5264.  
  5265. (1)  If you use MASM or LIB32, please post your experiences to
  5266. comp.os.msdos.djgpp news group, so that I can make the above instructions
  5267. less vague.
  5268.  
  5269. 
  5270. File: djgppfaq.info,  Node: ASM GPF,  Next: OBJ and LIB,  Prev: Converting ASM,  Up: Converting
  5271.  
  5272. 17.4 Converted code GP Faults!
  5273. ==============================
  5274.  
  5275. **Q*: OK, I've succeeded in converting and compiling my assembly-language
  5276. program, but when I run it, I get "Segmentation Violation" and "General
  5277. Protection Fault".  This program works when compiled with MASM, so how can
  5278. this be?*
  5279.  
  5280. *A* :  In DJGPP, your program runs in *protected mode*.  There are certain
  5281. things you can't do in protected-mode programs (that's why it is called
  5282. protected mode).  This issue is too complex to describe here, so only a few
  5283. of the more important aspects will be briefly mentioned.  If you are serious
  5284. about writing assembly language protected-mode code, or have a large body of
  5285. existing code to convert to protected mode, you should read any of the
  5286. available books about protected-mode programming with 80x86 processors.
  5287.  
  5288. Here is a short list of some of the techniques found in many real-mode
  5289. programs, which will trigger protection violation or erratic behavior in
  5290. protected mode:
  5291.  
  5292.    * Loading arbitrary values into segment registers, then using them to
  5293.      reference code or data.
  5294.  
  5295.    * Referencing code with data segment register, or vice versa.
  5296.  
  5297.    * Assuming certain locations (like BIOS area or video memory) will be found
  5298.      at certain absolute addresses.
  5299.  
  5300.    * Calling DOS or BIOS services with `INT NN' instruction.
  5301.  
  5302. 
  5303. File: djgppfaq.info,  Node: OBJ and LIB,  Next: 16-bit code,  Prev: ASM GPF,  Up: Converting
  5304.  
  5305. 17.5 I want to use a `.obj' or `.lib' code with DJGPP
  5306. =====================================================
  5307.  
  5308. **Q*: I have a set of useful functions in a `.obj' format, but no source
  5309. code.  Can I use them with my DJGPP program?*
  5310.  
  5311. **Q*: I have this `ACMELUXE.LIB' library of functions which I want to use.
  5312. I've extracted all the `.obj' files, but when I try to link them with my
  5313. program, GCC complains: "File format not recognized".  Can't I use these
  5314. object files?*
  5315.  
  5316. **Q*: I've got a bunch of `.obj' files I want to use.  I've ran AR to make a
  5317. GCC-style `.a' object library, but got an error message from GCC saying
  5318. "couldn't read symbols: No symbols".  How can I link them with my code?*
  5319.  
  5320. *A* : Sorry, you probably can't.  The GNU linker called by GCC doesn't
  5321. understand the format of `.obj' files which other DOS-based
  5322. compilers/assemblers emit.  Unless you can get the source of those functions,
  5323. convert it to protected-mode, flat-address model code and compile them with
  5324. GCC, you most probably won't be able to use them.  (1) (*note OBJ and
  5325. LIB-Footnotes::)
  5326.  
  5327. Lately, an automated conversion tool called `OBJ2COFF' was written by the
  5328. SPiRiT team, which can be used to convert `.obj' object files and `.lib'
  5329. libraries to `COFF' format, provided that the original `.obj' files have been
  5330. written for flat-address memory model.  (You can also try using LIB32
  5331. librarian from Microsoft C8 to convert object files to COFF.)  The main
  5332. problem, of course, is that most such object files were written for real-mode
  5333. programs in memory models other than flat, and without extensive
  5334. modifications would crash your program anyway... (*Note previous question:
  5335. ASM GPF.)
  5336.  
  5337. `OBJ2COFF' is available from the Oulu repository, e.g.
  5338. ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/o2cv10.arj and from DJ
  5339. Delorie's ftp server, e.g. ftp://ftp.delorie.com/pub/djgpp/contrib/o2cv06.arj.
  5340. If you have any problems with it or questions about it, send them to its
  5341. author, Rico <mb002@hi.ft.hse.nl> or to George van Venrooij
  5342. <george@il.ft.hse.nl>.  Note that the authors of `OBJ2COFF' have explicitly
  5343. prohibited commercial use, so you shouldn't use `OBJ2COFF' for converting
  5344. commercial object files.
  5345.  
  5346. Another conversion tool you might try is `EMXAOUT' from the `emx/gcc'
  5347. package.  It also requires the code to be written for the flat-address memory
  5348. model and will reportedly complain if you feed it with code written for
  5349. segmented memory models.  `EMXAOUT' is available from the SciTech Software
  5350. FTP site, e.g. ftp://ftp.scitechsoft.com/devel/emxaout1.zip.  If you need,
  5351. you should be able to compile it with DJGPP; however, a precompiled binary is
  5352. available in the above archive.  Or you can get `EMXAOUT' from the EMX
  5353. archives, e.g. ftp://ftp-os2.nmsu.edu/os2/unix/emx09b/emxrt.zip and the RSX
  5354. extender (for running `EMXAOUT' under DPMI) from the RSX archives, e.g.
  5355. ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc/rsx503rt.zip.
  5356.  
  5357. Note that EMXAOUT produces object files in *a.out* format, whose support in
  5358. DJGPP is not as full as that of *COFF*.  For example, `ld.exe' (as of
  5359. Binutils 2.7) doesn't support a.out object files inside `.a' libraries, so
  5360. you will have to link them as `.o' files.
  5361.  
  5362. 
  5363. File: djgppfaq.info,  Node: OBJ and LIB-Footnotes,  Up: OBJ and LIB
  5364.  
  5365. (1)  Note that mixing object files from different compilers usually won't
  5366. work either, even if they both are in the `.obj' format.
  5367.  
  5368. 
  5369. File: djgppfaq.info,  Node: 16-bit code,  Next: NEAR and FAR,  Prev: OBJ and LIB,  Up: Converting
  5370.  
  5371. 17.6 I *must* use my 16-bit code with DJGPP!!
  5372. =============================================
  5373.  
  5374. **Q*: If that's how it is, then I would have to give up using DJGPP.  I
  5375. simply cannot live without these `.obj' files.  Are you *really* sure there
  5376. is nothing I can do??*
  5377.  
  5378. *A* :  If you need your old code *that* badly, then there might be a way,
  5379. albeit a cumbersome one.  You can write a 16-bit, real-mode program and link
  5380. it with your precious functions you can't live without.  Have this program
  5381. spawn a DJGPP-compiled program and make the two communicate with each other
  5382. via a buffer allocated in low memory, or via command-line parameters passed
  5383. to the 32-bit program by the `spawnXX' function call.  You can also call
  5384. 16-bit functions directly with the library function called
  5385. `__dpmi_simulate_real_mode_procedure_retf', provided the 16-bit program
  5386. passes the CS:IP values of these functions to the 32-bit program.  You can
  5387. even put your 16-bit code as binary instructions into a buffer allocated in
  5388. low memory and call it with `__dpmi_simulate_real_mode_procedure_retf' (but
  5389. if you can do that, you can probably also disassemble the code into a source
  5390. form and submit it to `Gas').
  5391.  
  5392. *Now* will you consider sticking with DJGPP?  *Please??...*
  5393.  
  5394. 
  5395. File: djgppfaq.info,  Node: NEAR and FAR,  Next: Pseudo-registers,  Prev: 16-bit code,  Up: Converting
  5396.  
  5397. 17.7 What should I do with those "near" and "far" declarations?
  5398. ===============================================================
  5399.  
  5400. **Q*: I have this program that I need to port to DJGPP, but it is full of
  5401. pointers and functions declared with the "near" and "far" keywords which GCC
  5402. doesn't grok.  What shall I do?*
  5403.  
  5404. **Q*: A program written for a 16-bit compiler uses the MK_FP or _MK_FP macro,
  5405. but DJGPP doesn't seem to have it.  How should I port it?*
  5406.  
  5407. *A* :  In DJGPP you use a flat address space with no segmentation, so you
  5408. don't need far pointers in the sense they are used in 16-bit code.  Just
  5409. define away those keywords and you will be fine:
  5410.  
  5411.        #define far
  5412.        #define near
  5413.        #define huge
  5414.        #define _far
  5415.        #define _near
  5416.        #define _huge
  5417.  
  5418. Alternatively, you could add suitable `-D' switches to the GCC command line,
  5419. like this:
  5420.  
  5421.        gcc -Dfar -Dnear -Dhuge -c myprog.c
  5422.  
  5423. Macros that create far pointers from the segment and offset (usually called
  5424. `MK_FP' or `_MK_FP') are mostly used in 16-bit code to access certain
  5425. absolute addresses on memory-mapped peripheral devices, like the video RAM.
  5426. These chores are done differently in DJGPP.  Here's one possible way to
  5427. express `MK_FP' in DJGPP (courtesy of Charles Sandmann
  5428. <sandmann@clio.rice.edu>):
  5429.  
  5430.        #include <sys/nearptr.h>
  5431.        #include <crt0.h>
  5432.      
  5433.        void * MK_FP (unsigned short seg, unsigned short ofs)
  5434.        {
  5435.          if ( !(_crt0_startup_flags & _CRT0_FLAG_NEARPTR) )
  5436.            if (!__djgpp_nearptr_enable ())
  5437.              return (void *)0;
  5438.          return (void *) (seg*16 + ofs + __djgpp_conventional_base);
  5439.        }
  5440.  
  5441. The above uses the DJGPP nearptr facility; if you prefer to use farptr
  5442. functions (which are safer and work with all known DPMI hosts), you will need
  5443. to rewrite the code that uses these macros, so don't bother writing a
  5444. replacement for the macro itself.  The details are described in *Note
  5445. Accessing absolute addresses: Xfer, below.
  5446.  
  5447. Macros that extract the segment and the offset from a far pointer (called
  5448. `FP_SEG' and `FP_OFF') are required in 16-bit code to pass addresses in
  5449. registers when calling real-mode DOS or BIOS services, like functions of
  5450. interrupt 21h.  See *Note How to call real-mode interrupt functions: Pointer
  5451. segment, which describes how that should be done in DJGPP; here, too, you
  5452. won't need to port the macros but instead rewrite the code that calls the DOS
  5453. or BIOS service.
  5454.  
  5455. 
  5456. File: djgppfaq.info,  Node: Pseudo-registers,  Prev: NEAR and FAR,  Up: Converting
  5457.  
  5458. 17.8 How to convert _AX pseudo-registers?
  5459. =========================================
  5460.  
  5461. **Q*: Since DJGPP doesn't recognize Borland-style pseudo-register variables
  5462. like _AX, how should I port code which uses them to DJGPP?*
  5463.  
  5464. *A* :  These pseudo-variables are typically used in two different contexts:
  5465.  
  5466.    * When calling real-mode interrupt services.
  5467.  
  5468.      To port such code to DJGPP, use the fields of the `__dpmi_regs'
  5469.      structure (declared on the `dpmi.h' header file) to set the register
  5470.      values, and library function `__dpmi_int' to invoke the interrupt
  5471.      service.  For example, consider the following code snippet:
  5472.  
  5473.             #include <dos.h>
  5474.             void _highcolor (void)
  5475.             {
  5476.               _AH = 0x10;
  5477.               _AL = 0x03;
  5478.               _BL = 0;
  5479.               geninterrupt (0x10);
  5480.             }
  5481.  
  5482.      (1) (*note Pseudo-registers-Footnotes::)
  5483.  
  5484.      Here's one way to express this in DJGPP:
  5485.  
  5486.             #include <dpmi.h>
  5487.             void _highcolor (void)
  5488.             {
  5489.               __dpmi_regs r;
  5490.           
  5491.               r.h.ah = 0x10;
  5492.               r.h.al = 0x03;
  5493.               r.h.bl = 0;
  5494.               __dpmi_int (0x10, &r);
  5495.             }
  5496.  
  5497.      Please read *Note How to call real-mode interrupt functions: int86,
  5498.      elsewhere in this document, for further details on how call real-mode
  5499.      services from DJGPP programs.
  5500.  
  5501.    * Immediately before or after an inline assembly code.
  5502.  
  5503.      GCC features extensive inline assembly facilities which allow you to
  5504.      assign values to, or read values from registers from the inline assembly
  5505.      code.  See *Note Inline Assembly code with GCC: Inline Asm, for further
  5506.      info.
  5507.  
  5508. 
  5509. File: djgppfaq.info,  Node: Pseudo-registers-Footnotes,  Up: Pseudo-registers
  5510.  
  5511. (1)  This calls the video BIOS interrupt 10h to allow bright background
  5512. colors to be used instead of blinking characters.  DJGPP has a library
  5513. function, called `intensevideo', to do that, but let's assume we have reasons
  5514. not to use it.
  5515.  
  5516. 
  5517. File: djgppfaq.info,  Node: Low-level,  Next: Legalese,  Prev: Converting,  Up: Top
  5518.  
  5519. 18. Low-level DOS/BIOS and Hardware-oriented Programming
  5520. ********************************************************
  5521.  
  5522.   This chapter sheds some light on a few aspects of writing DJGPP programs
  5523. which interact with hardware or use interrupts.
  5524.  
  5525. * Menu:
  5526.  
  5527. * int86::                 It doesn't always work.
  5528. * Pointer segment::       Some interrupts require it, but how do you get it?
  5529. * Zero SP::               If you don't, your program crashes.
  5530. * Xfer::                  Moving data to and from conventional memory.
  5531. * 20 bits::               You should mask off the upper 12 bits when unused.
  5532. * Fat DS::                Fast direct access to memory-mapped devices.
  5533. * Above 1MB::             Interact with memory-mapped devices above 1MB.
  5534. * RMCB::                  How to let DOS/BIOS call your code.
  5535. * Hardware interrupts::   How to hook HW interrupts from DJGPP.
  5536. * _go32 vs __dpmi::       Which functions should you use?
  5537. * HW Int pitfalls::       Does your machine wedge?  Here are some reasons.
  5538. * Ports::                 Reading and writing I/O ports in DJGPP.
  5539. * Inline Asm::            How to write inline assembly with GCC.
  5540.  
  5541. 
  5542. File: djgppfaq.info,  Node: int86,  Next: Pointer segment,  Prev: Low-level,  Up: Low-level
  5543.  
  5544. 18.1 Got "Unsupported INT 0xNN" calling `int86'
  5545. ===============================================
  5546.  
  5547. **Q*: Why does my program crash with "Unsupported DOS request 0xNN" or
  5548. "Unsupported INT 0xNN" when I call `int86' or `intdos' functions to invoke a
  5549. software interrupt?*
  5550.  
  5551. *A* :  Calling real-mode DOS or BIOS services from protected-mode programs
  5552. requires a switch to real mode, so the `int86' family of functions in the
  5553. DJGPP library should reissue the INT instruction after the mode switch.
  5554. However, some services require pointers to memory buffers.  Real-mode
  5555. DOS/BIOS functions can only access buffers in conventional memory, so `int86'
  5556. has to move data between your program and low memory to transparently support
  5557. these services.  But this means it should know about all these services to
  5558. perform these chores correctly, because each service has its own layout and
  5559. size of the buffer(s).  While `int86' supports many of these services, it
  5560. doesn't support all of them.  The supported functions are listed in the
  5561. library reference.  *Note int86 library reference: (libc.inf)int86.  For
  5562. those it doesn't support, you will have to call the `__dpmi_int' library
  5563. function instead.  It is also documented in the library reference, *Note
  5564. __dpmi_int: (libc.inf)__dpmi_int.  `__dpmi_int' requires that you set up all
  5565. the data as required by the service you are calling, including moving the
  5566. data to and from low memory (*Note how to use buffers with DOS/BIOS services:
  5567. Pointer segment, below).
  5568.  
  5569. 
  5570. File: djgppfaq.info,  Node: Pointer segment,  Next: Zero SP,  Prev: int86,  Up: Low-level
  5571.  
  5572. 18.2 How to use buffers with DOS/BIOS services
  5573. ==============================================
  5574.  
  5575. **Q*: I want to call a DOS/BIOS function which requires a pointer to a buffer
  5576. in, e.g. `ES:DI' (or any other) register pair.  How do I get the segment to
  5577. put into the `ES' register?*
  5578.  
  5579. *A* :  If you use `int86x' or `intdosx' for a DOS or BIOS function supported
  5580. by them, then just put the address of your buffer into the register which
  5581. expects the offset (`regs.x.di') and forget about the segment.  These
  5582. functions are processed specially by the library, which will take care of the
  5583. rest.
  5584.  
  5585. If you call `__dpmi_int', then you must put into that register pair an
  5586. address of some buffer in *conventional* memory (in the first 1 MByte).  If
  5587. the size of that buffer doesn't have to be larger than the size of transfer
  5588. buffer used by DJGPP (at least 2KB, 16KB by default), then the easiest way is
  5589. to use the transfer buffer.  (Library functions don't assume its contents to
  5590. be preserved across function calls, so you can use it freely.)  That buffer
  5591. is used for all DOS/BIOS services supported by DJGPP, and it resides in
  5592. conventional memory.  DJGPP makes the address and the size of the transfer
  5593. buffer available for you in the `_go32_info_block' external variable, which
  5594. is documented the library reference.  Check the size of the buffer (usually,
  5595. 16K bytes, but it can be made as small as 2KB), and if it suits you, use its
  5596. linear address this way:
  5597.  
  5598.      dpmi_regs.x.di =
  5599.       _go32_info_block.linear_address_of_transfer_buffer & 0x0f;
  5600.      dpmi_regs.x.es =
  5601.       (_go32_info_block.linear_address_of_transfer_buffer >> 4) & 0xffff;
  5602.  
  5603. For your convenience, the header file `<go32.h>' defines a macro `__tb' which
  5604. is an alias for `_go32_info_block.linear_address_of_transfer_buffer.'
  5605.  
  5606. If the size of the transfer buffer isn't enough, you will have to allocate
  5607. your own buffer in conventional memory with a call to the
  5608. `__dpmi_allocate_dos_memory' library function.  It returns to you the segment
  5609. of the allocated block (the offset is zero).  If you only need a small number
  5610. of such buffers which can be allocated once, then you don't have to worry
  5611. about freeing them: they will be freed by DOS when your program calls `exit.'
  5612.  
  5613. For bullet-proof code, you should test the size of the transfer buffer at
  5614. runtime and act accordingly.  This is because its size can be changed by the
  5615. `STUBEDIT' program without your knowledge (however, it can never be less than
  5616. 2KB, the size of the stub, because memory used by the stub is reused for the
  5617. transfer buffer).
  5618.  
  5619. 
  5620. File: djgppfaq.info,  Node: Zero SP,  Next: Xfer,  Prev: Pointer segment,  Up: Low-level
  5621.  
  5622. 18.3 How to call software interrupt functions
  5623. =============================================
  5624.  
  5625. **Q*: My program crashes/doesn't do what it should when I call
  5626. `__dpmi_simulate_real_mode_interrupt.'*
  5627.  
  5628. *A* :  You should zero out some of the fields of the `__dpmi_regs' structure
  5629. before you call that function.  Random values in these fields can cause your
  5630. program to behave erratically.  The fields in point are `SS', `SP' and
  5631. `FLAGS.'  When `SS' and `SP' are zeroed, the DPMI host will provide a stack
  5632. for the interrupt handler.  This stack is locked and is 4KB-long for any
  5633. handling done in protected mode (such as real-mode callbacks), and at least
  5634. 512 bytes in size for interrupts reflected into real mode.  This is usually
  5635. enough, but sometimes you'll need to use your own, larger stack, e.g., if you
  5636. expect interrupts to nest, or if your handler needs a lot of stack space.
  5637. (1) (*note Zero SP-Footnotes::)  In these cases you should point `SS' and
  5638. `SP' to a larger buffer which is in conventional memory (possibly part of the
  5639. transfer buffer).
  5640.  
  5641. If `SS:SP' isn't zero, it will be used as the address of the stack for the
  5642. interrupt handler, so if it points to a random location, your program will
  5643. most certainly crash.  A non-zero `FLAGS' field can also make the processor
  5644. do all kinds of weird things (e.g., imagine that the single-step or the debug
  5645. bit is set!).
  5646.  
  5647. If you don't have any reason to set `SS:SP' to a user-defined stack, it's
  5648. easier to call the `__dpmi_int' library function, which zeroes out the stack
  5649. pointer and the `FLAGS' fields for you (and also doesn't force you to type
  5650. long function names!).
  5651.  
  5652. 
  5653. File: djgppfaq.info,  Node: Zero SP-Footnotes,  Up: Zero SP
  5654.  
  5655. (1)  The DPMI spec indicates that you should *not* use the default stack if
  5656. your procedure/interrupt handler uses more that 60 bytes, or 1/8 of the total
  5657. stack space available by default.
  5658.  
  5659. 
  5660. File: djgppfaq.info,  Node: Xfer,  Next: 20 bits,  Prev: Zero SP,  Up: Low-level
  5661.  
  5662. 18.4 How to move data between your program and conventional memory?
  5663. ===================================================================
  5664.  
  5665. **Q*: How can I move data between my program and the transfer buffer?*
  5666.  
  5667. **Q*: How do I access my peripheral card which is memory-mapped to an address
  5668. between 640K and 1M?*
  5669.  
  5670. **Q*: How can I read or change a value of one of the variables in the BIOS
  5671. data area?*
  5672.  
  5673. **Q*: How can I peek at an address whose far pointer I get from an INT 21h
  5674. call?*
  5675.  
  5676. *A* : Usually, memory-mapped devices or absolute addresses below 1MB mark are
  5677. outside your program's address space, so you cannot access them directly.
  5678. "Direct access", when you just dereference a pointer, means in DJGPP that you
  5679. use your program's `DS' selector, and all the addresses are offsets relative
  5680. to the base of that selector.  So first, you will need a special selector
  5681. that will allow you to access your device or absolute address.  There are
  5682. several methods you can get such a selector:
  5683.  
  5684.    * Use the selector that DJGPP creates for itself to access conventional
  5685.      memory.  DJGPP makes this selector available to you via the `_dos_ds'
  5686.      macro (defined on `<go32.h>' header file).  This selector has base
  5687.      address of 0 and a limit of 1MB, so you can use it to access any address
  5688.      in the conventional memory, but the relatively large limit allows a
  5689.      buggy program to overwrite portions of DOS memory.  (1) (*note
  5690.      Xfer-Footnotes::) The advantage of `_dos_ds' is obviously that you don't
  5691.      have to create it, and that it is good for accessing every region in the
  5692.      first MByte range.
  5693.  
  5694.    * Create your own selector that spans only the region of memory that you
  5695.      want to access, and use that selector instead of `_dos_ds'.  For
  5696.      example, here's a code snippet to set up a selector which provides
  5697.      access to 64KB of text-mode video memory at `0xB800:0000', courtesy of
  5698.      Bill Currie <bill_currie@blackmagic.tait.co.nz>:
  5699.  
  5700.             int TxtVRAMSetupSelector (void)
  5701.             {
  5702.                static char selectorData[8] = {
  5703.                  0xff, 0xff, 0x00, 0x80,
  5704.                  0x0b, 0xf3, 0x40, 0x00
  5705.                };
  5706.                int screenSelector = __dpmi_allocate_ldt_descriptors (1);
  5707.                if (__dpmi_set_descriptor (screenSelector, selectorData) < 0)
  5708.                  abort ();
  5709.                return screenSelector;
  5710.             }
  5711.  
  5712.      The advantages of this method are that (1) you can set up the selector
  5713.      limit such that it only covers the memory region that you need, thus
  5714.      protection of the rest of memory is retained; and (2) you may set the
  5715.      base address to point to the beginning of the specific memory region you
  5716.      need to access, so that you don't have to add the base address for every
  5717.      access, making the access faster.  For details about the contents of the
  5718.      8-byte selector descriptor, see the documentation of the
  5719.      `__dpmi_get_descriptor' function in the library reference Info file.
  5720.  
  5721.    * Use the DPMI service which creates a selector to access a specific
  5722.      real-mode segment address.  The DJGPP library has a function
  5723.      `__dpmi_segment_to_descriptor' which is a wrapper around that DPMI
  5724.      service.  It is easier to use than the `__dpmi_set_descriptor' function
  5725.      above, since you don't have to mess with the 8-byte descriptor buffer,
  5726.      but it always defines a 64KB limit by default.  Here is an example of
  5727.      code which gets a selector to access 64KB of video RAM beginning at
  5728.      `0xA000:0000':
  5729.  
  5730.             short video = __dpmi_segment_to_descriptor(0xa000);
  5731.  
  5732.      Note that descriptors created by this function should never be modified
  5733.      or freed.  For this reason, you should use this function sparingly.  For
  5734.      instance, if your program needs to examine various real mode addresses
  5735.      using the same selector, you should allocate a descriptor and change the
  5736.      base using the `__dpmi_set_segment_base_address' library function
  5737.      instead of using `__dpmi_segment_to_descriptor' to allocate separate
  5738.      descriptor for each address.
  5739.  
  5740. Once you have a selector, you can use one of three methods to access your
  5741. absolute addresses using that selector:
  5742.  
  5743.    * If you want to access a byte, a 16-bit word, or a 32-bit double word,
  5744.      use the "far pointer" functions declared on the `<sys/farptr.h>' header
  5745.      file.  You should convert any real-mode far pointer segment:offset pair
  5746.      into a "linear address" (i.e., segment*16 + offset), and use `_dos_ds'
  5747.      or any other selector which allows access to conventional memory, like
  5748.      this:
  5749.  
  5750.            unsigned char value = _farpeekb(_dos_ds, segment*16 + offset);
  5751.  
  5752.      Use `_farpeekw' to peek at 16-bit shorts and `_farpeekl' to peek at
  5753.      32-bit longs.  If you need to access several (non-contiguous) values in
  5754.      a loop, use the corresponding `_farnspeekX' functions which allow you to
  5755.      set the selector only once, as opposed to passing it with every call
  5756.      (but be sure the loop doesn't call any function that itself sets the
  5757.      selector; see the library reference for more details).
  5758.  
  5759.      There is a corresponding set of `_farpokeX' and `_farnspokeX' functions
  5760.      to poke (change the values of) such memory locations.
  5761.  
  5762.      These functions have an advantage of emitting inline assembly code when
  5763.      you compile with optimizations, so they are very fast.  See the library
  5764.      reference Info file for further details about these functions.
  5765.  
  5766.    * If you need to access more than 4 contiguous bytes, use `dosmemget' and
  5767.      `dosmemput' library functions.  They also require you to convert the
  5768.      segment:offset pair into a linear address, but they don't need the
  5769.      conventional memory selector, as they can only be used to access the
  5770.      conventional memory (they use `_dos_ds' internally).
  5771.  
  5772.      Note that some memory-mapped peripheral devices might require 16-bit word
  5773.      accesses to work properly, so if `dosmemXXX' yields garbled results, try
  5774.      `dosmemXXXw' or "farptr" functions.
  5775.  
  5776.    * For moving buffers to selectors other than `_dos_ds' (e.g., created by
  5777.      one of the methods explained above), use the `movedata' library
  5778.      function.  It requires that you pass a selector and an offset for both
  5779.      the conventional memory address and for the buffer in your program's
  5780.      address space.  Use the `_my_ds' function (note that it's a *function*,
  5781.      not a variable!) to get the selector of any variable in your program,
  5782.      and use the address of the variable (cast to an `int') as its "offset"
  5783.      or linear address.  `movedata' is fast because it moves by 32-bit longs,
  5784.      but be careful with its use when moving data to and from peripheral
  5785.      cards: some of them only support 8- or 16-bit wide data path, so moving
  5786.      data 4 bytes at a time won't gain you much, and might even get you in
  5787.      trouble with some buggy BIOSes.  The functions `movedatab' and
  5788.      `movedataw' are provided for moving by bytes and by 16-bit words,
  5789.      respectively.
  5790.  
  5791.      For example, here is a code snippet that combines one of the methods for
  5792.      allocating a descriptor for video RAM access with a call to `movedata'
  5793.      to move a buffer to the graphics screen:
  5794.  
  5795.             short video = __dpmi_segment_to_descriptor(0xa000);
  5796.             movedata(_my_ds(), buffer, video, 0, 320*200);
  5797.  
  5798.    * For the fastest access to memory outside your usual address space, you
  5799.      might consider using the "nearptr" functions declared on the
  5800.      `<sys/nearptr.h>' header; see the library reference for more details.
  5801.      Also see the description of how to get the *Note fastest direct access
  5802.      to peripheral devices: Fat DS, below.
  5803.  
  5804. 
  5805. File: djgppfaq.info,  Node: Xfer-Footnotes,  Up: Xfer
  5806.  
  5807. (1)  Original release of DJGPP v2.01 makes the limit of `_dos_ds' be 4GB,
  5808. which effectively disables memory protection when you use that selector.
  5809. However, since no memory outside the first 1MB is properly mapped into your
  5810. program's address space without additional DPMI calls, and the DPMI host is
  5811. then free to put memory-mapped devices, such as Weitek I/O space or the
  5812. linear frame buffer of an SVGA, on any address it sees fit, that huge limit
  5813. is an unjustified security hole.
  5814.  
  5815. 
  5816. File: djgppfaq.info,  Node: 20 bits,  Next: Fat DS,  Prev: Xfer,  Up: Low-level
  5817.  
  5818. 18.5 Conventional-memory addresses use only 20 bits
  5819. ===================================================
  5820.  
  5821. **Q*: I call `movedata' to pass data between my program and the transfer
  5822. buffer, but get bogus values or General Protection Fault.*
  5823.  
  5824. *A* :  Valid conventional-memory addresses are only 20 bit-wide.  However,
  5825. the value stored in the variable
  5826. `_go32_info_block.linear_address_of_transfer_buffer' (or its alias, `__tb')
  5827. is not guaranteed to have the higher 12 bits zeroed, and `movedata' doesn't
  5828. mask those high bits, because it can also be used to move data between 2
  5829. protected-memory locations.  Be sure to mask off the high 12 bits of the
  5830. value returned by various `..._linear_address_...' fields in DJGPP
  5831. structures, whenever that address references a conventional memory location,
  5832. before you call *any* of the functions from the `movedataX' family, the
  5833. "farptr" or the "nearptr" functions.
  5834.  
  5835. 
  5836. File: djgppfaq.info,  Node: Fat DS,  Next: Above 1MB,  Prev: 20 bits,  Up: Low-level
  5837.  
  5838. 18.6 Fast access to memory-mapped devices or absolute addresses
  5839. ===============================================================
  5840.  
  5841. **Q*: The "farptr" functions are too slow for my application which *MUST*
  5842. have direct access to a memory-mapped device under DPMI.  How can I have this
  5843. in DJGPP?  My entire optimized graphics library is at stake if I can't! :(*
  5844.  
  5845. *A* :  The following so-called Fat DS method was suggested by Junaid A.
  5846. Walker <junaid@barney.eng.monash.edu.au> (he also posted a program which uses
  5847. this technique to access the video RAM; you can look it up by searching the
  5848. mailing list archives).  But first, a word of warning: the method I'm about
  5849. to describe effectively disables memory protection, and so might do all kinds
  5850. of damage if used by a program with a wild pointer.  Or, as Stephen Turnbull
  5851. <turnbull@shako.sk.tsukuba.ac.jp> has put it:
  5852.  
  5853.      *Surgeon General's WARNING*:  The description below uses the "Fat DS
  5854.      hack", a steroid derivative which gives your program great strength, a
  5855.      thick neck, baldness, and is known to be closely linked with the
  5856.      Alzheimer's disease.
  5857.  
  5858. Having said that, here is the trick: you change the limit of the segment
  5859. descriptor stored in `DS' to `0xffffffff' (i.e., -1), using function 8 of the
  5860. DPMI interrupt 31h.  After that, you have access to all the memory which is
  5861. currently mapped in.  You then use the 32-bit wrap-around in the linear
  5862. address space to access memory at, say, linear address 0xa0000 (which belongs
  5863. to the VGA), or any other address on your memory-mapped device.
  5864.  
  5865. You should know up front that this trick won't work with every DPMI host.
  5866. Linux's DOSEmu and Win/NT won't allow you to set such a huge limit on the
  5867. memory segment, because these operating systems take memory protection
  5868. seriously; in these cases `__djgpp_nearptr_enable' will return zero--a sign
  5869. of a failure.  CWSDPMI, QDPMI, Win 3.x and Win 9x all allow this technique
  5870. (OS/2 Warp seems to allow it too, at least as of version 8.200), but some
  5871. events break this scheme even for those DPMI hosts which will allow it.  A
  5872. call to `malloc' or any other library function which calls `sbrk' might
  5873. sometimes change the base address of the `DS' selector and break this method
  5874. unless the base address is recomputed after `sbrk' call.  (The "nearptr"
  5875. functions support this recomputation by providing you with the
  5876. `__djgpp_conventional_base' variable, but it is your responsibility to use
  5877. it.)  The same change happens when you call `system', and as a result of some
  5878. other events external to the executing code thread, like multitasking or
  5879. debugger execution.
  5880.  
  5881. You should also know that the `__djgpp_nearptr_enable' function in DJGPP v2.0
  5882. didn't verify that the limit was properly set.  So if the DPMI server would
  5883. fail the call *silently*, the function won't detect it and will not return a
  5884. failure indication.  DJGPP v2.01 corrects this omission by always verifying
  5885. that the DPMI host has honored the request, and returns a failure indication
  5886. if it hasn't.
  5887.  
  5888. If you are aware of these limitations, and don't need your code to run under
  5889. all DPMI hosts, it might be the fix to your problems.
  5890.  
  5891. Confused about how exactly should you go about using this technique in your
  5892. program?  Look at the docs of the "nearptr" functions, *Note
  5893. __djgpp_nearptr_enable: (libc.inf)__djgpp_nearptr_enable.
  5894.  
  5895. Another possibility is to use the DPMI function `0x508' that can map any
  5896. range of physical memory addresses into a block that you allocate.  Note that
  5897. this is a DPMI 1.0 functionality which is *not* supported by most DPMI 0.9
  5898. hosts (`CWSDPMI' does support it).  There is a helper function
  5899. `__djgpp_map_physical_memory' in the DJGPP C library that you can use to call
  5900. these services.
  5901.  
  5902. 
  5903. File: djgppfaq.info,  Node: Above 1MB,  Next: RMCB,  Prev: Fat DS,  Up: Low-level
  5904.  
  5905. 18.7 Accessing absolute address above 1MB
  5906. =========================================
  5907.  
  5908. **Q*: How can I access memory-mapped peripheral devices (or any other
  5909. absolute address) above 1 MByte mark?*
  5910.  
  5911. *A* :  You should use DPMI functions to allocate an LDT descriptor, and map
  5912. it to an absolute physical address.  You can then use the functions from
  5913. <sys/farptr.h> to access that linear address.  These are the DPMI calls that
  5914. you will have to use:
  5915.  
  5916.    - allocate an LDT descriptor (Int 31h/AX=0);
  5917.  
  5918.    - map selector to physical address (Int 31h/AX=0800h);
  5919.  
  5920.    - lock linear address (Int 31h/AX=0600h);
  5921.  
  5922.    - set segment base address (Int 31h/AX=7);
  5923.  
  5924.    - set segment limit (Int 31h/AX=8).
  5925.  
  5926. All of these DPMI calls have `__dpmi__XXX' wrappers in the DJGPP library.
  5927.  
  5928. 
  5929. File: djgppfaq.info,  Node: RMCB,  Next: Hardware interrupts,  Prev: Above 1MB,  Up: Low-level
  5930.  
  5931. 18.8 How to make DOS/BIOS call your function
  5932. ============================================
  5933.  
  5934. **Q*: How can I make any real-mode service call my function?  E.g., the mouse
  5935. driver has a provision (function 0Ch) to call a user-defined handler when
  5936. certain events occur, which expects a far pointer to my function in the
  5937. `ES:DX' register pair.*
  5938.  
  5939. *A* :  Those services expect a real-mode function, so you should wrap your
  5940. protected-mode function with a real-mode stub.  To this end, call either the
  5941. `_go32_dpmi_allocate_real_mode_callback_retf' or the
  5942. `_go32_dpmi_allocate_real_mode_callback_iret' library function, as required
  5943. by the real-mode service you want to hook, and pass the `segment' and
  5944. `offset' fields it returns to the service you want (in the above example, Int
  5945. 33h function 0Ch) by calling `__dpmi_int.' Here's a code fragment that shows
  5946. how to do this:
  5947.  
  5948.  
  5949.        #include <dpmi.h>
  5950.        #include <go32.h>
  5951.      
  5952.        static __dpmi_regs        callback_regs;
  5953.        static _go32_dpmi_seginfo callback_info;
  5954.      
  5955.        int install_mouse_handler (unsigned mask,
  5956.                                   void (*func)(__dpmi_regs *))
  5957.        {
  5958.          __dpmi_regs r;
  5959.      
  5960.          callback_info.pm_offset = (long)func;
  5961.          if (_go32_dpmi_allocate_real_mode_callback_retf(&callback_info,
  5962.                                                          &callback_regs))
  5963.            return -1;  /* failure */
  5964.      
  5965.          r.x.ax = 0xc;
  5966.          r.x.cx = mask;
  5967.          __dpmi_int (0x33, &r);
  5968.          return (r.x.flags & 1) ? -1 : 0;
  5969.        }
  5970.  
  5971. The handler (`func' in the above example) will be called with a pointer to a
  5972. `__dpmi_regs' structure which is filled by values found in the CPU registers
  5973. when the mouse driver calls the handler.  See the docs in the library
  5974. reference Info file for further details about allocating wrapper functions.
  5975.  
  5976. 
  5977. File: djgppfaq.info,  Node: Hardware interrupts,  Next: _go32 vs __dpmi,  Prev: RMCB,  Up: Low-level
  5978.  
  5979. 18.9 How to hook hardware interrupts
  5980. ====================================
  5981.  
  5982. **Q*: How do I register my DJGPP function as a hardware interrupt handler?*
  5983.  
  5984. *A* :  The optimal setup depends on the interrupt frequency and on the amount
  5985. of processing it requires.  Therefore, only some basic considerations and
  5986. techniques are listed below.  What combination of these is best for your
  5987. application is up to you to decide.
  5988.  
  5989. First, some background.  Hardware interrupts can occur when the processor is
  5990. either in real mode (like when your program calls some DOS service) or in
  5991. protected mode.  When your program runs under a DPMI host, hardware
  5992. interrupts are caught by the DPMI host and passed to protected mode first;
  5993. only if unhandled, they are then reflected to real mode.  Therefore, in DPMI
  5994. mode you can get away with installing only a protected-mode handler.
  5995. However, if the interrupts happen at a high frequency (say, more than 10
  5996. KHz), then the overhead of the interrupt reflection from real to protected
  5997. mode might be too painful, and you should consider installing a real-mode
  5998. interrupt handler in addition to the protected-mode one.  Such a real-mode
  5999. handler will be called *before* the interrupt gets to the DPMI host, and
  6000. handle the interrupt entirely in real mode, so it must be written in assembly
  6001. and located in conventional memory (below the 1MB mark).  If you need to hook
  6002. an interrupt with both PM and RM handlers, you must hook the PM interrupt
  6003. first, then the RM one (because hooking the PM interrupt modifies the RM
  6004. one).  Also, you should know that some DPMI hosts don't allow you to hook the
  6005. RM interrupt (CWSDPMI does); the only way to be sure is to try.
  6006.  
  6007. To install a protected-mode interrupt handler, you do this:
  6008.  
  6009.    * In general, your handler should be written in assembly to be
  6010.      bullet-proof.  It should lock all the memory (code, data and stack) it
  6011.      touches during interrupt processing (this is virtually impossible in C),
  6012.      explicitly issue the `STI' instruction before `IRET' and perform all the
  6013.      other chores described in the DPMI spec (*note DOS Protected Mode
  6014.      Interface Specification: DPMI Spec.).  To install assembly handler, you
  6015.      should do this:
  6016.  
  6017.         - Call `__dpmi_get_protected_mode_interrupt_vector' and save the
  6018.           structure it returns (to restore the previous handler address
  6019.           before your program exits).
  6020.  
  6021.         - Lock all the memory your handler touches with a series of calls to
  6022.           `__dpmi_lock_linear_region.'
  6023.  
  6024.         - Finally, call `__dpmi_set_protected_mode_interrupt_vector' passing
  6025.           it the pointer to a `__dpmi_paddr' structure filled with `_my_cs'
  6026.           in the `selector' field and the address of your function in the
  6027.           `offset32' field.
  6028.  
  6029.    * If your handler function is written in C, you should generally call the
  6030.      `_go32_dpmi_XXX' functions instead of the bare-bones API wrappers whose
  6031.      names start with `__dpmi_.'  Specifically:
  6032.  
  6033.         - Call `_go32_dpmi_get_protected_mode_interrupt_vector.'  This
  6034.           function puts the selector and offset of the specified interrupt
  6035.           vector into the `pm_selector' and `pm_offset' fields of the
  6036.           structure pointed to by its second argument.  This data should be
  6037.           saved and later passed to
  6038.           `_go32_dpmi_get_protected_mode_interrupt_vector' to restore the
  6039.           vector on exit.
  6040.  
  6041.         - Call `_go32_dpmi_allocate_iret_wrapper,' passing it the address of
  6042.           your functions in the `pm_offset' field and the value of `_my_cs'
  6043.           in the `pm_selector' field.  The `pm_offset' field will get
  6044.           replaced with the address of the wrapper function which is a small
  6045.           assembler function that handles everything an interrupt handler
  6046.           should do on entry and before exit (and what the code GCC generates
  6047.           for an ordinary C function doesn't include); the effect is similar
  6048.           to using interrupt or `_interrupt' keyword in some DOS-based
  6049.           compilers.
  6050.  
  6051.         - If you want your handler to chain to the previous handler, call
  6052.           `_go32_dpmi_chain_protected_mode_interrupt_vector.'  This will set
  6053.           up a wrapper function which, when called, will call your handler,
  6054.           then jump to the previous handler after your handler returns.  Put
  6055.           the address of your handler into the `pm_offset' field and the
  6056.           value of `_my_cs' into the `pm_selector' field of the
  6057.           `_go32_dpmi_seginfo' structure and pass a pointer to it to this
  6058.           function.
  6059.  
  6060.         - You then call `_go32_dpmi_set_protected_mode_interrupt_vector' with
  6061.           the address of the `_go32_dpmi_seginfo' structure you got either
  6062.           from `_go32_dpmi_allocate_iret_wrapper' or from
  6063.           `_go32_dpmi_chain_protected_mode_interrupt_vector.'
  6064.  
  6065.      The problem with writing handlers in C as above is that the wrappers'
  6066.      code and data aren't locked, and in practice you can't lock all of
  6067.      memory the handler itself uses, either.  Thus, this approach is
  6068.      generally unsuitable for production-quality software and should be used
  6069.      only when the program is known not to page (i.e., only the physical
  6070.      memory is used).  You might consider disabling virtual memory to make
  6071.      sure your program doesn't page.  To accomplish this, either set the
  6072.      `_CRT0_FLAG_LOCK_MEMORY' bit in the `_crt0_startup_flags' variable, or
  6073.      use `CWSDPR0' or `PMODE/DJ' as your DPMI host.  In fact, using one of
  6074.      these methods is the recommended way of debugging the first versions of
  6075.      a program that hooks hardware interrupts; only after you are sure that
  6076.      your basic machinery works should you move to testing it in a setup when
  6077.      paging might happen.
  6078.  
  6079.      Note that `_CRT0_FLAG_LOCK_MEMORY' is only recommended for small
  6080.      programs that run on a machine where enough physical memory is always
  6081.      available, because the startup code currently doesn't test if memory is
  6082.      indeed locked, and you can end up with unlocked, or partially unlocked
  6083.      memory, which will crash your program.
  6084.  
  6085. To install a real-mode interrupt handler, you do this:
  6086.  
  6087.    * Call `__dpmi_get_real_mode_interrupt_vector' and save the structure it
  6088.      returns (to restore the previous handler address before your program
  6089.      exits).
  6090.  
  6091.    * Allocate some conventional memory with `__dpmi_allocate_dos_memory' and
  6092.      put the code of your handler there with the `dosmemput' function.  (You
  6093.      could also call one of the functions which allocate a real-mode
  6094.      call-back, but these will cause a mode switch on every interrupt, which
  6095.      you want to avoid; otherwise there is no point in installing a real-mode
  6096.      handler, right?)
  6097.  
  6098.    * Put the address which `__dpmi_allocate_dos_memory' returned into a
  6099.      `__dpmi_raddr' structure (the lower 4 bits into `offset16' field, the
  6100.      rest into `segment' field), then call
  6101.      `__dpmi_set_real_mode_interrupt_vector.'
  6102.  
  6103. For examples of installing and using hardware interrupt handlers, see the
  6104. sample code written by Bill Currie <bill_currie@MAIL.TAIT.CO.NZ>, the Sound
  6105. Blaster interrupt-driven functions, the `mkkbd' package, and the `libhw'
  6106. library, described under *Note sample DJGPP packages: Samples.  Alaric B.
  6107. Williams <alaric@abwillms.demon.co.uk> has written a tutorial on DJGPP
  6108. interrupt handling, at this URL:
  6109.  
  6110.      http://www.abwillms.demon.co.uk/prog/djints.txt
  6111.  
  6112. 
  6113. File: djgppfaq.info,  Node: _go32 vs __dpmi,  Next: HW Int pitfalls,  Prev: Hardware interrupts,  Up: Low-level
  6114.  
  6115. 18.10 Should I use _go32_XXX or __dpmi_YYY functions?
  6116. =====================================================
  6117.  
  6118. **Q*: In v1.x I was used to the `_go32_...' functions, but now comes v2 which
  6119. also has `__dpmi_...' functions.  Are there any differences between these two
  6120. varieties?*
  6121.  
  6122. **Q*: Do I need to convert my old v1.x code to use the new `__dpmi_...'
  6123. functions?*
  6124.  
  6125. *A* :  These two groups of functions have different functionality, so don't
  6126. just substitute the new ones for the older ones, because it usually won't
  6127. work!  The new `__dpmi_...' functions are just bare-bones wrappers of the
  6128. DPMI API calls (*note DPMI Specification: DPMI Spec.), generally unsuitable
  6129. for use with handlers written in C, whereas the old `_go32_...' functions are
  6130. intelligent helper functions which only make sense if your interrupt handlers
  6131. are C functions.  The problem with the `_go32_...' functions is that they
  6132. don't lock all the code and data they (and your handlers) use, so they can
  6133. crash on memory-tight machines and thus aren't suitable for
  6134. production-quality code.  But they are certainly useful in the initial stages
  6135. of writing and debugging code that hooks hardware interrupts, and for
  6136. migrating existing v1.x code to v2.  Some of the old names were just
  6137. `#define'd' to the new names where the functionality is identical.
  6138.  
  6139. The bottom line is that it shouldn't be necessary to convert your code for it
  6140. to work at least as well as it did in v1.x; but if you want it to be more
  6141. stable, you should rewrite your handlers in assembly and use the new
  6142. `__dpmi_...' functions (*note How to install a hardware interrupt handler:
  6143. Hardware interrupts.).
  6144.  
  6145. 
  6146. File: djgppfaq.info,  Node: HW Int pitfalls,  Next: Ports,  Prev: _go32 vs __dpmi,  Up: Low-level
  6147.  
  6148. 18.11 Hardware interrupt hooking has its subtleties ...
  6149. =======================================================
  6150.  
  6151. **Q*: I did all the above, but my program occasionally still hangs...*
  6152.  
  6153. *A* :  Hooking hardware interrupts in DJGPP (and in protected mode in
  6154. general) has a few subtle aspects.  In general, hardware interrupt handling
  6155. in DJGPP v2.x is rock solid *if you play by the rules*.  Unfortunately, the
  6156. rules are a bit tricky.
  6157.  
  6158. One cause of your problems might be that your interrupt handler or some
  6159. memory location it uses get paged out because of the virtual memory
  6160. mechanism, or because your program spawned a child program.  In that case,
  6161. the interrupt might cause a call to a non-existent service routine, with the
  6162. obvious results.  You should lock all the memory pages that your handler
  6163. accesses by calling the `__dpmi_lock_linear_region' library function.  This
  6164. also means in practice that you should write your handler in assembly, as
  6165. described in *Note how to set an interrupt handler: Hardware interrupts,
  6166. above.  You can disable virtual memory, or put `_CRT0_FLAG_LOCK_MEMORY' into
  6167. `_crt0_startup_flags' to make sure nothing is paged out (but then your
  6168. program might not have enough memory to run, unless you run on
  6169. memory-abundant systems).
  6170.  
  6171. Another problem might be that the hardware peripheral you use generates a lot
  6172. of interrupts.  Due to specifics of hardware interrupts handling in protected
  6173. mode, there is a substantial overhead involved with reflection of interrupts
  6174. between real and protected modes.  For instance, on a 486DX/33 this
  6175. reflection might consume up to 3000 clocks; on a 386SX/16, even a 1KHz clock
  6176. might eat up 1/2 of available cycles.  If your hardware fires too many
  6177. interrupts, your CPU might not be able to keep up.  In that case, consider
  6178. reducing the interrupt frequency, or move some of the processing done inside
  6179. the interrupt handler to some other place.  Use a ring 0 DPMI server such as
  6180. `CWSDPR0' or `PMODE/DJ' which don't swap interrupt stacks--this will reduce
  6181. the overhead of the interrupt reflection to some degree.  If your handler is
  6182. written in C, write it in assembly and make sure it doesn't chain.  If that
  6183. doesn't help, install a real-mode handler.
  6184.  
  6185. Some losing memory managers, notably EMM386, were reported to induce a high
  6186. interrupt handling overhead.  In one case, a user reported an increase in the
  6187. interrupt rate from 2 KHz to 6 KHz after uninstalling EMM386.
  6188.  
  6189. Still another possibility is that you use a non-default `sbrk' algorithm in
  6190. your program (check if the header file `crt0.h' is included anywhere in the
  6191. program, and if so, if the `_CRT0_FLAG_UNIX_SBRK' bit in the
  6192. `_crt0_startup_flags' variable is set by the program.  If it is, then a
  6193. hardware interrupt which happens at the wrong time could crash your machine,
  6194. especially if you run under Windows 3.x.
  6195.  
  6196. You should also keep in mind that the DPMI server can decide to handle some
  6197. of the interrupts itself and not pass them to your program, although this is
  6198. rare.  For example, Win95 won't pass the Ctrl-Alt-Del combination to your
  6199. keyboard interrupt handler, but will rather act on it itself; QDPMI sometimes
  6200. processes Ctrl-C presses so that your program never sees them, etc.
  6201. Sometimes, but not always, you can change some configuration option to make
  6202. some keys get to your handler (e.g., the Alt-TAB setting on the Win3.x `.PIF'
  6203. file).
  6204.  
  6205. If the above still doesn't explain your problem, then post your code on
  6206. comp.os.msdos.djgpp news group or the djgpp mailing list <djgpp@delorie.com>,
  6207. tell there how it fails and somebody will usually have a solution or a
  6208. work-around for you.
  6209.  
  6210. 
  6211. File: djgppfaq.info,  Node: Ports,  Next: Inline Asm,  Prev: HW Int pitfalls,  Up: Low-level
  6212.  
  6213. 18.12 How to read and write ports
  6214. =================================
  6215.  
  6216. **Q*: I need to read from and write to PC ports, and I'm accustomed to using
  6217. the `inp' and `outp' functions.  But I hear they aren't available in DJGPP?*
  6218.  
  6219. *A* :  They are in v2.x.  Just  `#include <pc.h>'  and you get their
  6220. prototypes.  The functions themselves are in the default library.  Note that
  6221. there are also size-specific versions for byte- word- and dword-long access
  6222. (e.g., `inportl' for reading a 32-bit dword), as well as functions to
  6223. read/write sequences of bytes and words, like `inportsb' and `outportsw';
  6224. these are DJGPP-specific.
  6225.  
  6226. 
  6227. File: djgppfaq.info,  Node: Inline Asm,  Prev: Ports,  Up: Low-level
  6228.  
  6229. 18.13 Inline Assembly code with GCC
  6230. ===================================
  6231.  
  6232. **Q*: I am used to writing inline assembly with Borland C, but can't figure
  6233. out the way to do it with GCC...*
  6234.  
  6235. **Q*: How can I reference C variables from my inline assembly code?*
  6236.  
  6237. *A* :  GCC has extensive inline assembly facilities.  They allow you to
  6238. specify everything other compilers let you (like the registers where GCC will
  6239. put specific results), but in a way that doesn't disable compiler
  6240. optimizations of the C code that includes inline assembly.  Because of this
  6241. flexibility, the syntax of the inline assembly code is very different from
  6242. the other DOS-based compilers.  The GCC on-line docs describe these
  6243. facilities in detail; to read the relevant sections, type this from the DOS
  6244. prompt:
  6245.  
  6246.        info gcc "C Extensions" "Extended Asm"
  6247.  
  6248. (Note the quotes: they are important.)  You will, of course, need that the
  6249. stand-alone info reader be installed on your system for the above command to
  6250. work.  If it is not already installed, get the file `txi390b.zip' from the
  6251. DJGPP distribution and install it.
  6252.  
  6253. If you read this FAQ via WWW, you can also read about the GCC inline assembly
  6254. extensions with your Web browser, at this URL:
  6255.  
  6256.      http://www.delorie.com/gnu/docs/gcc/gcc_86.html#SEC89
  6257.  
  6258. 
  6259. File: djgppfaq.info,  Node: Legalese,  Next: Help,  Prev: Low-level,  Up: Top
  6260.  
  6261. 19. Legal Aspects
  6262. *****************
  6263.  
  6264.   This chapter answers some questions about various legal aspects of writing
  6265. programs with DJGPP.
  6266.  
  6267. * Menu:
  6268.  
  6269. * Applications::    Legal restrictions of applications written with DJGPP.
  6270. * Redistribution::  Legal aspects of redistributing DJGPP itself.
  6271.  
  6272. 
  6273. File: djgppfaq.info,  Node: Applications,  Next: Redistribution,  Prev: Legalese,  Up: Legalese
  6274.  
  6275. 19.1 Legal (un)restrictions on DJGPP applications
  6276. =================================================
  6277.  
  6278. **Q*: Can you explain in plain English the legal restrictions of distributing
  6279. programs compiled with DJGPP?*
  6280.  
  6281. **Q*: Can I write commercial programs with DJGPP?*
  6282.  
  6283. *A* :  In most cases, you don't have to worry about any legal restrictions
  6284. when you compile your programs with DJGPP.  Using the GNU C/C++ compiler
  6285. doesn't make your programs subject to *any* restrictions.  The C library
  6286. which comes with DJGPP is *free*, which means you are free to use it in any
  6287. way you like (but please observe *Note basic rules of courtesy:
  6288. Redistribution.)  So, if you write C programs, you have absolutely nothing to
  6289. worry about.
  6290.  
  6291. The basic C++ `iostream' class library (`libiostr.a') and the Standard
  6292. Template Library (`libstdcx.a') which come with DJGPP allow you to use them
  6293. binary-wise (i.e., without changing library sources) in your C++ programs
  6294. *without restrictions*, unless you compile your programs with a compiler
  6295. other than Gcc (which won't happen if you work with DJGPP).  Only the library
  6296. of additional C++ classes (`libgpp.a') requires that you provide your
  6297. customers with source or object code of the application, so they could relink
  6298. the application with future or modified versions of the C++ library.  (If you
  6299. intend to distribute commercial programs linked with the `libgpp.a' library,
  6300. you are strongly advised to read the GNU Library General Public License which
  6301. comes with the library, for rigorous definition of its terms.)
  6302.  
  6303. Two GNU packages, `Flex' and `Bison', are also special in that using them to
  6304. produce your programs doesn't place your programs under GPL or LGPL.  In
  6305. other words, lexers produced by `Flex' and parsers produced by `Bison' do
  6306. *not* imply GPL/LGPL.
  6307.  
  6308. If you *do* use in your program any of the FSF sources that fall under
  6309. GPL/LGPL (like some of the GCC's sources, or the GNU `getopt' or `regex'
  6310. packages which come with many GNU programs), then you must comply with the
  6311. terms of GNU licenses when distributing your programs; in this case your
  6312. entire application becomes GPL.  If that is unacceptable to you, consider
  6313. using the versions of `regex' and `getopt' from the DJGPP C library (which
  6314. are not as powerful, but are free from any restrictions).
  6315.  
  6316. You may ship any of the utilities developed specifically for DJGPP (e.g., the
  6317. floating-point emulator or the CWSDPMI DPMI host) *as distributed by DJ
  6318. Delorie* with your program with no other requirement besides telling your
  6319. customers how to get DJGPP for themselves.
  6320.  
  6321. Note that the above says nothing about the legal aspects of contributed
  6322. packages, like `GRX' and others; you will need to read their docs to find out.
  6323.  
  6324. 
  6325. File: djgppfaq.info,  Node: Redistribution,  Prev: Applications,  Up: Legalese
  6326.  
  6327. 19.2 Legal restrictions of DJGPP utilities and libraries
  6328. ========================================================
  6329.  
  6330. **Q*: Can I redistribute djgpp, and if so, how?*
  6331.  
  6332. **Q*: I run a business that sells shareware for distribution costs.  Can I
  6333. include djgpp on my CD-ROM?*
  6334.  
  6335. **Q*: I want to include djgpp in a product that happens to need a compiler
  6336. provided with it.  Can I do this?*
  6337.  
  6338. **Q*: Is DJGPP GNU software?*
  6339.  
  6340. **Q*: Is DJGPP public domain software?*
  6341.  
  6342. **Q*: Is DJGPP shareware?*
  6343.  
  6344. *A* :  DJGPP is *not* public domain, neither is it shareware (you *don't*
  6345. have to pay a license fee to use DJGPP).  Parts of DJGPP (the compiler and
  6346. some of the development tools) *are* GNU software, so you must comply with
  6347. GNU GPL if you distribute those parts (usually, you won't need to distribute
  6348. them, because they are freely available to everyone).  A small part of the C
  6349. library is taken from the Berkeley BSD sources, and is therefore in public
  6350. domain.  Other parts of DJGPP, which include most of the C library, the free
  6351. DPMI host CWSDPMI, and some of the utilities, are copyrighted, but in a way
  6352. that allows you to use them freely and without restrictions.
  6353.  
  6354. When you redistribute DJGPP itself (as opposed to your programs compiled with
  6355. DJGPP), you must comply to the conditions applicable to whatever you
  6356. distribute.  The parts which are in public domain are, of course, freely
  6357. distributable.  Other parts of DJGPP fall under the DJGPP copyright which
  6358. allows you to redistribute everything provided that you follow these rules:
  6359.  
  6360.    * You must redistribute DJGPP as a whole, with all its parts, including
  6361.      the sources to utilities and libraries that are part of DJGPP, unless
  6362.      other arrangements are first made with DJ Delorie <dj@delorie.com>.
  6363.  
  6364.    * Please make a good faith effort to stay up to date with the latest DJGPP
  6365.      versions, so people don't get old versions with bugs that are long ago
  6366.      solved, or, worse still, versions that are no longer supported.
  6367.  
  6368.    * You must call it *DJGPP* and nothing else.
  6369.  
  6370.    * You may *not* take credit for it, and you must *not* remove any notices
  6371.      in DJGPP that give credit to those who worked on it.
  6372.  
  6373.    * You must tell the recipient how to get the latest version off the
  6374.      Internet, or at least how to find out what the latest version is.
  6375.      DJ Delorie gets a lot of questions from people who got old versions from
  6376.      vendors and don't realize that they're way out of date.
  6377.  
  6378.    * Distributing CWSDPMI with shareware or commercial programs requires
  6379.      notification of its author Charles Sandmann <sandmann@clio.rice.edu> by
  6380.      mail or acknowledged e-mail.
  6381.  
  6382. In addition, it would be a courtesy to inform DJ Delorie <dj@delorie.com>
  6383. that you are including DJGPP in your product, in case this information is
  6384. obsolete.  A token sample of your distribution would be nice also.
  6385.  
  6386. 
  6387. File: djgppfaq.info,  Node: Help,  Next: v2,  Prev: Legalese,  Up: Top
  6388.  
  6389. 20. Getting Help
  6390. ****************
  6391.  
  6392.   This chapter tells you how to get answers to questions you didn't find in
  6393. this FAQ.
  6394.  
  6395. * Menu:
  6396.  
  6397. * DJGPP isn't GNU::             Do *not* post to GNU News groups.
  6398. * Mailing list::                How to post to DJGPP mailing list.
  6399. * Subscribing::                 You can see every posted article.
  6400. * Unsubscribing::               When it's too much to read...
  6401. * Silent list::                 Is the list alive?
  6402. * Duplicates::                  If you get duplicate messages.
  6403. * Newsgroup::                   We prefer you use it instead of the
  6404.                                   mailing list.
  6405.  
  6406. 
  6407. File: djgppfaq.info,  Node: DJGPP isn't GNU,  Next: Mailing list,  Prev: Help,  Up: Help
  6408.  
  6409. 20.1 Don't post DJGPP-specific problems to GNU News groups
  6410. ==========================================================
  6411.  
  6412. **Q*: I post my problem to the "help-gcc" News group, but don't get any
  6413. answers.*
  6414.  
  6415. *A* :  Is your problem likely to be special to the DJGPP port or to the DOS
  6416. environment?  If so, don't post to GNU Usenet groups, but to the
  6417. comp.os.msdos.djgpp news group or to the DJGPP mailing list
  6418. <djgpp@delorie.com>.  People who read GNU News groups usually neither know
  6419. nor care about DOS-specific problems.  Post there only if the problem seems
  6420. to be generic to one of the FSF utilities.  For most problems, this can be
  6421. deduced only after either tracing a problem in the source code or testing it
  6422. on some non-DOS platform.  As a general rule, always post to the DJGPP group
  6423. first.
  6424.  
  6425. 
  6426. File: djgppfaq.info,  Node: Mailing list,  Next: Subscribing,  Prev: DJGPP isn't GNU,  Up: Help
  6427.  
  6428. 20.2 How to post to the mailing list
  6429. ====================================
  6430.  
  6431. **Q*: How do I post to the DJGPP mailing list?*
  6432.  
  6433. *A* :  Send mail to the list address <djgpp@delorie.com> as if it were a
  6434. person.  Please use the mailing list only if you cannot access the DJGPP news
  6435. group, because reflecting the mail to and from the mailing lists incurs
  6436. additional load on the DJGPP server.
  6437.  
  6438. 
  6439. File: djgppfaq.info,  Node: Subscribing,  Next: Unsubscribing,  Prev: Mailing list,  Up: Help
  6440.  
  6441. 20.3 How to become a subscriber to the mailing list
  6442. ===================================================
  6443.  
  6444. **Q*: How do I subscribe to the DJGPP mailing list?*
  6445.  
  6446. *A* :  Send mail to the list server <listserv@delorie.com> (NOT to djgpp@!!),
  6447. leave the subject line empty and in the body write:
  6448.  
  6449.       subscribe <your e-mail address> djgpp
  6450.  
  6451. If you only want to receive announcements of new versions and ported
  6452. software, but don't want to see any other DJGPP mail traffic, subscribe to
  6453. the `djgpp-announce' by sending message to the list server
  6454. <listserv@delorie.com> which says so:
  6455.  
  6456.       subscribe <your e-mail address> djgpp-announce
  6457.  
  6458. The announcements which go to `djgpp-announce' get reflected to `djgpp', so
  6459. you don't need to subscribe to both these lists.
  6460.  
  6461. The DJGPP mailing list is available in the daily and weekly digest forms.  To
  6462. subscribe to one of these, send this one-line message to the above list
  6463. server:
  6464.  
  6465.       subscribe <your e-mail address> djgpp-digest-daily
  6466.  
  6467. or
  6468.  
  6469.       subscribe <your e-mail address> djgpp-digest-weekly
  6470.  
  6471. Note that some mailers reject messages with too large size, so you might have
  6472. trouble with the weekly digest.  If you subscribe to it and don't get the
  6473. digest, try the daily one instead, or switch to another mail software.
  6474.  
  6475. You can also subscribe to DJGPP-related mailing lists through DJ Delorie's
  6476. WWW server, at this URL:
  6477.  
  6478.      http://www.delorie.com/mailing-lists/subscribe.html
  6479.  
  6480. Note that you don't have to subscribe to the djgpp mailing list if you don't
  6481. want to get all the traffic in your mailbox (typically, about 30 messages per
  6482. day).  You can ask questions on the list even if you are not a subscriber,
  6483. because people usually answer both to your e-mail address and to the list
  6484. (well, actually, the mailer program does it automatically and most people
  6485. don't bother to change that).  If you want to be sure the mail gets to you
  6486. directly, say in your message that you don't subscribe to the list, and ask
  6487. people to answer directly.
  6488.  
  6489. If you have a Usenet feed, consider reading the comp.os.msdos.djgpp news
  6490. group instead of subscribing to the mailing list, so that the load on DJ's
  6491. list server will get lower.  There is also a possibility of reading the news
  6492. group (but not posting to it) through the Mercury Gopher server at Michigan
  6493. State University,
  6494. gopher://gopher.msu.edu:3441/chronological%20comp.os.msdos.djgpp
  6495.  
  6496. 
  6497. File: djgppfaq.info,  Node: Unsubscribing,  Next: Silent list,  Prev: Subscribing,  Up: Help
  6498.  
  6499. 20.4 How to unsubscribe from the mailing list
  6500. =============================================
  6501.  
  6502. **Q*: Whew!  There's too much traffic on the djgpp mailing list (at least the
  6503. SysAdmin glaring over my shoulder thinks so... ;-).  How do I unsubscribe
  6504. myself?*
  6505.  
  6506. **Q*: I've been trying for days to unsubscribe from the djgpp mailing list.
  6507. What am I doing wrong?*
  6508.  
  6509. *A* :  You should be sending your unsubscribe messages to the list server
  6510. <listserv@delorie.com> *(not djgpp@delorie.com!),* with the contents being
  6511. just this:
  6512.  
  6513.       unsubscribe <your e-mail address> djgpp
  6514.  
  6515. When you unsubscribe, that stops *new* messages from being sent to you.
  6516. Messages that are already in the mail queues of various mail programs between
  6517. the DJGPP list server and the machine where you receive your mail--cannot be
  6518. stopped.  Therefore, allow some time before you decide that your unsubscribe
  6519. message didn't work.  In extreme cases, when one of the machines that are
  6520. forwarding mail to you is down, you can get the messages upto 5 days after
  6521. you've unsubscribed.
  6522.  
  6523. If you think you have waited enough and the messages still keep coming, write
  6524. to listserv administrator <djgpp-request@delorie.com> and ask him to help you.
  6525.  
  6526. You can also unsubscribe yourself from any of the DJGPP-related mailing lists
  6527. through DJ Delorie's WWW server, at this URL:
  6528.  
  6529.      http://www.delorie.com/djgpp/mailing-lists/subscribe.html
  6530.  
  6531. Recently, DJ has added a mail archive browser to his Web site.  With this
  6532. tool, you can list and read the messages by year, month and day, as well as
  6533. search the last few days for something you might have missed.  This service
  6534. is available via World-Wide Web, at this URL:
  6535.  
  6536.      http://www.delorie.com/djgpp/mail-archives/browse.cgi
  6537.  
  6538. 
  6539. File: djgppfaq.info,  Node: Silent list,  Next: Duplicates,  Prev: Unsubscribing,  Up: Help
  6540.  
  6541. 20.5 If you don't see any message from the list ...
  6542. ===================================================
  6543.  
  6544. **Q*: I don't get any messages from the DJGPP list for several days.  Is the
  6545. list alive?*
  6546.  
  6547. *A* : Try sending a message to the list and see if you get it back.  If not,
  6548. it is possible that your name was inadvertently taken off the list.  This is
  6549. known to happen sometimes (don't ask me how).  Also, if your address begins
  6550. to fail consistently (like "user unknown" or "unknown host"), DJ Delorie
  6551. removes that address from the list, but cannot send a message to this effect,
  6552. for obvious reasons.  You can check if you are subscribed to any of the
  6553. DJGPP-related mailing lists through DJ Delorie's WWW server, at this URL:
  6554.  
  6555.      http://www.delorie.com/djgpp/mailing-lists/subscribe.html
  6556.  
  6557. If this tells you you're not, re-subscribe yourself by sending the above
  6558. subscription message to listserv <listserv@delorie.com>, or via DJ's server,
  6559. at this URL:
  6560.  
  6561.      http://www.delorie.com/djgpp/mailing-lists/subscribe.html
  6562.  
  6563. When in doubt, re-subscribe anyway (it hurts neither you, nor the list
  6564. server).
  6565.  
  6566. If you subscribe to the weekly digest, then the problem might be that your
  6567. mailer rejects the huge message size.  Try the daily digest, or switch to
  6568. another mailer, and see if that helps.
  6569.  
  6570. 
  6571. File: djgppfaq.info,  Node: Duplicates,  Next: Newsgroup,  Prev: Silent list,  Up: Help
  6572.  
  6573. 20.6 Why do I get every message more than once?
  6574. ===============================================
  6575.  
  6576. **Q*: Why am I getting 2 and often more copies of the same message?  Don't
  6577. you people think I can get the idea at the first reading??*
  6578.  
  6579. *A* :  First, check the headers to make sure that all of the duplicate
  6580. messages have their `To:' header addressed to the DJGPP list, not to your
  6581. direct e-mail address.  Often, when people reply to your post, you get the
  6582. direct message, and a `Cc:' (the "carbon copy") one via djgpp list server.
  6583. This is normal behavior.
  6584.  
  6585. If indeed you get more than one copy of a message addressed to the list, it
  6586. is possible that you have added yourself to the list several times.  (This
  6587. could happen if your site supports a mail exploder which re-mails DJGPP to
  6588. you, and you have also subscribed yourself directly.)  One way to check this
  6589. would be to unsubscribe and see if you keep getting mail.  Another way is to
  6590. check your subscription through DJ's server, at this URL:
  6591.  
  6592.      http://www.delorie.com/djgpp/mailing-lists/subscribe.html
  6593.  
  6594. Look out for multiple subscriptions, possibly under different
  6595. names/addresses.  You could also write to DJ Delorie <dj@delorie.com>, and
  6596. ask him to investigate.
  6597.  
  6598. Another thing to do, especially if you think it's not your fault, is to write
  6599. to a user named POSTMASTER at the address of each of the machines whose names
  6600. you find in the `Received:' headers of the bouncing messages (these are
  6601. people responsible for the operation of the mail software at their sites) and
  6602. ask them politely to help.
  6603.  
  6604. Many times this kind of problem is caused by excessive load on the list
  6605. server, so everybody who can please switch to reading the comp.os.msdos.djgpp
  6606. news group and unsubscribe from the list.
  6607.  
  6608. 
  6609. File: djgppfaq.info,  Node: Newsgroup,  Prev: Duplicates,  Up: Help
  6610.  
  6611. 20.7 DJGPP now has a news group!
  6612. ================================
  6613.  
  6614. **Q*: With so much daily traffic (about 30 messages a day), isn't it high
  6615. time to create a Usenet News group?*
  6616.  
  6617. *A* :  Beginning June 1st, 1995, DJGPP *has* its News group!  It is called
  6618. *comp.os.msdos.djgpp*, and it is two-way gated to the venerable DJGPP mailing
  6619. list.  This means messages posted to either the mailing list or the news
  6620. group will appear on both (once, let's hope ;-); you can read either one and
  6621. post to either one, and everybody eventually sees everything.  The entire
  6622. traffic ends up in the mail archives on the DJ's Web server within 24 hours,
  6623. and is available for searching, at this URL:
  6624.  
  6625.      http://www.delorie.com/djgpp/mail-archives/
  6626.  
  6627. If you have a Usenet feed, now is the time to consider unsubscribing from the
  6628. mailing list and switch to reading the news group instead, so that the load
  6629. on the list server will get lower.
  6630.  
  6631. 
  6632. File: djgppfaq.info,  Node: v2,  Next: Miscellany,  Prev: Help,  Up: Top
  6633.  
  6634. 21. Version 2 vs v1.x
  6635. *********************
  6636.  
  6637.   This chapter is for those who are used to working with DJGPP v1.x and want to
  6638. know more about v2 while they consider switching.
  6639.  
  6640. * Menu:
  6641.  
  6642. * New and improved::            What's new in v2.0?
  6643. * Environment::                 How v2.0 environment is different from v1.
  6644.  
  6645. 
  6646. File: djgppfaq.info,  Node: New and improved,  Next: Environment,  Prev: v2,  Up: v2
  6647.  
  6648. 21.1 New features in DJGPP v2
  6649. =============================
  6650.  
  6651. **Q*: What exciting new features will I find in v2 as opposed to v1.x?*
  6652.  
  6653. *A* :  DJGPP v2.x is a DPMI-only environment, and it includes a free DPMI
  6654. host for those who don't have another DPMI provider installed.  In addition,
  6655. v2 features the following major improvements upon v1.1x:
  6656.  
  6657.    * much faster extender (the free DPMI host) and library functions;
  6658.  
  6659.    * very low memory footprint of the DPMI host below 640KB;
  6660.  
  6661.    * the DPMI server is loaded only once: no more problems with spawning child
  6662.      programs (e.g., almost unlimited recursive Make's);
  6663.  
  6664.    * ANSI- and POSIX-compliant libraries and header files, which should make
  6665.      porting Unix programs a lot easier;
  6666.  
  6667.    * support for signals;
  6668.  
  6669.    * 387 emulation under DPMI;
  6670.  
  6671.    * graphics which works in *any* setup, including under Windows;
  6672.  
  6673.    * fixes of many bugs in hardware interrupts' and mixed-mode programming
  6674.      support;
  6675.  
  6676.    * support of long filenames on Windows 95;
  6677.  
  6678.    * ability to build all of DJGPP without commercial products (like Turbo C
  6679.      required to compile go32 in v1.x);
  6680.  
  6681. If you want to help in further v2 development, check out the list of features
  6682. which have yet to be done and volunteer to implement some of them.
  6683.  
  6684. 
  6685. File: djgppfaq.info,  Node: Environment,  Prev: New and improved,  Up: v2
  6686.  
  6687. 21.2 DJGPP environment in v2.x
  6688. ==============================
  6689.  
  6690. **Q*: There's been this talk about v2 and about `go32' going away in that
  6691. version, but I'm confused on what the new setup will be.  Could you clarify
  6692. the details of this change?*
  6693.  
  6694. *A* :  In v1.x of DJGPP, the `go32' extender was responsible for the
  6695. following:
  6696.  
  6697.    * Loading and running the application in protected mode.
  6698.  
  6699.    * Managing protected-mode and virtual memory.
  6700.  
  6701.    * "Extending DOS" so that protected-mode programs could issue calls to
  6702.      real-mode DOS and BIOS services and still run.  (This is mostly done by
  6703.      switching to real mode and reissuing the interrupt, but some services
  6704.      require special handling by the extender.)
  6705.  
  6706.    * Handling of hardware interrupts which happen while the CPU is in
  6707.      protected mode.
  6708.  
  6709.    * Loading 387 emulator (if required).
  6710.  
  6711.    * Loading the graphics driver and working with VGA bank-switching to create
  6712.      an illusion of a linear video memory.
  6713.  
  6714.    * Command-line and wild-card expansion in a Unix-like fashion.
  6715.  
  6716. In v2.x, a minority of these functions are done by a DPMI host, which is a
  6717. memory-resident software required to run protected-mode programs under
  6718. MS-DOS.  There are a few commercial DPMI hosts (like Quarterdeck's `QDPMI',
  6719. Qualitas `386Max', MS-Windows 3.x and Win95, OS/2, even Linux), but DJGPP v2
  6720. comes with a free DPMI host called `CWSDPMI' for those who don't have one
  6721. already.  Loading the application into protected-mode memory (a function done
  6722. in v1.x by `go32') is handled by a 2KB-long real-mode stub which runs at
  6723. start-up, before the application's `main' functions is called (the stub will
  6724. also load `CWSDPMI' if no other DPMI host is detected).  All the other custom
  6725. code required to process BIOS- and DOS-related calls from protected-mode is
  6726. now built into the library functions which your program calls, so there is no
  6727. need for a special extender, because the application just issues DPMI calls
  6728. serviced by the DPMI host.
  6729.  
  6730. `CWSDPMI' can be loaded as a TSR, even loaded `HIGH' into the HMA/UMB, which
  6731. will make applications load much faster.
  6732.  
  6733. 
  6734. File: djgppfaq.info,  Node: Miscellany,  Next: About,  Prev: v2,  Up: Top
  6735.  
  6736. 22. Miscellany
  6737. **************
  6738.  
  6739.   This chapter is a hodgepodge of questions which don't belong to any of the
  6740. other chapters.
  6741.  
  6742. * Menu:
  6743.  
  6744. * Changing::            How to change any DJGPP package?
  6745. * Samples::             Where to find sample/ported code for DJGPP?
  6746. * Symlinks::            Yes, DJGPP allows them (well, almost...)
  6747. * DPMI Spec::           Where to look for DPMI specifications.
  6748. * WWW::                 The DJGPP Web site.
  6749. * Upload::              Where to upload your DJGPP packages.
  6750. * Cross-DJGPP::         You can use DJGPP for cross-development.
  6751. * 0xfe+0x20::           Is this a bug?
  6752. * Struct size::         What is the size of a struct under DJGPP?
  6753. * Struct packing::      C++ compiler doesn't pack structs.
  6754. * Int 24h::             Catching those "Abort, Retry" messages.
  6755. * go32-v2::             What is go32-v2 for?
  6756. * DXE::                 What are those `.dxe' files?
  6757. * LFN::                 LFN support has some subtle bugs.
  6758. * Missing separator::   What does Make mean by that?
  6759. * Zoneinfo::            What's in that *zoneinfo/* directory?
  6760. * FAQ format::          How to convert this FAQ to other formats.
  6761.  
  6762. 
  6763. File: djgppfaq.info,  Node: Changing,  Next: Samples,  Prev: Miscellany,  Up: Miscellany
  6764.  
  6765. 22.1 How to change a DJGPP package?
  6766. ===================================
  6767.  
  6768. **Q*: I want to change cc1.  How do I do this?*
  6769.  
  6770. **Q*: How do I fix a bug/add a feature to one of the DJGPP programs?*
  6771.  
  6772. *A* :  First, get the sources.  These are called `*s.zip' in the DJGPP
  6773. distribution.  The C Library sources are in `djlsr201.zip'.  Some sources are
  6774. too big, and might be split into multiple zips, all of which must be unzipped
  6775. to get a complete source distribution, like this:
  6776.  
  6777. `em1934s1.zip'
  6778. `em1934s2.zip'
  6779. `em1934s3.zip'
  6780. All sources are shipped in ready-to-build form.  Any diffs that come with the
  6781. source distribution, like the files in the `diffs/' directory, have already
  6782. been applied, and any configuration scripts and/or batch files have been run.
  6783.  
  6784. Next, try to build the program without changing it.  Some packages will have
  6785. a `CONFIGUR.BAT' file; if so, run it first.  If there is a `MAKE.BAT' file,
  6786. run it; if not, look for a file named `MAKEFILE.DJ' or `MAKEFILE.DJG';
  6787. sometimes these will be in a subdirectory called `dos/', or `msdos/', or
  6788. `pc/.'  If there is such a file, then type, e.g., `make -f makefile.djg', if
  6789. not, just say `make' and see what happens.  (The reason for an apparent lack
  6790. of a standard here is that different packages were ported to DJGPP by
  6791. different people, as best as they saw fit.)  After you've successfully built
  6792. the program, make your fixes and build the program the same way you did
  6793. before.
  6794.  
  6795. Note that generally to build these programs, you must have the GNU Make
  6796. program, e.g.
  6797. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/mak375b.zip, and some
  6798. makefiles require that you install additional utilities, like Sed
  6799. ftp.simtel.net/pub/simtelnet/gnu/djgpp/sed118b.zip, e.g. ftp://.  Sometimes
  6800. the makefiles won't even run under `COMMAND.COM' (they require a smarter
  6801. shell).  In that case, either get a better shell, or convert the makefile to
  6802. be runnable by `COMMAND', or do the required steps manually.  If the Makefile
  6803. is too complex for you and you can't figure out what are the necessary
  6804. commands, invoke make with `-n' switch and see what it would have done.
  6805.  
  6806. If your machine lacks floating-point hardware (like a 386 without a 387, or a
  6807. 486SX), then you should know that current versions of GNU Sed and GNU Make
  6808. issue floating point instructions, so you will have to make provisions for
  6809. loading an emulator, see above, *Note FP Emulation: Emulation.  The port of
  6810. Make 3.75 and later can be built so that it doesn't issue FP instructions,
  6811. but you will have to get the sources and recompile Make first, as the stock
  6812. version wasn't configured in that way.
  6813.  
  6814. If you think that you found a bug in one of the programs or libraries written
  6815. for DJGPP (e.g. the C library, CWSDPMI, symify, etc.) be sure to check the
  6816. list of known bugs, at this URL:
  6817.  
  6818.      http://www.delorie.com/djgpp/doc/kb/kb_7.html#SEC4
  6819.  
  6820. If your bug is not there, you can later submit it to the bug-tracking system,
  6821. at this URL:
  6822.  
  6823.      http://www.delorie.com/djgpp/bugs/
  6824.  
  6825. Before you submit a bug report, please make every effort to verify that your
  6826. bug is not caused by incorrect usage, or by problems in your DJGPP
  6827. installation.  Reports such as "All DJGPP programs crash" or "I cannot
  6828. compile any program" are clearly not bugs, because these things work for many
  6829. hundreds of DJGPP users every day.  If you can investigate the cause of the
  6830. bug and find a solution that makes it go away, submit a bug report with all
  6831. the details.  If you cannot find the cause(s), I suggest posting your problem
  6832. description to the news group and asking people to verify that it is indeed a
  6833. bug, before you submit a bug report.  The bug-tracking system includes a list
  6834. of all known bugs, many of them with solutions or work-arounds; please check
  6835. them before creating a new bug report.
  6836.  
  6837. 
  6838. File: djgppfaq.info,  Node: Samples,  Next: Symlinks,  Prev: Changing,  Up: Miscellany
  6839.  
  6840. 22.2 Where to find sample DJGPP code or a package ported to DJGPP?
  6841. ==================================================================
  6842.  
  6843. **Q*: Where can I find an example of XXXX / a package doing YYYY ?*
  6844.  
  6845. *A* :  Stephen Turnbull <turnbull@shako.sk.tsukuba.ac.jp> has compiled a list
  6846. of publicly available packages related to DJGPP, based on the DJGPP mailing
  6847. list traffic.  The list is still under construction (Steve says that many
  6848. pointers have not been followed up to get host and directory references
  6849. right), so it must be taken with a grain of salt.  Check out Steve's list, at
  6850. this URL:
  6851.  
  6852.      http://turnbull.sk.tsukuba.ac.jp/public-ftp/djgpp/doc/documentation.list.html
  6853.  
  6854. Here is a list of places you might look into for examples of frequently
  6855. needed code fragments, or for packages people keep asking about:
  6856.  
  6857.    * Interrupt-driven support of peripheral devices and hooking hardware
  6858.      interrupts:
  6859.  
  6860.         - Alaric B. Williams <alaric@abwillms.demon.co.uk> maintains a
  6861.           library of utility functions and example handlers, useful for
  6862.           writing hardware interrupt handling code.  You can get Alaric's
  6863.           library with your Web browser, at this URL:
  6864.  
  6865.                http://www.abwillms.demon.co.uk/prog/index.html
  6866.  
  6867.         - Bill Currie <bill_currie@MAIL.TAIT.CO.NZ> has written sample code
  6868.           for hardware interrupt handlers, e.g.
  6869.  
  6870.  
  6871.  
  6872.  
  6873.           ftp://ftp.delorie.com/pub/djgpp/contrib/sample-interrupt-handlers-v2.zip
  6874.           which should get you off the ground if you need to write your own
  6875.           handlers.
  6876.  
  6877.         - Martynas Kunigelis <martynas.kunigelis@vm.ktu.lt> donated a
  6878.           tutorial and a working code that installs a keyboard interrupt
  6879.           handler, e.g.
  6880.           ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/mkkbd3.zip that
  6881.           can also serve as a good example of a hardware interrupt handler.
  6882.  
  6883.         - you can look at the latest version of Sound Blaster support library
  6884.           at the Oulu repository, e.g.
  6885.           ftp://x2ftp.oulu.fi/pub/msdos/programming/djgpp2/sb05_dj2.zip or at
  6886.           the DJGPP server, e.g.
  6887.           ftp://ftp.delorie.com/pub/djgpp/contrib/sb05_dj2.zip; this package
  6888.           is maintained by Joel Hunter <jhunter@kendaco.telebyte.net>.
  6889.  
  6890.         - check out the example of hooking the timer interrupt, e.g.
  6891.           ftp://ftp.coast.net/Coast/msdos/c/pctime13.zip.
  6892.  
  6893.         - if you need a serial communications library, check out SVAsync,
  6894.           e.g. ftp://ftp.delorie.com/pub/djgpp/contrib/svasync.zip.
  6895.  
  6896.    * Network support libraries:
  6897.  
  6898.         - the TCPLIB library, e.g.
  6899.           ftp://lab1.psy.univie.ac.at/pub/tcplib-dj200/tcplib-dj200.1.tar.gz
  6900.           provides the TCP/IP sockets interface.  (I am told that you can
  6901.           safely ignore the warnings you get when compiling the package.)
  6902.  
  6903.         - a port of WATTCP library, e.g.
  6904.           ftp://ftp.msen.com/pub/vendor/snsi/wattcp/gnu-c/.
  6905.  
  6906.         - a modified port of WATTCP library done by DJ Delorie
  6907.           <dj@delorie.com> is available from DJ's server, e.g.
  6908.           ftp://ftp.delorie.com/pub/djgpp/dj/.
  6909.  
  6910.    * Port of curses library to DJGPP:
  6911.  
  6912.         - download PDCurses package, e.g.
  6913.           ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/pdc22.zip.
  6914.  
  6915.    * Dynamically loaded code:
  6916.  
  6917.         - Check out the DLM (Dynamic Link Modules) environment for DJGPP,
  6918.           written by "Ilya P. Ryzhenkov" <ilya@spy.isp.nsc.ru>, available from
  6919.           his machine, e.g. ftp://spy.isp.nsc.ru/sys/pub/dlm/.
  6920.  
  6921.    * X library:
  6922.  
  6923.         - the Xlibemu library, e.g. ftp://asterix.inescn.pt/pub/PC/X/ includes
  6924.           `Xt' and `Xmu' toolkits, a 3D version of the `AW' toolkit, a few
  6925.           demo applications (e.g. `xmine'), and can be used to compile
  6926.           `Tcl'/`Tk' and GNU Emacs with X support.  Xlibemu is based on X11R5
  6927.           and was developed by Antonio Costa <acc@asterix.inescn.pt> for
  6928.           DJGPP v1.x.  It is also available on an alternative site, e.g.
  6929.           ftp://groucho.idt-isep.ipp.pt/pub/pc/djgpp/etc/X/ and on the DJGPP
  6930.           server, e.g. ftp://ftp.delorie.com/pub/djgpp/contrib/Xlibemu/.
  6931.  
  6932.         - the Xlib and Xt for DV/X environment, e.g.
  6933.           ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v1tk/qddvx102.zip (you
  6934.           will also need qdlib102.zip and qdtkt102.zip from the same site).
  6935.  
  6936.    * Ports of various GNU utilities not included in DJGPP:
  6937.  
  6938.         - Many of these are now part of DJGPP, so first look on SimTel.NET
  6939.           mirrors with the rest of DJGPP, e.g.
  6940.           ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/.
  6941.  
  6942.         - Marc Singer <elf@netcom.com> maintains a port of RCS, the Revision
  6943.           Control System, to DJGPP, e.g.
  6944.           ftp://ftp.netcom.com/pub/el/elf/rcsdos/.
  6945.  
  6946.    * GUI libraries:
  6947.  
  6948.         - SWORD (the System of Windows for the ORganization of the Desktop)
  6949.           is a Graphic User Interface library made with C++ objects, written
  6950.           and maintained by Eric Nicolas <nicolas@JUPITER.saclay.cea.fr>.  The
  6951.           latest version 2.1 is available from the DJGPP v2tk subdirectory,
  6952.           e.g. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/ as
  6953.           sw21_*.zip.
  6954.  
  6955.         - check out the BCGUI package, at this URL:
  6956.  
  6957.                http://www.delorie.com/djgpp/dl/contrib/
  6958.  
  6959.           or get BCGUI via FTP, e.g.
  6960.           ftp://ftp.delorie.com/pub/djgpp/contrib/bcguiNNN.zip or get BCGUI
  6961.           at Stephen Turnbull's server, e.g.
  6962.           ftp://turnbull.sk.tsukuba.ac.jp/pub/djgpp/packages/bcguiNNN.zip.
  6963.  
  6964.         - If you actually have the original Borland Turbo Vision, then you
  6965.           might want to get patches to compile Turbo Vision under DJGPP, e.g.
  6966.           ftp://ftp.uni-stuttgart.de/pub/systems/os2/programming/support/.
  6967.           For more info on this port, visit the TVPlus site, at this URL:
  6968.  
  6969.                http://www.zeta.org.au/~grove/tvhome.html
  6970.  
  6971.         - Another port of Turbo Vision library was done by Robert Hoehne
  6972.           <Robert.Hoehne@Mathematik.TU-Chemnitz.DE>, and can be downloaded
  6973.           via WWW, at this URL:
  6974.  
  6975.                http://www.tu-chemnitz.de/~rho/tvision.html
  6976.  
  6977.           , and also from the DJGPP distribution sites, e.g.
  6978.           ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/tvisionb.zip
  6979.  
  6980.    * Game programming:
  6981.  
  6982.         - Try the Jlib gaming/graphics library, e.g.
  6983.           ftp://x2ftp.oulu.fi/pub/msdos/programming/djgpp2/jlib_NNN.zip
  6984.           written by J P Griffiths <jpg@cs.waikato.ac.nz>.  This library is
  6985.           best suited to multi-platform game programming, since it's portable
  6986.           to Linux.
  6987.  
  6988.         - Also see the Allegro game programming library, e.g.
  6989.           ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2tk/alleg211.zip,
  6990.           written by Shawn Hargreaves <Shawn@talula.demon.co.uk>.  It is also
  6991.           available from the Allegro home page, at this URL:
  6992.  
  6993.                http://www.talula.demon.co.uk/allegro/
  6994.  
  6995.             This library is best suited to DOS game programming.
  6996.  
  6997.    * VGA Mode-X graphics:
  6998.  
  6999.         - Paul Fenwick <bg914@FreeNet.Carleton.CA> wrote an X-Mode package
  7000.           Xlib, e.g. ftp://ftp.delorie.com/pub/djgpp/contrib/xlibdj24.zip or
  7001.           Xlib at Oulu, e.g.
  7002.           ftp://x2ftp.oulu.fi/pub/msdos/programming/djgpp2/xlibdj24.zip.
  7003.  
  7004.    * Multi-tasking libraries:
  7005.  
  7006.         - The POSIX Pthreads library, e.g.
  7007.           ftp://ftp.cs.fsu.edu/pub/PART/PTHREADS/pthreads.zip is a portable,
  7008.           standard package supported on many platforms.
  7009.  
  7010. 
  7011. File: djgppfaq.info,  Node: Symlinks,  Next: DPMI Spec,  Prev: Samples,  Up: Miscellany
  7012.  
  7013. 22.3 How to create symbolic links to programs
  7014. =============================================
  7015.  
  7016. **Q*: How do I create symbolic links?*
  7017.  
  7018. **Q*: I have this program that behaves differently depending on the name it's
  7019. called.  Under Unix, I just create symbolic links to achieve that, but DOS
  7020. doesn't support links.  Do I have to put several identical programs under
  7021. different names on my disk??*
  7022.  
  7023. *A* :  DJGPP allows you to simulate symbolic links to programs.  Generate a
  7024. stub (which is a small DOS program attached to every DJGPP program by the
  7025. `stubify.exe' program), call it by the name of the link you want, then edit
  7026. its header to run another program.  For example, let's say the real program
  7027. is `dj1.exe' and we want to make a link called `dj2.exe' that really calls
  7028. `dj1.exe.'  First, generate a stub under the name `dj2.exe.'  Next, run
  7029. `STUBEDIT' to modify the new program's stub info block and change the name of
  7030. the executable it runs.  In this case, we'd change it to `dj1':
  7031.  
  7032.       C:\USR\BIN> stubify -g dj2.exe
  7033.       C:\USR\BIN> stubedit dj2.exe runfile=dj1
  7034.  
  7035. Voila!  Now, when you run `dj2', it tells the stub to load the image of
  7036. `dj1', but pass "dj2" in `argv[0].'
  7037.  
  7038. If you use the DJGPP port of GNU Fileutils 3.13 or later, the `ln' program
  7039. there can do the above steps for you if you say this (like on Unix):
  7040.  
  7041.       ln -s dj1.exe dj2.exe
  7042.  
  7043. 
  7044. File: djgppfaq.info,  Node: DPMI Spec,  Next: WWW,  Prev: Symlinks,  Up: Miscellany
  7045.  
  7046. 22.4 Where to find the DPMI specification?
  7047. ==========================================
  7048.  
  7049. **Q*: Where can I find the specifications for the DPMI functions?*
  7050.  
  7051. *A* :  You can find the DPMI 0.9 spec by anonymous ftp to one of the
  7052. following sites:
  7053.  
  7054. At the Quarterdeck ftp site, e.g. ftp://qdeck.com/pub/memory/dpmispec.zip.
  7055.  
  7056. At the Oulu repository of PC-specific programming info, e.g.
  7057. ftp://x2ftp.oulu.fi/pub/msdos/programming/specs/dpmispec.arj.
  7058.  
  7059. The DPMI 1.0 specs are available by anonymous ftp from the Intel anonymous
  7060. ftp site, e.g. ftp://ftp.intel.com/pub/IAL/software_specs/dpmiv1.txt.  (The
  7061. file `dpmip1.zip' at the same location is the PostScript version of this
  7062. spec.)
  7063.  
  7064. Some information about the DPMI API is also found in the Ralf Brown's
  7065. Interrupt List, e.g.
  7066. ftp://ftp.simtel.net/pub/simtelnet/msdos/info/inter53c.zip.  Look at the
  7067. functions of Interrupt 31h, or search the files for the word `DPMI.'
  7068.  
  7069. You can also browse the DPMI spec on-line, at this URL:
  7070.  
  7071.      http://www.delorie.com/djgpp/doc/dpmi/
  7072.  
  7073. 
  7074. File: djgppfaq.info,  Node: WWW,  Next: Upload,  Prev: DPMI Spec,  Up: Miscellany
  7075.  
  7076. 22.5 The DJGPP Web site.
  7077. ========================
  7078.  
  7079. **Q*: Where is the DJGPP Web site?*
  7080.  
  7081. *A* :  Yes, DJGPP has its own home on the Internet, set up and maintained by
  7082. (who else?) DJ Delorie <dj@delorie.com>.  It has an HTML version of this FAQ
  7083. list with search capabilities, the entire set of DJGPP distribution files, a
  7084. searchable archive of the DJGPP mailing list and news group traffic, plus
  7085. other useful and interesting information about DJGPP.  For instance, did you
  7086. ever wonder how DJGPP got started and what DJ's original goals were?
  7087. Rejoice: the Web site includes the story of DJGPP genesis, at this URL:
  7088.  
  7089.      http://www.delorie.com/djgpp/history.html
  7090.  
  7091. To visit, point your Web browser to the DJGPP Web site, at this URL:
  7092.  
  7093.      http://www.delorie.com/djgpp/
  7094.  
  7095. 
  7096. File: djgppfaq.info,  Node: Upload,  Next: Cross-DJGPP,  Prev: WWW,  Up: Miscellany
  7097.  
  7098. 22.6 Where to upload your contributions to DJGPP
  7099. ================================================
  7100.  
  7101. **Q*: I wrote a program using DJGPP.  How can I make it available to others?*
  7102.  
  7103. **Q*: I found and corrected a bug in one of the programs distributed with
  7104. DJGPP.  Where should I put it?*
  7105.  
  7106. *A* :  If the program/patches are small enough, consider posting it to the
  7107. mailing list or the comp.os.msdos.djgpp news group as uuencoded compressed
  7108. archive (to conserve space).
  7109.  
  7110. If the compressed file is larger than, say, 50K bytes, it's best to upload it
  7111. to a public site where everybody can get it.  You can upload your
  7112. contribution to a special directory on the DJ Delorie's FTP server, e.g.
  7113. ftp://ftp.delorie.com/incoming/.  This directory is write-only, and it gets
  7114. purged every couple of days, so be sure to write to DJ Delorie
  7115. <dj@delorie.com> about your upload; he will then move it to the
  7116. `/pub/djgpp/contrib' directory.
  7117.  
  7118. If you decide to upload, please send mail to the `djgpp-announce' list with a
  7119. brief description of your program/patch.  (The message will get reflected to
  7120. both the news group and the DJGPP mailing list, so you don't have to
  7121. cross-post there, but it also goes to people who only subscribe to
  7122. djgpp-announce list because they want to get such announcements and nothing
  7123. else.)
  7124.  
  7125. If your program is more than a patch or a beta version, you might consider
  7126. uploading it to the DJGPP archives on SimTel.NET.  If you decide to do it,
  7127. write to DJ Delorie <dj@delorie.com> and ask him for uploading instructions.
  7128. Material uploaded there gets automatically distributed to all of the
  7129. SimTel.NET mirrors throughout the world, which makes it easier to get.
  7130.  
  7131. DJ Delorie requests that all contributed packages uploaded to his server be
  7132. source-only distributions; don't bother to include libraries or pre-compiled
  7133. binaries, since DJ deletes them when he opens the zip archive.  This is so
  7134. there will be no danger of distributing programs infected by a virus (as
  7135. there are no 32-bit virus-scanners yet).  Please avoid uploading
  7136. self-extracting archives because DJ extracts them on a Unix machine which
  7137. can't run DOS executables.
  7138.  
  7139. 
  7140. File: djgppfaq.info,  Node: Cross-DJGPP,  Next: 0xfe+0x20,  Prev: Upload,  Up: Miscellany
  7141.  
  7142. 22.7 DJGPP as cross-compiler
  7143. ============================
  7144.  
  7145. **Q*: I want to use DJGPP as a cross-compiler for Motorola 68K targets.  How
  7146. should I proceed about this?*
  7147.  
  7148. **Q*: I want to build GCC as a Unix-to-DOS cross-compiler.  What should I do?*
  7149.  
  7150. *A* :  If you want a cross-compiler for m68k on a DOS machine, you need DJGPP
  7151. configured as `host=i386-go32', and `target=m68k-coff.' This has been done
  7152. already, e.g. ftp://ftp.lysator.liu.se/pub/msdos/gnu/gcc-dos-m68k/.  The
  7153. binaries there are based on GCC 2.6.0.  This package is reportedly no longer
  7154. supported, but if you have questions about it, you can send them to Jim
  7155. Karpinski <jk55@cornell.edu>.  You can also try to contact Kai Ruottu
  7156. <karuottu@freenet.hut.fi>, who is the provider of DOS-hosed gcc-m68k.
  7157.  
  7158. An "RPM" (Redhat Package Maintenance) distribution of the Linux to DOS
  7159. cross-compiler is available, which is based on DJGPP v2.01 and includes
  7160. everything you need to create DJGPP binaries on Linux (without running
  7161. DOSEmu).  This package has been built by James Soutter <cgjks1@lut.ac.uk>
  7162. using the instructions below; you will need Linux and RPM 2.2.7.  The RPM
  7163. packaged cross-compiler is available from Redhat site, e.g.
  7164. ftp://ftp.redhat.com/pub/incoming/djgpp-2.1-1.i386.rpm; the sources are also
  7165. available, e.g. ftp://ftp.redhat.com/pub/incoming/djgpp-2.1-1/src.rpm.
  7166.  
  7167. For building GCC as a Unix-to-DOS cross-compiler, here are the instructions
  7168. on how to do it.  (Unfortunately, "make install" in the Gcc distribution does
  7169. exactly the wrong thing by default, so you end up copying a lot of stuff
  7170. around manually.)
  7171.  
  7172. First, use the original FSF distributions for Gcc and Binutils, not the
  7173. source distributions from DJGPP.  That's because the DJGPP archives have
  7174. sources patched to compile on MS-DOS and sometimes omit files that aren't
  7175. necessary for DJGPP.  In particular the GCC sources lack many files that the
  7176. MS-DOS build doesn't need, to conserve space.
  7177.  
  7178. Unpack Gcc and Binutils into a directory, let's call it `X/.'  Thus, you
  7179. have, say, `X/gcc-2.7.0' and `X/binutils-2.5.2.'  The following sequence of
  7180. commands should make the job:
  7181.  
  7182.      mkdir X/dos-binutils
  7183.      cd X/dos-binutils
  7184.      configure --target=i386-coff-go32
  7185.      make CFLAGS=-O
  7186.      
  7187.      mkdir -p /usr/local/i386-go32-msdos/bin
  7188.      
  7189.      cd binutils
  7190.      cp ar c++filt objcopy objdump size /usr/local/i386-go32-msdos/bin
  7191.      cp nm.new /usr/local/i386-go32-msdos/bin/nm
  7192.      cp strip.new /usr/local/i386-go32-msdos/bin/strip
  7193.      
  7194.      cd ../gas
  7195.      cp as.new /usr/local/i386-go32-msdos/bin/as
  7196.      cp gasp.new /usr/local/i386-go32-msdos/bin/gasp
  7197.      
  7198.      cd ../ld
  7199.      cp ld.new /usr/local/i386-go32-msdos/bin/ld
  7200.      
  7201.      cd ../../..
  7202.      mkdir X/dos-gcc
  7203.      cd X/dos-gcc
  7204.      configure --target=i386-go32-msdos
  7205.      # Note: this produces errors building libgcc.a.  Ignore them.
  7206.      # The libraries will come from the cross-compiler kit.
  7207.      make LANGUAGES=c CFLAGS=-O
  7208.      
  7209.      cp xgcc /usr/local/bin/gcc-dos
  7210.      cp cc1 /usr/local/i386-go32-msdos/bin/cc1
  7211.      cp cccp /usr/local/i386-go32-msdos/bin/cpp
  7212.  
  7213. Unzip the DJDev and Gcc distributions in, say, /usr/local/djgpp.  Ideally,
  7214. build libgcc.a on a DOS machine, or get it from the `djcrx200.zip' archive.
  7215.  
  7216. Remove all `^M' characters from include files (you can compile DTOU.c on the
  7217. Unix box to make this easier).  Alternatively, use the `-a' switch to UnZip
  7218. when unzipping the archives.
  7219.  
  7220. Change lib/djgpp.lnk to use "coff-i386" instead of "coff-go32" and remove the
  7221. `^M' characters from that file also.
  7222.  
  7223.      mkdir -p /usr/local/lib/gcc-lib/i386-go32-msdos/2.7.0
  7224.      cd /usr/local/lib/gcc-lib/i386-go32-msdos/2.7.0
  7225.      ln -s /usr/local/djgpp/include .
  7226.      ln -s /usr/local/djgpp/lib/* .
  7227.  
  7228. Build `stubify' and install it in `/usr/local/i386-go32-msdos/bin.'  You
  7229. might need to insert these two lines at the beginning of `stubify.c':
  7230.  
  7231.       `#include <sys/types.h>'
  7232.       `#include <unistd.h>'
  7233.  
  7234. That's it!  To build a program for DOS, say something like this:
  7235.  
  7236.       gcc-dos hello.c -o hello.exe
  7237.  
  7238. 
  7239. File: djgppfaq.info,  Node: 0xfe+0x20,  Next: Struct size,  Prev: Cross-DJGPP,  Up: Miscellany
  7240.  
  7241. 22.8 GCC says "garbage at end of number"
  7242. ========================================
  7243.  
  7244. **Q*: There is a severe bug in GCC: it says "garbage at end of number" for
  7245. this line:*
  7246.  
  7247.       i = 0xfe+0x20;
  7248.  
  7249. *Ain't it silly that such a great compiler would fail so miserably?*
  7250.  
  7251. *A* :  That's not a bug, that's a feature of the *ANSI C language
  7252. definition.*  By ANSI rules, the above expression is a single "preprocessing
  7253. token", unless you place whitespace in front of the plus sign.  The reason
  7254. for this seemingly counterintuitive feature is the syntax of floating-point
  7255. constants in which letters `e' and `E' followed immediately by a sign signal
  7256. a decimal exponent.  You can use the `-traditional' compiler switch to turn
  7257. this feature off (together with a plethora of other ANSI features; see the
  7258. GCC docs for details).
  7259.  
  7260. 
  7261. File: djgppfaq.info,  Node: Struct size,  Next: Struct packing,  Prev: 0xfe+0x20,  Up: Miscellany
  7262.  
  7263. 22.9 What should sizeof (struct xyzzy) return?
  7264. ==============================================
  7265.  
  7266. **Q*: When I call `sizeof' on a struct, I sometimes get values which are
  7267. larger than the sum of the sizes of the struct fields, whereas in Borland C++
  7268. I always get the correct result.  Is it a bug in GCC?*
  7269.  
  7270. **Q*: I have a program that reads struct contents from a binary file.  It
  7271. works OK when compiled with BC, but reads garbage when compiled with DJGPP.
  7272. This must be a bug in DJGPP, right?*
  7273.  
  7274. *A* : No, it's not a bug.  GCC generates 32-bit code, and in that mode, there
  7275. is a significant penalty (in terms of run-time performance) for unaligned
  7276. accesses, like accessing a 16-bit short which isn't aligned on a word
  7277. boundary, or accessing a 32-bit int which isn't aligned on a dword boundary.
  7278. To produce faster code, GCC pads struct fields so that each field can be
  7279. accessed without delays; this sometimes produces struct size which is larger
  7280. than the sum of the sizes of its fields.  If you need to minimize this
  7281. padding (e.g., if your program uses large arrays of such structs, where
  7282. padding will waste a lot of memory), lay out your structures so that the
  7283. longer fields are before the shorter ones.  For example, let's say that you
  7284. have a struct defined thus:
  7285.  
  7286.        struct my_struct {
  7287.          char name[7];
  7288.          unsigned long offset;
  7289.          double quality;
  7290.        };
  7291.  
  7292. To make such a struct use the least number of bytes, rearrange the fields,
  7293. like this:(1) (*note Struct size-Footnotes::)
  7294.  
  7295.        struct my_struct {
  7296.          double quality;
  7297.          unsigned long offset;
  7298.          char name[7];
  7299.        };
  7300.  
  7301. If the layout of the structure cannot be changed (e.g., when it must match
  7302. some external specification, like a block of data returned by a system call),
  7303. you can use the `__attribute__((packed))' extension of GCC (*Note the Gcc
  7304. docs: (gcc)Type Attributes.) to prevent GCC from padding the structure
  7305. fields; this will make accesses to some of the fields slower.
  7306.  
  7307. Beginning with version 2.7.0, GCC has a command-line option `-fpack-struct'
  7308. which causes GCC to pack all members of all structs together without any
  7309. holes, just as if you used `__attribute__((packed))' on every struct
  7310. declaration in the source file you compile with that switch.  If you use this
  7311. switch, be sure that source files which you compile with it don't use *any*
  7312. of the structures defined by library functions, or you will get some fields
  7313. garbled (because the library functions weren't compiled with that switch).
  7314. Alternatively, you could declare any single structure to be packed, like so:
  7315.  
  7316.        struct {
  7317.          char name[7];
  7318.          unsigned long offset;
  7319.          double quality;
  7320.        } __attribute__ ((packed));
  7321.  
  7322. However, note that the latter will only work when you compile it as a C
  7323. source; C++ doesn't allow such syntax, and you will have to fall back to
  7324. declaring each struct field with the packed attribute.  Therefore, it's best
  7325. to only use declarations such as above if you are *certain* it won't be ever
  7326. compiled as a C++ source.
  7327.  
  7328. The padding of struct fields should be considered when you read or write
  7329. struct content from or to a disk file.  In general, this should only be done
  7330. if the file is read and written by the same program, because the exact layout
  7331. of the struct fields depends on some subtle aspects of code generation and
  7332. the compiler switches used, and these may differ between programs, even if
  7333. they were compiled by the same compiler on the same system.  If you do need
  7334. this method, be aware of the struct field padding and don't assume that the
  7335. number of the file bytes that the structure uses is equal to the sum of the
  7336. fields' sizes, even if you instructed the compiler to pack structs: GCC still
  7337. can add some padding after the last field.  So always use `sizeof struct foo'
  7338. to read and write a structure.
  7339.  
  7340. Another problem with porting programs that read structs from binary files is
  7341. that the size of some data types might be different under different
  7342. compilers.  Specifically, an `int' is 16-bit wide in most DOS-based
  7343. compilers, but in DJGPP it's 32-bit wide.
  7344.  
  7345. The best, most robust and portable way to read and write structs is through a
  7346. `char' buffer, which your code then uses to move the contents into or out of
  7347. the struct fields, one by one.  This way, you always know what you are doing
  7348. and your program will not break down if the padding rules change one day, or
  7349. if you port it to another OS/compiler.  The ANSI-standard `offsetof' macro
  7350. comes in handy in many such cases.
  7351.  
  7352. 
  7353. File: djgppfaq.info,  Node: Struct size-Footnotes,  Up: Struct size
  7354.  
  7355. (1)  Note that this still allows the struct to be padded at the end, though.
  7356.  
  7357. 
  7358. File: djgppfaq.info,  Node: Struct packing,  Next: Int 24h,  Prev: Struct size,  Up: Miscellany
  7359.  
  7360. 22.10 C++ doesn't pack structs!
  7361. ===============================
  7362.  
  7363. **Q*: When I use `struct ffblk' from the header `dir.h' in a C++ program, I
  7364. get garbage in some fields of the structure!*
  7365.  
  7366. *A* :  There is a known bug in GCC 2.7.2: the C++ compiler effectively
  7367. ignores the `__attribute__((packed))' directives, so the structures end up
  7368. being not packed.  DJGPP v2.01 comes with GCC 2.7.2.1 which corrected that
  7369. bug, so upgrade.  As a work-around, surround the declaration of the structure
  7370. that needs to be packed with `#pragma pack', like this:
  7371.  
  7372.        #ifdef __cplusplus
  7373.        #pragma pack(1)
  7374.        #endif
  7375.        .
  7376.        .
  7377.        .
  7378.        #ifdef __cplusplus
  7379.        #pragma pack()
  7380.        #endif
  7381.  
  7382. 
  7383. File: djgppfaq.info,  Node: Int 24h,  Next: go32-v2,  Prev: Struct packing,  Up: Miscellany
  7384.  
  7385. 22.11 How to avoid "Abort, Retry, Fail" messages
  7386. ================================================
  7387.  
  7388. **Q*: How do I write a program that accesses floppy and CD-ROM drives, but
  7389. avoids popping that "Abort, Retry, Fail?" message from DOS?*
  7390.  
  7391. **Q*: Other DOS compilers supply a function named `harderr' or `_harderr' to
  7392. hook the critical-error interrupt 24h, but DJGPP doesn't seem to have
  7393. these...*
  7394.  
  7395. *A* :  Under DPMI, Int 24h is always hooked by the DPMI server, since Int 24h
  7396. is issued by the real-mode DOS code, and it is not possible to terminate a
  7397. DPMI client (like DJGPP program) from real mode, if you press `A' in response
  7398. to that prompt.  The default handler under most DPMI servers will just set
  7399. `AL' register to 3 and do an `IRET', thus silently failing the DOS call that
  7400. triggered Int 24h.  The DJGPP startup code also hooks the protected-mode Int
  7401. 24h with a handler that fails the DOS call as described above.  So in most
  7402. circumstances you won't see that DOS prompt at all; your program will just
  7403. see a failed DOS call.
  7404.  
  7405. However, some DPMI hosts (notably, QDPMI), will sometimes crash your program
  7406. if it generates Int 24h, for instance when you access an empty floppy drive.
  7407. In such cases, or when the default action of failing the DOS call is not good
  7408. enough, you will have to hook Int 24h with your handler.  This should be done
  7409. in exactly the same manner as hooking hardware interrupts (*note how to set
  7410. an interrupt handler: Hardware interrupts.), because Int 24h is one of the
  7411. few software interrupts that, like all hardware interrupts, are always
  7412. reflected to the protected-mode handler first.  Note that `CWSDPMI' currently
  7413. doesn't support hooking Int 24h; if you set an interrupt handler, it won't be
  7414. called.
  7415.  
  7416. There are ways to avoid program crashes due to Int 24h (under those DPMI
  7417. hosts that exhibit this buggy behavior) other than to install a handler for
  7418. it.  For instance, you can test if the floppy drive is empty with a BIOS call
  7419. before accessing it with DOS functions; there are also similar ways to check
  7420. if a CD-ROM drive is empty.  The library function `getmntent' (*Note
  7421. getmntent: (libc.inf)getmntent.) can be used to detect all the drives that
  7422. can be safely accessed by DOS; or you can borrow some of the internal
  7423. functions used by `getmntent' from the library source distribution, e.g.
  7424. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/djlsr201.zip.
  7425.  
  7426. 
  7427. File: djgppfaq.info,  Node: go32-v2,  Next: DXE,  Prev: Int 24h,  Up: Miscellany
  7428.  
  7429. 22.12 What is that `go32-v2.exe' program?
  7430. =========================================
  7431.  
  7432. **Q*: What is go32-v2 for?*
  7433.  
  7434. *A* :  The `go32-v2' program does the following:
  7435.  
  7436.    * With no command-line arguments, it prints the available physical and
  7437.      virtual memory, much like `go32' did in v1.x.
  7438.  
  7439.    * It can run unstubified v2 COFF images, like this:
  7440.  
  7441.            go32-v2 myprog
  7442.  
  7443.    * If you rename it to `go32.exe' and put on your `PATH' before the v1.x
  7444.      `go32.exe', it can also run a v1 COFF images, by loading the v1.x `go32'
  7445.      and letting it do the job.  With this setup, you can run v2 programs
  7446.      from v1.x programs, because the v1.x program will load `go32-v2' (since
  7447.      it found it first on the PATH) which knows how to run v2 images, instead
  7448.      the original `go32' which cannot.
  7449.  
  7450. 
  7451. File: djgppfaq.info,  Node: DXE,  Next: LFN,  Prev: go32-v2,  Up: Miscellany
  7452.  
  7453. 22.13 What is DXE?
  7454. ==================
  7455.  
  7456. **Q*: What is DXE?*
  7457.  
  7458. **Q*: Can I make a DLL using the DXE support?*
  7459.  
  7460. **Q*: Where can I find information or examples about writing/loading the DXE
  7461. files?*
  7462.  
  7463. *A* :  DXE is a limited facility to dynamically load code which is rarely
  7464. needed in DJGPP.  An example is the floating-point emulator code (*note the
  7465. details of DJGPP FP emulator: Emulation.) which is only used on those few
  7466. machines that lack an FPU.  The DXE design is intentionally limited to keep
  7467. it as simple as possible, so that the code that loads a DXE could be small
  7468. (it's a few hundreds bytes).  Because of this, there are a number of
  7469. limitations in the DXE mechanism that prevent using it for full-fledged
  7470. dynamic linking (i.e., a DLL).  For instance, the DXE module cannot access
  7471. variables or functions in the main module.  Unloading a DXE is also not
  7472. supported (but I'm told you can add this by making afew simple changes in the
  7473. C library).
  7474.  
  7475. The only place you can find some docs and examples of writing and using a DXE
  7476. is in the file `djtst201.zip' in the DJGPP "tests" distribution, e.g.
  7477. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/djtst201.zip.  The example
  7478. there is *exceedingly* simplistic, but then so is the entire DXE mechanism...
  7479.  
  7480. 
  7481. File: djgppfaq.info,  Node: LFN,  Next: Missing separator,  Prev: DXE,  Up: Miscellany
  7482.  
  7483. 22.14 Long Filenames Don't Work!
  7484. ================================
  7485.  
  7486. **Q*: I cannot make Info find some of its files under Win95...*
  7487.  
  7488. **Q*: Why does Make behave as if some of the files were not there?*
  7489.  
  7490. *A* : Are you running DJGPP v2.0 on Win95 with long filename support enabled
  7491. (LFN=y in the environment)?  If so, set LFN=n from the DOS prompt and try
  7492. again.  If the problems go away, they are probably due to known bugs in some
  7493. v2.0 programs wrt the LFN support.  Make and Info which came with DJGPP v2.0
  7494. are two programs which are known to reveal these bugs.  Before you decide
  7495. that you are a victim of these bugs, though, make sure that all the files
  7496. that your programs need to access have been renamed to their long names.  For
  7497. example, if Make needs to find a file called `ALongFileName.cc' (because the
  7498. Makefile tells it to build `ALongFileName.o'), make sure there indeed is such
  7499. a file in the directory.  Sometimes people use archive tools (like `PKZIP')
  7500. that truncate long names, even on Win95, when they open an archive, which
  7501. leaves you with names like `alongfil.cc', which is not the same as the
  7502. original name when LFN is supported.  Be sure to use archivers that support
  7503. long filenames, e.g. use `DJTAR' when you open `.tar.gz' archives, or rename
  7504. all the files to their original long names after you open the archive.
  7505.  
  7506. If the problems persist even though the filenames are correct, upgrade to
  7507. DJGPP v2.01 or later, where all programs should support long filenames
  7508. properly.  If you cannot upgrade, you will have to disable LFN support (set
  7509. LFN=n from the DOS prompt, setting it in `DJGPP.ENV' does not always work in
  7510. DJGPP v2.0).
  7511.  
  7512. 
  7513. File: djgppfaq.info,  Node: Missing separator,  Next: Zoneinfo,  Prev: LFN,  Up: Miscellany
  7514.  
  7515. 22.15 Make says "missing separator"
  7516. ===================================
  7517.  
  7518. **Q*: When I invoke Make, it refuses to do anything and prints this cryptic
  7519. message:*
  7520.  
  7521.        makefile:10: *** missing separator.  Stop.
  7522.  
  7523. *Now what kind of excuse is that?*
  7524.  
  7525. *A* : Unlike most other DOS Make programs which accept any whitespace
  7526. character at the beginning of a command in a rule, GNU Make insists that
  7527. every such line begins with a TAB.  (Most other Unix Make programs also
  7528. require TABs.)  Make sure that the line whose number is printed in the error
  7529. message (in this case, line 10) begins with a TAB.
  7530.  
  7531. There are editors that replace TABs with spaces, so even a Makefile that used
  7532. to work can become unworkable if you edit them with such an editor.
  7533.  
  7534. Another, more rare, cause of the above error message is if you use static
  7535. pattern rules (with the `%' character) incorrectly.  Read the documentation
  7536. that comes with Make carefully and try to find the error.
  7537.  
  7538. 
  7539. File: djgppfaq.info,  Node: Zoneinfo,  Next: FAQ format,  Prev: Missing separator,  Up: Miscellany
  7540.  
  7541. 22.16 What is in that `zoneinfo' directory?
  7542. ===========================================
  7543.  
  7544. **Q*: When I installed DJGPP v2, it created a directory named `zoneinfo' with
  7545. a lot of small files that take up 3.5MB of my disk space.  What are they for?
  7546. Can I delete them?*
  7547.  
  7548. *A* :  These files exist so that time-related library functions can correctly
  7549. calculate the offset between the local time and the "UTC" (Universal
  7550. Coordinated Time).  This offset is required when you get files from another
  7551. time-zone, like from the Internet, or when you download an archive that was
  7552. compressed in another time-zone.  If you don't care about file time stamps
  7553. being incorrect in such cases, you can delete all those files and never look
  7554. back.
  7555.  
  7556. You might wonder why we need all these zoneinfo files when the UTC offset
  7557. *is* required.  Well, the simplest way to tell programs what the UTC offset
  7558. is, is to have the user specify a single number which is the offset; but then
  7559. this number needs to be changed twice a year, to accommodate for the daylight
  7560. saving time.  Another, not-quite-so-simple way is to have the user specify
  7561. the current UTC offset and the DST rules; but this is a tedious and
  7562. error-prone process, and many users get it wrong.  Both of these methods have
  7563. the drawback that if the rules change, programs misinterpret old time-stamps,
  7564. since they treat them according to new rules.  Using a table that is read from
  7565. a file and includes the offset calculation rules for every year avoids all
  7566. these problems and requires the user to point the `TZ' environment variable
  7567. to the file that is pertinent to his/her time zone, which is easy:
  7568.  
  7569.       set TZ=c:/djgpp/zoneinfo/israel
  7570.  
  7571. *or*
  7572.  
  7573.       set TZ=c:/djgpp/zoneinfo/us/alaska
  7574.  
  7575. To find the rule suitable for your location, look into the `src' subdirectory
  7576. of `zoneinfo' and browse the file whose name is your continent/part of the
  7577. world.  If no binary file exists with the name of your zone, you can create
  7578. one with using the time-zone compiler `zic', whose source is also in the
  7579. `src' subdirectory.
  7580.  
  7581. A public domain time-zone database exists, and is updated from time to time
  7582. with the latest world-wide changes to the offset calculation rules.  (The
  7583. rules change because politicians in different countries make laws that change
  7584. the local clock settings.)  The contents of the `zoneinfo' directory which
  7585. comes with DJGPP is based on this database, but if you want the latest rules,
  7586. you can download them from the net, e.g. ftp://elsie.nci.nih.gov/pub/ as
  7587. `tzdata*.tar.gz'; `tzcode*.tar.gz' in the same directory includes the
  7588. programs that can be used to generate the offset tables from their source in
  7589. `tzdata*.tar.gz', the latest implementations of POSIX library functions that
  7590. use time-zone information, and the man pages that document the rules and the
  7591. software.  The last update as of this writing was in May 1996.
  7592.  
  7593. On any single machine, you don't need more than a single file from that
  7594. directory, which is the file for your time zone; once you find that file, you
  7595. can safely delete the rest.  But if you distribute a program that uses the TZ
  7596. setting, you will have to include all of the files, or tell your users how to
  7597. get and install them.
  7598.  
  7599. 
  7600. File: djgppfaq.info,  Node: FAQ format,  Prev: Zoneinfo,  Up: Miscellany
  7601.  
  7602. 22.17 Generating the FAQ in your favorite format
  7603. ================================================
  7604.  
  7605. **Q*: How can I generate the FAQ list in a format I'm used to?*
  7606.  
  7607. *A* :  First, you need to get the FAQ sources.  The sources of the latest
  7608. version of this FAQ list can always be found as `faqNNNs.zip' on DJ Delorie's
  7609. server, e.g. ftp://ftp.delorie.com/pub/djgpp/v2faq/faq210s.zip and on
  7610. SimTel.NET mirrors, e.g.
  7611. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/faq210s.zip.  This includes
  7612. the source file (written in Texinfo), and all the auxiliary tools required to
  7613. produce the Info, plain-ASCII, HTML, and a few other versions of the FAQ
  7614. list; the FAQ in all these formats is available in a separate ZIP archive as
  7615. `faqNNNb.zip' from DJ Delorie's server, e.g.
  7616. ftp://ftp.delorie.com/pub/djgpp/v2faq/faq210b.zip or from SimTel.NET mirrors,
  7617. e.g. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2/faq210b.zip.  Currently,
  7618. this includes the Info version, the text (ASCII) version and an HTML version
  7619. as a single large `.html' file.  More formats will be available as the tools
  7620. for their generation are developed/tested.
  7621.  
  7622. If none of these formats is good enough for you, here are some tools
  7623. available to generate the FAQ list in other formats.  If you know about any
  7624. format not mentioned below that can be generated using widely available
  7625. tools, please drop me a note so I could update this list and consider that
  7626. format or those tools for inclusion in a future release of the FAQ.  If you
  7627. develop any such tools, consider uploading them to a site where they will be
  7628. publicly available, and tell me about that site.
  7629.  
  7630. Note that the FAQ source is a heavy user of the Texinfo macro facility, so
  7631. any conversion program that doesn't support Texinfo macros will probably have
  7632. hard time coping with the FAQ.  When confronted with this problem try feeding
  7633. the converter with the macro-expanded version of the FAQ (the Makefile in the
  7634. source distribution has a special target for such cases).
  7635.  
  7636. A program called `Makertf' can reportedly be used to convert a Texinfo
  7637. sources of this FAQ to the "Rich File Format" which can then either be
  7638. browsed by an RTF browser (such as Adobe Acrobat) or converted into a Windows
  7639. Help file with a Windows Help compiler.  `Makertf' is available from CCT
  7640. mirrors, e.g. ftp://ftp.coast.net/Coast/win3/winhelp/mkrtf104.zip.  The
  7641. Windows Help Compiler is available via anonymous ftp from the Microsoft ftp
  7642. site, e.g. ftp://ftp.microsoft.com/Softlib/MSFILES/HC305.EXE.
  7643.  
  7644. There also a program called `INFNG' that can be used to convert the Info
  7645. (*not* Texinfo) version of the FAQ to the Norton Guide format.  `INFNG' can
  7646. be downloaded from the DJGPP archive, e.g.
  7647. ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2misc/infng100.zip.
  7648.  
  7649. 
  7650. File: djgppfaq.info,  Node: About,  Next: Topic Index,  Prev: Miscellany,  Up: Top
  7651.  
  7652. 23. About this FAQ
  7653. ******************
  7654.  
  7655.   Maintainer: Eli Zaretskii <eliz@is.elta.co.il>.
  7656.  
  7657.   This FAQ is Copyright (C) 1994, 1995, 1996, 1997 by Eli Zaretskii
  7658. <eliz@is.elta.co.il>.  It may be freely redistributed with the DJGPP package
  7659. or any part thereof, provided that you don't prevent anybody else from
  7660. redistributing it on the same terms, and that this copyright notice is left
  7661. intact.
  7662.  
  7663.   Comments about, suggestions for, or corrections to this FAQ list are welcome.
  7664. Please make sure to include in your mail the version number of the document
  7665. to which your comments apply (you can find the version at the beginning of
  7666. this FAQ list).
  7667.  
  7668.   Much of the info in this FAQ list was taken from the DJGPP mailing list/news
  7669. group traffic, so many of you have (unbeknownst to you) contributed to this
  7670. list.  The following people read this list in its previous versions and
  7671. provided useful feedback, comments, information and/or suggestions:
  7672.  
  7673.      John M. Aldrich <fighteer@cs.com>
  7674.      Anthony Appleyard <A.APPLEYARD@fs2.mt.umist.ac.uk>
  7675.      John Bodfish <bodfish@austen.notis.com>
  7676.      Francois Charton <deef@pobox.oleane.com>
  7677.      Bill Currie <bill_currie@blackmagic.tait.co.nz>
  7678.      Bill Davidson <bdavidson@ra.isisnet.com>
  7679.      DJ Delorie <dj@delorie.com>
  7680.      Tom Demmer <Demmer@LStM.Ruhr-Uni-Bochum.De>
  7681.      Juergen Erhard <jae@laden.ilk.de>
  7682.      Jeremy Filliben <prime@UDel.Edu>
  7683.      James W. Haefner <Jim@anolis.bnr.usu.edu>
  7684.      Koen Van Herck <kvhk@barco.com>
  7685.      Robert Hoehne <Robert.Hoehne@Mathematik.TU-Chemnitz.DE>
  7686.      Gordon Hogenson <ghogenso@u.washington.edu>
  7687.      Harry Johnston <omega@es.co.nz>
  7688.      Martynas Kunigelis <martynas.kunigelis@vm.ktu.lt>
  7689.      Pieter Kunst <kunst@prl.philips.nl>
  7690.      Y. Lazarovitch <yitzg@haven.ios.com>
  7691.      Alexander Lehmann <lehmann@mathematik.th-darmstadt.de>
  7692.      Marty Leisner <leisner@sdsp.mc.xerox.com>
  7693.      Dave Love <d.love@dl.ac.uk>
  7694.      Rob Nader <naderr@topaz.cqu.edu.au>
  7695.      Eric Nicolas <nicolas@JUPITER.saclay.cea.fr>
  7696.      Elliott Oti <e.oti@stud.warande.ruu.nl>
  7697.      Esa A E Peuha <peuha@cc.helsinki.fi>
  7698.      Walter Prins <prins@quark.cs.sun.ac.za>
  7699.      Steve Salter <salters@admin.fanshawec.on.ca>
  7700.      Charles Sandmann <sandmann@clio.rice.edu>
  7701.      Terrel Shumway <Shumw001@Cerritos.edu>
  7702.      Andrew Szymkowiak <aes@solia.gsfc.nasa.gov>
  7703.      Launey Thomas <ljt@sierrasemi.com>
  7704.      Chris Tilbury <C.J.Tilbury@estate.warwick.ac.uk>
  7705.      Stephen Turnbull <turnbull@shako.sk.tsukuba.ac.jp>
  7706.      Santiago Vila <sanvila@pizarro.unex.es>
  7707.      Ronan Waide <waider@waider.ie>
  7708.      Morten Welinder <terra@diku.dk>
  7709.      Anthony Edward Wesley <awesley@galaxy.anutech.com.au>
  7710.      Mark H. Wood <mwood@mhw.OIT.IUPUI.EDU>
  7711.  
  7712. 
  7713. File: djgppfaq.info,  Node: Topic Index,  Next: Program Index,  Prev: About,  Up: Top
  7714.  
  7715. 24. Topic Index
  7716. ***************
  7717.  
  7718.   This is an alphabetical list of all the topics covered in this FAQ.  Use it
  7719. to search for a description of your problem and follow the link to find the
  7720. answer(s).
  7721.  
  7722. * Menu:
  7723.  
  7724. * !proxy method of passing long command lines: Long commands.
  7725. * "Far" declarations, porting to DJGPP:  NEAR and FAR.
  7726. * "Huge" declarations, porting to DJGPP: NEAR and FAR.
  7727. * "Near" declarations, porting to DJGPP: NEAR and FAR.
  7728. * -ansi switch and C++-style comments in C programs: C++ comments.
  7729. * -fconserve-space switch:               Large image.
  7730. * -fstrength-reduce optimization, disabled by default: Faster v1.
  7731. * -msoft-float switch to GCC:            -msoft-float.
  7732. * -traditional switch and C++-style comments in C programs: C++ comments.
  7733. * .lib libraries, using with GCC:        OBJ and LIB.
  7734. * .o files from EMXAOUT can't be put into a library: OBJ and LIB.
  7735. * .obj object files, using with GCC:     OBJ and LIB.
  7736. * 16-bit code, using with DJGPP:         16-bit code.
  7737. * 68K targets, cross-compiling with DJGPP: Cross-DJGPP.
  7738. * @ character, how to pass it to programs: Special chars.
  7739. * ^Z character at end of DJGPP.ENV:      Buggy DPMI.
  7740. * __crt0_glob_function, disable filename globbing: Disable globbing.
  7741. * __DJGPP__ pre-processor symbol:        DJGPP-specific.
  7742. * __dpmi_get_memory_information, doesn't change after free/malloc: Confusing alloc.
  7743. * __dpmi_get_protected_mode_interrupt_vector: Hardware interrupts.
  7744. * __dpmi_get_real_mode_interrupt_vector: Hardware interrupts.
  7745. * __dpmi_int, calling DOS/BIOS services: int86.
  7746. * __dpmi_int, high in program's profile: I/O bound programs.
  7747. * __dpmi_int, how to pass buffers:       Pointer segment.
  7748. * __dpmi_int, use to invoke software interrupts: Zero SP.
  7749. * __dpmi_simulate_real_mode_interrupt, need zero SS, SP and FLAGS: Zero SP.
  7750. * __dpmi_YYY vs _go32_XXX, which one to use: _go32 vs __dpmi.
  7751. * __GO32__ pre-processor symbol:         DJGPP-specific.
  7752. * __pure_virtual, unresolved function:   Pure virtual.
  7753. * __tb, an alias for the address of transfer buffer: Pointer segment.
  7754. * _AX variable, porting to DJGPP:        Pseudo-registers.
  7755. * _BP variable, porting to DJGPP:        Pseudo-registers.
  7756. * _BX variable, porting to DJGPP:        Pseudo-registers.
  7757. * _CX variable, porting to DJGPP:        Pseudo-registers.
  7758. * _DI variable, porting to DJGPP:        Pseudo-registers.
  7759. * _dos_ds, a selector to access conventional memory: Xfer.
  7760. * _DS variable, porting to DJGPP:        Pseudo-registers.
  7761. * _DX variable, porting to DJGPP:        Pseudo-registers.
  7762. * _ES variable, porting to DJGPP:        Pseudo-registers.
  7763. * _go32_dpmi_allocate_iret_wrapper:      Hardware interrupts.
  7764. * _go32_dpmi_chain_protected_mode_interrupt_vector: Hardware interrupts.
  7765. * _go32_remaining_physical_memory, doesn't change after free/malloc: Confusing alloc.
  7766. * _go32_XXX vs __dpmi_YYY, which one to use: _go32 vs __dpmi.
  7767. * _SI variable, porting to DJGPP:        Pseudo-registers.
  7768. * _stklen, setting stack size:           Stack size.
  7769. * Accessing absolute addresses above 1MB: Above 1MB.
  7770. * Accessing absolute addresses in conventional memory: Xfer.
  7771. * Accessing absolute addresses with dedicated selector: Xfer.
  7772. * Accessing C variables from inline assembly: Inline Asm.
  7773. * Accessing VBE 2.0 linear frame buffer: Direct access.
  7774. * Accessing video memory:                Direct access.
  7775. * Alignment of data by GAS can slow-down code: Pentium.
  7776. * Allegro library, failure to compile:   Allegro.
  7777. * Announcements, mailing list:           Subscribing.
  7778. * Archives, DJGPP mailing list/News group, how to search: Deja vu.
  7779. * argv[0] when program runs under a debugger: How to debug.
  7780. * Asking for help:                       Totally lost.
  7781. * Assembly source, code produced by Gas: Gas bugs.
  7782. * Assembly source, converting to AT&T syntax: Converting ASM.
  7783. * Assembly source, converting to protected mode: ASM GPF.
  7784. * Assembly source, GCC/Gas syntax:       Syntax.
  7785. * Assembly syntax:                       Syntax.
  7786. * AT&T vs Intel assembly syntax:         Syntax.
  7787. * atan, inaccuracies with FP emulator:   Emulator accuracy.
  7788. * Automated downloading from a PC:       DJGPP = Fatware.
  7789. * Automated downloading from a Unix box: DJGPP = Fatware.
  7790. * Automated FTP from a Unix box:         DJGPP = Fatware.
  7791. * Automatic variables, how much memory:  Stack size.
  7792. * Bad format, profiler error message:    Gprof needs COFF.
  7793. * Binary data I/O:                       File data corrupted.
  7794. * BIOS service calls:                    int86.
  7795. * BIOS service calls which need buffers: Pointer segment.
  7796. * BIOS setup, influence on compilation speed: Slow compiler.
  7797. * Breakpoints don't work in GDB under Windows: Debugging woes.
  7798. * Browsing documentation:                Where is the docs.
  7799. * Buffered I/O, effect of buffer size on I/O speed: I/O speed.
  7800. * Bug report, how to submit:             Changing.
  7801. * Bug-tracking system for DJGPP:         Changing.
  7802. * Bugs, how to browse a list of known DJGPP problems: Changing.
  7803. * C library, legal restrictions:         Redistribution.
  7804. * C programs compilation, recommended system RAM: Minimum.
  7805. * C++ class variables under GDB:         C++ classes in GDB.
  7806. * C++ debugging with stabs information:  C++ classes in GDB.
  7807. * C++ method names under GDB:            C++ classes in GDB.
  7808. * C++ programs compilation, recommended system RAM: Minimum.
  7809. * C++ programs, large executable:        Large image.
  7810. * C++ programs, problems with packed structs: Struct packing.
  7811. * C++ source, debugger cannot find:      GDB and C++ source.
  7812. * C++ STL library, not in lgp271b distribution: Unresolved externals.
  7813. * C++, missing header files:             Missing C++ headers.
  7814. * C++-style comments in C programs, GCC won't compile: C++ comments.
  7815. * Caldera OpenDOS, DPMI services crash DJGPP: Buggy DPMI.
  7816. * Calling 16-bit code from DJGPP:        16-bit code.
  7817. * calloc fails under EMM386 or HIMEM:    EMM386 alloc.
  7818. * calloc fails under QDPMI or Windows:   QDPMI alloc.
  7819. * calloc fails under Windows 3.x:        Windows alloc.
  7820. * calloc fails under Windows 95:         Win9x alloc.
  7821. * calloc, effect on "Fat DS":            Fat DS.
  7822. * Can't find node "Top", Info message:   Info can't find ``Top''.
  7823. * CCT mirrors' list:                     CCT.
  7824. * CD-ROM, getting DJGPP:                 DJGPP by WWW.
  7825. * Chaining interrupt:                    Hardware interrupts.
  7826. * Changing GNU/DJGPP programs:           Changing.
  7827. * Child processes, spawning under OS/2:  OS/2.
  7828. * Child programs, how much memory is left: Swap out.
  7829. * Class method name in GDB:              C++ classes in GDB.
  7830. * Class static variable name in GDB:     C++ classes in GDB.
  7831. * Code is slow due to incorrect alignment by GAS: Pentium.
  7832. * Code page change might prevent MSHELL from working: Debug graphics.
  7833. * Code quality, GCC:                     How fast.
  7834. * Code speed, slower in v2.x:            Faster v1.
  7835. * Code, DJGPP-specific:                  DJGPP-specific.
  7836. * COFF output from linker, how to get:   GDB needs COFF.
  7837. * COFF output, required for profiling:   Gprof needs COFF.
  7838. * Color text cannot be printed with `printf': Screen I/O.
  7839. * Command line, disabling filename expansion/globbing: Disable globbing.
  7840. * Command line, escaping special characters: Special chars.
  7841. * Command line, filename expansion/globbing: Filename globbing.
  7842. * Command lines, longer than 126 characters: Long commands.
  7843. * Command-line arguments:                Command line.
  7844. * Comments, C++-style in C programs:     C++ comments.
  7845. * Commercial programs, writing with DJGPP: Applications.
  7846. * Compatibility, hardware, general:      Requirements.
  7847. * Compatibility, Linux:                  Minimum.
  7848. * Compatibility, Novell NWDOS 7:         Minimum.
  7849. * Compatibility, operating systems, general: Requirements.
  7850. * Compatibility, OS/2:                   Minimum.
  7851. * Compatibility, Warp:                   Minimum.
  7852. * Compatibility, Windows 3.x:            Minimum.
  7853. * Compatibility, Windows 9x:             Minimum.
  7854. * Compatibility, Windows/NT:             Minimum.
  7855. * Compilation for debugging:             How to debug.
  7856. * Compilation messages, bogus:           Which language.
  7857. * Compilation progress, GCC switch:      GCC optimizations.
  7858. * Compilation speed:                     Slow compiler.
  7859. * Compile-time problems:                 Compiling.
  7860. * Compiler crashes, which subprogram of: General trouble.
  7861. * Compiler speed:                        Compiler performance.
  7862. * Compiling GCC and CPP:                 Reasonable hardware.
  7863. * Compiling GCC and CPP, RAM disk:       Config.
  7864. * Compiling large programs, disk cache settings: Reasonable hardware.
  7865. * Compiling large programs, RAM disk settings: Reasonable hardware.
  7866. * Compiling large source files:          Reasonable hardware.
  7867. * Compiling Objective C sources:         Objective C.
  7868. * Complex class is not in libgpp.a:      Class Complex.
  7869. * Complex class, porting to libgpp.a 2.7.1 and later: Class Complex.
  7870. * Complex template class:                Class Complex.
  7871. * Compressing DJGPP executables:         Large executable.
  7872. * Configuration, for optimal performance: Config.
  7873. * Configuration, reasonable:             Reasonable hardware.
  7874. * Configuration, the best:               Optimal hardware.
  7875. * Conventional memory, moving data to/from: Xfer.
  7876. * Conversion of the FAQ to different formats: FAQ format.
  7877. * Converting DOS .obj/.lib files to GCC: OBJ and LIB.
  7878. * Converting DOS code to DJGPP:          Converting.
  7879. * Coprocessor setup, change with _control87: Numeric exceptions.
  7880. * Copyleft, effect on DJGPP:             Applications.
  7881. * Copyright issues:                      Legalese.
  7882. * Crash traceback, how to read:          Crash traceback.
  7883. * Crash, DJGPP programs:                 Trouble.
  7884. * Crash, numeric exception:              Numeric exceptions.
  7885. * Crashes, general troubleshooting:      General trouble.
  7886. * Crashes, v2.0 programs:                v2.x crash.
  7887. * Critical error handling in DJGPP:      Int 24h.
  7888. * Cross-compiling with DJGPP:            Cross-DJGPP.
  7889. * crt0.o, GCC can't find:                Missing headers/libraries.
  7890. * Ctrl-C in debugged programs:           Debugging woes.
  7891. * Curses library for DJGPP:              Samples.
  7892. * Cygnus GCC port to Windows:            Windows/NT.
  7893. * Cygnus port of GCC for WinNT and Win95: Windows apps.
  7894. * DEADBEAF, use to spot uninitialized memory: v2.x crash.
  7895. * Debugger cannot find C++ source:       GDB and C++ source.
  7896. * Debugger causes programs to overflow the stack: Stack size.
  7897. * Debugger crashes on programs compiled for profiling: Debugging woes.
  7898. * Debugger crashes on programs which use exceptions: Debugging woes.
  7899. * Debugger crashes under QEMM/QDPMI:     Old QDPMI.
  7900. * Debugger doesn't know about #include'd source: Included source.
  7901. * Debugger doesn't pass signals to debuggee: Debugging woes.
  7902. * Debugger GP Faults on Windows 3.x:     Debugging woes.
  7903. * Debugger, usage:                       How to debug.
  7904. * Debuggers for DJGPP programs:          How to debug.
  7905. * Debuggers use transfer buffer:         Transfer buffer.
  7906. * Debugging C++ programs:                GDB and C++ source.
  7907. * Debugging C/C++ code generated by a program: Included source.
  7908. * Debugging graphics programs:           Debug graphics.
  7909. * Debugging issues:                      Debugging.
  7910. * Debugging symbols, how to strip from executables: Large executable.
  7911. * Debugging with GDB, needs COFF output: GDB needs COFF.
  7912. * Description of GNU style of mangling C++ names: C++ classes in GDB.
  7913. * Development environments for DJGPP:    Samples.
  7914. * Differences between SimTel and CCT ftp sites: Where to find.
  7915. * Direct hardware access on Win/NT:      Windows/NT.
  7916. * Disabling globbing in filenames:       Disable globbing.
  7917. * Disabling QDPMI:                       Old QDPMI.
  7918. * Disabling virtual memory for CWSDPMI:  Slow compiler.
  7919. * Disabling wildcard expansion:          Disable globbing.
  7920. * Disk cache, influence on compilation speed: Slow compiler.
  7921. * Disk cache, recommended settings:      Config.
  7922. * Disk cache, when compiling large programs: Reasonable hardware.
  7923. * Disk space, required for installation: Minimum.
  7924. * Disk space, using less of it:          DJGPP = Fatware.
  7925. * Distributing DJGPP programs:           Distributing.
  7926. * Distributing DJGPP programs, FP emulator: Emulation.
  7927. * DJGPP applications, legal restrictions: Applications.
  7928. * DJGPP archives, how to search:         Deja vu.
  7929. * DJGPP as cross-compiler:               Cross-DJGPP.
  7930. * DJGPP distribution, list of:           What to download.
  7931. * DJGPP Documentation:                   Docs.
  7932. * DJGPP documentation, in man page format: Man pages.
  7933. * DJGPP documentation, in PostScript format: Ready PS.
  7934. * DJGPP documentation, look in source distributions: Can't find docs.
  7935. * DJGPP documentation, printing:         Printed docs.
  7936. * DJGPP documentation, reading as ASCII file: No Info.
  7937. * DJGPP documentation, reading with a Web browser: Ready PS.
  7938. * DJGPP documentation, see source files: Last resort.
  7939. * DJGPP documentation, where to find it: Where is the docs.
  7940. * DJGPP environment variable, how to set and test: Missing headers/libraries.
  7941. * DJGPP environment variable, setting under LFN: Missing headers/libraries.
  7942. * DJGPP mailing list, duplicate messages: Duplicates.
  7943. * DJGPP mailing list, how to post:       Mailing list.
  7944. * DJGPP mailing list, how to subscribe:  Subscribing.
  7945. * DJGPP mailing list, how to unsubscribe: Unsubscribing.
  7946. * DJGPP mailing list, in digest form:    Subscribing.
  7947. * DJGPP mailing list, no messages:       Silent list.
  7948. * DJGPP mailing list/news group, read via WWW: Unsubscribing.
  7949. * DJGPP News group:                      Newsgroup.
  7950. * DJGPP News group, reading via WWW:     Subscribing.
  7951. * DJGPP programs, problems with:         Trouble.
  7952. * DJGPP programs, problems with DPMI host: Buggy DPMI.
  7953. * DJGPP programs, profiling:             How to profile.
  7954. * DJGPP software, where to upload:       Upload.
  7955. * DJGPP users, asking for help:          Totally lost.
  7956. * DJGPP utilities, legal restrictions:   Redistribution.
  7957. * DJGPP v2.x, alternative DPMI hosts:    Environment.
  7958. * DJGPP won't run, prints "No DPMI":     No DPMI.
  7959. * DJGPP, a list of packages:             What to download.
  7960. * DJGPP, downloading via e-mail:         DJGPP by WWW.
  7961. * DJGPP, downloading with FTP:           How to download.
  7962. * DJGPP, downloading with Gopher:        DJGPP by WWW.
  7963. * DJGPP, downloading with WWW:           DJGPP by WWW.
  7964. * DJGPP, how to get it:                  Getting DJGPP.
  7965. * DJGPP, sample code:                    Samples.
  7966. * DJGPP, what it is:                     DJGPP.
  7967. * DJGPP, where to download:              Where to find.
  7968. * DJGPP-ANNOUNCE mailing list:           Subscribing.
  7969. * DJGPP-compiled programs can't find DPMI: Distributing.
  7970. * DJGPP-specific code:                   DJGPP-specific.
  7971. * DJGPP.ENV syntax explained:            Missing headers/libraries.
  7972. * DJGPP.ENV, trailing junk crashes Info: Buggy DPMI.
  7973. * djgpp_first_ctor, unresolved by linker: djgpp_first_ctor.
  7974. * djgpp_first_dtor, unresolved by linker: djgpp_first_ctor.
  7975. * Documentation, converting to plain ASCII: No Info.
  7976. * Documentation, converting to PostScript format: Printed docs.
  7977. * Documentation, in man page format:     Man pages.
  7978. * Documentation, in PostScript format:   Ready PS.
  7979. * Documentation, inside source distribution archives: Can't find docs.
  7980. * Documentation, reading:                Where is the docs.
  7981. * Documentation, the profiler:           Gprof docs.
  7982. * DOS code, using with GCC:              16-bit code.
  7983. * DOS libraries, using with GCC:         OBJ and LIB.
  7984. * DOS object files, using with GCC:      OBJ and LIB.
  7985. * DOS programs, converting to DJGPP:     Converting.
  7986. * DOS service calls:                     int86.
  7987. * DOS service calls which need buffers:  Pointer segment.
  7988. * DOSEmu, incompatibilities with DJGPP:  DOSEmu.
  7989. * Downloading DJGPP via e-mail:          How to download.
  7990. * Downloading DJGPP with FTP:            How to download.
  7991. * Downloading DJGPP with WWW:            DJGPP by WWW.
  7992. * DPMI host bugs, might crash DJGPP programs: Buggy DPMI.
  7993. * DPMI hosts, commercially available:    Environment.
  7994. * DPMI services, problems with Novell NWDOS 7: Minimum.
  7995. * DPMI services, required to run DJGPP:  Minimum.
  7996. * DPMI spec, where to get it:            DPMI Spec.
  7997. * DPMI, required to run DJGPP programs:  Distributing.
  7998. * Duplicate messages from DJGPP mailing list: Duplicates.
  7999. * DXE can be debugged with EDEBUG32:     How to debug.
  8000. * DXE description:                       DXE.
  8001. * DXE docs and examples:                 DXE.
  8002. * Dynamically loaded code for DJGPP:     Samples.
  8003. * E-mail, downloading DJGPP:             DJGPP by WWW.
  8004. * Emulation, floating-point:             Floating point.
  8005. * Emulator library:                      Emulation.
  8006. * Emulator, floating-point inaccuracies: Emulator accuracy.
  8007. * Environment size affects spawning child programs: How long.
  8008. * Environment variables, DJGPP:          Optimal hardware.
  8009. * Environment variables, linker:         Libraries' order.
  8010. * Error messages, redirecting to a file: Redirect.
  8011. * Excessive paging, tuning CWSDPMI:      Config.
  8012. * EXE compressor for DJGPP:              Large executable.
  8013. * Executable size, how to make smaller:  Large executable.
  8014. * Executable, bloated by static array:   Large image.
  8015. * Executable, how to strip off debugging symbols: Large executable.
  8016. * FAQ, conversion to different formats:  FAQ format.
  8017. * Far pointer memory access:             Direct access.
  8018. * Farptr functions, mask off 12 higher bits of address: 20 bits.
  8019. * Fatal signal, GCC message:             Fatal signal.
  8020. * File format not recognized by GCC:     Which language.
  8021. * Filename globbing:                     Filename globbing.
  8022. * Filename globbing, disabling:          Disable globbing.
  8023. * Filename wildcards expansion:          Filename globbing.
  8024. * Filename wildcards, disabling expansion: Disable globbing.
  8025. * Files, minimum set to download:        What to download.
  8026. * Files, reading and writing:            File data corrupted.
  8027. * Files, required disk space:            Disk space.
  8028. * Floating-point emulation:              Floating point.
  8029. * Floating-point emulation doesn't work: Emulation.
  8030. * Floating-point emulation under debugger: Debugging woes.
  8031. * Floating-point emulation, -msoft-float switch: -msoft-float.
  8032. * Floating-point emulation, non-DJGPP emulators: Other emulators.
  8033. * Floating-point emulation, under OS/2:  OS/2 emulation.
  8034. * Floating-point exception in Objective-C program: SIGFPE with ObjC.
  8035. * Floating-point issues:                 Floating point.
  8036. * Floating-point math functions, standard and high-quality: Unresolved externals.
  8037. * Floating-point, debugger support:      How to debug.
  8038. * FP_SEG and FP_OFF, porting to DJGPP:   NEAR and FAR.
  8039. * free doesn't change virtual memory:    Confusing alloc.
  8040. * FTP, downloading DJGPP:                How to download.
  8041. * FTP, downloading DJGPP in batch mode:  DJGPP = Fatware.
  8042. * Functions from libm.a crash with SIGFPE: SIGFPE in ldexp.
  8043. * Functions, which is in what library:   Which library.
  8044. * Game programming, libraries and techniques for DJGPP: Samples.
  8045. * Garbage at end of number, GCC message: 0xfe+0x20.
  8046. * GCC aborts with "Installation problem, cannot exec as": Fatal signal.
  8047. * GCC aborts with "Internal compiler error": Fatal signal.
  8048. * GCC can't recognize file format:       Which language.
  8049. * GCC can't recognize source language:   Which language.
  8050. * GCC crashes, which subprogram of:      General trouble.
  8051. * GCC hangs/crashes under Make:          Make hangs.
  8052. * GCC says "Fatal signal X":             Fatal signal.
  8053. * Getting DJGPP <1>:                     Where to find.
  8054. * Getting DJGPP:                         Getting DJGPP.
  8055. * getting DJGPP from a CD-ROM:           DJGPP by WWW.
  8056. * Getting documentation:                 Where is the docs.
  8057. * Getting more help:                     Help.
  8058. * Globbing in filenames:                 Filename globbing.
  8059. * Globbing in filenames, disabling:      Disable globbing.
  8060. * GNU Copyleft, effect on DJGPP:         Applications.
  8061. * GNU development utilities, port to DJGPP: Samples.
  8062. * GNU News groups, don't post DJGPP problems: DJGPP isn't GNU.
  8063. * GNU packages, how to change:           Changing.
  8064. * Gopher, downloading DJGPP:             DJGPP by WWW.
  8065. * gotoxy doesn't work with `printf':     Screen I/O.
  8066. * GPL, effect on DJGPP:                  Applications.
  8067. * Graphics driver setup:                 Which driver.
  8068. * Graphics issues:                       Graphics.
  8069. * Graphics programs, debugging:          Debug graphics.
  8070. * Graphics screen messed up under Windows: GRX and Windows.
  8071. * Graphics, direct video access:         Direct access.
  8072. * Graphics, limitations on Win/NT:       Windows/NT.
  8073. * Gurus, asking for help:                Totally lost.
  8074. * Hang, all DJGPP programs:              Buggy DPMI.
  8075. * Hang, DJGPP programs:                  Trouble.
  8076. * harderr function, emulating under DJGPP: Int 24h.
  8077. * Hardware interrupt handler crashes:    HW Int pitfalls.
  8078. * Hardware interrupts, hooking:          Hardware interrupts.
  8079. * Hardware interrupts, subtleties:       HW Int pitfalls.
  8080. * Hardware requirements:                 Requirements.
  8081. * Hardware requirements, minimal:        Minimum.
  8082. * Hardware-oriented programming:         Low-level.
  8083. * Header files, C++, GCC can't find:     Missing C++ headers.
  8084. * Header files, GCC can't find:          Missing headers/libraries.
  8085. * Help, asking for:                      Totally lost.
  8086. * HTML format, DJGPP documentation:      Ready PS.
  8087. * I/O speed, DJGPP programs:             I/O speed.
  8088. * i286:                                  i286.
  8089. * i386SX:                                Minimum.
  8090. * Inaccuracies, using emulator:          Emulator accuracy.
  8091. * Including source code, problems with debugging: Included source.
  8092. * Incompatibilities, i286:               i286.
  8093. * Incompatibilities, Linux DOSEmu:       DOSEmu.
  8094. * Incompatibilities, OS/2:               OS/2.
  8095. * Incompatibilities, Warp:               OS/2.
  8096. * Incompatibilities, Windows/NT:         Windows/NT.
  8097. * Info won't display a file:             Info can't find ``Top''.
  8098. * Inline assembly, how to write:         Inline Asm.
  8099. * Inline functions, linker won't find:   Still unresolved.
  8100. * inp function:                          Ports.
  8101. * Int 24h crashes DJGPP programs:        Int 24h.
  8102. * int86 crashes program:                 int86.
  8103. * int86x/intdosx, how to pass a buffer:  Pointer segment.
  8104. * intdos crashes program:                int86.
  8105. * Intel vs AT&T assembly syntax:         Syntax.
  8106. * Intel-style assembly code, using with DJGPP: Converting ASM.
  8107. * Interactive programs, screen I/O:      Screen I/O.
  8108. * Internal compiler error, when compiling C++ programs: Fatal signal.
  8109. * Interrupt 24h handling:                Int 24h.
  8110. * Interrupt chaining:                    Hardware interrupts.
  8111. * Interrupt frequency, maximum:          HW Int pitfalls.
  8112. * Interrupt handlers, locking memory:    HW Int pitfalls.
  8113. * Interrupt reflection:                  Hardware interrupts.
  8114. * Interrupt reflection overhead:         HW Int pitfalls.
  8115. * Interrupts handlers in DJGPP:          Hardware interrupts.
  8116. * Invoking v2 programs from v1.x programs: go32-v2.
  8117. * Keyboard interrupt cannot be hooked under debugger: Debugging woes.
  8118. * Keystrokes don't get to keyboard handler: HW Int pitfalls.
  8119. * Known bugs in DJGPP, how to browse:    Changing.
  8120. * ldexp crashes programs with FP exception: SIGFPE in ldexp.
  8121. * Legal aspects of DJGPP programming:    Legalese.
  8122. * Legal restrictions on DJGPP apps:      Applications.
  8123. * Legal restrictions, DJGPP utilities:   Redistribution.
  8124. * Length of command line:                How long.
  8125. * Letter case in filenames submitted to GCC: Which language.
  8126. * LFN API, not supported on Win/NT:      Windows/NT.
  8127. * LFN problems:                          LFN.
  8128. * LGPL, effect on DJGPP:                 Applications.
  8129. * libc2.tex, missing file:               Printed docs.
  8130. * Libraries, converting to DJGPP:        Converting.
  8131. * Libraries, GCC can't find:             Missing headers/libraries.
  8132. * Libraries, optional, how to link:      Unresolved externals.
  8133. * Libraries, order on compilation/link command line: Libraries' order.
  8134. * Libraries, searching for functions:    Which library.
  8135. * Library docs, missing libc2.tex:       Printed docs.
  8136. * Library docs, problems in generating printed version: Printed docs.
  8137. * Library functions, C++, linker won't find: Still unresolved.
  8138. * Library functions, linker won't find:  Unresolved externals.
  8139. * Library functions, linker won't find in non-default directories: Libraries' order.
  8140. * Library functions, linker won't find, libraries' order: Libraries' order.
  8141. * Library, floating-point emulation:     Emulation.
  8142. * Linear address, mask off 12 higher bits: 20 bits.
  8143. * Linear frame buffer access:            Direct access.
  8144. * Link-time problems:                    Compiling.
  8145. * Linker fails because of Win95 shortcut files: Linker script.
  8146. * Linker fails for a.out files in a library: Large object files.
  8147. * Linker fails for large libraries or object files: Large object files.
  8148. * Linker fails for obj files converted by EMXAOUT: Large object files.
  8149. * Linker fails to find crt0.o under Novell: Missing headers/libraries.
  8150. * Linker fails to produce executable under Novell: No EXE.
  8151. * Linker speed:                          Compiler performance.
  8152. * linker won't find djgpp_first_dtor symbol: djgpp_first_ctor.
  8153. * Linking C++ programs, use the GXX driver: Unresolved externals.
  8154. * Linking programs, unresolved C++ library functions: Still unresolved.
  8155. * Linking programs, unresolved library functions: Unresolved externals.
  8156. * Linking programs, unresolved library functions, libraries' order: Libraries' order.
  8157. * Linking speed, improve by stub-editing ld.exe: Slow linker.
  8158. * Links, symbolic, simulation with DJGPP: Symlinks.
  8159. * Linux-to-DOS cross-compiling with DJGPP: Cross-DJGPP.
  8160. * List of DJGPP packages:                What to download.
  8161. * Locking memory for hardware interrupt handlers: Hardware interrupts.
  8162. * Locking memory for interrupt handlers: HW Int pitfalls.
  8163. * Long command lines:                    Long commands.
  8164. * Long command lines, from Makefile:     Makefiles.
  8165. * Long command lines, maximum length:    How long.
  8166. * long filename support, bugs:           LFN.
  8167. * Long Filenames aren't supported on Win/NT: Windows/NT.
  8168. * Long filenames in setting DJGPP env. variable: Missing headers/libraries.
  8169. * Low-level programming issues:          Low-level.
  8170. * Machines with low extended RAM, tuning CWSDPMI: Config.
  8171. * Makefile, first character of every command must be TAB: Missing separator.
  8172. * Makefile, passing long command lines:  Makefiles.
  8173. * Makefiles with long command lines:     Long commands.
  8174. * malloc doesn't change virtual memory:  Confusing alloc.
  8175. * malloc fails under EMM386 or HIMEM:    EMM386 alloc.
  8176. * malloc fails under QDPMI or Windows:   QDPMI alloc.
  8177. * malloc fails under Windows 3.x:        Windows alloc.
  8178. * malloc fails under Windows 95:         Win9x alloc.
  8179. * malloc, effect on "Fat DS":            Fat DS.
  8180. * Man pages, how to read:                Man pages.
  8181. * Math functions crash with SIGFPE:      SIGFPE in ldexp.
  8182. * Maximum interrupt frequency:           HW Int pitfalls.
  8183. * Maximum length of command line:        How long.
  8184. * Memory allocation fails under EMM386 or HIMEM: EMM386 alloc.
  8185. * Memory allocation fails under QDPMI or Windows 95: QDPMI alloc.
  8186. * Memory allocation fails under Windows 3.x: Windows alloc.
  8187. * Memory allocation fails under Windows 95: Win9x alloc.
  8188. * Memory at run time:                    Memory.
  8189. * Memory locking for hardware interrupt handlers: Hardware interrupts.
  8190. * Memory manager, settings for optimal performance: Config.
  8191. * Memory size reported by go32-v2:       Disk space.
  8192. * Memory, how much is left for spawned programs: Swap out.
  8193. * Memory, virtual, failure to allocate:  QDPMI VM.
  8194. * Memory, virtual, free doesn't change:  Confusing alloc.
  8195. * Memory, virtual, malloc doesn't change: Confusing alloc.
  8196. * Memory, virtual, maximum available:    How much memory.
  8197. * Memory, virtual, QDPMI failure:        QDPMI VM.
  8198. * Memory-mapped devices above 1MB:       Above 1MB.
  8199. * Memory-mapped devices, accessing with dedicated selector: Xfer.
  8200. * Memory-mapped devices, fast access:    Fat DS.
  8201. * Memory-mapped devices, moving data to/from: Xfer.
  8202. * Method name in C++, how to pass to GDB: C++ classes in GDB.
  8203. * Minimal hardware requirements:         Minimum.
  8204. * Minimum system RAM:                    Minimum.
  8205. * Minimum system RAM, CWSDPMI:           Minimum.
  8206. * Missing C++ header files:              Missing C++ headers.
  8207. * Missing crt0.o:                        Missing headers/libraries.
  8208. * Missing header files:                  Missing headers/libraries.
  8209. * Missing libraries:                     Missing headers/libraries.
  8210. * Missing separator, Make error message: Missing separator.
  8211. * Mixing v2.0 GCC with CC1PLUS from v1.x, Unknown filetype message.: Unknown filetype.
  8212. * Mixing v2.x Make with v1.x programs hangs the machine: Make hangs.
  8213. * MK_FP macro, porting to DJGPP:         NEAR and FAR.
  8214. * Mode switches, effect on program speed: How fast.
  8215. * Monochrome monitor, redirecting screen output: Debug graphics.
  8216. * More help, how to get:                 Help.
  8217. * Motorola 68K targets, cross-compiling with DJGPP: Cross-DJGPP.
  8218. * Mouse handler, how to install with DJGPP: RMCB.
  8219. * movedata, mask off 12 higher bits of address: 20 bits.
  8220. * Moving data to and from conventional memory: Xfer.
  8221. * Moving data to and from transfer buffer: Xfer.
  8222. * MS-Windows header file windows.h, where to get it: Windows apps.
  8223. * MS-Windows programming under DJGPP:    Windows apps.
  8224. * Nearptr functions:                     Fat DS.
  8225. * Nearptr functions, mask off 12 higher bits of address: 20 bits.
  8226. * nearptr method of direct memory access: Xfer.
  8227. * Nested programs, how much memory is left: Swap out.
  8228. * Network installation makes linking slow: Slow linker.
  8229. * New features in v2:                    New and improved.
  8230. * No DPMI error message:                 No DPMI.
  8231. * No free XMS memory when NOEMS parameter is used: Swap out.
  8232. * No messages from the mailing list:     Silent list.
  8233. * Non-DJGPP floating-point emulators:    Other emulators.
  8234. * Not COFF error message from DJGPP programs: Unknown filetype.
  8235. * Novell NDOS, buggy DPMI services crash DJGPP: Buggy DPMI.
  8236. * Novell, linker or STUBIFY don't produce executable: No EXE.
  8237. * Null pointer dereference crashes v2.0 programs: v2.x crash.
  8238. * Numeric exception, program crash:      Numeric exceptions.
  8239. * Objective C, compiling:                Objective C.
  8240. * Objective-C programs crash with FP exception: SIGFPE with ObjC.
  8241. * Old CWSDPMI, influence on compilation speed: Slow compiler.
  8242. * Optimal performance, CWSDPMI tuning:   Config.
  8243. * Optimal performance, disk cache settings: Config.
  8244. * Optimal performance, RAM disk settings: Config.
  8245. * Optimal performance, system configuration: Config.
  8246. * Optimization crashes GCC:              GCC optimizations.
  8247. * Optimizing DJGPP programs:             How to profile.
  8248. * outp function:                         Ports.
  8249. * Overhead, interrupt reflection to protected mode: HW Int pitfalls.
  8250. * Packages, DJGPP, list of:              What to download.
  8251. * Packages, ported to DJGPP:             Samples.
  8252. * Packages, required disk space:         Disk space.
  8253. * Packages, which to download:           What to download.
  8254. * Packed structs, C++ bug:               Struct packing.
  8255. * Packing the structs:                   Struct size.
  8256. * Page fault error message from CWSDPMI: v2.x crash.
  8257. * Paging starts before all RAM is used:  EMM386 alloc.
  8258. * Peek/poke absolute address:            Xfer.
  8259. * Pentium-optimized code:                Pentium.
  8260. * Performance issues:                    Performance.
  8261. * Peripheral devices above 1MB:          Above 1MB.
  8262. * Peripheral devices, fast access:       Fat DS.
  8263. * Peripheral devices, reading/writing ports: Ports.
  8264. * Peripherals, moving data to/from:      Xfer.
  8265. * Pi, accurate computation:              Emulator accuracy.
  8266. * Port reading/writing:                  Ports.
  8267. * Ported programs run much slower:       Slow-down.
  8268. * Posting problems, not to GNU News groups: DJGPP isn't GNU.
  8269. * Posting to DJGPP mailing list:         Mailing list.
  8270. * PostScript documentation:              Printed docs.
  8271. * PostScript documentation, ready-to-print: Ready PS.
  8272. * Pre-processor symbols, DJGPP-specific: DJGPP-specific.
  8273. * printf cannot print color text:        Screen I/O.
  8274. * Printing DJGPP documentation:          Printed docs.
  8275. * Problems with DJGPP programs:          Trouble.
  8276. * Problems, asking for help:             Totally lost.
  8277. * Problems, searching for solution in DJGPP archives: Deja vu.
  8278. * Profiled programs crash under debugger: Debugging woes.
  8279. * Profiler documentation:                Gprof docs.
  8280. * Profiler produces no output:           No profile.
  8281. * Profiling DJGPP programs:              How to profile.
  8282. * Profiling DJGPP programs, need COFF output: Gprof needs COFF.
  8283. * Profiling issues:                      Profiling.
  8284. * Profiling programs that terminate abnormally: No profile.
  8285. * Profiling, library routines:           I/O bound programs.
  8286. * Program crashes accessing empty floppy/CD-ROM drives: Int 24h.
  8287. * Program crashes because of Int 24h:    Int 24h.
  8288. * Program crashes in int86/intdos:       int86.
  8289. * Program crashes in v2.0, but not in v1.x: v2.x crash.
  8290. * Program crashes while allocating memory: QDPMI alloc.
  8291. * Programs crash when compiled for profiling: Profiled crash.
  8292. * Programs crash with SIGSEGV due to small stack size: Stack size.
  8293. * Programs crash, general troubleshooting: General trouble.
  8294. * Programs crash, numeric exception:     Numeric exceptions.
  8295. * Programs crash, saving debugging output: Redirect.
  8296. * Programs crash, searching DJGPP archives: Deja vu.
  8297. * Programs that exit abnormally, how to profile: No profile.
  8298. * Programs using nearptr fail on Windows/NT: Windows/NT.
  8299. * Protected mode and converted assembly code: ASM GPF.
  8300. * Protected-mode interrupt vector:       Hardware interrupts.
  8301. * Pseudo-register variables, porting to DJGPP: Pseudo-registers.
  8302. * QEMM auto/off mode, conflicts with DJGPP: QEMM AUTO.
  8303. * Quotes, how to pass them to programs:  Special chars.
  8304. * RAM disk, influence on compilation speed: Slow compiler.
  8305. * RAM disk, recommended settings:        Config.
  8306. * RAM disk, when compiling large programs: Reasonable hardware.
  8307. * RCS port to DJGPP:                     Samples.
  8308. * Read DJGPP traffic via WWW:            Unsubscribing.
  8309. * Reading an int from a binary file:     Struct size.
  8310. * Reading documentation:                 Where is the docs.
  8311. * Reading documentation with a Web browser: No Info.
  8312. * Reading documentation with text editor/viewer: No Info.
  8313. * Reading documentation, converting to plain ASCII: No Info.
  8314. * Reading structs from disk files:       Struct size.
  8315. * Real-mode call-back:                   RMCB.
  8316. * Real-mode interrupt vector:            Hardware interrupts.
  8317. * Real-mode services, calling DJGPP functions: RMCB.
  8318. * realloc, effect on "Fat DS":           Fat DS.
  8319. * Reboot, every DJGPP program:           Buggy DPMI.
  8320. * Reboot, when running DJGPP programs:   Trouble.
  8321. * Recommended system RAM, for C programs compilation: Minimum.
  8322. * Recommended system RAM, for C++ programs compilation: Minimum.
  8323. * Recompiling GCC:                       Changing.
  8324. * Redirecting GCC messages to a file:    Redirect.
  8325. * Redirection in Makefile, effect on long command lines: Makefiles.
  8326. * Redirection, using the REDIR program:  Makefiles.
  8327. * Required hardware, general:            Requirements.
  8328. * Response file, passing long command lines: Long commands.
  8329. * Run-time environment in v2.x:          Environment.
  8330. * Run-time performance:                  Performance.
  8331. * Run-time problems:                     Running.
  8332. * Runtime speed, slower in v2.x:         Faster v1.
  8333. * sbrk, effect on "Fat DS":              Fat DS.
  8334. * Screen contents not restored under Windows: GRX and Windows.
  8335. * Screen I/O:                            Screen I/O.
  8336. * Searching DJGPP archives:              Deja vu.
  8337. * setvbuf, effect on I/O speed:          I/O speed.
  8338. * SHELL= variable in Makefile, effect on long command lines: Makefiles.
  8339. * Shortcut files under Win95 fail DJGPP linker: Linker script.
  8340. * Signals in debugged programs:          Debugging woes.
  8341. * SimTel mirrors' list:                  Where to find.
  8342. * Single-stepping doesn't work in GDB on Windows 3.x: Debugging woes.
  8343. * Single-stepping doesn't work in RHIDE on Windows 3.x: Debugging woes.
  8344. * Size of a struct under DJGPP:          Struct size.
  8345. * Slow code, due to bad alignment by GAS: Pentium.
  8346. * Slow compilation:                      Slow compiler.
  8347. * Slow compilation, tuning CWSDPMI:      Config.
  8348. * Slow linking, possible reasons:        Slow linker.
  8349. * Slow-down, programs ported from other compilers: Slow-down.
  8350. * Software interrupts, need zero SS, SP and FLAGS: Zero SP.
  8351. * Solved problems, searching in DJGPP archives: Deja vu.
  8352. * Sound Blaster code for DJGPP:          Samples.
  8353. * Source files, using as the best docs:  Last resort.
  8354. * Source language is not recognized by GDB in C++ programs: C++ classes in GDB.
  8355. * Spawned programs, how much memory is left: Swap out.
  8356. * Spawning child processes, OS/2:        OS/2.
  8357. * Spawning child programs on Windows/NT and 95: Windows/NT.
  8358. * Spawning programs, effect of environment size: How long.
  8359. * Spawning v2 programs from v1.x programs: go32-v2.
  8360. * Spawning v2.x programs from v1.x programs doesn't work: Make hangs.
  8361. * Speed of compilation:                  Slow compiler.
  8362. * Stack dump, how to read:               Crash traceback.
  8363. * Stack overflow under debugger:         Stack size.
  8364. * Stack size under DJGPP:                Stack size.
  8365. * Stack size, insufficient, causes programs to crash: Stack size.
  8366. * Stand-alone DJGPP programs that don't need DPMI: Distributing.
  8367. * Standard output/error stream, redirecting to a file: Redirect.
  8368. * Static array enlarges C++ executable:  Large image.
  8369. * STL library, not in lgp271b distribution: Unresolved externals.
  8370. * struct reading from a disk file:       Struct size.
  8371. * Struct, size in bytes under DJGPP:     Struct size.
  8372. * Structure packing, C++ bug:            Struct packing.
  8373. * Structure padding:                     Struct size.
  8374. * Subscription to DJGPP mailing list:    Subscribing.
  8375. * Subsidiary programs, how much memory is left: Swap out.
  8376. * SVGA types supported by GRX:           Which driver.
  8377. * Symbolic links, simulation with DJGPP: Symlinks.
  8378. * System configuration, the best:        Optimal hardware.
  8379. * System RAM, minimum:                   Minimum.
  8380. * Systems programming issues:            Low-level.
  8381. * TAB, must be the first character of every command: Missing separator.
  8382. * TABs replaced with spaces by a text editor: Missing separator.
  8383. * TCP/IP library for DJGPP:              Samples.
  8384. * Text-mode video memory access:         Direct access.
  8385. * Timer interrupts code for DJGPP:       Samples.
  8386. * Traceback, how to read:                Crash traceback.
  8387. * Tracing compilation progress with -Q:  GCC optimizations.
  8388. * Transfer buffer, mask off 12 higher bits of address: 20 bits.
  8389. * Transfer buffer, moving data:          Xfer.
  8390. * Transfer buffer, use when debugging:   Transfer buffer.
  8391. * Transfer buffer, using to call DOS/BIOS: Pointer segment.
  8392. * Tuning CWSDPMI for optimal performance: Config.
  8393. * Turbo Vision, DJGPP port:              Samples.
  8394. * TZ database updates, where to get:     Zoneinfo.
  8395. * TZ variable, how to set:               Zoneinfo.
  8396. * Uninitialized memory crashes v2.0 programs: v2.x crash.
  8397. * Unix-like sbrk algorithm considered harmful for HW interrupts: HW Int pitfalls.
  8398. * Unix-to-DOS cross-compiling with DJGPP: Cross-DJGPP.
  8399. * Unknown filetype, GCC message:         Unknown filetype.
  8400. * Unresolved __pure_virtual function in C++: Pure virtual.
  8401. * Unresolved externals:                  Unresolved externals.
  8402. * Unresolved externals in C++ programs, use GXX: Unresolved externals.
  8403. * Unresolved externals, C++:             Still unresolved.
  8404. * unresolved externals, djgpp_first_ctor: djgpp_first_ctor.
  8405. * Unsubscribing from the DJGPP mailing list: Unsubscribing.
  8406. * Unsupported DOS request message:       int86.
  8407. * Unsupported INT message:               int86.
  8408. * Uploading DJGPP software:              Upload.
  8409. * v2 code slower than v1.x:              Faster v1.
  8410. * V2, new features and bug fixes:        v2.
  8411. * v2.0, program crashes:                 v2.x crash.
  8412. * v2.01 code slower than v2.0:           Faster v1.
  8413. * V2.x, new environment:                 Environment.
  8414. * V86 mode, QEMM and CWSDPMI problems:   QEMM AUTO.
  8415. * VBE 2.0 linear frame buffer access:    Direct access.
  8416. * VESA support by GRX:                   Which driver.
  8417. * VGA Mode-X graphics for DJGPP:         Samples.
  8418. * Video memory, direct access:           Direct access.
  8419. * Virtual memory:                        Memory.
  8420. * Virtual memory exhausted, during compilation: GCC optimizations.
  8421. * Virtual memory under Windows 95:       Win9x alloc.
  8422. * Virtual memory, failure to allocate:   QDPMI VM.
  8423. * Virtual memory, free doesn't change:   Confusing alloc.
  8424. * Virtual memory, how to disable it for CWSDPMI: Slow compiler.
  8425. * Virtual memory, malloc doesn't change: Confusing alloc.
  8426. * Virtual memory, maximum available:     How much memory.
  8427. * Virtual memory, QDPMI failure:         QDPMI VM.
  8428. * Virus infection cause "Not COFF" message: Unknown filetype.
  8429. * Watchpoints don't work in GDB under Windows: Debugging woes.
  8430. * Web site for DJGPP:                    WWW.
  8431. * Weekly digest, problems in receiving:  Subscribing.
  8432. * Wildcards expansion:                   Filename globbing.
  8433. * Wildcards expansion, disabling:        Disable globbing.
  8434. * Win32 programming with GCC:            Windows apps.
  8435. * Windows applications with DJGPP:       Windows apps.
  8436. * WinNT/Win95 programming with Cygnus GCC port: Windows apps.
  8437. * WWW services for DJGPP:                WWW.
  8438. * WWW, downloading DJGPP:                DJGPP by WWW.
  8439. * X emulation for DJGPP:                 Samples.
  8440. * Zoneinfo directory:                    Zoneinfo.
  8441.  
  8442. 
  8443. File: djgppfaq.info,  Node: Program Index,  Prev: Topic Index,  Up: Top
  8444.  
  8445. 25. Program Index
  8446. *****************
  8447.  
  8448.   This index lists the problems and solutions by the program/package to which
  8449. they pertain.  If you know what program or package gives you the trouble,
  8450. look it up here.
  8451.  
  8452. * Menu:
  8453.  
  8454. * 386Max, how to ensure virtual memory:  QDPMI VM.
  8455. * 386Max, speeding up DJGPP start-up:    QDPMI VM.
  8456. * 4DOS, redirecting GCC messages to a file: Redirect.
  8457. * _control87, change coprocessor setup:  Numeric exceptions.
  8458. * _crt0_startup_flags settings and QDPMI: QDPMI VM.
  8459. * _crt0_startup_flags, setting to lock memory: HW Int pitfalls.
  8460. * _crt0_startup_flags, Unix sbrk is incompatible with HW interrupts: HW Int pitfalls.
  8461. * _string.h, GCC can't find:             Missing C++ headers.
  8462. * AutoWinNet, automated downloading:     DJGPP = Fatware.
  8463. * BatchFTP, automated downloading from a Unix box: DJGPP = Fatware.
  8464. * BCCBGI (from BCC2GRX) crashes with the default stack: Stack size.
  8465. * Bison doesn't imply GPL/LGPL:          Applications.
  8466. * Bison, debugging generated code:       Included source.
  8467. * C compiler overflows its stack for large programs: Fatal signal.
  8468. * C++ class libraries, legal restrictions: Applications.
  8469. * C++ compiler crashes for large programs: Stack size.
  8470. * C++ compiler overflows its stack for large programs: Fatal signal.
  8471. * Cawf, using to read man pages:         Man pages.
  8472. * CC1PLUS crashes with SIGSEGV:          Stack size.
  8473. * CHCP DOS command might prevent MSHELL from working: Debug graphics.
  8474. * complex.h functions, linker can't find: Still unresolved.
  8475. * Complex.h, GCC can't find:             Missing C++ headers.
  8476. * CPP, compiling, memory requirements:   Reasonable hardware.
  8477. * CPP, compiling, RAM disk:              Config.
  8478. * CTRL87, control numeric exceptions:    Numeric exceptions.
  8479. * CWSDPMI allows "Fat DS":               Fat DS.
  8480. * CWSDPMI crashes programs allocating memory is small chunks: QDPMI alloc.
  8481. * CWSDPMI crashes programs which dereference NULL pointers: v2.x crash.
  8482. * CWSDPMI doesn't support hooking Int 24h: Int 24h.
  8483. * CWSDPMI runs out of virtual memory:    Fatal signal.
  8484. * CWSDPMI, alternative DPMI hosts:       Environment.
  8485. * CWSDPMI, disabling virtual memory:     Slow compiler.
  8486. * CWSDPMI, legal restrictions:           Redistribution.
  8487. * CWSDPMI, maximum available virtual memory: How much memory.
  8488. * CWSDPMI, memory usage for nested programs: Swap out.
  8489. * CWSDPMI, minimum required system RAM:  Minimum.
  8490. * CWSDPMI, old (beta) versions slow-down compilation: Slow compiler.
  8491. * CWSDPMI, pages too early under EMM386: EMM386 alloc.
  8492. * CWSDPMI, problems with QEMM auto/off mode: QEMM AUTO.
  8493. * CWSDPMI, setting parameters for optimal performance: Config.
  8494. * CWSDPMI, should be distributed with DJGPP programs: Distributing.
  8495. * CWSDPR0 reduces interrupt reflection overhead: HW Int pitfalls.
  8496. * CWSDPR0, use for testing HW interrupt handlers: Hardware interrupts.
  8497. * CWSPARAM, a program to tune CWSDPMI performance: Config.
  8498. * DJGPP.ENV syntax explained:            Missing headers/libraries.
  8499. * DJGPP.ENV, beware of blanks when setting: Missing headers/libraries.
  8500. * DJGPP.ENV, compiler environment variables: Missing headers/libraries.
  8501. * DJGPP.ENV, linker environment variables: Libraries' order.
  8502. * DJP compressor supports DLM:           Large executable.
  8503. * DJP, an executable compressor for DJGPP: Large executable.
  8504. * DLM compression, with DJP:             Large executable.
  8505. * DLM, a facility to load code at run time: Samples.
  8506. * DOSEMU doesn't allow "Fat DS":         Fat DS.
  8507. * EDEBUG32 can debug a DXE:              How to debug.
  8508. * EMACS can be compiled with DJGPP:      Samples.
  8509. * Emacs, reading docs:                   Where is the docs.
  8510. * Emacs, reading Info files:             Where is the docs.
  8511. * Emacs, using to read man pages:        Man pages.
  8512. * EMM386, cannot use all free memory:    EMM386 alloc.
  8513. * EMM386, effect on max interrupt frequency: HW Int pitfalls.
  8514. * EMM386, malloc/calloc fails:           EMM386 alloc.
  8515. * EMM386, settings for optimal performance: Config.
  8516. * emTeX, printing the docs:              Printed docs.
  8517. * emu387.dxe, distribution with DJGPP programs: Emulation.
  8518. * EMX/GCC, writing Windows applications: Windows apps.
  8519. * EMXAOUT converter from .obj to COFF format: OBJ and LIB.
  8520. * EMXAOUT output can't be put into a library: OBJ and LIB.
  8521. * EMXAOUT produces a.out format:         OBJ and LIB.
  8522. * F2C, debugging generated code:         Included source.
  8523. * Flex doesn't imply GPL/LGPL:           Applications.
  8524. * Flex, debugging generated code:        Included source.
  8525. * FSDB crashes under QEMM/QDPMI:         Old QDPMI.
  8526. * FSDB, the full-screen debugger:        How to debug.
  8527. * Gas can introduce errors into assembly code: Gas bugs.
  8528. * GCC can't find C++ headers:            Missing C++ headers.
  8529. * GCC can't find crt0.o:                 Missing headers/libraries.
  8530. * GCC can't find headers:                Missing headers/libraries.
  8531. * GCC can't find libraries:              Missing headers/libraries.
  8532. * GCC cannot resolve djgpp_first_ctor symbol when linking: djgpp_first_ctor.
  8533. * GCC crashes during optimization:       GCC optimizations.
  8534. * GCC crashes, which subprogram of:      General trouble.
  8535. * GCC doesn't pack structs in C++ programs: Struct packing.
  8536. * GCC doesn't recognize .lib libraries:  OBJ and LIB.
  8537. * GCC doesn't recognize .obj object files: OBJ and LIB.
  8538. * GCC doesn't recognize file format:     Which language.
  8539. * GCC exhausts virtual memory:           GCC optimizations.
  8540. * GCC from v2.x crashes under v1.x Make: Make hangs.
  8541. * GCC hangs under Make:                  Make hangs.
  8542. * GCC says "garbage at end of number":   0xfe+0x20.
  8543. * GCC won't compile C++-style comments in C programs: C++ comments.
  8544. * GCC won't find inline functions without -O: Still unresolved.
  8545. * GCC, -fconserve-space switch:          Large image.
  8546. * GCC, -msoft-float switch:              -msoft-float.
  8547. * GCC, -v switch shows the compilation passes: Which language.
  8548. * GCC, assumes C++ source is .cc:        GDB and C++ source.
  8549. * GCC, code efficiency:                  How fast.
  8550. * GCC, compiling for debugging:          How to debug.
  8551. * GCC, compiling, memory requirements:   Reasonable hardware.
  8552. * GCC, compiling, RAM disk:              Config.
  8553. * GCC, environment variables:            Missing headers/libraries.
  8554. * GCC, file source language recognition: Which language.
  8555. * GCC, I/O speed:                        I/O speed.
  8556. * GCC, inline assembly facilities:       Inline Asm.
  8557. * GCC, maximum length of command line in Makefiles: How long.
  8558. * GCC, passing long command lines via Makefile: Makefiles.
  8559. * GCC, recompiling:                      Changing.
  8560. * GCC, redirecting messages to a file:   Redirect.
  8561. * GCC, slow compilation:                 Slow compiler.
  8562. * GDB cannot restart the debuggee:       How to debug.
  8563. * GDB causes stack overflow in a debuggee: Stack size.
  8564. * GDB crashes under QEMM/QDPMI:          Old QDPMI.
  8565. * GDB doesn't pass command-line arguments to debuggee: How to debug.
  8566. * GDB doesn't recognize source language: C++ classes in GDB.
  8567. * GDB GP Faults on breakpoint/watchpoint under Windows: Debugging woes.
  8568. * GDB needs COFF output:                 GDB needs COFF.
  8569. * GDB, conflicts with file redirection:  How to debug.
  8570. * GDB, debugging DJGPP programs:         How to debug.
  8571. * GDB, debugging graphics programs:      Debug graphics.
  8572. * GDB, how is it different on MS-DOS:    How to debug.
  8573. * GDB, how to use C++ class variables' names: C++ classes in GDB.
  8574. * GDB, how to use C++ method names:      C++ classes in GDB.
  8575. * GDB, init file name:                   How to debug.
  8576. * GDB, name of the READLINE init file:   How to debug.
  8577. * GDB, slow loading of symbols and sources: How to debug.
  8578. * go32-v2 reports the amount of memory and swap space: Disk space.
  8579. * go32-v2 usage:                         go32-v2.
  8580. * go32-v2, use to find out how much memory is available to DJGPP: EMM386 alloc.
  8581. * Gprof cannot find program:             Gprof needs COFF.
  8582. * Gprof documentation:                   Gprof docs.
  8583. * gprof produces no output:              No profile.
  8584. * Gprof says "bad format":               Gprof needs COFF.
  8585. * Gprof, documentation:                  Can't find docs.
  8586. * Gprof, the GNU profiler:               How to profile.
  8587. * Groff, port to DJGPP:                  Man pages.
  8588. * Groff, using to read man pages:        Man pages.
  8589. * GRX, supported SVGA types:             Which driver.
  8590. * gxx driver, not in gcc272b distribution: Unresolved externals.
  8591. * gxx driver, searches C++ libraries automatically: Unresolved externals.
  8592. * HIMEM, malloc/calloc fails:            EMM386 alloc.
  8593. * INFNG, produces the FAQ in Norton Guides format: FAQ format.
  8594. * Info crashes due to ^Z or whitespace at end of DJGPP.ENV: Buggy DPMI.
  8595. * Info crashes under QDPMI:              Buggy DPMI.
  8596. * Info won't display a file:             Info can't find ``Top''.
  8597. * Info, a stand-alone docs browser:      Where is the docs.
  8598. * Info, using to read man pages:         Man pages.
  8599. * iostream functions, linker can't find: Still unresolved.
  8600. * iostream library, why use it:          Unresolved externals.
  8601. * iostream.h, GCC can't find:            Missing C++ headers.
  8602. * LaTeX, printing the docs:              Printed docs.
  8603. * ld fails for a.out files in a library: Large object files.
  8604. * ld fails for large libraries and object files: Large object files.
  8605. * ld fails for obj files converted by EMXAOUT: Large object files.
  8606. * LD linker, linker script defines djgpp_first_ctor: djgpp_first_ctor.
  8607. * ld, how to improve linking speed:      Slow linker.
  8608. * Less, using to read man pages:         Man pages.
  8609. * Lex, debugging generated code:         Included source.
  8610. * libemu.a FP emulation library:         Emulation.
  8611. * libg++ library:                        Unresolved externals.
  8612. * libgpp library:                        Unresolved externals.
  8613. * libgpp.a, legal restrictions:          Applications.
  8614. * libiostream.a, legal restrictions:     Applications.
  8615. * libstdc++ standard templates library:  Unresolved externals.
  8616. * Linker can't find library functions:   Unresolved externals.
  8617. * Linker can't find library functions in non-default directories: Libraries' order.
  8618. * Linker can't find some C++ library functions: Still unresolved.
  8619. * Linker, environment variables:         Libraries' order.
  8620. * Linker, how to get COFF output:        GDB needs COFF.
  8621. * Linker, order of libraries in the command line: Libraries' order.
  8622. * Linking against optional libraries:    Unresolved externals.
  8623. * Linux doesn't allow "Fat DS":          Fat DS.
  8624. * Linux, compatibility:                  Minimum.
  8625. * Linux, needs a patch to run nested programs: DOSEmu.
  8626. * Make crashes on DOSEmu:                DOSEmu.
  8627. * Make crashes on OS/2:                  OS/2.
  8628. * Make error message "missing separator": Missing separator.
  8629. * Make requires floating point:          Changing.
  8630. * Make, GCC hangs when invoked from it:  Make hangs.
  8631. * Make, maximum length of command line to pass to GCC: How long.
  8632. * Make, passing long command lines via Makefile: Makefiles.
  8633. * Makeinfo, using to convert Info files to plain ASCII: No Info.
  8634. * MAKERTF, produces the FAQ in RTF format: FAQ format.
  8635. * Man program for DJGPP docs:            Man pages.
  8636. * math library, default ANSI/ISO and high-quality functions: Unresolved externals.
  8637. * More, using to read man pages:         Man pages.
  8638. * Mosaic, downloading DJGPP:             DJGPP by WWW.
  8639. * MSHELL fails because of TSR programs:  Debug graphics.
  8640. * MSHELL, redirecting screen output:     Debug graphics.
  8641. * NASM, a portable assembler with Intel syntax support: Converting ASM.
  8642. * NDOS, buggy DPMI services crash DJGPP: Buggy DPMI.
  8643. * Netscape, downloading DJGPP:           DJGPP by WWW.
  8644. * NM, printing library contents:         Which library.
  8645. * Novell 3.x, linker doesn't find crt0.o: Missing headers/libraries.
  8646. * Novell NWDOS 7, buggy DPMI services:   Minimum.
  8647. * Novell NWDOS 7, compatibility:         Minimum.
  8648. * NWDOS, buggy DPMI services crash DJGPP: Buggy DPMI.
  8649. * OBJ2COFF converter from .obj to COFF format: OBJ and LIB.
  8650. * OBJ2COFF, commercial use is prohibited: OBJ and LIB.
  8651. * OBJDUMP segment overrides bugs:        Gas bugs.
  8652. * Objective C, compilation problems:     Objective C.
  8653. * Objective-C, cannot run on machines without FPU: SIGFPE with ObjC.
  8654. * obstack package:                       Unresolved externals.
  8655. * OpenDOS, bug in DPMI services crash DJGPP: Buggy DPMI.
  8656. * OS/2 Warp allows "Fat DS":             Fat DS.
  8657. * OS/2, compatibility:                   Minimum.
  8658. * OS/2, floating point emulation:        OS/2 emulation.
  8659. * OS/2, incompatibilities:               OS/2.
  8660. * PMODE/DJ reduces interrupt reflection overhead: HW Int pitfalls.
  8661. * PMODE/DJ, can be used to produce stand-alone programs: Distributing.
  8662. * POVRAY, linker fails to link the library: Large object files.
  8663. * Q87, an emulator compatible with DJGPP: Other emulators.
  8664. * QDPMI allows "Fat DS":                 Fat DS.
  8665. * QDPMI and _crt0_startup_flags settings: QDPMI VM.
  8666. * QDPMI crashes debugger:                Old QDPMI.
  8667. * QDPMI crashes DJGPP programs when they cause Int 24h: Int 24h.
  8668. * QDPMI crashes Info:                    Buggy DPMI.
  8669. * QDPMI fails to provide virtual memory: QDPMI VM.
  8670. * QDPMI, how to disable:                 Old QDPMI.
  8671. * QDPMI, malloc/calloc failure:          QDPMI alloc.
  8672. * QDPMI, memory usage for nested programs: Swap out.
  8673. * QEMM crashes debugger:                 Old QDPMI.
  8674. * QEMM, auto/off mode, conflicts with CWSDPMI: QEMM AUTO.
  8675. * QEMM386, settings for optimal performance: Config.
  8676. * RCS port to DJGPP:                     Samples.
  8677. * REDIR, redirecting GCC messages to a file: Redirect.
  8678. * REDIR, redirecting stack dump to a file: Crash traceback.
  8679. * REDIR, use to get redirection and long command lines: Makefiles.
  8680. * regex package from GNU:                Unresolved externals.
  8681. * Regex.h, GCC can't find:               Missing C++ headers.
  8682. * RHIDE debugger GP Faults on breakpoints under Windows: Debugging woes.
  8683. * RHIDE, development environment for DJGPP: Samples.
  8684. * RHIDE, includes an integrated debugger: How to debug.
  8685. * RSX extender:                          Windows apps.
  8686. * RSXNT toolkit for developing Win32 applications: Windows apps.
  8687. * RSXNTDJ causes linker to fail:         Linker script.
  8688. * RSXWDK2 Windows development kit:       Windows apps.
  8689. * sbrk algorithm and QDPMI:              QDPMI VM.
  8690. * sbrk, Unix-like algorithm is incompatible with HW interrupts: HW Int pitfalls.
  8691. * SCRIPT, redirecting GCC messages to a file: Redirect.
  8692. * Sed requires floating point:           Changing.
  8693. * Sed script to convert ASM to AT&T syntax: Converting ASM.
  8694. * Sed, documentation:                    Can't find docs.
  8695. * sizeof, result when called on a structure: Struct size.
  8696. * stdiostream.h, GCC can't find:         Missing C++ headers.
  8697. * streambuf.h, GCC can't find:           Missing C++ headers.
  8698. * STRIP makes executables smaller:       Large executable.
  8699. * STUBEDIT, changing stack size:         Stack size.
  8700. * STUBEDIT, effect on memory left to spawned programs: Swap out.
  8701. * STUBIFY fails to produce .EXE under Novell: No EXE.
  8702. * STUBIFY.EXE, infected by a virus:      Unknown filetype.
  8703. * SYMIFY, a program to read crash traceback: Crash traceback.
  8704. * TA2AS, a converter from Intel to AT&T assembly syntax: Converting ASM.
  8705. * TeX, printing the docs:                Printed docs.
  8706. * TEXI2PS, converting docs to crude PostScript: Printed docs.
  8707. * UNIVBE, software VESA 2.0 emulation:   Which driver.
  8708. * Warp, compatibility:                   Minimum.
  8709. * Warp, incompatibilities:               OS/2.
  8710. * Win/NT doesn't allow "Fat DS":         Fat DS.
  8711. * Win/NT doesn't allow port I/O:         Windows/NT.
  8712. * Win95 long filenames and C++ headers:  Missing C++ headers.
  8713. * Win95, setting DJGPP environment variable: Missing headers/libraries.
  8714. * Windows 3.x allows "Fat DS":           Fat DS.
  8715. * Windows 3.x, compatibility:            Minimum.
  8716. * Windows 3.x, malloc/calloc fails:      Windows alloc.
  8717. * Windows 95 doesn't allow more than 16MB virtual memory: Win9x alloc.
  8718. * Windows 95 DPMI server loses selectors calling spawnXX: Windows/NT.
  8719. * Windows 95, shortcut files conflict with ld: Linker script.
  8720. * Windows 9x allows "Fat DS":            Fat DS.
  8721. * Windows 9x, compatibility:             Minimum.
  8722. * Windows applications, writing with EMX/GCC: Windows apps.
  8723. * Windows messes up graphics screen:     GRX and Windows.
  8724. * Windows, malloc/calloc failure:        QDPMI alloc.
  8725. * Windows, memory usage for nested programs: Swap out.
  8726. * Windows, setting memory parameters for DJGPP: Config.
  8727. * Windows, stack size control:           Stack size.
  8728. * windows.h header file, where to get it: Windows apps.
  8729. * Windows/NT DPMI server loses selectors calling spawnXX: Windows/NT.
  8730. * Windows/NT, compatibility:             Minimum.
  8731. * WinNT, setting DJGPP environment variable: Missing headers/libraries.
  8732. * WMEMU causes undefined references when linking: Emulation.
  8733. * WMEMU, an alternative floating-point emulator: Emulation.
  8734. * WMEMU, use when debugging FP programs on non-FPU machine: Debugging woes.
  8735. * Yacc, debugging generated code:        Included source.
  8736.  
  8737.  
  8738.  
  8739.  
  8740. 
  8741. Tag Table:
  8742. Node: Top533
  8743. Node: Urgent4395
  8744. Node: DJGPP6423
  8745. Node: Requirements7659
  8746. Node: Minimum8505
  8747. Node: OS/210216
  8748. Node: Windows/NT11459
  8749. Node: DOSEmu15633
  8750. Node: i28617277
  8751. Node: Windows apps17712
  8752. Node: Optimal hardware22643
  8753. Node: Reasonable hardware23667
  8754. Node: Config24697
  8755. Node: Getting DJGPP30087
  8756. Node: Where to find30828
  8757. Node: Where to find-Footnotes38927
  8758. Node: CCT39207
  8759. Node: How to download42887
  8760. Node: DJGPP by WWW43528
  8761. Node: What to download44982
  8762. Node: What to download-Footnotes53860
  8763. Node: Disk space54122
  8764. Node: DJGPP = Fatware56435
  8765. Node: Docs58355
  8766. Node: Where is the docs59087
  8767. Node: No Info60299
  8768. Node: Printed docs62292
  8769. Node: Ready PS64349
  8770. Node: Can't find docs65816
  8771. Node: Man pages66241
  8772. Node: Last resort69733
  8773. Node: Trouble70372
  8774. Node: No DPMI71753
  8775. Node: Buggy DPMI72309
  8776. Node: GCC optimizations74505
  8777. Node: Fatal signal77988
  8778. Node: Unknown filetype80995
  8779. Node: QEMM AUTO82096
  8780. Node: Make hangs83500
  8781. Node: Info can't find "Top"85303
  8782. Node: General trouble86719
  8783. Node: Redirect87878
  8784. Node: Deja vu89944
  8785. Node: Totally lost91007
  8786. Node: Compiler performance93219
  8787. Node: Slow compiler93922
  8788. Node: Slow linker98436
  8789. Node: Compiling100861
  8790. Node: Missing headers/libraries102800
  8791. Node: Missing C++ headers109217
  8792. Node: C++ comments112731
  8793. Node: Which language115262
  8794. Node: Objective C117353
  8795. Node: DJGPP-specific118053
  8796. Node: Unresolved externals119235
  8797. Node: Which library120976
  8798. Node: Libraries' order123272
  8799. Node: Still unresolved125076
  8800. Node: Class Complex125662
  8801. Node: Pure virtual127465
  8802. Node: djgpp_first_ctor128595
  8803. Node: Large image129978
  8804. Node: Large executable131039
  8805. Node: Linker script134195
  8806. Node: No EXE135878
  8807. Node: Large object files137796
  8808. Node: Allegro139541
  8809. Node: Running140327
  8810. Node: v2.x crash140961
  8811. Node: Crash traceback143435
  8812. Node: File data corrupted146141
  8813. Node: Screen I/O147353
  8814. Node: Distributing149451
  8815. Node: Graphics151082
  8816. Node: Which driver151704
  8817. Node: Direct access153024
  8818. Node: GRX and Windows154746
  8819. Node: Floating point155950
  8820. Node: Emulation156697
  8821. Node: Other emulators159086
  8822. Node: OS/2 emulation159896
  8823. Node: -msoft-float160445
  8824. Node: Numeric exceptions161064
  8825. Node: Emulator accuracy161968
  8826. Node: SIGFPE with ObjC162939
  8827. Node: SIGFPE in ldexp163807
  8828. Node: Debugging164676
  8829. Node: How to debug165581
  8830. Node: Old QDPMI170711
  8831. Node: GDB needs COFF171428
  8832. Node: Transfer buffer172476
  8833. Node: Debug graphics173491
  8834. Node: GDB and C++ source175383
  8835. Node: C++ classes in GDB176348
  8836. Node: Included source178493
  8837. Node: Debugging woes179622
  8838. Node: Profiling183037
  8839. Node: How to profile183700
  8840. Node: Profiled crash184352
  8841. Node: Gprof needs COFF185045
  8842. Node: Gprof docs185807
  8843. Node: I/O bound programs186328
  8844. Node: No profile187021
  8845. Node: No profile-Footnotes188783
  8846. Node: Performance189034
  8847. Node: How fast189623
  8848. Node: Faster v1190502
  8849. Node: Pentium193078
  8850. Node: I/O speed194451
  8851. Node: Slow-down196356
  8852. Node: Memory198377
  8853. Node: How much memory199197
  8854. Node: Confusing alloc200471
  8855. Node: QDPMI VM201572
  8856. Node: QDPMI alloc203442
  8857. Node: Windows alloc205344
  8858. Node: Win9x alloc206199
  8859. Node: EMM386 alloc207163
  8860. Node: Swap out208324
  8861. Node: Stack size210764
  8862. Node: Command line215046
  8863. Node: Filename globbing215884
  8864. Node: Disable globbing218185
  8865. Node: Special chars218968
  8866. Node: Long commands220801
  8867. Node: Long commands-Footnotes223503
  8868. Node: How long223811
  8869. Node: Makefiles225335
  8870. Node: Converting227105
  8871. Node: Syntax227879
  8872. Node: Gas bugs231663
  8873. Node: Converting ASM233089
  8874. Node: Converting ASM-Footnotes235879
  8875. Node: ASM GPF236106
  8876. Node: OBJ and LIB237529
  8877. Node: OBJ and LIB-Footnotes240795
  8878. Node: 16-bit code240998
  8879. Node: NEAR and FAR242342
  8880. Node: Pseudo-registers244874
  8881. Node: Pseudo-registers-Footnotes246624
  8882. Node: Low-level246942
  8883. Node: int86248149
  8884. Node: Pointer segment249729
  8885. Node: Zero SP252364
  8886. Node: Zero SP-Footnotes254071
  8887. Node: Xfer254323
  8888. Node: Xfer-Footnotes262058
  8889. Node: 20 bits262596
  8890. Node: Fat DS263577
  8891. Node: Above 1MB267378
  8892. Node: RMCB268223
  8893. Node: Hardware interrupts270163
  8894. Node: _go32 vs __dpmi277667
  8895. Node: HW Int pitfalls279415
  8896. Node: Ports283124
  8897. Node: Inline Asm283837
  8898. Node: Legalese285179
  8899. Node: Applications285547
  8900. Node: Redistribution288346
  8901. Node: Help291264
  8902. Node: DJGPP isn't GNU291961
  8903. Node: Mailing list292844
  8904. Node: Subscribing293328
  8905. Node: Unsubscribing295787
  8906. Node: Silent list297602
  8907. Node: Duplicates298983
  8908. Node: Newsgroup300820
  8909. Node: v2301810
  8910. Node: New and improved302199
  8911. Node: Environment303547
  8912. Node: Miscellany305714
  8913. Node: Changing306914
  8914. Node: Samples310775
  8915. Node: Symlinks318308
  8916. Node: DPMI Spec319750
  8917. Node: WWW320847
  8918. Node: Upload321698
  8919. Node: Cross-DJGPP323914
  8920. Node: 0xfe+0x20328002
  8921. Node: Struct size328909
  8922. Node: Struct size-Footnotes333513
  8923. Node: Struct packing333662
  8924. Node: Int 24h334458
  8925. Node: go32-v2336932
  8926. Node: DXE337811
  8927. Node: LFN339141
  8928. Node: Missing separator340876
  8929. Node: Zoneinfo341918
  8930. Node: FAQ format345205
  8931. Node: About348021
  8932. Node: Topic Index350780
  8933. Node: Program Index392198
  8934. 
  8935. End Tag Table
  8936.