Gaurav Seth's WebLog

JScript Engine Improvements - IE8 beta.

In this post, I just wanted to lay focus on some of the improvements that have been done in the JScript engine shipped as a part of IE 8 Beta release. These improvements include:

·         Changes to the JScript Garbage Collector to reduce circular memory leaks

·         Optimization of String Concatenation and Other Built-In String Operations

·         Optimization of Built-In Array Operations

·         Execution Engine Optimizations, which include

o   Function Calls

o   Accessing prototype properties of an object

o   Specific look-up patterns for JScript variables via window.foo and this.foo, where foo is the variable and this represents the global window object

Details about changes made and the best practices for these areas are documented in the Platform Performance Improvements whitepaper. Other whitepapers related to the IE8 are available here.

JScript and IE8 Beta

As a follow up my previous post JScript Performance in IE8 Beta, here is another set of reviews that I found about the JScript engine shipped in IE8 beta.

·         “…SunSpider JavaScript test on Internet Explorer 8. Previously it failed miserably coming in a very distant last place… That’s more than five times better than Internet Explorer 7 in our previous tests!...” -   http://cybernetnews.com/2008/03/06/internet-explorer-8-first-impressions/ 

·         “ …Fired up IE8 at last and I am really happy to see the speed of the application as it opens so fast in comparison to FF 3…” - http://www.thinkdigit.com/forum/showthread.php?p=768498

·         “…I downloaded and installed it on my Mac last night … tried running the SunSpider JavaScript Benchmark tests on it and it completed the test in an extremely respectable 9.9 secs. For comparison, Firefox 3.0b3 took 16.9 seconds to complete the same test…” - http://www.tomrafteryit.net/internet-explorer-8-beta-released/

·         “ …Just an update, on our slowest test system (old), running Vista 32bit, 1gb RAM, IE7 was running around 35000. Installing IE8 and rerunning the test the number is consistently under 10000… I know MS was reoptimizing all the Javascript for IE8, but this is pretty impressive, as IE8 is beating the latest build of FireFox 3 on the same system…” - http://www.codinghorror.com/blog/archives/001023.html

·         “…It feels fast… I have no data to back this up, but everything feels snappier. Not just script performance but page rendering as well…” - http://john-sheehan.com/blog/index.php/internet-explorer-8-beta-1-first-impressions/

·         “…IE8 beta1 was only released today, so we haven't been able to test it as thoroughly as the other browsers. However, it's clear that JavaScript performance has improved…” - http://bdn.backbase.com/blog/sjoerd/performance-is-everything

·         “…IE8 performance is much better than IE7.... and ‘closer to the other browsers’ (Firefox, Safari)…” - http://twitter.com/rayval

Stay tuned ....

JScript Performance in Internet Explorer 8 Beta

The cat’s finally out of the bag. IE 8 Beta is finally live and available publically for download. Here is a link to the blog post JScript in Internet Explorer 8 Beta 1 for Developers detailing the work done by the JScript team.

Here are a first few set of comments that I found around the performance of JScript engine that is shipped as a part of IE8 Beta.

·         John Resig’s post -  JavaScript in Internet Explorer 8, wherein he states “… Internet Explorer 8 is our release…”;  “…The IE team has made some big improvements in improving garbage collection issues, memory management, and performance - all of which will be greatly appreciated in everyday applications…” - http://ejohn.org/blog/javascript-in-internet-explorer-8/

·         “…In fact, it seems IE8 can go toe-to-toe with Opera 9.5 build 9815…” - http://thomas.tanreisoftware.com/?p=89

·         “…As for performance, it runs a javascript test I ran before 4 times faster than IE7…” - http://forums.majorgeeks.com/showpost.php?p=1118324&postcount=4

·         “It feels fast. I have no data to back this up, but everything feels snappier. Not just script performance but page rendering as well…” - http://www.dzone.com/links/internet_explorer_8_beta_1_first_impressions.html

·         “… pages seemed to load at about the same speed or a little bit faster as compared to IE7…” -  http://www.webware.com/8301-1_109-9887147-2.html?part=rss&tag=feed&subj=Webware

 Would add more as we go along.

Classes in Java Script

Here is a series of posts on “Classes in JScript”  written by Ritesh from the JScript team at MS:

Classes in Jscript - Part I

Classes in JScript – Part II: Instance Properties / Methods & Class Properties / Methods

Classes in JScript – Part III: Class Hierarchy and Data Encapsulation

Difference in Java Script behavior across browsers

