This week was an important one for the Google Wave team. The company finally removed the invitation-only beta status from the product, meaning that anyone can use it. It also made the feature usable from within Google Apps, whereas it was only previously usable in individual Google accounts. The problem is that it may be a bit too late for this innovative product to make a dent in the way that people communicate.

Google Wave was announced a year ago at the company's I/O developer conference. It promised to revolutionise the way that people talked to each other online. It could be seen as an evolved version of instant messaging, with dramatically improved functionality. People could talk to each other in synchronous real time conversations, but could also revisit these conversations, known as Waves, over time. They could include other people in conversations at any time, and allow those people to replay the conversations chronologically to see how they had developed. People could insert comments at any point in a conversation, and could see each other typing. Waves could be embedded as objects, and accessed in different places.



The problem is that Google didn't do the best job of explaining the service to people, admitted Lars Rasmussen, one of the people who developed Wave. The product was daunting to use in its raw form. Rasmussen said this week that the team had failed to explain in the hour-long demo of the product what people might actually want to do with it.

The other big problem for Wave is one of critical mass. The service is designed to replace email, and it's about time that someone did. The first email was sent 40 years ago, and while it might have worked well then, it hasn't worked very well lately. Spam, excessive CCing, formatting issues, the difficulty of bringing someone into an email conversation that's been going on for a while - all of these problems make it a hindrance rather than a help for many.

But everyone uses email. Unless you're very important to someone, sending them an invitation to a Google Wave that could possibly require them to set up an account before they can even use it is going to be time prohibitive, and will probably mean you don't get a response at all, other than, "just mail me, will you?"

Then there's the availability problem. Yes, Google opened up access to Waves in Google Apps this week, but only in the Premier edition, which means that if you're a small business wanting to get into Wave communications, you'll have to pay for it.

Isn't this a bit backwards? Surely, if you're trying to persuade people to use a product that you've already admitted has been badly marketed and which few of them understand, you're going to want to give them a free ride?

I have a free Google Apps account, and a personal Google account that I use only because there isn't a Google Apps version of Google's Reader RSS aggregator. All of my contacts are in my Google Apps address book, rather than my personal one, and while I live on the Google Apps version of Gmail, I never check my personal Gmail account. I've tried using Wave in the personal version, and it's such a pain to log in and log out again, or to access each account using separate browsers, that I rarely bother.

This leaves enterprise users to take the open source Wave service and run instances of it in their own organisations, but as we know, enteprises tend to be a little conservative, especially in areas such as communication, which are often beset by regulatory constraints.

In short, it's going to take Wave a little longer to get off the ground than Google may have hoped, if indeed it makes it into the mainstream at all. And that's a real shame, because the concept initially showed a lot of promise. 

Well, Apple's iPad was something of a letdown, wasn't it? The most anticipated product since the iPhone launched onto the global stage not with a bang, nor with a whimper, but with what can only be described as an embarrassed shuffle.

You could tell that things were starting to go awry even as Steve Jobs sat down in the comfy chair onstage to carry out the demo. He was scrolling happily through several web pages, blissfully ignoring the fact that the first one he went to - the New York Times - simply didn't work as it was intended. Why? Because apparently, just like its smaller brother, the iPad doesn't support Adobe Flash.



Tim Anderson wrote recently about the need to develop for the mobile Internet. Mobile search and location-based services will drive the mobile web. Mobile advertising has been growing slower than expected -- recently, research firm EMarketer anticipated a $1.1 billion spend by 2012. The financial downturn has slowed developments, but the potential for mobile Internet revenues is staring us in the face, nevertheless.

This is why Jobs' demo last Wednesday is so significant. The iPad is flawed in many respects. It has no camera. There are no standard ports on the thing. It costs more than many net books, and yet its operating system is locked down. But one of the biggest flaws is that without Flash, many of the sites that we would like to visit are not available.

Such is Adobe's chagrin that its platform evangelist Lee Brimelow published a list of websites including Google Finance, Disney, CNN, popular American media streaming site Hulu, and Facebook application Farmville. None of them were without Flash, meaning that none of them will work on the iPad.

Apple's decision to eschew Flash on the iPhone was irritating enough for Adobe, but to do it on a tablet device that Apple hopes will replace the laptop for many consumers sitting on the couch in the evenings is no less than a declaration of war. Adobe needs to promote itself in new markets like this one, where everything is at stake, and Apple is making it very difficult.

