My answer is sort of yes and sort of no. The application I am creating is intended to be a "real" or professional level quality UWA app, but it is primarily for my own purposes. I will probably put the bulk of it on github when the time is right. I have messed with/customized a number of the starter apps, and been satisfied with my results so far, but I am finding the transition from sample app to fully fulfilling the requirements for a store-worthy app to be REALLY poorly documented. I remember going to a user group at the local Microsoft office early in the Windows 8 era, and hearing pleadings from several people about "it is not that hard", and "you should really do this" but, now, as with then, I reach a particular point, get a number of "bzzzzt, that isn't right" messages, and move on with life because quality explanations for why don't even exist in google searches. "You should ask"? I move on with my life if I have to wait that long for an answer...

Call me a nice guy who generally gives people the benefit of the doubt, but this looks like code where someone INTENDED for some operations to occur on separate threads asynchronously, put some of the plumbing in, put a thread.join in for synchronous debugging, and never got back to it. You are correct in that the code would be more performant without creating the additional thread as they presently are, but the context of the usage is also important in determining your predecessor's intent. If GenerateTimeLineImage() is a void function that is basically a "fire and forget" service call, commenting out m_thread.Join() might increase application performance, and by quite a bit. I'll tell you that there is no hidden magic, but you haven't provided enough context for me to be as condemning as some other folks here.

I am also in Arizona, and my favorite part about DST is that most of the college football I like to watch (CDT and EDT) starts fairly early in the morning and ends with early enough that there is still a lot of the day left (well at least for 2/3 of the season) :-D

There are a lot of things that make VM hosts a "six of one, half a dozen of the other" proposition. I have generally preferred VMWare Workstation, as it is not "terribly" expensive, and find that it does, in fact, perform the best. I have been using it since v2(??? OK, a long time...). The main issue I have with it is that to get the best performance, you install extensions on the virtual machine that, unless fairly recently changed, cannot go to other VMWare platforms, i.e. ESX, ESXi, without some pain. OK, I am a weirdo who likes the idea that if I get something "right", I can transfer the whole platform to production without changing it. (I work very hard to establish "test" platforms that mirror production platforms, which is a worthy and nice benefit to the concept and ability to have virtual production machines...[See VMWare's VMotion and MS's SCVMM]) Yes, you can theoretically dumb down a VMWare Workstation VM to make it compatible with an ESXx server, but that has not proven flawless either. I have heard rumblings that Hyper-V may be part, or at least available for some versions, of Windows 8. If done right, this would REALLY make me happy, but that is a BIG if. I agree with everyone else about your prime hardware interest for doing SharePoint and BizTalk development. MEMORY! I have 8gb on my work machine, and 16gb on my machine at home. Being able to put the virtual machine on a separate hard drive is certainly a big plus, but you get nowhere without plenty of memory. Did you know that SharePoint, SQL Server and BizTalk CAN be installed on Windows 7 (probably the "higher" versions, but nonetheless) for development purposes? Stuff will run just fine, and certainly, use a server product for "near production" testing, but Beth Massi had a post on her MSDN blog about installing a development SharePoint installation on a dual-booted boot from VHD Windows 7 environment several months back (it may be even longer, because it was using a SharePoint beta at that)...