[xplc-general] win32 question

[Bernd Unger]

Hi!

I tried to use xplc in a simple Win32 application using precompiled headers.

On compilation i get an error message that some operators clash with existing definitions for guid's:

..\include\xplc\uuid.h(103) : error C2556: 'bool operator ==(const UUID &,const UUID &)': Überladene Funktion unterscheidet sich nur hinsichtlich des Rückgabetyps von 'int operator ==(const GUID &,const GUID &)'
C:\VS2003NET\Vc7\PlatformSDK\Include\Guiddef.h(192): Siehe Deklaration von 'operator`==''
..\include\xplc\uuid.h(103) : error C2371: 'operator`=='': Neudefinition; unterschiedliche Basistypen
C:\VS2003NET\Vc7\PlatformSDK\Include\Guiddef.h(192): Siehe Deklaration von 'operator`==''

Does anybody suggest a way to come around this?

- bernd

[Pierre Phaneuf]

Post by Bernd Unger
I tried to use xplc in a simple Win32 application using precompiled headers.
..\include\xplc\uuid.h(103) : error C2556: 'bool operator ==(const UUID &,const UUID &)': Überladene Funktion unterscheidet sich nur hinsichtlich des Rückgabetyps von 'int operator ==(const GUID &,const GUID &)'
C:\VS2003NET\Vc7\PlatformSDK\Include\Guiddef.h(192): Siehe Deklaration von 'operator`==''
..\include\xplc\uuid.h(103) : error C2371: 'operator`=='': Neudefinition; unterschiedliche Basistypen
C:\VS2003NET\Vc7\PlatformSDK\Include\Guiddef.h(192): Siehe Deklaration von 'operator`==''
Does anybody suggest a way to come around this?

The Win32 port of XPLC was suffering from a classic case of bit rot, it
seems. Stéphane Lajoie sent me a patch, which we cleaned up and checked
into CVS. Win32 should be fine in CVS, and will be part of the next release.

[Bernd Unger]

The current cvs version compiles and works under win32 without a problem.

Thanks!

-----Ursprüngliche Nachricht-----
Von: xplc-general-***@lists.sourceforge.net [mailto:xplc-general-***@lists.sourceforge.net] Im Auftrag von Pierre Phaneuf
Gesendet: Mittwoch, 17. März 2004 22:58
An: xplc-***@lists.sourceforge.net
Betreff: Re: [xplc-general] win32 question

Post by Bernd Unger
I tried to use xplc in a simple Win32 application using precompiled headers.
..\include\xplc\uuid.h(103) : error C2556: 'bool operator ==(const UUID &,const UUID &)': Überladene Funktion unterscheidet sich nur hinsichtlich des Rückgabetyps von 'int operator ==(const GUID &,const GUID &)'
C:\VS2003NET\Vc7\PlatformSDK\Include\Guiddef.h(192): Siehe Deklaration von 'operator`==''
..\include\xplc\uuid.h(103) : error C2371: 'operator`=='': Neudefinition; unterschiedliche Basistypen
C:\VS2003NET\Vc7\PlatformSDK\Include\Guiddef.h(192): Siehe Deklaration von 'operator`==''
Does anybody suggest a way to come around this?

The Win32 port of XPLC was suffering from a classic case of bit rot, it seems. Stéphane Lajoie sent me a patch, which we cleaned up and checked into CVS. Win32 should be fine in CVS, and will be part of the next release.

--
Pierre Phaneuf
http://advogato.org/person/pphaneuf/
"I am denial, guilt and fear -- and I control you"



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

[Pierre Phaneuf]

Have you seen the following page?
http://xplc.sourceforge.net/doc/others.php

Yes i have seen. There are very few things that work on Win32 and
Unix and are in a state where you can use or even try them.

XPCOM is one that works on Win32 (being used by Mozilla) and should
work. But it is also part of the reason I created XPLC (it was called
XPCOM-lite before the first release, I used to work on XPCOM), so... I
hear that UNO, SCF and GObject might be good choices that work on Win32,
but I did not work much with them, and only on Linux.

Compatiblity with COM is not the main issue. It can be a scenario
where i load my modules/plugings internally thru xplc and have a COM
interface to the whole thing around it. The plugins itself have not
to be COM compatible cause they are relative tight coupled and make
no sense in another environment i guess.

