The Microsoft implementation of the Java Virtual Machine is something anyone in the industry would have known about. Microsoft produced in the late 90's what was at the time very much the best Java implementation anywhere in the world, along with a superb Java IDE - the product was Microsoft Visual J++.

However, as always (and because they, also as always, wanted developers to have a better experience available on Windows than other platforms) Microsoft included their own extensions to the JVM and to the Java language.

Sun responded to this by a very large lawsuit to prevent Microsoft from preinstalling their VM and to prevent Microsoft from providing any support for Java which gave developers on Windows any kind of edge. The lawsuit was settled in 2004 and one of the results of that settlement was that Microsoft removed their JVM components from Windows entirely. The Microsoft JVM also stopped receiving any updates at all, even for security fixes.

Basically, to all intents and purposes it hasn't existed for the last 7 years. So, any question about it is moot, because it's obsolete - Oracle (who now own Sun) are the only company which makes a JVM for Windows and there's zero value in having it installed because there is basically no useful software written in Java (except perhaps for a small amount of Java which lingers in OpenOffice/LibreOffice - of course, that only uses Java because StarOffice/OpenOffice was funded by Sun largely to spread Java adoption, not because it was fit for purpose).

So basically, the answer to any question which involves the Microsoft JVM even peripherally is "remove it".

An important point about the JVM design is that there were much better abstract virtual machine designs and implementations around *before* Java, too. The only actual innovation in Java was that it was designed primarily to host code downloaded from the web; as such, the one new thing in Java as a design was that the JVM bytecode could be security-verified to ensure that it was safe to run before running it.

Of course, this capability was totally and utterly useless because the Java libraries were so bad (and the early JVM implementations were pretty ropey too) that both Java applets and Java desktop applications were atrociously poor to use compared to native apps on every platform.

So in the end, Java only gained any presence at all in three places; mobile devices, which didn't run the bytecode verifier anyway (instead all the Java mobile platforms, such as Nokia's Symbian, use code signing instead of verification), as a server-side language for bespoke internal applications in large companies (which have no need for a bytecode verifier either), and in the form of GWT as an in-house language at Google which was compiled to Javascript rather than to the JVM. So, *all* the design compromises for static verifiability that made the JVM so weak as a general-purpose VM were a complete waste of time.