wine-devel

wine-devel@winehq.org

5 participants
84465 discussions

Scrollbar: Overflow
by Phillip Ezolt 18 Feb '02

18 Feb '02

Hi, I've been trying to fix up the code in controls/scrollbar.c to deal with overflow of a 32-bit int, but I've run into a problem. In my test application, InfoPtr->MaxVal= is 0x7FFFFFFF (The largest signed int). InfoPtr->MinVal = 0. However, in various places in the code "infoPtr->MaxVal-infoPtr->MinVal+1" is calculated. This wraps the value around and causes bad things to happen. Does anyone know if the "+1" is necessary? Something has to be done differently, because what is happening now isn't right. --Phil Compaq: High Performance Server Systems Quality & Performance Engineering --------------------------------------------------------------------------- Phillip.Ezolt(a)compaq.com Performance Tools/Analysis

1 0

Re: I've tried to change keyboard table.. No good...
by Björn Róbertsson 18 Feb '02

18 Feb '02

Please give us a solution! I see that the only "solution" for this has been Thomas' Quinots patch for x11lib, which only works for XFree 3.3.1 which is only available in some ancient ... well considering we'd prefer to run RedHat 7.X or SuSE 7.X or Mandrake 8.X running RH 5.0 is somewhat too old... I've done the Xmodmap thing and it does work for me, but I cannot suggest Linux as an alternative desktop solution. Bjorn Robertsson bjornr(a)nyherji.is

1 0

Re:compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

Thanks for answering at first, Eric. I'm using gcc version 2.91.66, the default compiler for Red Hat 6.2, and this is the operative system I'm interested in.

1 0

Re:compiling problem
by Eric Pouech 18 Feb '02

18 Feb '02

> In file included from /usr/comun/src/mc_vis32.cpp:201: > /opt/wine/include/wine/wincon.h:25: parse error before `__attribute__' > /opt/wine/include/wine/wincon.h:229: `PHANDLER_ROUTINE' was not declared > in this > scope which compiler do you use? (name and version and which platform ?) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Clarification on my call for license change
by Jeremy White 18 Feb '02

18 Feb '02

