ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/WINDOWS/PROGRAM/NTWN32.ZIP/NTWN32.TXT

Text File | 1992-01-02 | 20.0 KB | 391 lines

The Windows 32-Bit API: An Overview

Since its original release in 1985, MicrosoftR  WindowsTM has become
the leading graphical system for IBMR compatible personal computers.
Version 3.0, released in May 1990, was a milestone that broke the 640K
barrier of the Microsoft MS-DOSR operating system by running
applications in protected mode, thus making it possible to develop
much more sophisticated applications. This innovation spawned myriad
applications and is responsible for the huge success of the Windows
environment in the marketplace showcased by the volume of graphical
applications sold (see Figures 1 and 2).

Between May 1990 and May 1991, more than 4 million copies of Version
3.0 were sold. International Data Corporation estimates that an
additional 7.8 million copies will be sold during 1992. In addition,
more than 66 thousand Microsoft Windows Software Development Kits
version 3.0 have been shipped, a clear indication of the number of
applications likely to appear during the next 12 to 18 months. By
spring 1991, more than 1200 Windows-based applications were shipping.

Building on this achievement and on the success of independent
software developers, Microsoft is extending and expanding the Windows
environment so that Windows-based applications can run on a broad
range of computing platforms - from low-end battery-operated portables
to high-end RISC workstations and multiprocessor servers.

We are expanding Windows to make it fully 32-bit, and are adding
additional operating system services. Microsoft Windows for Pen
Computing and Microsoft Windows with Multimedia Extensions will also
take advantage of new hardware technologies.

Windows Today

Today many people think of Windows as a graphical add-on to the
familiar MS-DOS operating system they have used for years.  This
perception took much of the fear out of upgrading to Windows for the
end user. But in fact, Windows is not limited by MS-DOS.

Windows is a complete operating system that provides extra features on
top of MS-DOS and replaces certain MS-DOS features.  Windows Version
3.0 does not use MS-DOS screen or keyboard I/O, does not use MS-DOS
memory management, and can even bypass MS-DOS file I/O with new
Windows-specific device drivers. Version 3.0 Enhanced-mode can handle
32-bit device drivers that are not limited by the infamous 640K MS-DOS
barrier. These drivers talk through Windows to applications that are
also not limited by the constraints of MS-DOS.

The advantage of being able to work with MS-DOS is that it preserves
the value added by MS-DOS's long life span (in computer years).
Windows can run with MS-DOS TSRs, MS-DOS device drivers, and of
course, it can run MS-DOS applications.  Future versions of Windows
will continue to be available on MS-DOS.

The Windows Architecture

Since the IBM PC was introduced in 1981, personal computers have
become much more diverse in capability and in configuration. This
diversity will increase in the next few years as personal computers
based on RISC processors and multiprocessor systems are introduced.

These diverse systems have different operating system needs.  For
example, a low-end battery-operated portable requires minimal memory
and hard disk footprint to minimize weight and cost.  It also requires
power management to extend battery life.  In contrast, network servers
and mission-critical desktops require sophisticated security to ensure
the integrity of data.  RISC-based systems require portability for
both the operating system and the applications.

Some vendors feel that the diverse range of hardware requires totally
different operating systems with incompatible applications.  They sell
different operating systems for personal computers, workstations,
servers, and in the future, pen-based systems.  Each of their
operating systems require unique, incompatible applications.
Connectivity between these divergent platforms is complicated.

Microsoft is focused on a much simpler solution.  We're extending
Windows into multiple, fully compatible implementations.  Different
implementations of Windows will be optimized for different classes of
hardware.  Customer investment in Windows development and Windows
applications will be protected.  Windows applications will run across
the spectrum of hardware, from notepad-sized pen systems, to mission-
critical desktops, to multiprocessor and RISC based systems.

Microsoft Windows is evolving into a complete operating system
architecture.  The Windows architecture addresses diverse requirements
by supporting different modes of operation.  Today Windows has three
modes: Real-mode, Standard-mode, and Enhanced-mode.  Real-mode
provides compatibility with previous versions of Microsoft Windows.
Standard-mode is optimized for an 80286 processor and provides access
to the full 16 MB of memory supported by that chip.  Enhanced-mode
takes advantage of the 80386 and 80486 processors by providing support
for multiple DOS applications and thru a technique called demand
paging, provides applications with access to more memory then is
physically present in the machine.  All three modes support both DOS
and Windows applications.

