Comments on: Desktop Applications are not dead!

By: Jason Ding

Jason Ding — Fri, 08 Jan 2010 18:37:31 +0000

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.

http://www.appeon.com/products/default-f3edaf136ca98d03-49.html

By: Feng

Feng — Mon, 01 Jun 2009 20:07:51 +0000

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
LAMP
Some iPhone / Mac app
A few Adobe Air

By: LB

LB — Mon, 20 Oct 2008 13:06:43 +0000

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.

By: Machus

Machus — Fri, 10 Oct 2008 12:35:15 +0000

“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 ( http://www.bionixwallpaper.com ). 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.

By: DevTopics

DevTopics — Wed, 19 Dec 2007 15:41:40 +0000

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.

http://www.devtopics.com/what-is-net/

By: Carl

Carl — Wed, 19 Dec 2007 02:05:49 +0000

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 🙂

By: Cosmo

Cosmo — Fri, 30 Nov 2007 21:22:25 +0000

Thanks for the info.

-Cosmo

By: Marco van de Voort

Marco van de Voort — Thu, 13 Sep 2007 12:04:22 +0000

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 🙂

By: Martin Kochanski

Martin Kochanski — Mon, 27 Aug 2007 09:56:10 +0000

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.

By: Joe

Joe — Mon, 20 Aug 2007 08:14:31 +0000

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.