Issues on Porting
DOS not make sense
- Fileformat: Normally these things use CR/LF, and sometimes
use braindead ibmpc-character encoding. I use “recode ibmpc:utf8mb4”
to make umlauts meaningful and “pt -u” to convert CR/LF’s. Makefiles
are mostly broken as well; and sources may contain some weird character
at the end of file. - Filenames: Normally crippled to 8.3 characters. I happened to
come upon some filename which was sometimes written to disk uninitalized
resulting is a fopen()-failure on DOS but working on Unix. Thus, on
Unix you’d get a long string of garbled characters as filename.. - Memory Model: DOS-programs come in different flavours of memory
models like “huge” or “small”, which is, of course, bogus. Delete it,
including “far”, “near” and “register”. - Types: On DOS, “int” normally is only 16bit, but is 32bit on
Unix. Depending on memory-models, pointers may also 16bit on DOS
(and of course are normally 32bit on Unix). - Strings: There are some naming differences on string-comparison
functions:DOS: Unix: stricmp() strcasecmp() strnicmp() strncasecmp()
- Language: C and C++ generally work when used in Character-mode,
i.e. if no graphics are used. Pascal can be a bit harder to get to work,
there are at least two pascal to C converters available. One is p2c of
the FSF and another ptoc.
I have ported some application from pascal to C using p2c and correcting
bogus manually (see below). Of course, using gpc (GNU pascal compiler)
or fpc (free pascal compiler)
you can compile pascal natively. For Basic, there’s
qb2c, which
can handle various basic-dialects through its preprocessor, but the
free version doesn’t understand dynamic memory allocation (DIM-command)
which makes it pretty useless.Pascal: C: assign FilePointer=Filename; FilePointer=fopen(Filename, "w"); _randint(15L); (rand()%15); _randomize(); srand((unsigned int)time());
For the crippled dialect of Microsoft C for DOS, I wrote a very basic
conversion-script to Borland C (see libgrx). - Character-Screen: Normally, DOS-Programs either use conio.h
or Turbo Vision. There’s a Linux-Version of conio.h, but I don’t
like it. You can easily replace conio with ncurses. There’s also
Turbo Vision for Unix, though I don’t know whether it works correctly.
The biggest nuisance with DOS-Programs is the stupid assumption of
its programmers that the screensize is 80×25. I wasn’t able to handle
other screensizes with the linux-conio, so I replaced every occurence
of conio-commands with their ncurses-equivalents.DOS: UNIX (curses): clrsrc(); clear(); gotoxy(Col, Row) move(Row, Col); refresh(); getch() getchar(); printf("string"); wprintw(window,"string"); #to avoid 80x25 issues cprintf("string"); wprintw(window,"string"); window(a,b,c,d); window = newwin(lines,cols,begin_y,begin_x);
Currently I’m working on some perl-scripts to automate this.
Alternatively it makes sense just to replace getch(), like this:
DOS: UNIX (curses): getch() int ch, charactr; while ((ch=getchar()) != 'n') { charactr=ch; }
Perhaps it is most easy to use my getch.c-function
to subsitute this. All you’ve got to do is to include it in the source. - Graphics: There’s a
BGI-Library for Linux, which doesn’t seem to work (a.out, no source
available). Another possibility seems to be
libgrx, along with bcc2grx, but libgrx seems to be seriously broken, and has problems with
mice and Keyboard on modern (glibc) systems.
Then FPK Free Pascal, a Pascal-compiler which can do Delphi II can handle SVGA-Graphics
as well, but not X. qb2c
in contrast appears to be able to do graphics on X.On a related note, there’s a
Visual Basic to C/GTK-converter, but I haven’t tried it yet. - Function-Keys: Handling of Function-keys, including DOWN, UP,
PGUP and PGDN seems to be mostly messy. I haven’t soled this right
now. It also seems that the conio.h getch() behaves different from
the ncurses getchar(). Plus there’s the issue of kbhit() which is
polling(!) the keyboard, which is an unbelievable stupidity and has
to be replaced with select() or something. - Random Numbers: Most DOS-programs can’t do these correctly and
they break on Unix, either resulting in always the same numbers given
back, or numbers of completely different length.DOS: UNIX: randomize(); srand((unsigned int)time()); random(number); rand()%number;
- There’s also another essay on this called
Porting
DOS applications to Linux by Alan Cox.
Also, there’s short writeup on porting DOS-programs which play with
hardware, it’s Porting DOS inb and outb functionality by someone at SCO.In the meantime, some other related articles have appeared:
Porting MS-DOS Graphics Applications in Linux Journal 53.
Easily Porting MS-DOS Diagnostics to Linux in LinuxGazette 58.
Porting Applications to Linux from Matt Welsh.
Related: Porting SGI Audio Applications to Linux, again, fom Linux Journal 53.
Porting Windows Applications to Linux from Mark Whitis.
Solaris-to-Linux Porting Guide from Ulrich Drepper.
Porting Win32 Applications To Linux from Gerson Kurz.
Porting MFC applications to Linux from Markus Neifer.
Porting MFC to GTK+ by Ryan C. Gordon.
Migrate your apps from OS/2 to Linux IBM.
Peter Keel,
last update (links) 03.09.2004