Gaurav Seth's WebLog : Visual J# / 64-bit computing

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

GauravS — Thu, 07 Jun 2007 13:31:00 GMT

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

Build your Visual J# Project/Solution and you are all set.

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

GauravS — Thu, 24 May 2007 20:59:00 GMT

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:

Build the *.vjsproj files with the “/property:platform=XXX” option.
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.

Visual J# 2.0 Redistributable – Second Edition: Compiler Changes

GauravS — Tue, 22 May 2007 15:10:00 GMT

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.

The code generated by the 64-bit Visual J# compiler that ships with Microsoft Visual J# 2.0 Redistributable Package – Second Edition targets the anycpu platform by default. Use the option that is specific to the particular 64-bit platform architecture type (x64 or itanium) while compiling for that 64-bit platform. Similarly, use the x86 option when compiling the application for a 32-bit platform from the 64-bit Visual J# compiler.

Visual J# 2.0 Redistributable – Second Edition: Leveraging Existing 32-bit Visual J# Code

GauravS — Mon, 21 May 2007 13:58:00 GMT

The 64-bit editions (x64 and IA64) of Microsoft Visual J# 2.0 Redistributable Package – Second Edition enable users to take full advantage of the 64-bit .NET Framework (v2.0 and v3.0) and the underlying 64-bit hardware platform without having to deal with differences between the 32-bit and 64-bit hardware platforms. To know more about the differences on the two platforms see the whitepaper here.

In most cases, Visual J# applications that were developed by using previous versions of Visual J# Redistributable targeting the 32-bit platform can be recompiled by using the Visual J# compiler that ships with Microsoft Visual J# 2.0 Redistributable Package – Second Edition and can be executed as 64-bit native applications without source code modifications. However, 32-bit Visual J# applications that have dependencies on floating-points, native code (for example, DLLs or COM InProc Servers) or the feature set that is not supported may require modifications when porting to 64-bit platforms.

To use the existing 32-bit code on the 64-bit platform, the application must be recompiled on a computer with the Microsoft Visual J# 2.0 Redistributable Package – Second Edition compiler by using the ‘/platform’ compiler switch.

Though it would be great to never know about the differences of the underlying platforms, a few scenarios which developers must address are available in the whitepaper here. Following are a few more feature areas supported by Visual J# for which a source code change would be needed to execute the applications natively on 64-bit platforms:

32-bit vs. 64-bit Platform Difference	Recommendation(s)
JavaCOM	Use .NET COM interop instead of COM interop.
J/Direct	Use .NET PInvoke instead of making native calls.
J++ delegates	Use .NET delegate to author delegates.
WFC	Use Windows Forms to write controls.

Visual J# 2.0 Redistributable–Second Edition: Released To Web

GauravS — Fri, 18 May 2007 07:54:00 GMT

The ENU Visual J# 2.0 Redistributable Package – Second Edition for x86, x64 and IA64 platforms is released to the web (download locations below). This release enables all Visual J# users to execute the Visual J# applications natively on the 64-bit platforms, thus leveraging the existing Windows and .NET Framework investments on 64-bit platforms. Apart from the 64-bit execution, the product also contains a host of bug fixes for issues discovered during various stages of the language since its inception. The product is supported over .NET Framework v2.0, v3.0 and v3.5 (Beta).

Product Download Locations

Microsoft Visual J# 2.0 Redistributable Package – Second Edition (x86)

Microsoft Visual J# 2.0 Redistributable Package – Second Edition (x64)

Microsoft Visual J# 2.0 Redistributable Package – Second Edition (IA64)

.NET Vs J2EE: How do we compare

GauravS — Thu, 10 May 2007 14:21:00 GMT

A customer recently wrote the following to us-

My organization is currently considering either .NET or Java (J2EE) as our enterprise application development platform.

I am sold on .NET as I believe that:-

· There are cheaper resources (per hour rate) and large vendor/contractor providers

· It quicker to develop applications with .NETusing either Visual Studio or Web Express

· Tools are free

· Strong technical community (MSDN).

He needed facts, independent white papers to confirm the findings.

Here is a link to Competitive Reports and Evidence: Comparing .NET to J2EE. This site contains extensive materials designed to help users evaluate Microsoft .NET vs. J2EE application server technologies. Each area contains downloadable whitepapers, benchmark comparisons, and sample source code (including studies by independent parties like Forrester)

The website Resources for Java Developers contains the above and more sections.

In case you know of more resources, feel free to add.

Back to the world of Blogging

