Originally Published: Friday, 2 June 2000 Author: Rob Bos
Published to: featured_articles/Featured Articles Page: 1/1 - [Printable]

Commoditising the Windows API

As WINE becomes increasingly stable, and as Linux becomes a major player on desktop machines, the viability of Linux as a development platform for Windows applications becomes increasingly realistic. Writing applications for the lowest common denominator, WINE, makes more and more sense to maintain compatibility with both the significant and growing Linux desktop as well as the more outmoded but larger Windows market.

   Page 1 of 1  

Linux is coming to the desktop. Every month it becomes easier to use and gains more capabilities -- it is quickly becoming easy enough for the average user to install and maintain. Free software is quickly liberating the desktop.

One of the major components of Linux on the desktop is the ability to run legacy Windows applications and to port them easily to Unix systems. The WINE project is very important in this regard; it lets companies which have invested significant resources into the Windows versions of their respective products to port to Linux with relatively little trouble. It also allows users to run applications which have been compiled for Windows directly. While the WINE libraries are by no means complete or bug-free, they are certainly stable enough to run and compile a significant and quickly increasing proportion of Windows programs.

As WINE becomes increasingly stable, and as Linux becomes a major player on desktop machines, the viability of Linux as a development platform for Windows applications becomes increasingly realistic. Writing applications for the lowest common denominator, WINE, makes more and more sense to maintain compatibility with both the significant and growing Linux desktop as well as the more outmoded but larger Windows market.

Linux is in some ways a superior development platform. It has tools that simply do not exist in the Windows world, a more flexible and powerful interface for the advanced programmer, and a more solid foundation for testing programs. The development and porting of so-called "integrated development environments" to Linux from Windows could make this argument even more powerful. Windows developers could have the best of both worlds: the stability and power offered by Linux, combined with the familiar interface of their favourite development environment. The transition to Linux for developers is made much simpler by this process.

It isn't hard to imagine that a large proportion of companies may start writing against the WINE libraries, the common standard of the old Windows and every other operating system, including Linux, instead of the Microsoft Windows API, to ensure compatibility between the various competing operating systems and the largest possible market share. Coding a program using the WINE libraries would mean that the program compiles with relatively little hassle for almost all the flavours of Windows, BSD, Linux, OS/2, and perhaps even MacOS.

One of the major arguments against WINElib is the OS/2 example. By implementing full binary compatibility with Windows programs, IBM gave developers a very good reason to stick with writing for Windows. Since their programs would run under both operating systems in any case, there would be no compelling reason to write OS/2 native applications, even if native applications would be significantly more powerful. Since IBM only emulated binary packages, however, their Windows emulation was doomed to fail -- Microsoft could change and enhance the API to a degree that IBM could simply not keep up with, even provided that OS/2 succeeded. They held all the cards, so to speak.

WINElib, on the other hand, is significantly different in that it provides not just a binary emulation environment but a compilation library for programs to run as native Linux applications. The Windows API is converted to just another of the many libraries available to the application.

In short, the WINE project, in attempting to duplicate the Windows programming interface on multiple platforms, in a completely non-proprietary manner, could very well turn it into a real standard. Microsoft would be unable to blatantly change its application specifications because of the de facto standard API; even if they did, the free software community could very easily keep on top of those changes through reverse-engineering -- but with the support of the computer industry. The WINE project can do it better, more stably, and more cross-platform than Microsoft -- which no matter how large, is still only a single company with limited resources -- and deploy it on more stable, more clearly modular platforms.

If Linux gets a significant portion of the desktop, its virtues as a superior development platform and the desire for software vendors to reach as large an audience as possible will make it possible for the WINE project to effectively lock Microsoft's ability to manipulate its API to its own advantage.

Rob Bos (rbos@linux.com) spent six hours trying to fix Windows NT 4.0 today. Sigh. NTFS is a bad thing.





   Page 1 of 1