SGI Windows NT Toolbox

Windows NT Primer
John Harrigan, SGI, 3/97
  1. Overview
  2. Windows NT At-A-Glance
    1. NT and Windows 95
    2. Software Development Under NT
  3. NT Terminology and Concepts
    1. Microsoft Foundation Classes (MFC)
    2. DirectX Software Development Kit
    3. Media Control Interface (MCI)
    4. Object Linking and Embedding (OLE)
    5. Component Object Model (COM)
    6. Subsystem
    7. Graphical Display Interface (GDI)
    8. Device Context (DC)
  4. NT System Services
    1. Memory Management
    2. Process Management
    3. Timers
    4. Threads
    5. File System
    6. File I/O
    7. Dynamic Link Libraries
    8. WIN32 IPC
  5. Window Management
    1. Windows
    2. Window Life-Cycle
    3. Fonts

     
  1. Overview
  2. 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 it’s 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.

     
  3. Windows NT At-A-Glance
  4. 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 it’s 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 it’s 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.

       
    1. NT and Windows 95
    2. 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 doesn’t 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.

       
    3. Software Development Under NT
    4. 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

      • Bristol Wind/U
      • MainSoft MainWin

        Their advertised advantages:

        • Single source code base (Win32 API)
        • Develop with Visual C++
        • Native performance with native look-and-feel
        • Provides robust consistent functionality across platforms
        • Large pool of trained talent
        • Massive documentation/samples/training

      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.

     
  5. NT Terminology and Concepts
    1.  
    2. Microsoft Foundation Classes (MFC)
    3. 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.

       
    4. DirectX Software Development KIT
    5. 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.

       
    6. Media Control Interface (MCI)
    7. 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.

       
    8. Object Linking and Embedding (OLE)
    9. 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.

       
    10. Component Object Model (COM)
    11. 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)

       
    12. Subsystem
    13. 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.

       
    14. Graphical Display Interface (GDI)
    15. 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.

       
    16. Device Context (DC)
    17. 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 Context’s 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.

     
  6. NT System Services
    1.  
    2. Memory Management
    3. 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, ...).

       
    4. Process Management
    5. 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.

       
    6. Timers
    7. 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.

       
    8. Threads
    9. 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)

       
    10. File System
    11. 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.

       
    12. File I/O
    13. 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 it’s virtual address space. Since multiple processes can map the same file, this functionality can be used to implement shared memory.

       
    14. Dynamic Link Libraries
    15. 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.

       
    16. WIN32 IPC
    17. 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).

     
  7. Window Management
  8. This section of the document discusses window management under NT, including fonts.

       
    1. Windows
    2. 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.

       
    3. Window Life-Cycle
    4. 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.

       
    5. Fonts
    6. 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.