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

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

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.

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# 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

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:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'YYY|XXX' ">     <DebugSymbols>true</DebugSymbols>     <DebugType>full</DebugType>     <Optimize>false</Optimize>     <OutputPath>bin\Debug\</OutputPath>     <PlatformTarget>XXX</PlatformTarget>     <DefineConstants>DEBUG;TRACE</DefineConstants>   </PropertyGroup>

 

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

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">     <DebugSymbols>true</DebugSymbols>     <DebugType>full</DebugType>     <Optimize>false</Optimize>     <OutputPath>bin\Debug\</OutputPath>     <PlatformTarget>x64</PlatformTarget>     <DefineConstants>DEBUG;TRACE</DefineConstants>   </PropertyGroup>

 

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:

GlobalSection(SolutionConfigurationPlatforms) = preSolution      Debug|x86 = Debug|x86      Release|x86 = Release|x86 EndGlobalSection GlobalSection(ProjectConfigurationPlatforms) = postSolution      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x86.ActiveCfg = Debug|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x86.Build.0 = Debug|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Release|x86.ActiveCfg = Release|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Release|x86.Build.0 = Release|x86 EndGlobalSection

 

Following is the modified result:

GlobalSection(SolutionConfigurationPlatforms) = preSolution      Debug|x86 = Debug|x86      Release|x86 = Release|x86      Debug|x64 = Debug|x64 EndGlobalSection GlobalSection(ProjectConfigurationPlatforms) = postSolution      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x86.ActiveCfg = Debug|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x86.Build.0 = Debug|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Release|x86.ActiveCfg = Release|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Release|x86.Build.0 = Release|x86      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x64.ActiveCfg = Debug|x64      {E2D2EA3E-0E77-4C82-8AA4-D94FFC1EB7F6}.Debug|x64.Build.0 = Debug|x64 EndGlobalSection

 

Note: For Option 2 (building the *.sln file), the following points need to be addressed: ·         Because adding new options at the beginning of the .sln file changes the default compile properties of the file, this is not the recommended approach. ·         If a solution has multiple projects which must be compiled for different platforms, iterate through each J# project and compile them separately instead of compiling them as a single solution file.

 

Note: Visual Studio is not certified to recognize and open project and solution files that are edited manually. To use Visual Studio 2005 to open and edit the project or solution files, the recommended approach is to maintain a separate copy of the files for manual editing.

 

The Visual J# compilers (both 32-bit and 64-bit) shipped with J# Redist 2.0-SE now support a new command-line switch “/platform” with the following available options for cross-compilation:

• x86: for use when target platform is x86.
• x64: for use when target platform is AMD64 (or x64).
• itanium: for use when target platform is IA64.
• anycpu: for use when application is portable across architectures.

To be compatible with the previous releases of Visual J# Redistributable, the code generated by the 32-bit and WoW Visual J# compiler that ships with Microsoft Visual J# 2.0 Redistributable Package – Second Edition targets the x86 platform by default. To run the existing Visual J# applications natively on 64-bit platforms, rebuild the existing applications by using the /platform switch and create anycpu or 64-bit platform-specific applications.