Adobe definitely has cause to worry. Apple's share of the mobile market is only 2.7%, according to research firm Strategy Analytics. On the other hand, it sold 99.4% of all mobile applications last year. People buying Apple's mobile devices use them in ways that users of other mobile platforms do not, and Adobe will be well aware of this, as will Microsoft, which offers the competing Silverlight technology.

And looming on the horizon is a potential game changer: HTML 5. This as-yet unratified technology is nevertheless being supported in its unratified perform in many browsers. It is vastly more functional than HTML 4. Web developers can display video using it, without having to resort to Flash. They can produce HTML-only pages that enable you to drag and drop anything, and edit any content. This is why Google Wave, the search engine giant's revolutionary new online messaging system, was built in HTML 5. It looks and feels like a desktop application.

HTML 5 cannot claim to do as much as Flash can, but it may do enough. Apple, which itself likes to dominate all aspects of its business, doesn't like it when other companies like Adobe dominate a single part of the online experience. What Jobs may have been imagining when he scrawled through that broken site last week was a world in which it used HTML 5 -- and in which Adobe was increasingly irrelevant.

What does that mean for IT professionals and web developers today? It means that understanding HTML 5 as it develops, and honing your skills in this exciting new technology, might not be a bad bet. As this new decade rolls on, you will find it looking more and more attractive on your CV.

At the Future of Web Applications conference earlier this month I spoke to Microsoft's corporate VP of the .NET Developer Platform, Scott Guthrie about ASP.NET MVC. Guthrie is a co-inventor of ASP.NET along with Mark Anders, now at Adobe. A few months back I wrote a piece entitled ASP.NET MVC rescues Microsoft's web platform, but I wanted to hear from Guthrie how he sees the framework evolving, and to explore whether it is time to abandon the older Web Forms approach. How does he see the future of the platform?

"The amount of buzz and religious fanaticism about [ASP.NET MVC] is amongst the highest I've been involved in, certainly since .NET 1.0 and Silverlight. Some people prefer the Web Forms model  and I emphasise that Web Forms is not going away, there's all the new stuff that's coming for Web Forms 4.0.

"MVC is an alternative way to do UI and still leverage ASP.NET. For crowds like the one here at FOWA that wants total control over the markup, and who like test-driven development, it's a dream framework. Those folk tend to be more online, so they communicate better which is part of the reason you hear the buzz. I think we'll have more than a million developers using ASP.NET MVC within the first twelve months."

In your talk you mentioned the stackoverflow site which performs very well but runs on not very much in terms of hardware? Is ASP.NET MVC more efficient than Web Forms?

"ASP.NET itself has always been really fast, we've had a lot of success with large sites. One of the things people like about ASP.NET MVC is that the model fits to what they are expecting, for the large LAMP contingent which is heavily represented at this conference.  And when they do the performance testing they say 'Holy cow, this thing is fast.'  Stackoverflow is a great example, written I think within three weeks and scaling to that level with two machines. Performance is a feature, and one of the reasons StackOverflow works as well as it does is that it's instantaneous response time.

"Conchango just did a site, implemented in 20 weeks, a giant ecommerce project, it's 100% ASP.NET MVC. The SEO is phenomenal, the YSlow rating is phenomenal, they're just blown away. It was fun talking to them last night - the guy was jokingly saying, 'I can't believe it works so well'. It's like the best marketing literature in the world times ten. More and more when I give talks I'd say half the people are new to ASP.NET MVC, and the other half come upand say, 'by the way we've done five sites on it.' That's great to hear."

On equivalent hardware and leaving aside different coding styles, is ASP.NET MVC going to scale that bit better than Web Forms?

"No. The reality is you can build hugely scalable sites with each. Where it does help a little bit is that there is smaller page size and there's a bit more control. There's less abstractions."

And the page lifecycle is shorter?

"It is shorter. I don't think that's making any measurable perf difference. It's more that it naturally flows to what they're doing. I do think it's fast, in the same way that web forms can be fast too. But it promotes a certain way of working that, if you know what you're doing, you tend to build really fast apps."

What about the open source aspect? Are people contributing code?

"People are not contributing code directly to ASP.NET MVC, but we're shippling JQuery and we're shipping JQuery validation which are open source projects, and we are integrating them into our code. With JQuery in ASP.NET MVC version 1.0 we just shippped it, whereas in version 2.0 we have helper libraries that are making big usage of it.

