Resurrected Entertainment

Archive for the 'DOS' category

Microsoft Quick C Compiler

December 21, 2010

Quick C CompilerWhen I first came in contact with this compiler, I was just starting high school and eager for the challenges ahead (except for the material which didn’t interest me — basically non-science courses). When I went to pick the courses for the year, I noticed a couple which taught computer programming. The first course, which was a pre-requisite for the second, taught BASIC while the second course taught C programming. At this point in my life, I was an old hand at BASIC, so I basically breezed through first programme. The second course intrigued me much more. I was familiar with C programming from my relatively brief experience with the Amiga, but I had a lot left to learn. My high school didn’t use the Lattice C compiler, but a Microsoft C compiler instead. I located the gentleman who taught the course and he pointed me to a book called Microsoft C Programming for the PC written by Robert LaFore and the Microsoft QuickC Compiler software. I had a job delivering newspapers at the time, so I could just barely afford the book using salary and tips saved from two weeks doing hard time ($50 at the time), but the compiler was just too expensive. So I did what any highly effective teenager would do, basically I dropped really big hints around the house (including the location and price of the compiler package I wanted) until my parents purchased a copy for me on my birthday.

There are a number of differences between the BASIC and C programming languages. One of the more obscure differences lies in how the C programming language deals with special variables that can hold memory addresses. These variables are called pointers and are an integral part of the syntax and functionality of the language. BASIC did have a few special functions which could accept and address locations in memory – I’m thinking of the CALL and USR functions specifically, although there were others. However, a variable holding an address was the same as one holding any other number since BASIC lacked the concept of strong types. The grammar of the C language is also much more complex than BASIC; it had special characters and symbols to express program scope and perform unary operations, which introduced me to the concept of coding style. When a programmer first learns a particular style of coding, it can turn into a religion, but I hadn’t really been exposed to the language long enough to form an opinion. That would come later, and then be summarily discarded once I had more experience.

There were libraries of all sorts which provided functionality for working with strings, math functions, standard input and output, file functions, and so on. At the time, I thought C’s handling of strings (character data) was incredibly obtuse. Basically, I thought the need to manage memory was a complete nuisance. BASIC never required me to free strings after I had declared them, it just took care of it for me under the hood. Despite the coddling I received, I was familiar with the concept of array allocations since even BASIC had the DIM command which dimensioned array containers; re-allocation was also somewhat familiar because of REDIM. However, there were many more functions and parameters in C related to memory management, and I just thought the whole bloody thing was a real mess. The differences between heap and stack memory confused me for a while.

There were many features of the language and compiler I did enjoy, of course. Smaller and snappier programs were a huge benefit to the somewhat sluggish software produced by the QuickBASIC compiler and the BASIC interpreter. The compiled C programs didn’t have dependencies on any run-time libraries either, even though there was probably a way to statically link the QuickBASIC modules together. Pointers were powerful and were loads of fun to use in your programs, especially once I learned the addresses for video memory which introduced me to concepts like double buffering when I began learning about animation. Writing directly to video memory sounds pretty trivial to me right now, but it was so intoxicating at the time. I was more involved in game programming by then and these techniques allowed me to expand into areas I never considered. It allowed for flicker-free animation, lightning fast ASCII/ANSI window renderings via my custom text windowing library, and special off-screen manipulations that allowed me to easily zip buffers around on the screen. A number of interesting text rendering concepts came from a book entitled Teach Yourself Advanced C in 21 Days by Bradley L. Jones, which is still worth reading to this day.

At around this time, I also started to learn about serial and network communications. The latter didn’t happen until my last year at high school. Basically, I wanted to learn how to get my computers to talk to one another. It all started when I became enchanted by the id Software game called DOOM, which allowed you to network a few machines together and play against each other in a vicious winner takes all death-match style combat. Incidentally, games like Doom, Wolfenstein 3D, or Blake Stone: Aliens of Gold led me down another long-winding path: 3D graphics, but that didn’t happen until a few months later. Again, the book store came to the rescue by providing me with a book entitled C Programmer’s Guide to Serial Communications by Joe Campbell. I was somewhat familiar with programming simple software which could use a MODEM for communication, since BASIC supported this functionality through the OPEN function, but I knew very little about the specifics. Once I dug into the first few chapters, I knew that was all going to change.

