Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

Silverlight 4 COM Support and 32/64 bit machines – the C64 Emulator

Pete Brown - 08 December 2009

My primary development machine at home is still (gasp!) running the 32 bit version of Windows 7. I just haven’t gotten around to paving it to upgrade to 64 bit. My other machines, including my presentation laptop, are all running 64 bit.

Prior to PDC, I had made some significant changes to the Silverlight C64 emulator. I added sound, started to add a touch-enabled user interface, fixed up some minor perf issues etc. One of the changes was to enable access to the Windows 7 device API in order to use the accelerometer as a joystick.

Accelerometer as a Joystick – a COM Hack

The idea was to strap the accelerometer to the back of my tablet, and use the touch interface as the button and keyboard. The end result is a pretty expensive 8-bit hand-held game machine :)

// this relies on the .NET accelerometer joystick implementation I wrote
// and the COM component it registers. It also requires that the app have
// the silverlight version of full trust so it can work with COM
public class AccelerometerJoystick : IJoystick
    private dynamic _joystick;

    public void Initialize()
        _joystick = ComAutomationFactory.CreateObject("PeteBrown.AccelerometerJoystick.Joystick");

    public bool IsJoystickPointedNorth
        get { return _joystick.IsJoystickPointedNorth; }

    public bool IsJoystickPointedSouth
        get { return _joystick.IsJoystickPointedSouth; }

    public bool IsJoystickPointedEast
        get { return _joystick.IsJoystickPointedEast; }

    public bool IsJoystickPointedWest
        get { return _joystick.IsJoystickPointedWest; }

Since the canonical Windows 7 demo for the accelerometer is the XNA racing car game, I decided to use Pole Position as my own test case.


I built the accelerometer interface by using a shim DLL I wrote which interfaces with the device API using the Windows API Code Pack and then exposes that info via COM. I did that because the native device API is not exposed via IDispatch (although it appears there may be some COM+ way around that). Silverlight 4 only supports IDispatch-based COM interfaces.

a great idea, FAILed because the kid can't spell "you're"On my main dev machine, I just did a regasm /codebase on the COM dll, and Silverlight was immediately able to use it via the IDispatch support in Silverlight 4. It actually worked really well and had decent performance.

Now I knew this was a colossal hack, and not an approach I would recommend for any real app. After all, you’d have to install and register a separate inproc COM dll with your Silverlight app, something that’s akin to including a custom ActiveX control in your Ajax app. It’s the VB6 days all over again. Naughty developer!

Besides, if you’re going to go through that trouble, just write the app in WPF and get a cleaner end-user install and better developer experience. If you want to light up both on Windows and x-platform, use MEF and/or cross-compilation.

In the course of a different conversation, I mentioned this little hack to Ashish Shetty (one of the Silverlight PMs) and he seemed surprised it worked and worked well. To put it bluntly, this is not a supported scenario.

What the COM API is expected to be used for is out-of-process communication with existing COM Servers installed on the local machine – the “automate Microsoft Excel” scenario. While you could talk to your own custom out-of-process servers, that wasn’t really the intent, as it would require an additional install. Again, if you’re going to go through all that trouble and restrict yourself to the Windows platform anyway, write it in WPF.

64 bit vs. 32 bit

One reason the in-process scenario is not a supported scenario (and I say that without any official statement on the matter – just basing it on reactions from the team) is you’ll get different results on a 64 bit vs. 32 bit system.

So, I was going to demo this cool hack at PDC09, but my demo machine is 64 bit. It simply would not work on the 64 bit machine, and it wasn’t until the day before PDC that I realized the platform bitness was why. It failed when trying to find the inproc server entry in the registry. Now, before you ask, I didn’t check to see if I compiled to 64 bit if that would fix the issue on the 64 bit platform, as I felt that was a completely unsustainable approach.

The Solution: Out-of-Process

If you must create your own shim, you’ll need to do it as an out-of-process COM server (the old ActiveX EXE). But before you go that route, ask yourself if it wouldn’t be better to write this in WPF and just use the full .NET framework rather than involve COM, the registry, the performance hit of an out-of-proc server, and the install issues related to it all.

