Interview: James MacLean

In this interview, Linux Journal talks with James Maclean, of Nova Scotia, Canada, who is the current leader of the DOSEMU team.

Linux Journal: Tell us a little bit about DOSEMU...

James: The DOS Emulator for Linux started a few years ago when Matthias Lautner created an application for Linux that could load DOS from a diskette and then accomplish some rudimentary DOS commands. At that time I could remember getting one editor to run sometimes and other DOS programs to give signs of starting but crashing the application. All in all, very impressive to me.

Then Robert Sanders jumped in, and in what seemed to be a very short time, had coordinated and expended enough effort to make DOSEMU begin supporting much of the necessary low-level emulation that DOS programs expected.

Since then a group of about a dozen of us have taken on the challenge of furthering DOSEMU's DOS compatibilty, and increasing its performance. To date, we can run quite a gauntlet of DOS applications ranging from wordprocessors to database packages, from graphics packages (now including Windows 3.0 to a point) to even some games (albeit slowly).

Linux Journal: Tell us a little bit about yourself...

James: My first exposure to computers was around grade 9 when my folks bought a Texas Instruments 99/4a. I was quickly impressed by how my disorganized mind could write BASIC code that looked quite organized to the end user. So naturally I started creating games, and actually sold a few. My most memorable one being 'Oil Suckers'. Of course I knew then what I wanted in a career :-). In time I learned how to program that computer from the machine code up, and always dreamed of creating my own multi-tasking operating system after seeing how much of the computer's time was being wasted. (So naturally I envy Linus, and I hope he doesn't mind that there are those of us that live vicariously through him :-).)

Then came university, where I actually lost part of my ambition to go on with computers. Luckily in the year I graduated I started a job as an opertator for the provincial government's data center which was an IBM 3090 MVS/JES3 shop. From being amazed at the power of the mainframe, I started again quickly learning as much as I could about the system I had to make use of. It was due to this interest and growing knowledge base that I soon was given the nickname JES.

Then my job moved here to the Department of Education where I am a one-man team looking after in-house matters for our division. This was my first time to actually use a PC, and again I found it limiting to only be capable of running one program at a time (DOS). Later on our M.I.S. coordinator started a pilot project to see if the Internet would be of any benefit to the department. Luckily at the time I mentioned my interest in getting back to Unix, which was what we had in University, and he mentioned that Byte magazine had the ftp location of a free Unix-like OS called Linux. From there to here has been a fun roller coaster ride of running a powerful OS, being a coordinator of one project for it, and learning more than enough new stuff everyday.

Linux Journal: What got you interested in DOSEMU?

James: Once I had Linux up, I realized that our department (and myself) used many DOS-based programs. I had been running OS/2 2.0 on a 4MB system, and felt some of my DOS applications should be able to run under Linux. I heard about this DOSEMU app that was suposedly fairly primitive, but could do some things. I guess after I ran it, I realized how much I didn't know about Unix, and decided to hover around listening to what progress was made, if any, to DOSEMU.

Then Robert came along, and suddenly many of my DOS applications were either running, or almost running. This drove me to start tinkering with the code, passing some of my changes along to Robert, and finally coordinating the project.

Linux Journal: What is your technical background?

James: Well, I have a BSc. with a major in Computer Science, but I feel my real background comes from the experiences I have had; from programming the TI, to automating procedures for the IBM 3090, to taking long, hard looks at the internals of both DOS and PC's. I've programed in a multitude of languages (haven't we all :-)), and seem to be getting a good grasp of Unix from the inside out. I'm capable of discussing TCP/IP and Novell at the administrator level, and more and more on the technical level, but have yet to program at the network level, unless you count some small scripts in PERL.

Linux Journal: What interests you most about working with DOSEMU?

James: I think what interests me most about DOSEMU is the same thing that interests me most about Linux. The more I do with it, the more I realize what it can do. The source code is there, and the only limit seems to be time and imagination. I get a very rewarding feeling when something is added to DOSEMU that works and helps others out. Beyond any other OS to date, there really seems to be a sense of pride in running Linux, and for me, being a part of the DOSEMU team.

Linux Journal: Please tell us about some technical challenges that DOSEMU has presented, and how you solved them.

James: Technical challenges we've had many of, but the ones I can take credit for solving are few. One good example is our ability now to run graphics programs from within DOS on hardware that DOSEMU will support. We first set out to create our own routines to deal with saving and restoring all the necessary info for changing the video modes. Then Robert Sanders caught on to just calling the actual video bios already installed for each card, and using it. This little change made DOSEMU become much more functional, and no one had to code mode changes for each card.

We've also been attempting to create solid serial support for which I had a program that wouldn't even run correctly under OS/2's DOS. But with Mark Rejhon diligently scanning through kilobytes of my debug output, he was able to make this program run, as well as many others.

There was also the lack of support for FCB handling in the redirector. This was of course not documented anywhere, but I lucked into it when I decided to get a copy of Undocumented DOS 2. It had enough info to help me kludge in the additional code that allowed FCB using programs to run.

For me the most pleasurable one to fix was the stack-wrapping problem with many programs that start their stack at 0x0000 and of course wrap backwards (0xfffe). We always had many programs that didn't run, and I could never see anything in the debug listing to explain why. Then I got a small piece of code from a person who wondered why something would run only if compiled certain ways. With the code in hand, I started looking at it through debug and noticed that the program seemed to be running in reverse. Very strange, so I asked around and got some good ideas, but none panned out. Then when I was down to half as much hair as I used to have, I noticed that the stack didn't contain what was suposedly pushed on it. Suddenly it came to me, 0 - 2 <> 0xfffe when a linear address was made from the seg:off pair. Instead of wrapping at the offset, it was just subtracting two from the linear address. This little extra code enhancement started a multitude of programs running, none the least of which for me was Netware's lsl. Linus has made a much better set of functions for handling this scenario, and added them into the vm86 function of the kernel for us to use.

One of the most noticeable changes that has occurred lately is due to Lutz Molgedey. After some discussion had appeared about catching the signals DOSEMU uses at a lower (kernel) level, Lutz asked if it would be a worth-while task. I know quite honestly that I said something to the effect that I wasn't convinced about the speed improvement being that great, but if he wanted to try, go ahead and see what he comes up with. Shortly after, and very much to my surprise, he had made the necessary first layer of kernel changes, and DOSEMU started to run like a scalded cat. The increase in speed was enormous, and we all felt that it was worthwhile to give us a DOSEMU we would work with.

Linux Journal: What parts of DOSEMU do you like the most?

James: I find the redirector interesting because I can dynamically redirect anything Linux has for directories. The ability to connect to our Novell Server and also use Netware Lite has also made it much more functional for me. I would say though, from looking after the project, I am always impressed by the input I get from all over the earth, from ideas to patches, and the true enjoyment from sitting down every second Saturday on the #Ldosemu IRC channel to talk with folks that I share common interests with, no matter where in the world they harbour.

Linux Journal: What parts would you like to change?

James: I think we'd all agree the code still needs a bit of cleaning. The installation for the new user is still too raw, and should have possibly more documentation, or a front end to ask step-by-step installation questions. I'm hoping to see even better networking support like TCP/IP from within DOS using network cards known to Linux.

Linux Journal: Anything else you'd like to say?

James: I'd really like to say thank you to all those hackers that make up our DOSEMU team, as well as to everyone that has sent in patches, or just given suggestions along the way.

James B. MacLean can be reached via e-mail at jmaclean@fox.nstn.ns.ca.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState