Archive for January, 1997

How I manage to get the work done

Wednesday, January 1st, 1997

How I manage to get the work done

Time ain’t on my side..

Somewhere deep down in my brain, I knew I had to do some work. So I
finally got around to ask what the matter was with that work. “Ahh, we’re
doing it already, and next week is last date for a pre-meeting with the
assistant”. Okay, so I got me dated for that meeting. In the meantime I
collected some materials: The plastic card for library-access, for instance.
I thought I would make something on software-piracy. But nope. No data
available, no hard statistics, nothing. Seems that there is no software
piracy, just the SPA crying, because they want to sell their anti-piracy
software. Remind me to pirate that software.

A day before that meeting I finally had an idea of what I could do. I’d
write on victimless crimes, yep. That’s something I caught on in my
15 minutes library visit. So I emailed across the world, got some crime-
statistics from the USA, but none of Switzerland and finally went to the
meeting. I brought up my notebook and explained what I would do. The assistant
obviously was shocked by raw data and told me not to worry. “You already have
enough data”. And I had to hand in the paper in two weeks. So there.

I went home and did what I always do when such pressure hits me. I divert
pressure to things I shouldn’t really do now. So in these two weeks

  • Started programming Perl
  • Reorganized my Web-Server
  • Organized 300 Megabytes Data
  • Wrote these pages

Of course, sometime, I’d have to write the paper, which is, probably now,
being it only one and a half day until I have to hand it in. See?

And I am even writing this text before my work!

Peter Keel,


Open the Sources

Wednesday, January 1st, 1997

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?


  • 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


  • Turbo Pascal – dos.h and conio.h


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

C Problems


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 (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,