18 July 2017

History, Future Plans, and Common Controls

Progress Bar
See the first post on Common Controls here

A Little History and Future Plans

Every developer has this experience more than once: you build a component, go open source, or even buy to get it almost right.  You tweak it to meet the requirement at hand, and then you move onto the next problem.  All the while, this nagging in the back of your mind is telling you that “you could have done better, made it more extensible, more aesthetically pleasing.”  That’s over engineering if you try to make all of those things happen when other tasks remain on the critical path and you have met the requirement, especially with a paying customer--without their permission, that's downright unethical.  Still, and I think this is so for all of the good developers I have come across, there is a natural desire to perfect your craft, make it beautiful, and make it stand the test of time.

I wrote my first piece of commercial software when I was in high school and many apps before that,  used by friends primarily.  I believe I was about 11 I wrote my first useful piece of software. These apps were MS DOS apps written in Pascal or QuickBasic. The inner core of the application was a big loop that painted the ASCII characters that were used back then to create frames, menus, inputs, reports, and whatever else you did on the screen. The loop received user input, forked off to perform various tasks like reading or writing data to a floppy drive, and then came back and start painting the character-based UI to update it based on what occurred in the subroutine.  

 For those of you who weren't there to do this kind of development, you may wonder what all the weird characters in the DOS character page (see image from Wikipedia below) used for.  Those characters, my friends, were the building blocks of MS DOS applications that went beyond just standard letters.  You were quick to learn these codes and the algorithms for drawing and updating boxes, centering text in the boxes, making the box appear highlighted, etc.  A little like CSS these days--just a little, in the sense there were a ton of tricks you could master to make the app look good.

box characters

At that point in computer history, there was no such thing as a GUI available to a little kid writing code on his TRS 80 in his basement. But that inner loop that looked a whole lot like a message loop in Windows, so the transition to Windows development was not a big deal. Plus, I switched to a much less verbose and lower level language--C.  Back in those days, there were few “controls” or much of anything to help create a functioning Windows application. You built your menus and dialogs in resource files and manipulated these objects directly. You had a heap to tend to with care, or you would leak like a stuck pig. There were the standard libraries available and the Windows headers to include to give the linker the data it needed and the macros you needed to make Windows programming possible. But it wasn’t that hard. It was labor intensive.

EnteEnter MFC with C++. This combination was freedom from the slavery of the message pump (well, sort of) and handed a shortcut or a wizard to perform all of those menial jobs you had to deal with before. Everything was good.

Enter OLE, COM, and DCOM. Back to everything being hairy and incomprehensible at first, but after a while that too became comfortable. The problem was the platform, runtime, and languages kept changing so the idea of making the last thing you did even better seem a little bit ridiculous because who knew what was coming out of Redmond next.

Well, that was VB 6.0, which we will skip, so I don’t have vicious flashbacks.

EnteEnter .NET.  I was at the PDC event in Florida when they announced it.  I remember thinking “Oh great; we are starting all over again.” And we were, to some degree.  I took the huge stack of DVDs (or were they CDs?) back to my hotel room and wrote my first "Hello World" in C#.  It felt like C.  I had been doing VB.NET.  I was frigging ecstatic!  The base class libraries, even in 1.0, were so wonderful in comparison to Visual Basic.  I almost called home to tell my manager that I was in love.  Thankfully, I didn't.  That would have been embarrassing for the both of us.

.NET has survived and thrived and will remain for many more years, if not decades, so now the idea of building a library of reusable, better engineered, better looking components seem reasonable. C and C++, and even MFC remain and are updated, but as a platform, managed code has punctuated Microsoft’s strategy from its inception. I remember thinking “this is for real” when SQL Server implemented a managed host inside the SQL engine. That’s no small feat and means a level of commitment. Now, with Azure, Office Online, and just about everything else coming out of Microsoft these days, it is either language agnostic (finally, Microsoft has decided that OPT—Other People’s Technology—is useful), .NET (C#, VB.NET, F#, and 20+ others implemented by others) or JavaScript.

I have been writing software for just about 25 years—and I still have the desire to perfect my craft, learn more about the subject, and keep fresh.  I spend several hours a week on Channel 9 (MSDN), YouTube, or my Kindle reading, listening or watching things about my craft.  Yet, it seems, a challenge for anyone who has been doing software for this long that there will be a particular technology that you end up specializing in. For me, there are two—back-end services, which is wonderful because it involves a great deal of diverse technologies, and Windows development.  I still love Windows development.  It's where I started.  I got to meet guys like Don Box and Charles Petzold when I worked at Microsoft. I have exchanged emails with various luminaries throughout the years, including Steve Jobs (yes, that Steve Jobs--he didn't do Windows but he was from that world too), Mark Russinovich, Dave Probert, and others.  A close friend of mine built HTTP.sys and helped invent various pieces of Windows you all use, plus holds a bunch of patents at Microsoft.  I came from Microsoft, practically born of its culture (original culture), and will always love Windows.  A small window in my nerdiness in this subject is that I am book two (not chapter two, BOOK two) of Windows Internals 6th edition, with the 7th Edition queued up on my Kindle.

Windows was cool and damn the haters, it still is.

But things are always changing in my industry so over the past couple of years, I have gathered what I know about Windows development in the managed world and started the ShibumiWare Stack  Aside from adding fresh content when I learn something new on the job, fixing bugs, and maintaining it, I am moving on to other topics as my primary focus—with services and other “plumbing” always being my other favorite. I see in my future much more web development, mobile development, machine learning, cryptography, system’s integration, and others. Microsoft Dynamics is going to be a big part of what I do. I will always love to do Windows development when called upon to do so, but on my 25th anniversary as a developer, I am going off to focus on other Microsoft technologies.

So What's Next with the Common Controls Series?

I plan on completing the series on Common Controls, which I figure will end up around eight to ten posts.  There is a lot of I have done and many tricks I will share along the way. 

Something to Keep in Mind

There is exactly zero code in the stack that I had to purchase.  I spent maybe 6 years doing Windows development using DevExpress and loved it most of the time.  I missed it when I wanted to do hobby projects that looked great but no way was I going to pay thousands of dollars.  I realized through that experience that with a little (or a lot) of work a dedicated developer can make standard Windows development (versus WPF) look very nice indeed.  The time I spent doing "raw" Windows development helps because I know deep down in that really cool looking component, there is just Win32 and Windows development techniques.   So it doesn't overwhelm me easily.

What to Expect in the Next Common Controls Post

I think I have written a login dialog about 20 times in my career so I took all I learned and ever needed and built a credentials management framework with a common dialog that is a shape-shifter of sorts.  Its object model is programmable to allow for themes, different kinds of user names (email address, domain credentials, and others), password complexity options (and UI components that visually tell you if you are meeting those requirements), options for remembering credentials with full encryption, profile management, web content to explain the login process, and other goodies.   It has extension points for providing your own crypto implementation via interfaces.  Various UI components can be made visible or hidden depending on your needs.  It is about as complete as I can make it. 

That post is forthcoming, but I have a lot on my plate right now so I cannot tell you when.


Thanks for staying tuned!


04 July 2017

Happy 4th of July 2017

Colby & Parker

Quality Nerd Time Together

My son and I collaborated on this video--the first time for both of us combining music, video slices, and images into a single video.

We used Audacity, GIMP, LAME, and Microsoft Encoder.


And Here is our Masterpiece...

Everyone have a safe and happy holiday!