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

Edit 1: Okay your best bets are

1) Delphi

2) MFC

3) WTL/ATL

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.

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 http://msdn.microsoft.com/en-us/magazine/cc301696.aspx or http://www.codeproject.com/KB/library/tlibc.aspx?msg=2234794). 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 http://en.wikipedia.org/wiki/WTL and http://wtl.sourceforge.net/). 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 http://technet.microsoft.com/en-us/magazine/cc138019.aspx). 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 http://msdn.microsoft.com/en-us/library/ms682579.aspx and http://blogs.msdn.com/larryosterman/archive/2004/06/03/147736.aspx). 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 http://msdn.microsoft.com/en-US/library/f7f5138s%28v=VS.80%29.aspx) or one should use at least /DYNAMICBASE linker switch (see http://msdn.microsoft.com/en-us/library/bb384887.aspx). 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).

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.

The C++ Qt libraries (originally by Trolltech, recently acquired by Nokia, webpage here: http://qt.nokia.com/) 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!

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).

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.

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: http://www.xenocode.com/obfuscator/) 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.

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.

Fatih

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).

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 @ http://win32assembly.online.fr/tutorials.html.

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 http://www.winprog.org/tutorial/ [theForger's Win32 API Tutorial]

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

If size is of essence, don't forget you can further optimise the file size after compilation with tools like http://www.bitsum.com/pecompact.php

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.

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.

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.

PowerBasic. Seriously.

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

Check it out. http://www.powerbasic.com/

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.

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 7.3.1.3.wxDev C++ uses wxwidgets as a part of GUI

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

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.

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

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.

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.

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

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.

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.

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.

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.