open watcom compiling gcc on win32

[Kai Henningsen]

esp5@pge.com (Edward S. Peschko)  wrote on 30.01.04 in <20040130211615.GA16722@mdssdev05.comp.pge.com>:

> On Fri, Jan 30, 2004 at 06:29:13PM +0100, Oscar Fuentes wrote:
> > "Edward S. Peschko" <esp5@pge.com> writes:
> >
> > > Ok, I wasn't being specific enough. That is exactly what I want -
> > > visual C++ ABI compatibility at the 'high level' on win32.
> > > In a capsule, my argument is that it opens up a world of possibility for
> > > gcc/g++ on win32, it is completely feasible through open watcom.
> >
> > How lack of MSVC++ ABI compatibility is hurting you?
>
> well it is hurting me.. Here's an example -
>
> Right now, the perl world on win32 is pretty much divided in half, with
> the cygwin perl on the one hand, and the activestate perl on the other.
> python is the same way.

The question is of course, _why_ is it split like this?

I do _not_ believe that C++ binary compatibility is the reason. The vast  
majority of Perl native-code modules is written in C, not C++, and there  
is no ABI incompatibility with C. In fact, I'm using DLLs from gcc- 
compiled code (specifically, a Linux-hosted MinGW cross-compiler - it  
turns out much easier to deal with cross issues than with Windows issues  
for tools and makefiles for my case) and have not ever had an ABI  
compatibility problem, because most DLLs still have C-based interfaces.  
(That may change, of course.)

Instead, I believe the reason is Unix compatibility - or in other words,  
linking with CYGWIN1.DLL as opposed to MSVCRT.DLL or one of the other VC++  
libc implementations. (Nota bene that MinGW gcc does link with VC++ libc  
implementations - that's pretty much how it is defined to work!)

There are Perl modules that really want to run on some kind of Unix, and  
those probably prefer Cygwin. In fact, Perl itself prefers Cygwin (where  
fork() works) to dealing with Windows (where fork() needs to be simulated  
- which is of course how Cygwin manages to present a working fork()).

I do not know Python, but I expect it is the same.

> Hence, in order to do what I need to do, I need to maintain *two sets* of
> perls and pythons. And some modules work on activestate's, some modules work
> on cygwin.

True, but the cause is most likely not what you believe it is - you're  
barking up the wrong tree.

> but that's just it. How many times have you had to link to proprietary
> APIs like winrunner and oracle app-works, or to control apps like photoshop?

How many such APIs involve C++ as opposed to C?

> No offense intended, but as it is, for large software vendors gcc is really
> just a toy on win32 - it fits into its own little world, it might be nice
> to play with, but I don't see any large companies releasing APIs targetted
> at gcc/g++.

Nor do I see them releasing APIs incompatible with gcc/g++. (Not the least  
because that would make them incompatible with lots of other compilers as  
well.)

MfG Kai