TurboC Usage Porting Borland Turbo C source code to GNU gcc  Home  Usage  Download  Change log Bug list

Contents

Introduction
Using TurboC
Licensing
Running a ported program
Running a ported program remotely
Supported Turbo C entities
Handling of integer datatypes
Special-function keys
Text screen resizing
Graphical display characters in text mode
Graphics mode
Alternative graphics-mode functions
Endian conversions
Examples
Trouble-shooting

Introduction

No explanation of the exact functionality of the various TurboC library elements is offered here, except for noting differences between Borland's version and my version.  As Pablo Vidal points out on his UConio web page, if you don't know how to use these functions already, then you won't need the TurboC library, since you shouldn't be using it for new program development anyway.  Consult Borland's Turbo C Reference Guide as needed.

But if you are porting or supporting a Turbo C program that somebody else has created, and don't have access to Borland's printed materials yourself, I'd offer the following advice:  Download the free Turbo C development environment that Borland has kindly provided on their "museum" website.    (Requires you to register, but registering is free.)  The IDE has context-sensitive help, and you can find out what most functions do by typing the name of the thing (such as clrscr)  into the source-code editor and then hitting ctrl-F1.  Of course, this requires you to have some means of running an MS-DOS program.

Alternately, the online help for Borland's C++Builder program actually provides much fuller documentation of Turbo C library functions (even though it doesn't support a lot of them), and while C++Builder itself is not free, Borland allows you to download the Win32-based helpfile for free from their website .   After you download it, the particular helpfile you want is the one which Borland calls the DOS Reference.  Sadly, there's no guarantee that this documentation corresponds exactly to the functionality provided in Turbo C.

Using TurboC

gcc [-O0] ... your switches ... -lTurboC -lm -lncurses -L/usr/X11R6/lib -lX11 -lpthread

or

gcc -DDoNotFixIntegers ... your switches ... -lTurboCu -lm -lncurses -L/usr/X11R6/lib -lX11 -lpthread

The command-line switch "-DDoNotFixIntegers" is optionally used to turn off TurboC's integer datatype conversion macros and (as you may notice) uses a slightly different version of the library.  In the past, some GNU "functions" actually implemented as macros have failed to compile with optimization level higher than -O0, when integer datatype conversion is turned on.  That's why one of the examples includes -O0 and the other does not.  However, this precaution is probably no longer necessary, and you needn't use -O0 unless experiencing problems.

You can see samples of both types of compilation in the provided Makefile.  If there are complaints from the compiler, refer to the trouble-shooting section below.

The switch "-lm" is required by only a couple of functions, but there's no harm in using it for everything.  The switch "-lncurses" is needed only if you are using the Turbo C functions prototyped in conio.h, while the switches "-L/usr/X11R6/lib -lX11 -lpthread" are needed only if using the functions prototyped in graphics.h.  You'll want to remove these switches if they're not used, to enhance your ability to compile the ported program on more platforms.  For example, neither ncurses nor Xlib are typically present in a Mac OS X system (though they can be installed with some effort), and compilation of your ported program will therefore typically fail if these compiler switches are included.

Although I'm not entirely sure why you'd want to do it, and though I haven't tried it myself, I think you can probably disable the graphics.h functions in the TurboC library, and replace them with those in the GRX 2D graphics library.  In the TurboC library Makefile, remove the compiler switch "-DWITH_X" before compiling the TurboC library.  Then install GRX and follow the instructions in GRX's readme.bgi file.  I'd be happy to hear from anyone with feedback (pro/con/howto) on this topic, and will post those comments if they seem to be of general interest.

Licensing

If your code is linked to ncurses or X, as described in the previous section, you'll also have to conform to their licenses, namely the MIT license and the X-Consortium license respectively.  These licenses are highly non-restrictive, and require merely that you include their copyright notices.  Both licenses can be viewed at the Free Software Foundation's website.

Running a ported program

While text-based programs ported with the TurboC library run to some extent in almost any *nix text terminal, it is highly advisable to run the ported program under the X-window system, explicitly using xterm.  I'd recommend invoking your program as follows, either from a command line or as a desktop icon:

