open watcom compiling gcc on win32

open watcom compiling gcc on win32

[Edward S. Peschko]

hey,

I was wondering if open-watcom could be used to compile gcc on win32... I was hoping to
do so under cygwin..

If so, what are the steps for doing so? If not, what's the preferred compiler for 
building gcc on win32?

Thanks much,

Ed

(
ps - have the gcc folks looked at the watcom code? I know its not completely GPL
compatible, but I'm sure that some sort of agreement could be made with Sybase
to let gcc encorporate ideas from watcom...

well, its worth a try anyway. The personal thing I want to see is compatibilty with
VC++ 6.0 on win32 - which Watcom has and g++ of course lacks.

I know is discussed in the FAQ - however, I'm really scratching my head on how to 
use cygwin to talk to stuff like oracle and certain oracle tools in a performance 
acceptable way.
)

Re: open watcom compiling gcc on win32

[Marcel Cox]

Edward S. Peschko wrote:

> I was wondering if open-watcom could be used to compile gcc on
> win32... I was hoping to do so under cygwin..
> 
> If so, what are the steps for doing so? If not, what's the preferred
> compiler for building gcc on win32?

You should take a look at the Mingw32 project which is a native GCC
port to win32 platforms:

http://www.mingw.org/



-- 
Marcel (using XanaNews 1.16.1.3)
I can resist everything but temptation

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

On Tue, Jan 27, 2004 at 08:00:51AM +0000, Marcel Cox wrote:
> Edward S. Peschko wrote:
> 
> > I was wondering if open-watcom could be used to compile gcc on
> > win32... I was hoping to do so under cygwin..
> > 
> > If so, what are the steps for doing so? If not, what's the preferred
> > compiler for building gcc on win32?
> 
> You should take a look at the Mingw32 project which is a native GCC
> port to win32 platforms:
> 
> http://www.mingw.org/
> 
well, that's the point - 

I need a compiler that can link with VC++ dlls *and* compile the gnu toolchain. 
Right now, both python and perl are split into two 'personalities' : you can either 
compile modules *for* win32 or modules *for* unix, but you can't do both 
and hope to have them play well together.

Plus, certain third-party APIs don't work well with mingw - well, pretty much all
third-party APIs don't work well because they are all compiled for Borland
or VC++. And COM just plain sucks - most tool people assume that you have 
VC++ or Borland.

So, as far as I see it, watcom is the only viable choice for what I want to do.
And if I could compile gcc with watcom, I could pretty much compile anything gnu-like.

Ed

Re: open watcom compiling gcc on win32

[Marcel Cox]

Edward S. Peschko wrote:

> I need a compiler that can link with VC++ dlls and compile the gnu
> toolchain.  Right now, both python and perl are split into two
> 'personalities' : you can either compile modules for win32 or modules
> for unix, but you can't do both and hope to have them play well
> together.
> 
> Plus, certain third-party APIs don't work well with mingw - well,
> pretty much all third-party APIs don't work well because they are all
> compiled for Borland or VC++. And COM just plain sucks - most tool
> people assume that you have VC++ or Borland.
> 
> So, as far as I see it, watcom is the only viable choice for what I
> want to do.  And if I could compile gcc with watcom, I could pretty
> much compile anything gnu-like.

Actually, your problem is not so much the compiler itself as the make
machinery and the APIs available.
In fact, most of the gnu-like programs do not rely on any special GCC
features or extensions. However most of them are based on
automake/autoconf style configuration scripts that presuppose a Unix
like environment to run, and many of the applications are written close
to Posix APIs and often call functions that are not natively available
on Windows.

To solve the first problem, there are 2 kind of approaches:
- either you create a Unix like shell environment with the associated
tools under Windows. This has both been done in the Cygwin and the
Mingw project
- the other solution is to create new make or project files specific
for the development environment you have. An example of this can for
example be seen in the Ethereal project where there are automatic
configuration scripts for Unix like environments and a finished make
for for use with MSVC++