GauravS — Wed, 09 May 2007 12:07:00 GMT

I know I have kept away from blogging for quite some time now. There were pleasant changes in life that I was adapting to and kept me busy for a while. Beyond that, I would say it was some procrastination which kept me away. Well, so here I am, kicking the procrastination off … !!!

So what have I been doing for the past one year?

Well on the work front, it’s mainly been work to ship the next version of the J# Redist called the Visual J# 2.0 Redistributable – Second Edition(SE). The 2.0-SE release would be shipped in three variants like the .NET Fx SKUs – one SKU for each platform type viz. x86, x64 or amd64 as some people call it and ia64. Apart from enabling users to execute their Visual J# applications natively on 64-bit platforms, the release also contains quite a few bug fixes as compared to the previous release. We are on track to release the product in the second quarter of calendar year 2007 as published on the Visual J# landing page on MSDN.

How does WoW64 work?

GauravS — Wed, 26 Apr 2006 12:24:00 GMT

In one of my previous posts I discussed a little bit about WoW/WoW64 in 64-bit computing. While I was trying to write more about the same, I came across this blog from Craig McMurtry - http://blogs.msdn.com/craigmcmurtry/archive/2004/12/14/301155.aspx. After reading the same, I felt that this post is very comprehensive and there is not much left to be explained (whatever is, is there after the post). So read on …

===========================

We saw that both Itanium and x64 processors have a way of making their differences from 32-bit x86 processors invisible to 32-bit x86 code, although we noted that x64’s do so in a way that is a lot more efficient than Itaniums. However, when the 32-bit x86 code is running on a 64-bit operating system, with 64-bit data structures, how does the operating system hide its differences from a 32-bit x86 operating system away from the 32-bit x86 application?

The answer is that, on a 64-bit operating system, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows on Windows 64, or WOW64 for short. WoW64 intercepts system calls to the operating system made by a 32-bit application.

It formulates native 64-bit system calls, converting 32-bit data structures into 64-bit aligned structures.

Then it issues the native 64-bit system call, and translates any output data from the 64-bit system call into 32-bit data structures.

Now, for non-technical folks in the audience, software applications quite typically use the facilities provided by other software components, called libraries, and they usually do so in the most efficient manner possible, which is by having the operating system load libraries into memory, and then accessing the facilities that they need by referring directly to the locations of those facilities in memory. Later, when we talk about developing applications for 64-bit Windows, we are going to emphasize that 32-bit applications cannot directly access the facilities of 64-bit libraries, and vice-versa. So, it would be quite disastrous for a 32-bit application running on a 64-bit operating system to attempt to directly access the facilities of a familiar library if that library were to turn out to be 64-bit. So, for 32-bit applications to work properly on 64-bit operating systems, they need to have 32-bit versions of their libraries available, while 64-bit applications need to have 64-bit versions of their libraries. So, in many cases, 32-bit and 64-bit versions of the same library need to exist side-by-side. Furthermore, if a 32-bit version of an application is installed, it should not overwrite a 64-bit version and vice-versa, so 32-bit and 64-bit versions of applications need to co-exist side-by-side, too.

On 32-bit Windows operating systems, programs are installed by default into a system folder called Program Files, while operating system components and shared libraries are installed into the System32 folder. On a 64-bit Windows operating system, there are separate versions of those folders for 32-bit and 64-bit software components.

So, in addition to the Program Files folder, there is a Program Files (x86) folder for 32-bit applications. Also, in addition to the System32 folder, there is a SysWOW64 folder. Contrary to what the names may suggest, 64-bit operating system components and shared libraries go into the System32 folder, while 32-bit operating system components and shared libraries go into the SysWOW64 folder. (There are no typographical errors in this paragraph: 64-bit entities go into the System32 folder, and 32-bit entities go into the SysWOW64 folder.)

Registry keys specific to 32-bit applications are stored in a branch under HKEY_LOCAL_MACHINE\Software\WOW6432Node.

All of this is done transparently to the application by WOW64, which, in intercepting calls to the operating system, detects references to file paths and registry keys and maps them accordingly.

This system allows 32-bit and 64-bit versions of the same applications to be installed side-by-side on the 64-bit operating system without risk of overwriting one another’s files or inadvertently accessing the wrong versions of the same library.

On the x64 versions of Windows Server 2003, there are both 32-bit and 64-bit versions of Internet Explorer installed by default. Why? Because many sites on the Internet incorporate 32-bit libraries called ActiveX controls, and for Internet Explorer to access those controls, it needs to be 32-bit. If you open up the Task Manager with both version running, and go to the Processes pane, you'll see that 32-bit processes are denoted by *32.

