Frans Bouma's blog

I don't understand the longhorn-hype

There will be a new operating system among us in a couple of years: the OS currently code-named 'Longhorn'. The date today is September 29th, 2003. Longhorn is expected in late 2005. That's almost 2 years from now. In these two years, we have to live with Windows XP, that's the current top desktop OS Microsoft has to offer.

Don't get me wrong, I love to look at and play with new software, what the (near) future will bring us, I'm a geek after all. However the last couple of weeks started me thinking why is Microsoft not fixing Windows XP more and why isn't Microsoft releasing service packs for Windows XP on a more frequently basis? And I don't mean just service packs to fix code bugs, but also to fix design bugs. What I understood from reading the material that is available about Longhorn is that it is an OS that should be fixing a lot of the design bugs we run into today. However, that will be 2 years from now, the 'fixes' will be brought to us in a new OS, which will bring us new problems, which will be patched... when? In the Longhorn successor?

"But Windows XP is already rock-solid and stable, you're whining!". I know XP is pretty stable, I haven't seen a crash in ages, so it's not XP's stability per se, it's the awkwardness that's in the shell that's bugging me. Let's walk through some examples to get a clear picture.

• Spontaneous restarting of the shell. It just happened to me again. I clicked on the shortcut of the explorer on my 'quick-launch' bar and the shell completely vanished, taskbar, everything. Out of nowhere, 'explorer' restarts itself and the shell is back up. I'm a software developer, so instead of thinking 'Ah, that's a handy feature, it restarts itself when something is wrong', I wonder: 'who put that 'RestartOurselves();' call in the outermost catch() clause of explorer.exe so bugs in the shell don't have to be fixed' ? This simply should not happen. The shell should be rock-solid. However, it's not, it's far from 'solid'. Placing a restart call in the outermost catch clause is the hint that something serious is wrong in the design of the shell. This behaviour was already present in windows 2000's shell, so it isn't anything new either. Still, we have to wait till 2005 to see if this gets fixed, eventually. Why isn't this fixed today? Can anyone answer me that, please? When you're drooling over Longhorn's Avalon Shell, please consider that today's shell isn't good enough. We don't need anything new in 2005, we need something new that works today. The irony is, the shell is integrated with internet explorer (when explorer.exe is killed, all iexplorer.exe processes die too) and internet explorer is not updated anymore. This gives me the feeling we won't see serious updates in the XP shell in the two years (!) to come either.
• Silly GUI behaviour. I don't run my desktop in 640x480 mode, I run a 1600x1200 desktop. There are a number of silly things in the Windows XP shell and I want to enlighten one in particular so you get a picture about how silly some stuff is. When I right-click on the taskbar near the clock, I can select 'Properties'. Do you know where that properties dialog is placed on the screen? On the other side of the desktop, above the start-button. Now, this might sound irrelevant but the problem, as tiny as it might be, is perfectly illustrative of the common problem of the Windows XP desktop and why we need a replacement today: it is not designed to be helpful. Why is that dialog not popping up above my mouse-cursor like other property windows are? There are more examples of this: when you develop a winforms application or a win32 desktop application and you have a couple of windows to open, ever thought: "Why are these windows opened at random places on the screen." ? Why can't the default of the Windows XP shell be that it opens the window in the center of the screen, unless the developer has stated otherwise? With a desktop of 640x480 it is not a big problem, with desktops bigger than that it is.

My point is not to enlist a couple of shortcomings in the Windows XP shell. What I want to illustrate is that Microsoft acts too late and wrong when it comes to shortcomings to their own products. Some irritating shell behaviour was already present in NT4, why are we still accepting the fact that we have to deal with them today? I find that weird. Are we tired? Are we convinced that asking for patches (for Windows XP, the next service pack is not released in the near future, we have to wait at least a year) or functionality updates that are really necessary is useless? Why are we forgetting the current problems when we're talking about Longhorn? I don't get that hype. Longhorn might be good, better than whatever is on the planet at that date. However till that day, we have to deal with the current problems which are not addressed today nor will be in the near future, if ever.

A similar approach is taken in the Office group and the VS.NET group. I blogged some time ago (more than 2 months ago) about when the service pack for Visual Studio.NET 2002 would be released, after all it was promised by Microsoft. As it turned out, VS.NET 2003 seems to be the service pack for 2002, but it comes with a price tag. It's not the money the 2003 upgrades costs (however, after September 30th, it will cost a lot of money), it's the principle of fixing errors customers run into. Microsoft more and more seems to create hype around unreleased upcoming products and simply forgets to release updates for current products. I switched to Open Office because of the lack of serious bugfixing in Word XP. I could buy Office 2003, but why? To get fixes for a word processor I already own a license for? That's the world upside down. I don't need more functionality, I want the current functionality to work as planned. Word XP already contains more features I'll ever need, but a lot of them are broken (tables, bullet lists, headers) one way or the other. It might be caused by whatever I have installed on my system, but if that's the case it would be truly bad: software should be atomic, if application A can break functionality in application B, in the year 2003, application B is not well designed.

