The Emission Locus

Update: Encoding source files and documents as UTF-8 in VS2005

john — Thu, 21 Jun 2007 15:27:00 GMT

The old code was a bit tacky, using a timer to trigger the file encoding dialog. And of course it was buggy: it wouldn't work for multiple documents opening simultaneously.

So I've fixed it properly by using the WindowEvents_WindowActivated event. So when a window is activated, and it matches one of those non-BOM documents added by the DocumentEvents_DocumentOpened event, the encoding dialog is triggered for the document and then the next one in the list (if available) is activated.

Follow the instructions in the previous post to unpack and install (source included).

As usual, comments are welcome.

Encoding source files and documents as UTF-8 in VS2005

john — Sat, 16 Jun 2007 05:09:00 GMT

I'm picky about the encoding of my source files, HTML documents, etc. Whereever possible I save as either UTF-8 or UTF-16LE, both with a BOM (byte order mark). This ensures that the document can always be read without any encoding issues.

Although it has much better Unicode support than VS2003, VS2005 isn't very helpful with automatically selecting a file encoding; it assumes that the windows-1252 code page is sufficent. VS2005 does have an "Advanced Save Options" dialog on the File menu to set the encoding, but its not completely automated. Replaying a temporary macro recorded when using it will only bring up the dialog, but not choose the encoding.

My solution is a macro hooked up to the IDE's document open event. It brings up the "Advanced Save Options" dialog if the file does not have a BOM and also matches one of the supported file extensions (this list can be modified to suit your preferences). It works for new and existing documents; if the file is read-only the dialog is suppressed.

The environment doesn't directly support a "HasBOM" property as part of the EnvDTE.Document object so I've worked around that by reading the first few bytes of the underlying file to detect the encoded BOM.

To install unpack FixFileEncoding.vsmacros from the attachment into a directory somewhere. Then use the Macro Explorer to load the macro project; when prompted you must enable the event handling code or it won't work. If you don't feel comfortable loading someone else's macro file, I've also included the EnvironmentEvents.vb source file in the .zip file. You'll need to create a new macro project and then import this module.

VS2005 does have a cool feature for XML-style documents: if the document starts with a <?xml?> tag its encoding value is modified to match whatever is selected in the "Advanced Save Options" dialog. Very nice.

"Australian international airports now have even more CYA security"

john — Fri, 16 Mar 2007 06:24:00 GMT

The title of this post sounds like a sales pitch, but its just the morons in Australia's aviation security bureaucracy coming up with this rubbish for liquids, same as what has been done in the UK and the US:

http://www.dotars.gov.au/transport/security/aviation/lag/index.aspx

This is more "cover your ass" security that is just going to irritate innocent people and impact sales at duty free stores. The idiots that came up with this idea obviously assume that the vague group known as "the terrorists" or "them" don't read newspapers or watch TV. If this type of plot was foiled before, I'm sure at least one of them is aware of that and would try something else.

The whole thing is just an excuse for scared department heads to spend taxpayers' money to provide "enhanced safety" that has no benefit.

Bruce Schneier mentions more on this CYA nonsense in his latest Cryptogram newsletter.

Rebuilding the blog

john — Wed, 14 Feb 2007 06:47:00 GMT

I'm slowly rebuilding the blog articles and associated downloads, after moving to a new ISP from my self-hosted setup. Much easier to manage given the issues I've had with Bigpond's new login system.

I uninstalled IE7 within 30 minutes of installing it

john — Thu, 21 Dec 2006 04:34:00 GMT

Now I may not be a typical IE user, since I'm a developer, but I am more of a keyboard person than a mouse person.

Frankly, whoever it was on the IE7 design team that decided to make the address and command bars immovable should be given a good beating. And the same goes for the search box feature, which you can't hide or reposition.

In my IE6 configuration I have the menu on the top row, the next row has the tool icons (including Print Preview) and the Links bar, and the last row has the address bar and Google plug-in (for auto-complete, etc.). Using this configuration, if I get to the last link on a page one Tab keypress and I get to the address bar, another to the Google search, and then back to the page. IE7 adds another 4 or so Tab keypresses.

I agree with making the toolbars properly accessible with the keyboard, but this should be configurable (for backwards compatibility) via the Advanced Options dialog, or at least a documented registry setting for power users. The drop-down buttons are a nice idea, but I should also be able to show them all on the bar itself. The toolbar customization process is still minimalist and different to other products such as Visual Studio 2005, Visio 2003, etc.

Overall, 1 out of 5. Only recommended if you never customize IE and take what you're given.

Tommy Emmanual is a guitar legend

john — Tue, 24 Oct 2006 10:51:00 GMT

I have left Australia for a while and am currently in Singapore.

