kea@kasoft.UUCP (Ken Anderson) (11/21/90)
I am dealing with 2 clients who want to window-ize their applications. They both currently use Phar Lap's DOS extender and a suitable C compiler. I'm not up-to-speed on 32-bit compilers, but I don't get a clear picture from reading Appendix E of the SDK Reference Manual. As I see it, you can't run a DOS Extender under Win 3.0 at present. Although DPMI is implemented, you shouldn't call it directly, but use the WINMEM32.DLL functions instead. Phar Lap says that they are working on a DOS extender that will operate under Win 3 (but why use one?). Has anyone successfully ported a DOS extended program over to Win 3? What C compiler should I use to generate 32-bit instructions? Thanks in advance.-- Ken Anderson, kea@kasoft.UUCP, 416-274-6244 (fax:416-891-2715) ---
ed@odi.com (Ed Schwalenberg) (11/26/90)
In article <BXFys1w163w@kasoft.UUCP> kea@kasoft.UUCP (Ken Anderson) writes:
I am dealing with 2 clients who want to window-ize their
applications. They both currently use Phar Lap's DOS extender
and a suitable C compiler.
You're getting confused about three similar but unrelated issues.
Issue 1:
DOS Extenders are for using protected mode facilities under DOS;
DPMI is a spec for DOS Extenders to enable extended programs to
cooperate in the use of PM facilities and memory when running under
DOS multitasking systems like Windows. If your clients want their
DOS apps to work using the DOS virtual machines provided by Windows,
you need only wait until Phar Lap comes out with a version of their
extender that interacts with DPMI as implemented in Windows 3.0.
The Rational Systems expander used by 1-2-3 already does this.
Issue 2:
WINMEM32.DLL is for using 32-bit code and data segments in WinApps
on 386 machines. None of the compiler vendors has yet provided support
for this; you'll have to roll your own or wait until they do. If your
clients want their programs to be WinApps, and they need the 32-bit
model, you'll have to get into this. I haven't actually used this
facility yet, so I won't offer any opinions on which 32-bit compiler
to use.
Issue 3:
Do your clients actually need a 32-bit environment, or are they using
the Phar Lap environment primarily to use >640K memory? If they need
the 32-bit environment, you need to decide about the issues above. But
if they're just using lots of memory, the ordinary Windows environment
may be enough.mojo@netcom.UUCP (Morris Jones) (11/27/90)
kea@kasoft.UUCP (Ken Anderson) writes: >Has anyone successfully ported a DOS extended program over to Win 3? Yes. OmniPage Professional uses a true 32-bit code for the OCR module. >What C compiler should I use to generate 32-bit instructions? I can't say what you should use, but I had success using Metaware High C and the Phar Lap assembler and linker. Be prepared to do some heavy-duty system-level development to establish code and data communication across the USE32 and USE16 segments. I enjoyed it myself -- a good opportunity to work with native 386 code. Mojo -- mojo@netcom.UUCP Site Coordinating Instructor, San Jose South Morris "Mojo" Jones Skilled Motorcycling And Rider Training (S.M.A.R.T.) Campbell, CA 800-675-5559 ... 800-CC-RIDER ... 408-423-2212 AA4KB @ N6LDL.#NOCAL.CA.USA.NA / aa4kb.ampr.org / netcom!mojo@apple.com
rob@pcad.UUCP (Ralph Brown) (11/28/90)
In article <BXFys1w163w@kasoft.UUCP>, kea@kasoft.UUCP (Ken Anderson) writes: > > What C compiler should I use to generate 32-bit instructions? > I'm looking into the same problem, from what I can gather as of now, the Intel Code Builder set (1-800-322-4871) is the only environment that will support Windows in all modes. It is supposed to be available in the next month or so. My understanding is that to really interface to windows (not just run as a DOS app), you still need to write a glue layer between the application in protected mode, and the windows libraries which are in real mode. Does anyone have any experience with this GUI Glue layer, or even better know of a commercially available package to do it? Cheers, Ralph