- Some ability with Windows. This article does not micromanage every last tiny step of the process.
- Some knowledge of C++ is required. Teaching C++ is outside the scope of this article.
This seems like a reasonable place to start. Go to SourceForge and search for mingw. Probably the top result will be MinGW itself.
The reason for going via search is so that (a) you can see what sort of other stuff is available; (b) so that this document does not go out of date when SF reorganises itself. The scope of this article is just to get you started, so it won't touch on anything else.
After entering the MinGW page, go to Files. There's a lot of stuff that could be downloaded, but fortunately one of the downloads is a package of related utilities. At the time of writing the most recent is MinGW-3.1.0-1. This contains the following packages:
So we'll download this. Click the SourceForge Download MinGW-3.1.0-1.exe link, and proceed as normal through the SourceForge download process. If your browser gives you the option of running the executable, this should be ok.
At this stage I doubt that package changes will affect the contents of this article, so if there is a more recent package you'll probably be ok to download that instead. I'll also assume that we won't need to upgrade any of the packages.
Run MinGW-3.1.0-1.exe from wherever you saved it. I'll be installing in D:\MinGW.
You could associate C++ files with d:\mingw\bin\gcc if you like, but I'll be working mainly within the command line.
You won't want to clutter the bin directory with programs, so add d:\mingw\bin to your PATH. Go to Start -> Settings -> Control Panel -> System -> Advanced -> Environment Variables, then either update the system path or add/modify the user path.
Then open a new DOS box and type "gcc" (not from the MinGW bin directory). You should get the message "gcc: no input files". This shows the installation has been successful.
Your First MinGW Program
For me, DOS boxes are opened in the directory c:\documents and settings\dave. This is as good a place as anywhere. Create a new file with the command notepad hello_dos.cpp.
and save the file. Build it with g++ hello_dos.cpp -o hello_dos
and run it; you should get the output: "Hello, world"
Your first MinGW Windows program
Petzold's introductory Hello Windows program was a bit long at 84 lines, although the program existed for a different reason to this one. This one will be considerably simpler.
Create hello_win.cpp with Notepad as above and enter the following:
MessageBox(0,"Hello, Windows","MinGW Test Program",MB_OK);
Compile with g++ -mwindows hello_win.cpp -o hello_win
Then run it, and you should get a message box in the centre of the screen. This can also be run from Explorer. Without the -mwindows option, when run from Explorer you would also get a nasty DOS box appear for the duration of the program. However this might be a useful place to send debugging information; if you also include stdio.h you can use printf to display on this window.
For the WinMain prototype, go to MSDN and search for winmain. There are downloadable WinAPI references available elsewhere but I won't touch on them here.
Now for a REAL Windows program
There's quite a lot to a Windows program - creating the window class, the window procedure, not to mention resources and DLLs. I plan to pull this program apart in a future article. So here's a simple Windows program that displays a window.
LRESULT CALLBACK WindowProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam);
int WinMain(HINSTANCE hInst,HINSTANCE,LPSTR,int nCmdShow)
wc.style=CS_HREDRAW | CS_VREDRAW;
hwnd = CreateWindow(AppTitle,AppTitle,
while (GetMessage(&msg,NULL,0,0) > 0)
LRESULT CALLBACK WindowProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
return DefWindowProc(hwnd, msg, wparam, lparam);
This can also be downloaded from http://www.osix.net:80/modules/folder/index.php?tid=6126&action=vf.
WinMain is the entry point to the program. This function creates and registers the window class which stores information relevant to the application window - the icon, menu, window procedure and so on. Then it creates the window and enters into the application message loop. The GetMessage function returns zero when the application receives a WM_QUIT message.
WindowProc is the function that receives messages for the window and can be confusing in terms of what it should return, so here it is in very simple terms:
- if you process a message, you must return 0.
- if you don't process a message, you must return the result of DefWindowProc.
If you look at other programs you'll see window procedures in slightly different formats. Some will end a case block with a return 0 instead of a break, often also calling DefWindowProc at the end (outside the switch) and not in a default: clause. Whichever way you choose, make sure the code follows the above two rules and you should be ok. None is really more correct than any others, although my choice uses the standard switch structure (case/break not case/return), and associates the default action with the default: clause.
If the application should close when the main window is closed, which is common although not always the case, you should call PostQuitMessage in response to WM_DESTROY which is the last message sent to a window. If you don't, the application main window will close, but the application will still be active and the only way to kill it will be with Task Manager or equivalent.
Drawing on a window isn't necessarily the most intuitive process. All drawing operations operate on a device context (HDC), not a window handle. BeginPaint is one way to get a device context; the main benefit of BeginPaint over GetDC is that BeginPaint's device context is already clipped to the area of window that needs redrawing (specified in ps.rcPaint), thus providing a considerable speedup for applications whose redraw operations are long and complicated. BeginPaint should only be called in response to WM_PAINT; GetDC can be called at any time.
One advantage to using device contexts is that everything that can be drawn on - windows, memory bitmaps, printers etc - has an associated device context, so it is possible for exactly the same code to be used for drawing on the screen and printing. Further, if you decide to change the drawing to use double buffering to eliminate flicker, none of the sometimes complicated redraw code needs changing, only where it is invoked.