It's interesting, no, really, how the more things change the more they stay the same... I've been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port. In the DOS (actually Concurrent DOS, but...) version of the product I'd used structures of function pointers that the driver populated during…

I've spent some time over the last few days playing around with my CLR hosting socket server example. I had stalled on a piece of client work, I've got a bit of a head cold at the moment and my brain just wasn't in the right place for what I was supposed to be doing so I picked up one of more interesting the items on my todo list and took a look at that instead... The bulk of the work flowed nicely but then, just at the end things stopped working for no apparent reason... I'd done what was…

The work on the CLR hosting socket server example is going pretty well. I now have a server that can pass server notifications to managed code that either runs in an AppDomain per connection or within a single AppDomain (depending on how isolated you want the user code to be). I think I'm pretty much there as far as what I want to demonstrate is concerned; it works and the line between managed and unmanaged code is likely to vary depending on a client's particular requirements so there's little point in extending the example code any further. Hopefully I'll get…

My investigations into CLR hosting are going well and today I built an echo sever based on The Server Framework and my CLR Hosting helper library. The idea is that the server can deal with the network IO and then hand off the 'real work' to some .Net code. So far the integration is going pretty smoothly....…

Nice to see that the new beta, sorry, CTP, of the next .Net Framework will increase the performance of .Net sockets by 70%! Way to go .Net dudes.... Interesting to see that it's a joint effort between the System.Net people (who, I assume own the sockets code) and the CLR people (who own the platform)... I wonder what the CLR guys brought to the tuning table... It would be nice to know how the new (and existing) .Net sockets performance compares with the Win32 equivalent...…

Back in July Joe Duffy wrote an interesting piece on the CLR thread pool. I commented on it then, here. He's now written another piece about why they increased the maximum number of threads in "the thread pool" from 25/cpu to 250/cpu. Joe, I refer you to my previous comment... You're solving the wrong problem!…

This is mainly a reminder for me so that I can read this when I get back from Jackson Hole... Dino Viehland has written some interesting looking blog posts on how to implement the thread/task and syncrhonisation host managers for a hosted CLR. Note that this is all "Whidbey beta 1" stuff so, well, your milage may vary...…

I'm still playing with hosting the CLR in C++ (using "Customizing the Microsoft.NET Framework Common Language Runtime" by Steven Pratschner as my guide)... It's an interesting journey but, once again, I wonder who makes the important technical decisions at Microsoft and how they sleep at night ;) .…

I'm playing around with hosting the CLR in C++ at present and have come across a bit of crapness in the mscoree.h file... #if (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) typedef VOID ( __stdcall *WAITORTIMERCALLBACK )( PVOID __MIDL_0011, BOOL __MIDL_0012); #endif // (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500)…

Joe Duffy has written an interesting piece over on "Generalities & Details: Adventures in the High-tech Underbelly" about problems with the CLR thread pool. Joe's a program manager on the CLR team at Microsoft, so he knows what he's talking about! I find the issues that Joe raises interesting as I spent some time designing a flexible thread pool for my C++ IOCP servers some time go and came across the problems that he's facing. In essence the problem is that you want to allow the thread pool to grow and shrink based on demand but you don't want it…

So here I am, writing a piece about how the C++/CLI destructor and finalizer stuff could have been a bit neater and I put together some sample code to demonstrate my point and it doesn't do what the docs I mentioned yesterday suggest that it should do...…

Whilst I'm ranting about the little things... You still can't create named versions of the .Net ManualResetEvent and AutoResetEvent, even in .Net 2.0. Wasn't everything going to be fixed in Whidbey?…

Ted Neward has a very nice piece about the new language features in C# v3 and how they work together to provide something quite powerful. Go read it! Given that implicit typing, object initialisers and extension methods are all designed to allow LINQ to be a be able to generate classes on the fly and extend existing classes I'd still be happier if they could be optionally restricted from use on 'normal' classes to help prevent the less experienced running amok with these new language features and creating code that has interesting maintenance properties...…

Having looked through the slides that Vagn pointed me to in a comment to my recent post about C# v3.0 Extension Methods I can understand, a little more, about the reasoning behind the change to the language. Given that the C# v3.0 spec contains the following warning: "Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible. Extension members of other kinds, such as properties, events, and operators, are being considered but are…

There's a lot of noise coming out of the Microsoft PDC right now. Something that interested me was the future direction of C#; you can grab the spec from here. It seems they're adding "extension methods" which, to me, appear to be just syntactic sugar to make up for the lack of free functions...…

I've been merging my UDP framework development branch back to main, building all of my example servers and running all of the "black box" server tests for The Server Framework. In doing so I've experienced the pain of changing virtual function signatures. This is one area where C# syntax is definitely better than the C++ syntax...…

I have some code that launches another process in a suspended state, does some stuff (tm) and then resumes the process. This uses CreateProcess() and works fine on unmanaged exes. When I try and launch a manged exe with the same code the process starts up in a running state rather than in a suspended state. The docs for CreateProcess() don't mention any strangeness. Does anyone know of any docs that explain what's going on?…

Jeff Atwood has a nice piece on the productivity of different programming languages (go read it). His sums up with the following: Given .. 1). the abandonment of C++ and C for mainstream programming 2). the huge influence of individual programmer skill 3) the slow but steady adoption of scripting/dynamic language conventions in Java and .NET .. maybe all modern programming languages really are the same. Ole Eichhorn has already taken Jeff to task in the comments about his definition of mainstream, and Jeff has responded here so I'll leave that one alone for now ;) Several people picked up…

Geoff Appleby discovers that a common C++ template idiom doesn't work with .Net generics. The code that doesn't work is this: Public Class Class1(Of V As System.Web.Services.Protocols.SoapHttpClientProtocol) Inherits V End Class which is the .Net generics equivalent of this common C++ idiom: template <class base> class TDerived : public base { }; This is useful in all kinds of situations, as Christopher Diggins explains and, as Geoff says: "You don't know if V is NotIneritable, MustInherit, or whatever. It would surely fail at compile time if that happened" which is fine. Failing at compile time is great and means that…

So, Richard Hale Shaw is helping us move away from C++ and in his latest posting on the subject he explains how "veteran C++ programmers" don't like to manage memory themselves; hmm. I'd quite like to see his sample data. Especially as he then goes on to define "veteran C++ programmers" as people who don't like to manage memory themselves...…

There's a rather disappointing article on .Net sockets in this month's MSDN magazine.…