You seem to have a good grip around this, I see! Sounds good to me...

The key is binary compatibility. If you get something going with
the current version of XPLC, you could just bundle the DLL with
your application and just make the specification be to use this
version of XPLC. You could modify the magic numbers in the module
loader to have your own magic number, so that it will only load
modules designed for your application. You'd be incompatible with
any "normal" XPLC module, but you'd have perfect safety from any
crazy move on our parts (and most likely, modules for your
application would be pretty specific anyway).

Ok - thats the technical part - and is it allowed thru the license to
use a pure binary version of xplc in a commercial application?

By the way, we use a very common license, the Lesser General Public
License (often called LGPL, see
http://www.fsf.org/licenses/licenses.html#LGPL), so if you see
information about the LGPL, this is the same license we use.

In summary, you have to make available any changes that you make to XPLC
itself. Linking with other libraries or your program is allowed (WITHOUT
requiring you to make your source code available!), but you have to
allow for end-users to be able to replace the XPLC version you provide
with their own updated or modified version.

In short, if you do not modify XPLC and simply include an XPLC.DLL with
your application, you can just specify in the documentation which
version you used (so that users can download the correct one, make
changes and recompile the DLL), and everything will be fine.

I you *do* modify XPLC, you can then provide only those modifications,
either as a ZIP file of your modified version of XPLC or as a patch, you
do not have to provide any of your application source code.

Statically linking XPLC would be more problematic, as you would need to
provide a way for users to relink your application with their modified
version of XPLC. Using a DLL is very easy and legally safe.

I would ask you to put such an XPLC.DLL in the directory of your
application rather than in a global directory, so as to avoid people
thinking that this is the "real" XPLC that they should use. You could
rename the DLL, like XPLC_FOO.DLL or something, to make it clear that
this is specific to your "Foo" application.

I am trying to make it as easy as possible even for commercial closed
source applications to use XPLC, while at the same time defending it
against incompatible modifications (having the modifications available
makes it possible for me to review them or to at least blanket myself
and say "they do not use the standard XPLC, it might not work perfectly").

It also allows progress on XPLC to advance further, by polling all these
resources. I think it is only fair that instead of paying royalties on
the library, you pay with your potential improvements, right?

Stéphane and me just fixed this all five minutes ago! You can have
a look at CVS right now and tell us about it on the mailing list!

Ok - works great! I will write in the mailing list next... Thank you!

Excellent! Do not hesitate to report any further problems, even should
you decide to abandon XPLC! We are very eager to hear any constructive
criticism, and sometimes even the non-constructive ones!

We've been pretty open about stealing good ideas from others up to
now, I don't see why we'd stop! ;-)

Hope you are sharing ideas and not stealing them, otherwise they get
lost ;-)))

Hehe! :-)

[Stephane Lajoie]

Just make it BSDish already :).

The GPL and LGPL are designed to further a cause first and foremost,
and I think it is a mistake to allow that to prevent XPLC from
achieving its goals.

The way I see it, code falls into three categories:

First, building blocks. The technologies that want to be super
universal simply *have* to be completely free. If zlib was GPL, it
wouldn't be anywhere near as popular as it is now; if gcc didn't
specify that the binary code it produces didn't fall under the GPL, it
would be just as widely used as the Hurd (i.e., not at all). The Boost
library guidelines for contributors say "Leave your GPL code [and
advocacy] at the door". I think XPLC ought to be in this category.

Then there's a lot of LGPL and GPL software that make a good
foundation to build systems on. These are big enough that preventing
evil people from co-opting them completely makes sense: Linux, MySQL,
Gnome, etc. But they may not have gotten as good as they are without
the bit of arm-twisting that the GPL provides so they strike a good
balance.

Finally, the rest of software remains closed-source. That code can
only use the GPL and LGPL stuff by sitting on top of it, without
linking to it (in practice, closed-source software almost never links
to LGPL stuff because it's too much hassle). However, they tend to use
BSDish code quite a bit and contribute a lot to its popularity (if not
by improving it, at least by using it). If XPLC existed at the time
Microsoft decided they needed COM, it could be everywhere now
(including every Linux distribution).

This is not intended to be stupid irrational uncompromising advocacy
so please don't turn this into a second Slashdot. All I'm saying is
that XPLC may only be able to achieve world domination by being truly
free. Please consider this.

P.S: By the way, "No! It stays LGPL!" is a perfectly valid response to
make, and I won't argue further. My advocating for your users' freedom
is not meant to limit yours :).

