Windows, Diagnostics, and Me

Although, as I said before, I can’t talk specifically about what I’m working on in Windows for the time being, there are some general things I can say. The main thing I’m doing right now is some investigations around the diagnostic API surface of Windows. By “diagnostic,” I mean any information that Windows may possess regarding the internal state of the system at any particular moment that might be useful for understanding what’s going on. This is a pretty wide-ranging definition, covering everything from the current state of a thread up to the current state of the operating system itself.

The thing is, Windows contains an enormous amount of information about the state of things at any particular moment, but getting to that information can often be difficult or impossible. For example, a lot of components in Windows expose Event Tracing for Windows (ETW) data which can be used to look at what’s going on inside that component. The problem is that you have to know: a) which of the 100s of components that expose ETW events you should be looking at, b) which events that component surfaces you should be looking at, and c) what they mean. And usually there’s little or no documentation for any of it. In other cases, there isn’t even ETW events available–the data is just locked up in the internals of the system (unless Mark Russinovich has found it, of course).

The question I’m looking at is whether there are things that we could do to make Windows diagnostic information more available to developers (who could then use it to better understand their applications, or to build better tools for developers). I have no answers as of yet and, of course, nothing may come of this, but there you are. If you happen to be a Windows developer and are interested seeing some aspect of Windows diagnostics become more available to you, drop me a line in the contact form, I’d love to hear from you!

You should also follow me on Twitter here.

Restored some old VB parser samples…

It occurred to me the other day that my old VBParser samples for VB 7.1 and VB 8.0 had gotten lost in the ether somewhere along the line and were no longer on my website anywhere. So I dug up the sources and added them to my GitHub profile. I kind of seriously doubt that they’re a lot of use anymore, given that they are at least, what, three versions out of date now? But who knows?

You should also follow me on Twitter here.

NodeRT: Accessing WinRT from Node.js

If you’re using node.js on Windows and are interested in getting easy access to some of the cool WinRT-based APIs in Windows 8.0 and later, you should check out the new NodeRT project on Github. It’s a tool that allows you to automagically generate native node.js modules from WinRT winmd metadata files, making them easily available in node:

Since node.js runs as a regular Win32 application and not a Windows Store application (is that what we’re calling Metro these days?), you won’t be able to get access to Store-only WinRT APIs, but there are still quite a few useful WinRT APIs available to desktop apps.

Pretty awesome, check it out!

You should also follow me on Twitter here.

JsRT: Wrappers updated to v1.1

Even though I may not be working on the Chakra team any more, I’m still doing some noodling on making the hosting APIs easier to use. I’ve got some other interesting things coming soon, but on the way there I made some improvements/fixes to the wrappers that I released a while back.

Changes to v1.1:

  • PDB files are generated along with the LIB, and debug builds are included. All flavors are now packaged together.
  • Header file name is changed to jsrt-wrappers.h to be consistent with the other files.
  • Added equality operators for handles.
  • Added function_base::create which can deduce the strongly typed function wrapper from the function signature.
  • Fixes the handling of optional parameters in functions.
  • Changes the handling of rest parameters to use std::vector rather than a JavaScript array, which is more efficient.
  • Simplified prototype handling.
  • Bug fixes.

Let me know if there are any problems!

You should also follow me on Twitter here.

I Just Did Something I Swore I’d Never, Ever, Ever Do

OK, so I’ve worked at Microsoft… a long time. This summer, it’s going to be twenty two years since I first started full time, and twenty three years since I was an intern. During that time, I’ve worked in a lot of different places in the company. The Developer Division. Office. Developer Division again. A little division that doesn’t exist anymore, the Connected Systems Division. SQL. Developer Division again. And in all of that time, I had one cardinal rule: I was never, ever, ever going to work in Windows. No matter what happened, no matter how desperate I was, I was just never going to take a job anywhere in the Windows organization. No way, no how.

It’s not that I had anything against Windows or the Windows group, it’s just that for most of my tenure here so far, the Windows group has seemed… a little nuts. Not nuts in terms of what they’ve produced (although the whole Longhorn thing, ug), but in terms of how they seemed to work. From the outside, it looked like Windows was always on one kind of death march or another, from Windows 95 all the way through Windows Vista. And as much as I might like the OS, I just never thought that I was hardcore or badass enough to be able to withstand that kind of pressure.

There was also the fact that most of my career has centered around developers in one way or another, and for most of my time at Microsoft, Windows has been content to simply outsource the majority of the developer relationship to the Developer Division. This isn’t shocking or anything–hey, “Developer” is right there in the name!–but it meant that if I wanted to be working on developer-related stuff, there was only one place to be.

By now, I’m sure you’ve guessed where this is heading. After spending two very enjoyable years noodling on JavaScript hosting (and other related stuff) on the Chakra team, I’ve decided to break my longstanding vow and join Windows. Shocking, I know.

I decided to do this for two reasons. The first one is that since Windows Vista the Windows team seems to have adopted a much more sane attitude towards the whole work/life balance, something I got to see up close while working on a component that ships in Windows. They still work hard, don’t get me wrong, just that they no longer employ burly fellows to walk along the hall cracking whips every half hour.

