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,

2001-05-11

last update (links) 03.09.2004

Comments are closed.