The second problem (Posix compatibility) is generall more tough to
solve. You either have to develop to a Posix emulation library (like
Cygwin) or you have to do a major rewrite of the projects by replcing
Posix style constructs with their more or less equivalent Windows
functionality.


-- 
Marcel Cox (using XanaNews 1.16.1.3)

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

> > So, as far as I see it, watcom is the only viable choice for what I
> > want to do.  And if I could compile gcc with watcom, I could pretty
> > much compile anything gnu-like.

> Actually, your problem is not so much the compiler itself as the make
> machinery and the APIs available.

> The second problem (Posix compatibility) is generall more tough to
> solve. You either have to develop to a Posix emulation library (like
> Cygwin) or you have to do a major rewrite of the projects by replcing
> Posix style constructs with their more or less equivalent Windows
> functionality.

well, I have no problem *using* cygwin or dynamically linking a cygwin.dll.

But - the cygwin dll that I produce has to 'play well' with vc++ dlls. 
And *that's* what watcom provides.  In fact, that was what I was planning on 
doing. Compiling cygwin with watcom to produce a vc++ compatible cygwin dll.

And what I'm saying is that is what gcc should provide.  gcc, ld, ar, as, on win32 
should produce visual C++ compatible dlls.

Borland does it, watcom does it.. I don't know if the intel compiler 
does it, but I bet it does - VC++, 6 and above, is the standard by default
on those platforms. 

And since watcom is open source, it points the path on how to do it - no 
reverse engineering needed. I already talked to the watcom folks; the 
license explicitly allows people to look at the code and reverse engineer 
concepts. They might be mad if whole sections of code were taken and encorporated
into gcc outright, but I doubt that would even be feasible in the first place.

Ed

(
ps - apparently watcom 1.2 compatibility with VC++ is pretty damn good, ie
production ready or approaching it. At least that's what I surmised when 
googling for it, and asking around. Although I admit I have a small sample 
(5 'works fine for me's' and one resolved production problem.)

In any case, its something to check out.

Here's one thread: 

http://makeashorterlink.com/?U29316D37
)

Re: open watcom compiling gcc on win32

[DJ Delorie]

> But - the cygwin dll that I produce has to 'play well' with vc++ dlls. 
> And *that's* what watcom provides.  In fact, that was what I was planning on 
> doing. Compiling cygwin with watcom to produce a vc++ compatible cygwin dll.
> 
> And what I'm saying is that is what gcc should provide.  gcc, ld, ar, as, on win32 
> should produce visual C++ compatible dlls.

At this point, you've left the realm of gcc and wandered into either
the binutils realm, or the cygwin realm.  The mechanisms for producing
DLLs are in binutils (specifically, the linker "ld"), and the policy
for making cygwin1.dll specifically rests with the cygwin project.

http://sources.redhat.com/binutils/
http://www.cygwin.com/

Re: open watcom compiling gcc on win32

[Jonathan Wilson]

I believe what you are asking for is support for the visual C++ ABI in GCC.

Not that I know much about GCC but from what I have heard, there are things 
in GCC that make it harder to implement and things in Open Watcom that make 
it easier to implement.

Just as an aside, I was trying to add Thread Local Storage (i.e. the 
__thread keyword from visual C++) to GCC and I was unable to implement it 
because I was unable to figure out the correct RTL and other code to add.

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

On Thu, Jan 29, 2004 at 06:46:04PM -0500, DJ Delorie wrote:
> 
> > But - the cygwin dll that I produce has to 'play well' with vc++ dlls. 
> > And *that's* what watcom provides.  In fact, that was what I was planning on 
> > doing. Compiling cygwin with watcom to produce a vc++ compatible cygwin dll.
> > 
> > And what I'm saying is that is what gcc should provide.  gcc, ld, ar, as, on win32 
> > should produce visual C++ compatible dlls.
> 
> At this point, you've left the realm of gcc and wandered into either
> the binutils realm, or the cygwin realm.  The mechanisms for producing
> DLLs are in binutils (specifically, the linker "ld"), and the policy
> for making cygwin1.dll specifically rests with the cygwin project.

well, no, I wouldn't say that I've 'left the realm of gcc' - after all, the objects
that gcc produce, and how certain features of g++ on win32 work (RTTI, etc) would 
need to change and have to work smoothly with ld, and I would argue that it is
a *steering committee* decision that could prompt such a change in cygwin.

And the suggestions I got from some members of the mingw group
was to talk to the gcc steering committee. So here I am.  And in any case,
its a point in the g++ FAQ that I'm disputing:

http://docs.freebsd.org/info/g++FAQ/g++FAQ.info.problems_linking_with_other_libraries.html

I'd say this holds true for unix, untrue for win32. 

Ed

(
ps - I'll talk to the binutils group as you suggest.. however, in order for this
to work the three groups would have to work together. which sort of doesn't leave me
too much hope that it will happen..

however, there are other reasons for looking at watcom - optimisation being one 
of the primary ones. A command decision has to be made, and perhaps the will 
will be found and a set of gnu tools that produces vc++-linkable libraries 
will be implemented along the way. This could be slightly optimistic though.. ;-)
)

