If you were developing shareware softwares for windows, would you target the .Net Framework or use native code?

Question

For the sake of the question, by 'shareware' I mean a software which is relatively small in size (up to few dozens of mb) and available for download and evaluation through a web site.

I'm asking this question, because I don't understand something regarding the current state of windows commercial desktop development. It seems to me that:

1. There is no reliable statistic regarding the extent of windows systems with .Net Framework installed.

2. It makes no sense to force the end user to install the 20-60mb .Net for an application which may be smaller.

3. Applications conforms to the term 'shareware' above have a big share on the win os market. Much of them don't need the capabilities of low level languages like c++, and therefore ideally they should be developed with a RAD environment.

So, One would suppose there will be a blossom of RAD environments for native win code. But I know about only one - Delphi, and Delphi is so unpopular.

How is that?

Answer 1

1: no, except "all modern ones". it is quite widely used starting with Vista.... like "as part of windows". Quite a lot of software uses it by now.

2: Except that it speeds YOU upas develoepr by a factor of X (x > 2). It is a recommended update from Windows anyway so it should be on all computers. And your time has value, too.

3: häh? Seriously? what low level capabilities would that be? What typical shareware would that be? Note that .NET has a LOT of capabilities to call into the native stack... and a lot of very good capabilities without that.

To answer the end:

• Because your assumptions are wrong. Simple.

Answer 2

use .Net - this reduces your time to market. native languages like c/c++ can be used for system programming, where every ms counts :-)

Answer 3

Windows XP SP3 comes with .net 2.0. So you can target that without excluding too much potential users.

Answer 4

Scott Hanselman gives a figure of "over 65% of PCs have .NET 3.5 SP1 installed". Don't know the source of this figure though.

Answer 5

I'd target the .NET environment since, as mentioned, it is more and more becoming an integrated part of Windows. And even though it might need a download once most people find it useful.

Paint.NET is a successful shareware that targets the .NET platform. Balsamiq Mockups is another very successful licensed software that uses yet another platform, Adobe Air. So I wouldn't view the platform download requirement a showstopper.

Answer 6

Also take a look at ClickOnce that should make the .NET installation and the installation of your application a lot easier for the user.

They would still have to download the framework if they don't have it but it will happen automatically.

Answer 7

I would use Delphi. Tools and people make programs, not opinions. Why? Simply because it is perfectly suited.

Aside from the runtime download issue, for shareware there is the constant changing .NET framework to deal with, and to be honest I don't think Winforms is that great. (or is WPF nowadays, make up your mind Microsoft?)

ASP.NET is absolutely great, but for desktop apps I don't think .NET is such a great improvement over Delphi.

Answer 8

The only reasons I see why Delphi is not as popular today as .Net:

1. Embarcadero spend MUCH less money on advertisement than Microsoft
2. Delphi already is not so new and fancy

If this reasons does not matter for you, than you can freely use Delphi or C++ Builder.

Answer 9

So, One would suppose there will be a blossom of RAD enviroments for native win code. But I know about only one - Delphi, and Delphi is so unpopular.

If I read this, I would say, you've already made up your mind.

Both environments (.Net 3.5 and Delphi) have their own advantages and disadvantages. In our shop we use both platforms; the Delphi platform is used for software that needs to run on tens of thousands of machines we're we sell the software for only a few bucks / instance. We do this to avoid support calls. (a single Delphi executable with everything inside and only dependencies to system dll's is really really stable). This saves us quite some money.

