Desktop Matters!: A guide to Windows technologies for Linux users

By Jimmy O'Regan

A reasonable question, and one which will not go unasked (no matter how well I explain this!), is: "Why should Linux users read about Windows technologies?"

The main answer is: because so much development on Linux is influenced by Windows. Windows is the most common platform at the moment; most new users coming to Linux are coming from Windows, but more importantly, so are a lot of new developers.

Now, I don't mean to suggest that the technologies presented here originated in Windows, or that the equivalents available on Linux are limited to merely following the Windows version. In many cases, especially in the desktop, Linux technologies are arguably better, though in other cases, arguably worse.

The main motivation behind writing this is to have a document to point to when writing about desktop topics. I have already compared DCOP to OLE Automation; Tom Brown has also made this comparison. As many articles on desktop topics are written with the intention of introducing former Windows users to Linux, I feel it is helpful to have a glossary of sorts to point them to.

I also feel there would be no harm in introducing long-time Linux users to the concepts of Windows, to better aid those who would attempt to aid these new users, and to help them to understand why some software is designed the way it is. For example, most Linux types dismiss Visual Basic, without understanding why Visual Basic is useful to Windows developers.

A note about Wine

Most people know about Wine, even if only vaguely. Wine is an implementation of the Windows API, with a loader for Windows binaries. Using Wine, many Windows applications can be run on Linux; and several open source projects for Windows can be compiled using Winelib.

One problem with Wine is that it can't be used as a regular Unix library, because it has to be binary compatible with Windows to work. Because of this, you can't link to Wine to get an easy DLL loader. Work is being done in this area: Mono is using Wine to develop its implementation of .Net's Windows Forms, and Ardour.

Another, larger problem, is that the Windows API contains several hacks to support backwards compatibility. After I started writing this, Slashdot posted this article, which provides me with a way of explaining why Wine has such a hard task in implementing the Windows API:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

Yet another problem is that much of Windows is undocumented. From the article quoted above, I was lead to the weblog of Raymond Chen, one of the developers of Windows, where I found this quote from another Windows developer, which explains why: "The reason we can't publish the structures is that it precludes our changing them FOREVER. I mean FOREVER." (This page has more comments on this, though the main story is pretty amusing, considering that many people could be forgiven for thinking that this is what Microsoft does).

Language integration

One of the reasons behind the design of Windows is the goal of language integration. Most of the technologies in Windows seem to have been written for Visual Basic, but were made part of the operating system so that other languages could take advantage of them. This places an extra burden on language developers, but makes life easier for the developers who use these languages.

On Windows, a developer can access a COM object just as easily from Python as they can from C++ or Visual Basic. On Linux, they have several hoops to jump through first. A Perl or Python programmer who wants to use a C library must find a wrapper for their language first; if one is not available, they must write one of their own. A C programmer wishing to access a C++ library must write a wrapper library in C++, which exposes functions which may be called from C.

There are equivalents available; Perl's Inline modules allow Perl programmers to embed other languages inside Perl code. This allows the reuse of libraries, no matter what language they are written in; but it also requires you to be able to write enough of another language to access the functions you want.

GNOME's use of CORBA allows for language integration on a similar level to that present on Windows, especially with the Perl and Python bindings, but unfortunately these came too late. As it is, it is possible to fully access any CORBA object in GNOME, and to write CORBA servers, in both Perl and Python, but CORBA has all but been discarded from GNOME as a mechanism for calling functions. Ximian have focused their attention on Mono as a means of getting this integration, while other GNOME developers are looking at D-BUS.

OpenOffice.org and Mozilla have got the sort of framework which allows the same level of language integration as Windows. This is not surprising though, as both UNO and XPCOM have designs based on COM's.

Compatibility

Of much more importance is the compatibility between the various aspects of Windows. In Linux, though there are equivalents available for every individual part of Windows, these come from different projects, and several of these parts are incompatible.

There are three main collections of office software for Linux; OpenOffice, KOffice, and GNOME Office. Because components are incompatible, if I use KWord, I can't use Gnumeric for my embedded sales figures. I have to use KSpread. If I use OOCalc, I can't have an embedded Dia drawing.

