Fix Broken Installer

Real quick one.

I'm developing a Windows Installer Package using WiX and naturally I've made a bu-bu that's rendered a product uninstallable - it just wouldn't budge from my installed programs list. Luckily I have managed to remove all trace of this monstrosity using a tool called msizap which is available from Microsoft as part of the Windows SDK.

I just issued the following command from the SDK prompt:


msizap t {78FD3CB6-B722-4124-A06B-A371D8938DE4}


Where the GUID is the product id of the MSI I created.

Phew.

XML Format Function for Vim in Python

Visual Studio has a nice feature that lets you format an XML (or other) document to make it more readable (Edit > Advanced > Format Document). I really like this feature and felt the need to add it (for XML at least) to my text editor of choice, Vim.

Vim lets you define your own functions as follows (note that user functions must start with a capital letter):


function! YourFunction()
" definition of function goes here
endfunction


Which is great, but it does involve learning Vim's scripting language - an activity which is not that high on my list right now. What I discovered is that the default build of Vim includes a Python interpreter which can be invoked on Vim's command line like this:


:py[thon] # python command goes here


With multi-line sessions being initiated with a termination sequence of your choosing:


:py[thon] << ENDPY


Where ENDPY is an example of a termination sequence - it's just a symbol that you enter to tell Vim that you're finished writing your Python script/command so that it can go ahead and execute it - you could use any symbol you like; many examples use EOF.

This multi-line bit is what you need to implement your Vim functions in Python - you create a Vim function wrapper around a block of Python; access to Vim's buffers etc. is provided in the form of a built-in Python module called vim (see here for more info).

Continuing the dummy function definition above:

function! YourFunction()
python << ENDPY
import vim

# definition of function goes here (in Python!)

ENDPY
endfunction

You'd make this declaration in your .vimrc file; to invoke it you'd issue the following to Vim while in normal mode:

:call YourFunction()

That's a bit more typing than you'd expect in Vim; to cut this down you'd map this function call to a command as follows (note that, as for functions, user commands must start with a capital letter):

command! -nargs=0 Yfunc call YourFunction()

So now you need only type the following to call your function:

:Yfunc

This is all well and good, but very abstract; plus it doesn't show you the vim object in action. What prompted all of this in the first place was the need to format XML, so here is my solution, complete with command mapping:

function! PrettyXml()

python << ENDPY

import vim
from xml.dom import minidom

try:
  b = vim.current.buffer
  x = minidom.parseString( '\n'.join( b ) )
  b[:] = None
  for l in x.toprettyxml().split('\n'):
    b.append( str( l ) )
  del b[0] # remove empty first line
  
except Exception as ex:
  print ex

ENDPY

endfunction

command! -nargs=0 Pxml call PrettyXml()

This shows me getting access to the contents of the current buffer - the list-like object vim.current.buffer containing the lines of the buffer; using the Python Standard Library to achieve my goal and finally; updating the contents of the buffer.

This solution is a quick hack and as such has (at least) the following limitations:

