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

Internet Message Format | 1992-08-25 | 12.3 KB

Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!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: 25 Aug 92 19:27:59 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Tufts University - Medford, MA
Lines: 220
In-Reply-To: [e-mail]'s message of 25 Aug 92 04:00:07 GMT

In article <[e-mail]> [e-mail] (Heath Ian Hunnicutt) writes:

>       Sorry.  There is no hidden malloc in GlobalAlloc.  In fact,
>   GlobalAlloc manipulates the appropriate data structures (Descriptor
>   Tables, Global Arena Handler, and BurgerMaster) directly, in
>   order to set aside memory for your app.  (Addendum: Win 3.1 does
>   not hack on the Descriptor Tables, but calls DPMI 0.9 instead.  This
>   has added to the robustness of Win 3.1, but DPMI is still part of
>   windows, just an extra layer of internal abstraction...)

Well it was my guess that there is something like malloc underneath.
You put it nicely, "internal abstraction," everythig in windows API
seemed to be aimed at an "internal abstraction." (I might add that
they done a pertty good job at that).  However, this is nothing more
than the definition of over 600 primitives-- My point will be come
clearer as you read ahead.

>       THE ONLY DOS CALLS THAT WINDOWS MAKES ARE FOR FILE  MANIPULATION.
>   few things that DOS can do well, and, for the most part, Windows
>   lets it go ahead and handle that.  (32-bit access is an exception
>   to this, but DOS is still used to open and close the files.)
>
>       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.


>
>   * All non-disk peripherals.  Keyboard, mouse, video, comm ports, printer,
>       sound board, are all isolated from DOS, and managed by
>       Windows.
>
>   * Many of the DOS software services.  For example, the Get/Set PSP
>       calls are intercepted by Windows, which returns appropriate
>       info.
>
>   * Some disk access.  (Via 32-bit access)
>
>       So, windows is an operating system, with DOS as a file
>   system device driver.
>
>       You know what would be neat?  If I could set SHELL=C:\windows\
>   in my CONFIG.SYS.  I tried it, but the path wasn't set up yet, so
>   Windows couldn't find itself.  It would sure be nice to save the
>   memory that COMMAND.COM takes up by booting straight to Windows.
>
>   >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.
>       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.

>   >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.
>   >Windows still uses msdos drivers to do things and it will continue to
>   >do this.  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:
>
>       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.

Again, the same thing.  You probably missed it but I worte, "simulate
an operating system."  The fact that to open the communication port
one calls OpenCom does not make windows an operating system.  In fact,
in every well-designed communciation program there are primitves to
access com ports that does not virtualize nor makes the program an
operating system.  Windows still is a collection of 600+ primitives.


>       Ther reason Windows cannot multitask stems from the
>   design of 2.0, which could not assume hardware that made preemptive
>   multitasking hardware a possibility.  Windows 3.0 has not completely
>   abandoned some of the 2.0 concepts, and, as such, is stuck with
>   cooperative multitasking.  However, both 4.0 and NT will support
>   preemptive multitasking.
WindowsNT is another issue (another operating system not a GUI),and
Windows 4.0 is another story, and hay, I just read a post that says
that DOS 6.0 has a few things changed to make it ready for Windows
4.0, and among other things, make some changes to DOS 6.0 so that
windows 4.0 could become preemtive.  Hence, Windows does not solely
use DOS as a system device driver after all.

>   >Again, I never saw any of the code for windows but it seems to me that
>   >the whole "windows programs" environment is nothing more than a setup
>   >like this:
>
>   >loop on tasks ( simply run through a linked list of data structures)
>   >  get then WinMain function pointer of the current data-structure
>   >  (*func_pointer)([the winmain parameters here]) ;
>   >  get next pointer
>   >end loop
>       So what if it is?  That is a lot like what UNIX does, too.
>   Windows also provides for interprocess communication, device
>   sharing, serialization of input, virtualization of all hardware,
>   file locking and sharing, true preemptive multitasking with DOS
>   boxes in enhanced mode.
Noooo, unix plays with the stack and does context switches and all
sorts of things.  You see if the loop outlined above is a good guess
of what's happending (again, never seen the source code), then the
function WinMain uses the same stack as the calling program (simple
function call).  Hence, in order to introduce preemptive multi-tasking
there should be some arrangement to make a copy of the stack, and hold
a few stocks in memory and switch between them and take care of PCLBs
and all sorts of things that windows does for DOS apps but not for
windows apps.

>   >In Petzold's introduction for windows programming, he writes something
>   >to the effect,"...windows will not take away the cpu from a task
>   >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.
>       That's not really true.  Any app can yield, no matter
>   how deep on the stack it is.  Just call GetMessage, and you've
>   passed on control, without returning from your nested bunch
>   of calls.  All operating system use stacks and function calls,
>   that does not make them mere applications.
Again that's not the point.  Sure you can inflate the stack with
recursive calls that all have to unfold in the end, but that's
hardly multi-tasking that's what I mean by multi-BSing.  Mutlitasking
is what windows does window DOS apps.  And Again, what makes Windows
an application in my view is that an emense use of API primitives does not
make an appication an operating system.


>   >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."
Here this is were all the stack calls gets annoying-- hardly an
operating system approach.

>   I have still to figure out this one:  in the control
>   panel, >386 enhanced setup, if you read the help about time slicning and a
>   >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.
>       All windows applications are in a seperate address
>   spaces from any DOS app.  (Except from the view of a VxD, which is
>   hardly material here.)  *Windows programs get a time slice*, wherein
>   many of them may yield, and several may execute during the interval.
>   Then, DOS box 1 gets a slice, then DOS box 2, etc.,
"Windows programs get a time slice" hmm... let me bite:  So there is
one big frame that preemtively multi-tasks ONLY DOS APPLICATIONS like
DesqView, and then there is only one dos application that always
executes, i.e., the windows engine.  This DOS APPLICATION (windows
engine) then dynamically links libraries that site in *.exe files and
calls the WinMain of each.  Every such exe file is then really a small
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 DOS
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.


How are these function calls deferent than Borland BGI drivers?  You
register the screen with the initate command and than you use their
primitives.  Ture windows' API are much much more extensive but that
does not make it an operating system.

>   >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.
>       Windows has one up on DesqView because it runs
>   protected-mode executables, allows for many of the features described
>   above, and requires native apps to use Windows services.  DesqView
Native apps....  there are native libraries more likely.



-Tomer