|
 |
13 May 2004 |
|
This blog has moved to here. RSS feed is here. If you go there you can read all about how a simple and common line of code can stop the CLR inlining a function in your applications, and how to get around it.
What other blogs are saying about this post.
6:53:54 PM 
|
|
|
12 May 2004 |
|
10 May 2004 |
|
Right, now that I have a working C# wrapper for the CLR debugging APIs I can finish my next article and release this wrapper to the world. The number of people who ask me about writting debuggers in C# each week is remarkably high (I'm mad. What's your excuse for wanting to write a debugger?) so this should help them get past the wonderful array of problems that you can hit writing them from scratch. I'll only have a few hours to work on it this week though, so expect it next weekend unless I end up waiting hours for tests to run at work this week (a data recorder with 80Gb of storage and a high data rate still takes a an hour or two to run, and even longer to prove that every data sample is correct). Speaking of the day job, I fixed a bug that was seriously hurting our performance (although we were still running 99.9% of the time) and so I'm now pretty confident that I could have implemented my current embedded XP project under .NET if I had wanted to. This is an interesting development because there were a few problems we got on this project that came from C++ letting errors compile because they were technically valid code, but C# would have picked up most of them.
What other blogs are saying about this post.
12:53:18 AM
|
|
|
I know my PC's installation is slightly wonkey (I'm holding off reinstalling until I get around to buying a nice 10k rpm sata drive or two) but I seem to have lost all my ExitProcess notifications from my debugger. What's more they're missing from all of my sample code from my articles too. The question is did I miss that problem when I was writing them, and if so what am I missing that stops it happening or is my PC just in a much worse state than I thought? OK, all the other debuggers I have still work. Somebody please tell me where my bug is, it's driving me nuts.
What other blogs are saying about this post.
12:07:10 AM
|
|
|
09 May 2004 |
|
My current debugger framework has problems when running under a debugger. Since this has always worked before there's obviously something I'm doing different that I don't currently understand. I'll post the article that uses it when I've figured out what that is.
What other blogs are saying about this post.
1:18:58 PM
|
|
|
08 May 2004 |
|
07 May 2004 |
|
I have some really interesting situations where I'm managing to crash the CLR debugger at the moment so my fabulous way of demonstrating breakpoints mainly demonstrates how to get interesting errors at the moment. Hopefully I can get that sorted this weekend, but in the meantime there are lots of new errors for me to see. The other thing I'm doing this weekend is ditching Radio for .Text. It's about time that I used ASP.NET on my own website and I can't do that with my current hosts. I'm totally happy with their service in every way except for the lack of .NET thing but I need a few web apps and I really don't feel like using PHP when I renounced my Unix ways years ago. The move to .Text will not be perfectly smooth as I've got to keep the RSS feed linked and come up with a way to keep all my old entries as well without breaking any permalinks out there. Then again I could just say screw it and zap them. It's not as if I have many profound statements of truth that need to be preserved.
What other blogs are saying about this post.
11:52:01 PM
|
|
|
05 May 2004 |
|
Here's an interesting addin for you that's been posted to GotDotNet that integrates the very useful PInvoke.net site into visual studio so that you can easily find the signitures that you need, or more importantly the framework API call that you should be making instead if calling through into WIn32 land. This add-in for Visual Studio (7.0 or later) communicates with www.pinvoke.net, making it easy to copy signatures and types from the PINVOKE.NET repository into your source code. It also highlights alternative managed APIs that help you avoid PInvoke altogether, and makes it easy for you to contribute your own signatures and types! Because the latest information in the repository is displayed, the number of signatures and languages supported should grow over time. This also means that an Internet connection is required to make use of the add-in (although it behaves gracefully when no connection is present). Defining PInvoke signatures (also known as Declare statements in VB) without any help is an error-prone process that can introduce extremely subtle bugs. It's time to stop writing PInvoke signatures from scratch! Instead, copy and paste your way to productivity! Think of this as the 21st century version of VB6's API Text Viewer. For more information, visit www.pinvoke.net.
What other blogs are saying about this post.
9:52:45 PM
|
|
© Copyright 2004 Jon Shute.
|