Several people have asked me to clarify my original post. I apologize for not replying sooner; to be honest, I have been hoping that the flames would die down, and I was very reluctant to fan the flames in any way. Further, I'm not sure if I have anything to add other than kindling. But, I don't mean to 'hide', so here goes. First of all, let me say that my call for a change was not based on a single mysterious event. It was triggered by an event that I cannot discuss due to a confidentiality agreement. More important, it is a culmination of a number of events and disturbing trends which I can freely discuss. We've already discussed the concern with the InstallShield related patches of Transgaming; I won't belabor that now. But doesn't it bother anyone else that Marcus spent 5 weeks redoing work that they already had? Wouldn't you rather be able to better play Monkey Island instead? I have always felt that in order for Wine to progress, it was important that changes to Wine be returned to the Wine project. It has always been clear to me that if everyone returns the work, in the long run, everyone benefits. So, with each and every one of my major customers over the past three years, I have had a major, knock down, drag out fight over licensing. I have always insisted that changes we make to Wine be returned to Wine. This has meant (while in a sales situation) explaining the complexities of BSD versus GPL licenses. Wine still requires huge capital investments to make it work, and any company that is going to invest hundreds of thousands of dollars is naturally going to demand ownership of the resulting work product. It it were LGPL, it would be an easy negotiation - I'd just say "Sorry, can't do it." End of story. I know that the naysayers will jump on this and say "Oh, but then you wouldn't have had any customers, they would have been scared away by the LGPL." To this I respond very simply: bullshit. I was there for each of these sales processes, and each customer was primarily interested in the end result, not in the nitty gritty license details. There is an analogy I recall from when I took a physics and public policy class. If a physicist stands up and says "It's a bad idea to build chemical weapons" nobody will listen to the physicist's opinion - they just get a different physicist to do the dirty work. If, instead, she stands up and says "It won't work. The inverse poleron field conclusively prevents that." There is no more debate, and public policy moves on to protecting chickens from acid rain or something else. So, my business is threatened, because CodeWeavers is trying to be the best physicists in town. If I, as a matter of principle, refuse to work on chemical weapons, I lose business because my customers hire different physicists who will build chemical weapons. Okay, let me drop the analogy and come back to straightforward facts. If I believe in the LGPL, and release all of my code to WineHQ under the BSD despite that, then I am a fool. Transgaming, Lindows, name your new competitor, each of them can take the best of my work and use it in their product. I'm sure Transgaming doesn't have any problem using any of the great new Window management code or Window messaging code we wrote. In fact, the InstallShield 6 stuff wouldn't be *possible* without that code. However, if I had it to do over again, I would not have released that code under the BSD license. So, I think there are several fundamental problems: 1. The current license encourages forks. We have the WineX fork; I think that Lindows is still formulating their strategy, but they have publicly stated that they like having some proprietary pieces, this certainly suggests another fork of Wine. You can argue that the pain of maintaining a separate fork is so great, and the work of merging in the BSD code is so hard, that people will just naturally contribute their code back. We do merges of six month drifts on a regular basis; it's just not that painful (the last one took Francois 2 days; the resulting bug fixes probably took 3 or 4 days). If this argument held any water, then Transgaming would have just been forced to contribute the Direct3D and IS6 support back. 2. The current license discourages competitors from releasing their code. Since I believe in the LGPL, but compete with Transgaming and Lindows, contributing my code under the current license is like giving my competitors my very best and getting nothing in return. You know, the concept of making money on Free software is crazy enough without enabling your competitors into the mix. And, much as Gav and I are friends, we do compete. I have been in sales situations with embedded customers where gaming expertise was required. Now, Gav has the best of what I can do, and I have little or none of what Transgaming did. In hindsight, if I had it to do over again, I would have held out all code we had done over the past year or two. Where would Wine and Transgaming be if we had done that? 3. The current license is harmful to the growth of Wine, because it creates a murky, uncertain ground. This is true for a lot of reasons. First, I think we all sort of kind of hope that any corporate Wine citizens will follow some sort of unwritten ethical code of conduct. That is, we'd like the corporate citizens to pitch in and help Wine to grow. Having unwritten rules is foolish, IMO. The current license specifies: go ahead and do anything you want - we don't care. But I think we do care (*I* care). So corporate citizens spend all their time worrying about this middle ground of perception (how much time do you think this debate is taking away from my people, and the Wine hacking they could do?) Well, a Copyleft license provides potential corporate citiziens with written rules. Second, it clarifies the code issues. Right now, say I wanted to work on a game. Well, gosh, just how should I do that? Should I work against the WineX tree? But if I do that, I can't really talk about it on wine-devel, and I can't really share my work with others. Ah heck, maybe Transgaming will fix my game. I'm just going to reboot over to Windows. And if you don't think that's a serious problem, just look at the Wine project historically. Over the past five years, game related patches have overwhelmingly dominated wine-devel. Over the past 12-18 months of Transgaming? Virtually dead. Add to that the new problem of CodeWeavers now being unwilling to contribute their code under the current license. In my opinion, all the developers will just throw up their hands and go work on something else, and I think that would be a great tragedy. I hope that helps. Looking back on this, I see nothing but kindling. If you want to raise a point or an argument that is a variation on something we've heard before, just don't. And if you're not a contributor to Wine, please don't respond at all. You can flame me privately. Or go find a different mailing list. I would really prefer to hear only what Wine contributors think about this. Jeremy p.s. For the record, in my mind, Dan Kegel qualifies as a major contributor to Wine. It is through his hard work that we have a chance that the U.S. court system will put into place systems that will make Wine development easier and protect Wine from predatory action from Microsoft.

17 29

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 17 Feb '02

17 Feb '02