Last night's concert by Tommy Emmanuel at the Victoria Theatre was brilliant, and everyone thoroughly enjoyed themselves for almost 3 hours. I've been an Australian fan since the '80s and its easy to see that Tommy's talent and techniques have continued to mature. If you like acoustic guitar make an effort to see him live; some of the things he can do with his guitars are amazing. Highly recommended.

Using MSXML4 in an application installed by a non-administrator account

admin_user — Thu, 24 Aug 2006 10:55:00 GMT

An application I've been working on requires MSXML4 for validating instance documents against an embedded schema, but one of the installation requirements is that it must be able to be installed by a non-administrator. The offical Microsoft installer requires administrator privileges so this option is out. This caused a few headaches.

Then I remembered that application manifests can specify a list of COM objects exposed by a local DLL. This led to a solution that works, but is not Microsoft-approved.

The trick is to install MSXML4 in side-by-side mode on the development box (use the custom install option), then navigate to the \Windows\WinSxS folder. In the Manifests subfolder you'll find .manifest files for the side-by-side installations of MSXML4.dll (the manifest filename includes MSXML2, which is the library's COM namespace) and MSXML4R.dll (the manifest filename includes MSXML2R). The MSXML4R version number must match the value in the MSXML4 element.

Copy the entire element from both the MSXML4 and MSXML4R manifests into your application manifest's element (but don't copy MSXML4's element). Now MSXML4 is part of your assembly.

Also copy the matching DLLs from the \Windows\WinSxS tree to your application folder and voila! MSXML4 can be installed and used by a non-administrator.

Your application's folder should also have a appname.exe.local file so the COM redirector will force the local MSXML4 DLLs to always be used.

Important things to remember are that this scenario is not supported by Microsoft and that any updates to the MSXML4 files must be serviced by your application.

So an example manifest for Foo.exe using MSXML 4.0 SP2 (MSXML4.dll version 4.20.9818.0 and MSXML4R.dll version 4.1.0.0) should look something like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 <assemblyIdentity type="win32" name="Foo.exe" version="1.0.0.0" processorArchitecture="X86"/>
  <file name="msxml4.dll" hash="80e5fb356b5f5cfe6f765a9ffe1eb749642a2e0f" hashalg="SHA1">
   <typelib tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}" version="4.0" helpdir=""/>
   <comClass description="W3C-DOM XML Document (Apartment)"
             clsid="{88d969c0-f192-11d4-a65f-0040963251e5}"
             threadingModel="Apartment"
             progid="MSXML2.DOMDocument.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="W3C-DOM XML Document (Free threaded)"
             clsid="{88d969c1-f192-11d4-a65f-0040963251e5}"
             threadingModel="Free"
             progid="MSXML2.FreeThreadedDOMDocument.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="Object for caching schemas"
             clsid="{88d969c2-f192-11d4-a65f-0040963251e5}"
             threadingModel="Free"
             progid="MSXML2.XMLSchemaCache.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="Object for caching compiled XSL stylesheets"
             clsid="{88d969c3-f192-11d4-a65f-0040963251e5}"
             threadingModel="Free"
             progid="MSXML2.XSLTemplate.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="XML Data Source Object"
             clsid="{88d969c4-f192-11d4-a65f-0040963251e5}"
             threadingModel="Apartment"
             progid="MSXML2.DSOControl.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="XML HTTP Request class."
             clsid="{88d969c5-f192-11d4-a65f-0040963251e5}"
             threadingModel="Apartment"
             progid="MSXML2.XMLHTTP.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="Server XML HTTP Request class."
             clsid="{88d969c6-f192-11d4-a65f-0040963251e5}"
             threadingModel="Apartment"
             progid="MSXML2.ServerXMLHTTP.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="SAX XML Reader 4.0 coclass"
             clsid="{7c6e29bc-8b8b-4c3d-859e-af6cd158be0f}"
             threadingModel="Both"
             progid="MSXML2.SAXXMLReader.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="Microsoft XML Writer 4.0 coclass"
             clsid="{88d969c8-f192-11d4-a65f-0040963251e5}"
             threadingModel="Both"
             progid="MSXML2.MXXMLWriter.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="Microsoft HTML Writer 4.0 coclass"
             clsid="{88d969c9-f192-11d4-a65f-0040963251e5}"
             threadingModel="Both"
             progid="MSXML2.MXHTMLWriter.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="SAX Attributes 4.0 coclass"
             clsid="{88d969ca-f192-11d4-a65f-0040963251e5}"
             threadingModel="Both"
             progid="MSXML2.SAXAttributes.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
   <comClass description="MX Namespace Manager 4.0 coclass"
             clsid="{88d969d6-f192-11d4-a65f-0040963251e5}"
             threadingModel="Both"
             progid="MSXML2.MXNamespaceManager.4.0"
             tlbid="{f5078f18-c551-11d3-89b9-0000f81fe221}"/>
  </file>
  <file name="msxml4r.dll" hash="e09c7d1cb933719ab19ddae866e6cc0846eccdc4" hashalg="SHA1"/>
