There have long been complaints about undocumented functions in the Windows API which give Microsoft’s internal developers an advantage over third-party software developers. Perhaps even more frustrating are those that are semi-documented. An example was found recently by a user of the htmleditor, a .NET wrapper for the HTML editor built into Internet Explorer. If you write an editor you might want to support undo and redo; there are simple undo and redo commands available but they are crude. The API also provides more advanced functions, including a change log and the ability to undo or redo entries in the log. You can find the documentation here; the relevant interfaces are IHTMLChangeLog, IHTMLChangePlayback and IHTMLChangeSink.

All looks good on a brief inspection; but note the lack of any sample code. Then think about how you might want to use this API. What exactly does an item in the change log represent – a single character, an HTML element, a paste operation, or what? How can you inspect the items (they seem to be a binary black box, understood only by an API function called ExecChange)? There is only one function for iterating through a change log, called GetNextChange – are you intended to cache the entries somewhere, since there is no GetPreviousChange or GetFirstChange? The API allows for notification of changes, but the Notify event has no arguments: presumably you are meant to call GetNextChange and do something or other with the log entry.

Of course developers have shrugged their shoulders and experimented a bit. Some have found Notify failing to fire, particularly with MFC. Others have just been puzzled. I tried it with my C# wrapper and got strange results; I think the only way forward would be to reverse-engineer the log entries to work out what it is they represent.

But what about Microsoft’s developer support? There are managed newsgroups, which are meant to guarantee a response for developers with MSDN subscriptions, as well as other online forums supposedly monitored by Microsoft developers – like Senior Program Manager Dave Massy, who says in his welcome:

Welcome to the MSDN forum for Internet Explorer Addon Development. If you have questions around development of extensions for Internet Explorer then this is the place to ask them.

Perhaps it is; but Massy is strangely silent on the intricacies of IHTMLChangeSink. I have seen this often: easy questions get a ready reponse either from Microsoft or from community members, but the tough ones, where only Microsoft has the answer, are simply ignored; or else there is a request for further information which looks promising at first but leads nowhere. Try Googling on this API; you will find questions but few answers.

My question is this: why bother publishing the API at all if it is so poorly documented and badly supported that nobody can figure out how to use it?

I would guess that this API is or has been used internally, by other Microsoft products that use the IE editor, and that somewhere in the bowels of Redmond there is proper documentation or sample code, perhaps not in sufficiently polished form for general release.

It’s time Microsoft either stopped pretending to offer developer support through these online forums, or put in the effort required to make them work.

It was good to see – at last – the release of Visual Studio 2005 Service Pack 1 Update for Vista.

I was hoping this update would remove the need to run Visual Studio 2005 with administrator rights on Vista. Unfortunately I don’t think it does. It’s hard to be sure; in fact, I can’t find any clear statement about what the “Update for Vista” actually does. Following the “more information” links on the download page is like playing the original Adventure game – a maze of twisty little passages, all alike – none of which tells you what you want to know.

Still, I note that the list of bad things which happen when you run with normal permissions still exists; so I’m presuming Microsoft still recommends using “Run as administrator” for Visual Studio.

I dislike doing this. I don’t develop on Linux as root, nor on the Mac – why should it be needed on Windows? I realise that some things need local admin rights for good reasons – registering a COM DLL, for example – but I don’t see why I should have to run the entire IDE as admin just for the sake of those few activities.

How dangerous is it? I presume it’s no worse than running as admin on XP, for example, but it’s pretty bad. For example, I checked out what happens with online help if you use “Run as administrator” to start Visual Studio. Help opens in a separate application called Document Explorer, which embeds Internet Explorer to render the online documentation. As I expected, if you open this from Visual Studio’s Help menu it runs with elevated rights. Naturally, the docs include links to external web sites. What if you right-click one of these and choose “Open link in external window”? The site will open in IE, but take a look at bottom right. “Protected mode off”. In fact, IE is now running with a high integrity level, just like Visual Studio. Nothing to stop you browsing the web from here, probably not realising you are more at risk than usual.

