Joe White's Blog Life, .NET, and cats

Danny's .NET 2.0 talk: Part Two #Delphi #borcon2004

Covering Danny Thorpe's preconference tutorial on .NET 2.0. This is the second of two parts (the first is here).

Nick was blogging Danny's talk during Danny's talk. Either he found an outlet, or his laptop has waaay better battery life than the one I've got. So his blog entry is also worth a read.

Okay, picking up more or less where I left off before the bio break:

  • POGO (profiler-guided optimizations)
    • Why it matters: 64-bit processors have a big penalty for branches (lookahead and all that). POGO tests the app under real use, and if one branch is called 10x more often than the other, it changes the emitted code to adapt. Might even move code around to keep the most-common stuff together.
    • Will only be available for Managed C++ (it's not clear why)
    • MS won't license it out, so Delphi is out of luck (and so is C#)
  • Pointless side note: The Delphi/Win32 compiler has a NativeInt type. Don't use it. It's going away.
  • Delphi for .NET will support 64-bit processors, but VCL for .NET does not
    • In 64-bit, OS handles are 64-bit
    • There's still some code in VCL that has them as Cardinal
    • As part of the fix, compiler will probably add warnings if you try to assign a handle into a Cardinal or an Integer, so third-party code can be fixed easily
  • .NET 2.0 will have TryParse methods (hooray!), because Yukon (a) doesn't like the overhead of exceptions, and (b) reserves the right to terminate running code if it throws any exceptions at all!
  • Note about CLR hosting: Load the runtime once into your process, and it sticks
    • So you'd better know which runtime version you want when you start up
    • Other notes: Host can remap assembly bindings (ask for Studio -> remap to a request for a D8 assembly)
    • In 2.0, memory allocations will go through the host first, then the OS (because Yukon is really its own OS: it allocates all available memory, sub-allocates it to the CLR, and uses everything that's left for various forms of caching)
    • In 2.0, exceptions also go to the host first (because Yukon wants to be able to terminate immediately if certain bad exceptions happen)
    • In 2.0, threading goes through the host (because Yukon doesn't use threads, it uses fibers)
  • Diamondback = .NET 1.1
  • There will be a 2.0 Delphi release in the Whidbey timeframe
  • On generics and Win32:
    • Reeeeally don't want to codegen Win32 code at runtime
    • Generics may exist with restriction that T must be an interface (or maybe a class)
    • Don't know whether generics will be in first 2.0 release
  • The Whidbey-timeframe Delphi compiler may not support iterators or partial classes for Win32
  • ASP.NET 2.0:
    • Provider model: "I am your login genie — if you need login services, cookies, etc., come to me"
    • Web Parts: customization a la My Yahoo!
    • Master pages (hell, I was doing this back in 1.0, with a UserControl for the page header, another for the page footer, and a handler in Global.asax to insert them into every page)
    • Editorial note: ASP.NET 2.0's code-beside model will make a lot of users very happy, because they'll no longer be forced to make all their fields protected (and get yelled at by FxCop).
  • Yukon doesn't like static variables
    • Each request should be isolated from the other requests
    • Static variables also introduce opportunities for memory leaks
    • Problem: all Delphi-generated code has static variables, because that's how class types are implemented
    • Need to relax this rule in Yukon in order to use Delphi code
  • Yukon will only support .NET 2.0, not 1.x (not surprising, given that most of 2.0 was a drive to make .NET meet the standard set by the Yukon team)
  • Compact Framework in Diamondback
    • It should work, but you may need to use the command-line compiler
    • Unless a miracle occurs, there will be no designer, because MS's designer is still screwed up and not ready for release
    • Delphi 8 won't work in CF because of the way Delphi tries to ensure deterministic unit initialization order (calls RunClassConstructor, which doesn't exist in CF)
    • Diamondback will try to load that method, and if it doesn't exist, will still let the app run (but won't guarantee unit initialization order)
  • As reported recently, .NET 1.1 SP1 breaks Delphi 8. Danny anticipates a fix by next week.
  • mscoree.dll
    • Every managed app has an unmanaged entry point that calls mscoree.dll, which looks at your EXE, loads the right CLR version, and sends you on your way
    • There's only one version of mscoree.dll on your system at a time (not much other way for it to work)
    • Bug to note: When you install .NET 2.0 beta, it overwrites mscoree.dll (no problem). When you uninstall, it does not put the old mscoree.dll back (problem).
  • .dcpil, .dcuil files have references to the Framework, and are therefore not platform-portable. To use D8 with .NET 2.0, you first have to recompile the D8 RTL.
  • GC note: Each thread has its own heap, so there's no thread contention for the heap. Interesting.

And there you have it. Much info, much trivia, and I didn't blog the stuff I wasn't interested in, but this should be of some interest to the folks back home. Share and Enjoy.

I have another three pages of notes about John Kaster's talk about Diamondback, but I'm going to go get some food, and blog about his stuff later. (I will write about it later; whether I blog about it tonight or tomorrow depends entirely on wirelessness.)