Monday, April 3, 2006

Getting VCL/.NET ready for .NET 2.0 and 64bit CLR

Changes, my friends, are afoot.  While waiting for the Delphi/.NET compiler (dccil) to embrace all the latest goodies in the CLR world (partial types, generics, nullable types, anonymous methods, etc...) other engineers have been working on a lot of things that are independent of all the new compiler goodness.  The biggest change that is going to happen to VCL/.NET is the change from using Integer for handles (ie. THandle = Integer;), it must now be changes to IntPtr.  One common misconception (and one I admit to having fallen prey to as well) is that somehow IntPtr is some kind of “Pointer” type represented as an Integer.  Well, call me foolish and gullible, but I'm going to go out on a limb here and say that “IntPtr” is not what I'd call a very good name.  OK, OK... it basically sucks as a name.  I can see why at first glance one would be led to the misconception that “IntPtr” is a “Pointer.”  So what is this odd bit of identifier madness?  In actual fact (and to the more intelligent and astute among you, this is all mindless drivel), it really means this “Integer whose physical size and precision matches the physical size of a Pointer on the currently running underlying platform for which the “Just-In-Time” compiler is actually generating code” (pay no attention to the nested quotes in that statement).

What does this mean?  Well... if we've done our job correctly, this should end up being a complete non-sequitor.  However, as I dust off my trusty crystal ball (which can only look into the past, BTW), I would say that in reality, some of you will be affected.  Most noteably, those among you, that find yourself snuggling up a little closer to the Windows API.  This would, generally, be those of you who tend to dabble in the white arts that many call “component development.”  With a few exceptions, as I've outlined, most of the magic will be handled by the judicious and careful implementation of that wonderful bit of class and scope enhancing compiler construct called Helper Classes.  By creating a rich helper for IntPtr that includes overloaded operators, explicit and implicit conversion operators, and other bits of fun, we can now...hopefully...keep the vast majority of existing code out there compiling and correctly functional.  We've already got most of this work done, and now the task at hand is to scour the VCL sources for the rare cases where we have some unintended implicit conversions taking place.  Seppy and I talked about this just this morning and he's working through some interesting cases where the implicit conversions are getting into an infinite loop.  Should be simple to fix.

The biggest thing that may affect folks is if they've declared their own DLL imports and are using Integer for handles.  So start using THandle and things should go much smoother (at least until I can get even more information about our own progress).  Other cases are in the Message crackers where the LPARAM is now an IntPtr since that param will now grow to be an Int64 on 64bit platforms.  Much of this work was scoped for the DeXter release (BDS2006), however since Microsoft never released a version of .NET 1.1 that works in 64bit platforms it seemed to be busy work for little benefit.  We decided to concentrate on more immediately beneficial things... like fixing bugs.  Now that we've turned our resources to bear on the .NET 2.0 platform, we've been dusting off some of this preliminary work (we did get some critial issues fixed in the compiler for DeXter that helps in this effort) and are now in full swing.

On a final note, let's all take a moment of silence for the loss of all that wonderful work late last Saturday.  The good thing is that we've been able to stop David I's machine from calling NORAD. All the black helicopters have left along with all those men in black suits.