Building upon the success of Microsoft Windows Version 3.0, Microsoft
will introduce Version 3.1 in late 1991.  Version 3.1 incorporates
significant customer feedback; it improves performance, introduces a
newly designed file manager, improves network connectivity, and
improves system reliability.  Version 3.1 will support Windows
Standard-mode and Enhanced-mode.

Also during 1991, Microsoft will enhance Windows Standard-mode and
Enhanced-mode by providing extensions for sound, animation, and CD-ROM
access, called Windows with Multimedia.  We will also release
extensions for clipboard and pen-style computing, called Microsoft
Windows for Pen Computing.

Windows NT

In 1992, Microsoft will introduce a new product called Windows NT (New
Technology).  Windows NT is built on a modern, 32-bit, operating
system kernel.   Windows NT will deliver an extremely robust client
environment for mission-critical applications, a high-end desktop
platform, and a portable, scalable server environment (See Figure 3).
Windows NT will also transform Windows into a Microsoft LAN Manager
server platform, thus adding a fourth server platform to the three
currently supported by LAN Manager:  OS/2R, UNIX, and VMSR.

Windows NT does not require DOS to function.  However, it is
compatible with the large installed base of DOS and Windows
applications.  In addition to compatibility with existing
applications, Windows NT includes the features required to meet the
needs of the high-end desktop and server marketplace in the 1990s and
beyond.

To support large server applications, Windows NT provides completely
symmetric multiprocessor support.  With Windows NT, tasks are
symmetrically distributed between processors on a per thread basis.
This design provides maximum utilization of each processor in a
multiprocessor system and simplifies the development of multiprocessor
applications.

Security is required for network servers and many mission-critical
applications.  To meet this need, Windows NT has been designed as a
secure operating system.  Microsoft is working with the U.S.
Government to certify Windows NT as C2-level secure.  In addition, the
internal design of Windows NT can be enhanced in future releases to B-
level security.

Windows NT is highly portable.  It is being developed concurrently on
x86 and MIPS-based RISC platforms. MIPS-based computers will be
available from more than 60 hardware manufacturers who are members of
the ACE (Advanced Computing Environment) consortium.  With Windows NT,
existing DOS and Windows programs will run unchanged on MIPS-based
computers.

In addition to these advanced capabilities, the kernel-based design of
Windows NT can be thought of as a nucleus which is compatible with
different operating system environments.  The kernel design provides
Windows NT compatibility with DOS and Windows applications.  It also
allows Windows NT to support the OS/2 and POSIX application program
interfaces, both of which are under development at Microsoft.  This
design also allows Windows NT to support applications written to the
new Windows 32-Bit application program interface.

Windows 32-Bit API

Developers and end-users have made enormous investments in Windows
programming and Windows applications.  Most of these applications have
been developed to run on both the 16-bit 80286 processor and the 32-
bit 80386 and 80486 systems.  Although highly capable, programs
written to the Windows 16-Bit API, which is supported by Windows 3.0,
are constrained by the memory limits inherent in a 16-bit
architecture.  Code must be divided into segments which cannot exceed
64K (65,536 bytes).  This makes programming more difficult.  It also
imposes a performance penalty on high-performance 80486 and RISC-based
systems.

The success of Windows Version 3.0, made it clear that an easy
migration path from existing 16-bit Windows applications to a 32-bit
programming interface was required.  Unfortunately, OS/2 Presentation
ManagerTM (PM) was not an appropriate path.  Although similar in
appearance from an end-user perspective, the programming details of
Windows and PM are completely different.  So different in fact that
most software developers found it necessary to completely rewrite
their application when going from Windows to Presentation Manager.
This is a major reason why there are so few OS/2 PM applications
available.

The Windows 32-Bit API (Windows 32) has been designed to make the
transition from the Windows 16-Bit API (Windows 16) to 32-bit as easy
as possible.  Only minimal changes have been made to the syntax of the
Windows 32 API.  The API names are the same as Windows 16.  The
semantics are identical.  The message order is identical.  In fact, it
is possible to keep a single source code base and compile that source
code into both 16-bit and 32-bit programs (see Figure 4).

