Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » Design » ICorDebug   (RSS)
Wednesday, August 30, 2006 11:40 PM

An example of an API versioning problem.

Here's an example of an API versioning problem. In general: Anytime you take two separate concepts and tie them together based off some current implementation assumption, you're going to get trouble when that assumption is broken. The specific example
Posted by jmstall | 4 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
Wednesday, January 25, 2006 11:06 AM

What to do with a feature that only works 90% of the time?

Imagine when you're designing a feature if there was an operation that was very useful 90% of the time; but the other 10% of the time it was provably and innately unsafe (either crashed, deadlocked, or gave back garbage). By "innately unsafe", I mean
Posted by jmstall | 1 Comments
Filed under: , ,
Monday, August 01, 2005 12:13 AM

Simple example of an API design flaw.

Here’s a simple example of an API design flaw in ICorDebug. (ICorDebug is the API that Visual Studio / MDbg and other debuggers use to debug managed code). Here’s the background knowledge: 1) When a thread first executes actual IL (whether jitted or ngenned)
Posted by jmstall | 3 Comments
Filed under: ,
Tuesday, July 26, 2005 1:27 AM

Source-level step-in is not well defined.

One of the things that causes us grief is that source-level step-in (F11 in VS) is not a well-defined operation. Some examples : Consider the following call to static method foo: MyClass.foo(...); Now offhand, you'd expect the step-in to land in the method
Posted by jmstall | 3 Comments
Filed under: ,
Sunday, February 27, 2005 2:55 PM

Don’t do “complicated” work in Release().

BradA has been talking about API design guidelines, which reminds me of a bunch of subtle API design lessons we’ve learned from mistakes made in ICorDebug. I’ve started a list and it’s depressingly long. As I blog about these, I’ll pull samples from ICorDebug,
Posted by jmstall | 9 Comments
Filed under: ,
Wednesday, February 23, 2005 6:18 PM

Debugging any .Net language

The CLR is a cross-language platform, so it follows the CLR-debugging services are also cross-language. This means any 3 rd -party can write their own managed debugger, and that can debug any managed app produced by any 3 rd -party compiler. (This holds
Posted by jmstall | 5 Comments
Filed under: ,
Friday, January 28, 2005 12:24 AM

What is Interop-Debugging?

(This is an excerpt from an internal document I wrote explaining what is Interop-Debugging (aka Mixed Mode) and how does it work under the covers) General Debugging background. When a process is being debugged, it generates debug-events which a debugger
Posted by jmstall | 9 Comments
Saturday, October 02, 2004 12:51 PM

"Rocket Science" API?

Let me just say it and make sure we're all on the same page here: We made a lot of mistakes in v1.0 of ICorDebug. One such mistake was we frequently called ICorDebug a "Rocket Science" API. IMO, we figured that anybody writing a debugger must be a super
Posted by jmstall | 1 Comments
Filed under: ,
 
Page view tracker