What’s Next for the C64 Emulator

I have a few things in store for the emulator, but the biggest is opening it up and cross-compiling. When Silverlight 4 is released in 2010, I intend to have a cross-compiled version running on Silverlight 4 and WPF 4, that likely uses MEF to pull in different types of interfaces (like the accelerometer, keyboard-simulated, and on-screen touch joysticks). I don’t intend to push the COM approach on Silverlight any further, as while it was really fun to do, I don’t consider that a best practice. I’ll keep the Silverlight version web-oriented, and add machine access “stuff” to the WPF version.

posted by Pete Brown on Tuesday, December 8, 2009
filed under:        

3 comments for “Silverlight 4 COM Support and 32/64 bit machines – the C64 Emulator”

  1. Tomsays:
    <p>Very interesting post, Pete! Nice to see someone went there. :) When I first saw the announcement about COM support in SL4, and a screenshot of the prompt asking for user permission, my first thought was the "colossal hack" you just described. The "automate Excel" scenario seemed secondary. I find it hard to believe SL team members aren't anticipating both scenarios.</p><p>Why not use WPF instead? Lots of reasons, but one huge one is to deliver an app that runs in the browser, and SL does FAR better there than XBAP.Also, your SL app could be cross-platform but just do more when it's running on Windows.</p><p>For example, consider the SL feature voting page at http://silverlight.uservoice.com/. Most of the top items have a note from Tim Heuer that says "Planned for Silverlight 4", which is awesome. However, entry #15, "Add TWAIN Scanning", is a little different. It says "Planned for Silverlight 4. (COM interop support)".</p><p>Well, the TWAIN API is not COM-based. It predates COM by centuries. And I'm pretty sure MS doesn't ship any COM interface for TWAIN in Windows. (I know of several imaging companies that have made good money because of this.) So is Tim implying that TWAIN is supported via the "unsupported scenario" part of this COM interop feature?</p>
  2. Pete Brownsays:

    I can't speak to TWAIN support. It doesn't predate COM (COM was OLE if you recall) but IIRC TWAIN isn't a COM API. However, it's possible it's being exposed via a COM component somewhere. Worth checking into, as I've been surprised by how many things are accessible that way.

    As to your reasons for not going WPF, please remember that elevated Silverlight apps must run out-of-browser. Agreed on the "light up on Windows" bit. MEF is a great help there.

    The *main* scenario the SL team is tryint to tackle with COM automation in SL4 is the "automate excel" type scenario. I'm sure they've anticipated other scenarios, but it's doubtful we'll see explicit support for them in SL4.

  3. Tomsays:
    <p>Pete, thanks for setting me straight there. I'd missed or forgotten that elevated SL apps must run out-of-browser. That's a REALLY important point! I need to find out more about how out-of-browser SL apps stack up against XBAP/standalone WPF.</p><p>As for TWAIN vs COM age, I was exaggerating a bit :) It seems they're actually pretty close in age, and COM is indeed older if you include OLE. But what I was trying to get at was that TWAIN's API was not COM-based in the beginning, and I can tell you from working with it first hand at the lowest levels that it hasn't changed much since those early days. It's a very... unique API.</p><p>Thinking about this again, there actually is a Microsoft API that (sometimes) wraps TWAIN, with some caveats. It's called WIA. Maybe this is what Tim was referring to, and/or "TWAIN Scanning" was just considered as "Scanning". I'll see if I can find out what the story is here. I'd be pretty shocked if MS had their own COM API for TWAIN kicking around somewhere.</p>

Comment on this Post

Remember me

1 trackback for “Silverlight 4 COM Support and 32/64 bit machines – the C64 Emulator”

  1. uberVU - social commentssays:
    This post was mentioned on Twitter by brian_henderson: . @Pete_Brown: blogged: Silverlight 4 COM Support and 32/64 bit machines - the C64 Emulator: http://bit.ly/8gFBNb #sl4