NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/mswindo/misc/2419

Internet Message Format | 1992-08-26 | 12.2 KB

Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!heathh
From: [e-mail] (Heath Ian Hunnicutt)
Newsgroups: comp.os.ms-windows.misc
Subject: Re: Windows == OS
Message-ID: <[e-mail]>
Date: 27 Aug 92 00:12:45 GMT
References: <[e-mail]> <[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: California Institute of Technology, Pasadena
Lines: 214
Nntp-Posting-Host: punisher

[e-mail] (Name) writes:
>Let me see....  Virtualization, in my mind (with reference to this
>discussion), is that the OP makes each application think it has a
>certain resources all to itself without concern of other applications.
>For instance, the IBM CP/M (I think this is the one) works on the
>concept of virtual machines, each application feels like it has a
>machine of it's own, memory of it's own, cpu of it's, tape drives of
>it's own and so on.  Now stopping an application from accessing a
>resource-- controling a resource-- is not virtualization.
    Well, then (in your mind) you have no idea of what an OS is
responsible for.  How many stinking tape drives do you think my
machine has?  If Application 1 is using the tape drive, the OS
should: a) Prevent App 2 from interfering.  b) Let App 2 know in
some standard way why it can't open the tape drive just now.

>>       As I said, Windows 3.1 lets you do this.  If having malloc
>>   makes it an OS, why not just do this:
>>   #define malloc(size) GlobalLock(GlobalAlloc(GMEM_NODISCARD,(size)))
>>
>>       Ta,da!  I turned Windows into an OS with just one #define!
>It's not the five letter combination m-a-l-l-o-c.  Malloc supposedly
>get's memory from DOS.  Now, if ms-windows was an operating
>system,i.e., taking over the system as an operating system and
>releaving dos from it's duties, then it would of been able to juggle
>with malloc memory blocks too.
    Windows does not have to do it EXACTLY like DOS did in
order to be an Operating System.  If that were true, Windows
would have to BE DOS.

    The way Windows does it is fundamentally better than the
way does handles a malloc.  DOS does not allow memory blocks to
move, does not allow for virtual memory, and does not do any
sort of garbage collection.  The reason for these difficiencies
is due to the WAY DOS DOES MALLOC.  If Windows did it the DOS
way, it too would suffer from various stupidities.
    Tere is no good reason for Windows to support and manage
an underlying DOS memory subsystem that has no reason to exist,
and is not used.  Windows has its own memory management code,
its own way of doing things, and that is just fine.  Windows
does not have to be masochistic to be an OS.

>>       Well, so does the unix _open call.  I rarely make (nor am
>>   I allowed to) system calls or I/Os to the drive array, nor do
>>   I ever open the raw file systems.  Yet, _open is little
>>   more than a function call, which proceeds to issue an interrupt,
>>   trap, sysvect, or whatever to open a file.  How _open works
>>   depends on that OS's API.  Yessiree, all OS's have APIs.
>>   You're just going to have to accept that.   Just because Windows
>>   uses dynamic linking and nice names like GlobalAlloc, doesn't
>>   mean that it is any less an OS than any other OS.
>>       Furthermore, Windows is more than an OS!  Yes, it
>>   is 300% of an OS.  None of the functions provided in USER
>>   and GDI have much to do with the OS aspects of it.  Yet,
>>   the functions in KERNEL and SYSTEM have all the functionality of
>>   a real OS, except for managing the file system at the hardware
>>level.
>Unix's system calls are not the same as window's API functions.  On
>unix you can use ONLY the system calls to do certain things.  For
>instance try accessing process PCBs (processes control blocks)
>directly in machine code without using any of UNIX system function
>calls- your appllication will be terminated before you release the
>return key (this is because unix takes advantage of the OPERATING
>SYSTEM BIT or PRIVILEGE BIT).  Now you can freely do this on DOS, and
>in ms-windows.  You can very easily play with the PCB of windows
>engine itself.  This is because DOS does not take care of this (I am
>sure that on 286 and up has this bit).  This means that DOS still
>has a higher role than just a "device-driver for windows."  Hence,
>windows does not releave DOS of it's most fundamental operating system
>duties, and therefore, windows IS NOT an OP.
    Well, the PCBs you refer to are created by Windows, not
DOS.  They are similar to, but not the same as DOS's PSPs.  DOS
is not used to create them, although calls to the DOS API are
supported by Windows.
    Not all versions of UNIX will stop you from messing with
PCBs, since not all UNIX machines support memory protection.  The 286
does not support it well enough to encourage anybody to write an
OS that runs in more than one level on the 286.  DOS doesn't take
care of protecting the PSP because DOS can run on 8086s.  Windows
doesn't because it also has roots in the older processors.  Regardless,
that does not keep it from being an OS, either.

>The protected mode windows is so famous for is either not the same
>thing as I described in the previous paragraph or windows is not doing
>the job properly because it's not windows job but DOS's job.  Just
>yesterday I downloaded winvn, I executed from file-manager, and QEMM
>wrote on window's screen like it did not exist, and it complained that
>the CPU informed QEMM that the application *** executed a bad
>instruction and it gave me the option to reboot the system.  Now if
>DOS would of taken care these things like on unix, the application
>would of terminated and UNIX would of cleaned up after it (more or
>less) without rebooting.  Yet, it was not windows that complained, it
>was QEMM which is DOS's baby.  There is another example of where DOS
>still serves as an operating system were windows does not take serious
>duties.
    That is really an example of you not having QEMM set up