There are some limitations to 64-bit Windows’ support for 32-bit applications.

· You may remember reading here that 64-bit Windows operating systems do not support 16-bit applications? Well, many 32-bit applications have 16-bit installers. Windows detects many 16-bit installers and transparently instantiates an equivalent 32-bit version if one is available. Microsoft is working with vendors of 16-bit installers to obtain compatible 32-bit versions.

· You may also remember reading that 64-bit Windows operating systems require all drivers to be 64-bit. Well, many 32-bit applications depend on 32-bit drivers, and those applications will not run on 64-bit Windows.

===========================

A few points that I wanted to add to the above blog –

· Users often get confused between the 32-bit and the 64-bit subsystems on the 64-bit platform and struggle to find if a particular application is going to work on their 64-bit machines.

Applications are created as 64-bit, 32-bit or agnostic. All the 64-bit and agnostic applications would work on the 64-bit systems. For the 32-bit applications, it however depends if they are WoW64 enabled and tested or not. Applications which state that they would work as WoW on 64-bit platform, would use the x86 emulator. They should work as if they are running on a 32-bit machine. While a normal 32-bit app might not. So there is no default that installing a 32-bit application on the 64-bit platform would work in WoW automatically.

· How do we find if the application is running in the WoW mode or Native mode?

One of the ways in which you can confirm that your applications are running on the native 64-bit and not on a WoW emulation, is to check the size of the IntPtr on the machine. You can use System.IntPtr.get_Size() to find the same. For the native platform, the size would be 8 as compared to 4 on WoW emulation and 32-bit platforms.

Another way is to use the IsWow64Process API. It can help a user detect if the x86 targeted binary (assuming the binary is going to be a x86 binary)

is running in a Wow64 subsystem. You would need to do call this API via a GetProcAddress because it may not be present in some 32 bit OS'es.

· How do we find if the application is supposed to run in the WoW mode or Native mode?

I am discussing this from a managed code context. This can be easily found out from the PE header information of a managed file. To view this header you can use the corflags tool which is shipped as a part of the Visual Studio SDK. To read the details about this, read my blog here. The thumb rule is that binaries which are 32-bit (x86) specific, are the ones that would be executed in WoW64 environment on a 64-bit machine.

More soon!!!

MSDN webcasts on 64-bit platform computing

GauravS — Tue, 25 Apr 2006 12:10:00 GMT

Here are some really cool MSDN webcasts related to 64-bit computing. If you are getting started with 64-bit platforms or want to know a lot more about them, I am sure you would find these to be useful.

· MSDN Webcast: Welcome to 64-bit Windows Computing: Introduction, Architecture, Roadmap and 32-bit Application Compatibility (Level 100)

· MSDN Webcast: Terminal Services: Clear-cut Benefits with Windows Server 2003 x64 (Level 300)

· MSDN Webcast: Taking Application Development to the Next Level: Design and Development for 64-Bit Windows (Level 300)

· MSDN Webcast: Migrating Your Code to Run Natively on 64-Bit Windows: Insider Tips and Indispensable Tools (Level 300)

· MSDN Webcast: Managed Code on 64-bit Windows Platforms (Level 300)

· MSDN Webcast: Making the Most of Enterprise Hardware: SQL Server 2005 Data Transformation Services (Level 200)

· MSDN Webcast: Kernel Mode Drivers in Windows 64-bit Systems: Migration and Development (Level 300)

· MSDN Webcast: Implementing Security for Mobile Device Solutions (Level 200)

· MSDN Webcast: Guest Presenter: AMD64 Architecture Drilldown: 64-bit Performance and 32-bit Compatibility (Level 400)

· MSDN Webcast: Going Native on 64-bit Windows Platforms: Code Optimization Tools and Techniques (Level 300)

· MSDN Webcast: Going Native on 64-bit Windows Platforms: Application Support and Migration from Existing Application Frameworks (Level 300)

· MSDN Webcast: Data Warehousing with SQL Server 2000 Enterprise Edition (64-bit) (Level 300)

· MSDN Webcast: Active Directory: Maximize Performance in Enterprise Deployments with Windows Server 2003 x64 (Level 300)

· MSDN Webcast: 64-bit Computing with Intel(r) Processors - Enabling the Future (Level 400)

· MSDN Webcast: .NET Compact Framework 2.0 (Level 100)

· MSDN Architecture Webcast: Developing Applications for Windows XP x64 Edition with Visual Studio 2005 (Level 200)

