There’s a subtle but important difference between protected access in unmanaged C++ and protected access (i.e. family) in the CLR. The difference is due to the CLR’s ability to build security guarantees on top of type safety.
One way you get this exception is if unmanaged code does an OS RaiseException() or causes a fault. If that exception is propagated up the stack to managed code, we will try to map it to a managed exception. For example,
We don’t expose the managed size of objects because we want to reserve the ability to change the way we lay these things out. For example, on some systems we might align and pack differently. For this to happen, you need to specify tdAutoLayout for the layout mask of your ValueType or Class.
People often ask how they can expose traditional DLL exports from managed assemblies. Managed C++ makes it very easy to export functions. And you could use tricks like ILDASM / ILASM to inject DLL exports into managed assemblies built with other languages like C#.
If the operating system schedules multiple threads against a hyper-threaded CPU, the CLR automatically takes advantage of this. This is certainly the case for new versions of the OS like Windows Server 2003. Also, the CLR did work to properly spin on a hyper threaded system.
#define BOOTUP_EXCEPTION_COMPLUS 0xC0020001
You may see an exception with this code, or an HRESULT of this value, when trying to call into managed code. This can happen if you call in before the runtime has finished initializing, or after the runtime has started shutting down.
By default, static fields are scoped to AppDomains. In other words, each AppDomain gets its own copy of all the static fields for the types that are loaded into that AppDomain. This is independent of whether the code was loaded as domain-neutral or not.
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),