xterm +sb -tn linux -e PortedProgram PortedProgramOptions ...

The deficiencies which you may encounter if xterm is not used are numerous, but other kinds of text consoles (even a real text console without the X-window system) may prove to be satisfactory for your purposes.  You'll simply have to try it and see, if you're so inclined.

Graphical capabilities, on the other hand, are supported only under the X-window system, and require availability of an X server.  In general, this means that the ported program can be run on any *nix box except bare-bone ones (like firewalls) or quirky ones (like Mac OS X) that don't provide X.

Running a ported program remotely

xterm +sb -tn linux
telnet/rlogin/ssh/etc. (to connect to host)
PortedProgram PortedProgramOptions ...

To a certain extent, graphically-based programs can also be run remotely, because the TurboC library's graphical capabilites are based on the X-window system.  However, exploiting this capability is hardly a user-friendly process.  The following steps are necessary:

1. You must set up the X-server at the user's location to accept input from the remote computer hosting the ported TurboC program.  This is done with the command-line program xhost, and you need to know the ip address of the remote computer:
xhost RemoteIpAddress
2. The DISPLAY environment variable must be properly initialized on the remote computer to indicate the user's computer.  Typically this is done automatically when you log in (with telnet/rlogin/ssh ), but not necessarily.  So after logging in, but before running the ported program, you might need to set up DISPLAY.  In the bash shell, this would look something like this:
export DISPLAY=UserIpAddress:0.0

xterm +sb -tn linux
xhost RemoteIpAddress
telnet RemoteIpAddress
export DISPLAY=UserIpAddress:0.0
PortedProgram PortedProgramOptions ...

Supported Turbo C entities

Anyway, the table below isn't a complete list of all the Turbo C entities you can use, but simply those that the TurboC library treats specially. Also, I'm sure there are Turbo C functions that need special treatment which I've simply not encountered yet in my porting activities, and so aren't included here.
 

Handling of integer datatypes

The TurboC library allows you to handle this problem in two separate ways, at your option.  The first way, of course, is simply to ignore the problem and to assume that an int is an int is an int.  :-)   In other words, datatypes can be left unchanged, and it's up to you to figure it out later, if your program doesn't work.  By default, though, TurboC redefines the words short, int , unsigned, and long using macros so that they are replaced by GNU datatypes specifically corresponding to the Turbo C datatypes, namely:

#define short int16_t
#define int int16_t
#define unsigned uint16_t
#define long int32_t

This scheme has the advantage of transparently fixing almost all data declarations in your program.  Those declarations which are not fixed properly, such as unsigned long or the use of unsigned to define bitfields in a struct, are broken.  This is actually good news, because the compiler gives you an error message and you're allowed to fix the problem, rather than just allowing you to assume everything is swell.  The resources you have to fix the problems with are the various explicit datatypes provided by GNU gcc (int8_t,uint8_t, int16_t, uint16_t, int32_t, and uint32_t) and some new datatypes defined by the TurboC library corresponding to the original (non-macro-replaced) GNU datatypes: gchar, gschar , guchar, gshort, gushort, gint, guint, glong, and gulong.

For example, after automatic macro conversion, things like the following will be correct

int i, j, k;
unsigned u;
char c;
short is;
long n;

unsigned int i, j, k; // Change to unsigned or to uint16_t.
unsigned char c; // Change to uint8_t.
struct MyStruct
{
  int i; // Okay.
  unsigned x:1; // change to guint.
  unsigned y:2; // change to guint.
};
int main (int argc, char *argv[]) // Change to gint.
{
  ...
}

Note that if you want to use "-DDoNotFixIntegers" to compile the code you're porting, a different version of the library is used -- libTurboCu.a rather than libTurboC.a.  Both library versions are automatically built, for versions 20020319 or later.  (For earlier versions, I'm afraid you'll have to build libTurboCu.a yourself by manually changing the Makefile to have the gcc switch -DDoNotFixIntegers).

Here is a tabular summary of how the integer datatype declarations are handled if converted automatically by the TurboC library:
 

Special-function keys

