Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am a fairly proficient Linux programmer. I have been coding in Linux for 4 years, for both personal reasons and for profit. During those 4 years I have not even owned a computer running the Windows operating system. I am looking to expand my horizons into Windows programming, but am finding myself overwhelmed with the lack of what I perceive to be standardization. I feel as though different compilers follow different conventions, and all of the worthwhile IDEs cost money. Whats worse is that so many of the Tutorials are just terrible.

If anyone else has taken the switch from Linux to Windows programming, what was the most helpful. What are the most straightforward IDEs and tutorials for using the API.

I am looking to do mainly C and C++ development, along with some x86. I have found MASM primarily suits my needs for the latter.


migration rejected from Jan 16 '14 at 14:33

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by Martijn Pieters, ozz, Simon, Eric King, GlenH7 Jan 16 '14 at 14:33

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Martijn Pieters, ozz, Eric King, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

I would probably recommend Visual Studio for Windows development. They have a free version that should be more than enough to get you started called Express: – Fuji Jan 17 '12 at 19:27
Such a wonderful thing - linux user talking about lack of standardization in Windows <bg> – Eugene Mayevski 'EldoS Jan 17 '12 at 19:51
@cytinus: congratulations on your downgrade ;) – Andres F. Jan 17 '12 at 19:57
In my experience, you'll be much, much better off learning C# if you want to jump into the Windows game for profit. I have been very gainfully employed as a Windows developer since 2002, and the C# jobs greatly outnumber the C++ jobs. – Adam Crossland Jan 17 '12 at 21:42
For the sake of saying something different from all the VS answers (even though I actually like VS), I'm going to mention that the Codeblocks IDE ( runs on Windows and is geared towards C/C++ development. Eclipse is cross-platform and has a C++ variant ( Netbeans, also cross-platform, also supports C++ ( There. Now you have choices! :) – FrustratedWithFormsDesigner Jan 17 '12 at 22:17

Visual Studio C++ Express is free. It's a world-class IDE bundled with Microsoft's C and C++ compilers. There are some non-standard extensions provided by Microsoft's compilers, but you can write completely standards-compliant code, too. There are no limitations on selling applications created with the Express edition commercially, although there are certain other limitations of the Express edition, like the inability to use extensions and add-ins. For learning purposes, these limits should be a non-issue.

If you're more comfortable with GCC, given your Linux background, you can use that on Windows, too. Installing the MinGW toolkit is the easiest way of getting started. You'll need to bring your own text editor, but I'm not about to make recommendations on that. All good programmers, especially in the Unix world, have a favorite editor that you can't pry out of their cold dead hands. Emacs and Vim, for example, have Windows ports.

The big decision you're going to have to make is which API you're going to target. There are lots of choices, but it's really hard to recommend one without more information about what types of applications you're intending to write, what the purpose of those applications is, who your target market is, and other possible concerns (cross-platform, etc.).

To a Linux programmer, the Windows API (the native APIs provided by the operating system) are indeed going to look awfully non-standard. That's primarily because they are. They were all invented before there was a lot of standardization, and due to the importance of backwards-compatibility, they haven't been thrown out and replaced with updated versions. You will have to learn lots of new conventions if you want to program to the "bare metal", so to speak, targeting the native API.

The good news is that there are lots of great UI libraries available that wrap that native API, meaning that unless you have specific reasons for learning it (and despite what some people believe, there certainly are good reasons to learn and write apps that target the native API), you can largely avoid it. For example, lots of Linux programmers are already familiar with the Qt toolkit. That's available for Windows, too, and does a pretty good job of shielding you from the idiosyncrasies of Win32 programming. Then again, it's not exactly "standard" or idiomatic C++ either.
It's all what you get used to...

And if you do decide that you want to learn native Win32 programming, Microsoft's documentation is very extensive. But I wouldn't recommend that most people try and learn this way. The standard reference is still Charles Petzold's Programming Windows. If this is your mission, you'll definitely want to pick up a copy. I don't know of any better tutorial for Win32.

+1 for MinGW. It let me fake being a windows developer in my last job. – Philip Jan 17 '12 at 20:04
And cygwin is an even more Linux-like environment than mingw. Also, when getting started with Visual C++, the thing to note is that you want to choose "Win32 Project / Console Application" from the wizard. And probably disable "precompiled headers", since they break existing valid code with errors looking for the precompiled header #include. – Ben Voigt Jan 17 '12 at 20:13
It should be noted that I'm pretty sure you can still use the Windows compilers directly rather than through the IDE. – Dalin Seivewright Jan 17 '12 at 22:19
@Dalin: Yes, you certainly can use Microsoft's compiler without the IDE. It's called cl.exe. I believe the VS installations even install a convenient "Visual Studio Command Prompt" with all the environment variables set appropriately. – Cody Gray Jan 17 '12 at 22:28
A last word of advice: whatever you do, don't stare at the Windows APIs for too long, they're pretty comprehensive and redundant: messing around with one or the other trying to figure which is the most future-proof (something I used to do under Linux and MacOS) is pointless and extenuating. – ZJR Jan 18 '12 at 2:45

