Developing for Windows on Linux

Build and test both the Linux and Microsoft Windows versions of your project without rebooting. With the free tools MinGW and Wine, you might even call Win32 a cross-platform API.

Like most people who read Linux Journal, I am a rabid fan of all things Linux, GNU and open source. I run Linux on all of my personal machines, program on them, play on them and evangelize to others whenever possible. But, a large portion of the programming jobs out there involve writing applications for an operating system from Redmond, Washington.

For my job, I've had to write some smaller applications for the Microsoft Windows platform. Because speed of execution was an issue, I was going to have to write them in C, directly using the Win32 API. It occurred to me that if I was going to be using a standard language such as C, I might be able to develop in my nice and cozy Linux home.

This article is a short guide on developing an application for Windows completely within a Linux environment. I give a short introduction to Windows programming and step through compiling and testing a sample program. I also discuss Wine to simplify porting Windows source code to Linux.

Win32 Programming

For those of us raised on the wholesome nutrition of a UNIX-style process abstraction, the Windows model might seem downright heretical. The Windows model is a preemptive, multitasking, multithreaded, message-passing operating system. I'm limiting myself here to NT and its derivatives, 2000 and XP. All processes are considered threads by the operating system. This makes the process context slightly lighter than the traditional heavyweight process model used in UNIX-like operating systems. As a consequence of this everything-is-a-thread model, however, everything sits in global memory address space. With the correct permissions and the correct address, one program could twiddle another program's bits.

Another consequence of this is data structures created by the kernel don't sit at any fixed address. This means it is up to the user program to lock down the associated memory before using any global data structures, such as graphic contexts. You also must remember to unlock these structures once you are done with them, or they may help cause memory fragmentation.

Listing 1, available from the Linux Journal FTP site (see the on-line Resources section), is a basic Hello World program. Most of it is boilerplate, and only the portion within the switch statement is of any real interest. It does seem like quite a bit of code for a basic program, but that is the problem with using a low-level API. A good comparison on Linux would be writing code for X using Xt.

Instead of a main() function, a Windows GUI program starts at WinMain(). It's in this function that your program does all of its initialization. Part of this initialization includes defining the window class for the main window and associating a callback function for it. Next, create the main window and show it on the desktop. Control then passes to the message loop, and the callback function processes the messages that are sent to the main window.

A good quick introduction to writing Windows programs is available from winprog.org (see Resources). The authors of this Web site offer a good FAQ and a fairly good tutorial covering all of the basics. Of course, the bible for Windows programming is the massive book Windows Programming, by Charles Petzold. If you can't find what you need in this tome, you always can use it to beat the information out of your friendly neighbourhood Windows guru.

Cross-Compiling

One of the amazing things about GCC is that it has been ported to so many different platforms and operating systems. A great gift that comes from this is the ability to compile binaries on one platform that are destined for a completely different one. I regularly compile binaries for Solaris or Windows on my Linux laptop. This is an amazing advantage, allowing development to occur in a familiar, comfortable environment.

The purest way to set up is to go back to the source (see Resources). This way you can compile code with the exact settings and for the exact platform you want. Thankfully, this work has already been done. The good people at the MinGW Project maintain a port of GCC for compiling Windows binaries. This includes all of the associated files, such as the headers. The sources are available here along with binary tarballs. These programs also have been packaged for RPM-based and deb-based distributions. If you are running Debian, you can use apt-get to retrieve the mingw32 and mingw32-runtime packages. If you are running testing or unstable, you also should grab mingw32-binutils.

Most of the compilation options in GCC are available here in MinGW, along with a few extras. If you simply compile a program without any extra options, it can be run from the console. This is what you would do if you wanted to write a small, simple program that did not need a GUI. Because this is Windows, we want a GUI program, so we write all of the required boilerplate we saw above and add the -mwindows option to the compilation command. This sets up the macros and library links you need in order to compile a standard Windows executable. If you decide to write a more complicated Windows program that uses some other Windows' feature, you need to add in the libraries explicitly that you want linked.

In Windows you can define resources for your program. These include such items as menus, bitmaps and text strings, among others. These resources are defined in a separate file and need to be compiled separately before being linked to your executable. That job falls to the program mingw-windres, which creates an object file you subsequently can link to your executable.

To compile our simple example program shown in Listing 1, we use the command:

mingw-gcc -o example1.exe example.c -mwindows

______________________

Joey Bernard has a background in both physics and computer science. This serves him well in his day job as a computational research consultant at the University of New Brunswick. He also teaches computational physics and parallel programming.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More recent howto

Mitch Thomson's picture

The rather new MinGW-w64 project allows for creation of native 32- and 64-bit executables.
See compile Windows binaries under Linux for a quick howto.

Door number one, Door number two... Door number 36...

Confused's picture

I've used MinGW and MSYS before <microsoft bashing> my store-bought copy of vista suddenly decided it wasn't a valid licensed copy (which, to be fair, was resolved quickly and with lukewarm courtesy by tech support, and my copy did decide it was licensed after all, and I did not give it a fair chance to screw up again), and I decided it was a good time to wash my hands of the OS forever and stopped putzing around with cygwin in order to do my job without going into debt </microsoft bashing>

That said, though, the number of programs to choose from on the MinGW website is dizzying. Which program, specifically, did you grab and compile on your machine? Did you grab one of the .exe files and install it through wine, or is there a source distribution that I can build using the cozy make, su, make install procedure without invoking wine?