While the Windows 32 API is extremely compatible with the Windows-16
API, it also contains significant new features.  These features
include preemptive multitasked processes that use separate address
spaces, preemptive threads, semaphores, shared memory, named pipes,
mailslots, and memory mapped file I/O.  GDI (Graphics Device
Interface) improvements include Bezier curves, paths, transforms, and
a device-independent color model.

The Windows 32-Bit API is fully supported in both Windows Enhanced-
mode and Windows NT-mode.  The Windows 32-Bit API will first be
available in the Windows NT product during 1992.  It will be added to
Windows Enhanced-mode in late 1992 or early 1993.  Programs written to
the Windows 32-Bit API will run binary compatibly on both Windows NT-
mode and Windows Enhanced-mode.  All Windows 32 features are supported
by both Windows Enhanced-mode and Windows NT-mode, including
preemptive multitasking.  Windows 32 programs will be fully source
compatible between  x86 and MIPS processors.  Software Developer Kits
for the Windows 32-Bit API will be available in late 1991.

The following highlights some key features of the Windows 32-Bit API.

Kernel: The Base Operating System

The Windows 32-Bit API on both Window NT-mode and Windows Enhanced-
mode provides preemptive thread-based multitasking. It also runs all
Windows 32-Bit and MS-DOS applications in separate address spaces so
that they cannot corrupt one another.

The Windows 32-Bit API is designed to be portable beyond the 80386 and
80486 processors and in particular to be portable to RISC
architectures. All these processors have different features but have
in common 32-bit addressing and paged virtual memory architectures.
Paged virtual memory is more efficient to implement and executes
faster than segmented virtual memory. Memory management in Windows 32-
Bit is secure because the operating system places different memory
objects in different pages of memory and allows an application to
control access permissions (Read, Write, Read/Write, Execute, and so
on) to memory objects.

Given a large 32-bit address space, the operating system can
conveniently and efficiently optimize file I/O because processes treat
the file as a very large memory object and randomly access that
object. The operating system, through page faulting, can detect read
access to a file and bring in that data. It can detect when a shared
file is written to and then write out that data. With process-settable
access permissions and sparse allocation of physical memory pages,
processes can implement very efficient data access, even when access
patterns are entirely unpredictable.

GDI Improvements: Beziers, Paths, Transforms, Device-Independent Color

GDI, the drawing API for Windows Versions 3.0 and 3.1, provides a
useful device-independent drawing set for applications. As output
devices have become more sophisticated, so have drawing needs; hence
GDI has been improved.

Some Windows applications for Versions 3.0 and 3.1 have needed to
implement high-level graphics functions using the low-level drawing
primitives of the Windows environment. Although this capability has
provided application vendors flexibility in extending the Windows GDI,
it has not allowed them to take seamless advantage of advances in
printer and display technology. Application developers have had to
code their own algorithms for displaying graphics such as Bezier
curves and paths. With the Windows 32-Bit API, developers can call new
high-level graphics features that will take advantage of the built-in
drawing capabilities in advanced output hardware. Under Windows 32,
displaying Bezier curves can be handled by the graphics engine or by
output devices that have implemented Bezier optimizations.

The Windows 32 GDI is a complete and general-purpose drawing package.
Bezier curves are a general-purpose curve primitive from which a
straight line can also be derived. This function combined with the
PolyBezier functionality makes it possible to draw any combination of
continuous lines and curves.

Windows 32  adds a Path API. A BeginPath EndPath sequence "closes"
the sequence of drawing primitives between Begin and End. Thus, a
BeginPath, PolyPolyBezier, EndPath sequence makes it possible to draw
an arbitrary number of different filled shapes.

The Windows 32 transform API maps the virtual two-dimensional surface
on which you draw to the two-dimensional output surface. This API,
combined with the TrueType font technology first available with
Windows Version 3.1, makes it possible to draw truly device-
independent graphics that the system can map to the display surface,
including the rotation of bitmaps, fonts, and metafiles.

Windows 32 will also provide a device-independent color model.
Computer monitors and color printers use different technology to
render colors.  Additive mixing is used by computer monitors (RGB or
Red, Green, Blue), while subtractive mixing (CYMK or Cyan, Yellow,
Magenta, Black) is used by color printers.  Without device-independent
color, the different approach used by monitors and printers can result
in mismatched colors.

