The OS/2 Graphics Subsystem in the Workplace OS Family
In recent articles published in The Developer Connection News, we have presented an overview of Workplace OS. One of the key features of Workplace OS is its ability to run all of today's 32-bit OS/2 applications, which includes those written to the OS/2 Presentation Manager. In this article, we will explore the graphical and presentation service capabilities that Workplace OS/2 (WP-OS/2) will provide for OS/2 applications - focusing on the port of the OS/2 Graphics Subsystem to the WP-OS/2 environment.
All of the components present in the graphics subsystem of today's OS/2 2.1 will be ported to the WP-OS/2 IBM Microkernel environment. Presentation Manager applications that are written in a 32-bit, high-level language (such as C or C++) will port to WP-O S/2 with little more than a recompile. And, depending on the target hardware platform even the recompile might be unnecessary. For example, today's 32-bit applications that run on Intel hardware will continue to run on WP-OS/2 on Intel hardware. In ad dition, today's 32-bit, assembler code will port potentially unchanged to WP-OS/2 when running on an Intel hardware platform, but not to non-Intel hardware. However, applications written in a 16-bit, high-level language today, will, at a minimum, require a port to a 32-bit compiler. Ideally, they should be modified to take full advantage of a 32-bit flat memory model that OS/2 2.1 provides today and that the WP-OS/2 will provide.
The reality is that on WP-OS/2, 32-bit applications will be easier to port and will realize greater performance.
All of the interfaces provided by the PM Window Manager (PMWIN) and PM Graphical Programming Interface (PMGPI) will be available in 32-bit form on WP-OS/2. This is very important for application programmers who want to maintain one set of source code and have it run unchanged on a variety of hardware platforms (for example, Intel and RISC).
The Graphics Subsystem under WP-OS/2
The PM Window Manager
When we talk about the PM Window Manager (PMWIN) component of OS/2 2.1, we are referring to that piece of Presentation Manager that provides the support for the displaying and manipulating of windows and controls. As many of you know, even under OS/2 2.1 today, some pieces of 16-bit code and data are present in the Window Manager. As part of the port of the Window Manager to WP-OS/2, all of the remaining restrictions imposed by the presence of 16-bit code and data will be removed. This will yield advan tages for 32-bit applications. No longer will any thunk (or conversion) layers be needed to convert 32-bit data provided by applications to 16-bit format, so that the Window Manager can work with the data. Also, the control window classes provided by PMWIN, such as the listbox, will no longer have a 64KB constraint on the amount of data they can maintain.
The technology used to upgrade PMWIN for WP-OS/2 will be rolled back to the OS/2 2.x arena. Therefore, 32-bit applications will realize the benefits of a fully 32-bit Window Manager on any platform where the OS/2 2.1 application programming interface (API) is available.
Graphical Programming Interface
Since its inception in the days of OS/2 1.1 back in 1987, the Graphical Programming Interface (GPI) has had a 32-bit API. In other words, all of the parameters that get passed to GPI functions are 32-bit LONGs. In the OS/2 2.1 environment, the internal library of the GPI is fully 32-bit. Because of this, applications written to the GPI today will see exactly the same environment when running under either WP-OS/2 or OS/2 2.1.
OS/2 2.1 already contains a powerful, 32-bit, graphics engine. The graphics engine is the graphical kernel of PM. It sits between the GPI and the presentation drivers that support hardware devices. The engine contains the algorithms and functions that implement the OS/2 imaging (or drawing) model.
It handles and manipulates all aspects of the graphics subsystem - from rendering line primitives, such as arcs and splines, to performing coordinate transformations to managing fonts to calculating clipping. In the same way that 32-bit applications can be ported easily to the WP-OS/2, the graphics engine also is a simple port. This is because it is written almost entirely in 32-bit C code.
Presentation Driver Model
The term presentation driver refers to the piece of code that sits between the graphics engine and a hardware device such as a screen or a printer. Presentation drivers are really dynamic link libraries (DLLs) that can be dynamically loaded when required. A typical OS/2 2.1 system has one display presentation driver and one or more printer presentation drivers loaded at any one time.
The graphics engine maintains a dispatch table of functions for each device it has loaded. When an application makes a GPI call such as GpiPartialArc, the GPI calls the engine's function dispatcher, which jumps to the address of the PartialArc function in the dispatch table.
When the engine initially loads a presentation driver, the driver has the chance to replace the address of functions in the default dispatch table with the address of its functions. For example, if the driver provides the address of a function that implements the PartialArc function, the engine jumps directly to the driver's function - whenever the application makes a call to GpiPartialArc. Otherwise, the engine breaks the arc down into simpler graphics primitives that the device indicates it can handle by hooking out those functions, such as PolyLine.
Today, in OS/2 2.1, presentation drivers have to hook out (or support) between 59 (printer drivers) and 75 (display drivers) mandatory functions. That is, the engine provides no support for a range of functions that it expects all presentation drivers to provide routines for. Therefore, presentation drivers are more complex and take longer to write than perhaps should have be necessary.
As well as the current level of function it provides, the graphics engine is being further enhanced to make the writing of presentation drivers much easier. Existing drivers that hook large numbers of functions are still supported. However, the number of mandatory (must hook) functions is greatly reduced. Under the new model, the minimum that a presentation driver will have to do to get up and running is to notify the engine of a flat frame linear address where the engine can place a ready-for-display bitmap image of the picture generated by the application. For a display device, this could be simply the address of video memory in the hardware. For a printer device, this could be a large linear address space within the printer or an address space allocated by the presentation driver.
To achieve the new presentation driver model, the graphics engine will now provide support for functions that it required drivers to support in the past. The engine will also provide more built-in support for palette management and generation of rasterized images, so presentation drivers do not have to provide that support themselves.
The new presentation driver model means that it will be very easy and take very little time to get a presentation driver up and running. This is especially good when producing drivers for a new hardware device, as it is highly desirable to get a driver up and running quickly. By allowing Presentation drivers to hook out more than a minimum set of functions from the Engine's dispatch table, they will still be able to exploit built-in algorithms and features of hardware device that are provided to help spee d up the graphics rendering process. In other words, presentation drivers will focus on the hardware specific portions of their drivers (the parts that are unique) and can allow the Engine and the rest of the presentation manager video subsystem to do the rest of the work.
It is possible to port existing OS/2 2.1 presentation drivers to WP-OS/2. The new model does not replace the old one, rather it complements it. To port a presentation driver to WP-OS/2, it will first of all need to be converted to 32-bit code if it is currently 16-bit code. A high-level language should be used to enable porting of code across hardware platforms. As presentation drivers, by their very nature (especially in the case of display drivers), have hardware-dependent portions, some changes wi ll be needed to that part of the driver if it is being ported to a non-Intel platform.
The new presentation driver model will also be made available in the OS/2 2.x arena so that presentation drivers can be developed to the new model to work both under OS/2 2.x and WP-OS/2.
OS/2 2.1 provides a set of functions that character mode (non-PM) applications can use to manipulate the keyboard, mouse, and screen. Under WP-OS/2, the majority of these functions will be provided in 32-bit form.
In summary, the WP-OS/2 environment provides a fully-functional, 32-bit, Presentation Manager across a wide variety of hardware platforms. To the OS/2 application developer, simply put, this means a large increase in potential end users and target machines. As it is a simple task to port the Micokernel to new hardware platforms, and as WP-OS/2 is built on top of the Microkernel, the number of hardware platforms where the OS/2 2.1 API is available will continue to grow and grow. At the same time, PM applications will continue to port very easily to each of the new platforms requiring, in most cases, no more than a recompile.
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation