Hoo boy! This is going to be interesting.

Hoo boy! This is going to be interesting.

[Steve Cohen]

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

Hoo boy! This is going to be interesting.

[Steve Cohen]

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

Re: Hoo boy! This is going to be interesting.

[Frank Cox]

On Fri, 2010-10-08 at 14:25 -0500, Steve Cohen wrote:
> 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?

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

Re: Hoo boy! This is going to be interesting.

[Paul Crawford]

On 08/10/10 21:22, Frank Cox wrote:
> 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?

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

Re: Hoo boy! This is going to be interesting.

[Steve Cohen]

On 10/08/2010 03:22 PM, Frank Cox wrote:
>
> On Fri, 2010-10-08 at 14:25 -0500, Steve Cohen wrote:
>> 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?
>

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

> 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

Re: Hoo boy! This is going to be interesting.

[Paul Crawford]

Dear Steve,
> 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.

> 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

Re: Hoo boy! This is going to be interesting.

[solarflow99]

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.


On Mon, Oct 18, 2010 at 10:44 AM, Steve Cohen <stevecoh1@comcast.net> wrote:
> On 10/08/2010 03:22 PM, Frank Cox wrote:
>>
>> On Fri, 2010-10-08 at 14:25 -0500, Steve Cohen wrote:
>>>
>>> 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?
>>
>
> 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
>
>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hoo boy! This is going to be interesting.

[Steve Cohen]

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".




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.
>
>
> On Mon, Oct 18, 2010 at 10:44 AM, Steve Cohen<stevecoh1@comcast.net>  wrote:
>> On 10/08/2010 03:22 PM, Frank Cox wrote:
>>>
>>> On Fri, 2010-10-08 at 14:25 -0500, Steve Cohen wrote:
>>>>
>>>> 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?
>>>
>>
>> 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
>>
>>> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
>> the body of a message to majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>