Meditations on programming, startups, and technology
New Relic

Desktop Applications are not dead!

In his article, ”Desktop Applications are Dead”, Eugueny Kontsevoy – a Windows developer – argues sarcastically about the demise of Desktop applications. His article has real merit though and focuses almost exclusively on the problems which are introduced by Vista’s aggressive security policies. The annoying aspect of Windows Vista’s “cancel or allow” is undeniable, especially if seen through the eyes of an Independent Software Vendor (ISV, or in the case of a one man show, a Micro-ISV) who needs to convince the customer to download his program and install it in order to try it before buying. Every customer who gives up on installing your program is a possible lost sale. In a world where Windows users are already afraid to compromise their operating systems, the ability to make a sale needs to be preserved and defended; any extra barrier is harmful for multitudes of software vendors. Here Kontsevoy is damn right about this factor.

From DLL Hell to .NET Framework Hell

Eugueny even has a point in regards to applications which are developed with the .NET Framework. It is a necessary requirement of C#, VB.NET and managed VC++ .NET apps that you install the .NET Framework. You can’t just pick an arbitrary framework version either, depending on what language and framework features you employ, you may be targeting .NET 1.0, 1.1, 2.0, 3.0 or the currently in beta, .NET 3.5. Windows Vista ships with the redistributable version of .NET 3.0, therefore it is safe to assume that a developer will be able to run their applications on Vista if they target .NET 3.0 (Visual Studio .NET 2008 Beta2 allows you to define a target for you project, from 2.0, 3.0 and 3.5). .NET 3.0 incorporates Windows Presentation Foundation and with some design skills and the most colorful .NET book around (Windows Presentation Foundation Unleashed- easily the most eye pleasing book I own) you should be able to create attractive User Interfaces and be happy, right? Not exactly. I don’t have any hard numbers, but I would guess that the majority of users are still running Windows XP. The SP2 of Windows XP has an optional .NET 2.0 framework installation (not 3.0 though) so you’d be out of luck even if the user did install the optional component. From a business perspective you have to remove any possible barriers between your product and the customer. You absolutely need to maximize the number of people who successfully try your program in the hopes that they’ll love it enough to shell out their hard earned cash and actually purchase a copy of your product.

It would make sense then to target the .NET 1.1 Framework, as it is the most widespread version, plus applications written for 1.1 will work on .NET 2.0, 3.0 and all subsequent versions. But programming for 1.1 means not using any of the cool features that Microsoft introduced in C# 2.0, it means using Windows Forms 1.1 and being stuck with a rather primitive version of VS.NET (2003). It also means that you won’t be able to take advantage of many commercial and free third party components whose minimum requirement is Microsoft .NET 2.0. C# 3.0 and LINQ (both available only in .NET 3.5 require .NET 2.0) make for great blog posts and can raise a hell of a buzz, but they won’t help you too much when it comes to maximizing your profits – at least in the commercial/shareware sector at this time. This cycle will be repeated when newer version of .NET come out and new innovations (be they copied or original) are introduced by Microsoft. Vico was definitely right, history does repeat itself. There are attempts like ClickOnce deployment to solve these problems, but they raise other issues, and as far as I can see it, there is no definitive solution right now.

.NET is not the only option

Microsoft produces the most popular operating system in the World. It is natural then for developers to embrace the development solutions proposed by the maker of the OS that they are going to develop for. The marketing division of Microsoft is particularly good at attracting millions of developers, especially if we consider that they can afford to produce highly productive and decently innovative tools which are available for free or at fairly reasonable price tags. We all laughed when Ballmer shouted, “Developers, developers, developers…”, but when you think of Windows development nowadays, you are inevitably thinking about .NET. However, whether you view this as a pro or a con, ultimately it doesn’t need to be the only case.

If .NET imposes too many constraints on Independent Software Vendors, then we must not forget that .NET is not the only available option. It’s a personal choice, each company or developer can decide which way to go, but it is important to raise awareness about the potential alternatives. Sure, Microsoft produces Windows and should know better (in theory). Sure, they have a market cap of $271.65 Billion versus the few hundred million or less that most of their competitors reel in, but in the end, if .NET clashes with your business model, you have to consider looking over at the other side of the fence in order to find alternatives that fit you better. Let me make this clear, I’m not dismissing .NET for Desktop applications, I know full well that there are companies out there making millions in this market, while still using .NET.

A few potential alternatives to .NET

If you are aiming to develop commercial applications for Windows, be it the next Adobe Photoshop or a $15 utility, Microsoft .NET’s mainstream presence may give you an advantage. How so, you may ask. We’ve already exposed possible issues with .NET and this portion of the business of software, but the main problem in the end, is an inconvenient runtime which weighs you down as the right version of the framework has to be installed somehow before your application is able to work. A winning alternative would have to provide you with a stable environment which is affordable, as productive as its Microsoft counterpart, has a decently sized community and so on. But its main selling point would have to be that it needs to produce native Win32 executables. Doing so will be the secret advantage that an ISV holds over the majority of their competitors who use .NET. When you ship a really fast application in a single non-bloated .EXE file, you are embracing a meaningful percentage of the Windows market. The application will run on older versions of Windows, from Windows 95 up to Windows Vista, it will most likely feel more responsive and the lack of an extra layer which needs to be installed is going to enable it to be easier to install on your customer’s PC. The aim of maximizing your customer base will have been achieved from a technical standpoint.