Many a times, Java Script developers are perplexed by the fact that the same piece of Java Script code written by them behaves differently on the different web browsers. The reason for the same is the different implementations of the ECMA Script language which comes with various browsers. Here is a draft of JScript Deviations from ES3 which captures some of this.

So, now if you have a Java Script or JScript code which behaves differently on different browsers, take a look at this document. It might have the snwer to your problem.

Read more about this at Pratap’s blog ECMAScript3 and beyond.

JScript COM interop...

Here are links to a virtual series written by Sheetal, one of the developers in the JScript team on Jscript COM interop

·         Interoperability of JScript with COM

·         Calling functions of COM object from JScript

·         Script CallBack from COM

·         Passing Parameter to the Script Callback

·         Using Return Value of the Script Callback

·         Passing more than one parameter to the script callback

Got JScript Questions - Post them here...

One of the things that I did not capture on my Quick JScript References blog was a repository of the online MS community resources where one can post questions specific to JScript. The reason was that we were in the process of establishing a JScript forum. 

Now that we finally have a new JScript forum, the list is complete. Check out Don’s Appropriate forums to ask questions regarding JScript blog which encapsulates all this information.

So go ahead, and post your questions ... 

Some Quick JScript References

Looking for documentation regarding the different flavors of JScript and not sure which one is correct. While I was adding the documentation pages to my blog, I thought it might be worth to post them at the blog as well as a follow up to my blog regarding Difference between JScript, JScript.NET and Managed JScript

Here are some quick resources for JScript

Native JScript

• JScript User Guide
• JScript Language Reference
• JavaScript (JScript/ECMAScript) – Technical Articles

JScrip.NET

• JScript.NET – Getting Started; Writing, Compiling and Debugging code; Reference Guide
• JScript.NET Language Tour
• JScript.NET Articles – of which the whitepaper on “Performance Tips and Tricks for ASP.NET Pages Using JScript .NET” is surely worth a mention

Managed JScript

• Managed JScript QuickStarts
• Notes about JScript : Managed JScript announced
• Running managed JavaScript in Silverlight - Michael's Blog
• Managed JScript - Wallace B. McClure

AJAX

• Cutting Edge: Perspective on ASP.NET AJAX
• ASP.NET Spiced: AJAX
• “How Do I?” with ASP.NET AJAX (Videos)
• Multiple AJAX Videos
• ASP.NET AJAX

And yes, to add onto it is the fairly new JScript team blog - http://blogs.msdn.com/jscript

I would keep adding to these lists. In the meanwhile, in case you are aware of some other cool links for the above pl feel free to add them to the comments.

Improve AJAX Performance | Download Windows Script 5.7 now

Recently, Microsoft made a public release of Windows Script v5.7 which ships with different flavors of Windows® Vista for for Windows® 2000/XP as well as Windows® 2003 Server.

Below are the download links for the same

Download Windows Script 5.7 for Windows XP

Download Windows Script 5.7 for Windows 2003 Server

Download Windows Script 5.7 for Windows 2000

IE and especially AJAX users should surely install this update. Don (who’s the test lead on the JScript team) has enumerated upon the reasons and advantages one would get by installing the update at our JScript team blog here - http://blogs.msdn.com/jscript/archive/2007/08/12/windows-script-5-7-released-for-windows-2000-windows-xp-and-windows-2003-server.aspx

Note: The release notes for the same are now available at http://download.microsoft.com/download/f/f/e/ffea3abf-b55f-4924-b5a5-bde0805ad67c/Windows Script Release Notes.rtf

Microsoft Ajax View tool

Recently, MS made a public release of the Ajax view tool and I thought it's surely worth mentioning and spreading the word around.

Overview snippet of the tool …

The goal of the Ajax View project is to improve developer's visibility into and control over their web applications' behaviors on end-user's desktops.

The Ajax View approach is to insert a server-side proxy (or web server plugin) in-between the web server machines and the end-user's browser. This proxy captures the web application's JavaScript code as it is being sent to a browser and rewrites the code to insert extra instrumentation code. The injected instrumentation code runs with the rest of the web application inside the end-user's browser and can capture performance, call graph, application state and user interaction information, providing visibility directly into the last hop of the user's experience ...

Download from

You can find the download and usage information at http://research.microsoft.com/projects/ajaxview/

More information

John’s blog item about Ajax View on the IE team blog has more information regarding the same:  http://blogs.msdn.com/ie/archive/2007/08/23/Analyzing-Web-2.0-Applications-with-Ajax-View.aspx

