What are "gtk+", "glade", and "MinGW"?

Gtk+ is a free cross-platform graphical toolkit.  When you develop software using gtk+, it is possible to write a single program which works almost without change on various computer platforms like Linux, Mac OS X, and Windows.  In order to compile a program that depends on gtk+, you therefore have to have the necessary gtk+ development environment installed on your computer.

With that said, though, one must deal with the fact that the gtk+ developers provide little advice as to how to use gtk+ on Windows.  It turns out not to be difficult, but it helps to have it explained.   I assume in advance that you already have some experience at compiling C-language programs; if you don't, you probably are going to need to acquire some (or to bring in a friend with some experience), before using any of the stuff I'm going to say.

Glade is free software that helps you rapidly create a gtk+ program, and to easily design a user interface.  While there are other ways to create gtk+ applications, using glade is a very common method for doing so.  You can find out more about glade at glade.gnome.org.

MinGW is a free Win32 port of the GNU gcc C/C++ compiler.

P.S.:  After figuring out most of the stuff in this howto (and writing it), I discovered a site devoted to Win32 ports of gtk+ and gladewingtk.sourceforge.net.  You may want to check it out if my remarks below don't meet your needs.

Gtk+ 1 or gtk+ 2?

I will discuss only the newer gtk+ 2, rather than the older gtk+ 1.  The newer version has more features and results in software that's simply visually more attractive.  However, using version 2 does limit you in some ways:  For example, at present (10/25/03) the Mac OS X port is version 1 only.  I assume that most of what I say below can be adapted easily to gtk+ 1, but I don't care to explore the possibilties myself.

How To Install gtk+ 2 for Developing in Windows

  1. Download a bunch of stuff.  You're going to need both gtk+ itself, as ported to Win32, and a suitable C-language compiler.  In parentheses I show the specific software versions I have used, but presumably later versions will work just as well.  (In fact, since the time this section was written, I have used later versions of most of these libraries.  Forgive me for not providing exact links, but as you can imagine, these are likely to change so often that I would have a tough time keeping them up to date.)
    • From www.mingw.org, download the MSYS (1.0.9) and MinGW (3.1.0-1) exe files.
    • From www.gimp.org, download all of the following zipfiles:  atk (1.2.4), atk-dev (1.2.4), gettext-runtime (0.12.1), gettext-tools (0.12.1), glib (2.2.3), glib-dev (2.2.3), gtk+ (2.2.4), gtk+-dev (2.2.4), jpeg lib (6b-1), jpeg bin (6b-1), libiconv lib (1.9.1), libpng lib (1.2.5), libpng bin (1.2.5) pango (1.2.5), pango-dev (1.2.5), pkgconfig (0.15), tiff lib (3.5.7), tiff bin (3.5.7), zlib lib (1.1.4-1), zlib bin (1.1.4-1).
  1. Install MinGW.  This is simply a matter of running the exe file you downloaded above, and answering the prompts.  For the sake of argument, I'm going to assume that you have used the installation directory c:\mingw.
  2. Install all of the zipfiles you downloaded above.  Unzip them under c:\mingw.  After doing so, you should see directories such as c:\mingw\bin, c:\mingw\usr, c:\mingw\etc, and so on.
  3. Move the file(s) libatk*.dll from c:\mingw\lib to c:\mingw\bin.
  4. Install Msys.  Again, this is just running the exe file and following the prompts.  It doesn't really matter what install-directory you use, but at the end you will be prompted to tell which directory MinGW was installed under.  (The answer will be c:/mingw.)
  5. If you're reading this HOWTO because you just want to compile Virtual AGC programs, then you can return to the Virtual AGC download page now. 

"Command Line" Compilation of gtk+ Programs in Windows

The Msys Development Environment

Let's suppose you have a gtk+ application you want to compile for Windows. 

The trick to compiling such programs is to use Msys.  After installing Msys, you should have noticed the creation of an Msys icon on your desktop.  Clicking on the Msys icon opens up a window with a command-line environment inside it.  However, this command-line environment is not the "DOS Prompt" normally available under Windows; rather, it is a Linux-style command-line environment using what is known as the sh shell. 

The point of working with Msys is that it helps you to build the executable Win32 programs.  However, Msys is not itself needed for running these programs after they're built.  In particular, you can deploy or distribute the executables to computers which don't themselves have Msys installed on them.

When working with Msys, you will be doing all of your work within your "home" directory.  The home directory is a Linux concept that doesn't actually exist in Windows, and I'm not sure exactly how Msys chooses which particular directory it uses.  (In other words, it will be different on your computer than on my computer.) 

Getting Source Code

By some means you have go put the source-code you need into the Msys home directory.  Perhaps you've developed it directly using a Win32 port of glade; perhaps you've developed in Linux and have copied the source code; perhaps you've downloaded it from the web.  It doesn't really matter, as long as it ends up in the home directory. 

The easiest way to get files into or out of your Msys home directory is to use the "cp" command from within the Msys environment.  For example, here are two sample commands, one of which copies the directory c:\DirA into the home directory, and one of which copies the DirB subdirectory to the root directory of the c: drive.

cp -a c:/DirA .
cp -a DirB c:/

(Use the command "cp --help" to get more info on how to use the "cp" command.)

