Hoo boy! This is going to be interesting.
Okay, I am engaged in an effort trying to determine whether or not DOSEMU offers any hope as a path to porting a complicated legacy DOS application to more modern hardware as our stocks of available DOS-compliant hardware are diminishing to the danger point and replacements are no longer available.
To that end, I've downloaded DOSEMU onto a Ubuntu 10.04 system and it seems to work reasonably out of the box.
A very naive attempt to test the compatibility involved copying the executable in question to a drive accessible to DOSEMU, starting DOSEMU and running the application.
I start dosemu by simply typing the dosemu command, and a "DOS BOX" comes up in a different window. All the normal stuff is doable. But when I cd into the directory where I've placed my executable and then execute it, it blows up the DOS BOX (closes it) and in my original xterm window I now see:
OUCH! attempt to execute interrupt table - quickly dying
Well, I said this was a naive attempt. But I have two weeks to get this to work. Can someone tell me what this error message indicates and where I might possibly go to figure out how to fix it?
Thanks,
Steve Cohen
Quoted 2 lines · Steve Cohen
Can someone tell me what this error message indicates and where I might possibly go to figure out how to fix it?
What version of dosemu are you trying to use?
Is the problem with dosemu or with freedos? Have you tried running your application under "native" freedos? Have you tried running your application under dosemu with ms-dos (or whatever dos version you run it under now)?
What language is your application written in? Do you have the source code and a suitable compiler? If so, are you sufficiently familiar with the programming that you can play with the source code for your application and find out exactly what's causing it to blow up?
What kind of application are you using? Process control? Database? Custom hardware driver? Something else?
Signature · 1 line
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com
Quoted 7 lines · Frank Cox
What version of dosemu are you trying to use?
Is the problem with dosemu or with freedos? Have you tried running your application under "native" freedos? Have you tried running your application under dosemu with ms-dos (or whatever dos version you run it under now)?
Quoted 7 lines
What language is your application written in? Do you have the source code and a suitable compiler? If so, are you sufficiently familiar with the programming that you can play with the source code for your application and find out exactly what's causing it to blow up?
What kind of application are you using? Process control? Database? Custom hardware driver? Something else?
There are a number of things you need to try as outlined above.
However, you should also be aware that dosemu 'plays better' on a 32-bit OS than a 64-bit version, at least in my experience of trying the MS C6.0 compiler for our legacy applications.
As outlined above, try your application on 'real hardware' using freedos and whatever other DOS versions you have. Try and establish what it is happy with first. If it is only happy with, say, MS-DOS 6.22 then you can try that inside dosemu and see if it is then happy.
Finally once your app is not crashing dosemu, remember that some DOS applications, and our primary reason for using dosemu, need direct hardware access. Don't give dosemu a blank cheque though, find out what your app needs and enable just that, remembering also you need to edit the dosemu.conf file to allow such access *AND* to start dosemu / xdosemu with the '-s' option as well (and to be a sudo'er, as this punches a huge hole through the OS' security model!)
If you don't allow direct access you won't crash dosemu, it emulates the (wrong) results, so it is unlikely that a crash can be fixed by enabling this. Do it only *if* you need some special hardware to work, and you already have things kind of working OK (at least to the level of starting and stopping an application fairly normally).
And you are testing on a machine with no unique/valuable data I trust? :)
Regards,
Paul
Quoted 12 lines · Frank Cox
Quoted 2 lines · Steve Cohen
Can someone tell me what this error message indicates and where I might possibly go to figure out how to fix it?
What version of dosemu are you trying to use?
Is the problem with dosemu or with freedos? Have you tried running your application under "native" freedos? Have you tried running your application under dosemu with ms-dos (or whatever dos version you run it under now)?
Quoted 8 lines
What language is your application written in? Do you have the source code and a suitable compiler? If so, are you sufficiently familiar with the programming that you can play with the source code for your application and find out exactly what's causing it to blow up?
What kind of application are you using? Process control? Database? Custom hardware driver? Something else?
Sorry for the lapse. I was on vacation. Thanks for your help.
It's 1.4, the version you get with apt-get from Ubuntu 10.04 and the latest stable version, I believe.
This error happens under freedos. I have not yet tried running it under MS-DOS, which is what it runs under normally.
The application is a legacy app written about 20 years ago in C. We have source code for all the code that was written by our organization and for some of the third party libraries that were used. These include CScape (for which we do have source) and the Greenleaf Communications Library, for which, thus far, we don't. The application also uses some version of the PharLap DOS Extender, which currently is at the top of my suspect list for this problem. I've read the EMUfailure page, which mentions that
Quoted 1 line
Older versions of the Pharlap Extender (run286) need ring-0 access under DOSEMU to install their own DPMI server. The use of proprietary undocumented extensions to the DPMI protocol makes DOSEMU's DPMI server unsuitable for this extender.
I don't see run286 as something we're loading and the version of PharLap we are using includes the binaries phar2_ir.dll and phar2_ir.lib. Can someone confirm that this IS or ISN'T the version of PharLap that won't work with DOSemu? It appears to be the Greenleaf library that needs the PharLap and they include a header called phar286.h to support it.
The application is an operator console for a telephony-based system. It uses the serial port to communicate with a phone-dialing device. It also has a network interface to the back-end part of this system which handles switching, billing, and other interfaces.
Although we have source code and suitable compilers, tweaking it much is probably not an option for business reasons. We are on a 2-week fish-or-cut-bait time frame for evaluating DOSEMU for this purpose. If we can't get this to work, we will look at rewriting instead, which is our preferred long-term solution. DOSEMU, if it proves out in the two weeks allotted, would be the short term solution. The reason for this whole effort is hardware exhaustion - we haven't figured out a workable way to replace the old hardware, and are running out of suitable replacements, which are no longer available.
Steve Cohen
Dear Steve,
Quoted 2 lines
It's 1.4, the version you get with apt-get from Ubuntu 10.04 and the latest stable version, I believe.
Are you using 32-bit or 64-bit? I found 32-bit plays better generally.
Quoted 9 lines
Although we have source code and suitable compilers, tweaking it much is probably not an option for business reasons. We are on a 2-week fish-or-cut-bait time frame for evaluating DOSEMU for this purpose. If we can't get this to work, we will look at rewriting instead, which is our preferred long-term solution. DOSEMU, if it proves out in the two weeks allotted, would be the short term solution. The reason for this whole effort is hardware exhaustion - we haven't figured out a workable way to replace the old hardware, and are running out of suitable replacements, which are no longer available.
If all you talk to are serial ports, then you can use a VM under Linux and have that run your software & MS-DOS in it, and pass through the serial stuff to the machine's hardware.
Only 'gotcha' I have found is VM's generally can't successfully set non-standard baud rates, where as dosemu can (particularly if its going via direct hardware I/O to the serial ports rather than emulation).
Re-writing, while a good long terms solution, should *not* be under estimated in terms of the effort needed!
Having the source code is a *major* bonus, and you might be able to re-compile for Linux by only replacing some of the I/O and user interface side of it. We still have a 19-year old DOS control program that we use 24/7 on several systems because:
1) It works reliably (a lot of debugging over the years).
2) There is little "value" in a new program. Given we have it happy under dosemu, there is no functional advantage to changing.
3) It is around 6 months effort to re-write, then at least another 6 months to debug to an acceptably good degree of reliability. Given (2) there is a lot better use of our time on other projects (i.e. little "business case" for it).
Regards,
Paul
if possible, you could try the latest dosemu out of SVN, and use ms-dos instead, then make sure your dosemu.conf settings are uncommented for anything you think is suspect, such as enabling direct hardware access, etc.
Quoted 65 lines · Steve Cohen
Quoted 13 lines · Frank Cox
Quoted 3 lines · Steve Cohen
Can someone tell me what this error message indicates and where I might possibly go to figure out how to fix it?
What version of dosemu are you trying to use?
Is the problem with dosemu or with freedos? Have you tried running your application under "native" freedos? Have you tried running your application under dosemu with ms-dos (or whatever dos version you run it under now)?
Quoted 8 lines
What language is your application written in? Do you have the source code and a suitable compiler? If so, are you sufficiently familiar with the programming that you can play with the source code for your application and find out exactly what's causing it to blow up?
What kind of application are you using? Process control? Database? Custom hardware driver? Something else?
Sorry for the lapse. I was on vacation. Thanks for your help.
It's 1.4, the version you get with apt-get from Ubuntu 10.04 and the latest stable version, I believe.
This error happens under freedos. I have not yet tried running it under MS-DOS, which is what it runs under normally.
The application is a legacy app written about 20 years ago in C. We have source code for all the code that was written by our organization and for some of the third party libraries that were used. These include CScape (for which we do have source) and the Greenleaf Communications Library, for which, thus far, we don't. The application also uses some version of the PharLap DOS Extender, which currently is at the top of my suspect list for this problem. I've read the EMUfailure page, which mentions that
Quoted 4 lines
Older versions of the Pharlap Extender (run286) need ring-0 access under DOSEMU to install their own DPMI server. The use of proprietary undocumented extensions to the DPMI protocol makes DOSEMU's DPMI server unsuitable for this extender.
I don't see run286 as something we're loading and the version of PharLap we are using includes the binaries phar2_ir.dll and phar2_ir.lib. Can someone confirm that this IS or ISN'T the version of PharLap that won't work with DOSemu? It appears to be the Greenleaf library that needs the PharLap and they include a header called
phar286.hto support it.The application is an operator console for a telephony-based system. It uses the serial port to communicate with a phone-dialing device. It also has a network interface to the back-end part of this system which handles switching, billing, and other interfaces.
Although we have source code and suitable compilers, tweaking it much is probably not an option for business reasons. We are on a 2-week fish-or-cut-bait time frame for evaluating DOSEMU for this purpose. If we can't get this to work, we will look at rewriting instead, which is our preferred long-term solution. DOSEMU, if it proves out in the two weeks allotted, would be the short term solution. The reason for this whole effort is hardware exhaustion - we haven't figured out a workable way to replace the old hardware, and are running out of suitable replacements, which are no longer available.
Quoted 6 lines
Steve Cohen
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Actually, I'm an idiot.
I wasn't launching my application the way it expected to be launched. It is usually launched through a batch file which does some system setup.
Launching it in this way no longer gives the error, but there is still much setup of DOSEMU to be done.
OK, on to the next "point of interest".
Quoted 83 lines · On 10/18/2010 04:18 PM, solarflow99 wrote:
if possible, you could try the latest dosemu out of SVN, and use ms-dos instead, then make sure your dosemu.conf settings are uncommented for anything you think is suspect, such as enabling direct hardware access, etc.
Quoted 65 lines · Steve Cohen
Quoted 13 lines · Frank Cox
Quoted 3 lines · Steve Cohen
Can someone tell me what this error message indicates and where I might possibly go to figure out how to fix it?
What version of dosemu are you trying to use?
Is the problem with dosemu or with freedos? Have you tried running your application under "native" freedos? Have you tried running your application under dosemu with ms-dos (or whatever dos version you run it under now)?
Quoted 8 lines
What language is your application written in? Do you have the source code and a suitable compiler? If so, are you sufficiently familiar with the programming that you can play with the source code for your application and find out exactly what's causing it to blow up?
What kind of application are you using? Process control? Database? Custom hardware driver? Something else?
Sorry for the lapse. I was on vacation. Thanks for your help.
It's 1.4, the version you get with apt-get from Ubuntu 10.04 and the latest stable version, I believe.
This error happens under freedos. I have not yet tried running it under MS-DOS, which is what it runs under normally.
The application is a legacy app written about 20 years ago in C. We have source code for all the code that was written by our organization and for some of the third party libraries that were used. These include CScape (for which we do have source) and the Greenleaf Communications Library, for which, thus far, we don't. The application also uses some version of the PharLap DOS Extender, which currently is at the top of my suspect list for this problem. I've read the EMUfailure page, which mentions that
Quoted 4 lines
Older versions of the Pharlap Extender (run286) need ring-0 access under DOSEMU to install their own DPMI server. The use of proprietary undocumented extensions to the DPMI protocol makes DOSEMU's DPMI server unsuitable for this extender.
I don't see run286 as something we're loading and the version of PharLap we are using includes the binaries phar2_ir.dll and phar2_ir.lib. Can someone confirm that this IS or ISN'T the version of PharLap that won't work with DOSemu? It appears to be the Greenleaf library that needs the PharLap and they include a header called
phar286.hto support it.The application is an operator console for a telephony-based system. It uses the serial port to communicate with a phone-dialing device. It also has a network interface to the back-end part of this system which handles switching, billing, and other interfaces.
Although we have source code and suitable compilers, tweaking it much is probably not an option for business reasons. We are on a 2-week fish-or-cut-bait time frame for evaluating DOSEMU for this purpose. If we can't get this to work, we will look at rewriting instead, which is our preferred long-term solution. DOSEMU, if it proves out in the two weeks allotted, would be the short term solution. The reason for this whole effort is hardware exhaustion - we haven't figured out a workable way to replace the old hardware, and are running out of suitable replacements, which are no longer available.
Quoted 6 lines
Steve Cohen
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html