Recently I ran into a situation where it was desirable to have a program that ran and was visible on the Windows lock screen. Under ordinary circumstances this is something that just shouldn't be done. The Windows lock and logon screens are... sacred, in a sense, and displaying something on those screens is both a usability and security no no. That said, it's still possible to do and in unique situations it may even be the right solution. Plus, it was an interesting research exercise.
In my case, the machines that needed a program displayed on their lock screen were being used to drive the display of LCD screens for communication purposes. They would never be touched by a human, and in fact the purpose of running the machines on the Windows lock screen is to prevent tampering. This led me to investigate the feasibility of having a program display on the lock screen and eventually a working implementing written in C#.
Ultimately, I decided to implement a different set of security protocols to prevent unauthorized access to the machines, but nevertheless I figured I'd share my research here. Let me reiterate: please carefully consider whether it is necessary to display a program on the lock or logon screens, as Windows is specifically designed to prevent programs from doing so (think of what a pain a malicious program could be). Done considering? Well then read on!
When I started this blog, I told myself that I'd be updating it every few days, or at least once a week. I said once a month at the absolute worst. Who would have thought it would be a whole year? Not posting any updates for a year is how not to write a blog.
I'm going to change the way I go about writing. I'll be focusing more on brief postings on a specific subject, such as a programming technique or bug that needed fixing. By writing shorter posts, it should be easier to write more often.
Even though I haven't been updating my blog, I have been working on this or that. A lot of my effort has been spent on IRC Tools, my framework for .NET that will make writing IRC bots and clients a breeze. That's the goal anyway, hah.
What have I been working on and what do I plan to work on?
The IRC protocol is infested with annoyances. One of these is parsing the messages sent to the client by the server. This is a problem I needed to solve when developing IRC Tools. Without a proper parsing mechanism, the entire set of libraries would be completely useless. How did I do it? Read on!
Today at 1:30 EDT was the IE9 keynote video. It was interesting to finally see some of the browser features rather than the being stuck with the technical previews. I find myself having mixed reactions to the tone of the video.
From a technical perspective, IE9 is a huge leap from IE8 and the IEs before it. This very blog, for example, now looks the same across all of the most recent browser versions. Many in the web development community weren't sure we would ever see the day.
So apparently I've been busy lately and haven't moved beyond the "infant blog stage" in my blog life. Lucky for me (and you too?), some of the things that have been keeping me busy are relevant to this blog. Recently I've been putting a lot of work into IRC Tools, specifically the client library.
The core of the client library is there and working (parsing messages, handling them, and sending commands). Currently I'm implementing various classes to handle different incoming message types (e.g. the MODE message, or various numeric replies) and classes for outgoing commands. While working on these classes, I've come to the conclusion that the IRC protocol is terrible. It is vague and inconsistent, with different server implementations often creating contradictions in the way certain circumstances should be handled. Let's proceed with a small example.
