A Critique of the Windows Application Programming Interface
Total Page：16
File Type：pdf, Size：1020Kb
A Critique of the Windows Application Programming Interface Diomidis Spinellis University of the Aegean 83200 Karlovasi Greece email: [email protected] December 1997 Abstract ware to run under Windows. Although application writers can be isolated from the SDK by using libraries, scripting, The architecture, interface, and functionality of the Win- visual and fourth-generation languages, or utilising pro- dows Application Programming Interface (API) make it dif- grammable components, ultimately the SDK provides the ®cult to master and use effectively, and contribute nega- operating system interface thus affecting the robustness, tively to the safety, robustness, and portability of the ap- portability, performance, safety, and ease of Windows pro- plications developed under it. The API is structured around gramming. a large and constantly evolving set of functions and is based The ®rst versions of Windows provided a graphical envi- on a problematic shared library implementation. The pro- ronment to the MS-DOS operating system. The current ver- vided interfaces are complicated, non-orthogonal, abuse the sions of Windows provide a 32-bit graphical, multi-tasking, type system, cause name-space pollution, and use incon- networked operating system [3] used by thousands of work- sistent naming conventions. In addition, the functional- station and server applications. The core SDK Application ity of the interface suffers from inconsistency, incomplete- Programming Interface (API) covers an extremely broad ness, and inadequate documentation. Application develop- area providing the interfaces listed bellow. ers, programming tool vendors, and Microsoft should face the above problems and provide appropriate solutions. Input and output devices: mouse, keyboard, pen, screen, Keywords: Microsoft Windows; Application Program- printer, and sound. ming Interface; Win32 User interface elements: windows, menus, dialogs, input widgets, the clipboard, and internationalisation func- 1 Introduction tions. System services: ®les, memory, hardware, system Microsoft Windows 95 and Windows NT (from now databases, and networking. on referred-to as ªWindowsº) are increasingly becoming widely adopted as operating system platforms for desktop Graphical elements: bitmaps, fonts, drawing primitives, applications, back-of®ce servers, and research [1]. Their area management functions), and 3D graphics render- programming interface, currently distributed and docu- ing. mented as the ªMicrosoft Platform Software Development An additional number of APIs are provided and docu- Kitº [2] (SDK), provides a set of functions, data types, struc- mented as part of the Windows Platform SDK. The use of tures, macros, and tools for writing user and system soft- some of them is required in order to develop an application Computer Standards & Interfaces, 20:1±8, November 1998. that will satisfy the licensing requirements of Microsoft's This is a machine-readable rendering of a working paper draft that led ªDesigned for Windows NT and Windows 95º Logo Pro- to a publication. The publication should always be cited in preference to gram. These APIs cover the following areas: this draft using the reference in the previous footnote. This material is presented to ensure timely dissemination of scholarly and technical work. the Microsoft's Component Object Model (COM), Ob- Copyright and all rights therein are retained by authors or by other copy- right holders. All persons copying this information are expected to adhere ject Linking and Embedding (OLE), application au- to the terms and constraints invoked by each author's copyright. In most tomation, and ActiveX, cases, these works may not be reposted without the explicit permission of the copyright holder. shell interfacing, 1 telephony interfaces (TAPI), Element Number remote access services and procedure calls (RPC), Number of root header ®les 129 Number of import libraries 48 Total number of header ®les 232 Internet networking, W3 server interfacing (Winsock, Header ®le size (Mb) 5.2 ISAPI), Header ®le lines (non empty non comment) 120516 Macro and constant de®nitions 33174 messaging (MAPI), and Type de®nitions 4858 Functions 3433 game applications (DirectX 2). Interface methods 1462 Messages 858 The Windows platform SDK also documents a number of Noti®cation messages 180 interfaces for entities that are not yet part of the standard Structures 1077 Windows distributions such as the Microsoft SQL, Transac- Properties 498 tion, and Exchange servers, the management console and Enumeration types 110 clustering interfaces, the Win32 Internet functions, and the Function error codes 1137 Open Database Connectivity Interface (ODBC). Although many of the shortcomings of the basic Windows API are Table 1: Win32 API key metrics also evident in the above mentioned interfaces, we will not cover these in this article. The Windows interface is speci®ed using C language 2 Size, Structure, and Implementa- bindings, although due to the nature of its implementation Ð as a set of shared libraries callable using the calling tion convention commonly associated with Pascal programs Ð many of its functions are accessible from other languages The Windows API is accessed through a very large and com- and programming environments. plicated set of elements. Its size is dif®cult to judge because what exactly constitutes it is far from clear. The Windows In this article we will critically examine the architecture, SDK de®nition and its contents change rapidly according to interface, and functionality of the Windows API and point Microsoft's strategic and marketing interests. As an exam- to a number of problems associated with it. We will argue ple the October 1996 edition of the Microsoft Development that because of these problems the Windows interface: Library documents the Internet Server API (ISAPI) as part of the Win32 Software Development Kit (SDK), but docu- is dif®cult to master and use effectively, ments other server related APIs (such as the Open Database Connectivity Ð ODBC Ð API) as separate entities. The can be used to distort competition in the marketplace, April 1997 version of the Microsoft Development Library documents all Windows interfaces under the roof of a sin- contributes negatively to the safety, robustness, and gle ªPlatform SDKº. portability of the applications developed under it. In this article we will consider the Windows API (Win32) to consist of the items supplied as parts of Microsoft's The remainder of this article is structured as follows: Win32 Software Development Kit. The POSIX subsystem in the next section we examine the API's structure, size, of Windows NT, although part of the Win32 SDK, is sepa- and implementation looking on how these affect software rately installed and documented; for this reason we will not development, reliability, and marketplace competition. In consider it as part of Win32. section 3 we examine the interface provided by the Win- A ®le (WIN32API.CSV) supplied together with the Win32 dows API and identify problems related to the complexity SDK lists 9067 API elements (functions, interface methods, and non-orthogonality of the provided interfaces, the type structures, messages, macros, properties, etc.) This num- system, name-space pollution, inconsistent naming conven- ber although large does not include about 29000 constant tions, and portability. In section 4 we look beyond the in- de®nitions (constants de®ned using the #de®ne mechanism terface into the actual functionality provided by the API and of the C preprocessor) and about 4800 type de®nitions (C provide examples of inconsistency, inadequate documenta- typedefs) that can be found by going through all C header tion, and incompleteness. Finally, the last section contains ®les that are part of the SDK, nor does it include the Uni- proposals on how application developers, programming tool code, ASCII, and character set neutral function forms. A vendors, and Microsoft should handle the identi®ed API summary of some key metric sizes of the Win32 API is pro- problems. vided in Table 1. 2 The large size and monolithic nature of the Win32 API 3 Interface negatively affect a number of areas related to software de- velopment. The huge number elements comprising the API The provided functions have a complex and non-intuitive make it dif®cult to master it and use it effectively. As a re- interface with a number of mode changing ¯ags and excep- sult the productivity of application architects, software de- tions that unnecessarily complicate system application de- velopers, and maintainers is negatively affected. velopment. Space restrictions do not allow us to provide a detailed example; interested readers are encouriaged to dis- In addition, the creation of systems providing the same cover for their own edi®cation the three different ways in services on different platforms is dif®cult, and, given the which a read-only mode can be speci®ed using the seven rapidly evolving nature of the API, could well be impossi- parameters of the CreateFile function. ble. In the past, major advances in research and develop- Despite the apparent generality of functions such as Cre- ment of new hardware and operating system architectures ateFile it would be a mistake to think that the Windows such as the RISC processors and microkernels were lever- API provides a small set of generalised functions that cover aged on the ability to provide a Unix-like environment on a lot of ground by being combined in an orthogonal fash- top of the new architecture. With the domination