DownLoads‎ > ‎


If you are reading this it is hopefully because you want some hints on how to
build some of the code in one of Will Kranz's *.tar.gz source code distributions.
I was a mechanical engineer and switched over to coding software in the mid 1980s.
I had access to RT11 on PDP11 systems my dad owned, and did a little Fortran work
on them, but the majority of my code started on Intel 16 bit machines running MSDOS.
I still compile code for those systems as I still have some in the basement.  They
make good work stations to interface with the PDP11 systems I enherited from my dad.
Almost all of these are C programs.  I've made source code for many available on this
page, but if you are looking for something else let me know.

Most of the machines I currently work on are now Intel 32 bit systems.  The applications
I create are typically file access or conversion programs and work fine at the command
prompt level without any of the overhead of handling graphic windows.  These programs can
be built and run on a linux console or in a Windows 'Command Prompt' window.  Naturally they
can also be built in MSDOS if you have a suitable compiler.  As described below I normally
build MSDOS executables under WIN32 but most of the old Microsoft MSDOS compilers will build
this code with a suitable makefile (not included, but you should be able to work it out).
Some of the older code such as the MSBACKUP archives were built with Microsoft's Nmake and
are typically named 'makefile.mak'.

Under Linux I use the GNU utilities, 'gcc' to compile and link and 'make' to build the
applications.  For MSDOS and WIN32 I have switched to using the Open Watcom 1.8 distribution
which is available at  I think there is at least
a version 1.9 available now which also seems to work, but I am still using 1.8.  The
documentation also suggests this compiler suite will build linux executables, but I have
choosen to stick with the GNU utilities for Linux.

I don't intend to give a lot of detail here that you can get by reading the compiler manuals,
but a few of the main things I do to allow my code to build in all three environments are mentioned
below and shown in the sample program tstsz.c.  My source code tarballs typically include
a 'makefile.wnt' for the Watcom Wmake program that will build 32 bit console applications
using Watcom's wcc386 compiler and wcl386 linker.  You need to have the appropriate Watcom
tools installed and the path to them set in your environment.  If your are building in
a 32 bit environment the _WIN32 tag should be set correctly, but you can force this by
adding '-bt=nt' to CFLAGS in the build file or explicitly defining it via '-d_WIN32'. 
To cross compile a DOS 16 bit executable in a 32 bit environment add '-bt=dos' and
optionally -dMSDOS to CFLAGS and use wcc and wcl as the compiler and linker commands.
To compile in the Linux environment use the GNU make program with the supplied 'makefile'

The other defines are done in the source code.  For binary file access in MSDOS and WinNT
the file 'fcntl.h'  defines O_BINARY to a non-zero value.  For my code to compile under
Linux I define O_BINARY to 0 in the program specific *.h file.  Some of the string
comparision functions also have different names under Linux but the same arguments (handy)
so typically I redefine stricmp() and strnicmp() to allow linking under Linux.

I have had one other problem which seems to be specific to my MSBACKUP work.  This was
a program distributed by Microsoft for Win95, Win98, and WinME to automate file backups.
These were the 1st 16 bit Windows programs.  When they switched to WinXP, the first 32
bit windows OS, no thought was given to people with these old backups.  You are probably
well past this oversight on Microsoft's part, but if you want to recover some of this code
it can still be down.  The important thing when building this source code distribution,
msbksrc.lzh, is that I found that some of the structures had to be packed to get the correct
alignment in memory.  The Microsoft and Linux build files reflect this with some form
of a "#pragma packed(1)" entry in the source code to insure byte packing.  I believe these
to be the only programs I've written that require this.

/*--------------  source code for tstsz.c program ------------------------------------*/
/* tstsz.c  test sizes of std types  and my typedef defines

dos   qcl output: sizeof(char) 1 sizeof(short) 2 sizeof(int) 2 sizeof(long) 4
lin32 gcc output: sizeof(char) 1 sizeof(short) 2 sizeof(int) 4 sizeof(long) 4  (for 32 bit I386 systems)
    the watcom Win32 builds are the same as above  but
lin64 gcc output: sizeof(char) 1 sizeof(short) 2 sizeof(int) 4 sizeof(long) 8  (for 64 bit systems)

so for 64 bit compatibility make the DWORD typedef conditional per below
typedef unsigned char  BYTE;
typedef unsigned short WORD;

#if  defined(MSDOS) || defined(_WIN32)
# ifdef MSDOS
#define OS_STR "MSDOS"
typedef unsigned long DWORD;
# else
#define OS_STR "WIN32"
typedef unsigned int DWORD;
// its a unix like environment
#define O_BINARY 0 // required for DOS and WIN32, this makes that bit define Linux compatible
#define OS_STR "LINUX"
#include <stdlib.h>     // for exit() surpress warning about implicit declaration
#include <unistd.h>     // for lseek, read, write
// for string comparisions add the following
#define strnicmp strncasecmp
#define stricmp  strcasecmp

#include <stdio.h>
#include <string.h>
#include <fcntl.h>

  printf("\n%s  sizeof(char) %d sizeof(short) %d sizeof(int) %d sizeof(long) %d\n",
            OS_STR,sizeof(char), sizeof(short), sizeof(int), sizeof(long));

  printf("sizeof(BYTE) %d  sizeof(WORD) %d  sizeof(DWORD) %d\n",

#ifndef O_BINARY
   printf("warning O_BINARY not defined \n");