"I'd say that's a first for Microsoft, we're actually taking open source software that has multiple contributors, and using it in a deep way within our own product.

"We ship the ASP.NET MVC source code under an OSI Licence. You can take the code, you can modify it, you can do builds. I know a few people that have done customer tweaks, but for the most part it's that people like being able to learn the product through the code. There's also the reassurance of knowing that if they ran into something, they could fix it."

Would you consider accepting community contributions to the code?

"We've thought about it. I think a lot of people interpret open source as 'hey, anyone can just submit stuff'. The reality is that pretty much every open source project has a closed set of contributors. They come from multiple organisations or backgrounds, but you don't check anything into the Linux kernel without Linus or Andrew signing off on the fix. That would be true of ASP.NET MVC, in that there would be a core set of contributors. At some point I think we will probably open it up to let people to contribute code, or at least patches."

What's new in the latest ASP.NET MVC 2.0 preview?

"The ability to easily do forms validation for input, server-side and especially client-side in a very declarative, easy way, is a huge productivity win.

"'Areas' provide a way to take a large project and easily structure it into multiple small projects.

"New form helpers and what we call editor and display templates for customising them  is an innovative way to get strong typing, intellisense and debugging support, and a lot of flexibility in terms of UI generation.

"Asynchronous controllers allow you to call call services on the web, the Twitter, the Facebooks of the world, and  much more efficiently  scale your web server. The classic problem if you're calling Twitter is what's the response time of Twitter? What's the response time of Facebook? Most web servers are multi-threaded so they're processing multiple requests, but say they have 10 threads running and 15 requests come in, and each of those requests need to go and access Twitter, you're going to block 5 people while nothing is going on on the server. With the Async support we provide a way that you within your app can say, I'm going to wait for a while, yield back the thread, and when the data comes back reschedule me. It can dramatically improve the scalability of the site.

"We're doing a bunch of work around helpers for caching, paging, and a other things. In general it's a compatible release, we're trying to listen to the community, keep it a very transparent, Agile-based development process and knock off the top asks.

"We ship the source to every preview, take lots of feedback. That's the other thing people have really liked about the project, this open feedback. They don't feel like we're telling them, here's the way it is, take it or leave it. They like the fact that we've been iterating with them."

Guthrie is diplomatic about the question of Web Forms versus ASP.NET MVC, and even though I pressed him, would not quite agree that it performs much better. Clearly Web Forms is not going away. Take a look though at some of the comments from practitioners like Howard van Rooijen of EMC (formerly Conchango):

One of the great aspects of ASP.NET MVC is how lean and clean the architecture is - there is so little background noise compared to WebForms; possibly the best illustration of this is the difference between the MVC Request Pipeline vs. WebForm Page Lifecycle. The number of hoops you are forced to jump through in WebForms, compared to MVC is quite staggering.

Overall I heard nothing to change my general opinion, that if you can use ASP.NET MVC rather than Web Forms, you probably should.

Last week Sun launched JavaFX, its Java-based platform for Rich Internet Applications. Sun picked up the high level of interest in Adobe's Flash as an application runtime, and perhaps Microsoft's Silverlight as well, and hurriedly developed its own equivalent. JavaFX is a new scripting language that runs on the JVM (Java Virtual Machine) and is optimized for graphical effects and multimedia. It brings to Java animation features like timelines and motion paths, support for a variety of audio and video codecs, and a way of coding a graphical user interface without the supposed complexities of Swing with its Model/View/Controller (MVC) design. JavaFX applets can run within or outside the browser. One innovation is that you can drag an applet out of a web page and onto your desktop. If you close the browser, the applet keeps running, thanks to support for out-of-process plugins in Internet Explorer 7 and Firefox.

So far JavaFX has received a mixed reception, and it is easy to see why. The launch was rushed, and some early visitors to the site had a bad experience, with videos that would not play or samples that did not run. Videos running in JavaFX flash unpleasantly if you resize the browser. The install experience is not as smooth as for Flash or Silverlight in my experience, because you need to install the Java Runtime Environment (JRE) as well as the JavaFX plugin. The download size is larger, although this is disguised by Sun's slimmed-down initial install. The idea is that you get up and running quickly, while the rest of the JRE installs in the background. The SDK does not yet run on Linux or Solaris, although the applets themselves should run because they only require the standard JRE plus a runtime jar (add-on library) and can be executed using Java Web Start. The latest NetBeans has JavaFX support, but another downer is the lack of any dedicated visual design tools. Sun only offers an export add-on for Adobe's Photoshop and Illustrator, or a converter for SVG (Scalable Vector Graphics). There is no 3D API yet, though it is promised.