Re: open watcom compiling gcc on win32

[Jonathan Wilson]

> At this point, you've left the realm of gcc and wandered into either
> the binutils realm, or the cygwin realm.  The mechanisms for producing
> DLLs are in binutils (specifically, the linker "ld"), and the policy
> for making cygwin1.dll specifically rests with the cygwin project.
Actually, I believe that the windows versions of GCC can already produce 
windows compatible DLLs.

What this guy (and possibly others here and on the mingw list) seem to be 
asking for is for GCC to implement the visual C++ ABI (something which, 
from what I understand Open Watcom already does).

Re: open watcom compiling gcc on win32

[DJ Delorie]

> well, no, I wouldn't say that I've 'left the realm of gcc' - after
> all, the objects that gcc produce, and how certain features of g++
> on win32 work (RTTI, etc) would need to change and have to work
> smoothly with ld, and I would argue that it is a *steering
> committee* decision that could prompt such a change in cygwin.

In that case, you weren't specific enough the first time around.  To
me, "objects" refers to object files, which the assembler (not gcc)
produces.  "Compatible" for dlls usually means the system can load
them, tools can manipulate them, etc.  ABI compatibility at the high
level (C++) is a different story.

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

On Thu, Jan 29, 2004 at 07:37:41PM -0500, DJ Delorie wrote:
> 
> > well, no, I wouldn't say that I've 'left the realm of gcc' - after
> > all, the objects that gcc produce, and how certain features of g++
> > on win32 work (RTTI, etc) would need to change and have to work
> > smoothly with ld, and I would argue that it is a *steering
> > committee* decision that could prompt such a change in cygwin.
> 
> In that case, you weren't specific enough the first time around.  To
> me, "objects" refers to object files, which the assembler (not gcc)
> produces.  "Compatible" for dlls usually means the system can load
> them, tools can manipulate them, etc.  ABI compatibility at the high
> level (C++) is a different story.

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.

so, how realistic is this? 

Ed

Re: open watcom compiling gcc on win32

[Oscar Fuentes]

"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?

BTW, FYI, Borland is not C++ ABI compatible with MSVC++.

> so, how realistic is this? 

In the 3.x series, g++ uses a "industry-standard" C++ ABI. The old ABI
was abandoned due to the extra work required for its maintenance. Have
you asked MS if they plan to support that standard C++ ABI ? ;-)

I'm not a gcc developer and so I can't say how much work your proposal
requires (a lot, I guess) but as a MinGW user I can't see where the
benefit are, other than using pre-built MSVC++ C++ libraries.

-- 
Oscar

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

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.

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.

Hence, if I want to use expect in a script, I need to turn to cygwin.
When I want to use Win32::AdminMisc, I need to turn to ActiveState.
And if I need to bind to a third party API I need to turn to ActiveState.

