Porting DOS Applications to Unix? 61
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"
Should move to a windows like environmenet? (Score:5, Informative)
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...
Re:Should move to a windows like environmenet? (Score:2)
That said, I ported a rather large DOS based app to Linux a few years ago. This was one that used light-pens, touch screen, several industrial control I/O boards, network card, modem, etc. There were only 2 big issues I had.
First, I had to write custom drivers for the hardware. This really wasn't too hard actually, since I had already been directly accessing the hardware through an abstraction layer.
Second was screen I/O. Again, since I wrote everything through an abstraction layer, it really wasn't that big of an issue.
If I had NOT used abstraction, (hiding the details of the underlying hardware) it would have taken MUCH longer to port. The app was about 150K lines of code.
Re:Jhonny number 5 (Score:1)
Ok (Score:2, Funny)
Re:Ok (Score:3, Insightful)
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.
Re:Ok (Score:1)
(I do know how DOS works)
Re:Ok (Score:2)
damn, i'm a geek
Porting may be unnecessary (Score:2, Informative)
Eh...? (Score:2, Insightful)
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
Re:Eh...? (Score:1)
like, seriously
in regards to what appears to be your sig:
Linux has a zero price and x preformance, where X is dependant on your applicaton of linux, hardware, etc.
Windows has a X price and 0 preformance, where X is dependant on the vendor
so
Windows Price over Preformance: Error, Divide by 0
Re:Eh...? (Score:1)
So linux doesn't support that?
http://www.tldp.org/HOWTO/IPX-HOWTO.html
Re:Eh...? (Score:1)
Re:Eh...? (Score:2)
Furthermore, you're saying I could replace my novell server with linux, and use my hardware key which uses an NLM, which MARS does not support?
-Adam
I have never used IPX in my life (Score:1)
As to having IPX available to existing code within a dos emulator, probably not. Sorry. But if you can recreate the client in native code, you can talk to the server using the aforementioned guide.
LTSP (Score:2)
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
DOSEMU (Score:3, Informative)
Re:DOSEMU (Score:2)
Re:DOSEMU (Score:2)
You REALLY don't want to use such an ancient version of debian for a new project.
hmmm (Score:5, Informative)
Webify (Score:2)
too many open ends (Score:4, Insightful)
#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.
Windows emu (Score:1)
Porting (Score:3, Funny)
Make the code their own DoS tools, like we did back in my day... in machine code
Parts? (Score:3, Informative)
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?
Re:Parts? (Score:2, Informative)
Or you could try FreeDOS, although modem drivers might be an issue.
FreeDOS is ABI and API compatibilty with DOS. You should be able to use the same modem drivers you're using now.
Re:Parts? (Score:4, Insightful)
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." =]
Re:Parts? (Score:2)
Re:Parts? (Score:1)
Re:Parts? (Score:2)
Please mod my previous post as "-1 brainfart"
Re:IIRC some DOS apps don't like fast computers (Score:1)
Re:IIRC some DOS apps don't like fast computers (Score:2)
have you tried running them under wine or dosemu? (Score:2, Informative)
So you're solving a hardware problem... (Score:3, Insightful)
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.
svgalib (Score:1)
www.svgalib.org
no question (Score:1, Redundant)
VMware (Score:2)
--JRZ
Re:VMware (Score:1)
Cool program, though.
You haven't told us jack. (Score:2)
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 :)
Call the company that I work for (Score:4, Informative)
www.sector7.com
FreeDOS, DR-DOS (Score:2, Informative)
You can't afford the truth (Score:2, Insightful)
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.
More information, please (Score:1, Informative)
Doesn't sound like it would be too hard to port.
Upgrades for what? Tell me again what your problem is, and why exactly you need to invest in new hardware and/or new software?
OK, this sounds like the same clueless assholes whole replaced the $250 dumb terminals at the local library with $1250 Windows PCs. (The PCs perform the exact same function as the dumb terminals: card catalog lookups. Pentium CPU, 32 meg RAM, Win95 -- and the only app they run is a terminal program to connect with the mainframe in the back room.)
Do you know about FreeDOS [freedos.org]?
Do you know about Turbo Vision [sourceforge.net]? It makes nifty DOS or Linux apps that look and act like Windows [sourceforge.net] but run in text mode.
Telnet? (Score:3, Insightful)
A "console application" connecting to a server via DOS? I bet his "console application" is a telnet client!
Re:Telnet? (Score:2)
The older it is, the lower the probability that it uses TCP/IP. There were and are plenty of other protocols that were in common use back in the day, especially for an application on slow hardware with a slow connection, which wouldn't cope with the overheads of TCP/IP.
umm freedos? (Score:3, Informative)
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
More background needed, really. (Score:2)
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.
Winmodems and *nix... (Score:1)
Re: (Score:1)
The nature of an upgrade... (Score:1)
With an environment that is this old, I would recommend, for both your sake as well as the client's, to look at a full Linux migration. This migration should be looked at from many angles in order to save money.
First, are any of these remote PCs in a common location? If so, a single faster internet connection should be looked at. You could set up a small connection sharing/DSL network at the remote site(s). If enough connection consolidation can be done some money can be saved on a monthly basis. It will also cut down on the number of modems/phone lines to maintain. Even if you switch to a secure VPN over the Internet for each modem, the central computer only needs a single high-speed (DSL, cable modem, T1, etc.) network connection. This alone should save tens or hundreds of thousands of dollars per month on phone lines!
Second, port the application to Linux. Linux is a robust platform that will be supported for many years. DOS is not. NT is not. Microsoft is barely even supporting NT at this point. If it is written in C/C++, all the better. It will be a quick conversion. If not, it's worth the effort.
Third, If the client buys into the idea, look at replacing the PCs with newer hardware. I know that in the US (I'm assuming that the
If he likes the idea, buy just a few PCs at first. Get the programming glitches worked out and the communications tested.
Once the program/new environment is good to go, set up the new server and let some users try it beside their old setup for a week or two. Setup some basic training materials (maybe even a basic training class). Get the users trained on it while the PCs ship out but before rollout. THEN do the cutover.
Your client should be pleased with both the switch as well as the future ability to use the platform for other things. Whether used in text mode or GUI mode, Linux is a powerhouse that is a good investment.
Good luck.
If you need some help, shoot me an email or post it here.
Randy
PS: If you're company is not yet adept at a Linux conversion/rollout. This kind of contract would be great to get your feet wet and grow that side of the business.
I can't think of a good subject! (Score:1)