Design problem in wrapping Windows's Window API

I'm writing an object-oriented window API wrapper for Windows in D, and I'm having a (non-language-specific) design problem.

Windows requires that all windows be previously registered with RegisterClass; extending an existing class requires replacing the window procedure. Furthermore, there seem to be two kinds of window handles: HWNDs that need to be disposed (via DestroyWindow), and HWNDs that don't (e.g. from other applications).

I have created a Window class, and so long as I'm just wrapping the ShowWindow, UpdateWindow, FindWindow, and other such methods, everything is fine and dandy. But as soon as I try to add a constructor with a className parameter to my class that calls CreateWindow, I run across a problem:

1. The given className must already have been registered by RegisterClass.
2. In order to register a new window class, I would need to make my subclasses of Window to somehow call RegisterClass before trying to create a new Window, either directly or indirectly.
3. In order for my design (and inheritance) to make sense, i would need to make sure that, for any given subclass of Window, all instances are actually instances of the same window class; namely, that all classNames from a particular subclass are identical. (This is because the window procedures for all instances of a particular window class need to be the same.)

The problem is, there's no way to have an abstract static method (in order for Window to be able to ask the subclasses for their class info, and to register them once), and so I am forced to say something like CreateWindow(this.className, ...) in order to create a new window, which easily becomes problematic if my subclasses don't respect this rule, and give me a different class name per instance of the window.

Furthermore, I need a one-to-one mapping between the WNDCLASS.lpfnWndProc field and my Window subclass's (overridden) WndProc method. This doesn't exactly work, though, if I'm forced to get the method pointer on a per-instance basis, since it breaks the entire OOP design and messes everything up.

While it's possible for me to enforce this consistency at run-time, it's a bit ugly, and so it's not a great solution.

So, long story short, does anyone have any idea of an elegant solution to the problem of creating an abstract static method? I'm thinking of some design patterns like Factory and whatnot, but I'm not sure if they fit here... if someone thinks they might , I would really appreciate a little explanation on how it would fit into the design.

Thank you!

Wow, I certainly didn't expect this...

I searched for the phrase x86 thunks on Google. And, as it turns out, I wasn't the first person to come across this problem (surprise!).

The first hit was the exact problem and the solution to this question about Window Procs, even though it had nothing to do with my query (or at least, very little to do directly)... hope someone else finds it useful too.