Developing for Windows on Linux

(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

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