Fixing JavaScript

by Matt 13. June 2007 15:48

Looks like Microsoft are actually working on a fix for the circular reference memory leak in their JavaScript implementation. About time, perhaps, but I'd love to know the techy details. How do they get their JavaScript garbage collector to know what references (direct or indirect) an unknown COM object holds?

Is there going to be a separate interface that lists references? This would have to be implemented on the HTML element objects, and so would fail with ActiveX COM objects.

Perhaps the GC lists all properties of a (non-JavaScript) expando object and examines them for a known interface to indicate a JavaScript object. This would allow it to know when a circular reference was made, but it wouldn't identify if the original non-JavaScript object was referenced outside of the script engine.

It's an interesting problem.

But there goes my theory about them using the new managed JavaScript from Silverlight...


COM interface types. A quick glossary

by Matt 13. June 2007 06:24

Right. Let's brush away some cobwebs, and write this down so I don't have to google all over the web whenever I need a quick COM 101 refresher:

  • A custom or vtable interface is a COM interface that derives from IUnkown. It only supports early binding through the compiler's vtable.
  • A dispinterface is a purely IDispatch based interface. The methods defined in the IDL file are only callable via IDispatch::Invoke, and not via a vtable. These are usually used as event interfaces (i.e. you implement the interface on your object and pass it to another object that you want to receive events from). Knowing this explains why it's not a cardinal COM sin that Microsoft have been expanding DWebBrowserEvents2 for each release of Internet Explorer.
  • A dual interface is a COM interface that derives from both IUnknown and IDispatch - it's both a vtable interface and a dispinterface.
  • Expando objects implement IDispatchEx and allow you to add methods and properties at runtime. This is how JavaScript, VBScript and Internet Explorer allow you to expand script and HTML objects.

A type library can be used to store interface information. It can contain vtable layouts and the DispId's required to call IDispatch based interfaces.

You can implement IDispatch by hand, with a huge switch statement, if you want to, but remember that you'll need to crack the parameters out of arrays and stuff them back in again for the return value. 

Alternatively, you can let someone else do the heavy lifting for you and use an implementation of IDispatch which is based on a type library. (And seeing how one of the methods of IDispatch is to get a pointer to an ITypeInfo interface representing a type library - you might as well). This works by calling LoadTypeLib to get an instance of ITypeLib, then calling ITypeLib::GetTypeInfoOfGuid. The resulting ITypeInfo can be used to defer the interesting IDispatch methods (including Invoke). This is what ATL's IDispatchImpl does. It's interesting to note that the Invoke method will call vtable based methods on your interface. This is pretty good voodoo.

As far as I can make out, you could also use CreateStdDispatch to create an IDispatch interface for you, which essentially does the same thing as IDispatchImpl. Or, you can implement bits of IDispatch yourself and defer to methods such as DispInvoke and DispGetIDsOfNames.

If you want to support dispinterfaces, you can use ATL's IDispEventImpl. This is an implementation of IDispatch that doesn't require an implementation of each member on the dispinterface. It does this by using a map that routes DispId's to functions - ideal for an interface that doesn't actually have a vtable. You could even use IDispEventSimpleImpl if you didn't want to use a typelib.

Sheesh. It's nice that .net moves well away from all of this malarky, but it's still something that you need to know from time to time...


Customer Debug Probes == Managed Debug Assistants

by Matt 8. June 2007 10:52

In the hopes that I can save someone wasting quite as much time as I just have on this - Customer Debug Probes have changed name and become Managed Debug Assistants. (Google doesn't appear to have joined the dots on these two, so let's hope this helps).

They're exactly the same concept, but have had a bit of an overhaul, including a new name and naturally enough, a completely different way of enabling them. This MSDN page details how to enable and configure them (individually, and in an application.mda.config file).

These are debugger messages, so you have to be in a debugger to view them. One gotcha is that the application.mda.config file doesn't work when in Visual Studio. Instead, you need to go to the Debug menu -> Exceptions window and you can enable and disable the assistants there. In use, they interrupt your running as though an exception were thrown.

This has been a public service announcement on behalf of those struggling with COM interop.


