From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Cohen Subject: Re: Hoo boy! This is going to be interesting. Date: Mon, 18 Oct 2010 17:00:18 -0500 Message-ID: <4CBCC372.1000406@comcast.net> References: <4CAF7029.8020304@comcast.net> <1286569332.11941.13.camel@mutt.melvilletheatre.net> <4CBC876A.90204@comcast.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-msdos-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: solarflow99 Cc: linux-msdos@vger.kernel.org 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 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 >