New utility for download: ccc.exe ("Clipboard Character Count")

I've put a new command-line utility that I developed, ccc.exe, up for download on my utilities page.

ccc is short for "clipboard character count". This simple utility returns the number of characters currently present on the Windows clipboard.

The utility supports an optional -all switch to specify that the utility should return the length of all forms of text from the System.Windows.Forms.TextDataFormat enum, instead of just returning the count of plain text characters.

A minor formatting nicety in Visual Studio 2005

While working in Visual Studio 2005, I noticed a cool Autoformat-like behavior provided by the IDE.

I was working in a class that had a private class constant declared that I wanted to change to have public instead of private visibility. The original code looked something like: private const int MaxItems = 5; I used the ctrl+rightArrow keyboard shortcut to select a nearby instance of the keyword public, and then hit ctrl+c (Clipboard Copy), so I ended up with "public " (including the trailing space) on the clipboard.

I then double-clicked the instance of the "private" keyword that I wanted to replace to select it, and pressed ctrl+v to do the paste.

After the paste, the result was: public const int MaxItems = 5; This struck me as odd for some reason. After thinking about it briefly, I realized that I should have been left with an extra space after "public", due to the trailing space that was present on the clipboard: public  const int MaxItems = 5;

However, Visual Studio recognized what I was doing, and automatically removed the extra space for me, saving me a press of the Delete key after the paste. I tried pressing ctrl+z (Undo), and Visual Studio restored the removed space; a second ctrl+z press rolled back the Paste operation.

A very minor feature, but also indicative of the great attention to detail that Microsoft has put into the Visual Studio IDE. Pretty nice!

Fix: "This file is not in the standard Zip 2.0 format" (Winzip)

Earlier today, I was attempting to copy a large VMWare virtual machine image file to my test machine at the office. I was able to copy the compressed .zip file, about 3 GB in size, to the machine with no trouble. However, when I tried to use Winzip to decompress the file, I got an error: "skipping: [filename] this file is not in the standard Zip 2.0 format":

I had previously set up the same virtual machine image from the same .zip archive on another machine. I tried copying the uncompressed image file (about 6 GB in size) from that machine, but got another error, this time from Windows Explorer: "there is not enough free disk space".

I checked, and I did have only about 5 GB free. At this point I figured that the Winzip error might have been a symptom of the insufficient free space on the drive, with the weird error text possibly being attributable to the large size of the file.

I cleared some large files off the drive -- mostly old SQL Server databases and old Virtual PC images -- and got up to over 20 GB of free space. However, when I retried the copy operation, I still got the same error from Explorer about insufficient free disk space.

A quick Google search on that error revealed that the problem might be that if the test machine was running the old FAT32 filesystem instead of the modern NTFS system, that error message could result, as FAT32 supports file sizes only up to 4 GB. I also noticed that Winzip was reporting the uncompressed size of the virtual machine image file as 4 GB instead of the correct 6 GB, which seemed to be a symptom consistent with the .zip archive file being stored on a FAT32 drive. The test machine was indeed running FAT32 (checked by opening My Computer from the desktop, right-clicking the C drive, and selecting Properties from the context menu) and I had no reason not to upgrade it, so I went ahead and ran convert.exe to do the upgrade to NTFS.

When the upgrade to NTFS eventually finished, I once again tried to copy the uncompressed machine image across the network to the test machine, but the network itself decided not to cooperate at this point, and the transfer was progressing extremely slowly (even given the 6 GB file size). So at that point I turned my attention back to uncompressing the image from the .zip archive, figuring that it would now work since the filesystem was now NTFS and the disk had sufficient free space.

To my surprise, I continued to get the same error about "Zip 2.0" format. I also noticed that Winzip was still reporting the uncompressed VM image file size as 4 GB instead of the correct 6 GB. Earlier I had ignored the www.winzip.com/zip20.htm URL mentioned in the Winzip error message, assuming it would be similarly unhelpful to the Microsoft site links that Windows error dialogs that come up when an app crashes occasionally provide, but at this point I figured it was worth a look.

The text on the linked page isn't terribly helpful, mostly text encouraging an upgrade to Winzip 10 (which isn't a free upgrade even for registered/paying users of Winzip 9 and previous versions). However, it does mention something about a particular compression method, "bzip2", requiring Winzip 9 or later.