Vista preview handlers

by Matt 5. June 2007 17:07

Here's a right little collection of links for you. I should really put them on my list of Programs What I Run.

Anyway. Vista's got this nice preview pane that allows you to see, well, a preview of a selected file. Handy. Naturally enough, not all of your favourite file types are going to be supported out of the box, so here's a list of shell extensions to add that special magic.

Right. I feel a bullet list coming on.

But first things first. There is an MSDN article that showed how to build these extensions in managed code (which is allowed, because they run out of process. Don't run .net shell extensions in-process.) It adds a whole heap of previewers, but since it comes from a developer centric article, it's not exactly user friendly in terms of either installing or documentation. So, download the file, double click to extract it, go into the Installer directory and read the README.txt.

Now, you should have a previewer for:

  • .bin and .dat files, treated as binary files
  • .csv files displayed in a DataGridView
  • .isf files, which appear to be ink files from table pc's
  • .msi installer files displaying a list of all the files that might be installed
  • .resources files (used to hold strings and images during .net compilation)
  • .resx files (an xml based file that becomes a .resources file)
  • .snk and .keys files, again used by .net compilation to provide a strong name to an assembly.
  • .zip and .gadget. A rather lovely idea - displays a tree view of all the files in a zip based file. Gadget files are also zip files, so are also handled. You could take this further and register it as the previewer for .xpi (Firefox extensions), .jar files, and even .docx (although you might want to keep that one for the proper Word preview handler)
  • .pdf, via the Adobe Acrobat ActiveX control
  • .xaml!
  • Finally, there's an Internet Explorer preview handler. This is rather nifty and just displays the file in an IE control. It's registered for xml files (via the "xmlfile" registry key, not .xml. This means it gets anything that identifies itself as a .xml file, such as .rels). It's also registered for .config and an unknown .psq file type (which this link identifies as a "Product Studio Query File" and this link identifies "Product Studio" as a bug tracker within Microsoft). It also handles .xps files, because IE is the default xps viewer.

Now, a bunch of those preview handlers could handle other file types. The IE handler could display, oh, I don't know, html files? The MSDN article does have a sidebar on how to register other file types with existing extensions, but if that's too much of a drag, you can try this association editor.

And that's all from the same guy. What can anyone else add?

Oh, and these all work in Office 2007 on Vista, too. But not XP. Fortunately, someone has done all the dirty work of back-porting support for Office 2007 on XP. This package also includes most of the preview handlers already mentioned, but with a few more file types registered, such as .html, .htm, etc.


Vista | Shell Extensions | Preview Handlers

Programmatic access to UAC. Kinda.

by Matt 5. June 2007 05:28

I kinda like this web site. It offers a C++ source file with various functions to help in install time situations; functions like IsVista() and IsWow64(). And it also gives some functions to deal with User Account Control. GetElevationType(), IsElevated() and RunElevated() are going to be very useful.

The killer function, though is RunNonElevated(). This is a doozy.

Picture this - I run my installer. It needs to write to C:\Program Files, so gets elevated. Trying to be as nice as I can to my user, I offer them a chance to run my program at the end of the installer, as is common. Unfortunately, since the installer is now running elevated, my newly installed program will run elevated, which is not what I want.

So this function could be very useful. The downside is that Microsoft haven't actually provided any means of running a program non-elevated, so this function has to hack around it by injecting itself into the shell, which it knows is not elevated and getting explorer to spawn the process.

Is it just mean that sees the irony in having to inject code into one process to run another process securely?



Using C# 3.0 from .NET 2.0

by Matt 4. June 2007 18:32

I'm looking forward to Orcas. It's a (mostly) additive release, similar to 3.0. The CLR itself doesn't really change (there is a service pack level update, but you're essentially still running v2). There are updates to the compilers, the IDE and new libraries that add to .net 2 and .net 3.0 (such as System.Core.dll).

One of the nice things Orcas allows is "multitargeting", where you can target different versions of the framework (2.0, 3.0 or 3.5). Of course, if you're targeting a down-level version, you'll lose support of that framework version's assemblies (e.g. no WPF apps in a 2.0 targeted application). What might not be obvious is that the compiler still supports the 3.5 features, including the nice LINQ "select ... from ... where" syntax (although there's a caveat around that one).

