|
Porting Borland Turbo C source code to GNU gcc
|
 |
|
Porting Borland Turbo C source code to GNU gcc
|
|
Warning: By its very nature, TurboC is not a project with a lot of range for improvement. Like Popeye the Sailor, it is what it is, and that's all that it is.
Download the latest development snapshot here.
| Number | Type | Description | Status |
|---|---|---|---|
| 40 |
Buglet |
02/17/04: Jim Huang has
reported that in some (unspecified) version of *nix, the textmode.c
file does not compile, because of incompatibilities between the ACS_xxx macros and the
integer-type reassignments. This affects only systems on which
the library has never been compiled, and therefore is of no value to
anybody already using the library. |
Fixed in versions 02/18/04 and
later. |
| 39 |
Buglet |
02/12/04: The hex2h.c
file, which is actually a utility program, gets put into the libraries
(in the form of a main
function). Thanks to Jozeph Brasil for pointing this out.
It doesn't seem to affect most users, but sometimes causes a
multiply-defined function warning during compilation. |
Fixed in versions 02/14/04 and
later. |
| 38 |
Bug |
11/01/03: In trying to
compile under SuSE 8.2, I find that there have been changes in the
standard headers that cause a conflict between TurboC's gettext and the libintl's gettext. |
Fixed in versions 11/02/03 and
later. There is now a gettextIntl
function which encapsulates libintl's function. |
| 37 |
Bug |
12/16/02: Johnny Piette has reported
various
problems with compiling TurboC under gcc 3.x and/or newer
system library
versions: getdate and fcloseall prototypes
conflict;
also, linking the Test.cpp test program gives a "missing
__gxx_personality_v0"
error. |
Fixed. Note: In general, it
seems
as though with gcc 3.x, it may be necessary under some
circumstances
to compile c++ programs with the compiler actually called "c++" rather
than
with "cc" or "gcc". |
| 36 | Bug | 06/02/02: The diagonal line in the 3rd graphics screen of the GraphicsTest test program does not appear in FreeBSD. | To-do. |
| 35 | Bug | 06/02/02: The method of directly accessing an ncurses _line structure directly in gettext and puttext is not portable. This causes TurboC to not compile in SuSE 8.0. | Fixed. |
| 34 | Bug | 05/25/02: In graphics mode, getch returns regular keystrokes, but not special keys like arrows, F1-F10, etc. | To do. |
| 33 | Bug | 05/22/02: In fillpoly, the foreground color
of the border line is not correct. (It acts as though the
foreground is transparent.)
05/25/02: Same thing, but for the sector function. |
To do. |
| 32 | Issue | 05/21/02: Handling the situation in which the user manually closes the text or graphics window needs to be handled more gracefully. Manually closing the graphics window is now prevented (good!), but I can't remove the X button in the corner of the window. The text window, on the other hand, can be manually closed, and I don't know how to prevent it or to insure a graceful shutdown. | Look into it. |
| 31 | Bug | 05/07/02: getch and getche work only in textmode. Similarly, getchar works only when not in textmode. If graphics modes is used, getchar and getch don't work unless the focus is on the xterm window rather than the graphics window. | To do.
Partial fix 05/09/02: getch now works from a graphic window, whether or not it has been initialized with textmode. |
| 30 | Issue | The fcloseall function seemingly does not exist in FreeBSD. | Hmmm ... |
| 29 | Bug | When running remotely, found some escape-key sequences I hadn't found before for F1-F5, F10, so that these keys wouldn't register. This seemed consistent across platforms when running ssh. | 04/20/02, fixed. |
| 28 | Bug | Still a residual timing problem with the initial screen resizing, when running remotely. | 04/20/02, hopefully fixed by lengthening the timing loop for the screen resizing. |
| 27 | Issue | Probably never worked properly in a FreeBSD xterm. (I had only run it remotely, and never locally on a FreeBSD box.) | This is simply a question of using the proper settings with xterm , which requires the command switch "-tn linux" to match the environment I've actually been developing in. |
| 26 | Bug | No longer compiles under FreeBSD. | Fixed 04/20/02. |
| 25 | Bug | If the user manually resizes the xterm console, and the TurboC library subsequently restores the original size, portions of the screen may not be automatically redrawn. | Fixed 04/20/02, I think. |
| 24 | Bug | Found that strcpy (and presumably strncpy) may be implemented as macros and may therefore suffer from the bug reported as PR #22. | Fixed 04/18/02. |
| 23 | Bug | The the user physically resizes the console to be too small, subsequenct calls to ConioResizeCallback will not occur. This may have something to do with an error return in resizeterm. | To do. However, as of 04/18/02, the default behavior on resizing the terminal is to restore it to the size specified in textmode, and hence ConioResizeCallback would no longer be used anyway. |
| 22 | Bug | For some reason, when integer datatype conversion is turned on, you have to compile the code you're porting with optimization level -O0. If you use an higher level (such as -O1), some fairly inexplicable compiler errors occur. | Fixed 03/24/02. At least, strcmp, strncmp, strcmpi, stricmp, and strncmpi are fixed. There may be others I haven't detected yet. The problem is apparently the potential implementation of some functions a macros that may contain casts like (unsigned char *). I don't know why this would have worked at -O0, but apparently it did. |
| 21 | Bug | Apparently, adding the special display characters (like linedraw characters) broke tabs. | Fixed 03/24/02. |
| 20 | Bug | In movetext and puttext, if current window is not the full-screen, it may not be updated properly after the operation. | Fixed 03/23/02. |
| 19 | Bug | The libTurboC cgets function incorrectly performs a carriage return on receiving a carriage return input character. | Fixed 03/21/02. |
| 18 | Bug | The libTurboC cgets function returns non-nul-terminated strings. | Fixed 03/21/02. |
| 17 | Bug | cgets conforms to the documented behavior, in aborting after reaching the specified maximum number of characters. However, actual Turbo C does not behave this way; its cgets cannot terminate until a carriage return occurs. | Fixed 03/21/02. |
| 16 | Issue | Linking TurboC library to C++ code fails with many functions
not found. Thanks to Peter Carroll for bringing this to my
attention.
Explanation: I was targeting only Turbo C 2.x, and failed to realize that people with Borland C++ 3.x or 4.x might be using C++ rather than C. The TurboC header files don't yet have the extra goo needed for C++ compatibility. |
Fixed 03/18/02. |
| 15 | Bug | The Makefile will fail to build Test and TurboCChars (but will correctly build libTurboC.a) prior to placing the header files in with the system headers. | Fixed 03/18/02. |
| 14 | Serious bug | Apparently, my entire notion of using ncurse windows to emulate Turbo C windows is bogus, because ncurses windows are like sprites: they stand in front of the windows behind them, but don't modify those windows. Hence, when they are closed, their contents disappear completely. | Fixed 03/17/02. |
| 13 | Bug | In the following code, cprintf ("xxx %c yyy", 0); actual Turbo C displays the entire string, whereas the %cterminates the TurboC library cprintf after "xxx " because it effectively inserts a nul into the string. Only the character substitution value of 0 is affected. |
It's very unlikely I'll ever fix this. Change it manually in your code. |
| 12 | Issue | There's a several-second delay upon starting the ported program. Explanation: This delay occurs if the ported program is not being run under xterm; the delay is due to attempting to resize the xterm console to the proper number of lines and columns. | Fixed 04/18/02. |
| 11 | Bug | All unshifted characters on the numeric keypad may not work: 0-9, enter, '.', '+', '-', '*', '/', '='. | Fixed 03/16/02. |
| 10 | Issue | If the user physically resizes the console to smaller than the logical size of the console, a segfault can occur. | Probably fixed 03/31/02. For this fix to be effective, it's best to run the ported program under xterm. |
| 9a | Issue | It is not possible to prevent the user from physically resizing the console to an inappropriate size. | I don't believe it's possible to completely fix this if ncurses is used, but as of 04/18/02, the terminal is automatically restored to its correct size after a user manually resizes it. For this fix to be effective, the ported program should be run under xterm. |
| 9 | Issue | The textmode function cannot physically resize the console. | Partially fixed 03/16/02. If xterm is used, the console is physically resized. If not (for example, if KDE Konsole is used instead, or if an actual hardware text mode is used instead of the X-window system), the problem persists. I'm happy to call this problem "resolved", and simply require that xterm be used for full functionality, but others may not be. |
| 8 | Conceptual* | It's not possible with ncurses to mimic all Borland conio keystrokes (like Ctrl-Alt-F1). Furthermore, even the keystrokes that can be mimicked depend on how the *nix console being used has been initialized. Different console programs and different initializations for those programs may produce different numerical codes for the keystrokes. | I don't think anything can be done about this within TurboC
itself. A utility program is provided (CheckKeystrokes) with
which you can check what
special keys are working. You'll simply have to change your
source
program accordingly.
03/16/02: Support for special keys has now been greatly enhanced, to the point where it probably can't be improved much. |
| 7 | Bug | The clrtoeol function, if the console is wider than the screensize as defined with the textmode function, clears to the physical edge of the console. | To do. However, since the physical terminal width matches the logical terminal width (as of 04/18/02) when the ported program is run under xterm, I am liable to think of this problem as being resolved. |
| 6 | Conceptual* | Filenames hardcoded into a program will likely not work, because of things like drive-letters ("c:"), backslashes rather than forward slashes, and case-sensitivity. | Unfixable within TurboC. Please fix manually. |
| 5 | Conceptual* | The TurboC header files redefine the int, short, unsigned, and long datatypes. For this reason, they must follow standard header files such as stdlib.h and stdio.h. | Unfixable within TurboC. Please manually reorder the header-file inclusions within your source files. Current TurboC header files are conio.h and alloc.h. |
| 4 | Conceptual* | Borland Turbo C runs on an 'x86 CPU, which is a "little endian" processor. Byte ordering will be different on "bit endian" processors such as PowerPC. In most cases this won't matter at all, but it may affect file read/writes to files of specified formats. | Unfixable within TurboC. Please fix manually.
Note: Various endian-conversion functions have now been provided, but they must be manually inserted into the code. |
| 3 | Issue | Various Turbo C library functions are missing from TurboC. | I know it. Tell me specifically what functions you need, or (better yet) write them and send them to me. |
| 2 | Conceptual* | Various integer datatypes differ between Turbo C and GNU gcc . Some can be converted automatically by TurboC; some cannot. Refer to the summary table. | Unfixable within TurboC. Please fix manually. |
| 1 | Conceptual* | Structure sizes and field packing may not be (probably aren't) the same as in Turbo C. This can affects file reads/writes using complete structures or arrays of structures as file-records. | Unfixable within TurboC. Please fix manually. |