Just trying to navigate my way through a maze of identical-looking binaries, and I'm hoping that asking someone who actually got something working can shed a little bit of light on things for me.

Re: Developing for Windows on Linux

Anonymous's picture

(Replied to the wrong message earlier)

After reading this article, I immediately tried to apply it by compiling a couple of simple programs. My goal is to build Windows binaries and I want to include the Linux machines in the build process as well (using distcc). I built a cross compiler from the sources and everything seemed to build successfully. (The information for this came from this link: http://ranjitmathew.tripod.com/phartz/gcj/bldgcj.html

As a first test, I tried to compile a simple "Hello" file (hello.c) using the newly-created mingw32-gcc executable:

#include
int main(void) {
printf("Hello
");
return 0;
}

This worked and I was able to link hello.o on a Windows computer. Next, I tried to compile the C++ version (hello.cpp):

#include
using namespace std;
int main(void) {
cout
But this gave many errors. I knew it was that the include files were not being found, so I manually added them to the command line. I simply included all of the paths that the Linux g++ was using. (I discovered those paths by using the -v switch when compiling.) I even tried different variations with the include files that came with the mingw32 sources. I've been able to remove most of the errors, but a few still remain. The first one is this:

/usr/include/g++/i486-suse-linux/bits/c++locale.h:59: error: syntax error

which is complaining about this typedef:

typedef __locale_t __c_locale;

apparently, __locale_t is not defined anywhere (as far as I could tell.) Incidently, the same .h file under Windows looks like this:

typedef int* __c_locale;

I'm not an expert with Linux or g++, but I'm guessing there's some configuration issues as to why the new mingw32-g++ can't find the right header files. Even moving the mingw32-* binaries into /usr/bin doesn't help. Am I missing some header files or something else?

--Dig

Re: Developing for Windows on Linux

Anonymous's picture

Well, I missed that the angle brackets ( C++ insertion operator) confused the HTML reader (even after preview...). This is the HTML-friendly C++ code:

#include [iostream]
using namespace std;
int main(void) {
cout [[ "Hello" [[ endl;
return 0;
}

Replace [ and ] with less-than and greater-than.

--Dig

Re: Developing for Windows on Linux

Anonymous's picture

The first part of the section Win32 programming is simply dead wrong (well, almost). No proofreading?

Quote1: "All processes are considered threads by the operating system."

- No, processes are not considered threads. A process is a set of resources (private virtual address space, file handles, etc, etc). Each process has at least one thread though - the main thread of execution.

Quote2: "This makes the process context slightly lighter than the traditional heavyweight process model used in UNIX-like operating systems."

- The process context is not any lighter than UNIX - at least not because of the non-existing "everything-is-a-thread model".

Quote3: "With the correct permissions and the correct address, one program could twiddle another program's bits."

- No. Nope. Simply not possible without writing a kernel-mode driver. Unless one of the program exposed its data through named memory-mapped files (similar to mmap) with incorrect permissions set.

Articles like this only help to spread the many misconceptions on the NT family of operating systems. I seriously hope you haven't written any commercial applications for Windows ;-)

Whenever you have time, buy and read the latest edition of "Inside Windows NT". You won't regret it.

// Dev Anonymous

Re: Developing for Windows on Linux

joeybernard's picture

I do stand corrected on these issues. It was a combination of a lame attempt at humour/Microsoft bashing, combined with my working with mythology rather than going to sources and checking what I assumed was "common knowledge". While I did not have the money or inclination to get the book anonymous suggested, I did check out the great information on the sysinternals site (http://www.sysinternals.com). I claim temporary stupidity, simply because I never had to deal with systems level programming in Windows. Please accept my apologies.

Re: Developing for Windows on Linux

Anonymous's picture

After reading this article, I immediately tried to apply it by compiling a couple of simple programs. My goal is to build Windows binaries and I want to include the Linux machines in the build process as well (using distcc). I built a cross compiler from the sources and everything seemed to build successfully. (The information for this came from this link: http://ranjitmathew.tripod.com/phartz/gcj/bldgcj.htm)

As a first test, I tried to compile a simple "Hello" file (hello.c) using the newly-created mingw32-gcc executable:

#include
int main(void) {
printf("Hello
");
return 0;
}

This worked and I was able to link hello.o on a Windows computer. Next, I tried to compile the C++ version (hello.cpp):

#include
using namespace std;
int main(void) {
cout
But this gave many errors. I knew it was that the include files were not being found, so I manually added them to the command line. I simply included all of the paths that the Linux g++ was using. (I discovered those paths by using the -v switch when compiling.) I even tried different variations with the include files that came with the mingw32 sources. I've been able to remove most of the errors, but a few still remain. The first one is this:

/usr/include/g++/i486-suse-linux/bits/c++locale.h:59: error: syntax error

which is complaining about this typedef:

typedef __locale_t __c_locale;

apparently, __locale_t is not defined anywhere (as far as I could tell.) Incidently, the same .h file under Windows looks like this:

typedef int* __c_locale;

I'm not an expert with Linux or g++, but I'm guessing there's some configuration issues as to why the new mingw32-g++ can't find the right header files. Even moving the mingw32-* binaries into /usr/bin doesn't help. Am I missing some header files or something else?

-- Dig

Re: Developing for Windows on Linux (Ignore previous post)

Anonymous's picture

Ignore the above, I replied to the wrong message. I've reposted it. D'oh!

--Dig

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix