With the upcoming release of Windows 7 by Microsoft I am still surprised at a limitation of Explorer that has been around since explorer was first introduced with Windows 95. When Microsoft first introduced Windows 95 they included long filename support. This long filename support allowed Windows to store a filename of “up to 255 characters” while still maintaining compatibility with DOS and previous versions of Windows.

Remember filenames like LETTER~1.DOC and directories like PROGRA~1? Well, believe it or not they still exist by default in Windows 7! You can confirm this yourself by opening a command prompt and running the dir /x command. This will display files in the current directory with both their long filenames and DOS compatible filenames. Of course you can turn this filename generation off by setting the appropriate registry keys.

Back with Windows 95 the Windows API generally provided only ANSI functions. ANSI strings were either single-byte or a variable-width multi-byte arrays. When Windows NT came along with its new kernel, all of the internal strings were represented in Unicode (double-width) character arrays.

Along with the Unicode kernel, Windows NT also included updated APIs that used the new Unicode strings. So for every CreateFileA you now had a CreateFileW. To maintain backwards compatibility the original CreateFileA still had the limitation on the length of the path that Windows 95 did. Otherwise known by the macro of MAX_PATH which is defined as 260. Since CreateFileW was a new function, there was no backwards compatibility to maintain, so Microsoft provided a way to provide a path up to 32,676 characters. You can read more about the maximum path length on MSDN.

The drawback of still providing both APIs is that as applications pick and choose they can run into issues with the length of the path. Microsoft Word uses the CreateFileW function which allows them to create longer filenames than explorer can handle. I was hoping that in Windows 7 Explorer would finally be updated to use the Unicode CreateFile function… since Windows 95 was released over 14 years ago.

Unfortunately I ran into Explorer’s 260 character limitation just the other day. One of the deleted files resulted in a path of 273 characters long and the following dialog popped up:

I am currently writing a .Net application to listen, log and graph the temperatures and fan speeds of my servers using the xAP protocol. I’ll be using SpeedFan to monitor the temperatures and fan speeds of the servers because SpeedFan includes the ability to broadcast the current sensors using xAP. Sounds complicated right? We’ll lets look at the xAP protocol first.

The xAP Home Automation Protocol is a lightweight, ASCII based communication protocol. It’s a simple protocol that takes very little processing power to use and is actually easy to work with. It seems their goal is to work across multiple mediums (ethernet, serial, parallel) and multiple systems (full machine, light embedded systems, and even audrino boards!) while remaining simple and human readable.

xAP-header
{
v=12
hop=1
uid=FF671100
class=PC.status
source=Almico.SpeedFan.NARU
}
temp.1
{
id=Core
curr=48.0
want=40
warn=50
}
temp.2
{
id=CPU Off Die
curr=40.0
want=40
warn=50
}
temp.3
{
id=Motherboard
curr=40.0
want=40
warn=50
}
temp.4
{
id=HD0
curr=48.0
want=40
warn=50
}
fan.1
{
id=Fan1
curr=3342
}

As you can see in the message above you can easily read the following information:

• The class of the message is the type of PC.Status.
• The source is from SpeedFan by Almico on the computer Naru.
• There are 4 temperature sensors and 1 fan sensor on the server as reported by SpeedFan.

xAP over Ethernet uses a UDP broadcast on port 3639. Now, armed with this information, writing a simple .Net console application doesn’t seem too hard does it?

Hopefully by now you can already see a way or two in processing this text-based message. Believe me, it isn’t as hard as it seems! Over the next couple posts we’ll see a method for parsing the message and the incorporation of a few of the newer .Net technologies (some extension methods and lambda expressions)! Stay tuned!