P.P.S: Wouldn't xplc.apache.org be cool? :)

[Avery Pennarun]

Post by Stephane Lajoie
The GPL and LGPL are designed to further a cause first and foremost,
and I think it is a mistake to allow that to prevent XPLC from
achieving its goals.

There are numerous examples (eg. sendmail and BSD Unix) of BSD-licensed
projects forking, splitting, and turning into terrible mutually-incompatible
monstrosities (usually after a company makes their own proprietary
"improvements" and doesn't give them back). There are, as far as I know, no
LGPL examples of this problem - GPL/LGPL stuff just forks less often and
less dangerously. In the end, there's little advantage to anyone if your
project is widely used but incompatible, particularly if your project, XPLC,
is all about increasing compatibility between things.

I do agree that GPLed (as opposed to LGPLed) libraries are a pretty stupid
idea.

Have fun,

Avery

[Stephane Lajoie]

Post by Avery Pennarun
There are numerous examples (eg. sendmail and BSD Unix) of BSD-licensed
projects forking, splitting, and turning into terrible mutually-incompatible
monstrosities (usually after a company makes their own proprietary
"improvements" and doesn't give them back).

I agree those two examples would have benefited from the GPL. However,
they are not building blocks that aim for universal reach, like XPLC.
It's one thing to be *the* mail transfer agent or *the* Unix kernel,
but being *the* component system is on a different level. I contend
that competing at this level requires a more liberal license than the
LGPL.

Besides, there are also numerous examples of BSDish stuff not forking.
Even things with high commercial value like Apache and Postgresql
don't get forked much.

Post by Avery Pennarun
There are, as far as I know, no
LGPL examples of this problem - GPL/LGPL stuff just forks less often and
less dangerously. In the end, there's little advantage to anyone if your
project is widely used but incompatible, particularly if your project, XPLC,
is all about increasing compatibility between things.

I don't think its possible for XPLC to ever be widely used *and* have
many incompatible versions at the same time. The one force that can
make such a building block project widely used is the same one that
prevents incompatibility: the network effect.

Besides, there isn't many people who "get" components anyway. The only
people who would ever decide to use a component system by themselves
will likely value binary compatibility (the only one that counts)
enough to not break it stupidly.

But whenever somebody who "gets" it happen to be working on a closed
project and gets turned off by the LGPL, it becomes that much more
unlikely for XPLC to make it big...

[Avery Pennarun]

Post by Stephane Lajoie
I don't think its possible for XPLC to ever be widely used *and* have
many incompatible versions at the same time. The one force that can
make such a building block project widely used is the same one that
prevents incompatibility: the network effect.
Besides, there isn't many people who "get" components anyway. The only
people who would ever decide to use a component system by themselves
will likely value binary compatibility (the only one that counts)
enough to not break it stupidly.

Unix is just a big component system, really. BSD Unix forked (and
continues to do so) badly, resulting in exactly the problem you describe:
it's widely used *and* incompatible. Linux is actually GPLed, but since
Linux apps are technically not "linked" with the kernel, we don't suffer.

Perhaps XPLC needs to have a similar license - GPL, but with no linking-with
restrictions. This is actually weaker than the LGPL, and less hassle.
Check out the glibc license for an example.

Have fun,

Avery

[Stephane Lajoie]

Post by Avery Pennarun
Unix is just a big component system, really. BSD Unix forked (and
it's widely used *and* incompatible. Linux is actually GPLed, but since
Linux apps are technically not "linked" with the kernel, we don't suffer.

I don't think any one BSD was ever popular enough to have significant
network effects: it was pretty fractured from the get go. I understand
this was made possible by its license but maybe that wasn't the root
cause; I'd blame the free-for-all land-grab of greedy commercial
companies instead...

There's also a difference in scale. If a company wanted to write its
own Unix 20 years ago it would've had to spend quite a bit of money;
if BSD Unix had been GPL, they would've been forced to cooperate.
However, XPLC is small and easy to rewrite (no offense intended :)).
So people who can't live with the LGPL can make their own component
system anyway (but it would be incompatible!). Making XPLC more free
would make it that much more likely to have those people on board and
get the necessary network effect.

Post by Avery Pennarun
Perhaps XPLC needs to have a similar license - GPL, but with no linking-with
restrictions. This is actually weaker than the LGPL, and less hassle.
Check out the glibc license for an example.

I like this idea a lot. If there's no annoying linking restrictions,
the only remaining freedom that we don't grant is to make secret
proprietary changes to XPLC itself. Of course, we don't care for that
anyway since they would likely be incompatible with the real XPLC,
undermining the whole thing.

[Pierre Phaneuf]

Post by Avery Pennarun
Perhaps XPLC needs to have a similar license - GPL, but with no
linking-with restrictions. This is actually weaker than the LGPL,
and less hassle. Check out the glibc license for an example.

What would you think of this: keep the LGPL, but allow statically
linking if you have no modification at all to XPLC itself.

So downloading xplc-0.3.2.tar.gz, unpacking it, compiling it and linking
it statically with your closed source binary would be allowed without
any further fussing around on your part.

If you want to make changes, link dynamically, as per the normal LGPL.

[Avery Pennarun]

Post by Pierre Phaneuf
So downloading xplc-0.3.2.tar.gz, unpacking it, compiling it and linking
it statically with your closed source binary would be allowed without
any further fussing around on your part.
If you want to make changes, link dynamically, as per the normal LGPL.

Now you sound like djb :)

Have fun,

Avery

[Pierre Phaneuf]

Post by Avery Pennarun

Post by Pierre Phaneuf
So downloading xplc-0.3.2.tar.gz, unpacking it, compiling it and
linking it statically with your closed source binary would be
allowed without any further fussing around on your part.

Now you sound like djb :)