I don't want to maintain two separate distributions just because the 
compilers squawk with each other. I want things to be transparent. It costs
me functionality because I can't both do Expect and Win32::AdminMisc in the 
same script, and because I can't link in certain third-party APIs (from 
Oracle, for instance.)

If g++ was really smart, it would provide a compatibility mode which 
translated VC++ headers/etc into g++ (preferably STL) components, 
a 'crutch' for people who want to dump VC++ altogether.

> BTW, FYI, Borland is not C++ ABI compatible with MSVC++.

reference? I see different.

http://shop.store.yahoo.com/1-software-group/borcbuil50en.html

> > so, how realistic is this? 
> 
> In the 3.x series, g++ uses a "industry-standard" C++ ABI. The old ABI
> was abandoned due to the extra work required for its maintenance. Have
> you asked MS if they plan to support that standard C++ ABI ? ;-)

yeah yeah yeah.. very funny... I would say that the standard by default 
is VC++.

> I'm not a gcc developer and so I can't say how much work your proposal
> requires (a lot, I guess) but as a MinGW user I can't see where the
> benefit are, other than using pre-built MSVC++ C++ libraries.

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? 

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++. 

I don't want it to be that way. I want to dump VC++ altogether and use 
gcc (since it is the compiler I use on unix). It is really annoying me that
I can't, and that I'm forced to look for an alternative. (ie: watcom)

Ed

Re: open watcom compiling gcc on win32

[Ian Lance Taylor]

"Edward S. Peschko" <esp5@pge.com> writes:

> > BTW, FYI, Borland is not C++ ABI compatible with MSVC++.
> 
> reference? I see different.
> 
> http://shop.store.yahoo.com/1-software-group/borcbuil50en.html

I don't see anything there which says that the C++ ABI is the same.
But I really have no information on the topic.

On the other hand, I've heard several times that Microsoft has
patented their vtable layout.  That would make it impossible for gcc
to emulate it, unless Microsoft gave explicit permission.

Ian

Re: open watcom compiling gcc on win32

[Devang Patel]

On Jan 30, 2004, at 1:49 PM, Ian Lance Taylor wrote:

> On the other hand, I've heard several times that Microsoft has
> patented their vtable layout.

http://patft.uspto.gov/netacgi/nph-Parser? 
Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ 
srchnum.htm&r=1&f=G&l=50&s1=5,297,284.WKU.&OS=PN/5,297,284&RS=PN/ 
5,297,284

[ US Patent Number: 5,297,284]

>  That would make it impossible for gcc
> to emulate it, unless Microsoft gave explicit permission
--
Devang

Re: open watcom compiling gcc on win32

[Robert Dewar]

Devang Patel wrote:

> 
> On Jan 30, 2004, at 1:49 PM, Ian Lance Taylor wrote:
> 
>> On the other hand, I've heard several times that Microsoft has
>> patented their vtable layout.
> 
> 
> http://patft.uspto.gov/netacgi/nph-Parser? 
> Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ 
> srchnum.htm&r=1&f=G&l=50&s1=5,297,284.WKU.&OS=PN/5,297,284&RS=PN/ 5,297,284
> 
> [ US Patent Number: 5,297,284]
> 
>>  That would make it impossible for gcc
>> to emulate it, unless Microsoft gave explicit permission

Don't be too quick to make legal conclusions of this type
unless you have a basis for doing so. I certainly see no
basis for such a conclusion from what I have seen.

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

On Fri, Jan 30, 2004 at 04:49:03PM -0500, Ian Lance Taylor wrote:
> "Edward S. Peschko" <esp5@pge.com> writes:
> 
> > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++.
> > 
> > reference? I see different.
> > 
> > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html
>
> I don't see anything there which says that the C++ ABI is the same.
> But I really have no information on the topic.

It comes under the heading of "Microsoft Visual C++ project 6 support". They don't
specifically mention ABI compatibility, but they mention that you can import 
Microsoft visual C++ projects into Borland, and to link to VC++ dlls through an
import mechanism.

In any case, operationally you've been able to link Microsoft dll's to Borland
apps for years. Eg, the following discussion on google (1998):

