Jsou Windows95 32-bitovy OS ????????

From: Petr Snajdr <SNAJDR@STUDENT.VSZBR.CZ>
Subject: Jsou Windows95 32-bitovy OS ????????
Date: Tue, 23 May 1995 13:18:18 MET-2DST
Next Article (by Subject): Re: Jsou Windows95 32-bitovy OS ???????? Petr Matousek
Previous Article (by Subject): Re: Je Windows NT jen dalsim klonem unixu ???? Honza Kostal
Next in Thread: Re: Jsou Windows95 32-bitovy OS ???????? Petr Matousek
Articles sorted by: [Author] [Subject]
To safeguard against this sort of "code breakdown," Microsoft has
serialized access to key portions
of the Windows 95 infrastructure - most notably the USER (window
management) and GDI
(graphics device interface) subsystems. In technical terms, this is
referred to as a "non-reentrant"
design, meaning that only one application may execute within these
modules at any given time.
 
While such an approach works with Win32 applications - which can be
preempted at any point
during their execution - it breaks down once a 16-bit Windows (Win16)
application begins to
execute. As it stands, currently shipping Win16 applications cannot be
reliably preempted during
execution. Attempting to do so while such an application is calling on a
non-reentrant, 16-bit code
module can cause the entire operating system to crash.
 
To avoid this latter scenario, and thus retain some semblance of
multitasking, Microsoft has
implemented a special locking mechanism. Dubbed "Win1MUTEX," this
mechanism denies access
to the older code when a 16-bit application has called on its services.
Thus only the currently
running Win16 application has access to the 16-bit code - all other
applications, including Win32
applications, are "blocked" from executing until the 16-bit application
has finished and the
environment has been made safe for the next task.
 
 
In practice, the performance hit associated with this locking phenomena
is minimal when running
32-bit applications exclusively. However, when you introduce a mixture of
16 and 32-bit
applications - the most likely scenario given the projected lack of
available Win32 products -
Win1MUTEX becomes a major problem.
 
Most 16-bit Windows applications are notorious for failing to yield
properly under Windows 3.1,
and until they do so under Windows 95, all other applications will be
blocked from accessing
USER and/or GDI (in reality, only 50% of GDI calls are affected - but
these are the most common
functions so the net result is the same).
 
Taken as a whole, these two compromises - the serialization of subsystem
access and
Win1MUTEX - create what would best be described as a "semi-preemptive"
multitasking
environment. And while the resulting "hourglass" is expected under a
cooperatively multitasked
environment, it seems out of place in a "next generation" Windows that
supposedly "preemptively
multitasks" native Win32 applications.
 
Windows 95 - SAME CODE, DIFFERENT PACKAGING
 
"How can that be? It looks so different!"
 
Looks can be deceiving. While Windows 95 indeed sports a radically
different user interface (more
on that later), as you peel-away the layers of GUI and packaging you'll
discover a product that
looks remarkably like Windows 3.1. In fact, Windows 95 retains so much of
its original
DOS/Windows heritage that it retains the latter's most notorious
operational characteristic flaw:
instability.
 
For example, under Windows 3.1 all applications, as well as the operating
system code itself, share
a single memory address space. While such a memory management model
breeds performance, it
also means that an error in any single application can potentially crash
the entire operating system.
 
This crashing phenomena is often referred to as a General Protection
Fault or "GPF," and has been
the bane of Windows users since version 3.0. It is because of this
inherent architectural weakness
that Windows 3.1 has gained a well known reputation of being an unstable,
unreliable operating
environment.
 
