Open the Sources


Don’t give in to the Dark Side

There is a growing pool of software, originally written for MS-DOS, which now
becomes more and more impossible to run. People maybe liked a certain program
or used it for their hobbies, but now, they have another Operating System, and
they don’t want to use DOS or to reboot just to use this peace of program.

This, of course, happened to me with roleplaying-related programs when
I switched to Linux. I only use DOS for playing computer-games, and I only
boot it when I am sure that I will need it for an hour or more. Surely not
for using some DOS program which probably even runs on the commandline.

So there goes the solution: Recompile it. Simply. If there is a source, I
normally do that, and so I’ve got quite a collection of programs which I
ported from DOS to Linux. And so, I’d like everyone to tell:

Release your Sourcecodes!

It doesn’t hurt you to release a source-code of some program you wrote
five years ago. There is plenty of possibility to recycle old sourcecodes,
even when they’re written in some weird language such as BASIC.

So I take a look now at some possibilities and quirks regarding different
programming languages, their implementations and their portability. Especially
in regard to Unix/Linux.

Where, please?

Todays standard is C. Or some variation of it like Objective-C or C++.
So the point is:

  • Port your Program to C if possible.
  • Make it run on another operating system.

We’re gonna use the GNU C-Compiler, because it’s one of the best, and it’s
available on nearly every platform (Unix, Windows NT, OS/2, DOS, only
to mention the most common ones).

GNU C or GCC comes in three different variations, as C-compiler, C++-compiler
and objective-C-compiler. And then there are some add-ons (or merely pre-
processors) which can translate pascal and fortran to C. So there’s no such
big problem translating fortran or pascal to C. So here we go examining some
compilers and how their code can be translated to GCC.

Note: You cannot normally use conio.h or dos.h for programs not running on
DOS. So this must be circumvented in some way.

What general problems are to expect?

  • Command-line based programs should easily be ported. Problems can arise
    out of different length of data-types.
  • Character based programs using console io might give some troubles. The
    problem most often encountered will be that other operating systems do
    not allow direct manipulation of their console. This appears with conio.h
  • Graphically enhanced programs really aren’t easy to port. Instead of using
    language-specific or self-programmed graphic enhancements, svgalib must be
    used. This can be as difficult as rewriting the whole program from scratch.

What problems are to expect using specific languages?

C

  • DJGPP – The GNU-C for DOS, no changes necessary.
  • Symantec C – dos.h and conio.h, as well as makefiles
  • Turbo C – dos.h and conio.h, as well as makefiles
  • Borland C – dos.h and conio.h, as well as makefiles
  • Microsoft C – dos.h and conio.h, as well as makefiles
  • Quick C – dos.h and conio.h, as well as makefiles

Pascal

  • Turbo Pascal – dos.h and conio.h

Basic

  • GW or MS-Basic – line-numbering
  • Turbo Basic
  • Quick Basic

C Problems

dos.h

This one defines variable types and FAT-filesystem-specific things. Problems
can arise out of different lengths of data types (16 vs 32 bits).

conio.h

conio.h (console i/o) does not exist on Unix. There is a port of conio.h,
but this shouldn’t be used. Instead, ncurses.h or curses.h should be used.

Peter Keel,

1997-01

Comments are closed.