In case I have missed some and you know of more, let me know.

What is WoW, Windows on Windows, WoW64, WoWx86 emulator … in 64-bit computing platform

GauravS — Mon, 24 Apr 2006 15:21:00 GMT

Before we discuss this, it is important for the users to understand a few facts about 64-bit platform offerings.

64-bit computing (from a Microsoft perspective) comes in two variants

· x64 (EM64T/AMD64)

· Itanium (EPIC)

Both, Windows Server 2003 SP1 64-bit and Windows XP 64-bit, support the above two mainstream 64-bit processor architectures.

Code execution is enable in both the above kind of platforms in two ways

· Native 64-bit

· WoW64 x86 emulator

While as the name implies, native 64-bit takes advantage of the native 64-bit computing platform, Windows-On-Windows environment, WoW, WOW64 etc. are all names that refer to an x86 emulator that allows 32-bit Windows-based applications to run on 64-bit Windows. Wow64 allows 32-bit productivity applications developed using the .NET Framework 1.0, 1.1 and 2.0 and Win32 to run on 64-bit Windows and take advantage of the 64-bit Windows kernel which offers a larger number of kernel handles and window handles. WoW64 supports 32-bit console, GUI and service application, and although some 32-bit server applications may be certified to run on WoW64, WoW64 is NOT intended for 32-bit server apps. WoW64 does NOT support 16-bit Windows apps.

WoW64 emulation is performed natively (on the chip) by the x64 micro-architecture, which means WoW64 performance on x64 is similar to that of 32-bit Windows. However, because the Itanium (IA64) architecture does not support native WoW64 emulation, WoW64 performance on the Itanium is substantially less than that of 32-bit Windows.

64-bit Visual J# Redistributable TAP goes live

GauravS — Mon, 03 Apr 2006 12:14:00 GMT

If you have been reading my blogs and wondering that why off late I have been discussing a lot of advantages, issues and other stuff related to 64-bit computing – here is the answer. All this while (since the Whidbey release) the Visual J# team has been working on enabling the language for 64-bit platforms.

Today, we have officially opened the Technology Adoption Program (TAP) with select customers and MVPs for 64-bit Microsoft Visual J# Redistributable today. This program would run through June’06.

With the 64-bit Microsoft Visual J# Redistributable now available, J# users can now leverage

• Existing 64-bit workstation and server infrastructure investments

• Existing 64-bit .NET Framework investments

Catch you soon with more!!!

Some interesting reads on 64-bit performance benchmarks

GauravS — Mon, 20 Mar 2006 12:47:00 GMT

Here are some of the sites that I have really found good and informative about the different performance reports for 64-bit platforms (from a MS technology centric perspective).

64-bit Performance Benchmark: .NET 2.0 and IBM Websphere 6.0 - http://msdn.microsoft.com/vstudio/java/compare/benchmark64/default.aspx

XML performance showdown: Java, Mono and .NET - http://www.process64.com/articles/xmlmark1/xml-mark-revisited.pdf

Performance figures for 64-bit Paint.NET v2.6 - http://paintdotnet.12.forumer.com/viewtopic.php?t=651

Demo of the paint.NET application on different platforms

http://www.eecs.wsu.edu/paint.net/misc/PDN_x86_vs_x64.zip

Performance comparison of Java (and .NET) runtimes - http://gcc.gnu.org/ml/java/2004-10/msg00099.html

HPC.NET – are CLI based Virtual Machines Suitable for High Performance Computing - http://www.sc-conference.org/sc2003/paperpdfs/pap251.pdf

In case you know of more, pl share the same.

Using Delegates in the J# world

GauravS — Fri, 17 Mar 2006 18:02:00 GMT

While I was trying to write a blog around the topic of Delegates in J#, I found that a few blogs have already done this job pretty well. So I am not going to re-invent the wheel. I would just point you to the appropriate links for all information about delegates in J# (both System.Delegate and com.ms.lang.Delegate)

So here are the links

· Primer - Delegates in J#

· How to create com.ms.lang.Delegate in J#

· How to create System.Delegate in J#

· Some differences between com.ms.lang.Delegate and System.Delegate type in J#

· Some insights into Delegates from J# perspective

Also, if you are interested, here is a whitepaper on The Delegate Type in J#.

Hope this helps. In case you have any questions, feel free to write back to me.

Moving from 32-bit to 64-bit application development on .NET Framework

GauravS — Tue, 07 Mar 2006 10:12:00 GMT

