Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!gmdzi!strobl
From: strobl@gmdzi.UUCP (Wolfgang Strobl)
Newsgroups: comp.sys.mac.misc
Subject: Re: Rumor -> Loss of Mac's 20% advantage over Windows 3.0
Message-ID: <3053@gmdzi.UUCP>
Date: 6 Jul 90 21:57:42 GMT
References: <40218215MES@MSU> <1915@runxtsa.runx.oz.au> <3871@newton.physics.purdue.edu>
Organization: GMD, Sankt Augustin, F. R. Germany
Lines: 153

sho@maxwell.physics.purdue.edu (Sho Kuwamoto) writes:

>Now for some content.  I'd like to know more about the Windows
>architecture from a programmer's point of view.  I liked the
>discussions of the printer drivers and resource handling.  What other
>capabilities does Windows 3.0 offer to the programmer?  Graphics,
>presumably, are device independent.  Are there things analogous to
>cdev's, or do you have to pop up a window for a TSR by hitting
>ctrl-alt-hyper-meta-slash?  Is there any other non-obvious
>functionality which Windows 3.0 provides?  Let me explain by example.
>From where I sit, I can guess that it makes it easier to use fonts.
>However, I have no idea if it makes it easier to deal with arrays of
>screen objects (like the List Manager) sound, whatever.  

I will try to answer some of your questions. I cannot tell you
much about the API of Windows 3, because I don't have the Windows
3 SDK, yet. My own experience comes from using the Windows 2 SDK.
The basic architecture hasn't changed much since Windows 1,
anyway.

Device independent graphics

Graphics are handled in a device independent way, so a program can
draw (and type) something into a device without knowing about
device specifics like aspect ratio, resolution of the device,
what colors the device supports, which fonts it has, and the 
result looks more or less the same on all devices.

This works only on a best fit base, sometimes. Windows approximates
colors with dithering, uses a hardware font which is nearest to your
specification "12pt, light, italic, sansserif font" for example, or it
uses one it's builtin raster fonts, if there is nothing else available.

Windows queries the device driver about it's graphic capabilities
(installed hardware fonts, whether it can draw a circle, whether it
supports or needs banding) and hides much of that from the programmer
by simulating the missing parts.

But while a program CAN produce device independent output, this is
not enforced. The program can ask Windows about the capabilities
of the current output device and change it's behavior dependent on
the result. A common example is that a text processor or drawing 
program lets a user select from the font list it got from the 
printer driver.

cdev's.

Sorry, I don't know what cdev's are. "TSR" is of course the (in)famous 
Terminate and Stay Resident routine. What does a cdev do, and what 
is it used for?

Non obvious functionality.

Two somehow related but often overlooked features of Windows are
it's multitasking and that it's takes advantage of the segmented
architecture of the 80x86 processors.

Windows had to squeeze everything into what MSDOS leaves from the
640KByte. Windows itself would not fit into the remaining space.
There had something to be done in order to run more than one
application in this space, concurrently, especially when
the OS itself (here: Windows) has to compete with its
applications for memory.

Most code of Windows and of WIndows applications is
reentrant and moveable. Bigger applications and Windows itself
consist of many small code segments, which are loaded and discarded
on demand. It is sufficient to have space for the largest code
segment of an application (plus data, of course), in order to run
it.

An application does not hold pointers to memory for a long
time, they use handles, instead, which have to be locked in order
to get to the pointer. A memory block can be marked as "discardable",
if the application can reconstruct its content. Windows does
not normally preserve the content of a window, because this
may need to much memory, and an application has to be
able to reconstruct the window content anyway.

As long as an application restricts itself to the so called
Small Memory Model, where all pointer are 16-Bit offsets from
segments, Windows has to manipulate the segment registers only,
in order to move code and data around. This is fast, and
the application does not have to do anything to make it work.
If the application has special needs, it can allocate
global memory using a far (i.e. 16+16) bit pointer. But then
it has either to allocate it fixed (not moveable), or it
has to use the proper lock/unlock sequence.

Code can be placed in Dynamic Link Libraries, which are
just files which contain programs - or better: collections
of functions - which cannot be run standalone, but operate
using the stack of the calling application.

The important point here is that the code of a DLL is shared
by all running applications which use it. Windows itself is a
collection of such DLL's. Printer drivers are DLL's
with a known set of entry points. Many major applications
consist of a set of DLL's and one ore more programs using
these DLL's. 

Arrays of screen objects

Windows windows are instances of a window class. A window
class is a name, a window function and some data.
Windows communicate per messages, which are handled by the
window function of it's class. Windows can have childs.
A child lives on the surface of its parent.
A window does it work by creating childs and let them do
the work, or by reacting to messages it gets sent by
its childs, for example. MS Windows takes care about
which window gets which message, and queues a few of them.

Sound

There is a little know set of Windows functions which seems to
be written with a polyphonic sound chip in mind. Its works,
but is not much used, because the only sound hardware
in common use on PC's it not worth to mention it.

>Does Windows require you to write your own event loop, does it use
>callbacks, or does it use some sort of object oriented design?  

Yes, yes and yes (-:

You have to write your own event loop, but it normally does
not contain any special code, i.e. the standard Windows message loop
  while(GetMessage(&msg,NULL,0,0)) 
  {   TransLateMessage(&msg);
      DispatchMessage(&msg);
  }
or a slightly more complicated version of it fit for most applications.

The three above functions are Windows functions. The loop removes
messages from the application message queue and dispatches it to the
window function it belongs to. This is handled by Windows.
Window functions are callback functions. They have all the same
parameter list, which consists of a handle to the own window
(the "self", or "this"), the most important parts of the above &msg
structure: message id and two parameters whos content depend on the message.

A window functions processes some of the messages it gets (by
sending messages to other windows or even to itself, and hands
all other messages to the default window function DefWindowProc
(by calling it with the same list of parameters). This is a kind
of one level subclassing. By replacing the window function
of a window class with one which processes some of the messages
and calls the original one for all others, it is possible to
get more levels of subclassing. I leave it to you whether you call
this "object oriented".
 
Wolfgang Strobl
#include <std.disclaimer.hpp>