Dissecting DOSBox

December 20, 2010

If you’re a gamer and have been for years, then you’ve probably heard of and quite possibly used DOSBox. If you haven’t, then let me introduce it to you. DOSBox is great little program for running all of your favorite classic games. Games which were originally built for monitors and video cards which since been retired, and legacy audio systems like SoundBlaster 16, Audio Galaxy, or Gravis Ultrasound. Specifically, it supports games and programs which were written for the MS-DOS or compatible operating system. Although, the software specializes in supporting games, you may have success in running other programs. Although it doesn’t make any guarantees regarding these legacy applications, which can require different features provided by unsupported drivers, I have had success in running complex software like the DJGPP compiler but run into a bit of trouble when running an older version of the TDE (Thomson-Davis Editor).

I’ll wait here while you go and download your copy of the source code…

Now that you’ve downloaded DOSBox source and presumably unpacked it, you are ready to get your hands dirty. This isn’t going to be an article about how to use DOSBox, but rather, how does it work under the hood, exactly? What are the major software gears and wheels used for handling such programs? Why don’t all of your favourite games have 100% compatibility?

The first thing to understand about DOSBox is that it’s an emulator for x86 CPU instructions, floating point unit instructions, and various functions within MS-DOS compatible operating systems. Specifically, it emulates functions around Interrupt 21H (hexadecimal) and a couple around 20H, 25H, 26H, and 27H. It also installs an NULL handler for interrupts 28H and 29H which do nothing. But before we get ahead of ourselves, let’s take a step back and look at the various modules that make up the program.

CPU Emulation. At the heart of any emulation program is the CPU emulation core. Every program (.EXE or .COM file) on your DOS powered computer contains machine code and data. When using DOSBox, it’s the CPU emulator’s job to process that machine code; therefore, each program that is teased apart and executed by DOSBox arrives at this sacred chunk of memory sooner or later.

DOSBox can be configured to emulate the x86 core in a few different ways. Therefore, when we talk about emulation for CPU cores, we’re either talking about emulating each instruction found in the program one at a time, or the emulator will choose to batch process these instructions and operands and translate them to native instructions for direct execution on the host CPU (they call this mode ‘dynamic’). This direct execution mode can provide into better performance on some machines, but may be slower on others so the original emulation mode is still available.

Emulation can be a little confusing if you’ve never heard of it before, so let’s go over it once again. An executable program contains a bunch or binary data representing machine operation codes (or op codes), operands (arguments to that opcode), and data. This information can be fed to your CPU by your operating system, or they can be read by another program, just like any other file, and interpreted one byte at a time. In the last case, it would be the emulation program which decides how to implement the functionality of the CMPSB instruction (used for comparing bytes in memory), for example, rather than the CPU providing the hardware implementation. It’s this act of interpretation that differentiates emulation from direct execution on the host processor.

FPU emulation. In the world of electronic gaming, the software powering those fantastic explosions, shattering those fragile glass windows, and hurling those flying projectiles often need to do a series of calculations to determine values for acceleration, direction, and manipulating various bits of trigonometry. These calculations can involve irrational numbers like PI (3.141592654…), which I’m sure you all remember from school. In programming terms, these numbers are often stored in variables which follow a standard method of encoding the information about the significand and the exponent (along with the sign of the number); one such standard is IEEE 754. Let’s not get too mired in the intricacies of how floating points are stored, which is quite boring after all and not conducive to an interesting read on a Friday afternoon. Instead, let’s evade this topic and push on to describing operation codes in which floating point numbers are used as operands (parameters or arguments to a function). In this case, these op codes may need to be emulated just like the ones used by the CPU. Only this time, if the encoding standard differs from the host processor (in other words, if it doesn’t use IEEE 754 and you’re using a PC to run DOSBox), then the emulator will need to convert that format into something it can use natively, which an expensive operation (in terms of adding processing cycles and increasing execution time).