Unfortunately, many function-key sequences available using getch in MS-DOS are not available at all using the ncurses library.  (For example, F1 is available, but Ctrl-PgUp is not.)  Others may or may not be available, depending on various factors.   Consequently, while the TurboC library has mimicked this functionality as best it can -- or rather, as best I can -- you may still be in the position of having to change some of the special-function keys used by your program.

Here's a list of all special keys that I believe are handled by Turbo C's getch function, along with my observations of how they are handled by the TurboC library's getch function.  Your mileage may vary.
 

I'd be happy to hear from anyone with a clear idea on how make this work more consistently, perhaps by using termcap/terminfo, of which I'm completely ignorant.

Text Screen resizing

The situation is different in ncurses -- at least, if using the X-Window system -- because the size of the text console is entirely under the control of the user.  The user can resize the text console at will, and the program has little effective control over the resizing.

This presents a difficulty, because Turbo C programs have naturally been written under the suppositions that the text console size has been set by the program itself, and that the text console is not going to be unexpectedly resized during program execution.  Yet, these suppositions are both rather dodgy with code that has been ported using the TurboC library.

There are several possible approaches to the problem:

1. For TurboC versions 04/18/02 and later, the screen size is now correct if the ported program is run under xterm.  TurboC physically resizes the xterm console correctly upon starting the program.  While it cannot prevent the user from manually resizing the window later, it will correct any manual resizing by automatically restoring the window to its correct size.  (Sadly, it is possible for a persistent user to corrupt the window by trying hard enough to resize it, but the behavior is usually pretty acceptable.)  Or,
2. If for some reason it's impractical to use xterm, or if the window manager being used resists TurboC's attempts to resize xterm , then you may need to use some method outside of TurboC (such as instructions to the user) to prevent resizing of the window; or
3. Set the BypassResizeXterm variable to 1, and recode those portions of your program that depend on knowledge of the screen size (such as those using gotoxy and window functions) so that they are more flexible.   For example, don't use things like gotoxy(1,25) , but use gotoxy(1,LINES) instead.

In the latter case, by the way, if the user manually resizes the text console, then your current window (as determined by the windowor textmode function) will automatically be reduced in size (if necessary) to fit the new console size.  However, it will not be correspondingly increased in size of the user later enlarges the text console.  To override this behavior, you'll need to provide an alternative to the ResizeTurboC function.   You'll need to examine the source code for any further explanation.

Graphical display characters in text mode

What makes the first of these two lines "bad" is that the numerical code which the compiler creates for 'é' is based on the character sets and languages installed on the computer doing the compiling, and is very likely not 0x82.  So the first form is almost guaranteed not to work properly.  Even so, calling the second form "good" is stretching a point, because (as it happens), the TurboC library isn't presently able to display the character 'é' anyway.  True Turbo C is able to display any of the characters in the IBM PC character set -- i.e. the standard printable 7-bit ASCII characters, plus additional characters in the numerical ranges 0-31 and 128-255.  However, the TurboC library does not fully support this capability in text mode, because the ncurses library does not.  A subset of the IBM PC character set is supported, including linedraw characters.  (However, all linedraw characters representing double-lines or combinations of double/single lines are represented simply in terms of single lines.)
 

Screenshots of displayable Characters

True Turbo C

TurboC library

(Click here to see the program that generated this output.)  As you may notice, non-supported characters are rendered as dots.  Actually, this can be changed within the ported program to any other character as follows:

/*
  Add this code prior to the FIRST use of any conio function.
  The default character cannot be changed after initialization.
  The values used are any integer character code recognized by
  ncurses (NOT IBM PC character codes).
*/
extern gint DefaultChar;
DefaultChar = ' ';              /* or whatever */

/*
  Add this code AFTER the first use of textmode.
  It will be overridden if placed BEFORE textmode.
*/
extern gint TranslatedChar[256];
TranslatedChar[0x9d] = 'Y';     /* support YEN as 'Y'. */

Graphics mode

In true Turbo C, graphics-mode screens (as opposed to text-mode screens) are handled by something called the Borland Graphics Interface, or BGI for short.  The BGI is an API containing 80+ functions.  Note that the graphics functions provided with the TurboC library are somewhat less portable than the remainder of the library, in that the X-window system is required.  If you need graphics functions that can operate without X, I'd suggest reading the next section.

