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

Internet Message Format | 1992-08-30 | 5.4 KB

Path: sparky!uunet!usc!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: 31 Aug 92 03:15:58 GMT
References: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Tufts University - Medford, MA
Lines: 91
In-Reply-To: [e-mail]'s message of 28 Aug 92 07:28:30 GMT

WHEN I WROTE THIS POST I ACCIDENTLY PRESSED C-C C-S AND IT WAS SENT TO
BE POSTED THEREFORE I DID NOT FINISH IT.  THIS IS THE ONE THAT SHOULD
BE CONSIDERED THE POST, THE OTHER ONE SHOULD BE DISCARDED.

>   N > >   makes it an OS, why not just do this:
>   N > >   #define malloc(size) GlobalLock(GlobalAlloc(GMEM_NODISCARD,(size)))
>   N > >
>   N > >        Ta,da!  I turned Windows into an OS with just one #define!
>   N > It's not the five letter combination m-a-l-l-o-c.  Malloc supposedly
>   N > get's memory from DOS.  Now, if ms-windows was an operating
>   N > system,i.e., taking over the system as an operating system and
>   N > releaving dos from it's duties, then it would of been able to juggle
>   N > with malloc memory blocks too.
>   Sigh...
>
>   OK Simply take the MSC Compiler and write a Windows app which use malloc!
>   This
>   will work! malloc well be automatically translated to the sequence
>   "LocalAlloc
>   - LocalLock".
Good, refer back to my arguments that seemed stupid to you-- that
gives me a swift chance to clear my name, the one you tryied so
enthusastically to destroy.

The intention I had behind using malloc as an example was to show you
the mess windows is doing to DOS, and this assumed you were keen to
fundamental operating system concepts-- which you turnout to be a
little rusty on-- and in particular the VM concept.

If windows was an operating system layered over dos, everything that
happened at it's level and above would be completely under windows
control-- as the defintion goes, the operating system is the ultimate
controller of the underline hardware, and everything under window would
be viewed as the underline hardware.  However, the fact that a malloc
would allocate a memory block and windows is not able to control it
(i.e. windows controls it's memory blocks with management that is
above and beyond DOS's control, and the particular example I was
refering to moving these malloc blocks, which windows cannot, and
actually this malloc call is almost completely invisible to windows,
because one does not use window's primitves here) suggests that
windows is not a layered operating system (because DOS handles the
memory management of the malloc block).

The explanation of the argument above (and the argument itself) is
relevant to windows if and only if malloc calls are handled by DOS.  I
had specifically not mention malloc blocks under dos-boxes because
these are virtual dos machines, and hence, windows controls them
(because windows does the virtualization here), this would again make
the argument misplaced (by the way, do not confuse box-dos
virtualization, and the virtulization necessary by dos to support and
windows to bow to, in order to consider windows a layered operating
system).  Since I have not seen any code of either DOS or Windows, and
since it is not specifically mention, in any operating system books I
have read during the time I studied operating systems, how malloc
is really handled and implemented, I have resorted to Petzold's
comment, that windows will swap out an MS-DOS box, and will have to
return this MS-DOS box to the exact location whence it was swap from.
This ment that windows does not virtualizes DOS machines very well (if
it were these DOS-machines could be moved, since the underline
hardware is virtual and can therefore be duplicated else where).  It
also SUGGESTED that windows is not touching any of DOSs memory
management, it leaves that to DOS.  This along with the knowledge that
windows needs dos device-drivers to manage it's own memory (don't jump
on me for this statement, by dos's device-drivers I mean that they are
installed on DOS, and that DOS is the creature that runs them, hence
windows is a slave to dos, it needs dos to survive), I decided that
it is highly likely that windows will not dare to touch a malloc
block, and if it di,d it would die a hurrible death and would cause the
system to enter an unstable state.

>   will work! malloc well be automatically translated to the sequence
>   "LocalAlloc
>   - LocalLock".
Whatever the compiler is doing to cover up or fix windows' lack of
control system-wide control (I have already explained system-wide, it
follows from the definition of an operating system, which controls the
whole of the underline hardware) is of no material to our discussion.
I can understand why you put this statement and this argument of
yours, this is the result of your misunderstanding of my arguments,
and in this case, the specific malloc argument.


>   If you write a DOS app with MSC malloc will be translated to "intr( XXX) -
>   blabla (additional stuff)".
>   malloc-call on whatever OS will ALLWAYS be translated to underlaying memory>    managemant calls. There is no conceptional difference!
Excellent, it is appearnt from you reply that you begin to surface.
However, there is a conceptual difference because the compiler is doing
these thing not an operating system.

>   Martin
Tomer