The take away piece of information for all this is that floating point emulation can be slow in the worst case scenario, and fast in the best case. In either case, it’s not a good topic at parties so let’s just slowly walk away from it…

Hardware emulation. This is certainly one of the more interesting layers in DOSBox and also the most prone to hacks and tweaks within the source code. The science of taking an analog output and reproducing it digitally is prone to approximations, since the nature of analog is approximate and being digital is exactly the opposite. Most of the analog operations come from sound cards where the device is capable of producing a variety of analog wave forms which is used to create music and sound effects.

The operating system layer. Before the days of operating systems employing graphical user interfaces to shield the user from arcane console commands, and providing a host of time wasting games like Solitaire and Mind-sweeper, a sizable chunk of the PC market used DOS. Whether that was PC-DOS, MS-DOS, or DR-DOS is not really that important since the other versions typically remained closely compatible with MS-DOS. The DOS platform offered a host of utility programs to the user, along with a few drivers which included support for specific implementations for memory management, mouse drivers, and access to generic CD-ROM drives. Users could always install a specific version of a driver for piece of hardware they bought, like a Sound Blaster card, and after setting a jumper of two to configure interrupt and DMA channels, they would be off to the races. Unless something went horribly wrong…

Unbeknownst to many users but knownst to a few geeks around the Megaverse, the motherboard BIOS code provides a set of default drivers so that the boot sequence and the operating system can access a few essential devices like the hard drive, floppy drive, and keyboard when they start up. These drivers are usually ignored or replaced by the operating system so that it can provide its own, more advanced versions, but some of them are still used when your Windows operating system boots into safe mode, for example. The kernel, which is a core component of any operating system, provides mechanisms for switching between drives, accessing disks and partitions, and in the case of DOS, providing fixed names for devices like “LPT1:” (printer), “COM1:” (communications port), or “NUL:” (the abyss). These device names and indeed the drivers themselves provided a level of abstraction for the user and higher-level programs. The user could print a text file, for example, by issuing a command like “TYPE FILE.TXT > LPT1:” directly as a shell command, but they could also use a program like WordPerfect which has its own set of specialized printer drivers, so that it could do more tasks requiring advanced printing like graphics and italicized or bold lettered text.

DOSBox provides limited support for a few of these commands, but really it’s only enough to get your games up and running since that is its modus operandi after all. These commands can take one of two forms: an executable program or a keyword command available in the shell. I provide the list of available keyword commands in the Shell section below.

The interrupt layer. Much of the hard work when creating DOSBox probably rose up from the requirements around the CPU/FPU emulation, DOS and hardware abstraction support, and the support for interrupts. The bulk of the core system code for the DOS lies in supporting the features for every required interrupt function. Interrupts are specific routines which can accept parameters from the calling program and then return the results of the function in special variables. All of this happens by loading up certain register variables and invoking the interrupt CPU instruction. If you were to embed a small assembler routine into a C function, it may look like this:

