Porting Borland Turbo C source code to GNU gcc
TurboC in a nutshell
Why was TurboC created?
Features and Deficiencies of TurboC
Download and Install TurboC
Mac OS X
What's with the cute logo?
TurboC is available as free software under the GNU Lesser General Public License (LGPL).
But I ran into a snag. It's no good to release software if there's no way for anybody to find out about it. My preferred channel for announcing open-source software is freshmeat, but freshmeat doesn't "do" MS-DOS (and therefore politely declined to accept my MS-DOS projects).
Apparently, necessity really is the mother of invention. It occurred to me that if I could provide appropriate Turbo C compatible libraries and header files, then the effort of porting Turbo C code to *nix would be greatly simplified. In other words, it would be relatively easy to provide *nix versions of the old MS-DOS code. Whether it's absolutely easy or not depends a lot on the program you're trying to port.
Borland supposedly has (or will soon have) a Linux version of their C++ compiler. At this point, the nature, price, and target platforms of this compiler are mysteries. One presumes that (like Kylix) it will be Wine-based, and therefore will work only on 'x86 systems. Nevertheless, if it contains the various library functions implemented in the TurboC library -- and frankly, that's a very big "if" -- it might provide a simpler means of porting your Turbo C programs to Linux. Speaking for myself, even though I have been a long-time Borland user, I philosophically prefer to compile my program with GNU gcc.
For graphics.h functionality, there is the GRX library of Csaba Biegl, Michael Goffioul, and Hartmut Schirmer. I didn't discover this library until I had only a few graphics.h functions left to write, and I haven't fully evaluated it. Its stated aim is to be a multi-platform 2D graphics library. Its 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.
Of course, if you are only interested running your program on *nix systems -- as opposed to porting the program to *nix systems in general -- you might be able to simply run your existing executable using one of the freely available DOS emulators for Linux. DOS emulation using dosemu with freedos works very well on 'x86 systems, while bochs with freedos works well (if somewhat slowly) on non-'x86 *nix systems.
|*Most-current development code (20100828)||TurboC-dev.tar.gz|
The tarball contains a directory called TurboC-source. Within this directory, you can build the library simply by running make. This must be GNU make, and may be called gmake (for example, on FreeBSD or Mac OS X). (Note: In FreeBSD, you may need to edit the Makefile and comment/uncomment a couple of lines at the top, in a way that will be obvious to you.) I've verified that the most recent release snapshot (as opposed to the development snapshot) compiles and that a test program works on the following systems:
Linux Intel 'x86 (SuSE 8.0)(Early versions of the TurboC library which indicated that they worked with FreeBSD were probably over-optimistic in that assessment. Please upgrade to a version of at least 20020420, and be sure to follow the advice on running the ported programs.) The most current development snapshot has been tried only on SuSE 8.2.
Linux PowerPC (SuSE 7.3)
Put the libraries (libTurboC.a and libTurboCu.a) wherever libraries normally go on your system -- usually /usr/lib, I suppose. Put all of the header files wherever they normally would go -- /usr/include, I suppose. Or, you can just symbolically link them in these directories. Or, put them wherever you like and add appropriate -L and -I switches to your gcc command line.
Here's the way I would do it on my own system:
cd ~You may find (for example, in FreeBSD) that if you #include TurboC header files in the programs you're trying to port, you get compiler errors about symbolic links being "too deep". In this case, remove the "-s" switch from the ln commands above.
tar -xzvf TurboC-dev.tar.gz
... edit Makefile in FreeBSD ...
make (or gmake)
ln -s *.h /usr/include
ln -s libTurboC.a /usr/lib
Also, the Makefile makes certain assumptions about the locations of the X-window system header files and libraries; if these assumptions are wrong, you may need to alter the compiler switches "-L" and/or "-I" within the makefile. The X-window system is needed to compile the complete library, or to run a ported program, if you use any functions from graphics.h. If you don't intend to use these functions, you can use ported programs or compile the library on a system without X, by editing the Makefile and removing the compiler switch "-DWITH_X".
As most people in the *nix world know, Mac OS X is based on FreeBSD. Knowing this, you might suppose that if the TurboC library works on FreeBSD then it will work on Mac OS X. Alas! this optimistic appraisal is revealed as simplistic when viewed in the of harsh light of reality.
The TurboC library has indeed reached the stage where some versions (though not necessarily the current snapshot) compile and partially work under Mac OS X, if ncurses happens to be installed. Apple does not include ncurses in Mac OS X -- at least not as of the version 10.1 release. But ncurses available as a download from macosx.forked.net.
If you download and install ncurses, you should then be able to build the TurboC library as follows:
gunzip TurboC-dev.tar.gzWhat you do after this, is a mystery to me, though. I don't know how get the TurboC libraries nor the header files installed, because I can't figure out how to get the root-level permissions required to do so! Also, as I've said, the library only partially works. Perhaps it's a problem in the TurboC library ... perhaps it's a problem in the ncurses port. If anyone wants to explain this stuff to me, I'd be happy to know about it. Otherwise, for me, working with Mac OS X is too much like pulling teeth, so it's going to be quite a while before I work out the problems on my own initiative.
tar -xvf TurboC-dev.tar
Of course, feel free to tell me about bugs in TurboC. (Before doing so, of course, check out the list of already-known bugs.) I'll certainly make every effort to fix them.