http://makeashorterlink.com/?X1B225047

> 
> On the other hand, I've heard several times that Microsoft has
> patented their vtable layout.  That would make it impossible for gcc
> to emulate it, unless Microsoft gave explicit permission.
> 
> Ian

yeah. patents. you just have to look for chinks in their armor.

Right now, I'm looking at the patent 5,481,708, which is a 
'system and methods for optimizing object-oriented compilations', and
I assume is the patent that you are talking about.

http://makeashorterlink.com/?J28511047

The most pertinent claim is #1:

1. In a system for generating code executable by a computer from object-oriented
source listings, said source listings including definition of classes of objects 
having data members and functions operative on said data members, the computer
including a memory stack for creating automatic variables, a method for passing
of objects by value to a function, the method comprising:

    a) identifying by the system a class argument being passed by value as a 
       parameter to a particular function, said class argument comprising an 
       object to be instantiated from a particular class;

    b) creating a surrogate variable for the class argument by allocating 
       space on the memory stack for storing said value; and

    c) determining an address of said surrogate variable on the memory stack when code
       referencing said class argument is generated.

Hmm. My attention is immediatly drawn to the phrase:

'In a system for generating code executable by a computer from object-oriented
source listings'


well, what I'm not talking about a system for genrating code executable by a computer
from object oriented source listings, I'm talking about a system that *reads*
an executable format. No source or compilation involved.

In other words, from what I read it would be verboten for g++ to *produce* a 
format that is compatible with vc++. Which is fine - I really couldn't care less
if g++ produces dlls that vc++ can read - all I care is that g++ can read 
dlls that vc++ produces.

Quite ironic really - by patenting the process they insure that other compiler
vendors can be compatible *with* them, but that other compiler vendors can't 
produce compatible dlls; probably much more of a benefit to them than 
whatever small speed increase this optimisation gives them.

Anyways, that's the way I read it. Any other interpretations or patents?

Ed

Re: open watcom compiling gcc on win32

[tm_gccmail]

On 30 Jan 2004, Ian Lance Taylor wrote:

> "Edward S. Peschko" <esp5@pge.com> writes:
> 
> > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++.
> > 
> > reference? I see different.
> > 
> > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html
> 
> I don't see anything there which says that the C++ ABI is the same.
> But I really have no information on the topic.
> 
> On the other hand, I've heard several times that Microsoft has
> patented their vtable layout.  That would make it impossible for gcc
> to emulate it, unless Microsoft gave explicit permission.
> 
> Ian

For more information, see this message:

http://www.cygwin.com/ml/cygwin/2002-02/msg00290.html

Toshi

Re: open watcom compiling gcc on win32

[Oscar Fuentes]

"Edward S. Peschko" <esp5@pge.com> writes:

> On Fri, Jan 30, 2004 at 04:49:03PM -0500, Ian Lance Taylor wrote:
>> "Edward S. Peschko" <esp5@pge.com> writes:
>> 
>> > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++.
>> > 
>> > reference? I see different.
>> > 
>> > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html
>>
>> I don't see anything there which says that the C++ ABI is the same.
>> But I really have no information on the topic.
>
> It comes under the heading of "Microsoft Visual C++ project 6
> support". They don't specifically mention ABI compatibility, but
> they mention that you can import Microsoft visual C++ projects into
> Borland,

This is about source code projects.

> and to link to VC++ dlls through an import mechanism.

Only C dll's. Not C++. The same as MinGW.

> In any case, operationally you've been able to link Microsoft dll's to Borland
> apps for years. Eg, the following discussion on google (1998):
>
> http://makeashorterlink.com/?X1B225047

That's a C newsgroup.

I was a Borland C++ developer for 10 years. I *know* that Borland
uses a different C++ ABI. You can do a google search, request a
confirmation on the Borland newsgroups or simply try it yourself.

The fact is that gcc is *not* the only Windows compiler incompatible
with the MS C++ ABI.