For simplicity, I'll assume below that the code was developed using glade, and resides in a sub-directory of the home directory named according to the way the project was named when it was created in glade.  On the other hand, if the source code is in the form of a "tarball", all of the standard tarball-unpacking utilities like tar, gzip, and bzip2 are available within the Msys working environment.

Adapting Linux Source Code to Win32

There is, of course, no guarantee that a gtk+ application developed on Linux will actually compile and work properly in Win32, even if you follow my instructions exactly.   There's also no way in the world I can possibly cover all of the things you might have to adapt in your Linux source code to be compatible with Win32 (or vice-versa).

If only generic C-library functions and gtk+ functions have been used, there's a good chance that the program will work without much difficulty.  However, if Linux-specific functions that don't work (or work differently) in Windows are used, then the program probably won't compile or won't work well.  For example, accessing the RS-232 ("com ports") has a completely different API in Linux and Windows, and can only be adapted with a lot of effort.   On the other hand, using sockets looks very similar in Linux and Windows, but differs in certain details. 

At the very least, you'll probably find that you have to make at least a few source-code changes like the following:

#ifdef WIN32
#include <windows.h>

Compiling the Source Code

Glade enforces a build process similar to that of many other Linux programs, in which one first runs a script called "configure" (which creates a Makefile), then runs "make", and then runs "make install".  Unfortunately, "configure" scripts generally depend upon programs called autoconf and automake, which are theoretically available in Windows, but which I've never gotten to work properly in Msys.  Fortunately, it's reasonably easy to work out the necessary compiler command-line switches, and therefore to do without the configure-script. 

In general, to build a gtk+/glade application in Win32, one would run the C compiler from the Msys command prompt as follows:

cd GladeProjectName/src
gcc \

-o NameOfExecutable\
`pkg-config --cflags gtk+-win32-2.0` \
-mno-cygwin -mms-bitfields \
-DPACKAGE_DATA_DIR="\"/mingw/share\"" \
-DPACKAGE="\"GladeProjectName\"" \
*.c \
`pkg-config --libs gtk+-win32-2.0`

Note the use of backward-quotes rather than apostrophes above.  In other words, make sure to use `pkg-config` rather than 'pkg-config'.   The NameOfExecutable is, of course, the name you want to assign to the exe-file which is going to be produced.  The GladeProjectName is the name assigned when the original glade project was created.  For example, these might be "MyProgram.exe" and "MyProgram", respectively.

I'm not entirely sure, but I believe the same approach would work for compiling non-gladegtk+ apps as well.  Some adjustment of directory names would undoubtedly be needed.

Installing/Deploying the Executable

What is needed to install the executable program on another computer after it has been built?  My suggestions are:

Some Other Tools That May Help You


As I mentioned above, the most convenient (free) way I've found to develop gtk+ applications is to use the glade rapid-application development software.  Glade is available both for Linux and for Win32, and the project data is interchangeable among the Linux and Win32 versions.  You can download the Win32 port at wingtk.sourceforge.net.  At this writing (10/25/03), three separate versions of glade are available at that site.  I'd suggest using the one labeled "Glade for GTK+2".

RedHat Source Navigator

Personally, I find that there are many advantages to editing my source-code trees within an integrated development environment (IDE) like RedHat's free Source Navigator program.  Source Navigator has the helpful feature that it's available both for Linux and for Windows, and hence I can use the same working environment when I'm debugging the Win32 port as I do when I'm writing the code in Linux.  The main advantage of the IDE, though, is that when you build the code from within the IDE and encounter compiler errors, you can click on the error listing and jump right to the place in the source code where the error occurs.  This is a bit of a trick when you are compiling from the Msys environment, but I can tell you how to do it.  (I assume the same approach will work with IDEs other than Source Navigator, but I don't really have any specific information about it.)

Basically, when you tell Source Navigator to build your code, it opens up a window in which (by default) the command "make" is executed.  You need to replace the "make" command with a command that instead takes the use of the Msys environment into account:

MsysInstallDirectory\bin\sh --login -c "cd SourceDirectory; MakeCommand"

Your source code would typically be in some subdirectory of your Msys home directory, such as /home/rburkey/TestProject/src.  The command you  use in the Msys environment to build the executable might be the complicated gcc command described above; or perhaps you have wrapped the gcc command in a makefile --- called, say, Makefile.Win32.  So the command used by Source Navigator to build the executable could be

c:\msys\1.0\bin\sh --login -c "cd /home/rburkey/TestProject/src ; make -f Makefile.Win32"

Source Navigator expects the utility cat to be present for this to work.  Fortunately, cat is installed automatically when Msys is installed.  Just make sure that c:\msys\1.0\bin is in your PATH (or else copy cat.exe and msys-1.0.dll to someplace which is already in your PATH).

This approach seems to work quite well, although it does have the annoying characteristic of opening and closing a new window (with nothing in it) every time it invokes the compiler.

By the way, note the directions of the slashes in the command above.  The command "sh" is executed in the normal Win32 command shell, and therefore has backslashes as directory-name delimiters.  The stuff within the double-quotes, on the other hand, is executed within the sh command shell, and therefore expects to find forward-slashes as directory-name delimiters.

This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2017-01-11.

Virtual AGC is hosted by ibiblio.org