Curly Brace Coder

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,