Return-Path: | 'owner-risks@csl.sri.com' |
Received: | from csla.csl.sri.com([192.12.33.2]) (30074 bytes) by inet.sena.gr |
via sendmail with P:esmtp/D:user/T:local | |
(sender: <owner-risks@csl.sri.com> owner: <real-dds>) | |
id <m10dmcF-00002SC@inet.sena.gr> | |
for <dds@senanet.com>; Sun, 2 May 1999 06:08:27 +0300 (EEST) | |
(Smail-3.2.0.101 1997-Dec-17 #1 built 1998-Oct-12) | |
Received: | from localhost (daemon@localhost) |
by csla.csl.sri.com (8.9.1/8.9.1) with SMTP id UAA11380; | |
Sat, 1 May 1999 20:06:16 -0700 (PDT) | |
Received: | by csla.csl.sri.com (bulk_mailer v1.5); Sat, 1 May 1999 18:44:14 -0700 |
Received: | (from server@localhost) |
by csla.csl.sri.com (8.9.1/8.9.1) id SAA10239 | |
for risks-outgoing; Sat, 1 May 1999 18:44:14 -0700 (PDT) | |
Received: | from chiron.csl.sri.com (chiron.csl.sri.com [130.107.15.73]) |
by csla.csl.sri.com (8.9.1/8.9.1) with ESMTP id SAA10234 | |
for <risks@csl.sri.com>; Sat, 1 May 1999 18:44:09 -0700 (PDT) | |
Received: | (from risko@localhost) by chiron.csl.sri.com (8.7.3/8.7.3) id SAA18245; Sat, 1 May 1999 18:42:53 -0700 (PDT) |
Date: | Sat, 1 May 1999 18:42:53 -0700 (PDT) |
From: | risks@csl.sri.com |
Message-Id: | <199905020142.SAA18245@chiron.csl.sri.com> |
To: | risks@csl.sri.com |
Subject: | Risks Digest 20.36 |
Newsgroups: | comp.risks |
Sender: | owner-risks@csl.sri.com |
Reply-To: | risks@csl.sri.com |
Status: | U |
Content-Length: | 3775 |
RISKS-LIST: Risks-Forum Digest Saturday 1 May 1999 Volume 20 : Issue 36 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.36.html> and at ftp.sri.com/risks/ . Contents: Seagulls speak English: Aldershot (John Haseler) Yet another satellite hits the dust (Joan L. Grove Brewer) Titan 4B places military satellite in improper orbit (PGN) No Bell Tolls for thee (Jeremy Ardley) Risks of "smart" MS Internet apps (Andrew Shieh) Re: Dodgy automatic address book resolution (Larry Pryluck) MS-Outlook 98 risk of mislaying messages in Outlook today (Jahn Rentmeister) Bloatware and the Windows API (Diomidis Spinellis) Re: The Bloatware Debate (Henry Baker) Bloatware and Nightlight Saving (R.A. Downes) Update on DejaNews click-through monitoring (Richard M. Smith) Re: WC Watch Company site ... (David B. Horvath) Re: Risks of misaddressed mail (Frederick M Avolio) REVIEW: "A Guide to Virtual Private Networks", Martin W. Murhamm (Rob Slade) CONF: 12th Software Quality Week (Software Research) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- [...] ------------------------------ Date: Sat, 01 May 1999 15:19:23 +0300 From: Diomidis Spinellis <dspin@aegean.gr> Subject: Bloatware and the Windows API A number of contributors to previous digests have stressed the risks associated with increasingly bloated software applications. I believe that a part to the complexity and unreliability of many modern software applications can be attributed to their use of the Windows Application Programming Interface (API). I recently wanted to read - using C code - the name of the file pointed by a Windows shortcut: a shell-level equivalent of the Unix symbolic link. Unix symbolic links can be read by using readlink(2) - a simple three argument system call. The code I had to write to examine the Windows shortcut spanned over 100 lines of C and included initialisation of the COM (component-object model) library, checking for Unicode filenames, getting pointers to two COM interfaces, and releasing all the associated handles at the end. Seven of the API functions could return with an error which had to be checked. I am sure other readers can point to other similar examples. The architecture, interface, and functionality of the Windows API make it difficult to master and use effectively, and contribute negatively to the safety, robustness, and portability of the applications developed under it. The API is structured around a large and constantly evolving set of functions and is based on a problematic shared library implementation (the infamous Dynamic Link Libraries - DDLs). The provided interfaces are complicated, non-orthogonal, abuse the type system, cause name-space pollution, and use inconsistent naming conventions. In addition, the functionality of the interface suffers from inconsistency, incompleteness, and inadequate documentation [1]. I foresee that problems associated with the use or misuse of the Windows API will provide material for many future RISKS digests. [1] Diomidis Spinellis. A critique of the Windows application programming interface. Computer Standards & Interfaces, 20:1-8, November 1998. http://kerkis.math.aegean.gr/~dspin/pubs/jrnl/1997-CSI-WinApi/html/win.html Diomidis Spinellis, University of the Aegean ------------------------------ [...] ------------------------------ End of RISKS-FORUM Digest 20.36 ************************
Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.