> Patrik Stridvall wrote: > > > But the point I'm trying to make is that I can be in violation of > > > your RELICENSE. I can make a claim that YOUR work is > > > covered by the *GPL, so that your RElicense to me doesn't apply. > > > If this holds, then my original statement that you gave up your > > > copyright protection holds. > > > > I'm not sure I follow you. > > > > Yes, if my work is covered by *GPL, you can ALWAYS use it if you > > follow the conditions in the license. > > yes, even if it contradicts your relicense. If you "work on" > an *GPLed > product, what you do is automatically claimed by *GPL, thus you can't > make any license on your work that is *GPL free. The *GPL only claim parts that are considered a derived work of the *GPL work. So if I write a function A and use that to improve the implementation of a *GPL:Ed function B, the *GPL claims my function A under the *GPL because of the existance of code in B calling my function A and thus the work I distribute as a whole includes my function A as a derived work. However my function A in and of itself is not a derived work of the *GPL:ed work so the *GPL only claims the function A as a part of what I did above. This means that I can relicense the implementation of function A under another license and the *GPL can't claim any indepedent modifications to it since it is not by itself a derived work of the *GPL:ed work. > > Of course, if you later decide that oh well following the *GPL > > is not that bad in comparison after all, it is possible and > > even probably that I can't sue you for breaking the relicense > > as long as you follow the *GPL. > > and if your are relying on your copyright protection to allow you > to benefit on the relicense, you don't have it in this case. > Remember also that the *GPL is pretty much irrelevent so long > as you are > not distributing to the public, so it's not a great cost to choose to > go that route. If you are not distributing to the public you don't need a relicense, the *GPL only forces you to release your work if you distribute to the public. > > The point it that you must show that you follow either *GPL > > or my relicense in order to not be a copyright infringer. > > You don't have to follow both though. > > It's a little different, because I think the burden of proof is > different. Pending on the what you have in your relicense, it's > easy to show that the receiver is covered because they have the > software. On a GPL violation, you have to show that what they are > doing with the software is in violation of the license - which might > be much harder to show. I think we are coming to much of topic by discussing the burden of proof. The point is that if you distribute without the permission of the *GPL or my relicense you are a copyright infringer. Whether in pratice I can detect it or prove it, is irrellevant as far as choosing a license for Wine is concerned.

1 0

Update: Compiling with Winelib and msvcrt
by David Walser 17 Feb '02

17 Feb '02

I modified the winemaker command I issued to: winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -L/usr/lib/wine -lmsvcrt -lkernel32 --single-target ex3 . and now: c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o ex3.spec.o -L/usr/lib/wine -lmsvcrt -lkernel32 -L/usr/lib -lwine -lwine_unicode -lwine_uuid -lm -L/usr/lib/wine ex3.o: In function `main': /home/walser/cosc/450/ex3/ex3.cpp:25: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:43: undefined reference to `GetSystemTime' test -e ex3 || ln -s /usr/bin/wine ex3 so that's progress. I thought GetSystemTime was in kernel32, and doing strings on it shows it is (as well as in several others). What should I be linking in for GetSystemTime? Thanks.

1 0

Compiling with Winelib and msvcrt
by David Walser 17 Feb '02

17 Feb '02

Hi, I'm trying to compile a simple Win32 console app ( http://luigiwalser.homeip.net:8080/~walser/cosc/450/ex3/ex3.cpp if you want to see it). I did: winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -imsvcrt.dll --single-target ex3 ./configure --with-wine-libraries=/usr/lib --with-wine-includes=/usr/include/wine --with-wine-dlls=/usr/lib/wine --with-wine-tools=/usr/bin But make ends like this: gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -I/usr/include/wine -o ex3.spec.o ex3.spec.c c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o ex3.spec.o -L/usr/lib -lwine -lwine_unicode -lwine_uuid -lm ex3.spec.o: In function `__wine_exe_main': /home/walser/cosc/450/ex3/ex3.spec.c:52: undefined reference to `__wine_get_main_args' /home/walser/cosc/450/ex3/ex3.spec.c:53: undefined reference to `ExitProcess' ex3.o: In function `main': /home/walser/cosc/450/ex3/ex3.cpp:25: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:36: undefined reference to `_beginthread' /home/walser/cosc/450/ex3/ex3.cpp:37: undefined reference to `Sleep' /home/walser/cosc/450/ex3/ex3.cpp:43: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:47: undefined reference to `Sleep' /home/walser/cosc/450/ex3/ex3.cpp:49: undefined reference to `Sleep' ex3.o: In function `threadWork(void *)': /home/walser/cosc/450/ex3/ex3.cpp:81: undefined reference to `Sleep' test -e ex3 || ln -s /usr/bin/wine ex3 Note: it is computer science HW but building it with WINE isn't part of the homework, so I'm not asking you to do my HW for me :o) http://facultyfp.salisbury.edu/taanastasio/COSC450/Spr02/Assignments/Exerci… is the assignment. Info about my WINE installation: It's WINE 20011226 compiled from Mandrake SRPMS, the packages I have are: wine libwine1 libwine1-devel wine-utils you can look on rpmfind.net if you want to see what they include. Can anybody please help me get this working? Last note: if this is a mailing list, I'm not subscribed to it. Thanks.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 17 Feb '02

