Mapping X Windows Terminology to Microsoft Windows

The graphical models of UNIX and Microsoft Windows are very different. There are conceptual similarities, but little side-by-side mapping is possible. This section describes as many connections as possible.

In the headings of this section, the Win32 GDI term is followed by the corresponding X Windows term in the following format:

X Windows term vs. Win32 term

Callback vs. WindowProc

Win32 uses the WindowProc function in the same capacity as Callback in X Windows. An X widget can have a list of callbacks associated with it, but a Win32 window has a single entry point for handling messages sent to it.

Client vs. Client Window

X Windows comprises a protocol that describes how a client interacts with a server that could be running on a remote computer. How objects are drawn is the responsibility of the server. This provides device independence for the client application because it is not responsible for knowing anything about the physical hardware.

In the Microsoft Windows environment, the graphics device interface (GDI) API provides this layer of device independence. Windows-based applications, like X clients , are not required to access graphics hardware directly. GDI interacts with the hardware by using device drivers on behalf of the application.

A single Windows-based application can contain any number of separate windows. Each of these can have a window frame, caption bar, system menu, minimize and maximize buttons , and its own main display area, which is referred to as the client window.

Windows multiple document interface (MDI) applications have three kinds of windows: a frame window, an MDI client window, and a number of child windows. The term client window takes on a special meaning in this case. For more information about MDI, see the MDI documentation on the MSDN Web site ( http://msdn.microsoft.com/ ) or the Platform SDK.

Console Mode vs. Command Window

If X Windows or some other graphical user interface is not running on a UNIX system, a user must work in text only or in console mode .

Think of Microsoft Windows as exactly the opposite . If a console is not running, the user must work in GUI mode. Windows text-based mode is provided by running the Cmd.exe utility. This environment is also referred to as a command window or the MS-DOS prompt. To run the Cmd.exe utility, click Start , and then click Run . Type cmd , and then click OK . Or, on the keyboard, press the Windows key and then press R . The Run dialog box appears.

Developers can also use the Console API to build native Win32-based console applications. Search for Console Functions in the MSDN Web site ( http://msdn.microsoft.com/ ).

DPI vs. Screen Resolution

When starting an X Windows session, using the -dpi (dots per inch) option can improve appearance on displays with larger resolutions , such as 1600x1200. The- dpi option also helps to work around possible font issues.

A Windows-based application is usually built with no assumptions about the capabilities of the system it will run on. System APIs are used to calculate proper scaling and other characteristics. GetDeviceCaps() is used to obtain the DPI of the system. GetSystemMetrics() and SystemParametersInfo() provide information about practically every graphical element needed to calculate sizes for fonts and other graphical elements. For more information, search for dots per inch on the MSDN Web site ( http://msdn.microsoft.com/ ).

Graphics Context vs. Device Context

The X Windows graphics context (GC) contains required information about how drawing functions are to be executed. The Win32 device context (DC) provides similar information. The functions used in each are summarized in Table 11.9.

Table 11.9: X Windows GC and Win32 DC Comparable Functions
Xlib	Win32
XtGetGC	GetDC
XtReleaseGC	ReleaseDC
XCreateGC	CreateDC
XFreeGC	DeleteDC

For more information about using GC and DC, see the sections under Drawing earlier in this chapter.

Resources vs. Properties

In X Windows terminology, a widget is defined by its resources . Width, height, color , and font are examples of resources. Resources can be managed by using the XtVaCreateManagedWidget() method, or by using resource files or XtVaGetValues() and XtVaSetValues() .

In Win32 terminology, a control is defined by its properties . For example, a text control has the following properties: Center Vertically, No Wrap, Transparent, Right Aligned Text, and Visible.

Resource Files vs. Registry

X Windows systems use configuration files referred to as resource files to store information about system settings or preferences for a particular X Windows client.

In a Windows-based system, this type of information is stored in the registry . The registry stores data in a hierarchically structured tree. There is a Win32 API with more than 40 functions to help access the registry. For more information, search for registry or registry functions on the MSDN Web site ( http://msdn.microsoft.com/ ).

Resource file can take on another meaning in Windows-based application development. Resources, like widgets, are objects, such as menus , dialog boxes, cursors , strings, bitmaps, and user defined data, that are used in an application. Resource files have an extension of .rc and contain a special resource language (script) that is compiled by the resource compiler. The resulting file (.res) is then linked with the containing application.

For more information, search for using resources on the MSDN Web site ( http://msdn.microsoft.com/ ).

Root Window vs. Desktop Window

All X Windows windows are descendents of the root window. In the Windows environment, the desktop window is a system-defined window that is the base for all windows displayed by all applications.

/bin vs. System32

In Windows, the /System32 directory is roughly equivalent to the /bin directory on a UNIX system. This is where the system executable files are located. The /System32 directory is located in the system root directory. To find system root, at a command prompt, type set and press ENTER. This displays a listing of the current environment. In the list, locate SYSTEMROOT. Under SYSTEMROOT, there is an entry similar to SYSTEMROOT=C:\WINNT. This is the system directory, and under that directory is the /System32 directory.

/usr/bin vs. Program Files

The Program Files directory on a Windows-based system is similar to the /usr/bin directory on a UNIX system. This is a default location for user applications. In Windows, a user can create more than one such directory. Each drive, for example, might have a Program Files directory. The system environment variable ProgramFiles contains the path of one default location, for example, ProgramFiles=C:\ProgramFiles.

/usr/lib vs. LIB Environment Variable

In Windows, the path to user libraries can be anywhere . To manage this relationship, retrieve or set the system environment variable LIB.

/usr/include vs. INCLUDE Environment Variable

In Windows, the path to user include files may be anywhere. To manage this relationship, retrieve or set the system environment variable INCLUDE.

Pixmap or Bitmap vs. Bitmap

In X Windows, bitmap and pixmap have the same usage as Win32 bitmaps. For example, they can be used as pictures, fill patterns, icons, and cursors. They are, however, very different in form.

The following X Windows example represents a simple 16x16 X figure:

 #define simple_width 16 #define simple_height 16 static unsigned char simple_bits[] = { 0x01, 0x80, 0x02, 0x04, 0x20, 0x08, 0x10, 0x10, 0x08, 0x20, 0x04, 0x40, 0x02, 0x80, 0x01, 0x80, 0x01, 0x02, 0x20, 0x04, 0x10, 0x08, 0x08, 0x10, 0x04, 0x20, 0x02, 0x40, 0x01, 0x80  };

The following Win32 example also represents a simple 16x16 X figure:

 000000  42  4D  7E  00  00  00  00  00  00  00  3E  00  00  00  28  00 000010  00  00  10  00  00  00  10  00  00  00  01  00  01  00  00  00 000020  00  00  40  00  00  00  CA  0E  00  00  C4  0E  00  00  00  00 000030  00  00  00  00  00  00  00  00  00  00  FF  FF  FF  00  7F  FE 000040  00  00  BF  FD  00  00  DF  FB  00  00  EF  F7  00  00  F7  EF 000050  00  00  FB  DF  00  00  FD  BF  00  00  FE  7F  00  00  FE  7F 000060  00  00  FD  BF  00  00  FB  DF  00  00  F7  EF  00  00  EF  F7 000070  00  00  DF  FB  00  00  BF  FD  00  00  7F  FE  00  00

Window Manager vs. Windows 2000 and Windows XP

A special kind of X Windows client called the Window Manager provides a consistent working environment in the root window.

In a Microsoft Windows environment, the operating system itself is the window manager, and it provides the desktop window. When a user logs on, the system creates three desktops within the WinSta0 windows station. For more information, search for WinSta0 on the MSDN Web site ( http://msdn.microsoft.com/ ).

Widgets are usually represented as controls in Win32-based applications. Like the X Windows environment, Win32 offers many widgets to choose from, and a great number of third-party versions are available.

Sometimes deciding exactly what to call which is difficult. For example, X Windows dialog boxes are widgets. In Win32, however, dialog boxes are not considered to be controls, although objects such as dialog boxes, buttons, and scroll bars and so on, are all windows.

X Library [Xlib] [X11] vs. Gdi32.lib

The X Windows library [Xlib][X11] is the lowest level library. Like Gdi32.lib, it provides all the basic drawing functions.

X Toolkit [Intrinsics] [Xt] vs. User32.lib

The X Toolkit (Xt) is a library that accesses the lower-level graphics functionality of Xlib (X Windows) and provides user interface elements such as menus, buttons, and scroll bars. It is similar to User32.lib, except that in the Win32 environment the look and feel of widgets or controls is provided in User32.lib rather than by higher level libraries.