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

Text File | 1992-08-26 | 5.6 KB | 136 lines

Newsgroups: comp.os.ms-windows.misc
Path: sparky!uunet!microsoft!wingnut!philipla
From: [e-mail] (Phil Lafornara)
Subject: Re: Windows == OS
Message-ID: <[e-mail]>
Date: 27 Aug 92 00:48:39 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]>
Followup-To: comp.os.ms-windows.advocacy
Lines: 121

     Some of this is just too bizarre to leave untouched...

In article <[e-mail]> [e-mail] (Name) writes:
>
>I have never seen any of the underline code for windows, but from
>programming windows I say, with a great deal of confidence, that
>windows is not even 10% an operating system.  It's one huge layered
>APPLICATION.  Everything you do that interacts with the hardware goes
>through a layer, i.e., another function call.

     Please explain what this has to do with anything.  Can you
name a single operating system that doesn't require you to call
APIs to perform OS functions?


>  Instead of calling
>malloc, one calls globalalloc which is probably nothing more than a
>malloc that is hidden down somewhere plus some additional tracking
>information.

     And the point here is?


>  Windows can move memory because it never gives you the
>handle it gets from malloc, it keeps it and therefore could do what
>ever it wants with it without affecting your application, and when you
>actually want to use it, you lock it and then windows does not dare to
>touch it because now you have the malloc pointer.  Yet a true
>operating system, which supports this feature, does not care that
>you have the actual pointer, it changes the base address of your
>pointer on the hardware level.

      Does the 8x86 line support hardware remapping of pointers?
Can you think of an efficient way to allow movable memory on a
system that doesn't?  How about something like this - you request
your memory from a central source, and when you want to actually
use the pointer, you lock it.


>These API function calls are great, they hide most of the hardware and
>they do a lot of work for you and simulate an operating systems.

     It doesn't "simulate" an operating system in this respect.
All operating systems provide some API - perhaps it is more
transparent on some, but all of them have to do it.


>Windows still uses msdos drivers to do things and it will continue to
>do this.

     Windows uses MSDOS for its file access, and that's it.  It
uses different drivers for other resources.


>  In fact, even if MS will encorporate everything that windows
>needs, and currently takes from dos, into windows in such a way that
>you'll boot directly into windows and never boot dos (completely
>remove DOS from the picture), I will still argue that windows is not
>an operating system, and windows programs are really nothing more than
>function calls, which is probably why it could not properly
>multi-task:

     This paragraph is incoherent.  Please show me an example
of a program that isn't "nothing more than function calls".


>In Petzold's introduction for windows programming, he writes something
>to the effect,"...windows will not take away the cpu from a task in
>the middle of a message processing....make's sense right?"  Of course
>it does, windows could not take away the processing even if it
>wanted to; All of windows "multi-tasking" is nothing more than very deep
>function calls, so everything is on the stack and hence the message
>(or actually the function) must finish so that the stack will come
>back to this "ingenious" loop, and continue.

     Well, that's an interesting theory... not correct, or even
close to correct, but certainly unique.


>I don't mean to be rude to anyone (not even Microsoft) but I am upset.
>Somewhere in Petzold's book he says something like keep your message
>processing short so other windows programs could run concurrently, and
>if you have any big job to do divide your job to small parts and do it
>with the help of the timer....  That is really disguesting, windows
>programs need to do the job of the operating system, provide the
>"ticks."

     Pre-emptive scheduling of tasks is not a necessary condition
for an operating system.


>  I have still to figure out this one:  in the control panel,
>386 enhanced setup, if you read the help about time slicning and all
>that, it makes a soup out of the whole story and finally says that
>ms-dos applications ("the old-applications") have a time slice setting
>each, while windows programs share one setting.  Then, you get the
>default of 20.  Now if you change it you get some differences in
>behavior, but I still don't see how they could claim that windows
>applications are actually and truely time-sliced given the discussion
>above.

     Windows applications are not "time-sliced".  You read the
help wrong.


>Therefore, I hold my position, windows is not even close to an
>operating system.  True there are things that will make you think it's
>an operating system, for instance, the ms-dos time sharing is very
>nice compared to the windows apps "time BSing" but then you never hear
>of DesqView held as an operating system.

     "ms-dos time sharing" has nothing to do with any piece of
code being an operating system either.  Your argument is full of
holes in the places where it isn't downright incoherent.

     Followups to comp.os.ms-windows.advocacy.

                    -Phil

--
-------------------------------------------------------------------------
Phil Lafornara                         1 Microsoft Way
[e-mail]                Redmond, WA 98052-6399
Note:  Microsoft doesn't even _know_ that these are my opinions. So there.