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