This blog aims at clarifying the issues which 32-bit developers might be having when they start migrating to the 64-bit platform. My observations below would be concentrated towards the .NET Framework related technologies. Most of the things I discuss below are available at various scattered places. I am just aiming at collecting them at a single place to help developers migrating to the 64-bit platform.

Size of the Redist

As compared to the pure 32-bit platform offerings, the 64-bit offerings are usually double the size. This means the time to download and setup the 64-bit .NET Redistributable or anything similar also increases. But the reason for the same is the fact that the 64-bit offerings come clubbed with the 32-bit offerings. It enables applications to run in the native 64-bit mode as well as the WoW64 mode (which is the 32-bit version).

Framework64 directory

Unlike the 32-bit .NET Framework, when a user installs a 64-bit Redist on the machine there are two Framework directories that get created. They are

· …\WINDOWS\Microsoft.Net\Framework\v2.0.50727

· …\WINDOWS\Microsoft.Net\Framework64\v2.0.50727

Notice the difference in the two directories. The Framework directory contains the assemblies that are specific to the WoW64 (32-bit emulation on 64-bit platforms) world. The Framework64 directory on the other hand contains assemblies that are specific to the 64-bit platform. And assemblies that are platform agnostic are available in either or both the directories as per need basis.

Creating platform specific apps

