🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #23427

Re: Last time on this one

#23427
From: David Baggett
Date: Wed, 13 Jan 1993 01:48
81 lines
4499 bytes
In article <1185@usdtsg.DaytonOH.NCR.COM> anisko@usdtsg.UUCP () writes:
>   Uh, Dave, Microsoft makes DOS, not IBM (i.e. 3rd-party again).  The
>fact that they have a virtual monopoly on IBM DOS (except for DR DOS)
>makes them the standard.

OK, one more clarification:  *Microsoft's* MS-DOS was packaged *by IBM*
with every PC ever sold until the clone market kicked in.  So YES, I
suppose TECHNICALLY SPEAKING there's no IBM CLI.  But there is an
IBM-endorsed standard.  (Not that IBM matters anymore.)  There is (once
again) no Atari-endorsed CLI for the ST.  OK?!

>As for "wimp" interfaces, would not OS/2 and Windows then be
>considered as well? (being non-CLI?).

OS/2 runs DOS better than DOS, but sure Windows is WIMPy, and it sucks
eggs (sorry David) too.  I don't use it.  I detest it.  Feh!

>And those are the main selling points for the PC's right now 

Windows?  Selling point?  Hah!  The main selling point is that you get
a hell of a fast machine for your money.  If you really want an OS
get 386 MACH or something.

>>Second, the ST doesn't run Unix.  It can't run Unix because it isn't
>>capable of doing virutal memory.  (It does run Minix, though; I'll
>>give you that they're similar.)
>
>   Dave, could you give me a short description of virtual memory and
>what it takes to do it?  I assume (correct me if wrong) that the Windows
>SWAP file would be considered virtual memory?  Why would doing something
>like that not be capable on an Atari?  Just curious.

Coming right up:  "Virtual memory" generaly refers to memory (for code
or data) that may or may not have a physical counterpart in the machine.
Under Unix (which has virtual memory), processes can allocate as much
memory as they want to (almost).  When you allocate more memory than
there is in the machine, proceses get "swapped out" to disk.  In other
words, pages of memory get saved to disk and marked as "swapped."  When
a process tries to access a swapped page, a "page fault" occurs, which
is similar to an exception on the ST (e.g., two bombs).  The reason
you need hardware support is that you have to check to see whether
your page is swapped it *at every memory reference*.  This is hideously
slow without hardware support.

Windows does do VM, and Windows NT probably uses VM even more.  But
Windows doesn't run 80x86 chips that don't support virtual memory.
The 8086, the 68000's counterpart, doesn't have virtual memory support.
The 286 does, but in a very limited and brain-damaged way.  The 386
does (for real), which is why Windows is recommended for 386 systems
and better, and why MACH runs on 386's and better.

Software virtual memory schemes are possible but generally lose due to
slowness or required brain-damage.  The original Macintosh OS
implemented a software virtual memory scheme, which is where the 32K
per code segment limitation came from (which was subsequently inherited
by Megamax C version 1.x, BTW).

The TT and Falcon, BTW, CAN do VM, because the 68020 and 68030 handle
VM quite well.

>   Depends if you could use the software.  Something like Game Workbench
>would seem like a great thing for game programmers. 

Your point is well taken, but that was intended to be an example.  How
about the world's greatest DTP system?  I'd think that would be about
$300 a copy if it were something as good as Interleaf, Frame maker, etc.

>>An early, buggy version of a poorly designed single-tasking OS.
>
>   But it works and is functional.  An OS is supposed to be
>functional, not *necessarily* elegant (though it could be).  I went
>from TOS 1.0 to 1.4 and finally 2.05, and have had very little 
>problems in the process.

I was just answering the question.

Dave Baggett
--
dmb@ai.mit.edu           MIT Artificial Intelligence Laboratory                  
ADVENTIONS: interactive fiction (text adventures) for the 90's!
dmb@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS
Technical Details
Message-ID: <1ivscsINNrh1@life.ai.mit.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!olivea!mintaka.lcs.mit.edu!ai-lab!case!dmb
References: <1isna6INNonm@golem.wcc.govt.nz> <1itbngINN4t4@life.ai.mit.edu> <1185@usdtsg.DaytonOH.NCR.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!olivea!mintaka.lcs.mit.edu!ai-lab!case!dmb
From: dmb@case.ai.mit.edu (David Baggett)
Newsgroups: comp.sys.atari.st
Subject: Re: Last time on this one
Message-ID: <1ivscsINNrh1@life.ai.mit.edu>
Date: 13 Jan 93 01:48:12 GMT
References: <1isna6INNonm@golem.wcc.govt.nz> <1itbngINN4t4@life.ai.mit.edu> <1185@usdtsg.DaytonOH.NCR.COM>
Organization: MIT Artificial Intelligence Laboratory
Lines: 81
NNTP-Posting-Host: case.ai.mit.edu