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,
It’s been over two years since I blogged. Although I remain happily (perhaps even ecstatically) working at Microsoft, I left the CLR team and the Developer Division about a year ago. I’m now on an incubation team, exploring evolution and revolution in operating systems.
My original posts on Finalization and Hosting had some hokey XXXXX markers in place of content, where that content hadn’t already been disclosed in some form. Now that the Visual Studio 2005 Community Preview is available, I’ve gone back to those two posts and replaced the XXXXX markers with real text.
My prior three blogs were supposed to be on Hosting. Each time I got side tracked, first on Exceptions, then on Application Compatibility and finally on Finalization. I refuse to be side tracked this time… much. Also, I need to explain why it’s taken so long to get this blog out.
Earlier this week, I wrote an internal email explaining how Finalization works in V1 / V1.1, and how it has been changed for Whidbey. There's some information here that folks outside of Microsoft might be interested in.
I’ve already written the much-delayed blog on Hosting, but I can’t post it yet because it mentions a couple of new Whidbey features, which weren’t present in the PDC bits. Obviously Microsoft doesn’t want to make product disclosures through my random blog articles.
The PDC has happened, which means two things. I can post some of my (slightly self-censored) reactions to the show, and I can talk about what we’ve disclosed about Whidbey and Longhorn more freely. In this particular case, I had promised to talk about the deep changes we re making in Whidbey to allow you to host the CLR in your process.
I had hoped this article would be on changes to the next version of the CLR which allow it to be hosted inside SQL Server and other “challenging” environments. This is more generally interesting than you might think, because it creates an opportunity for other processes (i.e.
Usually I write blog articles on topics that people request via email or comments on other blogs. Well, nobody has ever asked me to write anything about shutdown. But then I look at all the problems that occur during process shutdown in the unmanaged world.
One of the recurring requests for a blog is related to TransparentProxy, RealProxy, Contexts, Interception, etc. As usual, I’m typing this where I don’t have access to our corporate network and the sources, so some details might be a little off.
I’ve been putting off writing this blog, not just because I’m on vacation in Maui and have far more tempting things to do. It’s because one of my blogs has already been used on Slashdot as evidence that Windows cannot scale and won’t support distributed transactions (http://slashdot.org/comments.pl?sid=66598&cid=6122733),