Some will agree that the best IDE for Windows is Microsoft Visual Studio. To me, it's really the only viable development solution if you want to do serious Windows programming. The "professional" edition of Visual Studio costs a bunch of bucks. The answer is to install one of the Express versions, which are free. Go to MS and look for VCExpress. There are several versions, each devoted to one and only one language. Happily, there is a C/C++ version that includes an assembler. (Also versions for Basic and .NET and who knows what else, but these are of no interest to you I believe.) It's a snap to download and install one of these Express packages.

There is also a *nix look-similar dev framework called Cygwin/MinGW that you'll want to investigate. I know nothing about it.



A Linux programmer proficient with C programming can easily adapt to the Win32 API, which unlike many say is a tremendous piece of library to build amazing GUI programs for Windows.

Windows API is pure ANSI C with some custom MACROS, typedefs and structs which are standard subjects in C programming.


In my opinion, you should install and toy around with two main options for a while and stick with one of them for your own development: Visual C++ Express and MinGW.

Visual C++ Express

It's always a nice thing to have it installed, as it enables you to compile and try out lots of code (not MFC, though). You should only install an older version if you don't have access to code with which you must share the same C runtime, such as exchanging file descriptors that the other party must be able to fread(), fwrite() or fclose(), or exchanging memory pointers that the other party must be able to free().

The compiler is cl.exe. The compiler differences will bug you when and where you least expect them, but it's generally affordable to make the same source files compile in several compilers.

The make tool is nmake.exe. Nmake is mostly like other makes, but be careful about hairy stuff such as inline inclusion and proprietary extensions, and the execution of shell commands (sh vs cmd.exe) and *nix tools. As a basic rule, don't try to maintain Makefiles that are valid on both nmake and another make, it's much easier to just maintain separate makefiles.

The IDE is quite nice, although the Express version doesn't have it all, such as remote debugging.

MASM is downloadable separately from the Express editions, but it's included with the paid versions.


MinGW is a minimal set of native GNU tools, such as GCC, and ported headers, which are (basically) translations from VC++ specifics to GCC's ones. The main advantage over Cygwin is that it compiles bare apps and libraries which don't depend on a middle layer that emulates POSIX (cygwin1.dll).

MSYS brings you part of the remaining toolchain you're used to, such as sh and make. These are not entirely bare apps (msys-1.0.dll takes the place of cygwin1.dll), but you're only going to make use of them, you won't generally target for MSYS unless you're developing MSYS.

You must be aware that it runs in an environment very similar to Cygwin, especially about pathnames. They're mostly interchangeable and most tools do the right thing with whatever kind of pathname you pass them, but keep in mind that this might not always be the case, especially if a pathname has spaces.

Installation may be a hassle, you must follow the most recent instructions closely and try out one thing or another between steps. However, once it's done, you may just copy the entire tree to anywhere else and point to it.

MinGW comes with as, so you don't have to learn another assembler.

I've experienced better runtime performance with the output of VC++, but on rare times I'd wish it was as easy to get the development environment up and running from thin air (e.g. another directory, a USB pendrive) like with MinGW+MSYS.

But again, I've felt this need very few times. The machine-wide installation of VS or VC++ is straight forward. It's possible to make it portable, but you'll have to either install it once or get other tools to extract what you need from the installer, then you need to know what to copy and change vcvars*.bat to rely on its current path, rather than on environment variables such as VS*COMNTOOLS and some hardcoded values such as the setting of VCINSTALLDIR. And last but not least, be sure you're not violating some license when and where you use it.

VC++ version from 2003 onwards will make your output EXE or DLL depend on Microsoft's C runtime for that version as an assembly. Reread the last sentence. That usually means you'll just have to make sure the machines where you deploy your code should have the corresponding runtime msvcr*.dll files properly installed. The redistributable packages are available somewhere inside VC++ directory and from

On the other hand, most open-source projects expect GCC, so you'll get less compilation warnings and a little lower risk of getting weird bugs at runtime with such projects. At least, bugs that are related with the module itself, it might have other bugs due to interaction with libs compiled with some other compiler (e.g. mismatched calling conventions).

If I remember correctly, MinGW's output depends on msvcrt.dll, an aging version of Microsoft's C runtime that didn't change name between VC++ versions up until VC++ 6.0. Unofficially, it's present in every Windows installation, so you'll probably not have to bundle it. On the other hand, you might want to bundle a version that you know it works, so that it may replace an older version of that DLL. In the case of an EXE, you may simply put it on the same directory instead, if you find that the installed one is older.

