Mike Schaeffer's Blog

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.

I don't know how plausible it is, but it'd be awfully nice if laptops had a way to power USB ports when the machine is off but plugged in. Perhaps this could be controlled by a switch on the side of the case that turns on USB power only.

The use case, of course, is for portable devices that can charge their batteries over a USB connection. Apple has stopped bundling anything except a USB cable with the iPod, and it's pretty easy to find USB power cords for PDA's and cell phones. With this kind of functionality in a laptop, the laptop could become a traveler's one central power adapter, eliminating the need to carry large numbers of dedicated adapters or half-baked partial solutions like the iGo. I can see paying 50-60 dollars extra for a laptop with this feature.

Another way this could be implemented would be to put 3-4 power-only USB ports on the laptop's power brick.

My blog setup requires that I log in via ssh to my webserver to use a text editor to edit articles in raw HTML. This is the downside of using barebones blog software. On the flip side, it'd at least be pretty easy to add a (private) article submission form. All it would have to do is present a list of subdirectories in the blosxom hierarchy, and allow content from a text box to be deposited into a named file with a specified timestamp (which can be set with touch). Step 2: allow these files to be edited in a text box.