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

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

Path: sparky!uunet!kithrup!stanford.edu!ames!haven.umd.edu!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: 29 Aug 92 23:44:15 GMT
References: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Tufts University - Medford, MA
Lines: 95
In-Reply-To: [e-mail]'s message of 29 Aug 92 02:05:02 GMT

>   NA>>   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 wh
>     >>   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:
(I, Tomer , posted this)
>
>   It has to, DOS simply cannot provide the services that are needed to
>   run Windows.  If DOS did have those resources, then we wouldn't see
>   Windows taking control(1) over DOS.
Right, correct you are.  This makes windows an intruder not an
operating system.  This is also one of the sources of confusions
(subtle operating system concepts get mixed up here), read the post
with "VMM is an operationg system.....no this is disassebling...."

>   NA>>   Windows programs, up until now, have been based on another paradigm
>     >>   mulktitasking, which has proven to be not as good as pre-emptive.
>     >That was known a head of time.
I have not wrote that, so'll skip it, it's not integral to a
discussion windows==OS (?).

>
>   Ahhh, but we have history playing a role here.  The 8086 was not
>   capable of efficient pre-emptive multitasking.  The original platform
>   for Windows included the 8086, up until version 3.0.  Since version
>   3.1 is basically just an API extension of 3.0 with bug-fixes, we can't
>   expect any changes in paradigm.  Now that 3.1 no longer runs on 8086
>   platforms, we are now prepared for Windows 4.0(?) which will multitask
>   Windows apps pre-emptivley as well.

 >    >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.
>
>   I beg your pardon... but it isn't at all apparent that you have
>   availed yourself of the current literature.  If you had read the
>   literature about Windows, then you would have known about DLL's, and
I know about them and understand their operation as MS likes us to, my
attempt will be explained after we settle more important things, like
fundamental concepts of operating systems, then we can play with what
I was trying to do.
>   that Windows can move memory around transparent to bothe Windows and
>   DOS apps being run under Windows.  I've never seen the source code for
>   Windows... yet reading the tech journals and publications gives me a
>   good idea as to what is going on.
Exactly, put this good-ideas together and you'll see what I mean with
the DLLs and everything else, but wait until we get to more stable grounds.

>     >>   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.

>  Not the same, and again you are revelaing your ignorance of Windows
>  technical matters.  What if you had 10 different programs that all
>   statically linked a comman library routine into there executables?
No, you are totally refusing to understand the paragraph, and it's
intent.  I will get back to this (if you wish) after we get to more
stable grounds, i.e., go over some fundamental operating systems.

>   you have each of those 10 programs running, then there is a copy of
>   that library code in each one of those apps' memory space.  That means
>   there is 10 copies of the library  routine in memory.  Inefficient use
>   of system resources.  DLL's are different.  You can leave the library
>   routine OUT of the executable code.  Now you can run your ten
>   different applications, and they will access the library routine
>   through a DLL.  Only ONE copy of the code exists, and it is linked
>   dynamically, AT RUN TIME, to the applications that request it.

>     >>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!!!
>
>   Good!
Notice that I constantly hold formly to certain things and admit when
I am wrong.  Things that you think I am wrong about because there is a
serious mess of concepts and references, you will find them correct
and very interesting when we get to more stable grounds.  In the mean
time keep an open head.

-Tomer