Working Paper

XVT Versus Microsoft Windows API

bY Dave Stephens

OCLC Online Computer Library Center, Inc. 6565 Frantz Road Dublin, Ohio 43017-0702

19% June 30

Working Paper

XVT Versus Microsoft Windows API

by Dave Stephens

Office of Research OCLC Online Computer Library Center, Inc. 6565 Frantz Road Dublin, Ohio 43017-0702 Proprietary Notice This document has been prepared by OCLC and the information contained herein is proprietary and confidential. OCLC reserves all rights to this document and its contents, and any reproduction, republication of other unauthorized use thereof, in whole or in part, without the express written consent of OCLC is prohibited. OCLC Working Papers Series The Working Papers series provides OCLC staff a forum for research and technical papers in progress. This series is designed to improve access to information that is central to OCLC research and technological interests. The Working Papers series encourages scholarly discussion and peer review early in the research process. The position papers, recommendations, and preliminary research reports found in the series may lead to research proposals, projects, reports, or publications and presentations of other kinds. Information contained in the Working Papers series may be considered proprietary and confidential, and distribution is subject to the proprietaty statement, if any, found in this document. For more information, contact the OCLC Office of Research.

A Report on Conversion of JAPAN MARC Records to OCLC-MARC Records by Yuzo Ito Working Paper Number: OCLC/OR/WP-88/1;424 pages

Online Union Catalog Subsetting Analysis by John Bunge Worlung Paper Number: OCLC/ORAXrP-88/2P; 18 pages

Selected Descriptive Statistics from the OCLC Online Union Catalog by Mark Crook Working Paper Number: OCLC/OR/UT-88/3P;9 pages

Scientific American Project Report by Lora J. Nelson Working Paper Number: OCLC/OR/WP-88/4P; 102 pages

A Bibliographic Study of Latvian Records in the OCLC Online Union Catalog by Inese Auzina Smith Working Paper Number: OCLC/OR/WP-88/5P; 39 pages

Optical Character Recognition on Noise-Free Images of Documents by John C. Handley Working Paper Number: OCLC/OwwP-89/1P; 8 pages

An Analysis of Table of Contents Data in Archive and Bibliographic Records by Mark A. Crook Working Paper Number: OCLC/OR/WP-90/1P;5 pages Wisdom: A User Interface for CD-ROM and Online Database Searching by Mark W. Bendig Working Paper Number: OCLC/OR/WP-M/2P; 27 pages

Multimedia Computing: An Annotated Bibliography by Mark A. Crook Workmg Paper Number: OCLC/OWWP-M/~P;6 pages

XVT Versus Microsoft Windows API by Dave Stephens Working Paper Number: OCLC/OR/Wp-%4P; 4 pages Contents Overview, 1

Keyboard, 1

Event Management, 1

Window Types, 2

Object Orientation, 2

Memory, 2

Performance, 2

Communications, 3

Device Independence, 3

Development Tools, 3

Conclusion, 3

V OCLC Working Paper

1330 June 30

Many portability tools such as XVT have been offered to software developers. However, such tools have always required compromise. The purpose of this report is to indicate these tradeoffs for the Microsoft Windows platform so that these tradeoffs can be carefully evaluated for Microsoft Windows products that might benefit from running elsewhere. Overview Portable environments such as XVT can take one of two extremes. In the first extreme, these tools will provide a full featured environment and then will shore up any deficiencies in host environments through large amounts of emulation code and hence memory. At the other extreme, in order to minimize memory requirements and maximize speed, portability tools will provide only the lowest common denominator across their target environments. XVT chose the latter; there are only 220 functions in XVT while there are 450 functions in Microsoft Windows. Furthermore, some XVT functions are not portable includmg GET-GRAFTPTR, GET-HDC, GET-HWT\iD, GET-WNDOWPTR and key-hook.

This report demonstrates the many resultant effects on Windows users and developers from this design approach. First, XVT provides only one window style for overlapped windows whereas Microsoft Windows supports both thick and thin frame captioned styles for these window types. Second, dynamic thumb tracking is not implemented in XVT. Thus, developers can’t effect the sort of facility used in PIFEDIT’s help system. PIFEDIT is a Microsoft Windows utility. Also, XVT only supports an ASCII and a “picture”clipboard format; Microsoft Windows supports ASCII, bitmap, metafile, SYLK and DIF clipboard formats. Furthermore, XVT does not support portable color. Keyboard XVT has a much simpler keyboard interface than Microsoft Windows. When a window is unable to receive keystrokes at the rate sent from a typematic keyboard, XVT does not consolidate these key strokes by storing a repeat count with the key code. Thus, XVT could exhibit overscrolling problems on slower machines. Also, XVT does not distinguish whether ? + - or * have been sent from the numeric or the standard keyboard nor does XVT recognize CtrlBreak or NumLock. Popular PC programs such as Brief discriminate between whether + or - are sent from the standard or the numeric regions of the keyboard. Event Management Microsoft Windows supports approximately 100 event types; XVT only supports 15. Also, Microsoft Windows subclassing is not provided in XVT. Subdassing allows a program to intercept messages sent to existing Microsoft Windows functions and then process the messages it chooses while passing the remaining messages to the original function.

OCLC Working Paper 1 1990 June 30

Window Types XVT only supports two types of window styles: overlapped (document) windows and popup windows. Microsoft Windows supports three types of windows: overlapped, child, and popup windows. Also, XVT does not allow control over how a popup window is associated with its parent. Thus, unlike Microsoft Windows, an XVT program can’t choose whether or not the popup window is hidden when the parent is maximized or whether or not the popup is hidden when the parent becomes active. Object Orientation Microsoft Windows is object oriented; XVT is not. Predefined objects in Microsoft Windows provide many useful tools that accelerate development. These tools include push buttons, check boxes, radio buttons, group boxes, scroll bars, windows with text editing capabilities and powerful list windows. Such facilities are limited to dialog boxes in XVT.

