The Moth

Well, not just yet but this month none the less. Everyone will receive Internet Explorer 7.0 via Windows Update (after they accept the EULA).

For web devs this means making sure your web pages work on IE7. It should, as a lot of effort was put into compatibility apparently, but all those CSS improvements and security enhancements (especially “protected mode” on Vista) may break you... who knows (other than you!)

I am not a web dev so I just see this from an end-user's perspective. I have switched to IE7 for a while now. You may think "Yeah, since you can't run IE6 side by side with IE7, obviously you have switched in order to dogfood IE7". Well, yes that is true, but to be perfectly honest with you, I meant that I switched from Firefox. That's right, I am one of the crowds that switched from IE to Firefox just over a year ago and now I have switched back (with my only gripe being no free ad-blocker out of the box, but I might be tempted by an add-on).

The main thing firefox gave me is now present in IE7: Tabbed browsing (and it is done a lot better IMO with closing/newing/previewing hitting the sweet spot).

Other things I like are the RSS integration (inc. RSS platform), easy page zooming, printing now does the right thing by default and integrated search that lets me add custom search providers e.g. I've added one that searches my blog:


The other thing, which is quite significant, is that IE7 just seems a lot faster (I wonder if someone can prove that for me please, I just know it is true).

Of course, there are websites out there doing stupid things like checking if they recognise the browser. In other words, an idiotic person wrote code that says "I explicitly recognise IE6 and support it, but anything else that will come in the future I will just not render and give out a silly message". As you can probably tell by the emotion in my statement, I have been dealing with such a 3rd party crap website to order my company car... anyway... if you are in that scenario too, you can always spoof the website by using this user agent tool (even more useful on Vista where there seems to be no way to remove IE7+).

Bottom line... try IE7 if you haven't already... you will like it (screenshot in my previous blog post).

I hate to make all this sound like an advert, but see it as my way of saying "thank you" to the IE team for a product I genuinely like!

Whenever I talk about the Vista enhancements in Windows Error Reporting, I am surprised to discover the number of devs that ask me "What is winqual?”

You know how sometimes an application crashes and then you hit that "send" button in the dialog that pops up? Well guess where it sends those reports (which can include your own diagnostics!).

That isn't just "a server that Microsoft uses to diagnose potential system issues". It is a server with data about *your* application, waiting for *you* to examine that data. Simply go register for free on winqual.

If you fix a bug and want to update all those users that have been hitting "send", how do you update them? Yup, winqual again. Trust me; it will make them happy :)

So what are you waiting for, use the Vista enhancements, register with winqual for free, examine the bug reports, and update your users with the solution. Let me hear you repeat after me (am I taking this too far?):

"I am off to http://winqual.microsoft.com/"

I really hope you guys were not waiting for me to point you to a (fairly) new blog on Vista. This is the authoritative blog of the Shell team that is growing in readership like no other blog ever has.

Go read everything they’ve written to date as every single post is a gem, e.g. the one about minesweeper or the one about the menus or best of all the one with the treat at the end.

And if you’ve had enough of serious information, they published something on the lighter side today :-D

Remember that rss download feed I was telling you about? It just "dropped me a line" to say that all the MEDC content is available for anyone to download!

Go get the MEDC 2006 conference DVD!

My session was APP330...

I have explained before what you (a managed developer) has to do about User Account Control in Vista (and also expanded a bit on UAC policies).

The other day I got asked exactly how this works under the covers. Luckily, my mate Kenny covers this on his article (butchered quote):

When an administrator logs on to a computer ... the system ... creates ... two different tokens representing the same logon session. The first token grants all the permissions and privileges afforded to the administrator while the second token is a restricted token ... offering far fewer permissions and privileges. ... The system then creates the shell application using the restricted token.

Follow this link for the full unedited story.

I promised I’d let you know when WMDC for RC1 was out. Also given that most people searching for an ActiveSync replacement or for Windows Mobile Device Centre land on my blog, it is only fair that I let you have some links!

WMDC Beta3 page here. (Notice how now there is also support for Windows Mobile 2003 :))

How did I know? I got notified via the download center RSS feed (don’t tell me you are not subscribed to that?!) about the download page.

When I booted up my laptop today, with no intervention on my behalf, an unobtrusive message in a balloon on the tray informed me that there were solutions to my problems (or words to that effect, I doubt Vista can do anything about my real problems :)). So I clicked on it and it took me to the Problem Reports and Solutions window! See it below:



When I click on the "Problem fixed in Windows Vista final release" link, it take me to another page that looks like this (screenshot).

On that last screenshot, when I click on "See related problems" it shows me exactly what problem it is talking about, as you can see below:


If I then double-click on the item in the listview it takes me to the bucket/info that was sent up to winqual and thus it closes the loop (screenshot).

Have I told you that I love the new WER architecture more and more every day :)

The problem
When I was trying to call the WerRegisterFile API as described previously, I run into an interesting situation: Calling the API without specifying any CharSet should have attempted first the WerRegisterFile. If I specify CharSet.Auto, it should first attempt WerRegisterFileW and if it cannot find that then go back to try WerRegisterFile. Either way, you would have thought that this would succeed or blow. As it turns out, leaving the CharSet off, silently fails (no exception, return value is 0, Marshal.GetLastWin32Error is 0 etc) but specifying CharSet.Auto works as expected! For the record, CharSet.Unicode behaves like CharSet.Auto and CharSet.Ansi fails like when we omit altogether CharSet from the DllImport declaration.

Download a repro VS2005 project here (obviously requires Vista).


Solution
Looking at kernel32.dll (which exports this function) shows that there is only one entry for the API (screenshot of dumpbin). This seems to be a pattern with Vista, according to my colleague MikeT.

Well it seems that after a series of chats with Mike, he updated his post with useful thoughts. Read his 4th thought in the updated section and come back... I’ll wait...

[...time passes...]

So to prove the thought, I looked at another Vista API that takes strings: RegisterApplicationRestart. It too has no trailing A or W (screenshot). So calling this API without CharSet also gives no errors, but the string you get passed back to the application at the command line is definitely not the one I passed to it (something Chinese-looking on my system when I gave it something English).

That rests the case. I should have realised earlier that CharSet is not just about finding the correct entry point but also about how the string will be marshalled.

As an excuse I should state that, having mostly coded for WinCE, I think I have been spoilt since that is all Unicode and I can’t remember using CharSet with any of NETCF pinvokes and they all worked fine :)

Final thoughts
1. Whoever thought the default of CharSet should be Ansi has a lot to answer for. Note that it is a C# decision as the CLR defaults to Auto!
2. I wonder if the Vista change (that threw me off track) is going to bite others or if it just muppets like me that fell for it :S
3. Why is WerRegiserFile in kernel32.dll when all the other WER APIs are in wer.dll?!
4. WerRegisterFile should be giving some indication to the developer that it failed. At the end of the day, you give it a path (string), it thinks it is a different string (path), so it cannot find the file and then it silently fails! WTF?
5. I detest silent failures. Make an explosion next time. A big loud one or a quiet one, but not a silent one. Silent ones are the worst!

Eric Wroolie wrote (what I think is) a nice review of my event from a couple of days ago and has some interesting thoughts on attending webcasts versus attending live events. I strongly encourage you to go read and share your own thoughts there.

Having read that, you should now be inspired to attend a live event so if you can make it to London on October 18th, head over to the London Dot Net User Group where Ian is preparing a nice line-up and it is all for free! (full details available over the next few days)

If that is too soon for you, definitely plan to make it for DDD4 that is also free. Even better, you can shape the day by voting now for the sessions you'd like to see! How cool is that? :)

This post just serves as a background URL that I can link to from my next post later :)

We all know that to call unmanaged code from managed code you have to pinvoke (i.e. use the DllImport attribute). One of the enumerations that becomes relevant when calling native methods that accept strings is CharSet.

It is also relevant for native structures with strings but I am explicitly ignoring that in this post. I am also ignoring the CharSet.None enumeration as it means the same as CharSet.Ansi and is there for C++ legacy reasons, I think.

CharSet is useful so you can instruct the runtime to invoke the "A" version of an API or the "W" version (Ansi or Unicode) e.g. MessageBoxA or MessageBoxW. If you select CharSet.Ansi the CLR attempts to invoke an entry point with an appended "A" if the entry point specified by the signature doesn't exist. If you select Auto, then on modern OSs it will default to Unicode. This means the CLR will attempt to invoke an entry point with an appended "W" before attempting to invoke the entry point specified by the signature. If you miss the CharSet from your DllImport declaration, the default is Ansi with the behaviour described above.