Slashdot Mirror
Porting DOS Applications to Unix?
jgbustos asks: "I'm the manager of a small software development company. For the last five years we've been managing a communications network consisting of several thousand PC terminals which connects to an NT server over the phone lines. The terminals run a console application on a light DOS. Everything is fine so far. So what's the problem, then? We have a hard time finding parts to maintain the network. Our client says that he's willing to invest in hardware upgrades, but we should move to a Windows-like environment, however he doesn't want to pay for more than 4000 Windows licenses. What's the best alternative for porting our app to Linux/? Please bear in mind that the terminals are small PC's having 16MB RAM, less than 2GB HD, less than i586 CPU, and a 33k modem. Thanks in advance"
What do you mean - they just want a GUI?
In any case, I bet you could find a linux or BSD distro that runs small and runs a windowserver. Though you might just want to try and find a dedicated browser and go for a web solution. If the client can just dial up and PPP to you and fire up a browser, you don't even have to worry about distributing updates to your software - just updating the server.
Really, more info about the problem domain would help...
I'm now going to shove my foot in my mouth. There. Couldn't you pretty much just recompile?
Why not fork?
There are couple of tools for Linux that will run MS-DOS executables. One that comes to mind is dosexec. Although I've never had the need/desire to run MS-DOS programs under Linux so I can't tell you how well any of them work.
What exactly was the reason, again, that you have to upgrade to either linux or windows?
/EISA switch so it'll use upper memory on machines with more than 64MB of memory.
You're having a hard time finding 'parts'???
Go to your local computer store. If you need a motherboard, get a motherboard. If you need a processor, get a processor. Etc, etc, etc.
There are valid reasons to upgrade software, but hardware shouldn't be one of them.
I do the computer side of a small video chain. Each store has a novell server, and multiple dos workstations. I'd like to put it all on linux so the interoffice communication can all be done via tcp/ip with the modems. There are other reasons. Unfortunately the software we're using requires IPX for the hardware key, so that's impossible in my situation.
However, we're running 1.4GHz machines in some stores (ie, a $250 machine) as workstations with either a boot floppy or compactflash. There are no problems with running dos on these systems, except that we have to use DEVICE=HIMEM.SYS with the
So, tell us again why you can't find hardware for your current lite dos systems?
-Adam
If you have a terminal server, and export the display to every machine, that might work.
:P
You'll most definetly want to turn on compression.
You'll have to try it to see if it is usuable tho over such a slow modem.
As to porting the dos apps to it - depends on the dos app
I remember a program called DOSEMU for System V UNIXware. It worked well enough for me to run most DOS programs on my 386 running UNIXware. I would test the emulation layer first, and then look at making a custom linux image for the PC's. Something like Systemimager should work nicely for distributing the install.
So, do you want to port the app to a command-line form running on Linux on the current hardware? (0.02USD: ncurses, slackware) Or do you want to port the app to a GUI form running on Linux on newer hardware? (0.02USD: any number of toolkits, any number of distributions) Obviously as the second route is the greatest change, the variables are more numerous giving you a much wider of range of options to look at. I'm guessing your current programmers are C or Pascal folks? You might consider using GTK+ (GUI Lib written in C, also has bindings for FreePascal). As far as a linux distro for the more open-ended situation goes, I'd have to say debian. The install can be a bit of a pain for the uninitiated, but it more than pays back that annoyance after install becuase with the very intelligent package management system you can do stuff like point the terminals at a central server to pull updates from (e.g. roll your app in to a .deb, have terms auto-update once a week using a cron job, makes deploying patches and security updates easy as pie). Debian will also work in fairly constrained hardware environments like slackware, but it tends to be a beefier install usually.
News for Geeks in Austin, TX
Is there anything happening from the Terminals or are they just displaying information? Can you screen scrape your existing app, send it over the web, and then have all the wimpy boxes out there run Lynx/Lightweigh browser of your choice?
Open Source Identity Management: FreeIPA.org
#2. What's the DOS app, do you have source? What does the DOS app do?
#3. Why not just roll out replacement terminals as needed, instead of en-mass? You could probably use FreeDOS instead of MS-DOS, and set up a new machine ($200 walmart variety) to do exactly what you need.
Please... thats all we need is more DoS tools on Linux, so all the script kiddies can brag about how l33t they are...
Make the code their own DoS tools, like we did back in my day... in machine code
I assume by that you mean DOS disks/licenses? DOS runs just fine on modern hardware.
Anyway, there are alternatives to porting, such as using an emulator. DOSemu, DOSexec are names I've heard, or Wine would probably work too (but be a bit bulky). Or you could try FreeDOS, although modem drivers might be an issue.
If you're hell-bent on porting, though, there are a lot of variables involved that you haven't supplied us with. What language is the app written in, for example? Was it written with portability in mind, or is it dependent on proprietary libraries? What does it do, and are any OSS projects that do the same thing? Without that information, no one is going to be able to give you a real answer. Maybe it will work with just a recompile (have you tried that yet?), or maybe it will be easier to start over from scratch. No one can tell without info!
Why have there been so many "I want to port arbitrary software to Linux" questions with no accompanying details lately? How the hell is anybody supposed to answer these?
Under capitalism man exploits man. Under communism it's the other way around.
Try dosemu or wine and see if they run under one of them. It may be possible to switch to Linux first then port the apps to Linux. Also you could try using QT or Java, then you would not have to worry about 4000 windows.
Only 'flamers' flame!
with either new hardware + new Windows software or just new Linux software on the old hardware.
If that's the choice, go with Windows + new hardware, and warn the client that the bill will rise as you finish the migration. The Linux option has been painted into a no-win situation because software-only can't solve a hardware problem. This is reminiscent of the old OS/2 days, when it was roundly criticized for not running well in 4MB, and then they'd go off and buy 16MB to run Windows.
If you're serious about offering choices, prototype a Linux solution on one machine, so you can show the UI. A Windows prototype shouldn't be necessary, since everyone assumes it can be done. (I won't justify that assumption, but it's common.) Then put together a bill for both options with the full migration.
Then let the customer decide, and pay.
The living have better things to do than to continue hating the dead.
You should at least evaluate VMware workstation (free trial link: http://www.vmware.com/vmwarestore/newstore/wkst_ev al_login.jsp). You could move to Linux or Windows, run VMware, and run the app within a DOS virtual machine. Since you'd run the exact same app on (if you wish) the exact same version of DOS, you wouldn't have to worry about porting, compatibility, or hardware issues.
--JRZ
OTOH, if you wrote it in C, most of it is going to port right over, except for where you're doing hardware access. Some of THAT will port over too but no matter what you're not going to get out of rewriting your display code, since I'm guessing you're doing direct video access regardless of what language it's written in.
If you wrote it in C, you should have no problem provided you haven't forgotten how to write C. If it's written in assembler, you might be better off using it for a reference work and reimplementing it. In C :)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
We are porting specialists. We move anything to anything.
www.sector7.com
If tits were wings it'd be flying around.
Try FreeDOS (www.freedos.org) or DR-DOS (www.drdos.net). They are drop-in (more or less) replacements for MS-DOS.
Ok I am going out on a limb and guessing that you do NOT have the source code for this application, and that the original developer (the only guy on the planet that would actually understand the source code if it was available, which it isn't) isn't available to help you with this project.
If your client can't afford (doesn't want to pay for) seats of the operating system for new hardware, on top of the cost of 4,000 new systems, you absolutely positively cannot afford the cost of a custom developed solution that involves reverse engineering the DOS app and trying to code an identical app under *nix that still talks with your servers over IPX.
Custom development runs $400 a day on the extremely cheap side (you find contractors that know what they are doing for $50 an hour) to $1600+ a day for consulting firms to provide you with their staff.
Your best bet would be to find a bulk supplier of retired hardware - if you could get a truckload of 486 boxes with drivers and external modems (beware the WinModems) just buy them by the pound and use them with DOS and your apps.
Glonoinha the MebiByte Slayer
I can see some situations where that would be true, but it would not be the fault of DOS, other than the fact that it happened to be popular during the time when it was still practical to count clock cycles for operations. I use DOS on modern hardware regularly, with no issues, but I use a very narrow range of applications, some of which are even still maintained. Maybe there could be some problems with out of order execution, but I thought that OOO capable CPUs were supposed to be able to handle that gracefully.
Under capitalism man exploits man. Under communism it's the other way around.
The terminals run a console application on a light DOS. Everything is fine so far.
A "console application" connecting to a server via DOS? I bet his "console application" is a telnet client!
freedos is free. it's about 3mb, with all the options installed, and runs on current hardware, and supports neat things like USB and (i think TCP/IP). then you don't need to port anything, and it runs on current hardware (or, at least my 5 year old amd k6-2 300, so probably anything that supports x86)
if all you're doing is running a console app in dos, and your infrastructure is built around this, it seems far simpler to just go the way of freedos
moox. for a new generation.
You, as system supplier, have some sort of maintainance issue with the current set-up, the nature of which is not described in detail, unfortunately, but I can understand that identifying the particular application on /. may not be the best way of endearing yourself to the rest of your company and its current client, especially if, as it sounds, it's a custom implementation for that client. Meanwhile, the client is saying that if the setup is going to have to be be changed anyway, then they want to take the opportunity to upgrade the application and make it... what? Just prettier for the sake of it, or a more common PC-like look and feel so that there is less sniping from their customers about it being primitive and out-of-date? Or do they want added functionality as well? Are the existing central servers sacrosanct, or can that part of the app be adjusted, too?
I've got no concrete suggestions, but as this response indicates, I'd personally be inclined to sit down with the client and explore what they want and their reasons for it, and then, and only then, evaluate the approaches you collect.