Some of the more important points of departure from true Turbo C are these:

• External files.  True Turbo C relies on the existence of certain plug-in files, specifically the BGI "drivers" (such as EGAVGA.BGI, HERC.BGI, etc.) and the fonts (such as TRIP.CHR, SANS.CHR, etc.).  The TurboC library has no such dependence, though it may eventually be possible to load new fonts at runtime.  Functions related to manipulation of these files are provided, so that you don't have to take the effort of writing them out of your code, but often they are empty stubs.
• Missing functions.  Implementation of the floodfill function is not presently planned.
• Screen hiding.  Since true Turbo C ran under MS-DOS, a non-windowed non-graphical environment, the way it had to operate was to take over the entire display screen, and to place the hardware graphics controller itself either in "text mode" or in "graphics mode".  In other words, if the graphics controller was in text mode then only textual functions (like those in stdio.h or conio.h) could be used, whereas in graphics mode only graphical functions (graphic.h) could be used.  Material written to the screen in text mode disappeared when graphics mode was started, and vice-versa.   With the TurboC library, because a windowed environment is used, both text-mode windows and graphics-mode windows can appear simultaneously.  In other words, when graphics mode is started, a new graphics-mode window is created, but no effort is made to hide the old text-mode window.
• Palettes.  Since true Turbo C dealt with actual modes of the hardware graphics controller, palettes were built into the graphics controller itself, and changes to palettes (for example, reassignment of a palette color, like the background color) were instantly reflected on-screen.  With the TurboC library, changes to the paletted (and specifically, to the background color) are reflected only in future screen-writes, and don't affect anything already written to the screen.
• Text.  The bitmapped font is supported.  For various reasons, sadly -- having spent a considerable amount of work on it -- I find that it's not convenient to support Borland's "stroked font" (CHR) format.  (These reasons include the following:  Borland's license does not allow using the Borland-supplied fonts with the TurboC library; nobody has made any free CHR fonts available on the Internet; and, while there are TrueType-to-CHR programs available, they cost more than I'm willing to pay -- i.e., more than zero.)  Therefore, the functionality otherwise normally provided by the stroked fonts will eventually be supplied indirectly by means of *nix system fonts.  Currently, this has not yet been implemented.  Or, you may draw text directly using Xlib functions, as described a few lines below.  You may also find the TcUnicodeMappings array useful when using Xlib.
• The getimage and putimage functions .  This is described in detail above.  Briefly, these functions are used to fetch a rectangular area of the display into an image buffer, or to write the image back to the screen.  The formats of the image buffers were undocumented by Borland, but actually corresponded to the memory maps used by the specific graphics controllers and graphics modes.  These formats are not duplicated by the TurboC library.
• Flexibility.  You don't need to confine yourself to the BGI functions.  You can also use X-window library functions.  For example, *nix system fonts -- which BGI obviously doesn't support -- can be used in a TurboC-ported program via Xlib functions like XLoadFont , XDrawString, etc.  All you have to know -- other than basic X operations -- is that the TurboC library exposes the following X objects for your use:
Display *TcDisplay;       // The X-window "display".
Window TcWindow;          // The X-window "window".
gint TcScreen;            // The X-window "screen".
GC TcGc;                  // The X-window "graphics context".
It's necessary to modify the graphics context (TcGc) for any serious drawing.  If you don't restore it to its original settings, the TurboC library will become seriously confused.  Therefore, it's best to copy the graphics context (with X-window function XCreateGC followed by XCopyGC), and work only with your copy of the graphics context rather than with the original.  Also, to avoid threading conflicts, always wrap your X operations as follows:
XLockDisplay (TcDisplay);
// ... your X code goes here ...
// For Example, draw a text string at x=10, y=20:
XDrawString (TcDisplay, TcScreen, TcGc,
             10, 20, "I am text", 9);
XSync (TcDisplay);
XUnlockDisplay (TcDisplay);

Alternative graphics-mode functions

For example, there is a 2D graphics library called the GRX library ( by Csaba Biegl, Michael Goffioul, and Hartmut Schirmer).  The GRX website does not advertise (or even mention) Turbo C compatibility. However, it contains quite a few functions of the same name (and, apparently, the same functionality) as Turbo C library functions.   To find out more, download the library using the link above.  After unpacking the tarball, you'll find the Borland replacement functions in the src/bgi directory, and information about them in the doc/readme.bgi file.

Disabling the graphics functions present in the TurboC library involves these steps:

1. Edit the TurboC library's Makefile, remove the compiler switch "-DWITH_X", and rebuild the TurboC library.
2. Eliminate the TurboC version of graphics.h from the system includes (probably /usr/include).
3. Install GRX.

Endian conversions

To make it easier to deal with this problem, I've provided a number of functions not originally present in Turbo C that can be used to convert endian types where required.  Unfortunately, it's still up to you to figure out that there's a problem and to add these function calls to the program.

There are two separate groups of functions, those which convert the endian type of an integer value already stored in memory, and those which convert data on-the-fly whilst reading/writing a file.  All of the functions require the TurboC.h header file.
 

Examples

#include <conio.h>
#include <time.h>

void
main (void)
{
  time_t t, newt;
  int i = 0, x, y;
  time (&t);
  clrscr ();
  cprintf ("Hit any key to continue: ");
  x = wherex ();
  y = wherey ();
  // Wait for a keypress, flashing the message
  // "I'm waiting!" on and off once per second.
  // After any key is hit, display "Hello, world!"
  while (!kbhit ())
    {
      time (&newt);
      if (t != newt)
        {
          t = newt;
          i++;
          if (0 == (i & 1))
            cprintf ("I\'m waiting!");
          clreol ();
          gotoxy (x, y);
        }
    }
  getch ();
  cprintf ("\r\nHello, world!\r\n");
}

• You will want to add the following statement at the very end of the program:
textmode (EXITMODE);
• The "Hello, world!" message won't actually be seen, because the textmode(EXITMODE)you have to end with will instantly restore whatever was on the screen prior to running the program.  So, you might want to add another getch() printing the "Hello, world!" message.
• GNU gcc expects main to be of type int rather than void, and of course you can't actually use int because of the automatic conversion of integer datatypes.  So use gint instead.

gcc -o Hello Hello.c -lTurboC -lncurses
xterm +sb -e Hello

Trouble-shooting

• Whenever possible, run the ported program under xterm, with the command-line switches "+sb -tn linux".
• Functions needed by Turbo C may not have been provided in the TurboC library function list.  Solution:  Write them and send them to me.
• Integer datatypes may not have been converted properly.  Solution:  Handle as described earlier.
• Some functions, such as strupr, strlwr, and fcloseall are not handled by any of the Turbo C header files.  Solution:  #include <TurboC.h> .
• The TurboC library cannot physically resize the console unless the ported program is being run under xterm.  Solution:  Manually resize the console, rewrite the code to adjust automatically to size changes, or send me a fix.
• The ported program does not release control of the console on exit.  Solution:  Add a call to textmode(EXITMODE) before exiting the program.
• Functions don't behave as expected.  Quite a few functions are common to Turbo C and to gcc, but act somewhat differently.  An example is printf.   In gcc this supports the carriage-return character ('\r'), but in true Turbo C does not.  I've chosen not to correct this.  Other functions, like getch , ungetch, and mkdir, are different enough that I've had to correct for their differences.  Typically this is done by means of macros, so that these functions have their gcc interpretations above the point in the source file where their associated header files are included, and have their Turbo C interpretations below that point.  Solution:  Learn to recognize it, I guess.  The gcc functions are always available, even after macro assignment, by means of a new name, such as getchNcurses.
• Not all special-function keys on the keyboard are supported. Solution:  Rewrite the code to eliminate the keys that aren't supported, or send me a fix .
• Not all graphics characters are supported in console i/o mode (cprintf/putch/etc.), and none of them are supported in regular text mode (printf/putchar /etc.).  Solution:  Rewrite the code to eliminate those characters, or send me a fix.
• char is signed but is supposed to be unsigned (or vice versa).  Solution:  Both Turbo C and gcc have options/switches for setting whether characters are signed or unsigned by default.  Make sure you set the switch in gcc the same way as the option in Turbo C.
• Main function is of the wrong type.  The gcc compiler expects main to be of type int, whereas in Turbo C these are often (always?) of type void.  Solution:  Change it.
• You may experience some compiler errors if integer datatype conversion is turned on but a compiler optimization level higher than -O0 is used when compiling your code.  Solution:  reduce the optimization level to -O0 and report the problem.  This applies only to compiling your own code, and not to building the TurboC library.
• Allocating the image buffers for the getimage function:  The proper sequence of operations, as defined by Borland's docs, is this:
// Good code, approved by Borland and by the TurboC library.
void MyFunction (void)
  {
    void *bitmap;
    bitmap = farmalloc (imagesize (left, top, right, bottom));
    getimage (left, top, right, bottom, bitmap);
    ... do stuff, such as call the putimage function ...
    farfree (bitmap);
    return;
  }