Wait a second, didn’t Delphi die out many years ago? Not quite. What do the following applications have in common? Skype, MySQL Administrator, SQL Backup, Macromedia Captivate, Inno Setup, Borland Developer Studio itself, TOAD, Beyond Compare, Macromedia HomeSite, etc… You bet, they’re all written in Delphi. Delphi (the IDE) and Object Pascal (the language) have always been much more popular in Europe than in the States, but despite this, what almost killed Delphi was its management. Borland made a few crucial mistakes that cost Delphi a lot in terms of its popularity. It’s a typical scenario really, were a technically superior product (think of Betamax vs VHS, etc…) ended up being much less successful than a better marketed, but less valid alternative (e.g. VB6). The press has long spread word of Delphi’s imminent (or present, depending on where you’re sourcing your info from) death for almost a decade now, but Delphi is still alive and kicking. Sure, since .NET came along market percentage that Delphi covers has dwindled, but Delphi may be the right answer for the sorts of development needs outlined above.

If you speak to the majority of Delphi developers, you will notice that they are passionate and very convinced about the product they use. They may be a small group at this point, but it’s a good, endearing community. The other positive news is that Borland has separated their Developer Tool Group into a company called Code Gear. This company makes up 25% of Borland’s total income and they’re 100% focused on the promotion and improvement of Delphi and their other development tools. Delphi’s Product Manager, Nick Hodges, is very active in promoting the product and responding to people online. The buzz is slowly growing, and Delphi’s future is looking far more positive now than it has for quite some time. Code Gear may be the best thing to happen to Delphi in ages.

