Welcome to MSDN Blogs Sign in | Join | Help

February 2006 - Posts

Wednesday, February 22, 2006 10:46 AM

How bad threading design affects the user

I can't help but notice awful threading designs manifested in some apps (which will remain nameless). Here are some random grievances I have with these apps: 1. Don't block the UI thread, especially not on file or network access . When you block the UI
Posted by jmstall | 12 Comments
Filed under:
Tuesday, February 21, 2006 2:57 PM

The cost of context switching

If you think context switching activities is cheap, then just try saying two sentences; and then try interleaving those two sentences. For example, I can say "I like kites" and "puppies are cute" in under 2 seconds. But to interleave them ("I puppies
Posted by jmstall | 2 Comments
Filed under:
Sunday, February 19, 2006 11:45 AM

Should multiple instances of an app share the same process?

I have a grievance with some programs that host many separate instances (main windows) hosted by a single process. On the plus side , you can get some good perf wins from this. One process can host many windows. (I think of this as the evolution of MDI
Posted by jmstall | 1 Comments
Filed under:
Friday, February 17, 2006 10:34 AM

Modules vs. Assemblies from the managed debugger's perspective

While managed assemblies may be very interesting from the loader and deployment perspective, they don't really have much interesting for debuggers. The debugger is far more concerned with modules: - the key debugging functionality is associated with modules.
Posted by jmstall | 2 Comments
Filed under:
Thursday, February 16, 2006 2:02 PM

IFEO and Managed-debugging

Be careful of Image File Execution Options (IFEO) with managed debugging - it won't work like you expect. IFEO lets you set some registry goo such that when you launch a target app (specified by a registry key name), a debugger (specified by a string
Posted by jmstall | 7 Comments
Filed under:
Tuesday, February 14, 2006 1:00 PM

Sample Mdbg extension

Here is a template for playing around with an extension for the MDbg sample (Mdbg is the managed debuggeer written in C#). It adds an "Addition" command to MDbg that adds two numbers. Not very exciting, but it shows the plumbing. You can download the
Posted by jmstall | 4 Comments
Filed under:
Monday, February 13, 2006 12:13 PM

When can't you do Edit-And-Continue?

In .Net 2.0, we wanted to focus managed Edit-And-Continue (EnC) resources on the core-scenarios so that we could make those as good as possible. One significant resource was testing: if you think about what it means to really test EnC, you can probably
Posted by jmstall | 7 Comments
Friday, February 10, 2006 7:38 PM

Living with the consequences.

Sometimes we think we can make a decision, but it turns out the decision is already made for us by the consequence of earlier choices. Mathematics is filled with great examples. One of my favorites is: e πi = -1 (that's e^pi*i == -1). (See proof from
Posted by jmstall | 0 Comments
Filed under:
Thursday, February 09, 2006 4:00 PM

Passing Property values by reference

I was wondering how well properties were integrated into C#. For example, C# lets you use += with the properties. It's easy enough to convert: MyProperty += 4 to MyProperty = MyProperty + 4 However, C# won't let you pass a property in as a ref parameter.
Posted by jmstall | 16 Comments
Filed under:
Thursday, February 09, 2006 10:40 AM

TV Reruns (past the 200 mark)

My TV-savvy friends tell me that there's some magic number of TV episodes that means you finally have enough unique episodes to viably show re-runs. I wonder what that number is for blogging? I bet that some of those high volume bloggers could probably
Posted by jmstall | 5 Comments
Filed under:
Thursday, February 09, 2006 12:15 AM

ICorDebug failure codes

ICorDebug has many different ways of saying "failure". The full list is everything that starts with "CORDBG_" in CorError.h. There are a lot of very specific HRs to describe specific scenarios. For example, CORDBG_E_IL_VAR_NOT_AVAILABLE will tell you
Posted by jmstall | 0 Comments
Filed under:
Wednesday, February 08, 2006 10:47 AM

About CORDBG_E_OBJECT_NEUTERED

Sometimes ICorDebug APIs will return CORDBG_E_OBJECT_NEUTERED. If you're using MDbg, COM-interop will convert this to throwing an exception. This means that the object is "logically dead". Since somebody is holding an outstanding reference to it, we can't
Posted by jmstall | 5 Comments
Filed under:
Wednesday, February 08, 2006 1:37 AM

Design Implications from boring details

You can discern a lot of information about an API from what appear to be subtle or irrelevant details For example, each ICorDebug object has a logical parent. (See here for a brief explanation of the different ICorDebug interfaces). Here's a chart: ICorDebugProcess
Posted by jmstall | 2 Comments
Monday, February 06, 2006 11:28 AM

Impossible vs. Insufficiently Clever

I find people will often say something is impossible, when really they just aren't s mart enough to figure it out. Physicists (and the Discovery channel) love pointing this out about time-travel: No law of physics, except for perhaps the law about increasing
Posted by jmstall | 11 Comments
Filed under:
Friday, February 03, 2006 12:52 AM

Viewing the current Exception in the debuggeer

VS (and mdbg) expose the $exception pseudo-variable which shows you the most recent exception. (kudos to Shaykatc for mentioning this a year ago). Debugger authors can implement this with: HRESULT ICorDebugThread::GetCurrentException([out] ICorDebugValue
Posted by jmstall | 1 Comments
Wednesday, February 01, 2006 1:00 PM

Random ICorDebugThread trivia

Here's random information about ICorDebugThread that I hope eventually makes it into MSDN: 1. The managed CreateThread callback comes at the first bit of managed code that a thread runs. (I think this is a bad for these reasons , and instead it should
Posted by jmstall | 5 Comments
 
Page view tracker