Difference between JScript, JScript.NET and Managed JScript

There are three different types of JScript engines that MS currently offers to the users. In this blog I would like to discuss more about the differences between them and would go into the reasoning for three different types sometime later.

JScript (or native JScript)

Read the intro about this in my previous blog here. The native JScript engine relies primarily on Microsoft's ActiveX/COM to provide much of its functionality. The core engine (jscript.dll) is installed as a Windows/IE component on a user machine and resides in “% SystemRoot%\system32” directory.

JScript.NET

JScript .NET is the next generation of an implementation by Microsoft of the ECMA 262 language. Combining the feature set of previous versions of JScript with the best features of class-based languages, JScript .NET includes the best of both worlds. The JScript.NET engine relies primarily on the .NET Framework to provide much of its functionality and runs on the Common Language Runtime.

Differences in JScript .NET when compared to (native) JScript include true compiled code (as it is converted to MSIL format for the CLR), typed and typeless variables, late- and early-binding, classes (with inheritance, function overloading, property accessors, and more), packages, cross-language support, and full access to the .NET Framework.

 

Being a part of the .NET Framework, JScript .NET’s core engine Microsoft.JScript.dll is installed at “% SystemRoot%\Microsoft.NET\Framework\vX.XXXXX”. The  X.XXXXX specifies the .NET Framework version which is installed. Based on the .NET Framework version that is shipped/installed, the language is at times referred to as version 1.0/1.1/2.0 correspondingly. Also, the language at times is versioned based on Visual Studio’s major version it shipped with – like 8.0 for Visual studio 2005 with which .NET Framework 2.0 was shipped. So JScript.NET-2.0 and JScript.NET-8.0 both refer to the same version.

Managed JScript

Managed JScript is the name that is used for the implementation of the ECMA-262 language over the Dynamic Language Runtime to be delivered by Silverlight. It is the latest addition to the JScript family and was released in MIX07.

 

Unlike JScript .NET which is less dynamic than the original JScript but provides CLS compatibility, Managed JScript is designed on top of the DLR and provides the features needed for scripting scenarios. Implementation over DLR enables Managed JScript code to works well with not only C#, but also with IronPython , IronRuby, VB among other languages. The Managed JScript engine is installed by Silverlight 1.1 at “%ProgramFiles%\Microsoft Silverlight\Microsoft.JScript.Runtime.dll”.

 

The official release of Managed JScript is planned as a part of Microsoft Silverlight 1.1 (the Alpha Refresh release of the same can be downloaded from here) and next versions of ASP.NET. You can get more information about the same from the official Silverlight website here.

Hope this should get some clarity of the different types of JScript offerings from Microsoft. I would follow up with more on JScript soon.

The World of JScript, JavaScript, ECMAScript …

Change is inevitable, except from vending machines – a quote from an unknown source but so true. With the release of the Visual J# 2.0 Redist-SE over, the time has come for me to change and look for bigger and brighter challenges. I recently moved to the JScript team at Microsoft IDC. So yes, that would mean going ahead you would read quite a bit on the same at my blogs. Here is a short summary of a few definitions:

What is JScript?

JScript is Microsoft’s implementation of the ECMAScript scripting language. JScript is implemented as a Windows Script engine, which means it can be "plugged in" to any application that supports Windows Script, such as Internet Explorer, Active Server Pages, and Windows Script Host. JScript was first supported in Internet Explorer browser 3.0 and typical file extension of JScript source code files is .js.

Got you, but then what is ECMAScript?

ECMAScript is a scripting programming language, standardized by Ecma International in the ECMA-262 specification. There are three editions of ECMA-262 published, and the work on the fourth edition is in progress.

ECMAScript is supported in many applications, especially web browsers where it is is often referred to as JavaScript or JScript. The various dialects typically include their own, different standard libraries, of which some are standardized separately – such as the W3C-specified DOM. Some implementations, of the same have a completely different set of libraries. This means that applications written in one dialect of ECMAScript will not likely work in another, unless they are designed to be compatible

What is JavaScript? How is it different from JScript?

"JavaScript" is actually Netscape Communications Corporation's (and now the Mozilla Foundation's) implementation of the ECMAScript standard.

In addition to other internal implementation differences, the existing version of JScript uses non-generational mark-and-sweep garbage collection whereas JavaScript (the original implementation of which is the SpiderMonkey engine) uses a generational mark-and-sweep system.

