Easy.. Vista's architecture is like this..
Take input from the computer. Process it through countless bloated
and redundant code libraries, lop off a few bits along the way to
ensure a bug at some point, pass it through IE and back out the other
side to prove IE's an integrated part of the OS, process just a
little more so that your 3Ghz machine runs as fast as 75Mhz pentium
on W98, and spit out the answer.
-Steve
At 01:25 PM 6/15/2006, you wrote:
> The real deal.
>
http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx
Inspired by Alan's post (a very interesting read), I wish someone would
explain the core architecture of Vista. We know that Windows is
essentially message driven, but that's a little vague and simplistic.
For contrast, I'll try to explain the core of IBM's OS390 architecture,
which is the only OS I've been inside of. After so much time with
Windows, and now with Vista coming, I'd like to understand more about
how Windows/Vista works and assume others feel similarly.
OS390
At the center of OS390 is the PSW (program status word), which controls
the entire machine. The PSW contains the address of the next instruction
to be processed and a key indicting the state of the process (plus other
control info). A process running in "supervisor state" (key 0) is
permitted to access and change anything in memory, while an application
program (key 8) is restricted to the memory it's acquired within it's
address space (thus it's impossible for an application program to crash
the machine). To accommodate this, each memory page contains a key, and
this keys is compared to the processes key in the PSW when access is
attempted.
The machine itself is "interrupt driven". When an interrupt occurs, the
PSW is updated with the entry point address of the service (OS module)
related to the interrupt, thus transferring control from the process
that was running to the code that will process the interrupt. There are
only a small number of interrupts defined, and they are hierarchically
arranged to establish precedence. The most "powerful" interrupt is a
machine check interrupt, which occurs for a hardware failure, and
preempts all others.
There are six levels of interrupts. The hierarchy is: Machine Check,
Program Check, I/O, Supervisor Calls, Restart and External.
Every process launched gets an address space (of a default, but
configurable) size. The lower and upper portions of the address space
map into the OS (a collection of mostly reentrant programs loaded into
memory when the machine is IPL'd/booted) that are shared by all address
spaces. The center of the address space (virtual memory pages) belongs
to the application itself. Thus a given address space (memory addresses
available to a given program) is split between OS and application code.
[the VM OS works differently; in VM every "machine" lives in a
completely separate virtual address space; thus it can run multiple
OS390 machines. This is the same concept for VM on PC's]
Anyway ... The flow goes like this: Your application is launched by
virtue of the PSW being loaded (by the Dispatcher) with the entry point
address of your application (which has been loaded into virtual memory
by a loader) ... Your application processes your instructions until it's
interrupted and control is transferred to another process. Your program
typically causes interrupts by invoking supervisor calls (SVC's) that
"interrupt" your program for an OS service, such as a request for I/O,
at which time the PSW is updated with the entry point of the SVC to
process your request. The SVC itself will then launch an async call into
the I/O subsystem and go into a wait for a response. While this waiting
is going on, control is given to another application (per the pecking
order). Then, when your I/O process completes, another (I/O) interrupt
occurs which transfers control back to the SVC you called, and
ultimately to your next instruction (again by PSW change).
Stated again: sharing of the processor (the PSW) occurs when your
program is interrupted (e.g. by your own SVC call for a service, such as
an I/O request) and your program goes into a wait pending the response.
At this time, another program is given control until the next interrupt
occurs, and so on. I/O interrupts (the typical interrupt) are handled by
the I/O subsystem which runs asynchronously to PSW controlled operations
(i.e. "outboard of the processor"). When an outboard I/O operation
completes, it notifies the machine by generating an I/O interrupt (which
is picked up by the SVC program you had called, who then routes control
back to your program's next instruction; perhaps after a wait for a
higher priority task).
I'm using SVC's that handle I/O as an example. In actuality, there are
bunches of SVC's. For example, getting more memory and launching
sub-tasks are SVC calls.
It is possible for your program to dominate the CPU by going into a
tight loop that causes no interrupts, but the OS or the operator will
see this and ABEND the program after a certain amount of time. The
typical program does issue SVC's, though, continuously throughout it's
life. SVC calls are roughly analogous to API calls, but not to be
confused with API calls because SVC calls result in the machine changing
state vis a vis PSW switching (branch-entered - directly called - SVCs
aside).
Per the interrupt hierarchy, a machine check (hardware failure)
interrupt can 'steal' control from the running program (by updating the
PSW with the address of the program that handles machine checks), but
"normal" switching of running tasks is handled within the SVC interrupt.
The major point is that the whole thing is interrupt driven.
A key to making sense of this is the speed with which the CPU operates.
A 100 'mips' cpu is processing 100 million instructions per second. Thus
your program can do a "whole lot" of work before generating an
interrupt, but all that work happens in microseconds.
The machine itself is shared by batch (background) and TSO (foreground)
users. Orchestrating all this is a supervisor program, which uses
controls (performance groups) to prioritize service given to workloads
(groups). A foreground (TSO) user would be in a performance group that
gets more service than a background (batch) job. The supervisor calls
(SVC interrupts) are the portal into the supervisor program, and
performance decisions (pecking order) are made within it.
Online systems, such as CICS (and TSO replacements such as Roscoe),
service many online users from within a single address space that's all
managed by CICS, so it's sort of an OS within an OS. Nevertheless, CICS
is still orchestrated by OS390 as a single background address space.
Performance group controls are used (by the supervisor) to prioritize
service given to address spaces (CICS typically gets highest ranking in
this order).
All address spaces (even CICS) are started using JCL (job control
language) that names the main program to be started and describes the
resources it will need. This gets complicated though because programs
can use dynamic allocation to get at resources not described in JCL. All
work is started by submitting JCL to the job entry subsystem (JES). In
the beginning this was done by punched card decks, but now there are
"internal readers" that jobs are submitted to automatically by
schedulers. Output destined to be printed is handled by JES
independently of the program that produced it (the printer operator then
uses JES commands to control the actual printing during or after the
process is completed).
Queues are used extensively to "stack" things that are pending, such as
communications and I/O interrupts coming back from the I/O subsystem,
and output print files.
While the machine is doing work, performance software is collecting
samples of the machines state (which program is executing) in addition
to event (e.g. I/O complete) stats, into a database that is used by
analysts to determine if the machine is servicing it's users according
to "service level agreements" that are agreed-upon "contracts" between
computer operations and users. Adjustments are made by tweaking files in
a library owned by the person who manages performance.
Multi-processor systems complicate things. There are tightly-coupled and
loosely coupled machines. Tightly coupled machines share memory but use
different PSW's. Loosely coupled machines are separate machines that
share workloads under control of the job entry subsystem (JES3).
-------
This architecture does go on and on, but I tried to summarize it on the
hope that someone will give a go at trying to summarize the Windows
Vista architecture by comparison.
Bill
[excessive quoting removed by server]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
