Hi,
On Thu, May 3, 2012 at 8:29 AM, Michael B. Brutman
<mbbrut...@brutman.com> wrote:
>
> Rugxulo,
>
> You read into things too literally at times ... ;-0
I know, and I was being facetious (somewhat).
> The 808x series of processor was segmented.
But compared to CP/M (64k max. per app), it was a big improvement.
> It was used on a machine
> that reserved a portion of memory for system BIOS, system BIOS
> extensions, and video RAM.
IBM architecture, yes, and you had to have some of that stuff. Well,
maybe not, SCP's original 8086 board could (and did) use the full 1 MB
(according to Tim Paterson).
> The first versions of the operating system (DOS) did very little to mask
> the architecture of the PC.
16k or 64k isn't a lot of RAM to begin with, so you can't have too
many bells and whistles.
> If you wanted to read the keyboard or draw
> the screen, you could use the DOS functions which were very incomplete
> in their implementation. Or you could go directly to hardware. Except
> for a few small warnings ("please don't go to BIOS, it might break your
> application on a completely non-conforming machine), many people went
> straight to the hardware. It only supported contiguous chunks of
> memory, making it hard to deal with the transition to machines with more
> than 1MB.
The 8086 was only intended to support 1 MB. That was a lot at the
time. The only workaround was EMS. I know you know this, and 10x
better than me, just saying .... It wasn't until the 286 (PC AT?
1984?) that 16 MB became the new "limit", not that anyone had that
much RAM for years to come.
> So now you have a thin shell of an operating system that does nothing to
> avoid exposing the hardware to the end applications. And we've been
> applying one kludge after another on top of that ever since.
The BIOS supported video gfx stuff (right?), but it was too slow for
most people. This is also why many people want / use gfx acceleration
these days, they want fastest speed! But that's for games, and
admittedly, the IBM PC was never (directly) intended for home gamers.
Nevertheless, it became popular for that anyways.
We're long past all that. We could easily have a stable driver
framework if we wanted. It's just nobody has bothered. A common
interface for sound cards would be better than letting every app do it
themselves. Allegro tried this but faltered on all the "modern"
SB-incompatible stuff. I don't expect miracles, but I do know that the
problem exists.
> For example, you mention Win 3.0 (DPMI). DPMI is a kludge to allow DOS
> applications to use more memory while still being able to invoke BIOS
> functions and DOS kernel functions.
It's far from a kludge, it's well thought out, better than VCPI even
(which was the whole point). And it was directly meant to play well
together with various environments. And yes, it was meant for DOS apps
to use more extended RAM. DPMI probably saved DOS from death (though
you could argue it was only a temporary solution until Win95 appeared
with easy support for 32-bit Windows stuff ... but MS "controlled"
Win32, unlike DOS).
> Windows and OS/2 don't add
> multi-tasking to DOS - they let several copies of DOS run side-by-side
> in what is effectively a dedicated virtual machine!
Thank the Intel 386 cpu's V86 mode for that. And keep in mind that
task swapping already existed (esp. on 286), but with 386's V86 mode
and DPMI, you could run several multi-megabyte 32-bit DOS apps at the
same time. So that was a big improvement.
> If I lock you in a
> prison decorated to look like 1988 you'll think you live in 1988 too ...
Not sure what 1988 refers to, but it's definitely not modern DOS.
Almost everybody nowadays assumes MS-DOS 5.x or compatible circa 1991.
Big difference in memory management, utils, etc. And that's not
counting all the third-party stuff.
> PC DOS 6.x and 7 still support FCB based programs. Yes, people should
> still use file handles. But my point was that once something gets
> added, it never gets removed no matter how archaic.
Welcome to the modern world. C++ suffers the same way, same as Java,
etc. I wish Win64 didn't kill NTVDM, but they wimped out (and don't
tell me it's impossible, it's not!!). Unless you prefer to be like Mac
OS X, which seems to drop support for something every other week.
> If you want to modernize DOS even just to support more current hardware
> you are going to have to duplicate a lot of work that has already been
> done
Yeah, do the work or do without.
> for drive controllers, video cards, USB controllers, BIOS bootstrap
> requirements, etc. Like I said, that would be redoing a lot of the work
> that has already gone into Linux.
Some of it, yes, some of it, no. And we don't want another Linux. IMO,
Linux is too big and complicated. But yeah, DOSEMU is pretty good, so
maybe it would be more "sane" to just make a lean Linux with that
atop. But I don't think the idea of "fixing" the DOS bootup
environment etc. is too shabby either.
> If you want to really modernize DOS you are going to have to fix or
> break a lot of things that exist today.
I was fairly content with WinXP's DOS support. Not perfect but way
better than nothing (and certainly better than a slow software-only
emulator with bugs, no offense to anyone). I'm not expecting
perfection. In fact, I don't expect anything! (Is barely anybody still
active around here??)
I don't think we have to break anything, and that's not the goal. The
imaginary (hopeless?) goal is to support a few extras. But I'm pretty
content already, just not perfectly so. ;-) I just don't
necessarily "want" to throw everything about DOS away. Is that so
wrong?
Was Linux so wrong in copying *nix instead of reinventing everything?
"We don't need to reinvent UNIX, it already exists!" "Why are we
working on Linux when FreeBSD exists? It's the real deal!" "Why use
Linux when Windows already just works?" (See what I mean? You can
argue anything if you're lazy or just prefer something else, no
offense intended.)
> You can implement a simple OS
> that uses the INT 0x21 programming interface, but if it doesn't run
> existing software (because you have a 32 bit kernel that doesn't handle
> segment wrapping correctly),
V86 ftw!
> doesn't load existing TSRs,
IIRC, both Win9x and WinXP allowed those (more or less).
> has a different
> memory map, and doesn't allow direct access to hardware, is it really
> DOS anymore?
You can have direct access to hardware. At least memory, you can
directly access it with DPMI. As for video and sound, emulating VGA or
SB isn't impossible (as has been proven with DOSEMU, DOSBox, NTVDM,
etc). Though I'm not specifically thinking about multimedia here, just
normal productivity (mostly cmdline?) apps.
Hey, this is all just thinking outloud. I'm not much of a programmer,
and I have no huge projects in the works, so don't expect Jack
(miracle worker) from me. :-) But it doesn't mean some ideas aren't
worth using. I'm just saying, a "better DOS" has already been done.
We've already "adapted" a lot over the years. It's not the same DOS as
it was in the '80s. I don't want to throw anything out, but certainly
some things are worth improving, right??
We've got to change sometime, esp. since AMD64 and UEFI are pretty
much trying to squash us. :-(
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
