Just a quick explanation for why there hasn’t been a new blog lately. I’m partway through a 3.5 week vacation on Maui. I have wireless & broadband out by the pool, but I can’t seem to find the time to blog.
An AppDomain is a light-weight process. Well, if you actually measure the costs associated with an AppDomain – especially the first one you create, which has some additional costs that are amortized over all subsequent ones – then “light-weight” deserves some explanation: A Win32 process is heavy-weight compared to a Unix process.
By default, old blogs are truncated from this web site. If you want to read old entries that have scrolled off, go to the CATEGORIES section at the right hand side of the web page. Select CLR (rss) and you’ll see the full list.
cbrumme 5/17/2003 6:56:00 PM
One of the suggestions for a blog entry was the managed memory model. This is timely, because we’ve just been revising our overall approach to this confusing topic. For the most part, I write about product decisions that have already been made and shipped.
The CLR’s type system includes primitive types like signed and unsigned integers of various sizes, booleans and floating point types. It also includes partial support for types like pointers and function pointers. And it contains some rather exotic beasts, like ArgIterators and TypedByRefs.
If there’s a topic related to the CLR, feel free to drop me a line asking me to talk about it. I have a very time-consuming day job and a full life outside of work, so expect a long delay before I address your topic.
In a comment to my last ramble, about asynchronous execution and pinning, someone asked for advice on using Windows impersonation in a managed application. Unfortunately, the managed platform currently has poor abstractions and infrastructure for controlling Windows identity, and indeed for most of the unmanaged Windows security system.
One thing we tried to do with the CLR and FX is provide a consistent asynchronous programming model. To briefly recap the model, an API called XXX may also offer an async alternative composed of BeginXXX and EndXXX methods. Even if the class that implements XXX doesn’t also offer BeginXXX and EndXXX,
The CLR has two different techniques for implementing interfaces. At first glance, it may seem like the choice between these two forms is a stylistic one. However, there are actually deep semantic differences between the two forms. Read this post to learn more.
The CLR type system supports both virtual and non-virtual instance methods. And IL can contain both CALLVIRT and CALL instructions. So it makes sense that IL generators would call virtual methods using CALLVIRT and call non-virtual instance methods with CALL. In fact,