If you're just extending your knowledge, I don't recommend you go for a paid version of Visual Studio. If you were more commited into it, like extending your products or your services for another platform, then it might be worth it. Also, before the 2012 versions, you didn't have the x64 cross-compiler and OpenMP in the Express editions.

From the API point of view, you'll have to remind yourself to not get frustrated wth it in comparison with *nix APIs, at least not until you (try to) understand what historical reasons there might be and the difference in architectures.

Get used to:

  • PascalNamingConvention
  • Huge parameter lists or huge-struct parameters
  • Security parameters
  • Parameters that can be NULL for reasonable defaults (e.g. security parameters, in most cases)
  • Reserved parameters that must be NULL or must be zero (m.b.z.). They may be repurposed in newer Windows versions
  • Functions that do a trillion different things (e.g. CreateFile())
  • Function names that end in Ex

For the Win32 API, use GetLastError(), it's thread-local. Not all functions report errors through it, and be careful that some functions that do won't set the last error to success (0), in which case you should reset it with SetLastError() before invoking them. For the C runtime functions, keep using errno, it's also thread-local.

The various graphical Win32 APIs have a high learning curve (which native GUI API doesn't?). Some window messages are obsolete, some operations are not officially documented (e.g. changing the owner of a Window), some things are old-school functions-and-structs for window creation and message dispatching while others are OLE/COM objects inside containers with callback dispatch-by-name events, etc. But if you follow the specs and use as few undocumented behaviour as possible (better yet, none), chances are your software will work unmodified for many years to come.

From time to time it's often good to know when are your calls entering kernel-mode (not kernel32.dll, it's user-mode).

My experience with abstracting required features between several OSes is that you must understand the architecture of the OSes you want to target before anything else. Unfortunately, even this analysis will be based on the current state of things, so try to make decisions based on the parts of the architecture that are the least probable to change (much) over time.

The various Win32 asynchronous I/O APIs, for example, are quite a pleasant surprise, despite being a bit complex to start with. But to take advantage of it, you must be prepared for a post-poned coding style when using such abstraction/library. And note that if you use I/O completion ports, they manage thread pools and less context switching for you, so you'd either not take advantage of that for a lowest-common-denominator abstraction, or you'd implement at least the thread pool on other OSes to make it scalable at the expense of a bigger library.

Note: I'm not advising you to make a cross-platform asynchronous I/O library, there are a few already.

Finally, the console is not like the usual *nix terminals. It's a blocking user-mode device that kernel32.dll masquerades into calls to an internal service made available by a sub-system. There's no asynchronous I/O, and line mode implies either that you rely on Windows' own line mode editing while blocking for a new line or that you handle raw console input. The console handles are not duplicatable across processes and are thus not inheritable either, but the console itself may be shared with the child process (the default). You don't get a terminal where you type ahead in echo mode until it's read (exception: Cygwin, because it implements its own raw console input handler).

Paulo: your last paragraph is now obsolete, due to clink + conemu + Gnu Coreutils + Gow (GNU on Windows) existence - they turn your cmd.exe experience into something close to a bash linux terminal (with a few exceptions, for example async IO). – Adam Adamaszek Feb 20 '13 at 17:42
@AdamAdamaszek, so, you have to install and combine 3 things to emulate *nix TTYs at the user level, and in the end, asynchronous I/O is still an exception. How does that make the last paragraph obsolete? That basically just means one of those components implements a raw console input handler. If you're given a console input handle, you're stuck with synchronous I/O, and at best you can have just 1 dedicated thread, knowing that there's only one console per process, to handle console I/O, probably with a queue or two. – acelent Feb 21 '13 at 0:26
@AdamAdamaszek, I correct myself, ConEmu and clink both seem to hook on certain DLL entry points, such as WriteConsoleW. Still... – acelent Feb 21 '13 at 0:41
I wasn't trying to prove you wrong. But still, for those of us stuck with Windows, all those apps improve the cmd.exe experience - hence my comment. – Adam Adamaszek Feb 21 '13 at 9:13
@AdamAdamaszek, point taken. You were talking about user experience and I was talking about developer experience, and probably that wasn't clear. More specifically, I was talking about the lack of file-alike traits of console handles. Actually, it's serendipity finding out about Gow through your comment. I use Gnuwin32, but it's a bit outdated by now. – acelent Feb 21 '13 at 15:10

Despite anyone, to this kind of questions, finds immediately easy and comfortable to recommend some express version of visual studio, if you plain to work with native API, I think that's not the best way to start.

VS is HUGE: Gigabytes to download and install, ton and tons of .Net framework development libraries you will not use at all (if you are programming on the native API), Thousands of registry keys modified ...

If you just want to try a simple windows APP, that's not the way to go.