void mouse_hide(void)
   asm {
      mov ax,02h;
      int 33h;

In this example, the value “02H” is being loaded into the AX register which represents the interrupt function to hide the mouse cursor, and the interrupt “33H” is an entry in the interrupt vector table to access available mouse functions (it acts like and index). DOSBox supports many interrupt functions, but their focus is around the ones necessary to run your favourite games. The important thing to remember about interrupts is that they do exactly that, they interrupt the CPU and force it to run the requested function.

Without going into too many technical details, interrupt authors generally follow two design rules: the functions must execute quickly and you shouldn’t call an interrupt from within another interrupt. The programmers working on DOSBox need to implement those interrupt functions in whatever way makes the most amount of sense on the running platform. So, if the game invokes an interrupt requesting a change of screen resolution and color mode, then the DOSBox emulator needs to adjust the resolution of the game window and invoke software support for VGA and EGA video modes, or a nice CGA video mode with a four-colour palette. Pretty.

The abstract front-end layer. This would be the charming side of DOSBox, if the project actually provided a graphical user interface out of the box. Instead, they have designed it one level deeper and abstracted the program’s front-end so that it could use different media and windowing libraries provided by the host’s operating system. By default, it uses the SDL library (SDL stands for Simple DirectMedia Layer) to handle the creation of the application container, window frame, sound, input functions and graphics modes. And lucky for them, SDL is available for Linux, Mac OS X, and Windows (and varied support for other platforms too), so there may never be a reason to move to a different library… until the SDL project is retired or if their senior programmer gets hit by a bus. If the project didn’t use a library like SDL, then the application would be tied to a specific set of operating system libraries, or it would need to provide an assortment of implementation modules for each OS target that followed a nice, clean little interface… like the ones provided by SDL.

I’ll pause while you give a big hug to the people working on that project. Don’t you feel better now? Wait, it wouldn’t be right to ignore DOSBox, since they are the stars of this little side show. Let’s spread the love around and try not to get too messy in the process.

The scaler layer. Strictly speaking, I wouldn’t really call this a layer, but the architecture does abstract it somewhat, and a lot of people like this feature so it’s worth discussing it a bit. When you decide to fire your favourite game up in DOSBox, you may notice the Window it creates is a little on the small side depending on your host’s current resolution. Wouldn’t it be nice if you could make the window bigger and still have it look good? That’s the job for the scaling routines. They take what would normally be a pixelated image (assuming you don’t like that sort of thing) and smooth out some of the rough spots. As with most scaling routines (other than piecewise-constant algorithms like nearest neighbour), there can be a bit of blurring but if the algorithms use a smaller set of surrounding pixels for their sample set, like an EPX or Scale2x routine then the result looks quite good and still maintains an acceptable level of sharpness and detail.

The shell layer. The shell provides a sub-set of the total native keyword commands available to DOS: DIR, CHDIR, ATTRIB, CALL, CD, CHOICE, CLS, COPY, DEL, DELETE, ERASE, ECHO, EXIT, GOTO, HELP, IF, LOADHIGH, LH, MKDIR, MD, PATH, PAUSE, RMDIR, RD, REM, RENAME, REN, SET, SHIFT, SUBST, TYPE, and VER. It also provides an execution environment for running batch files.

Hopefully, when you fire up your next DOSBox powered game (a number of product use this software, including game services like Steam), you’ll think of the long hours and tedious bits of programming that went into developing this stellar product, and maybe choose to send a bit more love their way this Christmas season.

Black Art of 3D Game Programming

September 20, 2009

Black Art of 3D Game Programming So you’re an aspiring game writer, now what are you going to do about it? You could get a job as a summer intern at a local game company and work for free doing all sorts of tedious tasks no one else wants to do. Or you could hit eBay and do yourself a huge favor and find this text. Before you write back about the publication date, yes it was published in 1995. No, it does not talk about OpenGL or DirectX. Phew, now that we have that out of the way, let’s talk about what this book can teach you.

This book’s greatest strength is how it dabbles in a number of good topics without being totally useless. A number of texts provide a lot of information about too many topics, while not providing enough material to do something fun or useful. That exercise is often left to the reader. Ha! A book like that in my house will pay a little visit to the recycling bin or get banished to the library, never to be read again. Other books tend to steam roll over you with too much theory of the mathematical kind. While I’m all for roots and quadratics, aspiring young programmers wanting the enter the field of game development shouldn’t necessarily want to go whole hog on their first book.

That being said, they will need some basic skills to get started, and matrix math is a fundamental skill for playing around in 3D. Fortunately for the junior programmer, it’s not the most difficult skill to learn. One of the black arts the book teaches you is how to master 2D and 3D transformations using matrix algebra. It doesn’t go into quaternions for gimble-lock free rotations, but since the reader is probably just starting out, it doesn’t really matter either. They will be able to make do without all of the fancy topics getting in the way of actually learning something useful.

The book does show its age in some chapters where the topic of conversation is how to take control of various video modes, but I think it’s still a worth while read. You can still do this kind of programming if your recreational operating system of choice is FreeDOS or some other version of DOS, even on a modern PC. You could even use Windows 95 or 98 for that matter, just get it to boot using the version of DOS which ships with all of that GUI crap. Trust me, you’ll be better off in the long run, plus you can wow your friends with your amazing latch register skillz.

DOOM II: Let the obsession begin. Again.

December 23, 2008

[Taken from the back of the box]

The wait is over. In your hot little hands, you hold the biggest, baddest Doom ever – DOOM II: Hell on Earth!┬áThis time, the entire forces of the netherworld have overrun Earth. To save her, you must descend into the stygian depths of Hell itself!

Battle mightier, nastier, deadlier demons and monsters. Use more powerful weapons. Survive more mind-blowing explosions and more of the bloodiest, fiercest, most awesome blastfest ever!

The 3-D modeling and texture bit-mapping technologies push the envelope out to the max. The graphics, animation, sound effects and gameplay are so virtually realistic, they’re unbelievable!

Play DOOM II solo, with two people over a modem, or with up to four players over a LAN (supporting IPX protocol). No matter which way you choose, get ready for adrenaline-pumping, action-packed excitement that’s sure to give your heart a real workout.

It must be tough to keep reading – what with your hands trembling in shear anticipation. So we’ll stop talking now to let you take this box to the counter.

DOOM II. It’s time to get obsessed again.


July 18, 2008

There are two ways to render graphics in DOS. The first involves setting the desired graphics mode and then drawing pixels on the screen via the BIOS or writing directly to video memory (an interesting topic by itself); the second method involves staying in text mode and drawing pictures with the standard set of ASCII or IBM’s Extended ASCII characters (thanks to Telecom Corner for the chart).


While scripting batch files, you can also make use of ANSI escape sequences to control the cursor, display coloured or blinking text, etc. In case your interested, DOS requires an ANSI driver in order to translate these escape sequences. These escape sequences are non-intuitive and look something like this:


Ahh. Isn’t it cute? Many people have been discreetly killed for creating less offensive syntax than that. In addition to the regular set of ASCII characters which can be used in creative and artistic ways to produce a recognizable picture, using the set of extended ASCII characters provides an easy way to draw connected lines within the grid of displayable characters. When creating your picture keep in mind the screen size, since this is dependent on the video mode (some video modes can display more rows and columns).

TheDRAW Title ScreenTheDRAW was written by Ian E. Davis and was last released in October of 1993. It is a program which allows you to paint a picture or create an animation using these special characters and ANSI attributes. It’s not like painting individual pixels, you are limited by the set of characters available. However, this hasn’t stopped ASCII artists from creating fantastic content. The most stunning examples I found were on Bulletin Board Systems. They were often themed according to design of the on-line system. Using TheDRAW, these pictures could be exported as ANSI-compliant or ASCII text files, or as header files to be used in other programming languages. There are a number of small tools available for translating these files into other formats used by other languages.

TheDRAW package is bundled with a utility called TheGrab which can take an screen shot of a running program. It’s not your typical screen shot utility which takes snap shots of any graphics screen. This program works only for text mode screens and will output a file in ANSI, ASCII, COM, or TheDRAW format files. Be wary of using this memory resident utility under DOSBox 0.72 as it will crash and force you to end your session.

Last but not least, TheDRAW package is bundled with a utility for creating your own fonts to be used in TheDRAW paint program. This is without a doubt one of my favourite features and makes creating screens a breeze. There are many fonts available in the wide, wide world so have fun.

All of these features are thuroughly explained in the documentation and in-program help. Many of my programs took on a more professional and fun look because of this drawing tool; although I think I went overboard in some cases. I still find it the best tool available for doing this sort of work in DOS, although I’m sure many of you may prefer other software such as AcidDRAW.

Vinyl Goddess on YouTube

May 12, 2008

If you’ve been wondering how to get all those bonuses, or if you’ve been itching to try the game but would like a little demo first, check it out in all its poorly encoded glory. I just positively love the music in this game; I should make a CD or something…

Building Software with DOSBox?

DOSBox LogoI have written about DOSBox in the past and I have nothing but good things to say about it. It’s a great project whose people continue to push for greater compatibility, speed and functionality. Over the weekend, I tried to use DOSBox as a development environment for compiling DOS applications using the DJGPP 32-bit compiler and associated development suite such as RHIDE, Allegro, GRX libraries, etc.

Sadly, it didn’t work out so well since a number of common tools simply didn’t function that well in v0.72. I’m not terribly disappointed, since the emulator takes forever to compile a project in its environment, and wouldn’t be suiteable for long term development. I’m raising the issues here in case anyone tries to use DOSBox in the same way.

First, let’s talk about what did work. DJGPP for starters. It works just fine; albeit, the compilation and linking process does take a while. Some might argue that this is all you need to develop a project, and while that might technically be true, it certainly doesn’t work out for anyone trying build something more than a “Hello World!” application.

So, what didn’t work? Well, I tried four different editors: edit (the one which ships with your MS-DOS operating system), TDE (Thomson-Davis Editor – one of my favourites), MEL (Multi-Edit Lite – another great little editor), and RHIDE (the development environment which you can install alongside DJGPP). I didn’t try VI/VIM, but I might sometime later just because I’m curious.

First out of the gates, Edit simply wasn’t suitable in an environment where tab characters are important. It simply replaces them with spaces and continues on its way. Too bad since the editor is simple and to the point. Although, it really isn’t a good solution since it lacks one of the most basic development features like syntax highlighting.

DJGPP makefiles will not tolerate spaces when there should be tab characters. No, it’s not being quirky, it’s in the POSIX standard after all but it doesn’t make it any less annoying. So, the solution is to switch to an editor which respects tab characters and does not try to convert them to nasty spaces. So I jumped to a more sophisticated editor: TDE. Sadly, I was let down again, due to a bug (could be within TDE or DOSBox) where the cursor was not visible while using the editor. It was a little like fumbling in the dark trying to find that blasted light switch.

After some research I found MEL, so I installed it and tried it out. The editor was well laid out, the cursor showed up, and it respected my tab characters. Super, finally something I can use! Alas, I soon discovered that our relationship would never last. You see, MEL doesn’t use tab characters out of the box, you need to turn it on through one of the configuration dialogs. No problem, right? Well, it doesn’t seem to remember the setting once you save it, so you need to set it every… single… time you load the editor. Hrrmph.

“Well, it’s time to bring out the big guns!” I thought. I had used RHIDE in previous development projects and found the environment quite enjoyable for the larger ones. I typed in the command to fire it up and… whammo! Congratulations, it’s a bouncing baby SEGFAULT. Sigh. I don’t know about you, but four editors is enough experimentation for one day. If you find an editor which works well and meets my humble requirements, please post it in the comments.

Anything missing which should be added? Well, you’ll certainly want to add in some basic DOS utilities such as XCOPY, DELTREE, ATTRIB, and what not. It will make your life much easier. It would also be great for DOSBox to incorporate a configuration reload command, so you don’t need to exit the emulator in order to reload the preferences file. For now, I’m going to use one of my older development boxes for this software project, and stick with DOSBox to run my games.

TheDraw for DOS

March 10, 2008

There are two ways to display graphics in DOS. The first involves getting out of text mode and setting the desired graphics mode and then drawing pixels on the screen via the BIOS or writing directly to video memory; the second method involves drawing with the set of ASCII or extended ASCII characters. You can also make use of ANSI escape sequences to control the cursor, display coloured or blinking text, etc. DOS requires an ANSI driver in order to translate these escape sequences. These character codes are non-intuitive and look something like this: ESC[=5;7h. I swear my cat coughed up a fur ball which looked exactly like that the other day.

The set of extended ASCII characters provides an easy way to draw connected lines within the grid of displayable characters. This grid changes in size depending on the video mode set. With the default video mode in DOS, the dimensions of this grid is usually 80 characters wide by 25 characters high and covers the entire screen. Naturally, these characters can be connected to form anything from boxes to mazes. It’s how all those menus and dialogs are drawn when using a program like QBasic.

TheDRAW is a program which allows you to paint a picture using a variety of special characters. It’s not like painting individual pixels, you are limited by the set of characters available. However, this hasn’t stopped ASCII artists from creating fantastic content. The most stunning examples I found were on Bulletin Board Systems which used them to attract new and repeat visitors alike. The ANSI art found on those systems were often themed according to design of the on-line system or the whim of the system operator. Using TheDRAW, these pictures could be exported as ANSI-compliant or ASCII text files, or as header files to be used in other programming languages. There are a number of small tools available for translating these files into other formats used by other programming languages.

ANSI art drawn using the TheDRAW

Many of my programs in QuickBasic took on a more professional and uniform look because of this spectacular drawing tool. I still find it the best tool available for doing this sort of work in DOS, although I’m sure many of you may prefer other programs.

When I began to write software using The C Programming Language, I used TheDRAW to create a title screen in a number of small programs (the concept of a splash screen hadn’t been introduced yet). Although most dialogs and windows I used were crafted in code using a custom built user interface library, the more complex dialogs were created using this application. To allow for input or interaction, the fields were marked by a special character, followed by a small series of alpha-numeric characters. These markers would be found by the interface library and the characters following the marker would correspond to a header file which linked the “names” to constants and then to user interface controls and data structures.

The output from TheDRAW was compressed and archived in a separate resource file to keep them from being easily pillaged by unworthy scavengers. I’m not an artist so it may have been overkill.


November 27, 2007

MS-DOS LogoDespite Tandy’s DeskMate application which tried to handle a number of disk and application related functions, MS-DOS (Microsoft Disk Operating System) was the actual operating system on which Deskmate needed to operate. I had experience with an earlier version of Microsoft’s DOS which I used at school; I believe the versions were 2.0 and 1.25. Unlike today where hard drives are common place and often taken for granted, the machines in the lab could only boot by way of 5 1/4″ floppy diskettes which contained the operating system. I believe the Tandy computer came with MS-DOS 3.42 and it was pre-installed on the hard drive. This was so much better than booting from a floppy, and I quickly assimilated as many commands as I could, since the school never gave me the time I wanted on the machine or the resources. Even with the aid of a text book, there were a few commands which took me a while to grasp, like COMMAND.COM or DEBUG.COM. My understanding of these wouldn’t completely solidify until I started programming in lower level languages like C and assembly language. I was also introduced to Microsoft’s shell scripts which they called Batch files. With the addition of extra software on the system, these scripts could actually become fairly sophisticated. Before I moved on to greener pastures and more flexible user interfaces, my system had sophisticated menus and launchers which helped my family out when they wanted to use the machine (it wasn’t often, but it did happen).

Version 5 was a much more refined operating system and contained powerful commands and programs like QBasic. It also featured a memory manager which allowed software to access all of that wonderful new memory that you may have been fortunate enough to acquire. Although it was included in MS-DOS Version 4, I believe the DOSSHELL command’s popularity spiked in Version 5. This was a program which was intended as a graphical replacement to the dull COMMAND.COM shell. It introduced a feature called task swapping which allowed you to load more than one program but only run one of them at a time; unlike multitasking which appears to run more than one program at the same time. Also, DOSSHELL could not load more programs than your memory would allow since it did not have a paging mechanism. Naturally, all of these benefits conflicted with the new versions of Windows which did exactly the same thing only better, and was soon relegated to a supplemental disk in future releases before being dropped entirely.

Version 6 introduced the much feared DELTREE command. DELTREE was a command which could recursively remove directories and files; it was so feared because new or untrained users would presumably delete their entire operating system accidently. If this was indeed a problem, I think they should have modified the program to make it more difficult to accidently trash your operating system by adding extra prompts and warnings for example, since it is a very useful command in some circumstances. Despite its notoriety, it was a fairly simple command as far as software goes, and the void was soon filled by programmers who released new versions on the Internet which did exactly the same thing only better; I wrote a utility to replace it as well but mine displayed a user interface if you specified the right command option.

Microsoft LAN Manager

July 25, 2007

After I had finished assembling my RetroBox, I was forced to to make a decision on what operating system to use. I chose to go with Windows 98 because I needed to be able to access my network. I also wanted to be able to boot into a DOS shell, but I didn’t want to dual-boot the machine. By writing a few options into the CONFIG.SYS and AUTOEXEC.BAT files, the user is presented with a small set of choices which may drop them into the shell. When I need to access files on my network or if I want to print something, I choose an option which boots me into Windows. My RetroBox is not a terribly fast beast, and it takes a while to boot and log-in.

To help alleviate this problem, I installed Microsoft LAN Manager in my DOS environment. Now I can access my network files and print through the network with ease. The process was a little frustrating and your experience may vary. I am providing this information, just in case you’re considering tossing the whole project and moving to Tibet to become a monk (if you’re already a monk living in Tibet, then you may be considering moving to Canada to become a Mountie).

The very first step would be to obtain a network card. For compatibility reasons, a popular 10/100 Mb card would be optimal. I have compiled a list of network card drivers which are bundled with Microsoft LAN Manager (which I will now be calling LAN Man to save some typing). Even if your network card is not on the list (mine wasn’t), you may still be able to obtain a driver from the company’s web site. My card is a D-Link “DFE-538TX Rev. D” and the earliest driver posted on the website was for Windows 98. After decompressing the file, however, I found a driver specifically for LAN Man which saved me from having to create a custom NIF file. I will explain how LAN Man uses these files a little later.

Once the physical card is installed, unpack your installation and run SETUP.EXE to get started. For many people, the setup process should be pain-free. My setup was not so problem free, however. I suppose it was due to the fact that I was running the Windows 98 shell, and not a pure MS-DOS, PC-DOS, or FreeDOS installation. I believe the root of the problem stemmed from the fact that the Windows 98 shell doesn’t like the ‘$’ wildcard. If you take a look at the SETUP.INF file, you’ll notice a number of files ending in the dollar sign. Within the file, a program like NetBEUI would be referenced like this:


Under MS-DOS, this would match the file NETBEUI.EX_. Under the Windows 98 shell, it does not seem to match it at all, so the installer complains that it cannot find the file. What I did to correct this problem was to simply change the wildcard to the ‘_’ character and presto! The installer was able to see the file and continue with the installation.

Because my card was not on the list of available drivers, I needed to add it to the list myself, which meant making an entry in the SETUP.INF file so it could find the driver files (<DRIVER NAME>.DOS and PROTOCOL.INI) and the Network Information File (NIF). After making an additional entry in the SETUP.INF file and copying the files to the right locations (under DRIVERS\ETHERNET), the setup program correctly enumerated the card name and I was able to select it from the installation menu.

After these changes, the install carried on happily, but complained at the very end that it could not find the “NETWKSTA.” file. There is no “NETWKSTA” file; it’s just a directory. This is the eight-character directory shorthand for Network Work Station. I don’t know why it was complaining, but it’s an important program and needs to be installed so you can use network resources like shared files and printers. This is also easily corrected after completing the installation. Just copy the file:


Don’t copy it from the CD-ROM, because that file is compressed and won’t run. That file will end in an underscore, so it won’t match the name I listed above.

During the network setup portion of the installer, if you choose to use DHCP then you don’t need to specify an IP address or sub-net mask. For log-in credentials, just supply a user name without a password if you don’t have an MS LAN Manager or Windows NT authentication service setup. When it asks you for a domain name and you don’t know what that means, just enter in a dummy name or leave it blank (I didn’t try leaving it blank, the installer may refuse to continue). One item to keep in mind: a Windows domain is not the same thing as a work-group, but I used my work-group name anyway since I knew it wouldn’t matter. Eventually, if I choose to setup a domain, I will change the domain name at that time.

After moving the commands inserted into my CONFIG.SYS and AUTOEXEC.BAT files around to suit my own taste, I rebooted the machine and ran the NET.EXE program. Using this software, I could enter the UNC path to one of my machines:


Go to the view menu and select “View available network resources”. It will present you with a dialog which will allow you to assign a shared folder to a local resource like a drive letter. I was able to read and write (provided the permissions are set appropriately on the share) to the folder using the new drive letter (F: in this case).

Please note: you won’t be able to mount a printer or a shared folder if the share name is greater than eight characters! It will simply complain that it cannot find the network resource.