Matevž Gačnik's Weblog

There's a nice little (and dangerous) tool present in every .NET Framework SDK.

It's called corflags.exe. If you run it, you might get something like this:

C:\corflags testme.exe

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 1
ILONLY    : 1
32BIT     : 0
Signed    : 0

What this tells you (via the CLR Header) is that testme.exe assembly hides a .NET Framework 2.0 compiled code. All 2.0 framework code will have 2.5 header version, while all 1.0/1.1 compiled code will have 2.0 header version. It's a bit of a mess, but noone can change history.

Next important value is PE. It tells you whether this assembly is a 32-bit or 'any cpu' compiled assembly. If PE value should be 'PE32+' than you could conclude that this is a 64-bit capable assembly.

The 32BIT property, contrary to its name, does not represent bitness of the assembly. In this case, 32BIT property holds a value of 0, which would mean that this is a 64-bit assembly. Actually this assembly can be run anywhere, since it was compiled with agnostic setting of 'any cpu'. If I wanted to, I could turn this knob using the following:

corflags.exe /32BIT+ testme.exe

Now, this assembly would always execute under WoW64 (emulated 32-bit environment on a 64-bit box). In a case where this execution would not be possible - ie. run against an ia64 box - one would get a BadImageFormatException exception.

There is no way (for now) to demand execution in a 64-bit process because this thing is not controled by a metadata flag. Rather it's controled at compile time and compiler has to emit PE32+ compatible code.

Recap: CLR Header property denotes compiler version which was used to produce the assembly. PE property tells you whether this assembly is either 32-bit (PE32), 'any cpu' (PE32) or 64-bit (PE32+). If the 32BIT property is set it mandates execution in a 32-bit process, if the platform allows it.

If you happen to be in the 64-bit world (read running a 64-bit OS on the x64 box, not IA64), there are two options on how your managed code runs.

It can run:

• In a 32-bit process (loads x86 CLR)
• In a 64-bit process (loads x64 CLR)

The high order bit here is the flag under which the image was compiled. Since you cannot compile for 64-bit architecture in .NET Framework 1.0/1.1, and 2.0 is your only choice, let's focus on Visual Studio 2005/.NET Framework 2.0 features.

If you look under the hood on a x64 box, you will find that VS 2005 installer will drop TWO frameworks on your machine.

The 32-bit framework will install in c:\windows\microsoft.net\framework directory, the 64-bit framework will install in c:\windows\microsoft.net\framework64 directory.

If you installed .NET Framework SDK, you will get two SDKs too. One will be in c:\program files\microsoft.net\sdk\v2.0 64bit (64-bit), the other in c:\program files (x86)\microsoft visual studio 8\sdk\v2.0 (32-bit, installed in VS 2005 base directory).

What happens at load time is the CLR runtime host decides on which CLR it needs to load based on the CLR metadata flags. Normally, if you do not change the defaults in VS 2005, your assemblies will be compiled using the 'anycpu' (also known as MSIL flag) which will allow the runtime to host the managed app in a 64-bit process on a x64 box and in a 32-bit process on a x86 box.

You can, however,  control and override this default behaviour even after your code has been compiled. There's a handy tool called corflags.exe present in the SDK that allows you to force 'anycpu' compiled code to use 32-bit process in 64-bit world.

More on that in another blog entry.

My old laptop died on me this past weekend. Even though it wasn't much of a machine lately, it was dependable to the very last moment, when it decided to stop working completely. Dell Inspiron,  RIP.

My new workhorse is a fabulous machine: Acer Ferrari 4005 WLMi

It's a 64-bit machine, based on AMD Turion 64 processor. It looks splendid, although I have to admit that if it would be possible, I would remove the Ferrari logo during my meetings - even though I am a Ferrari F1 fan.

I'm running Windows Vista December CTP x64 edition, including VS 2005 + .NET Frameword 2.0 x64, WinFX RTC December CTP x64, Windows SDK x64, etc.

Running Indigo in a 64-bit process is a breeze. :)

Anyone deciding between Pentium M and Turion 64 based machine should read: Clash of the Titans: Dothan vs. Turion

The article compares Intel Pentium M 760 (Dothan) and AMD Turion 64 ML-37. It's a great article considering the shift to 64-bit is currently underway.

Read this 7 times in a row: "Microsoft® Visual Studio® 2005 Extensions for Windows Workflow Foundation Beta 1.2 for Microsoft Pre-Release Software WinFX® Runtime Components - December Community Technology Preview (CTP)"

Wow.

If you are planning to install or have already done so, there's an issue with the automated install of December CTP of WinFX RC (Runtime Components).

The following link will install November 2005 WinFX RC:

http://www.microsoft.com/downloads/details.aspx?familyid=BD3BA2D5-6ADB-4FB2-A3AA-E16A9EA5603F&displaylang=en

And to make it even more complex, if you happen to install it in Windows Vista December CTP, there is no way to remove it and have a clean machine afterwards.

Use the complete download link, ie:

• x86: http://download.microsoft.com/download/9/4/9/949EEA41-364A-45DC-8F4E-47E7AC147D25/winfxrc.exe
• x64: http://download.microsoft.com/download/8/3/F/83F862AA-FF41-4D54-9567-1F37888A41DB/winfxrc_x64.exe

