🚀 go-pugleaf

-----BEGIN PGP SIGNED MESSAGE-----

In article <41nnifINNn4o@keats.ugrad.cs.ubc.ca>,
Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:

>But DOS was developed for machines that could only address 1MB.  That
>DOS wasn't made portable/scalable to a 32 bit architecture is a software
>problem, sure. DOS's system call interfaces are over-specified, in that
>they dicate low-level assembly language details, such as what registers
>pointers are passed in.

in other words, sloppy engineering, and, to boot, lack of foresight.
in a way, this is what yo uget for having your OS written by a bunch
of hackers: it works, but it's a nightmare to maintain.

in a way, you can't fault them.  software engineering is a recent art.
portable coding is a recent development.  then again, it's not that
new: Johnson wrote PCC in 1979, and UNIX was running on multiple
architectures in 1978.

>>And now you notice it yourself, contradicting yourself.
>
>No I'm not. Because the barrier was real in the days of the 808x machines.
>In 8086 compatibility mode, the 386 still can't address more than a
>meg.

which raises the question, why the hell would anyone want to run in
8086 compatibility mode, at least not any more than necessary.  some
VAXes have a PDP compatibility mode.  people don't go out of the way
to write software for it, and CM support was phased out some years
ago (on nearly every VAX-arch processor made in the last ten years,
loading a PSL with CM=1 raises a reserved operand fault).

>>The ability to map *virtual* memory pages around the I/O areas
>>implies that the OS software can *physically* address all available
>>RAM, whether or not it is below the adapters (640K) or not. Only DOS
>>misses this capability, and it is just because it was designed that
>>way. No runtime allocating of memory structures and such. It's
>>called 'assumptions'.
>
>DOS certainly does have memory allocation system calls. The problem
>is that these are specified right down at the machine language level
>as returning 20-bit addresses as segment/offset pairs. There are not
>portable C wrappers for these raw calls as there are in UNIX. 

DOS has a heap manager; it does no _memory_ management.  memory
management deals with allocating memory to processes, and protecting
memory not allocated to the current process from being trampled.  DOS
can't do this on a 8086 because the 8086 lacks an MMU, but that's no
excuse for not doing so on an 80386, which can.

>Many other kludges are specified too---like poking around DOS
>internals to discover what state it is in, it's non-reentrance, etc.

it was bad software engineering for Microsloth to advertise these as
anything other than "these may change with a new release of the OS".
VMS had advertised kernel internals (EXE$PPID_TO_IPID was one i recall
using, although i may have the name wrong, it's been 8 years since
i've done any VMS work).  you had to relink any program which used
these against the system image after upgrading the system.  i think if
you forgot to do so the image loader would blech with "SYSTEM.EXE
version mismatch" or something like that.

the main error made by Microsloth wrt DOS was trying to maintain
backward compatiability all the way down to DOS 1.0.  DEC publishes a
list of "obsolescent features" with each new release which may go away
with the next release.  if you are using a feature on that list, you
have a while to develop a workaround (often, DEC will tell you what
the workaround is).  DEC will not remove a feature without first
listing it as obsolescent except in very rare situations, and often
keeps obsolescent features around for several revisions (although they
are not documented, or are documented specifically as obsolescent).
by _not_ doing this, DOS is forced to maintain an absurd level of
backward compatability, in some cases with software that is over ten
years old.  this is sloppy project management, and sloppy user
relations.

DOS, Windows, and the Intel x86 series are all the mess they are
because Microsoft and Intel both have been bending over backwards to
retain backward compatability with stuff that's over 10 years old.
the problem with looking backwards all the time is that it makes it
hard to look forward.  Windows, the 386, 486, and Pentium are all
crippled solely because they are worried someone might want to run
some truly obsolete software.  i say, screw 'em.  if you want to use
ten-year-old software, use some ten-year-old hardware, or, better yet,
just emulate that ten-year-old hardware on today's modern hardware.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMD/2KRbgfSHT/piVAQEwoQP9Fp7sVLbA/dZ+QUPF9YZw2Tiky6OoPLyE
MSwXiGsMB/xyUz7mlb7zyxvFO6YKerv6oTL5KimuXJlACAx7daZ6geesvLSHEqO7
9d/Hcgrm2fgWBIKQBnuvrCqmVZWC286aM1hQLKcR9uwQy7DASlLBJ5kHNbYzyVF2
+rB4W7Jhqsw=
=DQ09
-----END PGP SIGNATURE-----