Mike Schaeffer's Blog

In a recent article on newsforge Toby Richards discusses his pet theory describing why Linux isn't mainstream. You should read the article yourself (it's short), but the basic gist is that 'people' at home want to use operating systems that are compatible with what they use at work, and Linux isn't used at work because there isn't a good equivalent to Microsoft Outlook. The problem is: this reasoning has been tried before.

For over a decade, there's always been some mystical missing piece of technology that was holding Linux back from mainstream acceptance. For a while personal finance software filled this role, later on it was a unified desktop, and later still, when KDE and Gnome reached stability, the need for good office software took up the baton. Fast forward to 2006 and the "one missing thing Linux needs to become mainstream" is apparantly a good equivalent to Microsoft Outlook.

This line of reasoning is seductive to programmers: it basically transforms the question of "What does Linux need to become mainstream?" into the question "What code do I need to write?". After all, if the only thing holding Linux back from mainstream acceptance is a piece of code, then a missing piece of code is easy for a programmer to fix. In fact, since 1997 (the last time I ran Linux full time), basically all of the 'missing pieces' I mentioned above have been rewritten or created anew. If an integrated graphical desktop with a functional office suite was really the key to mainstream acceptance, then Linux should already be there. 10 years ago that was the belief and 10 years later that belief was basically proven completely wrong. When was the last time you saw Linux running on anything other than a server or in some other relatively fixed-function application? Waving a magic wand and integrating Evolution with Exchange won't change this any more than any of the other scapegoats that have taken the blame for Linux's niche status in the past.

It'd be easy to blame this on changing times: after all, who knew that Exchange integration would be so key to Linux's mainstream acceptance a few years ago? Actually, that'd be anybody in IT with a pulse. As Todd points out, Outlook 97 ("It's nearly a decade old, for crying out loud.") runs under Wine and provides Exchange integration. Put another way, the Linux desktop software stack hasn't interoperated natively with the mainstream PC software vendor's e-mail solution for over nine years. This isn't a short-term problem: this is innate. Another example of this kind of long-running problem is the ongoing trouble finding modern video drivers for X11. As much as people complain about ATI's lousy video drivers, it's only a repeat of the same thing that happened with Neomagic and Diamond back in the mid-90's. The names are different, but the problem and result are exactly the same: when buying hardware, caveat emptor if you want modern graphics support.

In both of these cases, it's easy to assign blame to closed propriatary vendors. You could also argue that it's just a symptom of OSS developers wanting to work on whatever's 'coolest', rather than what needs to get done. However, with either explanation the problem is inherent with open source, and the net effect is the same: Linux gets most of the way to where it needs to be, but it gets there late and and fails to go the last mile or two. It's this last mile that's so important to mainstream acceptance, and getting through it is going to take a lot more than one or two pieces of code. I have no doubt that five years from now, Linux will have decent Exchange integration and excellent support for the ATI R300 graphics in my (then) six year old laptop. Too bad the battle for the desktop will have moved on.

Kerry Nietz, author of FoxTales, dropped me a note regarding a comment I made about his book back in January. I thought it was worth repeating part of my response here:

"Like I said in January, the book brought back memories of the first few years of my career. Obviously the details are different, but if my kids ever ask about the beginning of my career I'll point them to your book first. You did an excellent job capturing the spirit of commercial software development."

