Windows NT Primer
John Harrigan, SGI, 3/97
- Overview
- Windows NT At-A-Glance
NT and Windows 95
Software Development Under NT
- NT Terminology and Concepts
Microsoft Foundation Classes (MFC)
DirectX Software Development Kit
Media Control Interface (MCI)
Object Linking and Embedding (OLE)
Component Object Model (COM)
Subsystem
Graphical Display Interface (GDI)
Device Context (DC)
- NT System Services
Memory Management
Process Management
Timers
Threads
File System
File I/O
Dynamic Link Libraries
WIN32 IPC
- Window Management
Windows
Window Life-Cycle
Fonts
- Overview
The purpose of this document is to familiarize the reader with the Microsoft
Windows NT operating system. I wrote this document in light of several recent
visits to application developers who want to run their NT developed code
on IRIX.
This document is work-in-progress. In its current form, it gives an overview
of NT, introduces some NT terminology and discusses window management under
NT. I plan to increase the scope of the document in the future to include
NT to IRIX porting issues.
- Windows NT At-A-Glance
Windows NT is a 32-bit operating system from Microsoft with multitasking,
networking, and enhanced security. NT stands for "New Technology". Compared
to previous Windows operating systems, the security and robustness its
client-server model provides is significant. The flat memory addressing
and separation of task address spaces have considerable advantages for NT
programmers over the Windows 95/3.x environment.
NT has evolved from the following background:
- DOS - command line driven, no multitasking or networking. Single address
space.
- Windows3.x - extension of DOS, visual way of working, multiple applications
open (multitasking through application timer messages), no networking. Single
address space.
- OS/2 - (joint IBM/Microsoft effort) multitasking OS but still layered networking
Because of its security and robustness features, NT represents a major
improvement over other Windows (Win3.x, Win95) as an application development
environment. Microsoft targets to the power user, including the software
developer. An increasing number of application developers are adopting NT as a development
platform, some to the exclusion of Unix.
- NT and Windows 95
Why Both NT and WIN95 ? Making one operating system that's 100% compatible
with all your DOS and 16-bit Windows apps and having that operating system
be absolutely reliable, C2-securable and portable to RISC and multiprocessor
hardware; appears to be impossible (at least for Microsoft :> ).
NT is stable and robust, Windows 95 is not. NT machines run for weeks without
crashing, Windows95 machines do not. Windows 95 does have advantages for
some users: it runs in about half as much RAM as NT, has more driver support,
and is still a better platform for games and DOS-based legacy applications.
NT and Windows 95 have some considerable differences which limit NT's compatibility
with other Windows OS':
- NT doesn't support Windows 95's VxD virtual device driver model. As such
peripheral support under NT is not as complete as under Windows95/3.x.
- NT doesnt guarantee compatibility with DOS-based applications. This was
a focus for Windows95.
- Diifferent file-systems (NTFS vs. FAT), although NT can be configured to
run on a FAT drive partition.
- NT doesn't support PnP (plug and play). Interfacing new devices to an NT
machine requires more manual effort than Windows95
- Internationalization is different under NT and Windows95. Applications using
the NT approach will not run on Windows 95, and international applications
written for Windows 95 are not guaranteed to work on NT.
- Software Development Under NT
The most common software development environment in use on NT is Microsoft
Visual C++ with MFC (see "Microsoft Foundation
Classes" below)
Two companies provide the Win32 API and Microsoft Foundation Classes on
UNIX
NT's font support, built around Microsoft's TrueType technology, is considered
weak. Adobe never finished their NT version of Adobe Type Manager (ATM).
NT uses COFF (Common Object File Format).
Win32 - The Windows application programming interface (Win95 and NT API)
Win32s - the subset of the Win32 API supported on Windows 3.x/95 based machines.
Provides a way for application developers to develop applications on NT
(using a large subset of NT functions) and run them on existing Windows
machines (Win3.x, Win95). Missing are: UniCode; Threading; Security; Console
Support and Enhanced GDI.
- NT Terminology and Concepts
- Microsoft Foundation Classes (MFC)
Microsoft Foundation Class library. C++ application framework with pre-built
components and helper classes used by over 1 Million developers. Promotes
object-oriented programming and a portable, yet extensible, interface. MFC
consists of classes, global functions, global variables, and macros.
The Microsoft Foundation Class Library is an object-oriented interface to
Windows that was designed to meet the following goals:
- Effort of programming an application for Windows is significantly reduced
- Execution speed comparable to that of the C-language API
- Minimum code size overhead
- Ability to call any Windows C function directly
- Easier conversion of existing C applications to C++
- Ability to leverage from the existing base of C-language Windows programming
experience
- Easier use of the Windows API with C++ than with C
- True Windows API for C++ that effectively uses C++ language features
The core of the Microsoft Foundation Class Library is an encapsulation of
a large portion of the Windows API (Win32) in C++ form. Library classes
represent windows, dialog boxes, device contexts, common GDI objects such
as brushes and pens, controls, and other standard Windows items. The single
characteristic that sets the Microsoft Foundation Class Library apart from
other class libraries for Windows is the very close mapping to the Windows
API written in the C language. Further, you can generally mix calls to the
class library freely with direct calls to the Windows API. This direct access
does not, however, imply that the classes are a complete replacement for
that API. Developers must still occasionally make direct calls to some Windows
functions.
- DirectX Software Development KIT
The Microsoft® DirectX Software Development Kit (SDK) provides a finely
tuned set of application programming interfaces (APIs) that provide you
with the resources you need to design high-performance, real-time applications.
DirectX technology will help build the next generation of computer games
and multimedia applications. The current version of the SDK is DirectX 3.
Microsoft developed DirectX because it wanted the performance of applications
running in the Microsoft Windows® operating system to rival or exceed the
performance of applications running in the MS-DOS® operating system or on
game consoles. This SDK was developed to promote game development for Windows
by providing you with a robust, standardized, and well-documented operating
environment for which to write games. DirectX 3 allows you access to the
display and audio hardware while insulating you from the specific details
of that hardware. The overriding design goal in DirectX 3 is speed. Instead
of providing a high-level set of functions, DirectX provides a device-independent
interface, allowing applications to take full advantage of the capabilities
of the supported hardware and emulates hardware features in software whne
the feature is not present in hardware. The components of DirectX and a
brief description follow:
- DirectDraw - DirectDraw is a software interface that provides direct access to display
devices, particlularly display memory, while maintaining compatibility and
coordinating with the Windows graphics device interface (GDI). It is not
a high-level application programming interface (API) for graphics (see Direct3D
below).
- DirectSound - provides low-latency mixing, hardware acceleration, and direct access
to the sound device. It provides this functionality while maintaining compatibility
with existing Windows®-based applications and device drivers
- DirectPlay - a software interface that simplifies your application's access to communication
services. DirectPlay uses a simple send/receive communication model to implement
a connectivity API tailored to the needs of multiplayer applications.
- Direct3D - the advanced 3D graphics solution (along with OpenGL) available on NT.
Direct3D is a complete set of real-time 3D graphics services that delivers
fast software-based rendering of the full 3D rendering pipeline (transformations,
lighting, and rasterization) and transparent access to hardware acceleration.
Supports both a Retained mode and Immediate mode. This API is built on DirectDraw.
- DirectInput - provides fast and consistent access to keyboards; mouse; analog and digital
joysticks; touchscreens; tablets; light pens; VR headgear and other devices.
- DirectSetup - a simple application programming interface (API) that provides you with
a one-call installation for the DirectX 3 components. Applications and games
that depend on DirectX use the DirectXSetup API function to install their
system components on top of an existing Windows installation. This function
updates the display and audio drivers to support DirectX (if required) during
the DirectX installation process.
- AutoPlay - automates the procedures for installing and configuring products designed
for Windows-based platforms that are distributed on compact discs. When
you insert a disc containing AutoPlay into a CD-ROM drive on a computer
running Windows, AutoPlay automatically starts an application on the disc
that installs, configures, and runs the selected product.
- Media Control Interface (MCI)
A high-level command interface to multimedia devices and resource files.
MCI provides applications with device-independent capabilities for controlling
audio and visual peripherals. Using MCI, an application can control multimedia
devices using simple commands like open, play, and close. MCI commands are
a generic interface to multimedia devices.
- Object Linking and Embedding (OLE)
OLE facilitates application integration by defining a set of standard interfaces,
groupings of semantically related functions through which one application
accesses the services of another. OLE lets users manipulate information
in an intuitive manner, using an environment that is more "document-centric"
and less "application-centric". Users can create compound documents with
data, or objects, of different formats, and focus directly on the data rather
than on the applications responsible for the data. The data can be embedded
within the document, or linked to it, so that only a reference to the data
is stored in the document.
OLE services are organized in a two-tier hierarchy. The lower level contains
the infrastructure services; basic services that provide the means by which
features can be implemented and used. These include interface negotiation,
memory management, error and status reporting, interprocess communication,
structured storage, and data transfer. The upper level of the OLE service
hierarchy provides application features; those services that benefit the
end user. Some of the features currently available include compound-document
management, in-place activation, OLE automation, and drag-and-drop operations.
Because OLE is open and extensible, new features will be added in the future.
- Component Object Model (COM)
The object-oriented programming model that is the basis for the OLE infrastructure.
COM provides the following:
- The communications interface between the client and the service provider
(object)
- Objects can support multiple interfaces
- Object management (multiple clients into an object)
- Memory management (memory passed between clients and objects)
- Error and status reporting
- Interprocess Communication (IPC)
- Dynamic loading of objects (EXE or DLL - remote or local)
- Subsystem
This concept is central to the operation of NT. A subsystem can be thought
of as an API and its support environment. Clients (application code) communicate
with subsystems through LPC (local procedure calls). Subsystems can call
other subsystems as well as the NT executive (privileged level 0 - kernel
mode). Subsystems run as a separate process with address space isolation,
and can be multi-threaded. Windows NT comes with the following subsystems:
- Win16 - Windows 3.x
- DOS
- OS/2 1.3 - 16bit version of OS/2 API (no presentation manager)
- Posix - Class C security and Posix 1003 compliance
- Win32 - only subsystem which supports flat-model 32-bit programming. This
subsystem implements the predominant API in Windows, Win32.
- Graphical Display Interface (GDI)
These calls, implemented in the Win32 subsystem, perform device-independent
graphics operations in an application for the Microsoft Windows operating
system. These operations include the creation of line, text, and bitmap
output on different output devices. GDI is implemented in the Win32 Subsystem.
Win32-based applications can draw and print output on a variety of devices.
The software that supports this device independence is contained in two
dynamic-link libraries. The first, GDI.DLL, is referred to as the graphics
device interface (GDI); the second is referred to as a device driver. The
name of the second depends on the device where the application draws output.
For example, if the application draws output in the client area of its window
on a VGA display, this library is VGA.DLL; if the application prints output
on an Epson FX-80 printer, this library is EPSON9.DLL.
- Device Context (DC)
A link between a Windows application, a device driver, and an output device,
such as a printer or plotter. Operations which can be performed on Device
Contexts include: save/restore; delete; create; get and release. An application
must inform GDI to load a particular device driver and, once the driver
is loaded, to prepare the device for drawing operations (such as selecting
a line color and width, a brush pattern and color, a font typeface, a clipping
region, and so on). These tasks are accomplished by creating and maintaining
a device context. A device context is a structure that defines a set of
graphic objects and their associated attributes, and the graphic modes that
affect output.
- NT System Services
- Memory Management
In the Win32 API, each process has its own 32-bit virtual address space
that enables addressing up to 4 gigabytes (GB) of memory. The 2 GB in low
memory (0x00 to 0x7FFFFFFF) are available to the user, and the 2 GB in high
memory (0x80000000 to 0xFFFFFFFF) are reserved for the kernel. The virtual
addresses used by a process do not represent the actual physical location
of an object in memory. Instead, for each process, the kernel maintains
a page map, an internal data structure used to translate virtual addresses
into corresponding physical addresses.
The total amount of storage available to all executing processes is the
sum of the physical memory, RAM, and the free space on disk available to
the paging file, a disk file used to increase the amount of physical storage.
Physical storage and the virtual (logical) address space of each process
are organized into pages, units of memory, whose size depends on the host
computer. For example, on x86 computers the host page size is 4 kilobytes
(K).
A process can use the GlobalAlloc and LocalAlloc functions to allocate memory.
In the linear 32-bit environment of the Win32 API, the local heap and the
global heap are not distinguished. As a result, there is no difference between
the memory objects allocated by these functions. Win32 processes can safely
use the standard C library functions (malloc, free, and so on) to manipulate
memory. A bevy of virtual memory calls are supported which allow finer control
over allocated memory (read-only, reserve pages, lock pages in RAM, manage
private heaps, ...).
- Process Management
An application written for Windows can consist of more than one process,
and a process can consist of more than one thread. The Win32 application
program interface (API) supports multitasking, which creates the effect
of simultaneous execution of multiple processes and threads. The Win32 API
is designed for preemptive multitasking; this means that the system allocates
small slices of CPU time among the competing threads. Threads are allowed
to execute for a length of time, known as a quantum, before NT may decide to let another thread take over the CPU. The scheduler invocation
rate for Windows NT is hard-coded to average 10 milliseconds over long periods.
The system scheduler controls multitasking by determining which of the competing
threads receives the next slice of the processor's time. Each time slice
consists of a fixed number of clock ticks. The Windows scheduler is preemptive,
gaining control whenever a clock interrupt occurs and decrementing the count
of clock ticks remaining in the time slice of the currently executing thread.
If the count goes to zero, the scheduler determines which thread runs next.
Each thread has a scheduling priority associated with it that is determined
by the parent process at thread creation time. The parent can modify the
priority of a thread by using the SetThreadPriority call (dynamic priority
boost). Note that in NT a thread gets its quantum refreshed every time its thread or process priority is set. This means that a thread can reset its
quantum by calling SetThreadPriority (without changing its priority) before its turn runs out.
If it continues to do this it will effectively have an infinite quantum. Microsoft will probably
fix this, someday.
- Timers
Windows NT bases all of its timer support off of one system clock interrupt,
which by default runs at a 10 millisecond granularity, the same as the quantum. This
is therefore the resolution of standard Windows timers. Applications can use the NtSetTimerResolution call to change
the timer resolution. On x86 based systems the legal range of timer values
supported is 1-10 milliseconds.
Note that changing timer resolution under NT has an undesirable side-effect
on the NT Scheduler. The NT scheduler wakes up at each timer tick, adjusts the currently executing thread's quantum counter by decrementing it a fixed
amount, and then sees if it has reached zero, which means that its slice has expired
and that another thread may be scheduled. Since NT bases all of its timers off of
one interrupt, setting the Timer resolution value to something other than
a rate that is integrally divisible into 10 milliseconds (1, 2, or 5ms)
will cause scheduler fluctuations.
Let's examine what happens when the timer's resolution is set to 4 milliseconds.
On the first tick the quantum interval counter is decremented to 6. Since the quantum
(10ms) hasn't been exceeded, the scheduler isn't invoked. On the second
tick, the counter is at 2 so no scheduler invocation. On the third tick,
after 12ms the interval counter meets the requirements of being zero (or
negative) and the scheduler is invoked, but 2ms too late. The quantum is
20% longer than it should be. Then 10 milliseconds is added to the interval counter's value of -2 milliseconds so it becomes 8 milliseconds. The next
tick of the clock the interval counter is decremented by 4ms to 4 and on the following
tick to 0, where the scheduler is invoked again after 8ms (20% too soon). As this example demonstrates,
the quantum ends up jittering between 12 and 8 milliseconds. This jitter can cause specific threads to be unfairly scheduled.
- Threads
A process is a collection of virtual memory space, code, data, and system
resources, while a thread is code that is to be serially executed within a process. A processor executes threads,
not processes, so each 32-bit application has at least one process and one thread. A process always has
at least one thread of execution, known as the primary thread, and can have multiple threads in addition to this. Once a thread begins to execute, it
continues until it is killed or until it is interrupted by a thread with higher priority (by a user action or the kernel's
thread scheduler). Each thread can run separate sections of code, or multiple threads can execute the same
section of code. Threads executing the same block of code maintain separate stacks. Each thread in a process shares
that process's global variables and resources.
The Win32 API provides a set of synchronization objects and functions you
can use to coordinate multiple threads.
While this topic needs more digging, Windows NT libraries are thread-safe.
IRIXs' lack of thread-safe libraries, particularly X, GLX and OpenGL cause
grief for applications developed under NT. For instance, it is possible to create multiple threads in an OpenGL
application and have each thread call OpenGL functions to draw an image. The Microsoft software library
has sample code demostrating this at (http://www.microsoft.com/kb/articles/q128/1/22.htm)
- File System
Windows NT supports the following three file systems:
- NTFS - NT compatible file system
- FAT - DOS compatible file system
- HPFS - OS/2 compatible file system
The FAT file system is the default file system for Windows NT and offers
interoperability with Windows/DOS. Some public domain utilities exist which
allow Windows95 to read an NTFS volume but as shipped by Microsoft, Windows95/3.x
cannot read or write to NTFS based volume. In fact a Windows 95 machine
will not recognize any NTFS disks that are connected to it. As such, the
boot disk in a machine which has both Windows95 and NT installed (dual boot)
must be a FAT file system. The NT operating system can be installed on an
NTFS based disk/partition but it will not be accesible while the machine
is running Windows95.
The NTFS is considered to have the best performance of the three and is
designed to restore consistency to a disk after a CPU failure, system crash,
or I/O error. NTFS also includes features not present in HPFS or FAT, such
as security, Unicode filenames, automatic creation of MS-DOS aliases, multiple
data streams, and unique functionality specific to the POSIX subsystem.
The Windows file functions enable applications to access files regardless
of the underlying file system. However, capabilities may vary depending
on the file system and/or operating system in use.
The FAT file system requires file and directory names to have the 8.3-character
filename format, the HPFS file system allows names to be up to 254 characters,
and the NTFS file system allows names to be up to 255 characters. All three
file systems use the backslash (\) character to separate directory names
and the filename when forming a path.
- File I/O
Win32 implements calls for creating/deleting, opening/closing and moving/copying
files. Every open file has a file pointer that specifies the next byte to
be read or the location to receive the next byte written. When a file is
opened for the first time, Windows places the file pointer at the beginning
of the file. As each byte is read or written (using the ReadFile/WriteFile
functions), Windows advances the file pointer. An application can also move
the file pointer by using the SetFilePointer function.
Win32 also supports asynchronous, or overlapped I/O. Overlapped I/O enables
a single thread to initiate multiple time consuming I/O requests that can
run concurrently. This asynchronous I/O can be performed on files, pipes,
serial communications devices, or tape devices.
NT, like IRIX, supports Memory-Mapped file I/O (File Mapping). As such a
program can map a disk file into its virtual address space. Since multiple
processes can map the same file, this functionality can be used to implement
shared memory.
- Dynamic Link Libraries
Similiar to DSO's in Irix, Windows supports dynamic linking providing a
way for a process to call a function that is not part of its executable
code. The executable code for the function is located in a dynamic-link
library (DLL), containing one or more functions that are compiled, linked,
and stored separately from the processes using them. A DLL attaches to a
process when the process starts or when one of its threads calls the LoadLibrary
function. When a DLL attaches to a process, the operating system maps the
DLL module into the address space of the process, making the DLL's executable
code available to the process. When a DLL detaches from a process at process
termination or as a result of a call to the FreeLibrary function, the DLL
module is unmapped from the address space of the process.
- WIN32 IPC
Win32 application programmers are provided with a number of interprocess
communication methods. Even though I discussed some of them above, I wanted
to give this quick summary of them. It is likely that an application will
support IPC by using several of the mechanisms described below. For example,
all Windows-based applications should provide at least minimal support for
the clipboard. In addition, DDE and OLE may offer the application an opportunity
to communicate in a loosely coupled way with a wide variety of applications
that support these protocols.
- FILE MAPPING - enables a process to treat the content of a file as if it
were a block of memory in the process's address space. Therefore, instead
of using file input and output (I/O) operations, the process can use simple
pointer operations to examine and modify the contents of the file. The Win32
API enables two or more processes to access the same file-mapping object
. Each process receives a pointer to memory in its own address space. With
this pointer, the process can read or modify the contents of the file.
- PIPES - Win32 supports anonymous and named pipes which can be used to transfer
data back and forth between processes. Unlike anonymous pipes, however,
named pipes can operate between unrelated processes and across a network
between computers.
- MAILSLOTS - Mailslots provide a one-way interprocess communications capability.
Any process can create a mailslot and become a mailslot server. Other processes,
called mailslot clients, can gain access to the mailslot by its name and
send messages to the mailslot server process. A process can be both a mailslot
server and a mailslot client, so two-way IPC is possible with multiple mailslots.
- CLIPBOARD - The clipboard provides a mechanism for the well-established
cut-copy-paste model for simple data sharing between Windows-based applications.
It enables an application to read or write data in many different standard
and application-defined formats. The clipboard acts as a central depository
for data sharing among applications.
- DYNAMIC DATA EXCHANGE (DDE) - Dynamic data exchange (DDE) is a protocol
for interprocess communications that enables applications to exchange data
in a variety of formats. Applications can use DDE for one-time data exchanges
or for ongoing exchanges in which the applications update one another as
new data becomes available. The data formats used by DDE are the same as
those used for the Windows clipboard IPC mechanism. DDE can be thought of
as an extension of the clipboard mechanism.
- OLE - Object linking and embedding (OLE) applications manage compound documents
¾ that is, documents made up of data from a variety of different applications.
OLE provides services that make it easy for applications to call on other
applications for data editing. For example, an OLE-aware word processor
could embed a graph from a spreadsheet.
- DLL - It is possible to build a Win32 dynamic-link library (DLL) so that
its global data is shared with all processes that call the DLL. Therefore,
cooperating processes can call the DLL to examine and modify global data
owned by the DLL. To avoid conflicts between multiple processes, the access
to the shared memory should be controlled within the DLL with a semaphore
or other synchronization approach.
- RPC - The Win32 API provides remote procedure calls (RPC) to enable applications
to call functions remotely. With RPC, communication with other processes
becomes as easy as calling a function. RPC operates between processes on
a single computer or on different computers on a network. One way to think
of RPC is as a DLL that works on a network. The RPC provided by the Win32
API is compliant with the Open Software Foundation (OSF) Distributed Computing
Environment (DCE).
- Window Management
This section of the document discusses window management under NT, including fonts.
- Windows
A window in an application written for the Windows operating system is a
rectangular area of the screen where the application displays output and
receives input from the user. A window shares the screen with other windows,
including those from other applications. Only one window at a time can receive
input from the user. The user can use the mouse, keyboard, or other input
device to interact with this window and the application that owns it.
Windows are the only means a Windows-based application has to interact with
the user and accomplish tasks, so one of the first tasks of a Windows-based
application is to create a window. Elements of the Microsoft® Win32® API
allow applications to create and use windows; manage relationships between
windows; and size, move, and display windows.
DESKTOP WINDOW
- When Windows starts, it automatically creates the desktop window. The desktop window is a system-defined window that paints the background
of the screen and serves as the base for all windows displayed by all Win32-based
applications.
APPLICATION WINDOWS
- Every Win32-based application creates at least one
window, called the main window that serves as the main window for the application.
This window, serves as the primary interface between the user and the application.
Most applications also create many other windows, either directly or indirectly,
to perform tasks related to the main window. Each window plays a part in
displaying output and receiving input from the user.
- Window Life-Cycle
The first step in a window's life-cycle is creation. Given a registered
window class with a corresponding window procedure, the application uses
the CreateWindow function to create the window. This function directs Windows
to prepare internal structures for the window and to return a unique integer
value, called a window handle, that the application can use to identify
the window in subsequent function calls.The programmer can dictate the original
window state: open (minimized, maximized, or restored), hidden or visible,
and enabled or disabled.
After a window has been created, it must be opened (displayed) before it
can be used. Specify the WS_VISIBLE window style in the CreateWindow function
to open the window immediately after creation, or it can wait until later
and call the ShowWindow function to open the window. When a window is moved,
Windows automatically copies the contents of the client area to the new
location. This saves time because a window does not have to recalculate
and redraw the contents of the client area as part of the move. If the window
moves and changes size, Windows copies only as much of the previous client
area as is needed to fill the new location. If the window increases in size,
Windows copies the entire client area and sends a WM_PAINT message to the
window to fill in the newly exposed areas.
When the window is no longer needed or the application is terminated, the
window must be destroyed. This is done by using the DestroyWindow function.
When a window is destroyed/closed, the application should free any allocated
memory and close any open data files.
- Fonts
In Windows, a font is a collection of characters and symbols that share
a common design. The three major elements of this design are referred to
as typeface, style, and size. Windows organizes fonts by family; a family
is a set of fonts having common stroke width and serif characteristics.
Windows applications can use three different kinds of font technologies
to display and print text:
- Raster - stored as bitmaps
- Vector - stored as GDI calls
- True Type - stored as collections of points and hints that define character
outlines
The SYSTEM sub-directory of a user's Windows directory (the directory in
which Windows is installed) contains the system's font resource files. The
GDI portion of Win32 implements a multitude of FONT related calls.The Win32
application programming interface (API) provides a complete set of functions
to format and draw text in an application's client area and on a page of
printer paper. These functions can be divided into two categories: those
that format the text (or prepare it for output) and those that actually
draw the text. The formatting functions align text, set the intercharacter
spacing, set the text and text-background colors, and justify text. The
drawing functions draw individual characters (or symbols) or entire strings
of text.
Copyright © 1997, Silicon Graphics, Inc.
|