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 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
#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.
maybe it will be easier to start over from scratch
as we're fond of saying on my on my architecture team when folks try to fix application problems with more hardware... "$$$ will buy a lot of developement."
I guess in this case, "4000 windows licenses would buy a lot of nice OSS code." =]
"Karma can only be portioned out by the cosmos." -- Homer Simpson
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.
Short answer: No.
Longer answer:
In DOS, you have full access to the hardware. This means that you read and write registers and I/O ports directly. Many DOS apps wrote directly to video memory for example. Most programmers did this for performance reasons, AND that it was easier.
For example: Let's say you had a form onscreen to fill out. What you did was use a ASCII screen designer tool that allowed you to play with all the attributes, and dump the contents of that to a file. This file could be included with your app (in a header file) or loaded from disk at runtime. Of course there were many other ways of doing this.
Since this guy uses a modem, he probably purchased one of the communication libraries that had x/y/zmodem, etc. and handled all the ideosyncracies of the 8250/16550 comm chips.
You also had to play lots of tricks if you wanted to access memory above 640K - you needed to run something like a DOS extender (PharLap comes to mind.)
So, no. It's not just a recompile. It's a port.
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
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!