The Windowing System and System Classes

The Windows windowing system is called User.  The most significant
change to User is the desynchronization of the per-window message
queue from the system message queue. This change prevents errant,
looping applications that stop processing their messages from blocking
the computer system's entire user interface, thus making other
applications unavailable.

With the addition of input queue time thresholds, the system can
provide default handling for a looping or an otherwise nonresponsive
process.  From an end-user perspective, this means the they can do
other things while one application is busy.  For example, if a word
processing program is busy printing a 100 page document, a user can
minimize that application and begin working on a spreadsheet.  This
effectively minimizes the time the user waits with an "hourglass" on
their screen.

The desynchronization of the message queue is completely compatible
with the Windows Versions 3.0 and 3.1 message model. The message
ordering is the same. If WM_xyz came after WM_abc, it still does. This
compatibility is entirely necessary because in Windows 32 systems,
existing Windows applications run on top of the Windows 32-Bit message
system. The messages are simply copied from the 32-bit stack to the
16-bit stack and passed onto the application; therefore message order
cannot change.

Networking Extensions

Each time the APIs are further standardized in a particular area, it
becomes easier to write significant new applications. Because of the
variety of networking layers, ranging from network card interfaces and
protocol stacks to the wide array of network IPC mechanisms,
networking is probably the most confusing interface for developers
today. Windows 32 will include standard network APIs that can replace
those that network providers have previously needed to supply. Windows
32 will expose driver-style interfaces similar to the WinNet APIs
provided by Windows Version 3.0 so that third-party vendors can plug
their network services into the Windows open architecture.

Some of the new, 32-bit WinNet APIs being defined are file, print,
named pipes, mailslots, server browsing and machine configuration.
This means applications can rely on a consistent programming interface
regardless of the underlying network.  Even if a network is not
present, the APIs are still available and will return appropriate
error codes.

The Windows 32-Bit API includes peer-to-peer named pipes, mailslots,
and APIs to enable RPC (Remote Procedure Call) compilers. With Windows
32, a mail-server vendor can build a messaging service on named pipes
and asynchrononous communication that will run on top of any network
operating system, protocol stack, or network card - each of which
could come from a different network vendor.

Compatibility with Windows 16-Bit APIs

Windows Version 3.0 and 3.1 applications will be able to run in
Windows Enhanced-mode and Windows NT-mode systems that support the
Windows 32 API. To be compatible with versions 3.0 and 3.1, all
Windows 16 applications will run as one process in one address space.
They will be nonpreemptive with respect to one another but preemptive
with respect to the rest of the system, which mirrors their behavior
under Windows Version 3.0 Enhanced-mode. Windows 16 applications run
against the Windows 32-Bit APIs without a "layer" and without any
state mapping or message reordering like that necessary to run them on
OS/2 version 2.0.

Windows executables will also run on RISC-based Windows NT machines
(see Figure 5).  Excellent performance is expected on this platform
because although some code will be run against 80286 emulator
technology, all Windows calls will be mapped directly to the Windows
NT software.

Windows 32-bit APIs-The Future of Windows

Millions of people are actively using Windows Version 3.0 today.
Corporations and independent software vendors are making major
commitments to Windows and investments in Windows applications.

To protect this investment, Microsoft is evolving Windows into a
complete architecture.  Through separate implementations, Microsoft
Windows will run on vastly different types of hardware; from pen-based
notepad computers to multiprocessor and RISC systems.

Windows NT and future versions of Windows Enhanced-mode will support
the Windows 32-Bit APIs.  Designed to simplify migration of Windows
applications from 16-bit to 32-bit, these APIs will also make it easy
to develop new 32-bit Windows applications.  They contain significant
new features which will enable a new generation of powerful Windows
applications.

In addition, the Windows 32-Bit APIs will be used as the foundation
for future versions of Windows under development at Microsoft.  This
technology, often called Information at Your FingertipsTM, will make
it even easier to use personal computers and will provide significant
new functionality to Windows users.

Microsoft and MS-DOS are registered trademarks,Windows and Information
at Your Fingertips are trademarks of Microsoft Corporation.

OS/2 is a registered trademark and Presentation Manager is a trademark
licensed to Microsoft.

IBM is a registered trademark of International Business Machines.

VMS is a registered trademark of Digital Equipment Corporation.