If you're are accustomed to GCC, the MinGW project have distributions that work fine and give a good "kick in the ass" to the '70s-style install procedures of migw. And there are IDE that play very well their job, without the complication of visual studio.

Give a look to: TDM GCC:

Codeblocks : (Suggestion: don't download the official release, dowload the last "nightly build": is much much more advanced, for certain features even of visual-studio express).

If you need tutorials, you can refer to the Forger's: some oddities, but still very well structured. And if you want to see C++ techniques applied to C++, give a look to the Relisoft Windows API tutorial.

Visual Studio is not "gigabytes", and certainly the Express versions are not that large. If you don't want the .NET Framework stuff, don't install it. I don't have it installed on my primary dev machine because I'm working in native C++ WinAPI. But you're not going to beat VS as a development environment. The Intellisense is unsurpassed. The built-in documentation is handy. The settings are all nicely tailored to Windows development. Yes, it'll take some learning but it's worth it. There's little advantage in learning a new IDE in Code::Blocks, etc. but lots of advantage in learning VS. – Cody Gray Jan 17 '12 at 22:30
@CodyGray: The download is few megabytes, but it dowload during the setup more than 600MB before asking what to install. The setup doesn't allow (unless launching with specific commands you cannot know if you haven't experience yet) to choose any option (The only thing you can skip is the SQL server) There is NO built-in documentation in the express edition (it links everything from the internet). All the documentation about the native API looks "hidden" in the index (it is visible only if you search from a specific API ...) – Emilio Garavaglia Jan 17 '12 at 22:56
@CodyGray: ... If you're are an exper in VS express setup you can surelly do everything you stated. But a learner cannot be an expert of the setup of a product it installs for the very first time and that is practically impossible to clean unistall. – Emilio Garavaglia Jan 17 '12 at 22:57
I prefer MinGW, but at least knowing that VS Express is around, and for free is pretty relevant for newcomers. – ZJR Jan 18 '12 at 2:48
> I am looking to do mainly C and C++ development, along with some x86. 
> I have found MASM primarily suits my needs for the latter.

c/c++/assembler are excelent languages to write console-programs or device drivers. if you want to implement windows-gui applications i would prefer using c# language with dotnet runtime using the c# express edition of visual studio.

you can create gui application with Visual Studio C++ Express as mentioned before but with c# (or it is much easier.

before the .net age microsoft used the classlibrary "MFC" to create gui-s in c++ for windows. this lib and the tools to do mfc are not supported by c++ express.

If you are using "Visual Studio C++ Express" you also have to learn that (managed-)c++ may have a different semantics than in traditional c++.

c++ with an automatic garbage collector. you will not know when the class-destructor is actually called.

In my opinion learning c# is much easier than to relearn microsoft-s-managed-c++-semantics.


Visual Studio is the way to go for development but let me also recommend the book "Windows via C/C++" it is the "Advanced Programming in the UNIX Environment" for windows. It has all sorts of info about how windows works, to start a process, allocate memory, load libraries. When I made the switch it was very helpful. The "Windows Internals" books are also very good.

You may also find this series of videos from Microsoft useful (and free)


They demonstrate a lot of the debugging and internals of testing MS apps that can help you come up to speed quickly.

That said, I'm a hacker not a developer so maybe I care about internals a bit more than your average convertee. Good Luck! Oh, and the C# comment is right on for apps; hacking and OS stuff is still C++ though.

hxxp:// reference doesn't work – gnat Jan 16 '14 at 8:58
change hxxp to http and it will, I just tested it.... – CryptoMonkey Jan 16 '14 at 23:22
Also "Windows system programming", and you can also use the channel9 diving-deep show – yoel halb Feb 16 '14 at 22:44

For shield about idiosyncrasy of win 32 api use .net not MFC , sadly no genius can integrate c++ with descent .net winforms ( witohut clr , deprecated i far as i know VS 2012 not have clr windows apps), in .net interfaces ( with c# ) you not need learn nothing about edit's you gui with visual studio integrated editor ( is probably the base of the window programming ) , and without need of documentation ( in many cases ) from autocomplete alone you can learn on the fly how to use any controls of windows gui not big deal , are controls ( classes ) and events this is all you need to know about .net GUI for make a program besides programming of course . I love c++ and link dll's on c++ with my c# interface , and of course you can render from opengl and / or directx from c++ dll to c# GUI to make 2D / 3D editor's etc without performance hit ( you not need MFC to do that ).

This isn't a very good quality answer. It could be improved, however. Additionally, if I'm understanding this right, you're saying the common language runtime in .Net isn't in .Net, which is clearly wrong. Not to mention suggesting Winforms when XAML-based options exist now. With some heavy editing, this could still perhaps become a useful answer. – Magus Apr 3 '14 at 15:19