Most of the language compilers (like C#) now offer a /platform switch. By using this switch, developers can create binaries targeted for a specific platform type or binaries that are platform agnostic. There are four types of binaries that are emitted

· anycpu – platform agnostic

· x86 – 32-bit platform specific

· x64 – x64 platform specific

· itanium – IA platform specific

(Read more about x64 and IA – their differences, similarities and FAQs here)

By default the compilers (like C#) emit anycpu binaries (also called portable assemblies) which are platform agnostic. In case the users want to create binaries specific to a platform, they can use the appropriate switch and be done.

Cross Compilation

The above concept of /platform switch enables cross compilation of binaries. Cross compilation means compiling binaries to a specific platform type (different from the current platform). This is mostly used in terms of compiling and creating 64-bit assemblies from a 32-bit compiler and vice versa. One point to note here is that cross compilation usually refers to compiling to different target types from the compilers shipped with the 64-bit Redist (WoW and 64-bit). The reason for this is that, while trying to compile for a 64-bit platform from a pure 32-bit machine, the 32-bit Redist would not have the components that are 64-bit specific. In such cases the compilation might go through with warning but execution might lead to runtime exceptions. Also, one should note that while cross compiling, users should stick to the platform architecture type of the machine, viz. x64 or IA. Assemblies for IA and x64 are specific to the platform architecture and cross compilation across architectures is not advised.

GAC in 64-bit platforms

Now, that we know that there are multiple types of assemblies and ways to create specific assembly types, the question comes about the Global Assembly Cache (or GAC) in the 64-bit machines. Unlike the .NET Framework 1.1, where the 32-bit specific offerings used to have a single GAC present the model has changed for .NET Framework 2.0 (Whidbey). There are 3 types of GAC’s now available

· GAC_32

· GAC_64

· GAC_MSIL

While the 32-bit platforms have GAC_32 and GAC_MSIL, the 64-bit have all the three. GAC_32 contains assemblies that are specific to the 32-bit platform and GAC_64 specific to the 64-bit platform. The GAC_MSIL contains the assemblies that are platform agnostic. While trying to load assemblies from the GAC, the CLR first looks at the GAC specific to the platform. If it is unable to find the same, it then moves to the GAC_MSIL.

Apart from these, we also have the conventional GAC present in all platforms which homes the .NET 1.0/1.1 assemblies which are platform independent.

Corflags demystified

Corflags.exe is a tool that is shipped as a part of the .NET Framework SDK. It is a powerful tool which allows users to view and configure the corflags section of a PE image. All the data related to platforms is available in this part of the PE image. Let us view the options available from this tool.

C:\WINDOWS\assembly\GAC_32>corflags /?

Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42

Usage: Corflags.exe Assembly [options]

If no options are specified, the flags for the given image are displayed.

Options:

/ILONLY+ /ILONLY- Sets/clears the ILONLY flag

/32BIT+ /32BIT- Sets/clears the 32BIT flag

/UpgradeCLRHeader Upgrade the CLR Header to version 2.5

/RevertCLRHeader Revert the CLR Header to version 2.0

/Force Force an assembly update even if the image is

strong name signed.

WARNING: Updating a strong name signed assembly

will require the assembly to be resigned before

it will execute properly.

/nologo Prevents corflags from displaying logo

/? or /help Display this usage message

A look at an example of a PE header seen from this tool for a 32-bit assembly is below

Version : v2.0.50727

CLR Header : 2.5

PE : PE32

CorFlags : 11

ILONLY : 1

32BIT : 1

Signed : 1

Here is what each component of the header means

Version: Contains the version of .NET Redist with which the binary is built.

CLR Header: 2.0 indicates a .Net 1.0 or .Net 1.1 (Everett) image while 2.5 indicates a .Net 2.0 (Whidbey) image.

CorFlags: This is computed by OR’g specific flags to indicate whether the image is ILONLY, its bitness etc. and is used by the loader.

ILONLY: Managed images are allowed to contain native code. To be “anycpu” an image shall only contain IL.

32BIT: Even if you have an image that only contains IL it still might have platform dependencies, the 32BIT flag is used to distinguish “x86” images from “anycpu” images. 64-bit images are distinguished by the fact that they have a PE type of PE32+.

The most interesting aspect is the PE and the 32BIT flag of the header. These combine to specify the assembly types. Here is how they would look like for:

· anycpu: PE = PE32 and 32BIT = 0

· x86: PE = PE32 and 32BIT = 1

· 64-bit: PE = PE32+ and 32BIT = 0

Using corflags tool, users can forcefully change the PE headers of any assembly to make them behave the way they want to. Users can force most of the flags to the values as wanted. However, it is advised to use compiler switches instead of this tool to create binaries with specific characteristics as desired.

64-bit Design Considerations

Apart from what all I have discussed above, there are surely some design considerations that users need to take care of while creating applications for 64-bit/agnostic platforms. These are discussed pretty well in the whitepaper here. So I would not go and re-invent the wheel.

Other helpful resources

· 64-bit Windows

· Getting Started with the 64-Bit .NET Framework

· The x64 Vs AMD64 Vs EM64T Vs Itanium Riddle – What is what?

Other related blogs

· http://blogs.msdn.com/gauravseth/archive/2006/02/17/534128.aspx

· http://blogs.msdn.com/gauravseth/archive/2006/02/21/536079.aspx

· http://blogs.msdn.com/gauravseth/archive/2006/03/02/542055.aspx

· http://blogs.msdn.com/gauravseth/archive/2006/03/06/544637.aspx

Cross compilation in the 64-bit .NET Framework world for platform specific features

GauravS — Mon, 06 Mar 2006 21:20:00 GMT

In today’s world, a lot of applications are written targeting both the 32-bit and/or the 64-bit platform. Using cross compilation, users can now create applications using the .NET Framework which are platform agnostic. This is achieved by the data in the PE header maintained for each app in the .NET Framework world.

Compilers like that of C# and C++ language use the /platform switch to empower the user to choose the platform type, they want their binaries to be executed on. Using this switch the users can just compile their binaries to be anycpu binaries – which implies that they are platform agnostic and execute natively on the 32-bit and the 64-bit platforms. This also enables users to compile binaries specific to a targeted platform – be it x86, x64 or the itanium platform.

This looks to be a perfect solution for compilation of binaries that do not have any feature dependencies on platform specific architectures. Now, lets take a hypothetical scenario where a language supports some features that are 32-bit specific and some features that are platform agnostic. In such cases how should the compiler behave? Here is description of the way I feel applications should be targeted in such cases

Compilation from	Anycpu	X86	X64	IA64
32-bit compiler on a 32-bit machine	Invokes the 32-bit compiler	Invokes the 32-bit compiler	Error	Error
32-bit WoW compiler on a 64-bit machine	Invokes the 64-bit compiler as another process and compiles using the same	Invokes the 32-bit compiler	Invokes the 64-bit compiler as another process and compiles using the same	Invokes the 64-bit compiler as another process and compiles using the same
64-bit compiler	Invokes the 64-bit compiler	Invokes the 32-bit compiler as another process and compiles using the same	Invokes the 64-bit compiler	Invokes the 64-bit compiler

Apart from the compiler, the users should also be aware of the compiler they are compiling from and the targeted scenarios. For e.g. Let us consider an application which is dependent of features not supported in the 64-bit world. The user compiles the same to a binary of the type anycpu from a 32-bit machine. The user then tries to execute the same binary on a 64-bit machine. In most of the cases the user is bound to run into issues and a Bad Format Exception might be thrown. Thus, it is not true that in all scenarios, cross compilation always works.

In case you believe that there is some other way, let me know too.