Edge JsRT: Object Before Collection Callbacks

There are a number of new features in the Edge version of JsRT, and since I haven’t seen anything discussing them on the web, I thought I’d walk through them.

The first one I thought I’d discuss is object before collection callbacks. In the first version of JsRT, you could create an “external” object that could have a callback that would be called when the object was finalized. But this only allowed you to know about objects that you create. What if you need to know when an object that you’ve attached some special significance to is collected? Now you can call JsSetObjectBeforeCollectCallback, provide it the reference to track, some state, and a callback function. When the GC is going to collect the object, you’ll get a callback to let you know.

Useful for managing lifetime of native objects that track some JS object!

You should also follow me on Twitter here.

The Two Faces of JsRT (in Windows 10)

In terms of Windows 10, probably the biggest thing to happen to the JsRT APIs in Windows was the IE/Edge browser split.

For anyone who’s been living under a rock, Microsoft introduced a new browser in Windows 10 called Edge (neé Project Spartan). Edge basically represents a fork in the road for the web browser codebase at Microsoft: down one path the IE code will continue on, largely unchanged and preserving all that crufty backwards compatibility we all love to hate, and down another path will go Edge, discarding all the legacy shackles of IE and committing to a thoroughly modern browser experience.

And, just as the browser now splits into IE and Edge, so does the underlying JavaScript engine, Chakra. There are now two (yes, two!) JsRT APIs:

  • The “legacy” JsRT APIs that are exposed by jscript9.dll (the one that IE uses), have not changed since Windows 8.1, and will not be added to.
  • The “Edge” JsRT APIs that are exposed by chakra.dll (the one that Edge uses), have some breaking changes since Windows 8.1, and will be updated as the Edge browser moves forward.

You can find more details on the breaking changes that were made to the Edge JsRT on MSDN, but in a nutshell they are:

  • In C++ you #define USE_EDGEMODE_JSRT before including jsrt.h, and you link against chakrart.lib instead of jsrt.lib.
  • In C# and VB, you target your PInvoke declarations at chakra.dll instead of jscript9.dll.
  • The “version” parameter of JsCreateRuntime disappears (since there will only ever be one evergreen version of the Edge Chakra).
  • The debugging no longer requires an IDebugApplication. Thus, JsStartDebugging and JsCreateContext lose a parameter.

The last bullet point may seem a little odd and arbitrary. The reason is that the Edge version of the JsRT API is now supported as a part of the UWP (Universal Windows Platform). That means that a “modern” UWP application can host the Edge Chakra runtime and still qualify for the Windows Store (i.e. it won’t be rejected for using non-UWP APIs). To get there, though, the Chakra team needed to remove things that don’t work on the UWP, namely talking to the PDM (Process Debug Manager), which is what you need to get an IDebugApplication. Since it turns out in almost every possible case you don’t need to be able to supply your own IDebugApplication, Chakra now just acquires one on your behalf.

I’ve updated my chakra-host sample on GitHub to include samples that show hosting both “legacy” and “edge” JsRT on Windows 10. I’ve also added a new sample to the Windows Samples showing this. The Chakra team also now has a GitHub repo where they host their own samples.

You should also follow me on Twitter here.

Running node.js on Chakra!

It’s been a very busy year since I last posted, and a lot has been happening. As a result, I’ve kind of fallen behind a bit on all the stuff that came out around the Windows 10 launch. And one of the biggest things that I missed blogging about was the revelation of a (temporary) fork of node.js that runs Node on Chakra instead of V8!

This was actually the culmination of some work that I started several years ago as an internal project to enable some teams at Microsoft to author node.js applications that ran on Chakra instead of V8. The problem, then as now, was that there were some platforms where V8 didn’t or couldn’t run. So I spent a fun month or so working with another team concocting a shim over the nascent JSRT APIs that made them look a lot like the V8 APIs. The end result was a node.js binary that used Chakra and ran all the stuff that the team I was working with needed. Then the code went sort of into hibernation, and when I left the Chakra team, my expectation was that nothing more would come of it.

But, lo and behold, the IoT folks wanted node.js and they wanted it on ARM, which V8 doesn’t have an official code generator for, so that code miraculously got a second chance at life! After a lot of extra work on the part of the Chakra team (since the original shim only covered the scenarios the internal team needed), it was polished up and is now running out in the wild. It’s great to see that work continuing, especially since node.js can really be a joy to program in. Combining node.js with the ability of Chakra to access UWP (Universal Windows Platform) APIs also opens intriguing possibilities.

I’ve been thinking that I wanted to clone the fork to see if there was anything I could contribute, but things have been just too busy. Soon, maybe!

You should also follow me on Twitter here.

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.