Often I feel like I spend too much of my time searching through the framework source and the Win32 API when developing .NET applications. Today was no exception. A colleague suggested that a pair of message boxes displayed the end user in some retail POS software appeared too similar and should have custom icons to help distinguish them.

Windows.Forms.MessageBox provides a wrapper for the Win32 MessageBoxEx function which only supports the four standard message icons. There is however the Win32 MessageBoxIndirect function which is not accessible via the standard .NET framework but does support custom icons. Unfortunately the MessageBoxIndirect function only supports icons embedded as a Win32 resource in the executable and .NET resources are embedded completely differently.

I can add a .rc/.res file to Managed C++ project to be embedded in the executable but the IDE doesn't support .rc/.res files in a C# or VB.NET project (which is the language used by the retail POS software). It is possible to use the command line tools to build the .res file from a .rc file and link it into a C# or VB.NET assembly but this would be awkward to do even with some Visual Studio IDE post-build addin. I could add a Managed C++ project to the solution to provide all the Win32 icon resources but either way this is becoming all too complex for a feature that was destined to be included in a common class library.

Considering .rc/.res files are language independent and are used by the IDE internally to embed the executable file's icon as a Win32 resource this should be possible. I would be very interested if anyone knows how to fudge a VB.NET project to link a .res file into the final output target as part of the standard build process.

On a similar note, I have ordered John Mueller's book ".NET Framework Solutions: In Search of the Lost Win32 API". Hopefully this will be very handy when I tackle the rest of the framework.

I often get the feeling that I am the only person who has setup Windows 2K/XP computers with limited-access users. Does everyone out there really configure every user as an Administrator? The majority of application software and games available today suggest this is true.

Microsoft published a document entitled "Designed for Windows XP Application Specification" about three years ago. I can only assume that nobody has read it or any of the other related publications or API documentation. On page 37 of this document is Section 3.0, "Data and Settings Management". Here it quite clearly explains where applications need to save user related data and how. The days of Windows 3.1 are over. We have a Program Files folder with security permissions denying write access to non-Administrators. This has been the situation since Windows 2000 (maybe Windows NT 4.0 also?). Yet too many programs attempt to store user configuration information in the same folder as the executable itself.

On my home PC, I have a user account for myself and a user account for my girlfriend, Libby. Libby's account is a limited user account and this breaks a lot of software. She can't use WinAmp without modified permissions on the application's install folder. Also, we each end up inheriting the configuration changes made by the other. Many games that Libby likes to play (including the new and fantastic Yourself Fitness!) have problems too. These games try to store game progress data in the game's install folder. As a result Libby has to start from the beginning everytime unless I change the default permissions.

As the administrator it is necessary for me to install any software that Libby requests. If I am happy it isn't something harmful that she has downloaded I go ahead. Unfortunately it seems that a lot of software won't install to multiple users either. It is not just that the setup program simply didn't put the shortcuts in the All Users start menu. If I create the appropriate shortcuts, the software still won't run under a non-privileged account.

I guess the problem is a combination of ignorance, failure to test restricted user scenarios, and simply considering the problem insignificant. WinAmp has been around for a long time. Version 5 was released not too long ago. However, discussions regarding multi-user support in WinAmp on the WinAmp developer forums have been dismissed as not important.

Everywhere we look today, the focus is on security but if even the most secure and stable software won't work for users other than administrators, what is the point?