It’s crazy to be reading documentation and browsing the web with full admin rights, just to keep Visual Studio happy.

I intend to try running Visual Studio as a normal user and see how it goes. I reckon it will work for some projects at least.

Note: if you want to see the integrity level of the processes on your system, download the latest Process Explorer. You’ll need to select the Integrity Level column. The ins and outs of UAC and the extent to which it protects you are discussed in Mark Russinovich’s blog entry on the subject.

I am late with this; Paint.NET 3.0 was released at the end of last month. It deserves more publicity, since it is of high quality. If you have .NET Framework 2.0, Download it here.

The application is fine for general use; I may switch to it from my old favourite Paint Shop Pro, for trimming and touching up screen captures. One feature I like is the way it handles multiple documents. A thumbnail of each open document appears at top right, in a fat toolbar; click a thumbnail to switch to that document.

Paint.NET is particularly interesting for developers. It is written in C#, and started out as a design project; as I understand it, one of the intentions was to discover whether Microsoft’s .NET Framework was up to the task, given that image applications do a lot of intensive number-crunching. Most of the code is C# but not quite all. There is a shell extension written in C++ and some use of PInvoke and COM interop. I get the impression that the chief developer Rick Brewster is now more interested in creating an excellent application than in proving a point about .NET.

One point of interest is the user of multi-threading for optimized performance on multicore processors. Brewster has recently posted his performance tests on various processors from two to eight cores:

The 8-core system is frightfully fast, and it’s very clear that having rendering code optimized for multiple threads is a big win. However, I will be honest and state that the performance scaling is not at the level I was hoping for: we’re already seeing diminishing returns at this point! In general, I am seeing gains of about 3.0x on a quad-core system, and 5.1x on an 8-core system (compared to running with only 1 thread). Unfortunately, I do not have an 8-core Opteron system to compare against which might provide some more meaty information to chew on (does it scale better? worse?).

I take his point, though a 5.1x gain on an 8-core system strikes me as decent. I recommend downloading the source code and taking a look; it is well commented and has workarounds for various System.Windows.Forms annoyances. Before you ask the obvious question, Brewster recently commented in the Paint.NET forum that he has not yet looked at WPF (Windows Presentation Foundation).

In the user data area in Vista is a virtual store. Find it at:

C:\Users\[USERNAME]\AppData\Local\VirtualStore\

It is worth having a peek now and again. Here’s part of mine:

The Virtual Store is a feature of User Account Control, the centerpiece of Vista’s enhanced security. Applications that try to write to protected system locations, including Program Files, Windows, and HKEY_LOCAL_MACHINE in the registry, are prevented from doing so. Instead, a compatibility feature kicks in, and these applications write to a location in your home directory. Registry entries are written to a special area in HKEY_CURRENT_USER. The application mostly won’t know the difference, though there are limitations and you can get strange results. For example, if an application deletes a file from the virtual store when a file of the same name exists in the real location, the delete appears to succeed but the file still exists. Virtualization also fails (by design) if the application is run under another user account, or using Run As Administrator. The files written to the first user’s virtual store are invisible to these other users.

Virtualization is a stop-gap measure. Well-behaved applications should not write to these locations except when first installed, or for maintenance, both of which are administrative tasks. So the Virtual Store is a hall of shame. Microsoft features heavily in mine; we can just about forgive the appearance of the beta Expression tools, but Visual Foxpro 9.0? Adobe’s Flex Builder 2 is another disappointment. In most cases there are only one or two files, so we are not talking about major design issues, but they still need fixing.

If you are developing software, it is worth checking your virtual store in case stuff is slipping through. Note that you must have UAC enabled, and not be using Run As Administrator, since either of these settings will prevent the virtual store being used.

Technorati tags: vista, virtualstore, uac, security