The other reason is that since the Windows 8 cycle, the Windows team has a much more serious attitude towards supporting developers. They’ve even got a whole organization dedicated to it that works closely with the Developer Division and everything! And so when some acquaintances started chatting with me about some of the ideas the developer team in Windows had for future versions of Windows, I got interested. And then did an interview. And then accepted. So now here I am! Most of what I’m going to do isn’t public for the time being, so not a lot to say about that at the moment, but suffice it to say, I think it’s going to be interesting!

You should also follow me on Twitter here.

JsRT: Wrappers for C++

One unfortunate side-effect of the fact that the JsRT API is a flat Win32-style API is that it can be a little… painful to use in C++. Some of the conventions, particularly the use of error code returns everywhere and the use of return parameters, mean that you have to write a lot of boilerplate code. And marshalling values between C++ and JavaScript can be very cumbersome. So with that in mind, I’ve written some sample C++ wrappers that make the process of working with the JsRT APIs a lot nicer in C++.

You can get them from my GitHub account here. For more information, here’s part of the readme, which covers some of the highlights of the wrappers:

A Tour Through the Helpers

Most of the wrappers simply provide a nice object-oriented interface over the JsRT API. For example, creating a runtime and a context works like this:

jsrt::runtime runtime = jsrt::runtime::create();
jsrt::context context = runtime.create_context();

There are, however, a number of special features in the wrappers.

Context scopes

A context scope (jsrt::context::scope) automatically sets the current context when it comes into scope and clears the current context when it goes out of scope. This greatly simplifies working with scopes. For example:

jsrt::runtime runtime = jsrt::runtime::create();
jsrt::context context = runtime.create_context();
{
    jsrt::context::scope scope(context);
    ... work with context ...
}
// Context has automatically been set back to original value.
runtime.dispose();

Pinned references

To keep a reference to a Chakra object alive, it must be visible to the Chakra garbage collector (i.e. on the stack or stored in the garbage collected heap) or it has to be pinned using JsAddRef. The pinned<T> class functions as a smart-pointer template that keeps a reference alive using JsAddRef and JsRelease automatically. For example:

{
    jsrt::pinned<jsrt::object> pinned_obj = jsrt::object::create();
    // Object reference does not have to stay on the stack or in the GC heap
}
// Reference can now be garbage collected

Value translation

Value getter and setter functions can be strongly-typed, allowing automatic marshalling of JavaScript values to C++ values and vice versa. For example:

jsrt::object obj = jsrt::object::create();
obj.set_property(jsrt::property_id::create(L"boolProperty"), true);
bool bool_value = obj.get_property<bool>(jsrt::property_id::create(L"boolProperty"));
obj.set_property(jsrt::property_id::create(L"stringProperty"), L"foo");

The wrappers marshal types in the following way:

  • number values are marshalled to/from double

  • string values are marshalled to/from std::wstring

  • Boolean values are marshalled to/from bool

Strongly-typed arrays

Similarly, arrays can be strongly typed and accessed using numeric indexes:

jsrt::array<double> darray = jsrt::array<double>::create(1);
darray[0] = 10;
darray[1] = 20;

Functions

Perhaps the most useful aspect of the wrappers is the way that JavaScript functions can be wrapped and their arguments and return values marshalled to C++ types, and vice versa. For example:

auto f = (jsrt::function<double, double, double>)jsrt::context::evaluate(
    L"function f(a, b) { return a + b; }; f;");
double a = f(jsrt::context::undefined(), 1, 2);

Native functions can also be wrapped:

double add(const jsrt::call_info &info, double a, double b) { return a + b; }
auto nf = jsrt::function<double, double, double>::create(add);
jsrt::context::global().set_property(jsrt::property_id::create(L"add"), nf);
jsrt::context::run(L"add(1, 2)");

When calling a function wrapper, the first argument to the function call is the this value for the call. Function wrappers can also be bound to a particular value of this. For example:

auto bf = jsrt::bound_function<jsrt::value, double, double, double>::create(
    jsrt::context::undefined(),
    (jsrt::function<double, double, double>)jsrt::context::evaluate(
        L"function f(a, b) { return a + b; }; f;"));
double ba = bf(1, 2);

You should also follow me on Twitter here.

Using Jake with TypeScript

I’ve been playing around a lot lately with TypeScript and node.js, and have been using Jake as my make system. Oddly, I haven’t been able to find any npms that simplify Jake/TypeScript integration (maybe I’m not looking hard enough?), so I wrote a little one of my own, jake-typescript. It exposes two methods:

  • batchFiles takes a list of files and produces a Jake task that compiles each of the files separately (i.e. the default tsc behavior).
  • singleFile takes a list of files and produces a Jake file task that compiles all of the files into a single .js file (i.e. the –out behavior).

There’s also a structure to specify command-line arguments for the compile. It’s my first npm and I’m still getting up to speed on all the various conventions, definitely looking for feedback…

You should also follow me on Twitter here.