Under Windows 95, this same single address space model (referred to as
the "System Virtual
Machine") is retained, along with the inherent weakness of leaving key
portions of the operating
system code exposed to potentially buggy applications. Thus the same
application failures that
crashed Windows 3.1 can potentially bring down the entire Windows 95
operating system.
 
To their credit Microsoft has made great strides in "cleaning-up" many of
the bugs in the original
Windows 3.1 code while preparing it for inclusion with Windows 95.
However they cannot avoid
the inherent architectural flaws that the Windows 3.1 single System VM
model introduces. There
will always remain the possibility of an errant application causing a
disastrous system crash.
 
Windows 95 - BEAUTY THAT'S ONLY SKIN-DEEP
 
Another major feature of Windows 95, and one that has drawn considerable
attention from the
industry press, is its new user interface. Terms like "object-oriented"
and "desktop metaphor" are
often used to describe this radically different Windows look.
 
But as with most of Windows 95's underpinnings, the actual foundation
underneath the product's
user interface is nothing more than an extension to what already existed
in Windows 3.1. Unlike a
true object-oriented environment - where links between individual objects
are "live" and updated
automatically - the Windows 95 GUI is static. "Objects" on the Windows 95
desktop are merely
pointers to files on the disk. "Properties" for these objects are stored
in .INI files (for Windows
applications) or .PIF files (for DOS applications), and links between
them (called "shortcuts" under
Windows 95) are equally static.
 
For example, if you create a shortcut to an executable file and place it
on the Windows 95 desktop,
then rename the original executable, the shortcut will essentially be
severed. To re-establish it
you'll have to re-create the shortcut from scratch.
 
In a true object-oriented environment, all shortcut-like links to the
executable would have been
updated automatically by the underlying object management model. Windows
95 has no such
underpinnings, so links are easily broken by novice users who are
unfamiliar with the crudeness of
the Windows 95 interface.
 
Going hand-in-hand with Windows 95's shortcut mechanism is the product's
support for long file
and directory names on FAT volumes. Microsoft is emphasizing Windows 95's
ability to
automatically convert long file/directory names into 8.3 character
abbreviations for compatibility
with existing DOS and Windows applications. What they seem to be
ignoring, however, is the fact
that promoting the use of long names can be disastrous when there is no
underlying object model.
 
Take, for example, the novice user who, upon discovering long filenames,
decides to "reorganize"
their hard disk. They gleefully rename directories at will, unaware that
they are severing shortcut
after shortcut in the process. Suddenly none of their applications work,
and I/S is called in to undo
the damage (which in some cases may mean reinstalling both operating
system and applications).
 
The Windows 95 desktop itself is not an OLE 2.0 object. This statement in
itself has no
ramifications until you start understanding what type of integration is
lost due to this lack of object
technology. This deficiency in the product, means that an application is
not well integrated with the
desktop and does not inherit any of the advantages like Drag 'n' Drop
support.
 
Heralded by Microsoft as one of Windows 95's key selling points, the new
Windows interface may
in the end prove to be one of its biggest flaws. Without an underlying
system object model to tie
everything together, this new "shell" may prove to be an I/S support
nightmare.
 
Windows 95 - STILL DOS AFTER ALL THESE YEARS
 
"Windows 95 eliminates the need for DOS. It is a true operating system..."
 
This is one of the more colorful myths surrounding Microsoft's Windows 95
operating
environment. Microsoft claims that Windows 95 eliminates the need for DOS
- that DOS and
Windows are now completely integrated and that all the old restrictions
that DOS brought to the
table have been eliminated.
 
While it is true that you will no longer have to purchase a separate DOS
product in order to install
and use Windows 95, this in no way constitutes the eradication of DOS as
a part of the Windows
operating system equation. DOS is still there, lurking in the shadows.
It's just been cleverly
disguised by a different Windows GUI. And though much of its
functionality - including file
system access - has been replaced by 32-bit Windows 95 VxDs (Virtual
Device Drivers), there are
still ways in which DOS can hinder the Windows environment.
 
Take real-mode device drivers, for example. Under DOS/Windows 3.1 you
were forced to load all
DOS device drivers at DOS boot-time via the CONFIG.SYS file. These
drivers would then occupy
all DOS sessions under Windows' 386 Enhanced Mode, impacting their
available conventional
memory and limiting the overall configurability of the Windows VDM
architecture.
 
Windows 95 suffers from this very same limitation. Any real-mode DOS
device drivers that you
wish to access from within Windows 95 must be loaded via CONFIG.SYS at
boot-time. Thus, if
you want access to a particular resource, and this resource requires a
DOS device driver, you'll be
forced to pay a penalty in terms of lost conventional memory and
potential compatibility problems
across all Windows 95 VDMs.
 
And what about troublesome applications like games? Windows 95 features a
special DOS session
- the "Single MS-DOS Application Mode" - that allows such applications to
execute
unencumbered by the confines of a traditional Virtual DOS Machine
(virtual I/O, video memory,
etc.). What Microsoft doesn't publicize, however, is the fact that, in
order to invoke this mode, you
must essentially shut-down Windows 95. All running applications close,
and the Windows 95 GUI
itself is paged to disk. This entire process can take up to a minute
depending on the speed of the
hardware in use and the number of open applications - quite a disruption,
especially when you're
trying to finish that last minute memo or download a large file from a
host system.
 
CHICAGO: AN ISV HEADACHE
 
One area where Microsoft continues to be uncertain is on the subject of
API standards. Independent
Software Vendors (ISVs) have been fighting an uphill battle in their
efforts to pin-down
Microsoft's overall API strategy. This is especially true of the native
Chicago API, Win32c, which
is itself a subset of the full Win32 API published nearly two years ago
and implemented on
Windows NT.
 
Further exacerbating the situation is Microsoft's continual updating of
the Win32c specification.
New APIs emerge almost monthly, many of which extend Win32 in ways that
tie applications to
the Chicago platform. This has aggravated ISVs who wish to write
cross-platform applications for
Windows, Windows NT, and Chicago. The only way these ISV's can write
cross-platform
applications, because of the different APIs support, is to poll the
Kernel, determine which API is
available and write dual or triple path code. With the APIs still in a
state of flux there is no
guarantee that the multiple path code will work.
 
What this means to the 32-bit operating system customer is a potential
delay in the release of
Chicago-compatible Win32 applications. Given the architectural
limitations of Chicago's Win16
application support - especially when multitasking and stability are
major considerations - lack of
Win32 applications could represent a serious obstacle to the platform's
widespread adoption.
Chicago needs Win32 applications before it even begins to make sense as a
replacement for
Windows 3.1. But given the confusion and frustration in the ISV community
it may be some time
before we see a substantial selection of Win32 titles.
 
As you can see, so far Microsoft's Windows 95 operating system is long on
hype and somewhat
short on technology. But if you've followed their product offerings over
the past few years, this
revelation should really come as no surprise. Microsoft has a track
record of delivering
"cosmetically advanced" operating systems while ignoring the more
important issues like
robustness, capacity, and true object-orientation.
Go to listserv.cesnet.cz LWGate Home Page.