Thanks to Daniel Moth for all this info!


.net tools

Amazon's SQS service

by Matt 4. June 2007 05:57

Wow. I've only just realised how impressive Amazon's web services are. I've always liked their Simple Storage Service (S3), but well, that's just data storage - it's not terribly exciting (although I keep meaning to look into the opportunities for backup-to-the-cloud).

Today I stumbled across their hosted message queue service. This is all a bit more, well, enterprise-y. It's a B2B type solution, and normally, if you needed a message queue in your enterprise architecture, you'd host it yourself. Now you don't have to. Instead, you can pay Amazon to do it - per message, per amount of data in and per amount of data out.

And on top of this, Amazon have released a WCF transport for it, making it nice and easy to use from your favourite Microsoft messaging library. (Although looking at it, it's a community sample, albeit one provided by the Amazon team - the download is hosted on Microsoft's .net 3 sandbox site.)

Microsoft have recently dipped their toes in this area, too, with the release of a CTP version of their BizTalk Services (of course, Amazon's queue is already released). Microsoft's offering is perhaps broader in scope (as always), including identity federation (via the marvelous CardSpace) and a service relay, which is, at a squint, the closest match to Amazon's queue, although it's most definitely not a queue. It looks like Workflow hosting will come soon, too, which will be one to watch.

These are interesting moves, pulling key enterprise architecture out to hosted providers. I wonder where this will go, and who will use it? And I wonder if the people who do use these types of queues will still have queues at their end of the wire?


Snooping WPF applications

by Matt 29. May 2007 17:42

Rob Relyea has just posted a couple of links to WPF utilities to check out.

Firstly, there's a debugger visualiser for the element tree. Haven't tried it yet, but I do like the idea of these kind of visualisations.

The one I did try was Snoop, which is a very impressive tool to interrogate the visual tree of a running application, and display the tree, plus properties and events. Dead useful - think Spy++ for the 21st century. It's a little intrusive (it injects itself into the application being viewed), but I can live with that.

And that took me on a nice little stroll to see how WPF draws the navigation UI for the Frame class. Starting with this incredibly in-depth article (far too good to be simply a blog post) from the always brilliant Ian Griffiths on how WPF defines the default Template for a control, which then took me to the BAML decoder plugin for Reflector, which showed me the XAML for the resources in PresentationFramework.Aero.dll, which opened my eyes to the very nifty way that WPF handles resources and Templates and how a control's visuals can be made up with other controls. I like this WPF thing.


EV cert support for Firefox

by Matt 29. May 2007 04:10

IE7 introduced support for Extended Validation SSL certificates (aka High Assurance certificates). Any time you hit a site with one of these certs, the address bar changes colour to green. I've previously posted links to a couple of sites Microsoft host that allows you to test this.

While scouring the net looking for ways of integrating this into a project that hosts IE's web browser, I came across this article on Wikipedia, which contained this link to a plugin to enable the nice green address bar in Firefox. And it's written by VeriSign, which is nice of them (considering other CA's certs are going to be in competition with them).

Unfortunately, its support is not as complete as IE7. Currently, it only knows about EV certs from VeriSign, Thawte and GeoTrust. (Wikipedia lists 7 other CA's that support EV.) But it's a good start.

And if you're interested in how EV certs are implemented, just download the Firefox .xpi file and change the extension to .zip. You can see it's got a certs folder, containing various new root certs for the CAs. I don't pretend to know why they need new root certs, or why the old ones can't be used. The chrome folder has a .jar file, which can again be renamed to .zip and extracted. This contains a bunch of css files, some images and some Javascript.

evcextension.js is the file with all the goodies. And it's here where you can really see how messy the EV implementation is. Each CA has their own OID that marks a cert as being EV. (OID is an object identifier. Think of it as the way a cert identifies each of it's properties.) And since each CA has their own, they're all different. So, the process is to walk the certificate chain. If the certificate contains one of the recognised OIDs, the hash of the chained root cert must match the expected hash of the OID matching CA's root cert.

Fairly simple process, but messy - the addin must know about all CAs, all of their root certs and the OID they choose to identify their version of EV. (And there are other parts to implement too, such as changes to the revocation list checking.) So any change to a CA root cert, or adding new, known CA's requires an update to the addin.

The above linked Wikipedia article lists 10 CA's. Theoretically, it should be easy to add support for all of them. Just add the OID's and the matching root certs. Of course, finding all the root certs might be a bit tricky, especially when there looks like there are new ones that need to be downloaded and installed. I wouldn't like to mess here - just leave it to the people who know about this stuff.

Of course, the nice test site run by Microsoft doesn't work because the Firefox addin doesn't know about Microsoft's test root cert. That is something that I wouldn't mind hacking.

So, now we know how to support EV certs. We've got to do a lot of leg work and find out all the CA's that support it, what their OID's are and what their root certs are. If any of them change, we won't get notified. If we do find out they've changed, it's an update to our implementation (and we'd have to be careful about putting that data in config - we don't want it hacked so that any cert can be labeled EV).

Wouldn't it be nice if Internet Explorer exposed its implementation for the rest of us to hook into, especially when hosting the WebBrowser control?


The Dynamic Language Runtime

by Matt 28. May 2007 18:06

How cool is the DLR? Go and read that link; read the code and understand what it does. I'll be here with a paracetamol and a cup of sweet tea. Seriously fruity, isn't it?

Yep, that's the Dynamic Language Runtime announced at Mix 07. (We've already covered that I'm late with the Mix analysis. Get over it.) I like this. A lot. It's perhaps a shame then that I don't actually get dynamic languages (or perhaps - get the need for dynamic languages). But that's another post.

This eweek article is a good introduction, but briefly, consider this a set of BCL extensions to simplify lightweight dynamic code generation and dynamic dispatch - true late binding languages.

We're getting a few new languages out of this. IronPython's been the driving force behind all of this, and 2.0 now uses it. IronRuby is coming. The current plan for Visual Basic is to use it for VBx (VB 10). (That's a big statement, so also read the announcement from the VB team and this post clarifying future plans.) This can only be a good thing. I think we need a bit more diversity between VB and C#. More interestingly, there's also a DLR version of Javascript in the pipeline (this isn't, just to confuse things - oh, and it's implemented in Visual Basic to boot).

(And doesn't that just make you wonder if the IE team are going to pick up managed Javascript to replace the aging ActiveScript based implementation? It's slow and prone to circular memory leaks, and .net has garbage collection and a 1000x performance increase. Yeah. 1000x.)

Did I mention it was available on Codeplex? It's currently a part of IronPython, which is some flavour of open source. This means Mono can just use it, legally. And in just 16 days, technically.

Speaking of Mono, Miguel de Icaza has had a run of blog posts about a compiler workshop Microsoft has been running on the DLR (yeah, that's the Mono guys working with the Microsoft guys. You know, cats and dogs, living together, that kind of thing). And he's looking at a Linux version of Silverlight, currently codenamed Moonlight. (Mono is an interesting project. I like the idea of .net on Linux and Mac et al, but it just makes me feel sorry for them that they have to constantly chase Microsoft's libraries - WCF, WPF, Silverlight, etc.)

But surely the most intriguing part of the DLR is the delivery mechanism. Why Silverlight? This library has the potential to have a huge impact on the ecosystem of .net. If Microsoft get it right, it's going to open the runtime up to a whole heap of developers who wouldn't otherwise have gone near .net.

And it's being delivered as a browser plugin.

Now, it does have a hosting model so that it can be integrated with the desktop CLR, but it's a bit of a surprise that this isn't being packaged in with .net 3.5. Perhaps it's just a question of timing? Is it too late in the day, and the DLR too immature? An alpha technology might very well be a better suited home. Or perhaps it's the cross platform nature of Silverlight; couple this with open-sourced dynamic language support and you've suddenly got a number of things to get the alpha geeks interested.

Either way, Microsoft are moving in some impressively different directions with this. I'm going to keep an eye on this one.



Month List


Comment RSS