At this, I checked the Winzip version numbers (on the app's Help | About menu) on both of my machines. On the machine where I had previously successfully uncompressed the large virtual machine image file, Winzip 9 was installed; on the test machine where I was having trouble, Winzip 8 was installed. Aha!

I upgraded the test machine to Winzip 9. Once that was done, I was able to uncompress the image file from the .zip archive with no trouble.

So, on the "this file is not in the standard Zip 2.0 format" error from Winzip, the thing to do is to upgrade to Winzip 9 if you're running an earlier version. It took me a while to get that figured out, but at least I had a reasonable excuse to spend a little time to get the disk on my test machine cleaned up and upgraded to NTFS along the way. :-)

Usability: When the "Close" icon doesn't.

On the Windows platform, there are several icons that can appear on the buttons at the upper-right corner of an application window that have a well-defined, standardized functionality. Examples include a horizontal line to minimize the window, a single rectangle to maximize the window, and, perhaps most commonly, an "x" to close the window.

In most cases, when then "x" button is clicked for the main window of an application, the expected behavior is that the button click closes that application. However, for some applications, a click on the application window's "x" button, instead of closing the application, instead performs a "minimize to system tray" operation. Applications that display an icon in the Windows system tray (or "notification area") often (but not always) have this behavior. Microsoft ActiveSync is an example of such an application:

In general, since the "x" button cannot be used to close (exit) such applications, users wishing to close the application must employ some other (non-standardized) method, such as a menu pick in the application window, or a menu pick in the right-click menu of the app's system tray icon. (Some system tray apps don't allow themselves to be closed at all short of manually killing their process, but that's a separate issue!)

It would be nice if a new standardized button icon were used in place of the "x" icon for the "minimize to system tray" functionality. I propose using a small horizontal line in the lower-right corner of the button; this would follow the convention of the left-aligned horizontal line that appears at the bottom of the standard "minimize" icon. Here's a quick sketch I put together in mspaint.exe:

When appropriate, application designers could use the new "minimize to system tray" icon alongside a standard "x" icon, allowing users to easily either minimize the app to the tray or exit it, as desired. This would be an improvement over the current state of affairs where designers must choose which of two standard behaviors -- "close" or "minimize to tray" -- to assign to the "x" button of the main application window.

Microsoft Security Summit 2006

Today I attended the Microsoft Security Summit 2006 conference in Novi, Michigan. It's a free conference that Microsoft has been putting on in various cities targeted at both developers and IT folks promoting good security practices.

Keynotes

Both keynote speakers were very good. The opening keynote by Bret Arsenault was information-packed. Bret gave an overview of the history of security challenges in the IT industry along with solid coverage of the challenges facing the industry today. The hour length of the keynote flew by quickly, a sure sign of an interesting session.

The closing keynote by Jesper Johansson, covering security improvements in Vista, was also (to invoke the cliche) entertaining and informative. I've been subscribed to Jesper's blog for a while now, so it was cool to hear him speak in person (particularly since he turned to out be a good in-person presenter as well as a good blogger). I didn't recognize Jesper by sight, as he wasn't wearing his scuba gear. :-) Jesper made a wry observation about why security can be a hard sell to corporate executives: It's a significant financial investment which, when finished -- if done properly -- will result in everything continuing to work as it has before!

Jesper also made a comment which makes good sense from a security perspective, but perhaps not from a "real-world" perspective. He asserted that any application which either requires administrative privileges to install and run, or writes per-user data to shared areas of the filesystem such as under Program Files or the Windows folder, is "broken." Jesper mentioned Adobe's Photoshop as an example of such an app.

I agree that such applications are certainly less than ideal, but for many software shops, the time and money to engineer apps to run well not just on all currently-available versions of Windows but on potential future Windows versions as well is a luxury that can't always be afforded. Not everyone has the cash in the bank to support the delay and re-delay of product releases to ensure that functionality that does not directly impact the user experience is perfect, like Microsoft is attempting with Vista. Still, the ideal of applications that are engineered superbly from both a features and security perspective is a worthy goal for developers.

Break-Out Sessions

One of the afternoon sessions focused on some types of attacks to which web applications are susceptible, such as SQL injection. I had heard variations of this session a couple of times before, including once at the 2003 PDC conference in Los Angeles. This session included one particularly nasty attack which was new to me, though, called a "one-click" attack. (The attack name brought to mind the infamous Amazon patent of the same name, although it turned out to be unrelated.) This attack involves coding a hidden form into a simple .html page which, when visited, invisibly auto-submits a request to another site to which the victim had recently logged in.

The example of the attack demonstrated was an employee visiting a (deceptively) simple "car for sale" web page on the internal corporate site, which modified the target account/routing number for the user's paycheck direct deposit via the recently-visited internal HR site. Dangerous stuff. (The solution involves setting up a key based on the session ID that is required to be submitted along with the change request, using an ASP.NET 1.1 ViewStateUserKey or other means.)

The second afternoon break-out session covered new features in Visual Studio .NET 2005 and SQL Server 2005 that support development of secure applications. One new SQL Server feature mentioned was EXECUTE AS, which uses impersonation to enable subsequent queries or commands to be run under the security context of another user. Impersonation is ended when a REVERT is run.

During the Q&A at the end, I asked whether nested EXECUTE AS operations were supported; in other words, if I do, in order: EXECUTE AS 'Alice' EXECUTE AS 'Bob' REVERT Then who am I running as at that point -- Alice, or the original user? The presenter wasn't sure. I looked into this briefly, and apparently (per this Bob Beauchemin blog post) nesting is indeed possible.

Also during the last afternoon break-out session, developers sitting in the first 5 rows (plus those who were willing to move up to the front from the back) got a free copy of the "Required reading at Microsoft" book Writing Secure Code, 2nd Edition. Happily, I was sitting in the 5th row. :-) I did partially read through a copy of this a couple of years ago, shortly after its release; now, with another couple of years of experience under my belt, I plan to give the book a more thorough read-through.