Dan Kegel wrote:
Patrik Stridvall wrote:
Which is my response to Rogers comment above - sure the GPL
prohibits linking with a nonfree component.
Yes, but what is linking?
Don't you understand it is the vagueness of linking that is the problem.
I don't think it's vague. We can
On 2001.12.18 05:09 Patrik Stridvall wrote:
[snip]
Dimitrie O. Paun wrote:
Stop for a movement and tell me: are you against the letter
or the spirit
of the LGPL.
Asking that question is like asking whether I support the spirit of
Communism:
From each according to his
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
You forget that some independent(*) parts like the Crypto API are
parts of other DLL:s (like ADVAPI32.DLL) for no particular reason.
This is ridiculous: it is one of the few exceptions, it is
simply silly to
bring the Crypto API into this
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
Note that I said _small_ improvements because of the
modular nature of Wine. If the improvements are big, the DLL
separation would allow them to keep those changes proprietary.
I don't think small improvements is a problem anyway and
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
I'm against the fact that the GPL or to a smaller extent LGPL
tries use the doctrine of derived work as a weapon to achieve
their goals. It is a very dangerous weapon, since if the courts
or the policitians decide that a strong doctrine of
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
The problem is the doctrine of derived works. Nothing else.
And to you truly believe that our choice for Wine's license
will have any
influence over the doctrine of derived works?
Of course not. But it _will_ effect our abillity to attract
Roger Fujii wrote:
If they are in separate files, and one calls the other via a function call
that crosses process boundaries (i.e. uses a remote procedure call protocol),
there is no linking, at least not by current standards (and I bet this
will not change).
so, given that linux's
David Elliott wrote:
Dimitrie, this is exactly what Patrick and I have been trying to argue
against. If you read the LGPL it does state that you can statically link
as long as you provide the means for your users to statically link with a
newer version. One way to do this would be to
Dan Kegel wrote:
Roger Fujii wrote:
If they are in separate files, and one calls the other via a function call
that crosses process boundaries (i.e. uses a remote procedure call protocol),
there is no linking, at least not by current standards (and I bet this
will not change).
so,
Roger Fujii wrote:
It *appears* like a process to the user in the ui (ps has separate PIDs).
The problem is that words like process and linking really require some
context around them and it's hard to codify that in a document.
Yes.
Perhaps it would be clearer if I said 'address space'
Now, here's another something to mull over. We've pretty
much established
that you could statically link something proprietary with
something LGPL.
One question I have is how much of the library are you
allowed to use.
Alexandre mentioned that while the CryptoAPI example would be
David Elliott [EMAIL PROTECTED] writes:
Now, here's another something to mull over. We've pretty much
established that you could statically link something proprietary with
something LGPL. One question I have is how much of the library are
you allowed to use. Alexandre mentioned that while
[David Elliott explaination snipped]
Thanks for explaining what Patrik has been going on about.
Yes, it was quite a good explaination.
However...
In summary:
Consider a proprietary application which ships as a
proprietary library
which is statically linked with LGPL libraries at
Patrik Stridvall [EMAIL PROTECTED] writes:
So what you basicly saying is that a Crypto API that is a part of ADVAPI32
can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can.
Isn't that quite an absurd state to make? Or rather the perfect illustration
of the absurdities of LGPL.
Robert == Robert Baruch [EMAIL PROTECTED] writes:
Robert Well, the assembly-coded EXC_CallHandler works (to my surprise),
Robert with a little modification from what I described because after
Robert all, no plan survives contact with the enemy.
Robert However, we're still
Hi, I'm following this list for a while, and even if I still haven't
found time to devote to the project itself, I've seen few things in this
thread that I would like to comment on.
Please note that I will be referring to the 2.1 version of the LGPL.
Il mer, 2001-12-19 alle 07:41, David
I got around the problem of gdb unprotecting the write protected page by
not setting the breakpoint until after the write fault occurs.
When I stepped through the Shrinker exception handler, I got to the point
where it calls ReadProcessMemory with a handle of -1 to get the 8 bytes
around the
Alexandre Julliard wrote:
You known, no matter how much you may disagree with the FSF or their
license, they are not a bunch of idiots. They have been through this
long before you, and have spent a lot of time (and lawyers) to make
sure that it worked as they wanted.
Exactly. They WANTED
Patrik Stridvall [EMAIL PROTECTED] writes:
So what you basicly saying is that a Crypto API that is a
part of ADVAPI32
can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can.
Isn't that quite an absurd state to make? Or rather the
perfect illustration
of the
Patrik Stridvall [EMAIL PROTECTED] writes:
For example:
void CryptFoo()
{
CRYPT32_CryptFoo();
}
and release the code above under the LGPL.
That's the square root example. If you do that, you have to make sure
that the use of CRYPT32_CryptFoo is optional and that the function
still
On Wed, 19 Dec 2001 20:09:25 +0100
Uwe Bonnes [EMAIL PROTECTED] wrote:
You can try to set a hardware breakpoint hbreak or enter the int$3 in
that
page after fixup before protextions are set. But the latter will
probably be
tedious.
hbreak is exactly what I needed!
Thanks!
--Rob
On Wed, 19 Dec 2001 20:56:51 +0100
eric pouech [EMAIL PROTECTED] wrote:
did you try to add in scheduler/process.c for ReadProcessMemory
something
like:
if (handle == (HANDLE)0x)
{
memcpy(buffer, addr, size);
if (bytes_read) *bytes_read = size;
return TRUE;
}
On 2001.12.19 11:43 Dan Kegel wrote:
[BIG SNIP]
Thanks for explaining what Patrik has been going on about.
In summary:
Consider a proprietary application which ships as a proprietary library
which is statically linked with LGPL libraries at install time in a way
that lets users supply new
On 2001.12.19 12:22 Patrik Stridvall wrote:
[SNIP]
That is my argument that avoids all of
Patrick's doctrine
of derived work crap and gets right down to the fact that
it's trivially
easy to make your work fall under the work that uses the
library category,
so long as it is a
Patrik Stridvall [EMAIL PROTECTED] writes:
For example:
void CryptFoo()
{
CRYPT32_CryptFoo();
}
and release the code above under the LGPL.
That's the square root example. If you do that, you have to make sure
that the use of CRYPT32_CryptFoo is optional and that the
On 2001.12.19 12:32 Alexandre Julliard wrote:
David Elliott [EMAIL PROTECTED] writes:
Now, here's another something to mull over. We've pretty much
established that you could statically link something proprietary with
something LGPL. One question I have is how much of the library are
Patrik Stridvall [EMAIL PROTECTED] writes:
So almost all functions would look like
void CryptFoo()
{
#if HAVE_LIBCRYPTO32
CRYPT32_CryptFoo();
#else
/* Old Wine code */
#endif
}
with a few minor exception.
So you mean that I can't legally do that despite the fact that
David Elliott [EMAIL PROTECTED] writes:
Okay, that makes a bit more sense. Although couldn't one argue that
it still does work since it could fall back to the original LGPL
createwindow?
Sure, if this is the case it's OK. You can perfectly provide a
user32_better library that implements a
Mike McCormack [EMAIL PROTECTED] writes:
This is a fix for the problem below. Since all COM port fds are
non-blocking, if we get an error (EAGAIN) return from the initial
read, we should just ignore it and let the wineserver poll on it.
Shouldn't you check for EAGAIN then? It doesn't seem
A while ago I started hacking out an implementation of CryptoAPI. It sat
idle for a while and a few days ago I decided to start doing a bit more
hacking again.
The basics of ADVAPI32's CryptoAPI part is that it does nothing except
provide an interface for applications to call into CSPs
Duane Clark [EMAIL PROTECTED] writes:
The main ugly hack that is performed here is in determining whether a
pixel is a foreground or background pixel. This is done by adding the
red, green and blue values for each pixel, and testing whether they
exceed an arbitrary threshold. This should
Hi Alexandre,
Apologies, i thought explicitly about the error handling issue, and
should have made a note about why i did it that way.
Since the async handler code will handle problematic fds correctly,
rather than duplicating all the checks, i thought it would be easier
to fall thru to the
Mike McCormack [EMAIL PROTECTED] writes:
Since the async handler code will handle problematic fds correctly,
rather than duplicating all the checks, i thought it would be easier
to fall thru to the existing checks in check_async_list and
FILE_ReadAsyncService. Do you think it would be
David Elliott [EMAIL PROTECTED] writes:
What bothers me though is that it does not get Intenret Explorer to
load up the RSA CSP. The LoadLibrary fails because the DllMain
function in the CSP returns FALSE. I speculate this has something to
do with the fact that a real CSP needs to have its
Alexandre Julliard wrote:
Duane Clark [EMAIL PROTECTED] writes:
The main ugly hack that is performed here is in determining whether a
pixel is a foreground or background pixel. This is done by adding the
red, green and blue values for each pixel, and testing whether they
exceed an arbitrary
Duane Clark wrote:
It's reasonable, but you should be doing this locally in the X image
before transferring it to the server; painting the pixmap in the
server pixel by pixel is going to be quite slow. And you may want to
have a look at CURSORICON_IconToCursor, it does something similar.
On Wed, 19 Dec 2001, Dan Kegel wrote:
[...]
I'm running wine over an ssh connection over a cable modem,
which exposes a lot of speed issues. Font setup takes forever,
for instance, and app repaint happens partly reasonably, partly
in slow motion. I encourage developers to test using this
Mike,
None of your recent comms pathces has made the slightest difference to
my app, but this little one breaks it. It dials, the modem connects,
but the app never sees RLSD AKA CD AKA TIOCM_CAR. I reversed
overlapped_good.diff II, because AFAIK that is not in the CVS yet, but
it didn't
On Wed, 19 Dec 2001, Patrik Stridvall wrote:
They had a goal and I'm sure a lot of competent people did the best
they could be accieve it.
However, you can do the impossible no matter how hard you try.
And this is precisely why your entire dissertation about the derived work
doctrine is
There is a problem with 16bpp TrueColor modes: some windows
applications will just check BITSPERPIXEL and if it's 16 they will
assume that we are running with a 2/16/256 color palette.
What are the affected modes:
* 15bpp: rgb555 and bgr555
* 8bpp: VNC's bgr233 mode!
This patch
On 2001.12.19 20:08 Alexandre Julliard wrote:
David Elliott [EMAIL PROTECTED] writes:
What bothers me though is that it does not get Intenret Explorer to
load up the RSA CSP. The LoadLibrary fails because the DllMain
function in the CSP returns FALSE. I speculate this has something to
41 matches
Mail list logo
