Stack OverflowWhat programming language should I use to create small, native Windows Applications?
[+29] [26] Jey
[2010-04-26 07:01:44]
[ windows programming-languages ]

I want to develop an application that runs on any Windows platform (Windows XP, Vista, or Windows 7) but does not require a dependency like the .NET Framework or JVM. I have given the other requirements below:

  1. Runs in any windows platform
  2. Must have GUI libraries to create windows/primitive controls

The output .exe should also be very small, which negates the use of the .NET Framework.

Any suggestions for this requirement?

EDIT 1 : I would like to see any official msdn document which says .NET 2.0 comes preloaded on XP SP2. There are some answers that say this, but I am unable to find any such documentation on the internet. Thanks for this.

(3) Win 3.1? Win 95? Win 98? Win 2000? Whats your bottom? If you have XP SP2, .NET 2 is already on your OS. - leppie
It would be XP with no Service Packs. - Jey
@leppie, I would like to know for sure that it is the case with XP SP2. I have searched the internet but failed to find any documents about this. Can you give me a pointer? - Jey
.exe files built using .NET are very small. If the computers have the framework installed, then it will meet your requirements. - tster
(3) @leppie: .NET 2 does not come preinstalled on XP SP2. - Chris O
(1) @leppie: See… and… Windows XP SP2 only has .NET 1.1 SP1 in the Additional Components folder on the installation CD. - Daniel Rose
(3) I know this might be a little off-topic, but why don't you resort to writing a web-browser application? It's easy, fast, cheap, really easy, runs everywhere... Using the win32 api is so much overhead, it's just not effective. - Johannes Rudolph
In... any Windows platform? So... Windows 1.n, 2.n, 3.n, 95, 98, ME, NT 1.n, NT 2.n, NT 3.n, XP, Vista, 7 (and this isn't even touching Windows CE/Mobile/WhateverItIsCalledThisWeek!). You might want to be a bit more specific. - JUST MY correct OPINION
Duplicate of :… - George Stocker
thirded; .NET 1.1 will be there, but .NET 2.0 was an optional update. - Dean J
[+38] [2010-04-26 07:11:36] Asad Khan

Go directly use win32 API.... no dependencies, no overhead

Edit 1: Okay your best bets are

1) Delphi

2) MFC


Each of them have their own pros & cons.

MFC is evil; stay away!!!

WTL is not officially supported by MS, lacks documentation

I would myself go for Delphi if I were you or depending upon the project I would have opted to use C to directly access the raw windows API. Of-course it would add to the complexity of the project but it would be worth it in terms of small size & other requirements you specified.

In the end it really boils down to you the developer; your experience with these technologies & what you are comfortable with.

(12) take a look at delphi, its been like 6 years since I last used it but give try see if it fits your needs - Asad Khan
(1) Asad Khan's answer and comment are correct. A third possibility is to use MFC with Visual Studio 6 because XP with no service packs can handle it. If you use MFC with a modern version of Visual Studio then you'll have to redistribute libraries. - Windows programmer
(2) What if I use ATL and WTL. Then there is no need to statically compile the dlls, rite? - Jey
My last hobby project was straight Win32 using VC6, just for fun - all of my previous Windows programs have used MFC. The .exe is 172KB. - Mark Ransom
(9) Win32 is not a language. - Matt Joiner
(3) Voting up for the Delphi comment. Native, fast, small. Asad, want to edit your comment to include it? - David M
About Delphi and tiny executable, see my answer. - MaD70
MFC is a framework for creating Windows apps. ATL is a framework for creating COM objects. WTL is a framework for creating Windows apps based on heavy use of templates and ATL. My 2 Cents for dummies ;) - Asad Khan
I would argue that direct W32 API with C++ would be fine. - Paul Nathan
(1) I'd rather use a bag of dead rats for a GUI library than MFC. - Mircea Chirea
+1 for "MFC is evil" :-) - stiank81
@Asad, MFC is not a framework, it's a complicated light wrapper over the Windows API that adds a few features and has direct support in Visual Studio to generate most code - which is very helpful. Qt IS a framework, and a VERY well designed one; it's a dream to program with Qt! - Mircea Chirea
My apologies @iconiK you are right, I havent really programmed in Qt ever & would really like it if you can spare some time & teach me the nitty-gritty of it. - Asad Khan
Wow, never thought to use Delphi in such situations... and indeed MFC/ATL make baby jesus cry... +1! - maayank
[+29] [2010-05-02 02:16:36] Oleg