• It only deals with the whole buffer; selections are supported by the vim object, but I haven't made use of them
• It only deals with whole XML documents; I haven't tried to support fragments
• It is a bit picky about XML declarations - if you specify UTF-16 but encode with UTF-8 or ASCII, it will barf (just 'cos the Python minidom does) - arguably though, that's a feature.

This is not a very complicated example (and arguably quite a lazy solution) but what it does show is the potential - you can use the whole of the Python Standard Library to manipulate the contents of your buffer - there's nothing to stop you writing a function to tweet the current selection, for instance.

User Impersonation Class

I recently needed to impersonate a different user temporarily in an application. I've wrapped up the logic in the class below, I'll walk through the various features afterwards.

using System;
using System.Security.Principal;
using System.Runtime.InteropServices;
using System.Security.Permissions;
using System.ComponentModel;
using System.Security;

public sealed class UserImpersonator
  : IDisposable
{
  #region fields

  private readonly WindowsImpersonationContext _context;

  private const int LOGON32_LOGON_INTERACTIVE = 2;
  private const int LOGON32_PROVIDER_DEFAULT = 0;

  #endregion

  #region constructor

  [PermissionSet(SecurityAction.Demand, Name="FullTrust")]
  private UserImpersonator(string user, SecureString password, string domain = null)
  {
    if (String.IsNullOrEmpty(user))
      throw new ArgumentException("user cannot be null or empty");

    if (String.IsNullOrEmpty(domain))
      domain = Environment.MachineName;

    if (password == null)
      throw new ArgumentNullException("password");

    IntPtr token = IntPtr.Zero;
    bool loginResult;

    {
      IntPtr pwd = IntPtr.Zero;
      try
      {
        pwd = Marshal.SecureStringToGlobalAllocUnicode(password);

        loginResult = LogonUser(
          user,
          domain,
          pwd,
          LOGON32_LOGON_INTERACTIVE,
          LOGON32_PROVIDER_DEFAULT,
          ref token
        );
      }
      finally
      {
        Marshal.ZeroFreeGlobalAllocUnicode(pwd);
      }
    }

    if (!loginResult)
    {
      int err = Marshal.GetLastWin32Error();
      throw new Win32Exception(err);
    }

    try
    {
      var identity = new WindowsIdentity(token);
      _context = identity.Impersonate();
    }
    finally
    {
      CloseHandle(token);
    }
  }

  #endregion

  #region methods

  public void Dispose()
  {
    _context.Undo();
  }

  public void EndImpersonation()
  {
    Dispose();
  }

  public static UserImpersonator Impersonate(string user, SecureString password, string domain)
  {
    return new UserImpersonator(user, password, domain);
  }

  [DllImport("advapi32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
  private static extern bool LogonUser(
    string user,
    string domain,
    IntPtr password,
    int logonType,
    int logonProvider,
    ref IntPtr token
  );

  [DllImport("kernel32.dll")]
  private static extern bool CloseHandle(IntPtr handle);

  #endregion
}


I have made the constructor private, forcing the use of the factory method Impersonate and hence making it explicit that code running immediately after this call is running under the context of the user being impersonated; also I have implemented IDisposable to allow calling code to employ the using construct, as follows:


string user, domain;
SecureString password;

// initialise credentials

using ( var u = UserImpersonator.Impersonate( user, password, domain ) )
{
  // run code as different user
}

// back to previous user


I have also defined a more semantic EndImpersonation method that simply calls Dispose.

The implementation is quite simple - the credentials passed in are used to obtain an authentication token from Windows (via the LogonUser function exported by advapi32.dll) which is then used to create a System.Security.Principal.WindowsIdentity object which provides the impersonation context. Impersonation continues until Undo is called on the WindowsImpersonationContext object returned by WindowsIdentity.Impersonate - this is done in the Dispose method, linking UserImpersonator disposal to impersonation lifetime. Note: there was no need to implement a finalizer here as when the WindowsImpersonationContext is up for Garbage Collection, it's own finalizer will take care of business.

There are a couple of implementation details that are worth noting:

My declaration of LogonUser includes strings for the username and domain but a pointer (IntPtr) for the password. The reason for this is that I don't want the user's password sitting around in memory, unencrypted, with absolutely no control over when that memory is overwritten.
The SecureString class maintains an automatically encrypted buffer for storing string data, the contents of which can be decrypted and written to unmanaged memory using the Marshal class' SecureStringToGlobalAllocUnicode method for just long enough to make the logon call, before that memory is zeroed out and freed by Marshal.ZeroFreeGlobalAllocUnicode (in a finally clause, to make sure it happens). Notice that I specify CharSet.Unicode in my declaration, but Marshal does provide ANSI equivalents.

I use the SetLastError property of the DllImportAttribute to instruct the marshalling code to allow me to retrieve specific failure information using Marshal.GetLastWin32Error.

I use the PermissionSetAttribute to ensure that any code directly or indirectly calling the UserImpersonator constructor has full trust, as defined by the machine's Code Access Security Policy. The security implications of user impersonation make this a sensible safeguard.

Coprime Test

Two integers are coprime if and only if their highest common factor (HCF) is 1.
To put this another way, for any two integers A and B there is at least one integer n such that

an = A and bn = B
(where a and b are integers)

The highest such integer n for two integers is their HCF; for two coprime integers the highest (indeed only) value of n is 1.
So, a simple test for coprimeness is to see whether or not the HCF of the two candidate values is 1.
The Euclidean Algrithm is an efficient way to arrive at the HCF of two integers. It's based on the idea that the difference of two integers is divisible by their HCF. In other words:

A - B = an - bn = (a - b)n

Since a and b are integers, a - b is also an integer and hence A - B is divisible by n.
Repeatedly replacing the larger of A and B with the magnitude of their difference (we assume we're always dealing with positive integers) will eventually yield zero (when A = B) at which point the remaining non-zero number is the pair's HCF. In algebraic terms:

if A = B then an = bn or a = b

Which is the definition of the HCF.

---

This is a great way of finding the HCF but its efficiency can be improved; repeatedly subtracting B from A until B > A and then switching to subtract A from B is equivalent to taking A mod B and then switching each time, but this second method is more efficient on a machine that supports modular division as a native operation (x86 assembly language's div instruction yields quotient and remainder).
Putting this into code:

typedef unsigned int uint;

uint hcf( uint a, uint b )
{
  while ( a * b )
  {
    if ( a > b )
      a %= b;
    else
      b %= a;
  }

  return ( a > b ) ? a : b;
}

bool coprime( uint a, uint b )
{
  return hcf( a, b ) == 1;
}


Or in Python:

def hcf( n1, n2 ):
  while n1*n2:
    if n1 > n2:
      n1 %= n2
    else:
      n2 %= n1
  return max( n1, n2 )

def coprime( n1, n2 ):
  return hcf( n1, n2 ) == 1


Determining whether two numbers are coprime is important in numerous applications, including cryptography.

---

Update
Here's a recursive one-liner in Python:


hcf = lambda n1, n2: n1 if n2 == 0 else hcf( n2, n1 % n2 )


This looks might look like it relies on n1 > n2 but as a mod b = a when b > a, the function will automatically transpose the parameters if n1 < n2.