I'll check out Longhorn when it arrives. However 2 years is a long period. I thought I'd never say this, but I might have switched over to another platform by then (since Mono will be mature enough in 2005); this 'just wait for the next release'-attitude is not what customers deserve and I'm not willing to support it any more and neither should you. Hype is fine, looking at fancy screenshots and video's of demonstrations at the PDC on a rainy Sunday is fun, but never forget what the current situation is and that with the effort that is put into producing 'the next release', the current release would have been much better. After all, Windows XP was Windows 2000' successor, and it isn't perfect either, so why should Longhorn be?

Posted Monday, September 29, 2003 11:29 AM by FransBouma | 21 comment(s)

Useless programming language constructs

Ok, I'm back! :) After a long period of extensive programming (AKA 'Crunch mode'), the pressure is finally gone. Everybody who has released a big software product knows that releasing it is one, but the period after the initial release is as important as the release itself: early adopters who find odd bugs in weird circumstances no beta-tester has thought about testing nor did yourself thought it would be possible etc. But that's for another story to tell later :)

Today, I want to discuss a small set of, In My Humble Opinion, useless programming language constructs. I find them useless because they do not serve a purpose at all, however you can't leave them out because doing so will result in non-compilable code. I ran into these when porting C# code to VB.NET or during C# development.

• break in case blocks.(C#). In C# you have to add a 'break;' statement after each statement group you define as the 'case' block. This is because you can't have 'fall through' in C# in switch/case statements. Example:

  switch(foo)
  {
     case 1:
        // some statements [A]
     case 2:
        // some statements [B]
  }

  'case 1:' will stop at the end of [A], because C# doesn't support fall through. However, you still have to specify 'break;' at the end of [A], because you can't fall through, but that is not supported anyway! So specifying break or not doesn't matter, the end result will be the same. Also, you have to specify 'break;' at the end of [B], even though it is the last case block in the switch.
• Overloads when Overrides (VB.NET). VB.NET has many odd constructs, but one of the most weird ones is the obligation to specify 'Overloads' when you override a method with 'Overrides', even when the overridden method is abstract! Isn't it so that when you override a method, there is always another version of it, so overriding a method is also overloading the original. You can't leave Overloads out of the definition, even when the overridden method is abstract, which is weird, because abstract methods are not executable, the implementation of the abstract method is not an overriding method (however you have to specify Overrides), it is the implementation of the method.
• WithEvents with form controls (VB.NET). When you are writing VB.NET without Visual Studio.NET (for example when you port C# code to VB.NET, you suddenly feel the power of the Visual Studio.NET editors: you leave out statements that are automatically added by these editors. One thing that I find weird in VB.NET and which is solved automatically by the VB.NET editor is the obligation to explicitly define 'WithEvents' with a control when you want to implement an event handler. So for example you have a button on a form, and when you leave out the 'WithEvents', you can't define an event-handler. However, what's the use of a button without events, besides a nice thingy on a form? Isn't it so that when a control exposes events you always should be able to define event handlers for these events, without having to rely on 'WithEvents' ?
• ReadOnly with properties with only a 'Get' (VB.NET). This statement falls in the same category as the C# switch-case-break statement. When you leave out ReadOnly, it will not compile. When you specify a Set, plus ReadOnly, it will not compile. Isn't it obvious that when there is just a Get and no Set, the property is ReadOnly? Why a statement to explicitly define it ReadOnly, as if there is another way to define it.

Ok that's it for now, I'm sure C# and VB.NET have more of these language constructs which make you wonder why they're there in the first place. If you know more, post them in the comments :)

Posted Friday, September 19, 2003 2:30 PM by FransBouma | 13 comment(s)

It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.

The wait is over. After 8 long months of full time development, it's done. LLBLGen Pro is finished, the site is now online (go there by clicking here), the online store is available and the champagne is open and tastes as good as ever :)

I want to thank all beta testers for their tremendous amount of work they've put into the tool and for their support and feedback they have given me during the beta period. I also want to thank my wife for her moral support and for her help with the website and documentation. :)

The last thing I want to add before I stop hanging around at this keyboard for a few minutes is: 8 months ago I promised that LLBLGen Pro, the successor of LLBLGen, would be ground-breaking, would deliver features the competition would not have and for a price that was far more affordable than the competition. I hope I have delivered. :)

You can read all about LLBLGen Pro at http://www.llblgen.com

Update: I've uploaded the first sample application for C# and northwind to the llblgen.com site. I'll write more about this soon. Also VB.NET samples and other samples are on their way.

For the direct link to the example, click here

Posted Sunday, September 07, 2003 9:32 PM by FransBouma | 38 comment(s)