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 email@example.com.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide