AS> " Why is Ralf Brown's interrupt list peppered with API calls marked
 AS>   "this function is incompatible with the OS/2 compatibility box"?  "

Of course, the question is a leading question, in that it in order to answer
it one would have to implicitly accept as true a particular fact.  The premise 
of the question, that the interrupt list is "peppered" with such notation is
in actualy fact largely false.  In amongst the thousands of API calls
described in the interrupt list, there are a small handful that are explicitly 
marked as unsupported by OS/2 VDMs.  (Only OS/2 1.x had "a compatibility box"
(singular), incidentally.  OS/2 versions 2.0 and later all have multiple
Virtual DOS Machines.)   Many more of the APIs listed are marked as "supported 
by the OS/2 compatibility box", and indeed several API calls listed are
supported *only* in an OS/2 Virtual DOS Machine.  

GREPping version 58 of the Interrupt List (which is dated 1998) we find that
it contains just 26 occurrences of the phrase "compatibility box", and of
those at least 15, posibly more, are in sentences that say that that a
particular API *is* supported in the OS/2 compatibility box.  This is in a
list of over 8605 interrupts.

The reason that those few are marked as unsupported is pretty obvious with a
little thought.  The MS/PC/DR-DOS operating system(s) are written with the
notion that the application program has control of the entire machine, and can 
do anything that they like, including hitting directly on the PC hardware if
needs be.  Multitasking protected mode operating systems, because of this,
have to "virtualise" the hardware and firmware environment seen by DOS
programs, since on a protected mode operating system a running process should
not be able to adversely impact the operation of another running process, or
access or confuse the internal data structures of the operating system itself. 
 But of course there are things that DOS programs can do that are simply
impossible to virtualise because of this.  The ability to write directly to
raw sectors on a disc is one such.  To allow DOS applications such low-level
access to the disc would not only bypass any filesystem security measures
(OS/2 Warp Server has HPFS386, remember, which allows access control lists to
be applied to local files and directories), but would also interfere with the
operation of the filesystem drivers, since it would allow DOS applications to
make the contents of the volume on disc inconsistent with the internal data
structures maintained by the filesystem drivers themselves (to track open
files and directories).

So it is API calls, such as the INT 13h routines supplied by the BIOS firmware 
to allow write access to discs at sector level and similar calls, that would
undermine system integrity or security, that are unsupported by OS/2 Warp.

Another set of DOS APIs that are not supported are those that require a
particular structure to the internals of the operating system.  API calls that 
return pointers to internal, undocumented, DOS kernel structures are also
unsupported, for the very good reason, that is again obvious with a little
though, that *non*-DOS operating systems have no obligation to contain such
structures in their virtual DOS environments, since the virtual DOS layer is
simply a virtualisation layer on top of the operating system proper, which the 
DOS application has no access to (it being a protected mode operating system).

Of course, the badgering attitude of the original poster in the rest of the
post (which I have not quoted) indicates that he thinks that this lack of
support for DOS APIs, that either require access to the internals of DOS or
that bypass system security and udnermine system integrity, is a bad thing. 
Unfortunately for him, what it mostly indicates that he is also seriously out
of touch with modern softwares.  DOS-Windows 3.1, released nearly 8 years ago, 
*also* prevented, in the default configuration, DOS applications from
performing low-level access to discs via firmware APIs, for much the same
reasons.  So too does Windows NT.  The plain fact of the matter is that there
are things that DOS applications *can* do that they simply *should not be
able* to do, because those things are more properly the remit of an operating
system, not applications softwares.  In many ways, DOS is indeed not a
complete operating system in this respect, since it fails to fully insulate
applications programs from the hardware.  

Summary: Protected mode operating systems that insulate applications programs
from the hardware and from one another, and that are not based on DOS and so
do not maintain the same internal kernel data structures as DOS, namely OS/2
Warp, Windows NT, and linux, will never support *all* of the APIs available in 
DOS.

But then, the fact that DOS applications that do these sorts of things largely 
doesn't matter in the first place.  OS/2 has *native* utilities for things
like low-level disc sector editing.  The irony is that the native OS/2
utilities are usually *better* than their DOS counterparts.  The utilities in
the Graham Utilities for OS/2, for example, don't have 1042 cylinder
limitations (since OS/2 Warp itself doesn't) that plague DOS disc utilities. 
HPFSVIEW is even multithreaded, with one thread allowing one to view the
contents of the volume, and the other thread reading the HPFS disc structures
from disc in the background.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
633/260
2501/209