Scott Hanselman said it all.
Threadsafe Events article at CodeProject explains problems one might encounter with .NET events in a multithreaded environment (not necessarily stating the absolute truth but still). Unfortunately, no-one has figured out the perfect solution, and we will have to choose “the best from all bad solutions” for some time still.
Asynchronous Callback Contexts article by the same author shows possible solution for event cancellation, particularly during object disposal: end-users do not expect components to raise events after they have been disposed or after they have unsubscribed from these events. The author refers to his Nito Asynchronous Library as a way to solve this issue.
A “healthy set” of Win32 and C++-related links (related stuff, anyway):
- MVP Tips, Techniques, and Goodies by Joseph M. Newcomer has a lot of C++ and Win32 topics, covering all “gray” areas like asynchronous operations, synchronization, threading, memory leaks, optimizations, various Windows APIs, device drivers, etc. For example, there is An introduction to memory damage problems that goes thoroughly through the topic, or absolutely fantastic The n Habits of Highly Defective Windows Applications that nicely enumerates ugliest “no-no’s” one should avoid in his code if he wants to sleep well :)
- C++ In Action, book by Bartosz Milewski. Cool thing is that there is a web edition of the book. Additionally, on the C++ Resources page there is Windows API Tutorial, RSWL: Free Windows Library, and some other papers and presentations, including topics on Resource Management, something called auto_vector ;) , and rather interesting Dealing with Software Complexity presentation.
- Win32 samples has a lot of samples for Net*() APIs, as well as for LSA, NTFS streams, processes, security
Found TCP: Buffer Management and related Async Sockets and Buffer Management and Async Sockets and Buffer Management [CTD] articles on Greg Young’s blog. These articles describe the problem and show the solution:
When you call BeginReceive/BeginSend on a socket, the memory that you pass to the method will be pinned for the duration of the call. This will lead to heap fragmentation and to make matters worse it will often be in your gen0 heap if you aren’t careful. This becomes especially true in the most common socket applications (request/response) as BeginReceive is often called and waits for a long time to receive data (by long time I mean a few seconds or more).
The blog itself is interesting on its own.
Detours is a Microsoft library for instrumenting arbitrary Win32 functions (by Microsoft Research), unfortunately not free. There is a paper Detours: Binary Interception of Win32 Functions by Microsoft guys. In addition, there is API Hooking with MS Detours article on CodeProject.
Then, there is EasyHook – “The reinvention of Windows API Hooking” as they say themselves – which allows to hook APIs from managed code and write managed detours. This one is free, and from what is there it looks even more interesting than Microsoft’s Detour. And there is also a related CodeProject article.