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

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

Path: sparky!uunet!olivea!bu.edu!jade.tufts.edu!news.tufts.edu!news.tufts.edu!tguez
From: [e-mail] (Name)
Newsgroups: comp.os.ms-windows.misc
Subject: Re: Windows == OS
Message-ID: <[e-mail]>
Date: 26 Aug 92 20:45:04 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Tufts University - Medford, MA
Lines: 197
In-Reply-To: [e-mail]'s message of 26 Aug 92 04:48:58 GMT

>       And, you took my phrase "internal abstraction" out of
Oops, apologies.
>   context.  What I meant was, since DPMI is part of Windows,
>   whether GlobalAlloc hacks on the LDT or calls DPMI, memory
>   allocation is still being handled by windows.
>       My point was that Windows makes no calls outside
>   its own modules when allocating memory. i.e., it does not
>   pass the request on to DOS.
That's understood and well taken, read the paragraph after the one and
see why I don't think this changes anything.

>   >>       Windows intercepts and virtualizes:
>   >The way the sentence is phrased makes one think that windows
>   >virtualizes like an operating system virtualizes.  Yet, this is all
>   >nothing more than a layer of primitives.  You have to use window's
>   >primitives to fell this "virtualization" try accessing any of these
>   >things you mention directly and see how much of virtualization windows
>   >truely provides.
>       Ok.  If you directly access the DMA controller under
>   Windows, you get a GPF.  (This assumes a 386, and enhanced mode,
>   the only hardware that this is possible with, running under the
>   appropriate software.)  If, however, you access the UART directly,
>   and are the first to do so, you will succeed, but an OpenComm on the
>   same port by another app willl fail.  That is virtualization.
>   Furthermore, Windows even handles DOS apps doing hardware I/O,
>   and controls which task gets the access.
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.

>   >>       Actually, Win 3.1 changes the base address on the hardware
>   >>   level.  By abandoning real mode, Windows has gained greatly in
>   >>   memory management abilities.  Now, you can lock that HGLOBAL once, and
>   >>   use the pointer throughout your App's life.  When you quit, just
>   >>   unlock it once.  Windows will still be able to juggle your blocks,
>   >>   it just doesn't have to have your cooperation to do it.
>   >Once more the same old same old, use window's primitves and you get
>   >the abstraction, the point is that if windows was a real operating
>   >system I could use malloc and the operating system could still juggle
>   >with my memory blocks.>
>
>       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.

>   >>       Well, now there's a weird argument if ever there was one.
>   >>   If Windows is the only code that can access hardware or memory
>   >>   directly, at all times, and manages the access of user programs
>   >>   to hardware and memory, then it is DEFINITELY NOT AN OPERATING
>   >>   SYSTEM?  And what planet do you hail from, sir?
>   >You probably mis-understood what I wrote or I did not express myself
>   >clearly.  The API function, these primitives, hide the hardware and
>   >help you write software that is a little more distant from the
>   >hardware for that they are great.  They do a lot of work for you, one
>   >function call to FillRect stands for many complex lines of code, for
>   >this also they are great.
>       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.

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.



>   >dos application that usually prints something that this is a win
>   >executable file, and it has a WORD signature some were in the header of D
>   >executable that this is no ordernay DOS app, and then a database is
>   >attached to the end of this DOS executable.  This database is complex,
>   >includes resources, tables and more.  This DATABASE is then
>   >accessed by this DOS APPLICATION we know as the windows's engine, and
>   >it uses some type of an analog to dos overlays to load the actual
>   >library into memory (as regualr dos-like functions) and deals with the
>   >rest of this database,i.e.,resources, import/export tables and all
>   >that.  Then all these resources MUST be accessed via the
>   >primitves so widely knows as API functions, and this makes an
>   >operating system?  If this guess is correct at the core, then windows
>   >is not much different than DesqView and we have a dos application for
>   >an operating system.  As you mentioned earlier, "internal
>   >abstraction," correct internal to the dos application I refer to here
>   >as window's engine.
>       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
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.

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.


>   If I have misrepresented your views, sorry.  I'd like to quote
>you,
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.

Tomer