Be careful when hosting your web site based on DasBlog from a Windows XP machine. While IIS 6 in Windows 2003 prevents the download of files with unknown extensions by default, the IIS 5.1 in Windows XP allows downloading such files. In the case of DasBlog all *.blogtemplate files are at risk. There are a few sites out there where these files can be downloaded. Although this probably isn’t a big security risk it might be something you want to prevent. Probably the easiest way to do that is by modifying the web.config file. You should add the following line at the end of the <httpHandlers> section:

<add verb="*" path="*.snippet" type="System.Web.HttpForbiddenHandler" />

DasBlog – the weblog engine this site is running on – allows extensibility through macros. You’ll need to use them as soon as you want any additional dynamic content on your site. (The ads you can see at the bottom of the right side bar are an example of a macro which I’ve recently updated to make the ad selection a little more advanced.) The documentation doesn’t mention their development at all therefore the following post by Vasanth Dharmaraj is probably the best source of information available on it. It actually discusses everything you need to know to get going. Make sure you read it before trying to write your first macro.

Before using EventLog.WriteEntry for adding events to event log you should consider calling EventLog.CreateEventSource to make your application a valid source of events. Keep in mind though that you need administrative privileges for it succeed, therefore it is best to call it at installation time. So, if you want to write to the application event log by calling:

EventLog.WriteEntry("MyApplicationName", "My event text");

don’t forget doing this first:

if (!EventLog.SourceExists("MyApplicationName"))
   EventLog.CreateEventSource("MyApplicationName", "Application");

If you want to view EPS images with IrfanView you need to have AFPL Ghostscript installed. I spent quite some time investigating why it worked on one machine and not on the other before I checked the IrfanView plug-ins web page where I found this useful bit of information.

Essentially everything you need to implement plug-ins in your application is some way to dynamically instantiate classes at runtime. As long as they all implement the same interface, you just use it to access its properties and methods.

In COM world this was achieved by calling the CreateObject function. In the managed world you should use AppDomain.CreateInstanceAndUnwrap as demonstrated by the following example:

IBind pluginInstance = (IBind)AppDomain.CurrentDomain.CreateInstanceAndUnwrap("MCPP", "DamirsCorner.Samples.LateBinding.MCPP");

Everything you need to know at runtime is the full class name (including the namespace) and the containing assembly. To get those you can either require their previous registration within the application or you can dynamically discover them by loading assemblies from a predefined location (Assembly.Load or Assembly.LoadFrom) and enumerating their classes (Assembly.GetTypes) whichever suits you situation best.

Either as a user or as a developer you have certainly noticed that sometimes the application just flashes in the taskbar instead of actually coming to the foreground when the SetForegroundWindow function is called. What you might not know is why and when this happens.

As far as the why goes the Application Compatibility Toolkit’s Compatibility Administrator puts it very nicely in the GiveupForeground compatibility fix description: In Windows XP the foreground semantics have been changed to stop foreground focus stealing by one application if another application is active.

Further investigation reveals that this is related to the ForegroundLockTimeout value. It defines how much time must pass since the last user input to allow another process to force its window into the foreground. Before that time such a window only flashes in the task bar. The default value is 200000 milliseconds. The setting is stored in the registry:

HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout

The value can be programmatically changed by calling the SystemParametersInfo function as follows:

SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);

The downside is that the call only succeeds when the calling thread has permission to change the foreground window which usually isn’t the case.

To make the long story short: you should never depend on being able to bring your application window to the foreground and this will certainly only get more restrictive in the future. If the flashing in the taskbar is not enough, you should consider using tray balloon pop-ups as the alternative way of notifying the user.

By default the Windows XP Welcome screen shows the users created through the control panel applet. Administrator is shown only if it is the only account with administrative privileges. You can change all that by setting up the correct values in the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

To change the default behavior for a user create a DWORD value with its name identical to the account name and set its value to 1 to show it or to 0 to hide it.

I really need to write down this information here so that I won’t be googling for it every time a friend or a coworker asks me about it. The default port number 3389 for RDP (Remote Desktop and Terminal Services) can be changed through the following registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber