Seegras Logbook

• 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