If instead your program does stuff like the following, it will probably work, but you'll have a memory leak in which the memory allocated for the image buffers won't be fully deallocated:
// Bad code, by any standards.
void MyFunction (void)
  {
    char bitmap[4 + X_SIZE * Y_SIZE * COLOR_DEPTH];
    getimage (left, top, left + X_SIZE - 1, top + Y_SIZE - 1, bitmap);
    ... do stuff, such as call the putimage function ...
    return;
  }
The problem is that getimage has to transparently allocate memory of which you're not aware -- specifically, X-window system Pixmap structures.  In the olden days, programmers (such as myself) were tempted to write this kind of bad code because they believed that they understood the format of the graphical data in the image buffers -- even though Borland did not specify or even hint at its nature.  This assumption is now revealed as being false.
• Manipulation of the image buffers used by the getimage and putimage functions:   Borland does not specify the format of the data in the image-buffer structures used by the getimage and putimage functions.  (See the item above.)  All that is specified is that this:
struct {
  unsigned short width;
  unsigned short height;
  ... some undocumented stuff representing graphical data ...
};
For practical reasons, it is likely that some (perhaps many) programmers -- such as myself -- hacked the format of the graphical-data area, and chose to manipulate the area directly.  Programs based on this principle will not work, because the format of this area -- at least in the X-window based implementation of graphics.h functions -- is not the same in the TurboC library as it was in Borland's Turbo C.    (Note:  it is possible to rewrite the code for getimage and putimage so that the old Borland formats are preserved.  The formats were dependent on the graphics controller and the graphics mode.  Anyone who cares to hack all of these and to rewrite the code accordingly is very welcome to do so.  Please send me the fixes.  As of Borland C++ v5.0, the graphics.h file listed 43 graphics controllers and 29 graphics modes by name.  The comments in the next trouble-shooting item below may be of assistance to you, if you try to undertake this task.)  However, it is possible to manipulate the graphical data in the TurboC library image buffers, because I will tell you the format.  You need to use X-window drawing functions such as XDrawLine, as applied to X-windowPixmap structures.  The format of the image buffer, for the X-window implementation of the TurboC library, is as follows:
struct TcImageBuffer
{
  gushort Width;
  gushort Height;
  Pixmap Handle;
};
• Saving getimage image buffers to disk, or loading putimage image buffers from disk:  If you read the discussion above, it will be obvious to you that this is next-to-useless, since the image buffers themselves no longer contain graphical data.  What needs to be save or loaded is the Pixmap structures themselves, whereas the image buffers contain only the handles of the Pixmap structures.  I believe that it is possible to get around this problem by rewriting the getimage /putimage functions in terms of the X-window functions XGetImage and XPutImage rather than Pixmap structures.  If you want to do this and send me the patches, tell me about it.

