PDC Panel: Looking Ahead to the Future of the CLR

I am super excited to get the opportunity to moderate the Looking Ahead to the Future of the CLR panel at the PDC..   While the panelist and I have some great ideas of what we could talk about, I’d love to hear your thoughts.  Where do you want to go with panel? What are you hoping to hear about?   

Comments (8)

  1. lexp says:

    It seems that CLR tends to be just a high-level wrapper of core windows api functions.

    Almost all new longhorn functionality is implemented as COM objects in native code. Managed code in longhorn is .net framework + indigo + avalon. Will ever new functionality in core windows services be implemented in managed code?

  2. One Angry Developer says:

    1) Startup time of managed apps sucks. When/how will CLR be mapped into OS memory, at startup, the way kernel32 et al are?

    2) Working set of managed apps sucks. When/how will JIT-compiled code be shared across processes?

    3) The versioning- and hosting-stories also suck. The SxS regime promised we’d never again have to worry about app compat, but reality is that only one CLR can be loaded by a process, so what about "apps" that aren’t top-level EXEs (like, shell addins or controls hosted in a browser)? Whidbey is breaking some apps like these!

    I guess all three of these questions are really the same: Is WinFX really the new API for Windows OS, or is it doomed to remain a big, leaky abstraction bolted on over the top of Win32?

    In the past decade, we’ve had two runtime environments: kernel-mode and user-mode. Now we have a third: managed code.

    I’m not one of these zealots who thinks device drivers will someday be written in managed code… but I *would* like to see user-mode go away, some day, in favor of safe, verifiable, leak-free managed code.

  3. Keith Hill says:

    Yeah, important issues are managed app load time (any potential for a "process" pool with the CLR preloaded), version hell and documented checked exceptions (vs enforced checked exceptions). I’m curious if there is any potential for hardware-assisted garbage collection.

  4. Apolon says:

    Some questions:

    a) What’s Microsoft’s current position on managed interception and Aspect Oriented Programming? i.e. the state of play, pre 2.0 approaches that maybe best to stay away from, new .NET 2.0 CLR features that may be useful in this area, future plans.

    b)Opinions on dynamic weaving i.e. ability to dynamically alter the IL in an assembly/class at load time. The Java platform supports this as part of the class load process. Can this be done in a .NET 2.0 CLR? Future plans?

  5. kfarmer says:

    I would be very happy to see the load time dealt with, as well as the problems of the CLR being swapped out. Talk to the Monad team for details of this phenomenon. The current (and unhappy) solution is to ngen everything ahead of time.

    AOP is already feasible through context bound interception; take a look at "Applied .NET Attributes". There’s a performance hit, however, so more direct support would probably be welcomed.

    I understand that features of Spec# are being considered for C#3 — would they be pushed to the assembly metadata, so that the CLR could inspect and enforce invariants where possible?

    Comments on this project, and whether collaboration between MS and the author could lead to the inclusion of its features in the CLR: http://u.pereslavl.ru/~vadim/MCSharp/

  6. JD says:

    OAD hit the nail on the head.

    Managed code is great for controlled-deployment and long-running process scenarios like ASP.Net and likely SQLServer Yukon.

    The working set, startup, and redist/dependency problems make managed code a BAD choice for most developers targetting consumers and knowledge workers, however.

    So the IT shop and some ‘shareware’ type of developers may be satified with .Net, but real hardcore developers continue to shun it. Whidbey improves somewhat on these problems but not nearly enough.

    PROBLEM: Since to amortize startup costs it’s best to have a long-running process, I’d like to do so. But hosting the CLR is the only reliable way to do so (AppDomains are not a real security/reliability option). And Hosting the CLR is hard; you need strategies for process recycling, exception management, etc. Chris Brumme is probably the only one making the documentation even understandable.

    I’d like to see .Net spend some serious energy on wooing the hardcore developers. The language and libraries are productive, now make it a viable option for someone to ship something.

  7. I second the AOP question. And mentioning context bound objects and interception is uncalled for. 😉

    Lots more can be done in the AOP space in the CLR, with the rich type info, etc available.

Skip to main content