>> On the other hand, I've heard several times that Microsoft has
>> patented their vtable layout.  That would make it impossible for gcc
>> to emulate it, unless Microsoft gave explicit permission.
>
> yeah. patents. you just have to look for chinks in their armor.
>
> Right now, I'm looking at the patent 5,481,708, which is a 
> 'system and methods for optimizing object-oriented compilations', and
> I assume is the patent that you are talking about.
>
> http://makeashorterlink.com/?J28511047
>
> The most pertinent claim is #1:

[snip]

> Anyways, that's the way I read it. Any other interpretations or patents?

IMHO, it's best to ask about this to a lawyer.

Coming back on-topic (for this ml) the SC has no power for adding your
feature to GCC (not any other feature, BTW). You need to convince a
GCC contributor to do the work (or do it yourself).

-- 
Oscar

Re: 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

Re: open watcom compiling gcc on win32

[Edward S. Peschko]

On Sun, Feb 01, 2004 at 01:58:00PM +0200, Kai Henningsen wrote:
> esp5@pge.com (Edward S. Peschko)  wrote on 30.01.04 in <20040130211615.GA16722@mdssdev05.comp.pge.com>:
> 
> > 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.)

Well, it goes deeper than that - most developers use Visual C++ as their 
front-end, especially for GUI-driven apps. They use VC++-isms in 
their code and VC++ objects because that's what the activestate folks 
have compiled perl with - VC++. Hence, 50 or so win32 modules that 
use c++ 'by default' because the vc++ IDE makes vc++ constructs.

But you are right, the msvcrt.dll vs. cygwin1.dll is an issue that's just as large
(or larger). I've got some ideas on how to link with both.  And then find a way to 
overcome the VC++ ABI compatibility.

Anyways, I've been looking at that patent, and I think that it isn't that big 
a deal. Its fairly narrow, it doesn't cover any of the difficult stuff like RTTI, 
and - best yet - it looks like a patent that primarily pertains to generating
a vtable, not reading it. 

In particular, I don't think it would be infringing on the patent if a utility was 
built to read the vtable format, and to *write out* a vtable format that is compatible
with g++. To make it unproprietary. The first claim is the most important, and I think
that this step: 

    e) overriding the pointer to the virtual function in the virtual function table 
    associated with the designated base class with a pointer to the compiled overriding 
    virtual function. 

is especially vulnerable because any reverse engineering that g++/gcc would do
would be not be performing this step, and if anything performing this step in 
reverse. 

Claims 2-14 are pretty much variations on claim 1; claims 15 - 18 cover runtime 
access of the vtable (which any conversion utility would overstep) and claim #19
goes back to a variation of claim 1 for good measure.

That's the way I see it at least. Perhaps gcc/g++ could follow Borland's footsteps 
with cofftoomf.exe, start a new project and make a translation utility. That way,
the core g++/gcc would be safe, and the new utility would interface with gcc..

Ed

(
ps - oscar, you are right... borland does not link with c++ dlls, at least 
as far as I can see. I still think it would be worthwhile to do so.
)

(
pps - the way I was thinking of doing the cygwin/mingw merge was to prefix
all of the cygwin function calls with 'cygwin_', and to link with both 
msvcrt.dll and cygwin.dll at the same time. How feasible is this?
)

(
ppps - are the cygwin/mingw patches 'fully integrated' into the mainline? Or are 
there outstanding patches?
)

Re: open watcom compiling gcc on win32

[Christopher Faylor]

On Fri, Jan 30, 2004 at 08:29:00AM +0800, Jonathan Wilson wrote:
>>At this point, you've left the realm of gcc and wandered into either
>>the binutils realm, or the cygwin realm.  The mechanisms for producing
>>DLLs are in binutils (specifically, the linker "ld"), and the policy
>>for making cygwin1.dll specifically rests with the cygwin project.
>Actually, I believe that the windows versions of GCC can already produce 
>windows compatible DLLs.

Yes, of course it does.  What other kind of DLL would a windows GCC
produce besides windows compatible DLLs?

cgf