I re-skimmed the book last night (setting aside a brand-new copy of C.J. Date's Database in Depth, ironically enough), and it still seems relevant, six months after the initial read. That's always a good sign.

I took a look around my computer for information on the "DCOM Server Process Launcher" referred to in this post.
Fortunately, Microsoft's services control panel has a place to put descriptive text. The description for the "DCOM Server Process Launcher" reads "Provides Launch Functionality for DCOM Services". Seriously.

Why even bother trying? A Microsoft PM documented this description feature. A programmer coded it. A tester tested it. A writer wrote the text. Another writer documented the feature. Translators translated it into 60 different languages. All so that Windows could show a description that is exactly as useless as the name of the service.

The smallest disk Dell sells on their cheapest laptop is 40GB. Is it really too much to ask for the description to include text closer to this?

Launches Distributed COM (DCOM) processes, and it.s required for a number of other services and processes to function correctly including the Windows Firewall.

–http://mcpmag.com/columns/article.asp?EditorialsID=1124

For bonus points, the service description would also be available from the fault notification dialog box, possibly with hyperlinks to the appropriate developer information on MSDN (which could also be stored locally). The whole key here: trust the user of your product and enable them to use it efficiently.

The clipboard is one of the oldest and most often used data exchange mechanisms in Microsoft Windows. It's been around since Windows 1.0 and basically all applications use it to support operations like copy, cut, and paste. One of the more interesting aspects of the way the clipboard works is that it allows applications to copy data to the clipboard in multiple formats. For example, if you copy text in Microsoft Word to the clipboard, it's not copied in one format, it's copied in seventeen. One way to see this is to open the Clipbook viewer application (start>>run, clipbrd.exe), open the Clipboard window, and look at the list of data formats in the view sub menu. This is how different applications negotiate data formats when copying and pasting data; this is why you can copy a spreadsheet from super-smart Excel, paste it into super-dumb Notepad, and still get reasonable results.

In the process of adding better clipboard support to vCalc, I wrote a small tool for dumping clipboard contents to a console window. This tool, cbdump, runs from the command line and shows a list of all the data formats currently on the clipboard. It can also dump out the data in hexadecimal format, so you can see the actual data, unaltered by applications. To show what it looks like, here's sample output after copying a small Excel table to the clipboard:

c009: "DataObject"  (4 bytes)
000e: CF_ENHMETAFILE  (0 bytes)
0003: CF_METAFILEPICT  (16 bytes)
0002: CF_BITMAP  (0 bytes)
c2e2: "Biff8"  (5120 bytes)
c2e6: "Biff5"  (4608 bytes)
c1f3: "BIFF4"  (1904 bytes)
c2e3: "Biff3"  (1773 bytes)
c2f7: "Biff"  (913 bytes)
0004: CF_SYLK  (1131 bytes)
c2ec: "Wk1"  (197 bytes)
0005: CF_DIF  (137 bytes)
c298: "XML Spreadsheet"  (943 bytes)
c0f2: "HTML Format"  (2344 bytes)
000d: CF_UNICODETEXT  (22 bytes)
0001: CF_TEXT  (11 bytes)
c295: "Csv"  (11 bytes)
c0a5: "Rich Text Format"  (3071 bytes)
c00b: "Embed Source"  (6144 bytes)
c004: "Native"  (6144 bytes)
c003: "OwnerLink" ERROR in GetClipboardData
c00e: "Object Descriptor"  (152 bytes)
c00d: "Link Source"  (135 bytes)
c00f: "Link Source Descriptor"  (152 bytes)
c1f2: "Link"  (31 bytes)
0081: CF_DSPTEXT  (13 bytes)
c002: "ObjectLink"  (39 bytes)
c013: "Ole Private Data"  (792 bytes)
0010: CF_LOCALE  (4 bytes)
0007: CF_OEMTEXT  (11 bytes)
0008: CF_DIB  (57368 bytes)
0011: CF_DIBV5  (57452 bytes)
150642 bytes

The leftmost column is the integer ID of the clipboard format. This is the ID used by Windows to identify the format used by a particular chunk of data. Following the ID is the clipboard format's name, of which there are two kinds. By default, Windows knows about a few predefined types of clipboard data: these are identified by constants in the header file and are things like CFTEXT (text data) and CFDIB (a device indepentant bitmap). However, to handle the case where one of the Windows default formats will not work, Windows also allows applicatons to register additional formats and give them useful names. In the list above, that includes formats like "XML Spreadsheet", "Csv", and "Biff8". This allows applications like Excel to communicate rich, specialized data to applications that support it (Excel itself being a good example).

A couple paragraphs ago, I used the word 'negotiate' when referring to the way that two applications use the clipboard to exchange data. As currently presented, that negotiation looks a lot like the source application making everything available and the sink application cherry picking the one format it wants. This is not a very balanced or efficient negotiation. However, the clipboard is actually more intelligent than that. To see what I mean, go to Excel, copy a huge range of data to the clipboard and run cbdump. The output list of formats will basically be the same as before, the difference is in the way the list appears. You'll notice that the list scrolls past unevenly, jerking along with some formats taking longer to list than others.

The reason for the uneven scrolling is that Windows does not force an application to always provide data in every clipboard format it supports. When Excel copies data to the clipboard, what it's really doing is telling Windows that it has the ability to provide data in a format, it is not necessarily rendering the data in every format at the time of the copy. Then, when a sink application requests data from the clipboard, Windows can see if it has an actual copy of the requested format. If not, it then requests that Excel render the clipboard contents in the requested format and passes that result to the requesting application. The way cbdump works, to show the size of each data format on the clipboard, it requests a copy of each available data format. This forces Excel to render every supported format, some of which take longer than others. If you happened to have a Windows message viewer looking at the message stream to the Excel window, you'd see a series of window messages requesting rendered copies of unrendered formats.