🚀 go-pugleaf

Re:
>From: fleming@inmet.camb.inmet.com (Ed Fleming)
>Subject:DOS Extender Recommendations?
>Date: Fri, 30 Oct 1992 04:07:48 GMT
>Message-ID:<1992Oct30.040748.1545@inmet.camb.inmet.com>

>I have an OS/2 protected mode application on an 80386 developed 
>with the Microsoft C 6.0 compiler, which I need to port to 
>Windows 3.1.  Actually it's a non-GUI application, so what I'm 
>really targeting is a DOS box under Windows.  I need to be able 
>to dynamically allocate several megabytes of data.  We plan to 
>use the Microsoft 7.0 compiler for the Windows version of the 
>product.
>
>Under OS/2 I was blissfully ignorant of any behind the scenes
>manipulations which had to occur to enable me to access more
>than 640K of memory.  I simply malloc'ed to my heart's content,
>and everything worked without a hitch.  Well, now it's time to
>see how the other half lives...  In looking into what it's going
>to take to get from here to there, I've been poring over 
>literature describing the DOS 640K barrier, and the DOS extender
>products which are supposed to free you from the original 
>limitations of DOS.
>
>I talked with people at both Rational Systems and Phar Lap, which
>appear to be the two major players in this arena...

We have been using PharLap with our product for a couple of years.  It
used to be that PharLap was _much_ better than all the other products.
While the competitors have been doing catch up work, we feel that
PharLap is still a notch ahead.  The documentation of PharLap is also 
superior.

The biggest problem with PharLap is their price.  If you are going to sell
a product bundled with their DOS extender, be prepared for the increased
cost in royalties.  Some other DOS extenders are _free_, on the other hand.

>  Ozone (sp?)
>    They told be about this over the phone.  It's a lesser-known
>    product of theirs that's been out for about a year.  Apparently
>    it's geared toward exactly the type of migration I'm looking to
>    do -- moving non-GUI, character-based applications from OS/2 to
>    DOS protected mode.  They tell me that the conversion should
>    take all of 15 minutes to accomplish -- simply graft their
>    loader program onto your currently existing OS/2 executable to
>    produce a DOS executable which "simulates" OS/2 for your
>    original executable.  Additionally you can use Codeview to
>    debug such executables.  I'm waiting for further info from
>    Rational.

Haven't dealt with them.  IMHO, DOS extenders take a long time to
mature.  This is because there is no standard and they get to work with
the other products _by_trial_and_error_.  Some "standards" such as DPMI are
not very complete and one has to figure out how the other products
deal with the areas not covered by the standard.

>Phar Lap:
>--------
>  286 DOS Extender
>    - Also allows access of up to 16M.
>    - Supports MSC 7.0
>    - Uses Codeview protected version (cvp) for debugging

Why bother with the 286 extender (instead of the 386 one) at all?  Anyone
seriously thinking of running a large application would have junked the
old AT and bought a 386 long time ago.  Also, PharLap can also run under
Windows or other DPMI servers.

>... can continue to invoke the compiler's
>run-time library routines (malloc, calloc, halloc) and automagically
>be given access to extended memory.

This is generally true for most compilers.  

Btw, we have been using WATCOM C for a couple of years and have been impressed
with the quality of their compiler.  Their debugger is so-so.  (WATCOM
C is available for OS/2.)

Another point: our application has a home-brewn GUI and we write directly
to the screen in protected mode.  Interfacing with the mouse driver (which
runs in real mode) is a tad tricky but in general we don't have any
difficulties.

...

Interestingly, we have been taking an opposite approach.  We
have been dealing with DOS extenders exclusively and no OS/2 at all, mainly
because few of our clients use OS/2's.  (We sell our products to big
corporations on a  more or less a subscription basis, and we are dictated
by their platform requirements.)  

To anyone who has not dealt with DOS internals before, there's _a_lot_
to learn.

Tak.
-----------------------------------------------------------------------------
Tak To                                                    (617) 577-0310 x377
Aspen Technology, Inc                                Fax: (617) 577-0303
10 Canal Park, Cambridge, MA 02141.                       tto@aspentec.com
-----------------------------------------------------------------------------
Disclaimer: My opinion does not represent that of Aspen Technology, Inc.