.NET or WinAPI

Question

Hi guys, I am trying to build a desktop app. The biggest requirement is that it should be as miniscule as possible. For Windows users, is it better to build it in .NET or WinAPI? I am not from software background so pardon me if this is a non-sensical question, but I have heard that with .NET, there is a chance that some Windows users may not have it on their computers, in which case they will be required to download a large piece of software, whereas that will never be the case with winAPI. Is that right? What percentage of Windows may not have .NET 2.0 on their computers? Also, I have heard that developing this little app in WinAPI will take more effort. Is it worth it to do that or does .NET get you to almost as many users? Thanks

PS. I am new to this forum (and as I mentioned above, from a non-software background) but I have to say this forum is the best I have found for making some fundamental decisions about an app I am trying to build. But the thing is, the more I learn, the more the no. of questions I run into.. thanks for everyone's help :-)

Answer 1

Take a look at this question.

But if what you need is a really tiny executable, without having to install a full .NET framework, go for Win32. You don't have .NET framework preinstalled on Windows XP.

Answer 2

Most computers have .NET in some form on now by virtue of Windows Update and other programs the user may have installed. If you're new to coding, I'd definitely use WinForms/.NET over directly coding for the Windows API. It's much simpler, even if a larger.

Answer 3

Definitely go with 'native code' if it needs to be miniscule. However, this is lot more difficult especially if you're not from a software background.

It might be better to outsource this piece of work?

Answer 4

The biggest requirement is that it should be as miniscule as possible.

If that requirement is legitimate, it pretty much forces you into the win32 API level. But I really question this requirement. These days downloading a a few MB isn't what it used to be, and there are ways to mitigate the problems if much of your user base is still on dial-up. Comparing this to the increased difficulty (and therefore time) to develop for Win32 and .Net can make a lot of sense.

What percentage of Windows may not have .NET 2.0 on their computers?

It's hard to get real penetration numbers, and I've seen statistics as high as >90% and as low as 20%. So it all comes down to what you want to believe. If it's really that big of a deal you can develop for mono and use that to static link the run time.

Answer 5

Also, I have heard that developing this little app in WinAPI will take more effort.

Ok, imagine you've to build a car.

1. You go to an auto-parts catalog, you order the correct number of valves, pistons, cogs wheels, a fan, a radiator etc for the engine. You order all the lubricants, cogs, bearings, nuts & bolts required to build the transmission. You order head lights, bulbs for the lights, so for break lights, turn signals, reverse lights.

You order enough steel to weld together a chassis, you order some seats, some cloth to upholster them, a gear stick, pedals, switches for the lights, doors, glass for the windows and finally, a rear view mirror.

It all arrives and you've to put it all together. The chassis is only as strong as the strongest weld, and you've a mammoth task ahead to put it all together, and the room for error is huge. And it's not until you put it all together that you realise you haven't ordered any wheel hubs or tires.

This is Win32, the windows api.

1. You go to an auto-parts catalog, you order a chassis with seats, lights, wheels etc all installed. You order an engine and a transmission. The three items arrive. You still have to fit the engine and hook up the transmission (not trivial tasks), but it's a far simpler proposition.

This is .net framework.

If the project is larger than a remote control car for a young child, take the distribution hit and use .net

Answer 6

Writing native (unmanaged) code calling WinAPI will give you a smaller footprint without dependencies on the .NET framework.

But if you want a smaller .net framework deployment, take a look at the .net client profile. All the .net assemblies you normally use in a 28mb footprint. (With a 200kb bootstrapper that installes only the stuff that isn't already on the client machine)

See also this blogpost.

Answer 7

Is as "minuscule as possible" THE most important requirement? While going this route, you will have less dependencies (and thus smaller deployables) but your cost and time in development will increase.

I'm going to go out on a limb and say that most Windows PC's have the .NET framework installed already (either via Windows Update or pre-installed). If you are developing against XP or Vista, this will most certainly be the case.

But more importantly, is the size of the final package as important as the time-to-value? You are going to have a significantly easier time finding developers who write good code quickly in .NET. WinAPI development can be tedious, slow, and cost significantly more time in debugging. That's not to say WinAPI developers aren't good at what they do, but .NET is a forward advancement in software development that lets you focus more on the business problem and less on the technical domain.

If you are a PM or a project lead you might want to consider doing a cost-analysis to determine what is really important in your decision.