OS/2?
DOS programs under Windows, Windows NT, and OS/2 must either not use
386/486/586 (I refuse to say "Pentium" — urgh!)-specific features (such as
Virtual Mode or Flat Memory Mode), OR access them only through DPMI (DOS
Protected Mode Interface) instead of VCPI (Virtual Control Program Interface).
3D Studio requires a 386 or better, specifically so it can use the flat
memory model. It does this under DOS by being linked with a DOS extender, in
this case the Phar Lap 386|DOS-Extender. Release 2.01a and earlier are linked
with an older version of Phar Lap (v2.6 or earlier) which can access its
extended memory via INT15 (built into most BIOSes but limited to 16MB), EMS
(Expanded Memory Specification — emulates the old EMS/EEMS boards that were
needed for pre-286 computers to exceed the 1MB limit since the 8086, 8088,
80186, and 80188 were simply incapable of addressing more memory than that
directly — emulation requires a 386 or better, or a 286 with special support
chips, plus a driver such as EMM386, QEMM386, 386Max, NetRoom, etc.), XMS
(Extended Memory Specification — builds on INT15 to provide a more
standardized way to access 286 Extended Memory [limited to 16MB] and in some
versions 386 Extended Memory as well [limited to 4GB] — requires a 286 or
better and a driver such as HIMEM.SYS, QEMM386, 386Max, NetRoom, etc.), and
VCPI (a standard created by Phar Lap and Quarterdeck to allow more than one
program to run in Virtual Mode at the same time on a 386 or better).
Unfortunately, the older Phar Lap wouldn't use DPMI.
Animator Pro 1.3 and 3D Studio release 3 and later are linked with a more
recent version of Phar Lap that DOES add DPMI support to the other memory
standards it supports. This allows both of these programs, and others linked
with the newer Phar Lap, to run in a DOS box under Windows, Windows NT, and
OS/2 2.x.
Windows is a "cooperative" multitasking environment. This means that a
Windows program must permit itself to be interrupted, or it will never release
control. This is why it's possible for one program to lock up the whole system
under Windows. Most well-behaved Windows programs will give up control when
waiting for an "event" such as a keypress, mouse action, while displaying a
dialog box, etc. Other programs may then execute in the background.
Windows NT, OS/2 2.x, and to a limited extent DesqView, are all known as
"pre-emptive" multitaskers. This means that the operating system can just grab
control away from a program and give others a chance to execute, even if the
first program hasn't explicitly released control. In other words, the
program's execution is pre-empted. Other programs that need attention NOW
(such as communications programs that will lose incoming characters if they
aren't permitted to retrieve the ones in the buffer before new ones come in in
a few milliseconds, etc.) don't have to wait until the active program feels
like letting go of the CPU for a bit. They can just tell the OS that they need
to execute NOW, and the OS will just grab the CPU away from the active task and
give it to the high-priority background task for awhile.
For instance, you cannot format a floppy disk under Windows while other
tasks are running. You can only do so if the DOS box has Exclusive mode set,
which stops all other tasks from executing. The reason is that the signals
written to the floppy drive during the formatting process MUST be written at
PRECISELY the right times or the resulting disk won't work. After all, the
disk drive motor isn't going to pause in its rotation for a few milliseconds
while, say, Solitaire moves a card. <grin> But OS/2, and presumably Windows
NT, can format floppy disks in the BACKGROUND, even while other CPU-intensive
and physical event intensive (such as background communications programs,
including a fax driver in the act of receiving a fax at 14.4 kBPS) are running!
It can do so because each task can preempt others as needed, when they need to.
The upshot is that running 3D Studio Release 3 under OS/2 2.x or Windows NT
will not speed up rendering. It will actually slow it down a bit, more or less
depending on what else is running, but always at least a bit since the OS
itself will use some CPU time. HOWEVER, it will enable you to USE your
computer for other things while 3D Studio is rendering, and this is a MAJOR
advantage! Would you rather an animation render take 9 hours during which you
CAN'T use your computer for anything else, or 12 hours in which you CAN do your
word processing, CompuServe access, etc. at the same time? That's the question
to consider. To a limited degree you can do this with ordinary Windows 3.1.
To a much greater degree you can do it with any of the pre-emptive multitaskers
such as OS/2 2.x, Windows NT, or DesqView-386 — I wouldn't try doing a
CompuServe pass at 9600bps in the background while 3D Studio is rendering also
in the background while I'm editing some maps in the foreground with
PhotoStyler, for instance, under Windows 3.1 — chances are the CompuServe data
would be corrupted because of dropped characters missed while the other
programs were executing (a 16550-AF UART with FIFO enabled on the serial card
or internal modem would help here considerably — Windows 3.1 does support
that). Under OS/2, it would be no problem to do this.