> I've got BORLAND C++ v2.0 and was wondering if it's possible
 > to write a program which will work under either Windoze or
 > DOS...

Yes it is. But in reality, you'll probably wind up with two separate
programs in the same .EXE file.

To explain - Windows and OS/2 uses an "enhanced" .EXE format -
MSDOS only understands a vanillia .EXE header starting with "MZ"
or "ZM" with relocation items.  Extended .EXE's have additional
information used by the Windows and Os/2 loaders (probably WinNT too,
although I haven't checked) which provide the information for what is
usually the "real" program.  You'll notice that when a Windows or
OS/2 program is run in an MSDOS environment, you get a message to the
effect "This program requires Windows to run." or "This
program cannot be run in a DOS session".  This is actually a 'stub'
program which the new .EXE format provides for backwards compatibility with
MSDOS.

In short, the easy answer is that you write two programs and link your
MSDOS 'raw' executable as a DOS "stub".  There is no effect on
memory since the Windows part looks just like an overlay so it is never
explicitly loaded into RAM.

One drawback - trying to combine both sets of code into one (rather than
binding two programs) is going to be difficult. Windows programming
requires a strict methodology and format which simply is not variable. It
would mean that your MSDOS library code attempted to emulate Windows calls.

At that point, good luck..  you'll also have to write a binder which
resolves export library references to your DOS library code which isn't an
easy task. You might be able to use MicroSoft's BIND.EXE, but since they've
kindly not documented how it works, it would be difficult at best.


 > the absence of Windoze...) and allocate a display object for
 > whichever environment it's running in. By including my own
 > windowing routines, and by keeping the interface simple, it
 > shouldn't be too hard to do.

Nothing is ever "simple" when it comes to doing things in Windows.

Try it sometime - either you'll like it as many obviously do, or you'll
detest it as much as me (not so much Windows itself, but the programming
environment). I'm no stranger to GUI's either - imho the Windows API is a
dog's breakfast, very cumbersome.  Backwards compatibility with earlier
versions has been the downfall over time and its grown in an inconsistent
and illogical fashion. As one example, memory management still invovles
lots of fiddling which were required only for real mode programming, yet
the current Windows release (3.1) no longer runs in real mode.


david

---