It is easy to be negative; but some of these problems will disappear as JavaFX matures. A visual design tool is in the works, as is a mobile version that will be shown at the Mobile World conference in February next year. JavaFX will have a place for Java developers who are envious of what Flash and Silverlight can do. While it may not match Flash in terms of broad runtime deployment, I'm guessing that Sun will outpace Microsoft in this respect. JavaFX also has a couple of advantages over Flash, including more sophisticated client-side security and better code performance in some scenarios. The Java VM is mature and well optimized. Adobe's ActionScript virtual machine does have a just-in-time compiler, but seems slower than either Silverlight or Java for code execution. Speed of graphical effects is another matter, and while I have not seen any comparisons yet, I suspect Adobe's long multimedia experience may come into play here.

JavaFX will be welcomed then by Java developers who need more expressive graphics in their applications, and will be an interesting option for those developing games for mobile devices. Try as I might though, I'm finding it hard to believe that this is a huge section of the market, or that Sun will have much success persuading designers to target JavaFX rather than Flash, or that JavaFX will win much market share from Adobe for web-hosted video. Swing works well these days, its MVC architecture has merit, and it is well-suited to the kinds of Enterprise applications which commonly have Java clients. JavaFX is a useful addition to Java, but I doubt that Adobe is losing sleep over its likely impact. That said, I'm keen to hear from developers with plans for JavaFX applications, so don't hesitate to let me know.

Adobe's MAX conference in San Francisco this week was focused on what it calls the "Flash Platform", a technology stack oriented round the Flash multimedia runtime. The "platform" word highlights the fact that you can code for Flash and have your application run everywhere that Flash runs, including Windows, Mac, Linux, and some mobile devices as long as they are not from Apple. It is not a complete platform, being essentially an Internet client, though there are some server-side pieces such as LiveCycle Data Services, to simplify and optimize communication between Flash clients and Java middleware. You can also blur the distinction between browser and desktop with AIR, which runs Flash outside the browser and adds a local database engine.

So what's new? There was the usual set of announcements. The key ones are as follows:

AIR 1.5: an update to the desktop runtime which adds support for Flash Player 10 features such as Pixel Bender, for runtime graphical effects, and an option to encrypt local databases. There is also the SquirrelFish JavaScript interpreter - though this only comes into play if you are running JavaScript within HTML, rendered by WebKit, rather than ActionScript without the Flash runtime, which has its own just-in-time compiler. AIR 1.5 is available now.

A new version of Flex and the Eclipse-based Flex Builder IDE, code-named Gumbo. This has a new skinning and component architecture, more advanced text rendering, easier two-way data binding and a new Client Data Management (CDM) feature which from early descriptions looks reminiscent of a .NET dataset. You work with data on the client, storing updates locally, then zap the updates back across the wire in a single update operation. One thing that is not yet clear to me is the extent to which CDM requires LiveCycle on the server; I'll be sure to clarify this in a couple of weeks at MAX Europe (I was not present at the US event). The database aspect is significant, because so many enterprise applications boil down to CRUD (Create, Retrieve, Update, Delete) in one form or another.

Catalyst, formerly code-named Thermo, was previewed. This is a fascinating product which converts Photoshop artwork into Flex code; it also allows designers to create and preview a degree of interaction in their designs. Catalyst shares the same project format as Flex Builder. Again, I will be taking a closer look at MAX Europe. Here's a preview screen grab:

 

Cocomo (yet another codename) is a cloud effort from Adobe, focused on conferencing. Adobe hosts the services and provides Flex components to enable file sharing, text and VOIP (Voice over IP) chat, whiteboards, and data messaging; there is also user management built in.

Alchemy is a tool that converts C/C++ code to ActionScript, for execution within the Flash player. It's intended for re-use of existing libraries, not for general development.

Third-party announcements that caught my eye included Ensemble's Flex add-in for Visual Studio (though I was underwhelmed by the preview), and Zend's addition of AMF (Action Message Format) into its PHP Framework. AMF is a binary format that optimizes data transfer between servers and Flash clients.

Although none of these announcements is spectacular in itself, taken together they show the momentum behind Flash as a client for applications as well as video and multimedia, as I have mentioned here before. A good thing? Designers love Flash because of the freedom it gives them, along with the excellence of Adobe's design tools - Creative Suite 4 really is spectacular. Nevertheless, I have a nagging concern that if we adopt Flash rather than AJAX - interactivity in HTML and Javascript - for our next-generation clients, we are giving away the openness of the Web, because Flash is proprietary technology. I recommend this thoughtful post from Google's Brad Neuberg, which recommends not only open-sourcing the Flash runtime, but also integrating it more deeply with the browser and embracing web standards. There's little chance of Adobe adopting Neuberg's proposals, but he does a good job of spelling out the issues. Flash is compelling, as is Microsoft's Silverlight, but each is controlled by a single vendor. Do you think that matters? I'd be interested to hear your opinions.

 

The world's biggest software company is gearing up to tell you how its new modelling platform will transform developer productivity. Modelling is meant to make programming easier, by expressing the design of an application in easily understood diagrams rather than in a bunch of complicated C++, C# or Java files.

The snag is that while models are a great way to design, describe and communicate how an application works, in the end someone still has to write the code. Smart people have made immense efforts over the years to fix this by integrating the code with the model: generating code from models, generating models from code, or even devising ways to execute the model itself.

While these efforts have not failed completely, model-driven development has never taken off in a big way. Developers figure that they have enough trouble writing and debugging code, without taking on the burden of keeping a complex model in synch, or learning the mysteries of Model-Driven Architecture (MDA), with its PIM, PSM, MOF, OCL, ODM, SPEM and so on - have a look at the Object Management Group (OMG) if you want to know more.

Now Microsoft is having another go. Code-named "Oslo", the project includes a store, a language and various tools; and it's going to figure in a big way at the company's Professional Developer Conference next month. Some details are already trickling out. Posts from Don Box and Doug Purdy explain it in simple terms, and this eWeek article has a bit more. The modelling language is code-named D, and I suspect it is another role for XAML - see my post on 10 things you might not have known about XAML if you thought it was just for building GUIs and Silverlight applications.

It would make sense for Microsoft to use XAML, since it is a flexible textual language that is designed to play nicely with visual tools. I'm guessing that you will be able to create the model visually and then run it, just as MDA promises. In a video, Senior Vice President Bob Muglia says:

When a model is created, it's possible for the business process to run directly with very minimal procedures being created around that. The model is the centre of the universe.

There are also hints that Oslo will tie in with Microsoft's cloud computing initiatives - maybe Live Mesh or some more business-focused variant.

Will it work? Microsoft is certainly serious about it. It has even joined the OMG, despite years of antipathy, though I hope this does not mean Oslo will be as complex and unsatisfactory as MDA. I see it as model believers getting together, and a way for Microsoft to get more academic and enterprise credibility for its initiative.

There are however plenty of reasons to be sceptical. Microsoft has had numerous modelling initiatives over the years. In Visual Studio 2003 it was Visio and UML. In Visual Studio 2005 it was class diagrams, Domain Specific Languages (DSL) and Design for Deployment, a way of taking deployment constraints into account before and during development. This article explains the strategy, and enthuses about software factories as the way forward. Now there is Oslo, which looks like a brand new approach. Why think this will succeed any better than what has gone before? Why think that Microsoft will achieve what the fine minds at the OMG and its industry partners have failed to do?

There is also little evidence that this is driven by customer demand. When I talk to Microsoft developers, I don't hear many asking for better modelling tools; and if the subject does come up, it is usually a request for more standards-compliant and up-to-date UML diagramming, not full-on model-driven development. This is a top-down initiative.

Count me a sceptic then; but I also want to give Oslo a fair assessment when it is unveiled next month. It is quite simple. If Microsoft can deliver a modelling platform that really does simplify rather than complicate software development, and one that does not impose a heavy performance burden, then developers will love it. The big question: what is the chance of that?

The first week of September brought the most interesting tech news for ages. The reason is Google's launch of a new web browser, called Chrome, which has stolen the thunder from Microsoft's beta release of Internet Explorer 8. The browser wars are back, and with Firefox, Safari, IE, Opera and now Chrome, users have more choice than ever.

That's all very well for consumers, but will this make any difference in the Enterprise world where IE still reigns supreme? It is hard to see this changing soon. Web designers hate IE for its poor standards support (though this is much improved in IE8), but it has plenty of attractions for system administrators, integrating with Microsoft's system management tools, controllable through group policy, and easily kept patched with system update services.

