Interview: James MacLean
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 firstname.lastname@example.org.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
3 hours 45 min ago
- Nice article, thanks for the
14 hours 25 min ago
- I once had a better way I
20 hours 11 min ago
- Not only you I too assumed
20 hours 29 min ago
- another very interesting
22 hours 22 min ago
- Reply to comment | Linux Journal
1 day 15 min ago
- Reply to comment | Linux Journal
1 day 7 hours ago
- Reply to comment | Linux Journal
1 day 7 hours ago
- Favorite (and easily brute-forced) pw's
1 day 9 hours ago
- Have you tried Boxen? It's a
1 day 15 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?