Robert McLaws: Windows Edition

Blogging about Windows since before Vista became a bad word

  • Help LonghornBlogs Win

    CMP Media is holding a contest for the "2004 Best Tech Blog" award. You can nominate up to 5 blogs in one shot, and the 10 most nominated blogs will move on to the final voting on November 1. So please take a second and vote for us and 4 of your other favorite sites.

    More Longhorn-related posts to follow...

  • Microsoft Doesn't Own Monopoly on Slipping Ship Dates

    Microsoft's not the only one that suffers from slipping ship dates. The next 007 movie's ship date slipped from November 2005 to sometime in 2006. Maybe Microsoft should cut a deal with the companies that buy MGM to feature Longhorn prominently in the next movie. LOL. But that's not the only reason 007 is a lot like Longhorn. The next movie will probably be missing it's own key feature: Pierce Brosnan.

    So the new catchphrase is: Pierce Brosnan has been WinFS'd from the next 007 movie.

  • Help The Hurricane Victims

    All I can say is, I'm really glad that I don't live in Florida. But the people that do live there need your help. I can't even imagine what it would be like to live through four hurricanes within the same six weeks. The shelters are packed, and people need food and supplies. So please be as generous as you can, the holidays are coming soon. Click the links below to donate.


  • DNS Issues

    Somehow, over the past few days, my domain name registrar's DNS settings got all screwed up. For whatever reason, many of my domain names were parked, instead of pointing to my DNS servers. So some of you may experience patchy access to the site over the next 48 hours as the correct settings re-propagate across the web. Sorry for the inconvenience.
  • When FUD Becomes Journalism, or Avalon Is In Longhorn

    I don't get it. Why is eWeek trying to spread FUD by speculating on how developers might feel if Avalon was not in Longhorn? It's completely retarded. It's like asking someone in Phoenix, "How would you feel if an earthquake made California sink into the ocean?" or "How would you feel if Satan suddenly appearded before you in red silk panties and a whip and did the jitterbug?" (Personally, I'd probably feel like my doctor needed to up the dosage on my medication, but that's beside the point.)

    Avalon and Indigo are much more stable than WinFS is. I wouldn't be surprised if you see Indigo before the end of 2005, and Avalon not much longer after that. I mean, the PM of the WindowsForms team said that WindowsForms has about hit the limit of what it can do in Win32, and while it will stick around for a long time for compatibility, there likely won't be any new features post-Whidbey. With VS "Orcas" being the de-facto way to build apps in the "Longhorn" wave, and no significant new WinForms features planned for that version, it's pretty safe to say that the default way to build apps in Orcas will be Avalon, and that it will be "widely available" at release time.

    And any notions to the contrary are just plain hogwash.

    I think the quote by Somesgar was taken out of context. IMO, the statements he made were no more than responsible planning on the part of a VP. As I discussed previously, when you have so many dependencies between software packages, you have to be a lot more fluid in your planning. DonXML talked about being worried because there is no design-time story for Avalon yet, but that's simply because the VS team is still working on wrapping up Whidbey. There is no reason to build an Avalon designer yet, because it will more than likely require other IDE features that haven't even been spec'd out yet, much less written.

    The guy heard the quote and probably thought he had a story. It seems that the mainstream media is resorting more and more to making up stories to fill space, but this little piggy just doesn't fly. If Avalon missed a deadline and was late a month, Microsoft would push back the Longhorn ship date. WinFS was going to take a lot more than a month to fix.

  • Longhorn Shakeup - Part Two: The Death of the 'Software Wave'

    In my previous article, I discussed the social background behind last Friday's announcements, and the history that lead up to those decisions. Today, I'm going to talk about the demise of the synchronized software release. It's important to note here that these are editorials; an attempt to put the respective pieces together, based on my own experience and my interactions with the various parts of Microsoft. While I strive to maintain accuracy, I'd rather not get nit-picky over minute details, like for example, which version of the Windows codebase Longhorn is being built from.

    At PDC 2003, Microsoft talked in great detail about its ship schedule for the next 4 years. It was a very ambitious schedule, with several interim releases (XPSP2 and WS2003 R2) wedged in between two major "software waves". The first wave was called the "Yukon" wave, named for SQL Server 2005, code named Yukon. Microsoft's promise was to deliver a version of Visual Studio ("Whidbey") that was synchronized with the next version of SQL Server. After that came the "Longhorn" wave, which promised a version of Visual Studio version ("Orcas") synchronized with the next version of Windows, codenamed Longhorn.

    What was not talked about was the serious ramifications of attempting such a huge synchronization between development teams. It's a bigger deal than one might think. And it ultimately had a direct impact on the entire release schedule. Time to jump in the Wayback Machine...

    <insert wavy Wayne's World dream lines here />

    Lets jump back 3 months ago. The VS team was hard at work, and things were plugging along. Then, Microsoft executives drop a bombshell. "Yukon" development had run into some snags, which would end up pushing back the Whidbey release from late-2004 or early-2005 to mid-2005. True to form, most developers threw a temper tantrum, whining about how they wanted their tools now, blah blah blah. I think Microsoft needs to start handing out pacifiers with their PR announcements.

    But I'm getting off on a rant here. Anyways, I'm not exactly sure on these details, so if I'm wrong, don't ram it down my throat, but if I remember correctly, there were some issues with integrating the CLR into SQL that was holding up development. Why was this an issue? Well, lets take a look at the dependencies across the "Yukon" wave:

    Figure 1: Dependencies in the Yukon Wave

    So,the .NET Framework is the base, and Yukon has the CLR embedded in it. Oh yeah, and Visual Studio compiles against it. But what you may not have known is that the new features of Visual Studio are built in managed code, dependent on .NET 2.0. And did I mention that every single one of these parts were being developed at the exact same time? That would be a feat for ANY company to manage, especially one as large as Microsoft.

    So are you confused yet? Cause it gets better. Because the Longhorn wave follows the Yukon wave, any delay in the release of Whidbey automatically mean that there will be a delay in Orcas. Because, while Microsoft has Program managers who help manage features two and three releases out, large scale development of those features do not start until the release in progress is finished. And a delay in Orcas means, automatically, a delay in Longhorn. Speaking of which, let's take a look at the dependencies in the Longhorn wave:

    Figure 2: Dependencies in the Longhorn Wave

    As you can see, the model gets a lot more complicated. Lets see if I can explain it properly. First off, lets not forget that all these systems are being developed in conjunction with the Yukon wave, so all of those dependencies still apply.. Now, lets add Windows to the mix. All three pillars of Longhorn are being developed with a significant amount of managed code. And remember, the managed code base that they're working from is also still in development. Since the .NET Framework team is constantly kicking out new builds, it's entirely possible that each of the three pillar teams are working with different builds of the .NET Framework. If they're relying on internal features that are still in flux, a simple bug fix could have disastrous consequences.

    For WinFS, it's even more complicated. They're building on two systems that are still in flux... Yukon and the .NET Framework. In that scenario, it's entirely possible that the WinFS extensions are being constructed on a build of the .NET Framework that is entirely different from the one they are baking into the database, creating a whole new set of problems. This is why it was next to impossible to synchronize a Visual Studio 2005 build that could build Longhorn apps... they would have to have a significant, QA'd milestone from which to work with, namely Visual Studio 2005 Beta 1. Only after that build was released could you re-synch the teams, get everyone on the same versions of the Framework and using the same development tools, and move on from there.

    So at this point, you're going to say "Well, Microsoft is hemorrhaging cash. Why can't they just throw more money at the problem?" Oh, how short-sighted you are. Microsoft still has shareholders to answer to, and you don't just start throwing money around because you have a lot of it. It's real easy to acquire wealth. it's a lot harder to keep it. Just ask the hundreds of .COM companies that burst with the bubble. So throwing a couple million at the problem still doesn't solve the dependency issue. And with Yukon delays affecting the WinFS team just made it that much harder to overcome the problems they were already having. Again, you have to remember that WinFS is not just about search, just as Avalon is not just about XAML. WinFS is about a new file/metadata storage paradigm, from which ALL future Microsoft products will be built. WinFS is to information storage for the next 20 years of Windows as managed code is to Windows platform development over the same period. It's not something Microsoft can afford to get wrong.

    Lets think about the long-term vision of WinFS for a second. Think about all the Microsoft applications that store data in one form or another. You have a relational database in the file system. Forget needing MSDE or it's successor, SQL Server 2005 Express. Forget about having to deploy Access databases for simple applications... just add a new WinFS object schema (an XSD document) and store your data there. You won't even have to worry about application-specific APIs to get data out of OneNote, for example. Just use WinFS to grab the document, load up the data, and go. You could access Microsoft Money task items in Outlook (with the proper credentials, of course) synchronized with your other tasks. You could even store Visual Studio development tasks, culled from the Team Foundation Server database, and have those integrate with your calendar too. With the stakes so high, can Microsoft afford to listen to whiny, impatient developers? In this case, the answer is a most definite 'no".

    OK, so reports of the death of the 'Software Wave' has been greatly exaggerated. (Fooled ya, didn't I?) It's not exactly dead, but Microsoft has definitely learned its lesson. Since the successes of the 'out-of-band' approach with Windows Server 2003, Microsoft has had examples on both sides of the aisle on how to manage extremely interconnected projects. From this point forward, you will continue to see products released at the same time that complement each other. You might even see it continue to happen on such large scales as we've seen thus far. More likely, you'll see more 'features' broken out into their own 'products', that are re-combined into a future update (a la Windows Server 2003 R2).

    Now, notice that it didn't take long for even the most respected people in the industry to scream "Cairo" and doom WinFS to its death. Just remember, Microsoft's dream of a pen-enabled PC failed four times before it succeeded. The lessons from Microsoft Bob and the infamous Clippy went into making products like Windows XP and Windows Media Player 10 easier to use, and more effective. The lessons learned from the entire Longhorn process thus far, from PDC 2003 to blogging to software waves, will define how Microsoft develops software over the next 10 years.

    In my opinion, it's just another lesson in life. Do you shoot for the moon, dream big, and then risk coming up short from time to time; or do you always brainstorm within the confines of reality, listen to the pundits and the naysayers that work fervishly to convince you that it can't be done, and be guaranteed success? I don't know about you, but I can hardly recall an endeavor worth achieving that didn't involve dreaming big, high risk, and significant possibility of failure. And given the choice, I'll dream big every time.

    Next up: my predictions on what the Microsoft world will be like after 2006.

    UPDATE: I've disabled comments for now, because some Mac zealots resort to swearing to get their point across. For now, if you want to comment, blog about it and link to this post.
    UPDATE #2: Lets see if Mac enthusiasts can make a point without resulting to vulgarity.

  • Longhorn Shakeup - Part One: The Social Perspective

    This is the first in a series of commentaries I'll be writing about the changes that are coming in Longhorn. There's going to be a lot of speculation over how this will affect the Microsoft roadmap for the next decade, so I thought I should throw some inside insight into the fray. Now, much of what I have to say will probably appear to follow the "party lines" that Microsoft laid out on Friday. What I'm hoping to discuss over the next several entries is an expansion on what has already been revealed, in hopes of connecting the dots for the rest of the community.

    While most people will be focusing on the removal of WinFS from the main release, I want to take the time in this first article to talk about some of the backstory that lead up to Friday's decision. The past year has been very interesting for Microsoft. MSBlaster shook the company hard, and really forced everyone in the organization to take a hard look at how they did business. Up until that point, there was a real disconnect between the company and it's customers. Well, Microsoft caught an earful from those disconnected customers in the hours, days, and weeks following the attack. And, in the company's defining moment, they started listening.

    But Microsoft had been developing Longhorn in secret for at least 18 months, maybe longer, prior to MSBlaster. This development track had been predetermined, and predestined to follow the same old Microsoft dev cycle: built in the Echo Chamber, with few outsiders defining how the OS was going to function. Following that same ol' path was going to introduce the same ol' problems, but a burgeoning new movement inside the company would soon change that. 

    Two months after MSBlaster came the PDC, where Microsoft did something it had never done before: it laid it's plans bare in front of 3000 developers, reporters, and IT planners years before the finished product would be released. The plans were ambitous, and the world cheered. When Microsoft said it was betting the company on Longhorn, it was only partially accurate. MS really took it in the shorts with their "let's take over every tech company" strategy, so they really needed the whole "corporate transparency" thing to work for them. While it would appear to the world that Microsoft was betting the company on a revolutionary new platform, the bigger bet was that the world at large would welcome Microsoft's newfound benevolence.

    So in October 2003, Bill Gates & Co opened the kimono (and, surprisingly, Don Box didn't) to show the world Windows Codename 'Longhorn'. They touted new architectural strategies, new capabilities, and a new slew of confiusing acronyms (WinFS and WinFX... come on guys) that would make the computing world a better place. It was the "revolutionary" new operating system that would usher in the "Digital Decade", with large swaths of the company's product lines being delivered in synchronized waves.

    But as Bill was touting the future, already the need for change was apparent. Features that were being developed for Longhorn suddenly needed to be done yesterday, and Windows XP Service Pack 2, previously only a hotfix rollup, now had to break the mold and introduce a significant new feature set. Never before had Microsoft fundamentally changed the operation of a product in a service pack, and the ramifications would be huge. So Microsoft made one of the most expensive business decisions it ever made. They ground development on their next OS to a halt, and moved most of the Windows team to solving the security problem in Windows XP.

    Many people underestimate the significance of Service Pack 2. I personally believe that Microsoft should have called it Windows XP2, because it really is a new version of Windows, but I don't determine that stuff. A lot had changed since it was released in 2000. There were better compilers that did a better job checking for "buffer overruns" and other trivial bust nasty coding flaws. So Microsoft completely recompiled the codebase to take advantage of the increased protection. There were hundreds of bug fixes, as well as vast changes to the core of IE, which forms the basis of most of the Windows browsing and navigation experience.

    But I digress. So Microsoft didn't just stop working on Windows while SP2 was in development. They had evangelists across the country talking to ISVs, IT implementers, and end users, getting feedback on the public and private versions of Longhorn that had been released. They had internal teams prototyping Longhorn applications to get a feel for what ISVs would be going through. And they were surprised with the results.

    Compared with the difficulty in installing, using, and maintaining Windows; the prevalence of spyware, "browser helpers" and other malware; and the lack of consumer education on the perils of a connected society; the thought of a new desktop rendering system wasn't all that exciting. On top of that, it was becoming increasingly apparent that WinFS was not as far along in the development cycle as it's pillar counterparts. So Allchin did exactly what he is paid to do: he caught wind of the problem and realized that action needed to be taken.

    What happened next is the same thing that happens in every software development cycle. The problem is, while Microsoft went great lengths to educate people on what they wanted to do with Longhorn, they virtually ignored educating people on how software development works. This miscalculation will prove costly in the PR war that Microsoft battles daily. The armchair quarterbacks of the tech world will rip MS a new one, but Microsoft will learn from its mistakes, and the process will go on.

    In the weeks leading up to Friday's announcement, Microsoft had to look at what it wanted to do, versus how long it would take to do what it wanted, and how much that would cost to accomplish. They also had to factor in the new feedback, and adjust their priorties in regards to usability. So you would think "Well, Microsoft has $70B in the bank, they can afford to do whatever they want." In an ideal world, that would be true, but Microsoft is a publicly traded company, answering to shareholders that will not tolerate a lull in profits. Something had to give, and Microsoft came up with an unorthodox way to do it.

    In the end, Microsoft got what it wanted, but not in the way it wanted. They said that Longhorn was going to be a revolutionary operating system, and I believe that it will be. The architectural side will definitely improve, but the revolution will take place where it really belongs, in ensuring that computers are as easy to use, easy to manage, and resiliant to attack as possible. And that can only be good for everybody.

    In my next installment, I'm going to talk about the death of the 'software wave', and what it means for the Microsoft roadmap through the end of the decade.

  • Gates On Longhorn gets way too many scoops, especially since they like to spin stuff negative. Ah well. Read what BillG had to say about today's announcement.

  • Windows 2006 Cutbacks: The Long[horn] And The Short Of It

    Ok, so the press is going to have a heyday for the next month over the news announced today. This has been an open secret for quite some time, and it's good to see some actual information on what has been going on. I just got done with a round of interviews with some of the major news outlets, and I'll be assembling a post with links to all the comments all over the web about what's going on. But I wanted to take a minute and clear the air about what is happening.

    1. Microsoft is decoupling the development of the "Longhorn Pillars" to speed up the development process. I'll go into more detail later, but basically there are too many interdependancies for the Longhorn development process to be manageable, even by a company as large as Microsoft. If anything, the scale makes management of the process infinitely more difficult.
    2. Avalon and WinFX will still be delivered as a part of Longhorn. They will not, however, be dependent on Longhorn. This means that they will also be available to run on Windows XP and Windows Server 2003.
    3. The .NET Framework 2.0, code named "Whidbey", will be installed by default in Longhorn. At this point, it does not look like there will be any major parts of the OS that will be dependent on Whidbey by default. This may change, and those kind of details are still being worked out, so don't take that as static information.
    4. WinFS is being shipped as an out-of-band add-on pack (a la ADAM) for Longhorn, to be shipped after Longhorn is released. I'm going to go into detail on that tomorrow, but here's the drill. Microsoft won't publicly confirm this, so don't ask, but it only makes logical sense that Microsoft will now deliver it as part of Longhorn Server, with an "integration pack" for Longhorn Client, sometime in 2007. As I said, I'll go into the hows and the whys in a detailed post later this weekend.

    That's it for now, as I said, I'll be culling resources together to put together a more accurate picture shortly. In the meantime, I would recommend that everyone refrain from going nuts until more information is available.

  • Revisiting Longhorn's 'Priorities'

    "SP2 was a major milestone for the Windows development team," [Microsoft] said in a statement Wednesday to CNET "Now that it has been released, it is a natural time to revisit Longhorn priorities."

    The needle on the Longhorn Richter Scale keeps rumbling, and change is in the wind. Microsoft opened the kimono on Longhorn way early... but was it too early? Refocusing happens in every software project, but expectations on this version of Windows are so high, how will everyone react if the things that alludes to are true? If the inevitable happens, and there is a backlash, will Longhorn scalebacks be followed by a clampdown on the flow of information from Redmondites? One can only hope that rational thought will prevail.

    Stay tuned.

  • XPSP2 RTMs, What's Next For the Windows Team?

    It's been a long and bumpy road for the Windows team this year. I was in Redmond around this time last year when MSBlaster hit the scene, and let me tell you, it was quite amazing to watch. It had to have been a lot like the attack on Pearl Harbor. Microsoft was calling all hands in on nights and weekends, doing emergency customer service training courses... it was crazy. I might be in the cheap seats of the Diaspara, but from here I think it was the best thing that ever happened to Microsoft. I don't remember if they've caught the original writer or not, but as much damage as it did, you gotta give they guy snaps.

    Now I know I know, I'm not going to sit here and condone hacking, that's just irresponsible. But they did more than just expose a crack in Windows, s/he exposed the gaping wound that lay just below the White Knight's glistening armor. Let it not be said that one person can't change the world, because it just isn't true. That person awakened the sleeping giant that has sole responsibility over 90% of the worlds computers. And just as the world is a better place because of Pearl Harbor and September 11th, the over the next several months, from this point forward security will always be at the top of Microsoft's priority list.

    So the work on Service Pack 2 is complete. You all have been watching with bated breath for Longhorn news, leeching leaked builds from the Usenet, and what not. As tech-savvy users, it is your responsibility to make sure everyone you know has installed this update as soon as you get access to it. It's more important than anything in Longhorn, because it's here today, and it improves the security and stability of your machine TODAY.

    Now, at the same time all this has been going on, there has been a lot of complaining about the constantly slipping Longhorn release date. I haven't weighed in on that too much yet, but I think it's time to break my silence. Microsoft shifted between 80-90% of the Windows Client Team off Longhorn development and onto Windows XP SP2. Now, a lot of the features, like IE popup blocking and the No-Execute technology were originally supposed to be in Longhorn. Following the Battle of Blaster, Microsoft regrouped and decided, and rightfully so, that these features could not wait until 2006/2007.  Now you may not have known this, but XP2 was even compiled differently to prevent buffer overflows.

    So, in the Longhorn space, this is why we've only seen two public builds, 4051 and 4074. There were only 23 internal builds in the 8 months between the PDC build and the WinHEC build. 23 in eight months. I tested practically that many builds of XP2. It's the end of the first Friday in August, and you better bet the Windows Client Team is taking a long weekend off. I bet the probably even have the day off on Monday. But next week the WCT begins an even more daunting, and extremely expensive, task: Moving the XPSP2 code BACK into the Longhorn codebase.

    You see, when Microsoft started working on Longhorn, they forked the Windows codebase. So, for the past year, Windows has had 2 parallel development tracks, Longhorn and SP2. Longhorn development started with the Windows XP SP1 codebase a few years ago, and I'm sure at that time, Microsoft pretty much figured that was it. But one person changed a $70B company, and now you have the next revolution on the Desktop that is actually behind what is currently available in many respects.

    If you've been fortunate enough to play with Longhorn 4074, you'll notice that it doesn't have No-Execute protection yet, it doesn't have the Windows Security Center, and it doesn't have the brand new WiFi/Bluetooth stacks. All these great new features need to be brought back on the Longhorn train so that it can pull out of the station before 2007.

    So why did I just go off about all this? Well, I guess it's so that everyone can get a little perspective on the situation. The media talks up and down about how Microsoft's ship dates affect their bottom line, and that's what they are paid to do... talk. But events of the past year have made it readily apparent that, while the inevitable delays cost money, using software that was hurried out the door over a blip on the calendar can be exponentially more risky.

    Besides, Microsoft needed to give Apple enough time to make itself look retarded by saying that its next OS is Longhorn, without even coming close to having a comparable feature set.

    But that's just my opinion, I could be wrong.

  • Monoculture Is Not Necessarily Evil

    So says Larry Osterman, who always has some interesting things to say. He has some interesting things to say about platform stability in the ever-continuing Windows v. Open Source debate. Instead of getting all religious about it, he instead talks about it in terms of the cost of delivering software for a given platform. it gives a good overview of the history of computing in terms of shrink-wraped software v. hardware costs.

    Draw your own conclusions. Any way you slice it, it's a good read.

  • VS2005 on MSDN - Gentlemen, Start Your Downloads!

    Visual Studio 2005 Beta 1 is now live on MSDN. Get it while it's hot.
  • VentureBlog on Longhorn

    Martin Tobias over at VentureBlog has a couple interesting predictions on Longhorn. Scroll all the way down to the bottom where he says (in the next 2-5 years):

    2. Microsoft will NOT ship Longhorn.
    - Already delayed it to 2007. I think it is 2009.
    - Took out half the features including everything about WinFS.
    - They may ship Indigo sooner.

    Gosh. I hope he's wrong. Marty, you're just not thinking 4th dimensionally. (Right, I get that a lot.) Microsoft has already said that they will ship an Indigo stack sooner. They also said it would run on Windows Server 2003 and XP.

    At this point, the only reason why Microsoft delays Longhorn any later is if they have to continue pulling staff away from it's development to beef up security in the current version. They sooner they wrap up XP2, the sooner they can start the monumental task of back-porting all those changes in the XP codebase up to Longhorn. Why do I say that? Well, did you notice the XP SP2 RC1 (or 2) features were not in the WinHEC Longhorn build? That's because they're back in the XP branch. Once they're done, they'll have to do a massive amount of diff-ing to get the new code up the tree. Hopefully their source control and build management processes can automate that a bit.

    Oh yeah Martin, and BTW, you're applying massive amounts of FUD to the WinFS thing. Those quote-unquote "cuts" were blown way out of proportion.

  • Seven Reasons Why the API War is Not Lost After All

    Joel Splosky thinks that Microsoft has lost the API war. Whether or not anyone has addressed these before, I felt it was important to address them here.

    Some background on me: By Joel's definition, I'm a member of the "MSDN" camp. I'm the one that was sitting with Chris Anderson at dinner at PDC, telling him to rip out Win16 and Win32 from Longhorn. I told him that if you want to be revolutionary, you have to take the big risks. And that was the reason I told him they should also change the name to something other than Windows, but I've talked about that already.

    So, I need to preface all this by saying that Joel is a respected member of the community. He's used his ability to communicate ideas effectively, and the ability to write good software, to create a successful business. But he's wrong on several points, and those points make up the bulk of his arguments. Many of them are common misconceptions about Microsoft right now. So lets get started.

    1. .NET 1.1 is not completely backwards compatible with .NET 1.0
    It's important to note that while Joel said something very important:

    I still haven't had time to learn .NET very deeply.

    So because Joel doesn't know much about .NET, and still hasn't taken the time to port his application to .NET (which was just listed by aspNETPro as the Best .NET Bug Tracking software, a move that IMO was poor judgement seeing as how it's not a .NET app), I don't think Joel can be seen as an authority in this case. The changes to the Framework in 1.1 were not so much that scores of applications just stopped working. The did change the way a few dozen function worked, for either security or performance reasons, but the fact that you could have the .NET Framework 1.1 run side-by-side (commonly abbreviated as SxS) with the .NET Framework 1.0 pretty much negated many of the problems typically associated with breaking changes. And it's not like the stuff just disappeared; the compiler gave detailed warnings when things were depricated, and in many cases, still compiled without incident.

    2. VB.NET is an upgrade from VB6.
    Again, this is a false statement. While it may appear that VB.NET is just VB7, it is in fact, not. It is a new language, like C#, that was designed with many of the same syntactical attibutes of Visual Basic, much the way that Visual C# was designed with many syntactic similarities with C and C++. It's VB.NET 1.0, not VB7. And Microsoft put out tools to make the conversion even easier. Yes, it was a paradigm shift for VB guys. The sky, however, did not fall. The world did not end. Developers learned, and life goes on.

    3. The number of languages has decreased .NET adoption
    Again, I have to remind you guys that Joel is not a .NET programmer. He does not yet understand that "It's The Runtime, Stupid." That the languages map to MSIL-compiled instructions based upon the specific language's compiler. I believe that adding languages to the Common Language Runtime only increasesthe possibility that more varied developers will take their existing knowledge to .NET, instead of the unilanguage Java environment. 

    So now instead of .NET unifying and simplifying, we have a big 6-way mess, with everybody trying to figure out which development strategy to use and whether they can afford to port their existing applications to .NET.

    Picking a language is not a development strategy. It's a real simple decision: Which language is more familiar to me. Am I just starting out? If that's the case, VB.NET is for you, because it reads more like English and is easy to understand (even my mom can read a little VB.NET). If you come from a C, C++, or Java world, then C# (or in some cases, J#) is for you. If you're spending any more time than that thinking about it, you have bigger issues.

    The real reason that companies aren't moving to .NET as rapidly as you would think, although a Gartner report says that .NET development accounts for 65% of corporate development, is because companies are scared of anything that is "1.0". It's called "first version-itis", and pretty much every company has it. Further, most companies have dedicated millions to training for development in older technologies, and the turn-around rate for that kind of sea-change is a lot slower than most (myself included) would like.

    So, my prediction is that .NET development will increase significantly with VS2005. Especially with some of the other things that Microsoft is working on, that I'm still unable to discuss publicly.

    4. Win32 is being replaced in Longhorn with WinFX.
    This is 100% incorrect. Obviously Joel didn't sit in on the Jim Allchin keynote at PDC (I don't expect that he did, because if he won't even develop in .NET, I highly doubt he would have forked over two grand to look THAT far ahead). Jim demonstrated VisiCalc running on Longhorn. It's a 20 year old app, and it still ran. Now, I don't know about you, but I took one look at that, and groaned miserably. I think it's retarded that anyone would still use programs like that. But the again, the number one retail flooring management software is still a DOS console app written in old school C. I think Joel would have lept to his feet and cheered wildly. I groaned and rolled my eyes.

    The next evening, ChrisAn and I were at that dinner, talking about all the reasons why Win16 and Win32 needed to stay inside Windows. I countered with the argument that Microsoft had just spent millions to acquire Virtual Machine assets in Connectix. Why then was it necessary to maintain old APIs? Couldn't you just rip out the old code and replace it with a real-mode emulator? Chris chuckled and replied that it was completely impractical to rip out millions of lines of existing code in the Windows codebase.

    Unfortunately, Longhorn is not the fresh start that many (myself included) would hope for. It's more of an "evolutionary revolution". All the old stuff will still be in there. Win16 will even be in there (God help us all.). So just because Microsoft is not adding much to the APIs (althought there will be new Win32 work in Longhorn, contrary to popular belief) doesn't mean that Microsoft will not continue supporting them.

    5. XAML replaces Windows Forms development in Longhorn.
    We can't even get Microsoft to stop supporting console application development. We cant even get Microsoft to stop supporting VBA in Office. How can you possible think that Microsoft would stop allowing WinForms development? If Joel thinks that WinForms development is stalled out, he needs to take a look at guys like Tim Dawson, or one of his competitors, Hamid Shojaee. Hamid runs Axosoft, maker of the OnTime defect tracking system. Have you seen his WinForms UI? It's extremely sexy, and so much more usable than his last version. I'd say it's definitely more usable than Joel's application.

    Separating the GUI code from the business logic is the main reason why web development is so hot, and why most everyone loves ASP.NET. It will be one of the main reasons why XAML will take off too. And if he thinks WinForms has stagnated, he hasn't seen WinForms 2.0 yet. They's done some pretty cool stuff with the platform.

    So here's the drill. If you want to write programs that run on previous versions of Windows, as well as Longhorn, use Windows Forms. If you want to create applications to take full advantage of the advances in Avalon, use XAML. By the time XAML comes out, you can almost guarantee that there will be a plethora of WinForms -> XAML converters, and vice-versa.

    6. XAML is only for the "Smart Client".
    If you think that XAML is only for Windows programming, think again. Microsoft wants to blur the lines between Windows and Web development. Remember that XAML is not a GUI markup language, although that is what it can be used for. XAML is a way to declaratively work with .NET classes. That's why there are not one, but two different XAML paresers that work on the current version of the Framework.

    So, if Microsoft wants to blur the lines between a web site and an client-side application, what makes you think that the next version of IIS will not support serving up XAML to the client. Instead of getting a limited browser experience at, what if you could get a super-interactive experience with the full power of the client at What if, on a mobile device, you could use web services to allow location-aware applications ultra-dynamic, serving up XAML UI code along with data? A thick thin-client? Talk about a contradiction in terms. The possibilities become greatly expanded if you beging looking at what's in front of you instead of looking behind your shoulder at what's behind you.

    7. WinFS is all about "Search".
    Another popular misconception. This one is typically associated with database-driven application developers. Gosh, guys, why else would up put the metadata in a database??? Well, let me ask you a different question. Why do you think that MS spent so much time on creating XML schemas for Office documents, and then subsequently licensed them? WinFS is about using schemas to define objects for storage in a data-driven way. It uses schemas to define custom storage types that can be indexed for, among other things, search and retrieval.

    But WinFS was really designed to remove the "data silos" that applications use today. Right now, if you want to get an e-mail out of Outlook, you have to use the Outlook object model, which, like the rest of the Office object models, is convoluted at best. And forget having your Outlook contacts available to AOL Instant Messenger, or any other app for that matter. It's just too difficult today. Using WinFS, you can store that kind of information just as easily as you can store a file. And the object is even displayed for youin a file-like manner.

    Think about putting a database in the file system for a minute. What's the need for MSDE then? Think about applications that can be written to take advantage of that. Why store application settings in the Registry, when you can whip up a quick schema and store it in your file system, callable through ADO.NET-like syntax. Heck, with capabilities like that, I could teach my sisters how to write applications to help them with their everyday needs.

    In Conclusion
    At any rate, hopefully guys like Joel will be forward-thinking enough to stop looking towards the past and start looking towards the future. Yes, Microsoft will still go out of their way to make sure applications run on Windows. To say that will suddenly stop with Longhorn is irresponsible, especially coming from a misinformed authority. If Longhorn can still run a 20 year old program, it's pretty safe to say that Microsoft is going the extra mile to keep people as unwilling to change as humanly possible.

    That about wraps up my take on Joel's comments. IMO, Joel just doesn't understand where Microsoft is going, which is as much his fault as Microsoft's. They've done an extremely poor job of communicating their long-term strategy, but that is slowly changing. The only thing slower to change than a large corporation is the Government. This new 21st Century idea of openness in business scares a lot of people. Because companies make mistakes. And society has brainwashed everyone into thinking that mistakes are a bad thing. That failure is bad. But there is more information out there than ever before. And with so many Windows developers using his application, it's sad that he's not more in tune with his industry. My feeling is, if he doesn't study up, he's going to get left behind.

« First ... < Previous 54 55 56 57 58 Next > ... Last »