Robert McLaws: Windows Edition

Blogging about Windows since before Vista became a bad word

June 2004 - Posts

  • 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.

    PostTypeIcon
    3,014 Views
  • 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 http://www.longhornblogs.com/default.aspx, what if you could get a super-interactive experience with the full power of the client at http://www.longhornblogs.com/default.xaml? 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.

    PostTypeIcon
    14,930 Views
  • WinFS Scaleback Speculation

    Filed under:

    PLEASE NOTE: Before I go into my post, I need to state explicitly that what follows is pure speculation. It is not based on any discussions with Microsoft employees, NDA material, or the like. I am not a Microsoft employee, and I cannot verify in any way that the information contained within is accurate.

    So I was thinking earlier today about the recent hubub around WinFS. Lots of people have been upset that the Microsoft Business Framework and ObjectSpaces have all been brought under the WinFS umbrella. I discussed my opinions on the ObjectSpaces strategic decision over on my .NET weblog. And at the same time that Microsoft is broadening the scope of WinFS, News.com reports that Microsoft is "scaling back" some server functionality in certain scenarios, without going into specifics on what those scenarios actually are. In connecting the dots over the recent months, I may have an answer that is plausable enough that it could be true.

    Back at PDC2003, while I was sitting in on the Longhorn keynotes, I saw materials (though I can't recall if they were slides or handouts) that discussed the structure of the WinFS APIs. I remember being surprised to see hints in the class naming structure that WinFS was going to be extensible. I'm not talking about extensibility by adding new data types and what not, that's a given. I'm talking about extensibility about the database backend that was used.

    I saw a class design that hinted at a WinFS API based on the Provider Model, an extensibility architecture that Microsoft has backed into the Whidbey release of the .NET Framework. Based on the class names and structure, it seemed like you would be able to run WinFS on any database back-end. If you needed your file metadata to be on a DB2 backend, you could write a separate managed assembly that could do so. You'd then specify in the provider in some sort of configuration file (WinFS.exe.config?) and roll with it.

    So, based on the evidence, I'm gonna jump out on a limb and say that the server scenarios were WinFS metadata storage running on different databases, and that the WinFS API won't be provider-based until a future release.

    [Now Playing: John Mayer - Room For Squares - Why Georgia (04:31)]

    PostTypeIcon
    2,461 Views