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