As I mentioned, KDE, GNOME, OpenOffice, and Mozilla each have different component systems. Now, the situation isn't as bad as it could have been, as the nice people at Sun have written software to allow OpenOffice to be used as a Bonobo component, as a Netscape plugin, and to access XPCOM components, which they use for various purposes; and KDE have a technology called XParts which allows non-KDE components to be embedded as KParts (though not without a little hacking - only Mozilla is supported, though there is also the Cuckooo project to use OOo as a KPart), as well as QtGtk, which allows Gtk apps to use Qt dialogues - software using this library could, for example, display the KDE file dialogue, which allows KDE's IOSlaves to work within the GNOME app (Ars Technica has an overview of KDE's technologies). There is also a Bonobo plugin for Mozilla.

Other compatibility problems exist; but these are being tackled, mainly due to the work of freedesktop.org. Gtk-Qt is an example of this in action; it unifies the themes of Gtk and Qt, so users can have a common look on their desktop.

Visual Basic

Now, when I say Visual Basic, I mean the component-oriented type of programming which VB allows, which can easily apply to Delphi, or any other programming language available for Windows. But VB is the most popular language on Windows, so I use it for the purposes of this article.

There are several reasons behind the popularity of Visual Basic: Graphical GUI design, simple syntax, easy access to COM objects, and easy access to DLLs written in C. GUI designers are available for Linux: there's Glade for GNOME, QtDesigner for KDE, etc. Simple syntax is also not a problem: Python has at least the same level of simplicity.

That leaves access to components, and to libraries. Access to libraries isn't much of a problem, as for most common libraries, it's only a matter of time before someone writes a wrapper. Access to components, as mentioned earlier, is possible, but your choice is limited.

For a VB programmer, it's a common task to use Internet Explorer to grab some figures from a web site, use Excel to perform calculations on them, insert them into an Access database, mail them with Outlook etc. It's just as easy to grab those figures from Mozilla, to use Lotus 123 for calculations etc. (Though I should note that in reality, most people won't want to use components from other desktops/office suites).

On the plus side, there are technologies such as Sash XB out there!

.Net

.Net is Microsoft's newest baby. .Net languages target the CLR, or Common Language Runtime, which is like the Java runtime, but with extensions to support several languages. Programs written in one .Net language can access libraries written in another through the CLR.

.Net, especially when considered with C#, is seen by many as Microsoft's reaction to losing the lawsuit Sun brought against them after they made incompatible changes to Java. .Net, however, is also an extension to the COM + VB programming environment which Microsoft already had. It provides a class library with all of the different facilities of the Windows/COM API, which the Mono team are making great effort at implementing.

There are two important things about .Net from a Linux point of view; firstly, that there are two projects which aim to implement it: Mono and DotGNU Portable .Net; secondly, that Microsoft is designing a completely new API for it, so that these projects have less catching up to do than the Wine project does.

Plus, if you want to have an embeddable virtual machine which supports several languages, and will most likely have a large and varied class library, you can always follow the progress of Parrot, which is still being designed, but will host Perl 6 and (a version of) Python by the time it's finished.

The technologies

DDE

DDE, or Dynamic Data Exchange, is a protocol which allows Windows applications to exchange data. Data is exchanged in the form of short messages, which contain either a short item of data, or a pointer to a location in memory where this data is available.

DDE is deprecated.

OLE

OLE stands for Object Linking and Embedding. OLE was originally intended to complement DDE, and to provide a simple method of linking files, so that. for example a spreadsheet linked from a word processor would have the latest figures; and embedding the application, so that the user would be able to edit the spreadsheet without exiting the word processor.

On Linux, KDE has KParts, while GNOME has Bonobo. Bonobo is quite similar to the Windows design, as it uses CORBA interfaces which are very much like the interfaces used in Windows. KParts however, is a much simpler technology. A KPart is a shared library written in C++ which implements an interface. This library is accompanied by an XML file which describes the menu items the KPart provides. This allows for similar embedding, with a much less complicated framework. KParts use DCOP to communicate with each other.

VBX

VBX, or Visual Basic eXtensions, also called "custom controls", were introduced as a way of extending Visual Basic. Built on the embedding of OLE, custom controls were intended as a way of allowing component reuse. Controls could be added to the form (the "canvas" of VB's GUI designer) of a program, where they provided customised GUI elements, with their own properties and methods. For example, a VB programmer wishing to display an image would include an image control, setting the appropriate property to provide the location of the image.

VBX is an obsolete technology.

OLE Automation

OLE Automation is a set of COM interfaces used to present functions in an ActiveX object, or other program, in a standard way. Automation also provides a system like Java's reflection. This is used in VB to provide code completion, for example.

Despite Eric Raymond's assertion that "Most programs cannot be scripted at all. Programs rely on complex, fragile remote procedure call (RPC) methods to communicate with each other", most large programs do provide OLE interfaces. (See DCOM to find out about the RPC part.

OCX/ActiveX

OCX, or OLE Control eXtensions, were an extended version of VBX designed for 32-bit versions of Windows. VBX was a popular idea, and Borland's Delphi was able to use them. This, perhaps, convinced Microsoft that the idea would prove useful in their other languages, so they made OCXs a part of Windows.

OCX was later rebranded ActiveX, though this term was later used to refer to COM and other related technologies, when Microsoft extended Internet Explorer to act as an OCX container, as a reaction to Java applets and Netscape plugins. ActiveX components could be run on demand, like applets, but could also be installed, like plugins. Microsoft didn't pay as much attention to security as Sun did, though, and after the bad publicity ActiveX's security received, few use them as anything other than plugins.

Reaktivate is a KDE extension which uses Wine to allow ActiveX controls in Konqueror. There is a Mozilla ActiveX plugin, but as this is a Windows plugin, you'll either need to have the Crossover plugin (and note that this is no longer sold separately from Crossover Office), or install the Windows version of Mozilla using Wine. (The Wine project eventually wish to use the Mozilla code, but as the current code is written using ATL, this would involve a large rewrite).

For equivalents, see OLE, though it's worth noting that with Mozilla, it's now possible to write ActiveX-like components in Java.

Active Script

Active Script is an OLE technology which allows scripting languages to be used in any "host" application. This was (probably) a result of the work being done to add Javascript to Internet Explorer in addition to ASP. Active Script languages can access any function exposed through Automation.

The result is, for example, Perl in ASP and Python in web pages.

OpenOffice.org has a similar technology. Mono and Parrot will probably add this on a widespread basis.

COM/DCOM

COM, or Component Object Model, is an extension to OLE which also took in OCX, based on a modified version of DCE/RPC. Previously, object interfaces were specified using ODL (Object Description Language); with COM, these were specified using DCE IDL, with an extended syntax. DCOM stands for "Distributed COM". The only real difference here is that when an object is accessed on the same machine, it is accessed in the same way as a C++ class is, but if the object is on another machine, the RPC mechanism is used.

In Linux land, Samba implements quite a lot of DCOM. They are currently working on making it easier to write programs which use the Samba infrastructure to access DCOM objects. There is a lot of work going on in Wine at the moment which is aimed at getting RPC working.

DCOP is based on X's libICE, and Bonobo is based on CORBA, so both KDE and GNOME are as network transparent as Windows when it comes to accessing remote objects.

ASP

ASP, Active Server Pages, is an Active Script based way of generating web pages.

There have been several attempts to clone ASP for Linux. Sun Java System Active Server Pages (formerly SunONE ASP, formerly Chilisoft ASP) is possibly the best known, though it is a proprietary product.

Of open source attempts, there are Arrowhead ASP, a Java implementation, which requires all objects to be reimplemented in Java (though if Wine becomes usable as a library, Jawin could remove this requirement); ASP2PHP, which converts ASP (VBscript) to PHP; and ASP.NET in Mono.

ADO

ADO, Active Data Objects, is an Automation based interface to databases, similar to Perl's DBI. ADO is based on OLE DB, an earlier framework aimed at systems programmers. OLE DB is little used, as it is a very complicated, low level API, though programmers who wish to provide access to a new database must first write an "OLE DB Provider" (to continue with the Perl comparison, this is similar to a DBD module) before ADO programmers can use the database.

GNOME's GNOME DB is an ADO influenced library, which is similar enough that Mono used it to implement their version of ADO.NET. KDE, through the Qt library it's based on, also has a set of libraries for accessing databases.

J/Direct

Worth a brief mention, J/Direct is the extension to Java that Sun sued Microsoft over. J/Direct provided extra syntax for Javadoc comments which specified how a DLL function or COM object was to be accessed, as well as a set of attributes for compiled Java classes.

This technology is obsolete now, but lives on in Microsoft's J# for .Net. Portable .Net provides a Java compiler, though it doesn't accept either J/Direct or J# extensions; neither does IKVM, a Java VM for .Net which comes with Mono.

 

---

Jimmy is a single father of one, who enjoys long walks... Oh, right.

Jimmy has been using computers from the tender age of seven, when his father inherited an Amstrad PCW8256. After a few brief flirtations with an Atari ST and numerous versions of DOS and Windows, Jimmy was introduced to Linux in 1998 and hasn't looked back.

In his spare time, Jimmy likes to play guitar and read: not at the same time, but the picks make handy bookmarks.