Revenge of the Airplane

Last week Anders posted a link to the most amazing R/C demo I've ever seen (and still is). The balancing on it's rotor bit was unbelievable. Now the airplane wants a chance to show off. They call this "3d flying". Thanks for the link Rob.

Object Spaces in Longhorn

According to the MSDN Data Access and Storage Developer Center (what a mouthful), Object Spaces will now be rolled into Windows Longhorn. Previously expected next year in Whidbey, it looks like Object Spaces will now be part of WinFS in Longhorn. If you're not familiar with Object Spaces, think of the object relational mapping features of Borland ECO (Enterprise Core Objects) in Delphi 8 that allow you to automagically generate schema and persist objects in relational databases. This alleviates much of the work involved in creating, maintaining, and evolving Enterprise applications. Instead of working with both objects and persistence you only need to work with objects and the persistence is handled for you. So the good news is that OR mapping will be eventually be part of Windows. And the even better news for Delphi developers is that OR mapping in .NET is already here in Delphi 8. You can learn more about ECO in the online tutorials.

Delphi's Brother: C++Builder and VCL

The other day I was chatting with my brother on our daily "drive home from work" cell phone conversation and he mentioned that he was using C++Builder 6 for a rewrite of a hardware configuration utility. It struck me as interesting because the company Rob works for, a major chip manufacturer, is standardized on Visual C++. Rob is a long time user of VC++ but he is no stranger to C++Builder and VCL. He has a history with Borland C++ compilers going *way* back - and of course for years his brother was the C++ product manager at Borland. The thing that made me smile that day was that he was using C++Builder for a project in a very VC++ oriented environment.

Rob is a hardware level developer by definition. His drivers and firmware are in more consumer devices that I can count. If you're using a laptop or PC from a major manufacturer like IBM, HP, or Dell then there is a very high probability you're running some of Rob's firmware or driver code [but don't ask me to forward any support questions!] He explained that he recently had added some new features to some firmware that needed to be surfaced in an existing Control Panel applet. The applet was originally written with MFC in a very procedural non-RAD manner typical of MFC user interfaces. Over time and multiple developers it was now more or less a mess. It really needed to be rewritten, but an MFC rewrite wasn't really something he was looking forward to. Particularly because in the back of his mind he knew how much faster, easier, prettier, and cleaner it would be if he could "just do it" in C++Builder and VCL.

Knowing he'd have to take a little grief for using a "non-approved" tool and framework, he made a judgement call and "just did it". The new VCL based Control Panel applet will soon make itself into millions of PCs and Laptops. It now had new features, a more polished user interface, a far more maintainable code base and was written in less than a week with 41k of source code - compared to the "who knows" how many months the 261k of MFC code originally took. The estimate to rewrite the MFC applet from scratch with was twice the C++Builder VCL estimate and would have lacked all but the bare minimum of the new features and none of the polished user interface touches that ended up in VCL version.

The kicker was that the product manager lamented after the fact that it would have been nice if the applet were a regular application exe instead. 1 hour later it was converted.

This example is hardly unique. When I was the C++Builder product manager I heard the MFC to VCL stories regularly from customers. These days with my attention focused on Delphi I don't get to hear the C++ stories as often. So it was nice to hear this one, particularly from Rob.

Win32 in a .NET World

One of the more frequent questions we get asked these days is about the future of Delphi on Win32. It's practical question because there are literally hundreds of thousands of Delphi Win32 applications in operation today by millions of end users who rely on them. With all of the .NET hype and future .NET based Windows Longhorn technologies being talked about all the time by Borland, Microsoft, and the software development industry in general, it's no wonder a developer with ongoing Win32 requirements might pause with concern. Developers care about maintaining the quality of these Win32 projects and adding new features along the way. Fortunately for those invested in Delphi, Borland is taking the practical approach to continued Win32 support while at the same time speeding on the .NET track like a bullet train.

It's obvious that we're dedicated to .NET in a big way. Managed code is the future of general application development on Windows and most Delphi developers are already starting new projects on .NET with Delphi 8. If you haven't tried it yet, get a copy - you'll be amazed how great the new technology is… and also how surprisingly familiar everything is - but that's for another conversation. Rest assured that for now we are going to continue supporting Win32 in Delphi. As promised, we just signed off on the 7.1 service pack for Win32 which addresses some of the more commonly cited Delphi 7 issues - including everyone's favorite project manager sorting anomaly. Anders has kindly posted the readme on his blog. The update is available for download now and eventually will work it's way into the Delphi 8 boxes themselves - which happen to conveniently include Delphi 7. Win32 support and new features will be included in future Delphi's as well.

It's interesting that in addition to the questions of "if" Win32 support will continue, we also get the flip side; "why continue to support Win32?". One thing I've learned in my years of working on Delphi is that there is no single Delphi developer profile and there is no single Delphi application profile. Delphi:=diversity; It's the force behind Enterprise applications of all sizes, but is also used on rides at famous amusement parks, and tools on space missions, imaging equipment on search and rescue missions, is a favorite in Wall Street trading systems, and on and on. Some of these applications will benefit by migrating to .NET today, and there are some that don't have an immediate need. And when they do, Delphi will make it easier than any other development tool to get an existing application moved onto .NET. Not only does Delphi 8 include a .NET version of VCL to make migrating existing Delphi applications easier, language syntax is preserved, and additional features are included to make building hybrid applications simple. For example with unmanaged exports you can build new .NET assemblies that can be directly called from existing Delphi Win32 applications without adding COM or Web Services wrappers. So existing applications can even start to take advantage of .NET incrementally if desired.

Delphi .NET should be the first consideration for any new application development project, but many existing mission critical Delphi Win32 applications will still be in operation years from now and yes, there will even be brand new Win32 apps developed as well. So continuing to support Win32 along side .NET makes sense and provides Delphi developers a distinct advantage. That's how we see it anyway. Of course we'll take it release by release but for now Win32 is still a first class Delphi citizen.