Argh! I finally went crazy!!!

[Pierre Phaneuf]

Post by Stephane Lajoie
Finally, the rest of software remains closed-source. That code can
only use the GPL and LGPL stuff by sitting on top of it, without
linking to it (in practice, closed-source software almost never links
to LGPL stuff because it's too much hassle). However, they tend to
use BSDish code quite a bit and contribute a lot to its popularity
(if not by improving it, at least by using it).

The problem I have with BSD is that while nobody makes incompatible
changes to zlib when they use it and Boost is always all statically
linked, effectively, XPLC is all about having a strong binary-level
compatibility at various levels. If a company statically links XPLC in
their application and adds a helper component without giving it back, if
people start using this component they will now be creating components
that will only work with that version.

Or they could change a component in an incompatible way. Even if they
use the XPLC way of avoiding random crashes and they change the IID, a
basic object might just stop supporting an interface, and this isn't
XPLC anymore. Who's going to get the blame for "my XPLC component
doesn't work with this XPLC application" then?

Post by Stephane Lajoie
If XPLC existed at the time Microsoft decided they needed COM, it
could be everywhere now (including every Linux distribution).

Please! Even *I* will admit that I'm not that much of a genius! ;-)

Post by Stephane Lajoie
This is not intended to be stupid irrational uncompromising advocacy
so please don't turn this into a second Slashdot. All I'm saying is
that XPLC may only be able to achieve world domination by being truly
free. Please consider this.

If ABI compatibility wasn't such a big deal with XPLC, I might have went
BSD from the start, exactly because of all the reasons you gave. I have
to admit agreeing a bit with Avery on the "GPL/LGPL reduces the risk of
forking", but if I wanted total world domination, I might not have cared
too much about forking.

Sure, sendmail was horrible, but it *is* everywhere!

Post by Stephane Lajoie
P.S: By the way, "No! It stays LGPL!" is a perfectly valid response
to make, and I won't argue further. My advocating for your users'
freedom is not meant to limit yours :).

I'm mostly trying to limit my "screwedness". :-)

Post by Stephane Lajoie
P.P.S: Wouldn't xplc.apache.org be cool? :)

No! I'm trying so hard not to get pigeonholed! Then, it'd be "that
Apache thingy" and people would use that as an excuse not to use it in
their desktop-oriented software.