Microsoft Windows object-oriented facilities use classes, inheritance, message passing and objects to ease development in other ways. First, only the first instance of a window’s class needs to define its characteristics. Subsequent windows then inherit these properties when they use these predefined classes. Inherited properties include mouse pointer management and minimization icons. Second, object oriented facilities allow programs to send messages to windows in other programs. Third, messages can be sent through these facilities from child windows to their parent and vice versa. Also, Microsoft Windows allows the hierarchical relationshps between objects (windows) to be changed. Fourth, child windows are perhaps the most useful objects in the Microsoft Windows object-oriented paradigm as they greatly ease the process of “hit testing.”Child windows are not provided by XVT. Memory Unlike XVT, Microsoft Windows provides a GlobalNotify €unction that allows a program defined function to be called before discarding global memory blocks. This allows the program to implement swapable data. Also, XVT can require substantially more memory because it does not use dynamic link libraries and therefore can’t share code between instances of an application and between separate applications. XVT’s memory limitations are exacerbated by the absence of dynamic data exchange because data can’t be shared between applications without this capability. Performance Microsoft Windows provides nonpreemptive multitasking. This form of multitasking benefib from facilities that allow applications to yield to other applications and facilities that allow applications to check their event queues without yielding to other applications. XVT does not have such capabilities. Also, XVT windows must be created with the NULL brush for the background. This requires an application to paint the client rectangle each time it receives an update event. This performance siphon is noticeable even on a 16 MHz 80386 with static column RAM whenever an occluded window requires uncovering, highlighting and redrawing.

2 OCLC Working Paper 1990 June 30

Communications XVT does not virtualize communications across operating systems. Differences between operating environments could make for significant porting efforts. Thus, the cost of a multi-platform strategy using XVT may be much greater in relation to a Windows-only strategy than a superficial analysis of XVT would suggest. Also, the absence of dynamic data exchange may hamper the development of competitive communications software. Dynamic data exchange allows other applications ready access to online systems through the scripting facilities available in commercial Microsoft Windows communications packages such as Dynacomm, Ape, and Crosstalk for Windows. Device Independence The need for device independence is greater on the PC than on the Apple Macintosh because the aspect ratio of pixels varies across the different classes of industry-standard PC monitors. More specifically, VGA systems have square pixels while EGA systems do not. Such differences are even more prevalent in PC graphics printers. Microsoft Windows achieves device independence by mapping logical coordinates (windows) to device coordmates (viewports) at the system level. Microsoft Windows software can chose between three categories of mapping at the system level and thus determine the level of device dependence. XVT inherits the Macintosh’sstronger device dependence, increasing the cost of developing true WYSIWYG software. This XVT shortcoming is formidable for Microsoft Windows developers considering the variety of display and printing devices in the PC market. The absence of the metafile clipboard format further exacerbates XVT device dependencies because this format uses vectorized representations of graphical objects instead of device dependent bit maps. Development Tools Because XVT uses a “lowest common denominator architecture,”it will increase developments costs for many products that only target Microsoft Windows. Moreover, use of XVT would preclude using Microsoft Windows CASE tool generated software for production versions of software. Such tools include CASE:W, CtalkiViews, Common View, WAPE, Actor, and Winpro/2. Thus, a Windows-only strategy using these CASE tools has the potential for greatly lowered development costs over a multi-platform strategy using XVT. However, (like XVT) such CASE tools will force user interface quality and functionality tradeoffs and therefore need carefkl evaluation. Conclusion It should be pointed out that some of these XVT shortcomings (as of December, 1989) will be addressed in future versions of XVT. The developers of XVT have indicated that attention will be given to providing (1) buttons in windows, (2) dynamically modifiable menus, (3) portable color and, (4) child windows. However, it remains to be seen if these will be addressed via nonportable functions similar to those currently used in XVT such as GET-HDC, GET-IIMND, GET-WINDOWPTR and key-hook.

There are alternatives to XVT. Mirrors from Micrografx allows portability across Microsoft Windows and OS/2 Presentation Manager without any tradeoffs. Of course, this tool would not allow all the features of the OS/2 and the Presentation Manager to be exploited and would not provide portability to the Macintosh. Also,Microsoft is investigating the feasibility of including facilities into OS/2 that allow such translations to occur in real time so that applications can run under the Presentation Manager without change.

OCLC Working Paper 3 ocLc/oR/wp-9o/4P 195%June 30

The aforementioned XVT tradeoffs need to be carefully weighed for each potential Windows product. However, if user interface quality is central to product strategy or the targeted user base is accustomed to commercial-grade Microsoft Windows software, XVT probably should not be selected. Also, XVT will increase software development costs for many projects that only target Microsoft Windows. Overall, XVT would facilitate an undifferentiated mass marketing product strategy. However, such a strategy risks the possibility of being out niched by vendors who fully exploit those capabilities of Windows that are not available through XVT. Such risks should be carefully considered given the level of price competition by PC hardware suppliers and the alignment of independent software vendors around Windows version 3.

Increased Windows software competition and PC hardware price advantages have the potential for lowering demand for the Apple Macintosh through strong substitution effects. An XVT based offering could find itself out niched by Windows-only products that exploit unique Windows facilities and forced to use marketing tactics that deal with declining demand for its Macintosh offering.

4 oac Wo'OTkingPaper