Code Gear Delphi 2007 for Win32 is a development solution for ISVs that doesn’t fall short of Microsoft .NET. The professional version sells for less than $900 (US). There are also two other editions that you can use for commercial products: Turbo Delphi Explorer (entirely free) and Turbo Delphi (for Win32) Pro which costs less than half the price of Code Gear Delphi 2007 Professional. The free version is mostly limited by the fact that you can’t add third party components, and Delphi’s market is full of these kinds of high quality components. I really think that for ISVs it is worth investing in the Delphi 2007 Pro version. Code Gear produces a version of Delphi which targets .NET as well, and while this may be good for interoperability (Borland Development Studio 2006 even includes C# Builder), I believe that Code Gear should really focus on Delphi for Win32 as that is the crucial element which distinguishes it the most from Microsoft’s offering. They should also work on support for Win64, Cross Platform development, and Unicode. All of these things are lined up and they’ll take care of them in future releases, but I’d say that even having to spend time developing further ASP.NET support in Delphi is somewhat wasteful. The idea of writing code once and then being able to compile it for both Win32 and .NET is nice, however most software developers who decide to go for .NET, would rather go directly with Microsoft rather than use Delphi. So instead just opt to do one thing, but do it right.

Within the market we defined above, Delphi 2007 for Win32 offers up speed which is comparable to C++, but with an ease of programming similar to that of Basic. And yes, the executables are “Vista enabled”. My number one choice, if you’re not adopting .NET, is to go with Delphi. If you decide to do so, you can start by watching introductory videos here. And if you’re skeptical about Delphi’s future, consider the open source Lazarus project which can produce Win64 executables and cross platform executables through Free Pascal. It’s not as polished as Delphi, so for Windows Delphi is definitely the way to go. Yet you could always port your projects to Lazarus in order to target Mac OS X and Linux when required. This also guarantees that your code won’t go to waste, should Delphi disappear in the future (very unlikely).

Unmanaged C++

C++ with MCF or WCL or whatever toolkit you prefer is an option as well. You can even use Visual Studio .NET 2005 for this. So what’s to question about C++, you may ask. Well, C++ is not for the faint of heart and I think that it is a few time slower to develop with than Delphi. But you get the same benefit of native programs and there is nothing wrong with this option – if you know what you’re doing.

Cross platform solutions

Beside Delphi and VC++ there are a few cross platform options available. The bad news is that none of them is as productive or polished as Visual Studio and Delphi are. Furthermore, cross platform applications have a tendency to look good but “not quite right”. Possible options in this category are Real Basic, Trolltech QT, wxPython and even Java. Keep in mind that Java has two big issues. It doesn’t really solve the problem of runtime (though it makes it much more manageable), and while UIs can look good, they are usually clearly not native in any operating system.

An important cross platform solution for both Windows and Mac, is the uber-popular pairing of Flex and Adobe Air. Again, you still have runtime issues and, on top of that, you don’t have native widgets on either Windows or Mac. However applications can look very sleek and sexy, and I think it was worth mentioning this possibility.

Windows is not the only option

I can hear you thinking that this doesn’t solve Windows’ Vista issues. We have shown alternative solutions that simplify the process of delivering software over the Web, but we haven’t addressed the main concern in Eugueny’s post. We simply can’t change Vista; its issues remain. Should we then conclude that Desktop applications are dead? I don’t think so. Most customers will eventually learn to work around Vista’s nagging (or annoying, depending on how you look at it) features and will end up installing the software that they really want one way or another.

Providing a solution that doesn’t require a runtime install on top of the application would be a way to make good headway, as we (the developers) have done all that we can at this point. But let’s assume, as absurd as it might seem, that Vista really does block the majority of customers from installing software. Don’t you think that Microsoft will be forced to do something to address such a worrisome problem? If they don’t, it could practically be called suicide. And let’s move forward, let’s assume that Microsoft ignores the problem and only 5% of the Windows user base will install Internet commercial software from an ISV. Does this imply that Desktop applications are dead? I don’t think so either, because what Eugueny failed to consider was that Windows is not the only operating system available. Sure, it’s hugely popular, but that alone is not a good enough reason to ignore the other possible markets. There are emerging markets for the development of Desktop applications on Mac and Linux. Especially on Mac, where there’re plenty of companies making a lot of money by producing native Objective C and Cocoa applications. And there are plenty of users paying for these applications. Heck, even for Linux it’s possible (albeit harder) to create and market commercial software. As long as there are millions of customers out there who’re willing to pay for Desktop applications which scratch a particular proverbial itch that they happen to have, the Desktop application market is not dead. Luckily.

Did Web 2.0 kill the desktop star? What if the average quality of the software for Windows is so low that users don’t even bother to go through the annoying Vista installation process? Even in a pessimistic scenario where Windows Desktop applications are no longer in fashion, the claim that ‘Desktop applications are dead’ is not supported. Why? Because all this doesn’t affect Mac OS X. Mac users enjoy good applications, they appreciate the effort it took to create well designed software, and many are ready to spend money for valuable tools that solve a specific problem. One could argue that even if the catastrophic situation forecasted in the article mentioned above was to come to fruition, we could only state that Windows Desktop applications are dead. And honestly, I don’t think this is ever going to be the case, because Windows users are not too different from Mac users in regards to purchasing software that they value (or pirating it). Most likely, Desktop applications will be redefined and they’ll continue to evolve as a consequence (or positive side effect) of the endless stream of ubiquitous Web applications. Many applications will be moved onto the Web, sure, but many others are here to stay. I wouldn’t declare a whole broad category of applications to be dead with such ease.

Desktop applications or Web Applications

Web Applications offer several advantages over ‘fat clients’, but a “Web aware”, well written and properly designed Desktop application can provide an experience that is in my opinion, superior to that which you can experience through your browser. I love many of the so called “Web 2.0″ websites, but I also love several Desktop applications that I would never want to see end up being moved to the Web. Integrated with the Web or synchronized on the Web, perhaps, but not entirely replaced by a Web Application. Highly interactive and responsive sites are cool, but let’s not make of Web 2.0 a hammer which is eagerly ready to consider each and every problem as a nail.

Google Reader is a good Web Application for example, but it’s not a replacement for NetNewsWire on Mac OS X. If the Desktop app is practically dead, how come this product got downloaded more than a million times in a niche market such as that of Mac? We need less crapware and more high quality Desktop applications on Windows. Users will be ready to click a couple of scary “allow” buttons if we produce software that is genuinely worth installing. It’s inconvenient that Windows developers have to deal with poor OS choices that may lead them to lose significant amounts of customers in the long run, but the market is big enough to economically justify this in many cases.

Feel free to port your applications to the Web, if there are concrete advantages to doing so, but despite the look of it, Desktop applications (perhaps as smart clients or any other evolution of them) are here to stay. I don’t want a Photoshop, a Visual Studio, an OmniGraffle on the Web, even if it’s technically possible to do so. Let’s not forget that the Web was born for sharing hypertexts. And while it’s fine and dandy that it’s evolved since then to a point where we’re now able to run applications through a browser, let’s not lose sight of what is better suited to a browser and what’s not. Desktop applications are not dead. Even if in ten years there may be a convergence of web applications that look like Desktop applications, and Desktop applications with many of the advantages of Web applications, Desktop applications will still have a florid market, so long as we aim for quality, usability and web integration.

If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

receive my posts by email

37 Responses to “Desktop Applications are not dead!”

  1. Darrel Davis says:

    Excellent article. I agree that desktop applications are not going away and that for several functionality sets, web applications probably wouldn’t work. I have been a software developer for nearly twenty years and a web developer for the last 10.

    As a ‘wannabe’ MicroISV I researched (probably too much) this toolset problem. Based on market size and penetration in the market I’ll be selling to, I decided on a Windows application. Then came the tool choice. Since I had programmed for Windows in the (ancient) past, I had some idea how it worked. I found that, except for unmanaged C++, Microsoft has effectively removed the option of producing native Win32 applications. What a shame. Regardless of what I was told, I am sure the .Net frameworks downloads would have very negative effect on sales in my chosen market.

    I also had some past experience w/ Delphi and after looking around at several other options, I went with it. I purchased Dephi 2007 for Win32 and, other than some IDE ‘wishes’, I’m very happy with it.


  2. I can agree that Desktop Applications still are here to “stay” but I think that most people claiming that Desktop Apps are DEAD are exaggerating quite a bit. Though I DO believe that Web Apps will take a significant portion of desktop apps domains just like when .Net came around it took a great portion of Win32 apps and so on…

    I think they’ll more be in a symbiosis than opponents…!

    And that’s the point you fail to see…. ;)


  3. [...] Desktop Applications are not dead! «What do the following applications have in common? Skype, MySQL Administrator, SQL Backup, Macromedia Captivate, Inno Setup, Borland Developer Studio itself, TOAD, Beyond Compare, Macromedia HomeSite, etc… You bet, they’re all written in Delphi.» (tags: Delphi Windows developer software) [...]

  4. @Thomas Hansen

    I actually see the “symbiosis” point, Thomas. :) In fact, in my conclusion “web integration” is indicated as one of the three fundamental aspects of the future of Desktop application (i.e. quality, usability and web integration). ;-)

  5. Nate Kohari says:

    Great article! One thing though… version 3.0 of the .NET framework can be installed under XP via Windows Update, and can be bundled easily into an application installer.

  6. Thanks Nate. It is true that 3.0 is available through Windows Update and many installers can bundle it as well. Windows Update can be quite a pain though, because I believe (correct me if I’m wrong) Windows will install many other critical updates before allowing you to install the optional .NET 3.0.

    On the other hand, bundling it in an installer makes things easier but the download is going to be larger and the installation process will require an extra step (which could potentially go wrong) when compared to a Win32 app. As I said in the article, this is not the end of the world, and it’s a perfectly acceptable option. But if you are targeting the non-geek crowd with your application, this is a possible disadvantage.

  7. Collin says:

    What an insightful article, Antonio! I hadn’t really been considering Delphi much, but after reading your article, I’ve got to admit you’ve really given me a fresh perspective on it. I’m going to pick up a copy of Delphi for Win32 now that you’ve brought it to my attention. Thanks again, man.

  8. Antonio, great article and thanks for a good dose of enthusiasm! While you certainly covered the aspects of engineering tools that are available (and I am checking out wxWidgets with D language), you did not address my second point that actually should have came first:

    Most Windows Desktops are zoos (or should I say jungle?) where your application will have to fight in order to survive. The amount of 3rd party “crapware” that average people have installed is unthinkable. As I mentioned in the article, most NEW computers start off already partially disabled: you are going to lose a substantial amount of your users just because some unknown shareware version of anti-spyware program decided to throw its own “Danger! Danger!” dialog box in the mix of standard ones a user must face.

    In addition to that, the state of most Windows machines, especially those that have been running for a while, say 2 years, without professional “assistance” is absurdly bad: registry is a mess, reboot times are ridiculously long and (real life example) Windows Installer tries to repair Microsoft Office every time a user touches your application. Another example: standard way to parse XML on Windows is to use MSXML library which is a COM server. Even .NET parsing is just a layer on top of that. I have seen machines where COM registration information for MSXML object was damaged in the registry. Simply re-registering the component fixed it.

    Mind you, I am talking about mainstream users, not developers machines (that we usually take a good care of). My point is that Windows is a very fragile platform that people are learning to avoid messing with. Windows makes it HARD for users to explore various software options. Can you honestly say that you would be comfortable installing and uninstalling 50 random desktop apps in one day? I use VMWare for that.

    Sure, all these issues can be “addressed in code”. One can always plan for deployment and design with minimum dependencies, but that always reduce your options and ultimately decreases productivity. At my current job we have 3 engineers writing the actual code and 1 full-time engineer responsible for installers. That is 20% and I call it insane.

  9. Ankur says:

    To the best of my knowledge skype is written in QT/C++ not in delphi

  10. @Ankur

    Skype on Windows is written in Delphi. QT/C++ was employed for the Linux version. :)

  11. vic says:

    D is better than Qt/C++, looks like java, and works w/ wxWidgets (wxD).

  12. Liz says:

    Calm down Shakespeare, it took me an hour to read that. =)

    But I agree with your points and the other various comments, all in all, it was an excellent post.

    I see you are a ‘technical evangelist’, just a thought, Codegear should consider hiring you as their evangelist, because yours was the best advocacy piece on Delphi I’ve read to date. You made a passionate case for delphi and to think, I was planning to go with c# and .net. Damn you, you’re going to cost me $900! =)

  13. @Eugueny Kontsevoy

    I agree entirely with you, Eugueny. Successful deployment of applications for Windows can be problematic. We all know that Windows is not a particularly reliable operating system and that end users, whose machines are running Windows, often end up with a very messy configuration of their operating system.

    Windows problems have a real tenancy to discourage the user from experimenting with new software for fear of compromising their Windows set up. This is absolutely true and it exposes (in contrasting beauty) the way that Mac OS X operates. With Mac and an unprivileged user account, you can locally install applications with a simple drag and drop, usually without compromising anything.

    I tried to see this from an ISV viewpoint though, and I realize that Windows runs on 90%+ desktops, so despite its problems, if I were to write a nice application that is better suited for desktops, I would think twice before excluding Windows users from my customer base.

    I think that selling desktop applications that’ll run on Windows requires a little more effort because the market is very crowded and it’s easy to slip by unnoticed when everyone else is literally shouting to be heard. Couple this with the fact that there is a certain fear of compromising Windows on the buyers’ part, and what you get is anecdotal evidence that many ISVs who sell cross platform software, report as much as 40% or 50% of their sales from the Mac community – despite the tiny portion of the market which is actually represented by Macintosh. It is very possible that this is also influenced by the fact that Mac users are more prone to experiment, knowing that it is safe to do so. But it’s not an overly drastic scenario either, considering that usually the majority of sales still come from Windows and millions of applications are bought for Windows every day.

    I would consider Delphi to be the best option if you want to have a high level of productivity and minimum amount of dependency on Windows. It’s not the solution to every problem, but for those who need to develop in Windows because their business plan requires it, then Delphi (for win32), in my opinion, offers a sound solution which is about as good as it gets nowadays, unlike .NET.


    Haha, thanks Liz and sorry for the verbosity.

  14. [...] Are Desktop Applications dead or not? Antonio Cangiano blogged a response to a claim that Desktop Apps are dead: Desktop Applications are not dead! [...]

  15. Nick Hodges says:

    Antonio —

    Hey, thanks for the nice comments. We appreciate you pointing out what we are up to and that we aren’t dead. ;-)

    Delphi is a great and proven answer for desktop applications, but I do want to stress that it is a lot more than that as well. It’s great for multi-tier apps and web applications as well as SOAP, and almost anything else you’d need.

    It’s almost always true that if you need to build it, Delphi can do it.

    Nick Hodges
    Delphi Product Manager

  16. Snorkel says:

    Lightning Admin for PostgreSQL and MySQL is compiled with Delphi 2007, check it out at

  17. [...] gals), tell me really.  There is a meme going on right now that desktop software is dead and no it isn’t (sounds like the fights my kids have over the computer … my turn … no my turn…), [...]

  18. Xepol says:

    Web 2.0 is a bunch of cute tricks to make a website look pretty, but it just takes one internet connectivity problem with a mission critical app (what apps does a business use that isn’t mission critical, really?) to convince them that the old desktop paradigm is alive, well and the course of sanity.

    Not being able to get your work done because of some guy with a backhoe, a company with a contractor dispute, a 13 year old learning all about denial of service attacks, organized crime learning about service attacks or some monkey in remote server room flipping switches blindly isn’t going to sit well with anyone (or a million other things that can and do go wrong). Sit back, and pay your staff to idle, and write a memo about how desktop apps are to be reinstated tommorow (with a pen if you unwisely outsourced your text editor and it was the part that failed).

    And don’t even get me started with information privacy. How can you possibly do your due dilegence for security when you don’t even know where things are located, let alone have any rights to inspect them?

    Of course, you could probably purchase a server license and run a server in house that does that, but trying to manage that backend will inevitably outsize the need to manage desktop software (either you are small and its cheap and easy to manage the desktops, or you are large enough that the server backend becomes a real monster to maintain – what you gain in not having to maintain on a per station basis you can easily loose in server support, hardware, network bandwidth, and gods help you – a browser update)

    Grandma might be able to store her recipies on line, and billy might be able to write his bookreport in an online editor, but you could starve to death on what they’ll pay for it. The first time a university student find out that the local network won’t support him/her and 100 other classmates all writing a term paper online while everyone else downloads porn, music, movies, causing them to loose 10 hours of work is the day Microsoft gains a office customer for life.

    Like I said, Web 2.0 is cute, but unless everything about the internet changes, it will remain a fringe market destined to serve information webpages and google ads and non-critical items like social networking.

    Don’t agree? Remember the last time your messenger died? Remember how lost you felt? Now imagine your office tasks that pay for your living did the same thing.

  19. [...] pelo mundo eram feitos em Delphi. O exemplo mais famoso é o o Skype. Hoje me deparei com um artigo onde estão listados alguns outros programas feitos em Delphi, [...]

  20. Adrian Madrid says:

    Have you considered RealBasic? I have not used it yet for anything _real_ but the crossplatform capabilities are very enticing.



  21. Rick Romero says:

    I would have at one time agreed that Delphi is a great tool. As a matter of fact, I would still recommend Delphi 7 to anyone doing desktop application development. Fast IDE, good documentation. Unfortunately three recent releases of Delphi have been horrible. The lastes, Delphi 2007 for Win32 is only marginally better. My IDE still crashes regularly, and that is after one Service Pack. I’m afraid CodeGear has a lot of ground to make up for botched deliveries. I do have hope however.

    In the mean time, Visual Studio seems very stable and mature. Once the Framework is installed the user doesn’t notice or have to think about it. As far as they know they are just running a desktop application.

    My $.02.

  22. K.A. says:

    Deployment has always been the cons of Microsoft development solutions.

    The Other thing about .NET – which nobody mentioned – is that you must consider deploying third party component assemblies the way you had in old OCX times! This is where you will go ‘OH MY GOD! Which One do I have to deploy? How many assemblies does Crystal Reports Need to run on the target machine? And How Big is it? I have a simple one page report, but I have to deploy 10 MB to make it work! …’

    Delphi does not have this problem @ all because:

    1- It has the static linking built in the linker (For those who don’t know about it, it means every piece of code required will be bundled in your EXE, and the single EXE will be sufficient to run, not needing ANY external library)
    2- It’s applications do not need to register OCX’s in installation process, and of course they don’t need a Microsoft Installer technology to be deployed.
    3- You can always use InnoSetup to deploy your applications, which of course is written in Delphi, and is absolutely FREE and OPEN SOURCE!

    More Pros about Delphi:
    1- Better Database Connectivity Both in Run-time and Design-time (And a VERY GOOD third party support for both Data connectivity and Data controls)
    2- A superb Visual Forms designer supporting Visual Inheritance in design-time
    3- Well thought framework which will eventually help you use best coding practices
    4- Delphi’s VCL (Visual Components Library) is Open source (Not free, but Open Source!) It means you don’t have to wait for the Guys in Microsoft to consider your reported bug, and then decide [not] to fix it! You find a bug in VCL, you can fix it yourself. As a result, almost all 3rd party components in Delphi world come out with source codes. This is called good spirits!
    5- Code written in Delphi 1 in 1995, still is compatible, and compile (Most times without the slightest change) in Delphi 2007. This is what is called Compatibility in Delphi world.

    Many of the points above may seem unfamiliar, unreal or exaggerated to Microsoft world of development tools, but they are true :)

    I used MS Visual Basic 6 for 4 years before I find about Delphi, and I consider those years as lost and wasted years of my life!

    As a matter of fact, I’ve rewritten many applications written in VB6 and Java, where Delphi has proved to be about 5 to 10 times more productive (We’ve even done 90 man/months failed projects in 2 man/months with greater feature-sets), the code was easier to maintain, setup file was always smaller (2 to 10 times for JAVA+Eclipse!) , and there was always a very helpful community behind the scenes to support your problems!

    Many web-aware applications I’ve rewritten used Tomcat and other Huge Frameworks like .NET, with thousands of framework files and complex installation processes, where they were changed with a simple SINGLE-FILE 2MB server ISAPI, with a 3 lines installation guide. I have many customers that worship Delphi Now! (Which I don’t actually, I use some other languages for life)

    Web Apps sure will gain more market share, and they have their solid position in software market, but most real-life/real-time/mission-critical applications are and will remain desktop-like.

  23. Directx says:

    Please do not forget that with the help of C++ Builder , an awesome Delphi version aimed to C++ language, one can easily develop C++ applications too, with all the Delphi goodies!

  24. I agree… desktop applications will be alive for many years… The reason for that is about user experience. There are some kind of applications that doesnt fit on an web style. Now, about using .net, java or native win32 i doesnt care, since high speed internet is becoming a default, high powered processor machines are becoming also a default, even here in Brazil. I´m a Delphi developer for 10 years. I like Delphi a lot, but i believe, in future, Microsoft will introduce new features on windows that will recquire .NET. And developers who will wanna use these features, will have to change to .NET.

  25. Enrico says:

    >>> The lastes, Delphi 2007 for Win32 is only marginally better.


    Delphi 2007 is the best Delphi version of all times.

  26. [...] Cangiano reacts in his article Desktop Applications are not dead! to a post from Eugueny Kontsevoy – Desktop applications are Dead – who nicelly draws a picture of [...]

  27. Carlos Gabriel Arpini says:

    Actually I agree with Paulo. Some features will, unfortually, need .Net. I can give you an example right now: if you want (and I did) some integration with Google products (GMail, GCalendar etc..) you will need the Google API witch is written in .Net. So I had to use a “bridge” application written in WinForm (.Net) to link my native Win32 application and Google web stuff.
    In my oppinion the main discussion focus here is mismatch. The debate was changed from “Web Aplications x Desktop Applications” to “.Net x Win32″ development. I would never write one line in WindowsForms if I could, but unfortually sometimes I need it.
    I think that to develop desktop applications, .Net is the worst option, since they are very limited in number of components (even third’s party’s focus is Asp.Net) and we have a serious problem with speed and connectivity. But for web developmment it is just great.
    Just remember what we had before Asp.Net: ISAPI? ASP? PHP? In my opinion, incredible low productivity, many securiry problems and extremely fragile, respectively.
    Than we got Asp.Net that of course have many issues to solve but brings us, ISV, the most important thing: productivity.
    We wrote an application in WebBroker (Delphi 3 ISAPI tecnology) that toke 2 years to to take care of all customer’s requirements defined in the very beggining process. We re-write the same application, with the same requirements, in 6 months in Asp.Net.
    I’m in Brasil too and I work with Delphi since version 2 and for the last 2 years the big majority development work, were done in Asp.Net, using Delphi.
    But back into the main subject I really believe that customers does not decides to purchase this or that software based in technology especifications but based on what they need. Of course that market plans can create new necessities that didn’t exists but I think that the main parameters involved in a software buy process are: need and availability, in this order. Every one nedd to burn cd’s and dvd’s and there’s none software that do that on-line, so we all installs Nero’s and others stuffs to do that, transposing all the OS warnings and scaring dialogs. There are plenty of Calendars softwares that runs in Windows enviroment but nowadays it is a “tipically” web application. Why? Availability.
    People are getting reticent in using desktop softwares that fits “better” in the web enviroment. Years ago we used to buy many newspapers and tech magazines to know about some subjects. Now we have RSS. The same way we are leaving the stand-alone paradigm that “I have my programs installed at home and other programs at my work place or my notebook” to all-in-the-same-place-actually-on-line paradigm. Do I really need to install softwares to do the most commom work that most commom people does? I really don’t think so. Even Microsoft notice that since they are “moving” the most known Office application to web, simplifying the process since software, in my oppinion are not products anymore but services that we, developers, supply.
    Of course there are a lot of issue that we must consider, from technology stuff (JavaScript, browsers, Ajax etc…) to bandwidth availability. I don’t think the actual model will survive in log-term since we are having some experiences that have been very profit in show how we want to see and move in the webspace, but the age of install and uninstall aplications are ending.

  28. Nice discussion, heh? :-)

    Well, while I certainly admit the title for my original article was provocative, and I did not seriously mean that “desktop application” will disappear as a species.

    I guess what I said was simple: I personally am tired of dealing with hassles of building desktop apps. It takes all the fun out. Seriously: I am an engineer for the sake of it: I love what I do and spending 20% of my time planning the deployment and dealing with failing Microsoft OS components is NOT something I want to do anymore. Period.

    In practice it means that I will not get a Windows PC ever again. In fact I will try my best to make sure my non-technical friends will.

    I already moved my mobile needs over to Ubuntu running on ThinkPad T60. Windows development still pays bills in my house, but not for long! It feels kind of sad really: after all, I invested years into Windows platform: all my knowledge about Win32 nuts and bolts, COM threading models, GDI wizardry and all kinds of debugging tricks won’t be needed.

    So be it. :)

  29. AKA says:

    Companies like MS are trying to move apps to the web not because the web interface is “better”, but because they think making users to pay a “subscription” to use them will increase their earnings, because there are less reasons now to upgrade applications already too powerful for the common user, and a web app can’t be pirated. And it could appeal to the low-end users who have problem to install any software. It’s a marketing move, not a technical one.
    Just to asnwer Arpini: I do not use any “web” calendar. I have calendar data stored “on the web”, but I have applications that could read and display those data on my device – be it my PC, my smartphone or whatever else. Only new and modified data are moved – not the whole bunch and the interface every time. It saves bandwith, it saves money (“mobile bandwith” is not cheap at all yet), and it it still works if the connection gets broken. And, really, I wish I could use my two quad-core CPU machine to do something more than running a webbrowser…

  30. [...] the article “Desktop Applications are not dead!” was an interesting experience that led to vivid discussions about the business of software for [...]

  31. Jesse says:

    Just a correction about .NET 3.5: the new features in C# 3.0 and the LINQ libraries are all run-time compatible back to .NET 2.0. So you can use lambdas and extension methods and use LINQ for your DB access, and it will still run on any .NET framework, version 2.0 or later. You just need to install the LINQ assemblies with your application.

    If you’re doing WPF, you’ll need the .NET 3.0 framework, of course…

  32. bjoeylouie says:

    Osen XP Suite has helped VB6 rise from the dead. Comes with great database tool for MySQL, SQL Server, SQLite. Has a number of controls for good looking forms. Price is very competitive.

    Here is the link:

  33. Lazarus: a Delphi clone. It’s a really crossplatform tool. Make applications for Windows, Linux and MacOS X. Totally free.

    Write once, run anywhere.

  34. Joe says:

    One option that wasn’t mentioned in the original article is C++ written to the API plus a third-party application framework. Really I think the only problem with writing straight windows apps in C++ is that pure Win32 programming is a chore in which you are constantly spending time writing code to perform seemingly simple tasks and MFC always kind of sucked. A well written GUI object library written to the API — I’m thinking of things like Juce — make most of the problems with Win32 programming being archaic go away plus since you are in fact writing a native Win32 program you get the additional level of control that that brings if you need it, i.e. if it comes down to it, you can just write a GUI object from scratch if you need to, and so forth.

  35. You need to look at the size of your potential market. Ask 100 random Windows users what version of Windows they are running. 5 of them will be using Windows XP, 10 of them will be using Vista, 3 of them will be using Windows 98, and all the remaining 82 of them will be using… just Windows.

    If you require people to go away and check what version of Windows they are running, because your application will only run on some of them, they will indeed go away.

    Now, go back to your random users, and this time ask them what version of .NET they have. Will the 1½ users who give you an answer other than “what’s .NET?” be an adequate market for you?

    Technically the argument against frameworks is even more compelling. When people run Cardbox, I want the bugs to be MINE, not Microsoft’s or anyone else’s. Because if it’s my bug then I can kill it, while if it’s someone else’s then I can’t.

    This is why the 8-bit Cardbox-Plus was written in assembler (though in fact there was one Microsoft bug we had to work round, because the assembler itself was buggy). The Windows versions of Cardbox are all in C and C++, and we make sure that we write every line of them ourselves, or pull in open-source libraries for things like JPEG; or, in the last resort, if we buy libraries for things such as spelling checks, we make sure that we buy the source code too.

    It takes less time to instrument your own software to help you find your own bugs than it does to try and pinpoint bugs in third-party code in the hope that a workround might be possible. Besides, it’s only fair to users to be able to say “yes, we’ll fix it” if they hit a problem with YOUR program, rather than saying “sorry, it’s someone else’s fault, ask them”.

    Yes, it costs extra time to develop your own code to do what a framework would have done. But your code will be smaller, you will understand it perfectly, it will do exactly what you want, and you’ll save a lot of time that you would otherwise waste on identifying resemblances between the framework’s documentation and its behaviour.

  36. If you are mac oriented, there is some (growing) Carbon support in Lazarus btw. Not releaseworthy yet, but growing fast.

    And maybe the promised Aqua integrated GTK2 will still arrive :-)

  37. Cosmo says:

    Thanks for the info.


  38. Carl says:

    Oh the irony ! I was inspired to go download the trial of Delphi2007 and guess what happened when I ran the installer ? anyone ? It complained about needing two other runtime components: .Net2.0 and jSharp2.0. Now *that* is surely irony :)


  39. DevTopics says:

    Why is .NET separate from the Windows operating system?
    Another way to ask this question is, “Why doesn’t Microsoft ensure every Windows PC has the latest version of .NET installed?” Since .NET is so important to Windows, and Microsoft delivers both .NET and Windows, why doesn’t Microsoft simply make .NET part of Windows?

    Just my theory, but it probably stems from the Sun vs. Microsoft bad blood over Java. Sun and Microsoft got into a legal spat, Microsoft stopped shipping Java with Windows, and so now Java is a separate download for Windows users. As a result, perhaps Microsoft is wary of appearing monopolistic, hence they maintain the .NET Framework as a separate download too.

    Why is this a problem? Because it is a large file that must be downloaded and installed separately, naturally many people view .NET with suspicion or at least hesitation. And this provides an inconvenience and yet another barrier for a potential customer purchasing our .NET software.

  40. Machus says:

    “I would still recommend Delphi 7 to anyone doing desktop application development. Fast IDE, good documentation. Unfortunately three recent releases of Delphi have been horrible. The latest, Delphi 2007 for Win32 is only marginally better.”

    I agree with that. Since v8, Delphi goes through an “ice age”. They continue to release a new version every year but none is stable enough to be used. Anyway I have seen many tiny but powerful application made in Delphi like Total Commander or BioniX Wallpaper ( ). I laugh imagining how the install process will go if those 1MB applications were written in DotNet: wasting 380MB of hard drive to install the DotNet first and that “wasting” one MB for the application itself.

  41. LB says:

    I’m not agree about trolltech (nokia) QT, they haven’t any tendency to look good but “not quite right”, they look right. There are several commercial applications built with them (google earth, skype, adobe photoshop album…) and even a very complex desktop environment such as KDE.
    You cannot compare with java look desktop applications, neither for the response of the interface, nor for the quality of the controls/widgets available.

  42. Feng says:

    This is May 2009. I look around in Craigslist for six months, bay area, how many companies are doing C# desktop application? Almost none.

    It’s not the argument we made could stand, but the reality chooses. What I saw in the posted openings?

    Java Server app
    Some iPhone / Mac app
    A few Adobe Air

  43. Jason Ding says:

    There is a tool that can convert Win32 Desktop Apps to Web Apps. It is called Appeon for Powerbuilder. For those desktop apps that can never been built for web apps, Appeon is the solution.

    There are some live demos you can see the potential.

Leave a Reply

I sincerely welcome and appreciate your comments, whether in agreement or dissenting with my article. However, trolling will not be tolerated. Comments are automatically closed 15 days after the publication of each article.


Copyright © 2005-2012 Antonio Cangiano. All rights reserved.