From: tguez@jade.tufts.edu (Name)
Newsgroups: comp.os.ms-windows.misc
Subject: Re: Windows == OS     2/
Date: 28 Aug 92 19:30:01 GMT
Organization: Tufts University - Medford, MA

>   Since DOS is not re-entrant, you have to play tricks with memory
>   addresses to make DOS think its the only thing running.  YOu can't
>   multitask any other way than preemptively, since DOS doesn't know when
>   to give up its time slice.
Exactly refer to diagrams (earlier posts) and this is an argument
against widows being an operating system.  I could explain if it is
needed, but the way windows sends hooks into terratories not it's it
breaking the rules, another quote from a conversation:

>   Windows programs, up until now, have been based on another paradigm of
>   mulktitasking, which has proven to be not as good as pre-emptive.
That was known a head of time.
>   However, each Windows app is its own separate entity, with its own
>   separate stack and heap.


>   As far as your other comments in another post concerning Dynamic
>   Linking.  This has nothing to do with DOS overlays, as you suggested,
>   and again, this comment shows that your knowledge about Windows and
>   what it does are lacking.  Dynamic linking means that you don't
>   have
Correct my knowledge about the specific implementation of windows is
limited to the literature available-  MS does not release the source
code, if there is anyone to blame it's MS.
>   to bind in the executable code in the actual executable itself.  You
>   can make reference to it in another file, and when you call that
>   function, Windows will use the code in the other file.  This
>   "other
This is very easy to do if you view windows as an application that can
dynamically link object libraries, and then obviously linking ten of
the same object libraries will leave only one copy in memory.
Windows, then, looks more like an advanced dos applciation, and then
my suggestion was that as a dos app it could very well implement
dynamic linking by taking overlays (which are a part of dos, built
in, this is a fact) make these fixes windows does and enhance this
mechanism so it looks nice and smooth.  At any event, let's discard
specifics and look at the things abstractly with concepts in mind and
not blends of concepts as the posts.
>   function" has a separate code segment than the caller, and also a
>
>  different data segment, although it will share the caller's stack
> (necessary, since the DLL may be called by several different callers;
>this way the DLL has a separate stack for each different application
>   that it is a part of).

>   This brings me to your comments about the Windows stack, and how you
>   believe that all windows apps stacks are just part of the main Windows
>   "stack".  Again, this is wrong.  Each Windows app has its own
>   physically separate stack, in a different segment than any stack that
>  the Windows kernel might use.  If the opposite were true, as you
>   suggest, then it would be easy for applications to overwrite the
>   "main" stack and it would be awfully inefficient to monitor this kind
>   of activity to make sure you didn't violate another applications part
>   of the stack.  In fact, Windows does trap most illegal writes to parts
>   of memory that don't belong to a particular process, but it does this
>   by monitoring the segment selector of any pointer that you have.
>   Also, think carefully about the structure of memory that Windows uses,
>   and the maximum size of a segment in Windows: 64K.  If all
>   applications were to share the same stack then it would be very easy
>   to exceed the 64K limit very quickly.  In fact, each application's
>   individual stack can grow to be as large as 64K (theoretically), but
>   no larger.

 >  Which brings me to your point in another post about WinMain.
>   WinMain's parameters are NOT on the same stack as any "main"
>   application stack (which doesn't exist).  Rather, there is the use of
>   "instance thunks" which Windows uses to place the parameters on the
>   application's stack.

>  You have done a nice job of theorizing about some of the concepts, but
>   frankly, you are wrong in a lot of your assumptions about what the
>   functional specs for Windows are. 
I agree with you!!!
>   Resource Kit manual if you wish to gain a true understanding of what's
>   going on.

I am having an extremely successful email conversation with
raymondc@microsoft.com I think everyone would be very interested to
join and observe, this is the sort of converstion I ment to have.
Therefore, the next post I will take all the emails I sent him and the
ones he replied and all the followups between us put them into a file
and post them.  Then we'll move this discussion to posting.


Simling even more,
Tomer