• Various standard C library "functions" may actually be implemented as macros on some target platforms, and as true functions on others.  A common example is strcpy.  When such macros contain casts (such as "(unsigned int)") that are questionable as described above under handling of integer datatypes, code containing them will fail to compile. It's difficult for me to catch all of these, since they may be perfectly fine on my test machines.  For clues as to how to work around such problems, look at the implementation of strcpy in TurboC.h.  Sometimes, changing the compiler optimization level to "-O0" fixes the problem.  Or, just don't use the automatic datatype conversion.
• Header files are messed up.  The TurboC header files all include TurboC.h, which by default redefines short, int, unsigned , and long.  Solution:  Any standard system headers, must be included before any TurboC header, or else the reassignments of the integer datatypes will destroy them.  Actually, TurboC.h itself includes a variety of standard system headers -- like stdlib.h, stdio.h, string.h, ctype.h, and so on -- and this problem won't arise for those headers.   But your typical *nix system has a cadjillion header files, and TurboC.h can't include them all.
• Filenames don't work in fopen.   MS-DOS expected filenames like C:\MYDIR\MY.FIL, whereas *nix expects names like /MYDIR/MY.FIL.  Also, *nix is case-sensitive, whereas MS-DOS is not.  So if you have any hardcoded filenames that violate these rules, you'll have to fix them. I suppose I could have fixed fopen to get around some of these problems, but I have not done so.
• scanf/gets/getchar doesn't work.   In Turbo C, to a certain extent you can get away with mixing and matching getchar & getch or cgets & gets.  This doesn't work with the TurboC library because once the conio text console is active you can't use scanf/gets/getchar until closing the conio console.  Solution:  Rewrite the code to eliminate gets/getchar in favor of cgets/getch (or vice versa).  But note this:  In my experience, a large motivator for using conio was often simply that Turbo C's print/puts functions did not correctly support '\r'. gcc 'sprintf/puts functions do correctly support '\r', so you might not even need conio.
• The compiler gives weird errors for printf/scanf/(etc.) commands.  The gcc compiler is intelligent enough to find many discrepancies between format strings and value lists in printf statements.  For example, it can recognize that this is an error:
long n;                // a long
printf ("%d\n", n);    // an int
But it's not smart enough to necessarily recognize that the following isn't an error:
uint32_t n;            // a long
printf ("%ld\n", n);   // a long
That's okay, though, because gcc produces only warning message rather than fatal errors for these problems.  Besides, you'll want to check all of your i/o statements carefully anyway, since stuff like the following is correct in Turbo C but not in gcc/TurboC:
int n;                 // 16-bits
printf ("%d\n", n);    // 16-bit in Turbo C but 32-bit in gcc.
• printf/scanf/(etc.) don't work, but there's no compiler error.  See the item above.
• File i/o is messed up.  File i/o is not messed up, but since different datatypes are supported in Turbo C than in gcc/TurboC, the data formats you're reading/writing may be different.  This can happen in numerous ways:
• Integer datatypes are the wrong size.
• Integer datatypes are the wrong endian type.
• printf/scanf/(etc.) may use the wrong format strings (see above).
• Floating-point formats differ.  Sorry, but I've no clue about this.
• Structures are packed differently.  For example, a structure like this in Turbo C
struct MyStruct {
  char c;
  short s;
  int i;
  long n;
};
might have to be rewritten as follows in gcc/TurboC if you expect to use it for direct i/o to a file:
struct MyStruct {
  int8_t c __attribute__ ((packed));
  int16_t s __attribute__ ((packed));
  int16_t i __attribute__ ((packed));
  int32_t n __attribute__ ((packed));
};
I can't guarantee that this always works, but I've ported a reasonably substantial text-indexing system from MS-DOS (16-bit, little-endian) to LinuxPPC (32-bit, big-endian) that made heavy use of directly inputting/outputting structures to files, and the file formats were preserved.  That seems to me to be a good sign.
• Interrupt service routines.  Sorry, I don't even want to think about this.
• Inline assembler code.  It can be done, but I don't know how, and the syntax will be different.  I personally don't care about this problem, because I'm interested only in completely portable code. Sorry!
• Making DOS or BIOS system calls.  Obviously, you can't.
• Turbo C pragmas.  These will get warning messages from the compiler, but will be otherwise ignored.  But they're confusing, so unless you expect to go back to MS-DOS someday, I'd suggest removing them manually. :-)