.NET 3.5 is usually chosen (with the c# language) when interoperability with Microsoft software is needed.

What we see is that developers that know both tend to prefer Delphi for new projects. Developers that only know one of the two environments tend to prefer their own environment.

I think both platforms will exist in another 5 years. Delphi is a bit more stable (fewer latest and greatest API's introduced) and .NET a bit more experimental. In the end both platforms perform well, there is enough sourcecode and expertise out there (in The Netherlands where I live you can get developers easy enough).

Answer 10

If you compare PC share in market, it's way high. I love using Linux and with "mono" in Linux it is possible to use .net applications in Linux. .net 2.0 is the core framework and you can certainly target that as the base requirement. Microsoft has always developed products which has backward compatibility.

Yes, a good example is Paint.NET, they have changed with .net framework. Earlier the requirement was .net 2.0 now you need .net 3.5 and the features have improved as well.

Answer 11

Look at my answer to this SO question, and you'll see that Delphi is the tool of choice in many cases (so not really unpopular).

As Nick Bradbury explains it very clearly in "Why I use Delphi".

Answer 12

Delphi is not a bad choice but unless your software is strictly Windows-oriented, I'd suggest exploring QT as well: http://qt.nokia.com/products You can make your software cross-platform and sell to Mac people as well.

Also, since you mentioned the "low-level language C++", keep in mind that pascal isn't that high in the language hierarchy either :) It's the VCL library and the Delphi IDE that make the RAD environment. So, you shouldn't be comparing C++ to Delphi or .NET, you should be comparing C++ Builder vs Delphi vs QT vs Visual Studio.

Answer 13

Unless there is a specific reason to do otherwise, I always use native code (specifically Delphi) for client side development. Reasons include, but are not limited to:

• Faster start up time (no jitting or .Net startup time). This is especially visible when running client applications.

• Lower memory usage. Apparent in an empty application, and even more so in something more functional.

• Better UI performance (VCL vs Winforms) and specific support for Vista/Windows 7 themes and APIs and even support for gestures in Windows 7, if you like that sort of thing.

• Does not require an additional framework. This is the biggie. The actual requirements for version 2.0 and 3.5 the .Net framework are higher than the 20-60 MB that you suggest. And, unless you limit your applications to features available in an earlier version of the framework, users will need to make sure they have the latest one installed. Even Vista and Windows 7 won't have .Net 4.0 installed by default, which is due out shortly. I prefer having the option to do an XCopy install with few if any dependencies.

• The "time to market" argument applies equally well here. Delphi has an extremely productive development environment, from the productivity tools in the IDE to a blindingly fast compiler. This, along with the lack of deployment dependencies makes the development/test/release cycle very smooth.

• You might be surprised how many other developers are using Delphi for exactly the same thing. Here is an incomplete, but impressive list. Embarcadero is featuring some of these in a slightly flashier showcase.

• Answering your third point - Delphi is a RAD environment that still lets you get at the low level details, even supporting inline assembler.

There are lots of other reasons why I prefer Delphi, but I'm limiting my list to things that I think are relevant to the question.

I'm not intending to bash .Net. I like C# and Visual Studio is a great IDE in its own right with lots of productivity tools. I just think that .Net is better for server side (e.g. ASP.Net) and long running applications where startup times and jitting are less of an issue and it's easier to manage the .Net installs on a few servers than on each and every client PC.

And, if someone wanted to use .Net but craves the Delphi (Object Pascal) language, there is always Delphi Prism, which is included as part of RAD Studio.

Update:

The first line of my response makes it sound like I only prefer Delphi for client applications. It's actually my first choice for all development, with the exception of ASP.Net, which can also be a good excuse to use Delphi Prism.

Update2:

Some more details on the hardware requirements now that .Net 4.0 has been released. The minimum disk space requirements seem a little steep:

.Net 2.0 - x86: 280MB x64: 610MB
.Net 3.5 - x86: 280MB x64: 610MB
.Net 4.0 client- x86: 600MB x64: 1.5GB
.Net 4.0 - x86: 850MB x64: 2GB

Answer 14

I would use a framework such as Qt or wxWidgets rather than the native API. I don't trust the .NET framework and developing requires the target platforms to be running the correct version of .NET.

Answer 15

Speaking from pure experience, select whatever tool generates a resulting program which has the least external dependents. You want your program to run out of the box... not prompt to install another piece, or refuse to run until you make appropriate patches to work with a library which was changed and released when your attention was focused elsewhere.

If your targeting a large audience, keep your absolute requirements as minimal as possible. You might have 16gb of ram and a high end video card, but that doesn't mean that everyone does. A good test is to create a VM with the oldest OS you can find, with the minimum requirements for the OS...and seeing if you can install into it without any updates or an internet connection.

Keep in mind that those that can't run your software the first time are very unlikely to contact you and complain...they are more likely to give up and move on.

Answer 16

Developing and selling my own shareware, as you like to call it, has been my full-time occupation and only source of income for over a decade. I have been using Delphi all this time. Though things didn't look too bright during the final years of Borland, the new owners (Embarcadero) give me confidence in Delphi's future and I'm happy with the choice I made all those years ago.

I recommend that you get your advice from people who have been there, done that rather than asking "if you were", "would you" kind of questions. All successful shareware developers will tell you that:

1. While choice of tooling is important, it isn't going to be what decides your success. If your app rocks people will download all 50 MB of it. Choose the tool that you are most productive with even if that tool is unpopular.
2. What matters is whether you can release an application that does something useful or desirable without crashing too much.
3. What matters even more is whether you can market that application. Worry about your business plan first. Where is your product's demand coming from and how are you going to reach those people? When you have a concept that you believe can make money, then you can choose the tool to implement it.

Answer 17

Bottom-line, use the platform you are most productive in.

In my experience there is an enormous amount of FUD spread about .NET which seems to stem from dislike of Microsoft in general.

Get a real understanding of the pros and cons of .NET by reading some excellent books such as CLR Via C#, C# in Depth etc.

Answer 18

The nice thing about .NET is that the "is the framework installed?" problems are going away. All you have to do is wait!

.NET 2.0 is easy to target, is suitable for most applications, and is bundled with Vista and newer (and is a fast install on XP). And if 2.0 doesn't do what you need, the .NET 4.0 Client Profile is a vast improvement over the (admittedly terrible) .NET 3.5 install.

And with either an MSI or ClickOnce, you can just tell it to automatically detect the framework, and download and install your selected version if necessary. So the impact on that small minority of users without the framework is minimal.

Finally: the idea that .NET itself is slower to the degree a user might care about is ridiculous. Usually it's a problem with your own code (a common one is inefficiently parsing XML at startup).