Curly Brace Coder

My very first programming 'language' was Z-80 assembler, even before I had learned to program in interpretive BASIC. So you would think I would be used to doing things the hard way, used to pain... =P When I first saw the C language, I fell in love right away. I already had several CPU dialects under my belt, and the idea of pointers was already an easy notion to grasp -- I had already been using VARPTR in BASIC. The idea of a language that was graceful, provided native pointers, language constructs, NO LINE NUMBERS, who could ask for more? Then came C++. Well, not exactly. My first exposure to C++ was via the Glockenspiel "compiler", which was really a glorified C preprocessor. No matter, eventually Borland and Microsoft released C++ compilers, and I never looked back. Until around 2000, when Microsoft released .NET and C#. By this time, we had COM/DCOM, the STL, and boost. Writing custom allocators, IUnknown for custom COM objects, RAII patterns

One of the more difficult problems when trying to synchronize across threads and processes on Windows is not only choosing the right kernel object, but also constraining the lifetime and signalling context of said same object(s). Lets suppose we have an GUI application (which provides us with your typical potpourri of threading and synchronization context issues), and a console monitoring application with which we want to communicate some event. Lets suppose further that our GUI application will be running many background threads, any of which will actually be the thread which will need to signal the monitoring console process. It would look something like this: Immediately several issues arise: 1. The mutex object would have to be created on a separate thread in the process so as not to block the main foreground thread (more on this later). 2. The mutex object must  be signaled on the same thread that was used to create it! There are two approaches that can be taken to

"They say time is the fire in which we burn" It started out as a simple request... add a page to a custom embedded WPF application that will allow the user to set the date/time directly from the application. Seemed simple enough. I created the following screen (only a portion of the screen is shown below): Now, for better or worse, I do a large majority of my development on Windows 7 machines even if the target is a Windows 8/10 machine where the application will be deployed. In general, what works on Windows 7 usually  works on Windows 8/10, or so you would think. This works on Windows 7, but as you would expect, it fails on Windows 8/10. We get back the dreaded E_NOACCESS. Even running as Admin under the BUILTIN\Administrators group with UAC off, we still get the same thing. Time to do some Google searching. A quick search reveals posts on StackOverflow and MSDN that our user requires privileges to change the system time. That actually makes sense,