correctly, but I'd hate to pin any blame on you, who so obviously
knows what an OS should do and is.  DOS is incapable of
taking care of these things, and as a seperate entity from Windows,
has no real place in this discussion of whether Windows is an OS.
If you had set up QEMM right, or (better yet) used EMM386, you
would have been given the Windows GPF dialog box.  This is the
Windows analog to "Bus Error- Core dumped.) in Unix.



>>       What about the concept of Dynamic linking?  What about
>>   the fact that all functions must be reentrant?  And stop
>>   misquoting my phrase "internal abstraction".  I did not mean
>>   that it was presented to Apps, hence "internal".  I was talking
>>  about DPMI, not the API.
>>       Also, isn't the event-driven nature of Windows quite a bit
>>   different from DOS?
>Sorry about "internal abstraction."

>Dynamic Linking as you put it, is probably an extension of DOS
>overlays, and is not a new thing introduced by windows.  The
    Well, you probably don't know jack about dynamic linking,
either.  Is UNIX's shared library concept just an extension of
DOS's overlay idea?  Nope.  And DLL is much closer to shared
libraries than DOS overlays.
    For one thing, any app can use a DLL that has a documented
interface.  Try that with DOS overlays.

>event-driven nature of windows has nothing to do with an operating
>system.  X windows does exactly the same thing.  Ms-windows to dos
>as x-windows is to unix.  This is much closer to the truth than
>saying that ms-windows is an operating system.  This is not exactly so
>because there things windows takes care of that X-Windows doesn't
>touch (as should be) but still not enough to consider windows on the
>same shelf with operating systems.  Here is were you should be
>reminded of the argument in the above two paragraphs.



>>   Finally-
>>    I seem to have unintentionally deleted your points about how the
>>   Windows scheduling loop is not as OS-like as the one in, for example,
>>   Unix.  You stated that since it doesn't switch stacks, it is not
>>   really multitasking.  Well, I've got news for you:  All apps
>>   have their own stack that the scheduler switches them to before
>>   dispatching them.   They also have their own local heap, their own
>>   data segment, etc.,
>True.  Yet these are specifics that you'll have to check in the source
>code for windows.  The fact that MS says in their manuals that each
>application has a stack does not mean that this is literally true.  If
>it is true the that windows engine is simply another DOS APPLICATION
>being multi-tasking by this larger frame, which sure does explain
>plenty of things, then a given windows program stack is not really
>independent of this window's engine stack.  You know when you call a
>function with automatic variables it simply creates them on the
>current stack.  Now windows call WinMain and it must return from it
>before moving to another window's application.  This simply means that
>all the stack information (the private stack for each windows
>application) does not really exsit it is merely created and stacked
>over the single window's engine stack, which then totally unfolds when
>WinMain returns and hence it looks to everybody that each window's
>application has a private stock which is not true technically but is
>equivelant (sp?) conceptually.  This is why I expressed an outrange
>against the loop constract I have first introduced, and this is
>certainly different than what UNIX does.

    Well, you are wrong.  Windows does literally switch stacks,
by loading the SS register, which you probably don't know about.
Now you've gone and said that just because the docs say Windows does
something one way (switch app stacks) doesn't mean it is true.
Ok.  Well, neither does UNIX, and unless you show me the source code,
I won't believe you, because the UNIX docs could say anything.
    I KNOW THAT WINDOWS SWITCHES STACKS BETWEEN APPLICATIONS.
In fact, your stack may even get thrown out to the swap file if you
haven't been called in a while.  How do I know that?  By running
debuggers through windows, and through windows apps.  I have seen
pseudo-code of the Windows task switcher, and I can unequivicably
state that Windows does witch stacks for tasks.
    So, if my app calls GetMessage() when it is, let's
say 50000bytes deep on its stack(!), the app that gets control
may have an entirely fresh stack, depending on where it is
being resumed.
>About the heap there is no problem there at all, all window's
>appliation and DOS applications share one single huge heap which is
>exactly the DOS's heap starting at the end of the DOS code+data (I
>think at the beginning of physical memory) and end at the end of the
>real memory.  In fact, I think I read someplace that if a windows
>application attempts to use more heap that it declared in the *.def
>file windows will increase the heap-- I am not sure though. If that is
>true, then everything is truely absurde about windows because this
>could mean that windows does not really care about any heap statements
>and it is true that all applications simply share one huge global heap
>provided by dos.

    At this point, it is becoming increasingly apparent that
you have never written a Windows program.  Applications have
seperate, individual local heaps.  These are accessed by LocalAlloc.
What you read was probably that Windows can dynamically expand
the heap, if an application over-commits it.  This is an example
of something that makes Windows an OS, BTW.
    All apps can also alloc off the shared heap, the so-called
global heap.  NO DOS APP can use the global heap.
    Global heap items are allocated and managed by Windows,
not DOS.  DOS cannot use the global heap, as most of it is
above 1 Megabyte.  The heap is not a DOS feature.  It is
all part of the magic of Windows.


>Don't worry about it as long as this is a civilized discussion and not
>an dog-fight like what's going on in comp.os.windows.advocacy.
    Well, I think this thread is starting to get a bit loopy,
if you don't mind me saying so.  Why don't you go write a few
Windows programs, and read a book other than Petzold, then tell
me about Windows, and how it is not an OS at all.

Heath

--
On Saturday, April 18, 1992, this .sig became self-aware.