In C or C++ are the best for this requirement. I recommend Visual Studio/Visual C++ from 2005 till 2010 as a development environment. You can easy write a code using only Windows API. You can remove C/C++ runtime and receive an EXE or a DLL which has size about 3-4 KB (see for example or The most small utilities which I written for Windows Administrators has size under 10 KB and no dependencies excepting Windows DLL. But in the most cases removing C/C++ Runtime is not needed because MSVCRT.DLL is a part of Windows operation system. You application must be not a console application. It can have GUI of cause. If you create a small dialog based application you can use only Windows API. For a large but very compact and quick C++ application I'll recommended WTL (see and WTL is almost exact so powerful like MFC/ATL but very smart and much quickly.

UPDATED: We must be honest with us. If we are speaking about really tiny and quick application, we should speak not only about the computer language but at least a little about compiler and linker switches, about dll rebasing, binding and including manifest in the application. So I decide to add some the most important things (in my opinion) to my answer. I understand, that one don't like read long texts, but I see no other way. So we have to:

  1. remove the Runtime of the language which you use (removing C/C++ runtime in my case)
  2. use mostly Windows API instead of language runtime functions (it follows from the number 1 and is really not a subject of discussion)
  3. choose good switches of compiler and linker. About using of good compiler switches knows everyone. I write here some most important linker switches. For example, an old /OPT:NOWIN98 linker key which now are default just change „file alignment“ from 4K to 512. Linker switch /MERGE:".rdata=.text" (which can be combined with /IGNORE:4078 suppressing linker warning) reduce the number of sections in the EXE and is for me also almost mandatory. How we can see with respect of DUMPBIN.EXE utility, Microsoft use /MERGE:".rdata=.text" switch in all release version of his products. Switch /OPT:ICF remove redundant COMDATs from the EXE. Next linker switch /OPT:REF used typically together with compiler switch /Gy (Enable Function-Level Linking) and make also sense. One more linker switch /TSAWARE change a bit in EXE and switch off visualization of INI files (if used) on a terminal server (also on Vista/Windows 7 etc.)
  4. For C compiler it is recommended not use _MBCS in defines (if you not really need this).
  5. Allways include manifest with equestedExecutionLevel in your exe file (see It's default now in last version of Visual Studio. It switch off the application visualization feature of Vista and Windows 7 for legacy application. Visualization takes allays some process time and the process works slowly.
  6. Every DLL should call DisableThreadLibraryCalls(hInstance) in the DllMain. (see and In ATL it should be done inside of CAtlDllModule.DllMain(). Using of DisableThreadLibraryCalls() makes DLL size a little longer, but it's worth it. One should not forget, that a DLL will be loaded and DllMain called in every thread of application if one not do this.
  7. In every DLL one should use unique base address (see or one should use at least /DYNAMICBASE linker switch (see All kernel mode driver and all Microsoft DLL do this. It reduce working set of application and dramatically speed up DLL loading.
  8. Use DLL binding during software installation (BindImage table in MSI and BindImage action in InstallExecuteSequence MSI table) or call bind.exe utility manually with all your EXEs and DLLs. Usage of unique base address together with DLL binding follow to most quick dll load, reducing of applications working set and maximal sharing of DLLs and EXE code between instances of applications started at the same time (look at Chrome browser for example).

+1 for WTL. We use it all the time. - Rob
MSVCRT.DLL is the VC6 runtime - the more modern versions for vc7,8,9 and 10 don't get installed as part of a clean windows install. - Joe Gauterin
I suppose you meant "you can remove C/C++ runtime and receive an exe or dll which has size about 3-4kb" - MadKeithV
(2) @MadKeithV Thanks! Of cause you are right and I missed in one place the most important word in my answer. The text in fixed now. Such shit happens if one type quickly and not really can English. :-( - Oleg
No problem Oleg, that's why this is a collaborative site. - MadKeithV
+1 for nice information - Abhishek Simon
@Abhishek Simon: You are welcome! - Oleg
[+27] [2010-05-01 15:06:28] Zai [ACCEPTED]

If i get the task, i will choose one of this options :

  1. Assembly, if the program just have a few lines of code. This will create very small (tiny) exe.
  2. C++, if the program should also run on almost all windows platforms before Windows XP (i.e. Windows 9x/ME/2000) AND the program will likely be enhanced for future Windows OS.
  3. Visual Basic 6, if the program is required to be done quickly AND should just run in Windows 2000/XP/Vista/7, AND there is likely no enhancement for future Windows OS. Note that VB6 require a virtual machine dll (MSVBVM60.DLL) but it's available in Windows 2000 and newer, there is no guarantee that Microsoft will also include the dll on future Windows OS (e.g. Windows 8).
  4. Delphi, if (2), same as C++ option. But this will generate a much larger exe than the exe compiled in C++.

So, based on your requirement, I suggest Visual Basic 6.

(1) Seems a great summary. Any changes in the summary if the 64 bit OS is also taken into consideration? - Jey
(17) Assembly is a horrible choice. You will be unlikely to create smaller code than an optimizing C compiler can emit. - Daniel Goldberg
(5) Would take Assembly out for practicality reasons and slide Delphi up above VB as it has better long range support. - jamiei
(2) Assembly would be inefficient on the programmer end unless Xinxua is a asm guru. C++ would be much better. - Paul Nathan
(2) Note that programs built with recent versions of Visual C++ (2005 and up, maybe earlier versions too) do require a runtime with the default options (dynamic linking). If you link them statically, their size becomes much, much larger. I can't really check now, but I'm pretty sure that Delphi executables are mere dwarves in comparison to statically linked C++ executables - at least for Visual C++. Also note that as of Delphi 2009, executables no longer support Windows 9x/ME due to the Unicode switchover - you need 2k or later. - Michael Madsen
@Xinxua VB6 is the best choice for your requirements. "On 64-bit Windows, VB6 programs work fine as should be expected (as there is a 32-bit compatability engine, called WOW)." - Zai
Yes, VB6 is easy-to-learn, easy-to-understand, easy-to-use, but powerful language ;) - SEARAS
[+22] [2010-05-01 14:34:38] Dan Puzey

The C++ Qt libraries (originally by Trolltech, recently acquired by Nokia, webpage here: include GUI control libraries and reasonably nice designer tools in a C++ framework.

They're cross-platform (to Linux & Mac as well as just windows) and much faster/easier to work with than C++ with MFC/ATL. The overhead of linking the libraries is small enough (maybe a couple of MB for the minimal library set), and you don't have to redist the entire framework if you're only using a small part of it.

Might be worth a look!

(1) QT is definitely worth it. I love using QT. You can statically link the libraries in no hassle. - Xorlev
(3) Qt is great, no doubt about that, but the executable size might be a problem. The default QtGui4.dll weighs about 9 MB. Reconfigure the Qt distribution to the minimum with ./configure and make in order to shave some megabytes off the DLL's. If your application is minimal, the compressed executable size will still be around 3 MB. - Bram Schoenmakers
It is entirely possible to trim down the parts of the framework you add - I've seen several sub-5Mb examples where the UI wasn't too complex. - Dan Puzey
@Dan Statically linked executables? And which Qt versions? At the moment I (also) have the challenge to trim down the executable size of a Qt app. By the way, recompiling the toolkit with Visual Studio definitely helps, compared to the mingw32 compiler. However, I was not able to link to these DLLs, but that's an off-topic problem I will figure out someday. - Bram Schoenmakers
(2) Qt is bloated, and only acceptable when GTK+ isn't an option. - Matt Joiner
(11) GTK+ is crippled, and only acceptable when QT isn't an option. - deft_code
(1) @Bram, what? QtGui 9 MB? That's the debug build, the release build is about 2 MB for VC++. If you link statically and Qt is compiled with LTCG the executable will be very small, as anything not used is thrown away (and also optimized so much it's not even funny to see how fast it runs). - Mircea Chirea
@Matt, deft_coder... which one is emacs written in? I want to be on the right side of this debate and not choose the one vi was written with :) - gbjbaanb
[+10] [2010-04-26 07:13:52] Dani

You can program in C++ with the Win32 API, or use MFC (you will need to add a .dll but it will save you some time).

Just consider that developing time is around 50% longer here than in .NET, but that it will require a lot of work to 'look good'. Your application will work on win95 and above (including XP without any Service Packs).

(2) The DLL isn't required with MFC, you can select static linking. But it does make the .exe larger. - Mark Ransom
you are right about that. - Dani
[+8] [2010-04-26 07:09:39] Paolo

C++ or possibly Delphi are probably the mainstream options.

However, if this is for desktop PCs (i.e. not embedded) then I would really question the sanity of avoiding the benefits of .NET especially as it is now installed as part of the OS from XP SP2 up as leppie commented.

My most of the intended users would be XP with no Service Packs installed. So I guess you will take that into consideration - Jey
(2) I am curious as to how/why your TA are going to not have any service packs installed? - thecoshman
The end users are the people with no knowledge of computers, and this would be a small patch/tool to be executed - Jey
@Xinua, fair enough if that's the constraint then my first paragraph still stands. You could script your MSI to install the .NET framework with the app though... :D - Paolo
@paolo.. you can check my edit and is there any documentation out there to prove .NET 2.0 comes with XP SP2?? - Jey
(3) Sorry- the end users need to install sp2 for security reasons alone. XP is ancient. Latest SP is basically a securty mandatory issue to start with. - TomTom
Due to security reasons, I wouldn't allow my app to run on a pre SP2 copy of XP. - Chris Lively
(3) @Xinxua - My bad, .NET came with the SP2 installer but was an optional component - Paolo
[+6] [2010-05-06 08:12:56] Mark Redman

Delphi compiles to native windows (to a single exe) and is a great IDE to use.

I think there are some .net obfuscation tools that enable embedding the require parts of the .net framework in your exe (see: this may help with deployment, but might increase the file size.

You get standard interface controls out the box, with and commercial and open-source [1] component libraries available.


xencode not available you should use - JKS
[+3] [2010-05-07 14:50:25] fgungor

Also consider the Windows Template Library. You can access all the bells and whistles of the Aero with easy to use template classes. The best practice is to use C++ and ATL / WTL libraries. Also boost and stl are your best friends when it comes to C++ programming. The learning curve is a bit steep. But once you get through a few basics. You'll just get addicted. Unfortunately WTL doesn't have a documentation but the library is very solid and widely used among professionals. You should hunt down sample codes on Google which is straight forward.

By the way someone mentioned that using stl or boost can produce large executables. Well this is rather wrong because you don't pay for the features you don't use (in terms of size) since the classes are just "templates" and never gets -compiled- unless you instantiate/use them.


[+3] [2010-05-07 15:01:57] MaD70

If you choose Delphi or Free Pascal [1], an option for small executable is KOL (Key Objects Library) [2].

You install MCK (Mirror Classes Kit) into the Delphi IDE ( KOL-CE [3] if you want to use MCK with Lazarus [4], a Free Pascal IDE) so you can develop your software's GUI visually. Then, for deployment, you switch to KOL (a simple change in the import clause), which is more lightweight than VCL because there are no traces of development-time (IDE) code.

If you want an even more tiny executable, they have some system units replacement. In the past I compiled an example program, which comes with the library, containing all the components and it was about 25 KiB [5] (with system units replacement).

The only downside is that KOL is not a so rich library of components as VCL (althought the number of components slowly increase). Therefore I suggest KOL/MCK if your software's GUI is relatively simple or you can write yourself the components that you miss (or you can pay someone knowledgeable to do it for you).


[+2] [2010-05-05 06:51:30] Mr Roys

Use MASM32 [1] with WinASM Studio [2] or EasyCode [3](Two IDEs for 32 bit assembly for Windows apps)

Since Win32 assembly code essentially consists of calls to the Win32 API, it isn't that hard to pickup especially if you've done Win32 coding in C. A good set of tutorials can be found @


(6) That's just masochistic. - Mark Ransom
Not really, it's a big difference from ASM in the 16 bit days with segments and stuff. 32 bit assembly is actually much easier. The only issue is with OOP, it's possible but ASM doesn't do it that well. - Mr Roys
[+2] [2010-05-05 12:55:08] AKN

Your solution is "Window programming using Win32 API's."

Use Visual Studio 2003, 05 or higher and create Win32 Project. Since you may be new to win32 API programming, it is better to look thro [theForger's Win32 API Tutorial]

It may take some time to get a feel of it, but this would be your ideal solution.

[+2] [2010-05-06 02:52:30] FerretallicA

If size is of essence, don't forget you can further optimise the file size after compilation with tools like

If you can work with C++, that gets my vote. If for any reason you don't want to work with something which requires you to do nearly everything for yourself, I'd be looking at .NET 2.0. Reasonable trade-offs depend on WHY size and native code are requirements.

[+2] [2010-05-06 07:47:51] p.marino

If you haven't discarded it already for some reason, why not trying Realbasic [1]?

It generates compiled, self-contained .exe. Not sure of the actual size, but you can try it out for free for 30 days so you can probably play with a couple of "Hello World" examples to see how it fares.


[+2] [2010-05-06 15:15:29] MZB

Visual Studio 2008 / C++ / ATL headers / C++ library included statically

This gives you access to the template class CDialogImpl<> and means you can create and edit your dialogs in the resource editor.

It may not give you the smallest result, but there are no additional files to distribute and it's a lot easier to develop GUI code in than raw C/C++ and Win32.

But just how small do you really need to be? Is it worth your time?

For my simple 4-dialog application using the above approach the size is 388K. (I have a lot of bitmaps in the resource file, which therefore occupies some 280k of that).

That's nothing in terms of download speed / disk space / memory terms on a desktop.

[+2] [2010-05-06 17:01:46] KP.

PowerBasic. Seriously.

  • Easy to learn/use
  • Fast
  • Small exes
  • No external library dependencies
  • Well supported
  • Actively developed
  • Excellent documentation.

Check it out.

[+2] [2010-05-07 14:36:03] user335474

Read the FAQ for µTorrent, where this issue is discussed. Or was. They have changed the FAQ and the discussion has been removed, so here is the old FAQ with some editorial annotation:

  • It's written in C++. Comparing C and C++, as your question tags suggests, is silly with respect to the compiled product because they can both produce the same executables (many compilers are both C and C++ compilers).

  • ...except they don't. Many implementations of the template library are inefficient, especially at avoiding duplication. So µTorrent uses its own stripped-down classes.

  • Use an executable compressor such as UPX, after you have written the program. This is a special case of avoiding premature optimization.

[+2] [2010-05-07 14:48:06] JKS

C++ is the best choice for native small execuatables. Use wxDev C++ Editor to create your programs. It is actively developed and current version is C++ uses wxwidgets as a part of GUI

RAD Tool
Excellent GUI Components
Easy to learn/use
Actively developed Excellent documentation

[+2] [2010-05-08 09:30:45] mico

Delphi can create very small statically linked executables.

The Delphi environment is also much easier to program and understand than C or C++.

Given your requirements this would be my #1 choice.

[+1] [2010-05-07 20:26:57] bta

I usually write my apps in C/C++ and use a toolkit like FLTK [1] or WxWidgets [2].


[+1] [2010-05-08 06:56:45] Delan Azabani

In my opinion and through experience, C++ with GTK+ has always been a favourite; it's compact, relatively easy to write programs with, and as an added bonus, is cross-platform compilable.

[+1] [2011-02-09 05:25:43] Feng

I will choose Delphi as my first choice, it is very easy to use. The output file maybe a little bit big, but I do not think the EXE file size will be a real problem for a windows program. The output file will be able to run on most of the windows platforms. The minor shortage is there is no 64 bytes compiler yet.

Now the newest version of delphi has a 64 bytes compiler. It can alos export file to iOS (Apple plateform) and can be able to complied and run on a ipod or a Apple laptop. - Feng
[+1] [2011-05-10 09:30:48] Amit

C++ with WIN32 API is a good option....

[0] [2010-04-30 18:31:48] Sheng Jiang 蒋晟

You can use the MFC/ATL in Visual C++ 2008, which supports targeting Windows 2000 and higher. Visual C++ 2010's C++ runtime library requires XP SP2, so if you use it you need to avoid using the C++ runtime library in your program.

[0] [2010-05-06 11:59:52] ablaeul

Because you want a very small .exe file, you should opt for a C program. C++ programs can get very big, if you use stl or the io libraries.

For the GUI functions you can go directly for the Win32 API or use LessTif [1], which seems to create only small overhead in file size.


(1) They can get large... but they don't have to. A C++ program using C api's is likely to be no larger than a C program (at least not significantly so) - and using a few common C++ features such as basic stl datastructures won't balloon your exe size either. - Eamon Nerbonne
[0] [2010-05-06 18:57:11] Qwertie

One of the above C++ solutions is probably best, but in case you like C#...

See here [1] about the .NET framework versions bundled with Windows OSs. Basically, only .NET 1.0 is likely to be bundled with XP, and may not be preinstalled.

Mono has a feature offering ahead-of-time compilation [2], but it does not currently support the x86 platform in "full" mode, so it still requires the mono runtime.


[-1] [2012-02-06 11:03:58] Nwaomachux

HotBasic is the way to go. It's the newest kid on the block. (I'm kidding though, it's almost 10 years old.)

I just read up about it but have yet to do any programming in it. I really like what I've read because it took a very different approach than others.

nwaomachux, Nigeria.