</assembly>

Issue with application manifests on XP

john — Wed, 12 Jul 2006 16:47:00 GMT

Someone forgot to test for this:

Create an application manifest document (e.g. foo.exe.manifest) and include it as part of your foo application.
Mark the <xml> tag with the encoding="UTF-8" atribute.
Compile and test your sample app; works as expected.
Now use VS's Advanced Save Options dialog (or Notepad's Encoding option on the Save As dialog) to save it as UTF-8 with a BOM marker. This is a perfectly legal option.
Recompile. The test run now fails!

So the process loader's internal XML parser doesn't handle the BOM marker. I'll have to log a bug for this.

Custom Remote Desktop window sizes

john — Tue, 11 Jul 2006 08:54:00 GMT

Here's a good tip from Kudzu's blog:

I use remote desktop a lot. But 800x600 is too small, and if I use 1024x768 then it goes full screen and its not convenient to move between host and guest easily. To compound this, I run multiple remote desktops as well as virtual PC's. What I really want to do is run remote desktop in about 1000x720 so I get a large screen but still have quick access to the task bar and system tray of my host. Remote desktop has no options for these custom resolutions, but you can edit the RDP file.

Create a remote desktop connection and save the profile. It makes a file with an .rdp extension. This file is just a text file, so now open it in Notepad. The first few lines should look something like this:
    screen mode id:i:1
    desktopwidth:i:1015
    desktopheight:i:715
    session bpp:i:16
    winposstr:s:0,3,0,0,1015,725
I have done some testing and I found 1015x715 to be just about right for a 1024x768 host. The winposstr line specifies the initial size of the window on the host. Setting the second parameter to 3 makes it auto fit, and thus the other numbers are not needed.

A gotcha with the SetLocalTime API

john — Mon, 03 Jul 2006 11:59:00 GMT

Its been a long time between posts; I've been consumed by the tail end of a major project, including a number of longer-than-expected overseas trips. Anyway, to the issue at hand:

If your code calls SetLocalTime take special note of the documentation in recent versions of the PSDK (and also mentioned in MSKB article 234735):

"The system uses UTC internally. Therefore, when you call SetLocalTime, the system uses the current time zone information to perform the conversion, including the daylight saving time setting. Note that the system uses the daylight saving time setting of the current time, not the new time you are setting. Therefore, to ensure the correct result, call SetLocalTime a second time, now that the first call has updated the daylight saving time setting."

This tripped one of my test cases for an embedded application that may adjust the system time.

Workaround for bug in FormatMessage API

john — Mon, 28 Nov 2005 13:59:00 GMT

The FormatMessage API appears to have a bug that causes its behaviour to not match its documentation.

This occurs when the specified module does not have a MESSAGETABLE resource and both the FORMAT_MESSAGE_FROM_HMODULE and FORMAT_MESSAGE_FROM_SYSTEM flags are specified. Instead of continuing the search in the system modules the API fails and GetLastError() returns ERROR_RESOURCE_TYPE_NOT_FOUND (1813).

Here's the workaround:

HRESULT hr= E_ACCESSDENIED; //or whatever
_bstr_t rv; //for the error text

//
//NOTE: FormatMessage will fail if the FORMAT_MESSAGE_FROM_HMODULE
//      flag is specified and the module does not have a MESSAGETABLE
//      resource, even if FORMAT_MESSAGE_FROM_SYSTEM is specified!
//
const DWORD moduleFlags= (  FORMAT_MESSAGE_ALLOCATE_BUFFER  |
                            FORMAT_MESSAGE_FROM_HMODULE     |
                            FORMAT_MESSAGE_MAX_WIDTH_MASK);

const DWORD systemFlags= (  FORMAT_MESSAGE_ALLOCATE_BUFFER  |
                            FORMAT_MESSAGE_FROM_SYSTEM      |
                            FORMAT_MESSAGE_MAX_WIDTH_MASK);

CHeapPtr<WCHAR, CLocalAllocator> msg;
if (!::FormatMessage(moduleFlags, GetModuleHandle(NULL),
        (DWORD)errorCode, 0, (LPWSTR)&msg, 0, NULL))
{
    ::FormatMessage(systemFlags, NULL, (DWORD)errorCode, 0,
            (LPWSTR)&msg, 0, NULL);
}

rv= msg;

Note: the code uses the ATL CHeapPtr and CLocalAllocator classes.