I thought of going along with freedesktop.org for a while, because
they're the organization trying to regroup all these different
technologies from different projects and make everyone have a common
base, but the "desktop" part stopped me: some of the things I want to do
most with XPLC are server-side things, I don't want XPLC to be a
"desktop thing" either!

In his recent article, Havoc mentions the same political/strategic
problem, but he has what I feel is the best solution, if you're able to
pull it off: get people from a number of various projects like KDE,
Apache, GNOME, OpenOffice and what-not together to build their XPLC-like
thing, so that they're affiliated with all these projects and gain from
their visibility, but don't get pigeonholed at the same time.

But while that might be easy to say for Havoc, it's not quite as easy
for me. :-(

[Avery Pennarun]

Post by Pierre Phaneuf
The problem I have with BSD is that while nobody makes incompatible
changes to zlib when they use it and Boost is always all statically
linked, effectively, XPLC is all about having a strong binary-level
compatibility at various levels. If a company statically links XPLC in
their application and adds a helper component without giving it back, if
people start using this component they will now be creating components
that will only work with that version.

Well, in fact you can't stop people from doing that; each XPLC
object/interface/component, even inside XPLC, is so independent that someone
could just strip out the one they don't want from your LGPLed library and
implement their own version of that component.

Now that I think of it, "linking" is fuzzy enough, but linking via XPLC
components begins to get just ridiculous. How do you know, reading the
LGPL, exactly what's linked with your application and what isn't? What is
"XPLC itself?"

The trouble with small, well-defined interfaces is that they weaken the LGPL
to the point of near-uselessness, I think.

Post by Pierre Phaneuf

Post by Stephane Lajoie
P.P.S: Wouldn't xplc.apache.org be cool? :)

No! I'm trying so hard not to get pigeonholed! Then, it'd be "that
Apache thingy" and people would use that as an excuse not to use it in
their desktop-oriented software.

But then you could be associated with other exciting apache subprojects,
like XML parsers and Java thingies!

Post by Pierre Phaneuf
In his recent article, Havoc mentions the same political/strategic
problem, but he has what I feel is the best solution, if you're able to
pull it off: get people from a number of various projects like KDE,
Apache, GNOME, OpenOffice and what-not together to build their XPLC-like
thing, so that they're affiliated with all these projects and gain from
their visibility, but don't get pigeonholed at the same time.
But while that might be easy to say for Havoc, it's not quite as easy
for me. :-(

You do need to be strategic if you want XPLC to be everywhere - and I have
to admit, the smartest way to get started will be to get at least one of
those projects to adopt your thing. Or, alternatively, to make a wrapper
for *their* thing so that they're compatible with your thing whether they
like it or not.

Have fun,

Avery

[Pierre Phaneuf]

Post by Avery Pennarun

Post by Pierre Phaneuf
No! I'm trying so hard not to get pigeonholed! Then, it'd be "that
Apache thingy" and people would use that as an excuse not to use
it in their desktop-oriented software.

But then you could be associated with other exciting apache
subprojects, like XML parsers and Java thingies!

I'm so excited. Oh. Ah.

Post by Avery Pennarun

Post by Pierre Phaneuf
In his recent article, Havoc mentions the same political/strategic
problem, but he has what I feel is the best solution, if you're
able to pull it off: get people from a number of various projects
like KDE, Apache, GNOME, OpenOffice and what-not together to build
their XPLC-like thing, so that they're affiliated with all these
projects and gain from their visibility, but don't get pigeonholed
at the same time.
But while that might be easy to say for Havoc, it's not quite as
easy for me. :-(

You do need to be strategic if you want XPLC to be everywhere - and I
have to admit, the smartest way to get started will be to get at
least one of those projects to adopt your thing. Or, alternatively,
to make a wrapper for *their* thing so that they're compatible with
your thing whether they like it or not.

Yeah, that was part of the plan. I was going to try to sneak into most
distros using WvDial as a Trojan Horse, then slip patches to add XPLC
support to various projects, telling them "hey, everyone has XPLC
anyway!" and writing wrapper for their things so that they're
XPLC-enabled whether they like it or not.

Then we're rich.