All this is true; but having played extensively with Chrome over the last few days I think it will have a wide impact. For a start, like Google search and Google mail it will leak into enterprises simply by user choice. A remarkable feature of the Chrome install is that it does not trigger Vista's UAC (User Account Control), because it writes only to areas within the user's profile. Put another way, it does not require administrator rights to install, so machines will need to be tightly locked-down to prevent it. A web site might say, "best viewed with Chrome", and the user could have it installed and running a couple of minutes later.

What is more significant is that Chrome has the potential to change expectations over what a browser application can be like. Chrome includes Google's Gears extensions, which means browser applications can save files locally, run a local database, or even run off a local web server when offline. Another interesting feature is that Chrome can install a desktop shortcut to a web site, and that sites opened from one of these shortcuts appear in a full window without any browser controls at all - without any "chrome", in fact. This is by design. If you put the offline capabilities of Gears together with desktop shortcuts and a window that does not look like a browser, then you get something that users will not easily distinguish from ordinary Windows software.

 
Spot the difference: this page was opened from a Chrome shortcut and has no browser furniture.

With skilled coding, such applications can look good and perform well. The V8 JavaScript engine compiles to native code, and is designed to handle applications larger than today's AJAX sites. The Canvas element in WebKit, the rendering engine used by Chrome, enables flexible 2D graphics without the need of a plug-in. What Google has done is to raise the bar for web applications, letting them compete more effectively with old-guard software like Microsoft Outlook.
 
Personally I won't be ditching Microsoft Office just yet. Still, I respect what Google has achieved with Chrome even in this first beta, and I like the fact that the code is open source; anyone can download it and compile their own build in Visual Studio 2005. It is early days: but my guess is that we will see a lot more of Chrome in the coming months and years. 

Ever since .NET burst onto the scene back in early 2002, Microsoft has promoted it as the primary platform for custom applications. For sure it has plenty of advantages, including automatic memory management, a modern programming language called C#, and a rich class library encompassing both Windows and Web development. The Windows Presentation Foundation, touted as the next generation of the Windows user interface, can only be programmed using .NET.

Unfortunately .NET also has downsides. The first is potentially troublesome deployment, thanks to the large runtime required. The problem has not gone away even though Windows now comes with .NET as standard, since new versions appear regularly. The second issue is performance. Although a just-in-time compiler enables .NET code to run at near-native speed, there is still a heavy memory overhead. The result is that .NET applications generally load and run more slowly than native code equivalents.

The trade-off here is that ease of programming compensates for slower performance. It's true; but not all developers realise that the choice is not only between C# and Visual Basic on the one hand, and the intricacies of Visual C++ on the other. Before turning up as Microsoft's chief architect for C#, Anders Hejlsberg worked at Borland on a language called Object Pascal and a development tool called Delphi. There is some family resemblance, particularly if you include Delphi's Visual Component Library (VCL), which wraps the Windows API with a class library that is equally as capable as the Microsoft Foundation Classes, but much easier to code against. Unlike Microsoft's .NET tools, Delphi compiles directly to native code, and it is feasible to create applications that have zero dependencies, run like lightning, and work on versions of Windows right back to 2000.

Delphi's recent history has been unsettled. Borland delivered some unsuccessful .NET editions and messed with the IDE. The Delphi side of the business was then spun off into a separate entity called CodeGear, which was recently acquired by Embarcadero, best known for database design tools such as ER Studio. Fortunately the compiler remained as good as ever, and the signs are that Delphi's new home will be good for the product. The company has just released Delphi 2009, the first version with proper support for Unicode. A companion product called C++ Builder has the same VCL, but uses C++ in place of Delphi's Pascal variant. These releases also introduce language enhancements including generics and anonymous methods.

Delphi is not the answer to every software problem, and its documentation is poor compared to what you may be used to with MSDN, but in the right context it works like magic. Aside from .NET, every corner of the Windows API is open to it, including services, native code DLLs, COM components, and fiddly software like custom actions for the Windows Installer. The Delphi IDE is once again mature. If you have ever looked with horror at the tens or hundreds of megabytes demanded by .NET for your small Windows Forms utility, or found yourself troubleshooting some obscure problem installing the .NET Framework, Delphi is well worth investigating.