How do you know if this thing screwed you up? You will not be able to install a 1GB pack of Windows SDK (December 2005), which also includes WinFX docs and samples.

Another proof are filename timestamps of for example System.ServiceModel.dll and friends, which are 11/18/2005 - equaling to November 2005 CTP dates.

I've said it before - in the last two years I have become a huge Apple fan.

It all started with me being inquisitive and buying a peace of furniture - Apple iMac G5. It went on with iPod nano.

I love Apple hardware. I like Apple software. There are known limitations inside the Mac OS X platform for it not being able to compete with Microsoft in terms of development experience and development technology adoption. They are ages behind in some critical areas, but also a couple years ahead in terms of OS GUI experience. Things like search, metadata, clean user inteface or, in general, end-user things work perfecly in the current builds of Mac OS X 10.4.3.

Now, it seems that Apple is trying to push out new Intel based laptops in January. I am definitely reconsidering when it comes to having the best of both worlds.

Today, when I was driving back home from a client of mine, I managed to squeeze some time off between the necessary phone calls to reason about the state/discrepancies of technology adoption between different businesses.

There's an obvious dicrepancy present.

There are businesses which challenge technology. There are businesses which know about Vista/Indigo/Avalon/Workflow progress. There are businesses which think they know about Vista/Indigo/Avalon/Workflow progress. And then, there are real businesses.

They don't care.

By real I don't mean successful businesses. A business can be successful and not real at the same time. What I mean by real is large, heterogeneous, multi-platform, cross-racial businesses. They just do not care.

A line of thought, which is mostly present in these scenarios is this: What and how do we use technology to drive our business opportunities? And if one thinks about it, they are right in both cases:

1. Adopting a new technology can help you increase business opportunities. It can also slow you down during the learning cycle. If there are too many learning cycles, you can be slow all the time.
2. New technology usally costs money. It costs in terms of licences, training and lost working hours trying to make it work. This is counter productive in terms of fulfilling/achieving business opportunities.

The outcome is that real businesses take wise decisions and adopt when the time comes. They do not rush it. That's one of the reasons that makes them successful.

This should not be read as if my opinion is to wait till technology matures. There are rare cases that mandate usage of new technology instantly.

The following is a list of Windows Communication Foundation (read Indigo) changes from September CTP (beta 1) to November CTP (beta 2 RC0).

Most of them are name changes. Nevertheless, you will need to update at least configuration, since element/attribute naming there has changed quite a lot.

Class name changes:

1. Fault<T>       FaultException<T>
2. UnknownFault   UnknownFaultException
3. ServiceSite    InstanceContext

Parameters of [OperationBehaviour] attribute:

1. AutoCompleteTransaction TransactionAutoComplete
2. AutoEnlistTransaction   TransactionScopeRequired

Other changes:

1. ServiceHost<T>   ServiceHost(typeof(T)>

Binding names:

1. wsProfileBinding            wsHttpBinding
2. netProfileTcpBinding        netTcpBinding
3. netProfileDualTcpBinding    netTcpBinding
4. netProfileNamedPipeBinding  netNamedPipeBinding
5. basicProfileBinding         basicHttpBinding

Configuration element/attribute name changes:

1. /services/service[@serviceType]                   /services/service[@type]
2. /endpoints/endpoint[@contractType]                /endpoints/endpoint[@contact]
3. /services/service/endpoint[@bindingSectionName]   /services/service/endpoint[@binding]
4. /behaviors/behavior[@configurationName]           /behaviors/behavior[@name]
5. /bindings/*/binding[@configurationName]           /bindings/*/binding[@name]

Attribute changes:

1. [BindingRequirements(TransactionFlowRequirements=RequirementsMode.Require)]
   [TransactionFlow(TransactionFlowOption.Required)] 
2. [BindingRequirements(QueuedDeliveryRequirements=RequirementsMode.Require)
   [BindingRequirements(QueuedDeliveryRequirements=BindingRequirementsMode.Required)
3. [InstanceMode=InstanceMode.Singleton]
   [InstanceContextMode=InstanceContextMode.Single]
4. [InstanceMode=InstanceMode.PrivateSession]
   [InstanceContextMode=InstanceContextMode.PerSession]
5. [InstanceMode=InstanceMode.PerCall]
   [InstanceContextMode=InstanceContextMode.PerCall]
6. [InstanceMode=InstanceMode.SharedSession]
   [InstanceContextMode=InstanceContextMode.Shared]

This list may not be complete.

I do expect that QueuedDeliveryRequirements property of [BindingRequirements] attribute will be standalone when Indigo ships. There's no point in having a separate attribute for expected transaction semantics and leave out the queued delivery. It's the same concept being pushed down to administrators (binding requirements are fixed requirements which are supposed to be met by the admin - they are the developers' law of expected processing model).

Maybe this attribute should be named [QueuedDelivery], with appropriate property for demanding it (like QueuedDeliveryOption) and a property called OrderedSessionOption, which would handle ordered session maintenance.