I have a class that I put together, loosly based on some Microsoft sample code:
And then I made sure that the com.ms.util.SystemVersionManager class could be found in com\ms\util\ in the same directory as my Java source file (I extracted it from a zip archive that is part of the MS Virtual Machine installation for Win2000). It compiled just fine, and then, just to make sure I knew what JVM I am calling when I run "java" from the command line, I did this:
And then I ran my code. Now I was expecting errors galore, as it would be highly unusual for the BEA JVM to mimic very closely the MS VM. But what I actually got was wholly unexpected. The code ran in the native MS VM! Output:
Some other relevant info:
No CLASSPATH is set.
So, what the heck just happened? PCS [ November 20, 2002: Message edited by: Philip Shanks ]
Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
Joined: Sep 29, 2000
Are you sure that no classpath is set? Open a DOS window and at the prompt type >set then look for the classpath parameter. (or you can use the "echo %classpath%" command) If the code that you executed only uses classes up to the level that MS has loaded it would work correctly.
"JavaRanch, where the deer and the Certified play" - David O'Meara
Joined: Oct 15, 2002
I just confirmed... no %CLASSPATH% environment variable. Somehow, by accessing the com.ms.util.SystemVersionManager, the code winds up executing in the MS VM.
Joined: Nov 22, 2008
I just happened to open the mentionned class in Decafe (Java decompiler). The values are actually hard-coded into the class Hence, I'm pretty convinced you've still be running the same VM as before