17 Feb '02

> > > if you have to give out an unlimited, royalty free license to your > > > work, I think it's not unfair to say that you have given up your > > > copyright protection. As the copyright holder, it's true that you > > > can relicense it to suit other licenses, but it's not clear to me > > > that you can clearly make a copyright infringment case if there is > > > an LGPLed copy in the public. > > Well if somebody uses my work in a way either not permitted by LGPL > > or explicitly permited by me through some other license I can't see > > why I can't sue. > > But the point I'm trying to make is that I can be in violation of > your RELICENSE. I can make a claim that YOUR work is > covered by the *GPL, so that your RElicense to me doesn't apply. > If this holds, then my original statement that you gave up your > copyright protection holds. I'm not sure I follow you. Yes, if my work is covered by *GPL, you can ALWAYS use it if you follow the conditions in the license. However if you for some reason can't or won't, you can ask me for a relicense. If you don't I can sue you for violating the *GPL. If you do, you have to follow the conditions of the new license otherwise I can sue you. Of course, if you later decide that oh well following the *GPL is not that bad in comparison after all, it is possible and even probably that I can't sue you for breaking the relicense as long as you follow the *GPL. The point it that you must show that you follow either *GPL or my relicense in order to not be a copyright infringer. You don't have to follow both though.

2 1

winsock.h vs. unistd.h
by Francois Gouget 17 Feb '02

17 Feb '02

Here's a patch that takes care of the current winsock.h vs. unistd.h incompatibility. I am only half happy with it as it means that winsock.h will include unistd.h if you have not done so already. This is the only way I see to support both #include <unistd.h> #include <windows.h> and #include <windows.h> #include <unistd.h> If the patch is modified to handle only the first case, then winsock.h does not need to include 'unistd.h'. Index: include/winsock.h =================================================================== RCS file: /home/wine/wine/include/winsock.h,v retrieving revision 1.39 diff -u -r1.39 winsock.h --- include/winsock.h 2002/01/29 02:55:41 1.39 +++ include/winsock.h 2002/02/17 18:53:38 @@ -63,6 +63,26 @@ # define WS_DEFINE_HTONL #endif /* __WINE_USE_MSVCRT */ +#ifndef USE_WS_PREFIX +/* One cannot include both winsock.h and unistd.h because their definition + * of gethostname() conflicts. This is normally not a problem in Winelib + * applications because unistd.h does not exist on Windows and thus Windows + * source code should not use unistd.h. + * But there are still situations where one may want to use both so we are + * taking some specific steps to avoid problems. + */ +# ifdef R_OK +/* unistd.h has already been defined */ +# define gethostname You_should_not_include_unistd_h +# else +# define gethostname unix_gethostname +# include <unistd.h> +# undef gethostname +# define WS_DEFINE_GETHOSTNAME +# endif /* R_OK */ +#else +# define WS_DEFINE_GETHOSTNAME +#endif /* USE_WS_PREFIX */ /* @@ -898,7 +918,9 @@ int WINAPI WS(connect)(SOCKET,const struct WS(sockaddr)*,int); struct WS(hostent)* WINAPI WS(gethostbyaddr)(const char*,int,int); struct WS(hostent)* WINAPI WS(gethostbyname)(const char*); +#ifdef WS_DEFINE_GETHOSTNAME int WINAPI WS(gethostname)(char*,int); +#endif int WINAPI WS(getpeername)(SOCKET,struct WS(sockaddr)*,int*); struct WS(protoent)* WINAPI WS(getprotobyname)(const char*); struct WS(protoent)* WINAPI WS(getprotobynumber)(int); -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel