The Moth

If you missed my session at MEDC, I'll be doing a repeat online for the Windows Virtual Mobile Group next Wednesday 20th September (12:00AM Eastern Time, 17:00 GMT)

Register Now!

I’ll be assuming knowledge of device development of course so if you are a desktop developer, get started ;-)

http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-GB&eventid=1032306822

Wow, 150 minutes of Vista for developers and without talking about NetFx3 or C++ at all! How am I supposed to fill that time with quality content? Come find out what others are not telling you in Edinburgh on Wednesday 20th September (repeated in Reading on 3rd October). Register now!

A few of us are having drinks/food the night before; if you fancy that too, drop me a line.

For me, one of the four drawbacks of working for Microsoft (I’ll write about the other 3 some other time) is that I cannot submit a session for the Developer Day here in the UK. Hopefully you can though so go submit a proposal there now!

I’d like to see a session linking UML activity & state diagrams with WF – I don’t think anyone has picked up on their similarity yet.

No, it is not out for public consumption yet (although it is running here on my laptop). I was going to write an explanation to address the WMDC confusion... but Mel beat me to it here.

Windows Vista goes to Swindon next Wednesday so, if you are in the vicinity, make sure you sing up here!

Title: Windows Vista - Beyond NetFx3 with Daniel Moth
Date: Wednesday 13 September 2006
Overview: This session will start with a quick tour of the new operating system, describe the new APIs available and demo how to take advantage of some of them in Visual Studio 2005 (including the aero guidelines, glass, taskdialog, UAC, RSS, and sidebar gadgets).
Venue: Nationwide Building Society, Nationwide House, Pipers Way, Swindon, SN38 1NW
Times: 18:30 - 21:00(19:00 start)
Registration Details: emma@vbug.com OR call 01753 649687

This is a longer session than what I do for the roadshow (and I am preparing for it right now). It will be slightly different than the one I did in Newcastle (for one, we will be running Vista RC1).

The following day, on the Thursday, I have a press event on Windows Vista and NetFx3 in London and then on the Friday I'll visit my former colleagues at Trend in Horsham to give an overview of what's coming on the Microsoft platform. While you cannot subscribe for these two latter events, I still have to prep for them which might help explain any potential slowdown in my communications… :-)

Three weeks ago I wrote a short overview article of Windows Feedback Platform (WFP), the evolution of Windows Error Reporting (WER). Those of you who are subscribed to the msdn flash newsletter will have (hopefully) read it already (published 17th August). Its title: "Code quality, customer feedback and application reliability with Windows Vista".

If you want to read an online version of it (or wish to subscribe to the essential msdn flash) please go here where we store the archives.

In the article, I mention the Application Recovery APIs that I covered on my blog: RegisterApplicationRestart and RegisterApplicationRecoveryCallback.

If you've read those posts, you may wish to demo the APIs without having to explain WER and the dialogs that get thrown (I was in such a situation recently). One thing we can do is turn off WER for your sample demo application. To do that we need to wrap WerAddExcludedApplication like this:
[DllImport("wer.dll")]
internal static extern uint WerAddExcludedApplication(string pwzExeName, bool bAllUsers);

...and then call it like this:
WerAddExcludedApplication(AppDomain.CurrentDomain.FriendlyName, false);

Of course, if you do leave WER enabled, remember to show that with Windows Vista it now works even for hangs (not just for crashes) :-)

In the office today I was reading a popular PC magasine here in the UK and in the contents it said Dave (sorry I forget surname) looks at User Account Control in Windows Vista. I went to the page and read the article that left me quite disappointed. First, it doesn't really explain the goals behind UAC and how UAC achieves that: this information is available online (two clicks from my blog entry on User Account Control). Second, over half of the article is basically what seems to me a rant on the 'virtualization' feature (again, I cover virtualization on my UAC post). While I advise devs not to take advantage of virtualisation, I understand its purpose in offering crutches to some legacy applications that would otherwise break. In any case, the most disappointing thing about the article was that it didn't even mention how to turn off virtualization. While I did this at the nugget I link to from here, let's repeat it in written form.

1. In your Windows start menu go to the search box and type "sec" to bring up the "Local Security Policy"
2. Navigate to 'Security Settings->Local Policies->Security Options' and scroll to the bottom.
3. There you'll find 9 policies pertaining to User Account Control. Double click on the last one ("Virtualize file and registry write failures to per-user locations")
4. Change the value from Enabled to Disabled

With Vista RC1 there is an improvement to the dialogs that come up for each policy. There is an additional tab: "Explain". Click on this one to read about what the policy does :-) For the policy we've been talking about it looks like this:



I leave it to you to read the explanations for the other 8 policies:
- Switch to the secure desktop when prompting for elevation
- Run all users, including administrators, as standard users
- Only elevate UIAccess applications that are installed in secure locations
- Only elevate executables that are signed and validated
- Detect application installations and prompt for elevation
- Behavior of the elevation prompt for standard users
- Behavior of the elevation prompt for administrators in Admin Approval Mode
- Admin Approval Mode for the Built-in Administrator account

BTW, with RC1 (build 5600), the number of UAC prompts you get is significantly smaller than earlier builds so go check it out!

Last weekend we went to Amsterdam with my mates for stag do and yesterday I married Jenny at Brighton Town Tall (there will be a proper religious wedding in Greece next year).

So in a couple of hours we are flying to Malta for our first honeymoon (and some diving of course :-))

Normal service will resume on Monday 4th September – don’t call me, I’ll call you!

We looked previously at RegisterApplicationRestart and that blog entry serves as the introduction to the Application Recovery APIs in Vista so I suggest you read that before continuing below.

To demo this, we'll start with the code we've already created.
f) For both samples, let's offer an additional user option for hanging the application. We can do this via a dedicated button like this:

    // hang
    private void button3_Click(object sender, EventArgs e)
    {
      while (true) { }
    }

g) Our pinvoke wrappers cover 3 functions RegisterApplicationRecoveryCallback, ApplicationRecoveryInProgress, ApplicationRecoveryFinished and a helper delegate as shown here:

    [DllImport("kernel32.dll")]
    static extern uint RegisterApplicationRecoveryCallback(IntPtr pRecoveryCallback, IntPtr pvParameter, int dwPingInterval, int dwFlags);
   
    [DllImport("kernel32.dll")]
    static extern uint ApplicationRecoveryInProgress(out bool pbCancelled);

    [DllImport("kernel32.dll")]
    static extern uint ApplicationRecoveryFinished(bool bSuccess);

    delegate int ApplicationRecoveryCallback(IntPtr pvParameter);

Taking advantage of the APIs involves two functions:
h) First, we register our interest to be called back, by passing in the method that must be called:

    private ApplicationRecoveryCallback mCallback;

    // recover
    private void button4_Click(object sender, EventArgs e)
    {
      mCallback = new ApplicationRecoveryCallback(this.RecoverIt);

      IntPtr del = Marshal.GetFunctionPointerForDelegate(mCallback);

      RegisterApplicationRecoveryCallback(del, IntPtr.Zero, 5000, 1  4);
    }

i) Second, we need to write a method that will run our recovery code (I also used a helper method for code clarity):

    private int RecoverIt(IntPtr pvParameter)
    {
      // just an action that proves this runs
      File.Create(Environment.CurrentDirectory + @"\recover.txt").Close();

      int i = 4; //random number to simulate delay
      while (i != 0)
      {
        bool b = this.Ping();
        if (b) return 0;
        Thread.Sleep(3000); //simulates some recovery action
        i--;
      }

      ApplicationRecoveryFinished(true);
      return 0;
    }

    private bool Ping()
    {
      bool esc;
      ApplicationRecoveryInProgress(out esc);
      if (esc)
      {
        MessageBox.Show("Cancelled");
      }
      return esc;
    }

That's all there is to it. Now run your app, and after you have called RegisterApplicationRecoveryCallback, wait for 60 seconds before crashing/hanging the app via the appropriate button. Note how at that instance, in your application's folder an empty file is created (this is proof that your recovery method run).

The other relevant recovery functions that you could pinvoke are UnregisterApplicationRecoveryCallback and GetApplicationRecoveryCallback.
Incidentally, these restart and recovery APIs is what the new Restart Manager is based on.

...has my screencast on glass summarising my blog posts on the topic that regular readers will be familiar with. Go watch it!

...and this, this, this and that.