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