Note: Though people often use JScript and JavaScript interchangeably, which is because of the fact that these languages are very similar, it is important to note that neither of them is a simplified version of Java as some may think. Other than incomplete syntactic resemblance and the fact that both JScript/JavaScript and Java can provide executable content in web browsers, the two languages are unrelated.

Would follow up with more soon …

Visual J# 2.0 Redist Package Second Edition: Targeting Different Platforms using Visual Studio 2005

Visual J# applications were designed to be built in an “x86” only mode using Visual Studio 2005. The main reason for the same was the fact that Visual J# Redist 2.0 supported execution of J# applications natively only on 32-bit platforms. On 64-bit platforms, the Visual J# applications used to run only in the WoW mode and native 64-bit execution was not available.  Now, with Visual J# Redist 2.0-Second Edition, users can build and execute Visual J# applications natively in 64-bit platforms. Users can build Visual J# applications specific to the following platform types:

·         Anycpu – binaries that are platform agnostic and can run on any platform type natively

·         x86 – binaries that run natively on 32-bit machine and in WoW mode on 64-bit machines

·         x64 – binaries that only run natively on x64 architecture 64-bit machines

·         IA64 – binaries that only run natively on Itanium architecture 64-bit machines

Here are the steps that are needed to build Visual J# applications to non-default (non x86) architecture type using Visual Studio 2005

1.       Ensure that you UNINSTALL Visual J# Redist 2.0 which comes as a part of Visual Studio 2005.

2.       Install Visual J# 2.0 Redistributable Package – Second Edition on the machine.

3.       Make sure you are using the “Visual J# Development Settings” for Visual Studio (read more about how to change the development settings in Visual Studio at my blog post here).

4.       Now, when you open any J# Project/Solution in VS2005, go to the Configuration Manager as shown below

5.       This would open the Configuration Manager as below, in which you need to define a <New> Platform type as below

6.       Choose any of the three settings as shown in the drop down of the new popup window

7.       Let the other choices remain as-is

8.       Hit OK. This would show the updated platform setting in the Configuration Manager.

9.       Close the Configuration Manager

Building Visual J# applications for 64-bit platforms using MSBuild

MSBuild is a build platform for Microsoft and Visual Studio. Details about MSBuild tasks are documented here.

Microsoft Visual J# 2.0 Redistributable Package – Second Edition comes with MSBuild support enabled (including cross compilation) from the command-line. This enables you to build Visual J# projects (.vjsproj) and solution (.sln) files that are created with Visual Studio 2005 from the command-line by using MSBuild.

All Visual J# project and solution files that are created with Visual Studio 2005 default to the x86 architecture type. Modify the project and solution files to build them to a different architecture type as specified below:

• anycpu, x64, or IA64 architecture types if using the 32-bit (or WoW) MSBuild task.
• x86, x64, IA64 or anycpu type if using the 64-bit MSBuild task.

The reason for the above behavior is that the 32-bit or WoW MSBuild task, which is present at %SystemRoot%\Microsoft.Net\Framework\v2.0.50727, by default emits 32-bit (x86) architecture type binaries. The 64-bit MSBuild task, which is present at %SystemRoot%\Microsoft.Net\Framework64\v2.0.50727, by default emits anycpu binaries. This behavior is different from the default behavior that is expected from Visual J# project and solution files that are generated by Visual Studio 2005.

To build applications for a specific platform architecture type by using MSBuild, follow either of the following procedures:

1. Build the *.vjsproj files with the “/property:platform=XXX” option.
2. Build the *.sln files with the “/property:platform=XXX” option.

XXX above specifies the targeted platform type (anycpu/x86/x64/itanium).

For Option1 (building the *.vjsproj file), add a new Property Group section to the *.vjsproj file that is generated by Visual Studio 2005 as illustrated below:

 The value of YYY is the Configuration (Debug/Release), and the value of XXX is the Platform (anycpu/x86/x64/itanium). For example:

If you are building for the x86 platform type, ensure that x86 PlatformTarget is inserted in the existing PropertyGroup condition for x86 platform.

Values other than PlatformTarget should also be changed as desired in the Property Group section.

For Option 2 (building the *.sln file), modify all the *.vjsproj files which are a part of the solution as explained above and modify the *.sln file as described below:

·         In the GlobalSection(SolutionConfigurationPlatforms) and GlobalSection(ProjectConfigurationPlatforms) sections, add the “<Configuration>|<Platform>” preSolution and postSolution that you have included in your *.vjsproj files. For example, imagine that you had added Debug|x64 as above, and the original *.sln file resembled the following example: