- wine-devel - winehq.org

CVS server
by Dimitrie O. Paun 26 Dec '01

26 Dec '01

It looks like we're running an old version of CVS on the server, as it complains it does not understand #cvs up -C is it possible to upgrade it? That would be a good idea irrespective of the -C problem, as the new versions fixed quite a few (nasty) bugs. -- Dimi.

2 1

Re: Wine Tasklist (UNC)
by Mike McCormack 26 Dec '01

26 Dec '01

Hi Francois, I think the best way to handle UNC pathes is to do it properly; Wine should talk SMB/NBT directly to other machines on the network, not through Linux's VFS layer. This approach would give high level of flexability to Wine. We could: * support NetDDE and DCOM with a common code base * use Windows file permissions and security properly * support unicode share names properly * support named pipes, etc across the network * eliminate SMB<->VFS<->SMB problems eg. parsing /etc/fstab There's three options: 1) write our own SMB code (wineserver talks NetBIOS/SMB) i have a short snippet of code to resolve NetBIOS names in CreateFile, but that is only the beginning of the effort. 2) link with a LGPL'ed CIFS implementation. http://www.ubiqx.org/libcifs/ (very incomplete, but maybe possible later, may still have threading issues) 3) get Samba to provide us with a Unix domain socket to talk with. (SambaTNG looks like the best bet there.) i have experimented with linking Wine to samba's libsmbclient and use it to open files. That works (i have a test patch), has threading and licensing issues (it's GPL). This would be alot of work, but i think it's the only way to do it properly. Mike > * UNC path handling > - for drives '\\.\e:', devices > - for network paths > - there's been a patch related to this recently but I believe it does > not cover all cases > - integrate with Samba to handle network UNC paths > - provide a way to mount/unmount drives at runtime, especially > network drives. One should be able to disable this in the config > file (for security reasons). > - Support for 'persistent' mounts... will require modifying the way w > specify which drives are mounted where. > - provide an applet to mount/unmount drives while Wine is running. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: Bulletproof the debugger.
by Michael Stefaniuc 26 Dec '01

26 Dec '01

On Fri, Dec 21, 2001 at 01:52:12PM -0800, Medland, Bill wrote: > Bill Medland (medbi01(a)accpac.com) > Don't ask me why but on my setup vsnprintf returned a value greater than This is the new and correct behavior according to the C99 standard. All snprintf function should return in error case the number of characters that would have been written to the buffer if the size of buffer would have been big enough. This change while usefull will brake a lot of things. IMO the glibc is still using the old behavior. bye michael > the size of the buffer (much bigger), resulting in the debugger tripping > a segment violation. > Considering the location of this code I see no problem with using belts and > braces; it isn't going to be executed much but when it is we want it to work > (despite braindead operating systems) -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 3

Patches for several bugs
by Sander van Leeuwen 26 Dec '01

26 Dec '01

Hi, Here are the bug fixes I promised. There are more, but I can post those at a later time. - controls\button.c CB_Paint, line 806 hBrush = SendMessageW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); if (!hBrush) /* did the app forget to call defwindowproc ? */ hBrush = DefWindowProcW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); -> (Auto)Check, (Auto)Radio & (Auto)3State buttons send WM_CTLCOLORSTATIC instead of WM_CTLCOLORBTN (verified in NT4) (fixes opening dialog buttons in Opera 6 (choose interface)) - dll\user32\text.c TEXT_GrayString, line 499 if(!hdc) { DeleteDC(memdc); return FALSE; } -> DC leak - COMCTL32: Comboex, rebar, tooltips, toolbar: NEVER delete the font object received by WM_SETFONT -> See attached diff files for comboex, rebar & toolbar. Our tooltips has too many differences for diff to produce usable output, but the changes are similar to the other three. - COMCTL32: Tooltips: wrong COMCTL32_Free calls -> 4 calls with wrong pointer: COMCTL32_Free(&lpttsi); should be COMCTL32_Free(lpttsi); - user32: frame tracking * - Only draw changed track frame instead of clearing the old one and * drawing the new one (less flickering) * - Send WM_MOVING when moving a window * - Send WM_SIZING only when sizing a window * - Fixed handling of rectangles changed by WM_SIZING/MOVING -> Can't easily produce diff file. Too many changes. (check src\user32\wintrack.cpp in our CVS tree) - USER32: groupbox redrawing fixes -> I am not 100% sure the same happens in Wine, but it looks like that. When an application changes the font or the text of a groupbox (smaller font or fewer characters), then the old text has to be erase properly or else you'll still see part of it. If I remember correctly, that could be seen in Opera 5.12 (property dialogs) -> Again, too many changes to produce a diff file. (check src\user32\button.cpp, BUTTON_SetText & BUTTON_SetFont) - USER32: static control -> our version supports more styles (SS_CENTERIMAGE, SS_REALSIZEIMAGE) and features (SS_ENHMETAFILE) (src\user32\static.cpp) Sander

1 0

Re: DOS packing patch (fix)
by Lionel Ulmer 25 Dec '01

25 Dec '01

Hi all, I am a bit worried by this patch : I looked at how "pshpack1.h" works, and it uses the '#pragma pack(1)' method when compiling with GCC. > +/* WARNING: one byte packed structs from here !! (i.e. not DWORD aligned) */ > +#include "pshpack1.h" > + And I wonder if this really works as with the latest versions of GCC (2.95.3 onwards AFAIK), '#pragma pack(1)' is ignored (at least on my self-compiled GCC :-) ) and you need to use the '__attribute((__packed__))' construction after each structure. But well, I may say completely stupid things as otherwise a lot of bugs would exist in Wine... Lionel PS: Merry Christmas all :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

16 bit comm issue
by Mike McCormack 24 Dec '01

24 Dec '01

Hi, There's a problem with the current 16bit comm architecture which i'm not sure how to solve correctly. If a 16bit Windows programs uses EnableCommNotification to receive WM_COMMNOTIFY messages then sits in a message loop waiting for them, it will never receive them because there is no chance for APC that sends the message (COMM16_ReadComplete) to run. I have a patch for this problem which puts an alertable wait in GetMessage(16), which i posted in October. What is the problem with this method, and is there a better solution to the problem? Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

DOS stuff pretty much broken [Re: wine/ dlls/kernel/kernel_main.c dlls/kernel/wp ...]
by Andreas Mohr 24 Dec '01

24 Dec '01

On Tue, Dec 04, 2001 at 02:54:50PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1007495689308334133587778 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/12/04 14:54:50 > > Modified files: > dlls/kernel : kernel_main.c wprocs.spec > dlls/ntdll : Makefile.in ntdll.spec > dlls/winedos : Makefile.in dosvm.c int09.c module.c > winedos.spec > graphics : dispdib.c > include : callback.h miscemu.h > miscemu : main.c > msdos : Makefile.in dosmem.c dpmi.c int20.c int21.c > int2f.c interrupts.c ioports.c > Added files: > dlls/winedos : devices.c dosaspi.c dosexe.h int10.c int16.c > int17.c int19.c int20.c int21.c int29.c int31.c > int33.c ioports.c vga.c vga.h xms.c > Removed files: > include : dosexe.h vga.h > msdos : devices.c dosaspi.c int10.c int16.c int17.c > int19.c int29.c int33.c vga.c xms.c > > Log message: > Moved most of the real-mode stuff to dlls/winedos. > > Patch: http://cvs.winehq.com/patch.py?id=1007495689308334133587778 This one probably breaks a whole heap of older Win3.x apps. When I started the Win98 setup.exe for fun, it choked on int 0x21 "list of lists" (DOS_LOLSeg not initialized). Trouble is that we initialize DOS variables in case of DOS programs *only*. This is rather fatal IMHO, especially in the case of List Of Lists, which is a pretty important structure with lots of information that some Win 3.x programs might rely on. Thus DOS stuff should be reorganized somehow. Any suggestions ? IMHO probably winedos should get loaded as soon as DOS3Call() gets called even once. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
by Laurent Pinchart 24 Dec '01

24 Dec '01

When trying to install The Longest Journey (an adventure game), I ran into a problem with modal message boxes. The installer displays at some point a task modal message box, but for some reason the box disapears almost instantly, and I'm stuck with a focused installshield screen on which I can't do anything as the task modal msgbox is invisible and unfocused. I'd like to implement the modal message boxes to fix my problem, but I don't know where to start. Could someone give me a few indication about what would be required to achieve a proper behaviour or modal message boxes ? Thanks. Laurent Pinchart

4 8

Terrible bug: WinExec16, DOS programs
by Andreas Mohr 24 Dec '01

24 Dec '01

Hi all, I just found out that WinExec16 doesn't even support starting DOS programs. Whereas LoadModule16 doesn't seem to support loading DOS programs (error 22, which is not documented for LoadModule16), WinExec16 definitely does launch command.com on Win98SE. Not so when using Wine. What to do about that ? More specifically, which functions to change how exactly to support this ? (the whole interoperation between WinExec, WinExec16, LoadModule*, LoadLibrary*,CreateProcess etc. is highly problematic). This thing makes me get slightly worried about our Win16/DOS compatibility as a whole... :-\ -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Windows screensaver.
by gleb＠nbase.co.il 24 Dec '01

24 Dec '01

Hello all, Perhaps this was asked before, but I didn't find the answer. Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this? Thanks, -- Gleb.

2 2

Re: License debate conclusion
by James Tabor 23 Dec '01

23 Dec '01

Dan Kegel wrote: > > Roger Fujii wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > Wine against companies that want to take it and never contribute code > back. Its protection might not be airtight -- but it would clearly > communicate the spirit. And my impresson was that the majority of > Wine developers agree. > > > - Dan Hum????????? Like the ODIN Project! James

1 0

Re: License debate conclusion
by Dan Kegel 23 Dec '01

23 Dec '01

James wrote: > > Dan Kegel wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > > Wine against companies that want to take it and never contribute code > > back. Its protection might not be airtight -- but it would clearly > > communicate the spirit. And my impresson was that the majority of > > Wine developers agree. > > Like the ODIN Project! Good point. The ODIN project's license is at http://odin.netlabs.org/License.phtml There was some talk of sharing code between Wine and Odin in 1999; see http://www.winehq.com/News/1999-50.html#0 We might want to update http://www.winehq.com/others.html to reflect the current status and license of the Odin project. I'm not quite sure whether the Odin license is compatible with the LGPL. It looks fairly GPL compatible, but I didn't look hard. - Dan

1 0

Re: License debate conclusion
by Roger Fujii 23 Dec '01

23 Dec '01

Alexandre Julliard <julliard(a)winehq.com> wrote: > > My conclusion is that there clearly isn't enough support in the > developers community to justify changing the license. So I'm not going > to proceed with any change, either now or in the foreseeable future. hurrah. before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs. This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license. -r

6 6

[Fwd: Re: License debate conclusion]
by lee 23 Dec '01

23 Dec '01

> I think it's clear that Wine cares, and should be careful not to alienate > companies like Codeweaver and Transgaming. One way to deal with Transgaming > might be to start a campaign to get people to buy Transgaming subscriptions, > or perhaps try to rummage up enough of a one-time payment to get Transgaming > to contribute their current changes back. I suspect that there's some > such arrangement they'd be happy with. I tried to do just that and got rejected ( error after submitting and didn't want to try 'again' until they contact me ) by the online payment system for some odd reason....I wonder how many others have experineced this ( I checked my input twice and had all *'s filled out )........granted it could be isolated in that I made some minor goof on form..-we'll see. just a fyi in case it wasnt' me.. lee -===

1 0

Re: [PATCH] forward tab notification to the parent
by Andreas Mohr 23 Dec '01

23 Dec '01

On Sat, Dec 22, 2001 at 02:31:56PM +0000, Gerard Patel wrote: > The following patch : > ChangeSet ID: 1008622332606314052827656 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/12/17 15:52:12 > > Modified files: > dlls/comctl32 : tab.c > > Pass on all unhandeled messages to the owner. > > leads to bad regressions with some apps. > > The attached patch has the same positive effect on hh.exe > but without the regressions. Confirmed: That patch had horrible effects on desk.cpl. Applying your patch fixed it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

fixme:win32:DeviceIoControl Unimplemented control 256 for VxD
by Matts Kivik 23 Dec '01

23 Dec '01

[root@localhost Visual Pinball]# wine Vpinball.exe +relay +snoop +vxd x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b4be8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b50c4)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device NWLINK wine: Unhandled exception, starting debugger... I get the following errors when trying to run a windows program called Visual Pinball. Wine release 20011108. In addition to the crash, the toolbars are not drawn. Some tools in the toolbars are drawn when I "hoover" over them with the mouse. I another thread I have read that the VNETBIOS call is to check the MAC adress, but what is the NWLINK doing ? _____________________________________________________________ Want a new web-based email account ? ---> http://www.firstlinux.net

1 0

Re: CVS regression.
by Gerard Patel 23 Dec '01

23 Dec '01

At 02:30 PM 22/12/2001 -0800, you wrote: >I'm in the processess of doing a cvs regression to find out what broke >half-life in the main wine. The first problem appears in the "2001-11-8 >EDT" cvs, but it's not the same promlem as I was having with the current >cvs. That one occured between the "2001-11-15 EDT" cvs and the "2001-11-13 >EDT". > >But unless anyone has any ideas I though I'd start working on what patch >did it, and I was wondering if "2001-11-13 EDT" was the cvs at the >begining or end of the day (before or after that days pathces were >applied). And if the dates in the wine.cvs newsgroup are accurate. > >I'm rather new at this so any advice would be welcome. Did you read documentation/cvs-regression ? I updated some weeks ago to add precisely that you can use times up to the second so that it's possible to apply each patch separately. I use http://www.winehq.com/hypermail/wine-cvs/ to find exact patches times. > >P.S. The error i'm looking for is a timeout of a CriticalSelection when >you try to join a mulitplayer game. The one I found in the "2001-11-8 EDT" >cvs is an unhandeled exception when it first goes to the "Loading..." >screen. > Unfortunately, it is not impossible that a first breakage is completed by another a few days after. The more important breakage to find is the first (unless the second breakage is an attempt to fix the first) Another possibility is that the 2 problems are only different manifestations of a single problem; you can have a thread crash nicely, triggering the debugger, or in different circumstances nastily, without much messages. In the latter case, it can happen that another thread is blocked by the crashed thread and displays a critical section wait timeout. It will not be possible for me to help you more until next year, I'll not have internet access until then. Good luck. Gerard

1 0

CVS regression.
by Daniel Sabo 22 Dec '01

22 Dec '01

I'm in the processess of doing a cvs regression to find out what broke half-life in the main wine. The first problem appears in the "2001-11-8 EDT" cvs, but it's not the same promlem as I was having with the current cvs. That one occured between the "2001-11-15 EDT" cvs and the "2001-11-13 EDT". But unless anyone has any ideas I though I'd start working on what patch did it, and I was wondering if "2001-11-13 EDT" was the cvs at the begining or end of the day (before or after that days pathces were applied). And if the dates in the wine.cvs newsgroup are accurate. I'm rather new at this so any advice would be welcome. P.S. The error i'm looking for is a timeout of a CriticalSelection when you try to join a mulitplayer game. The one I found in the "2001-11-8 EDT" cvs is an unhandeled exception when it first goes to the "Loading..." screen.

1 0

For review... CD interfaces in wine
by eric pouech 22 Dec '01

22 Dec '01

not ready yet for cvs inclusion (yet), this patch implements two things: - it replaces the wine internal & proprietary cdrom interface (used in MCICDA and MSCDEX/int2F) with the proper win32 ioctl:s calls - it allows opening any device with CreateFile (using the name "\\.\E:") (this is still very hackish, but not worse than what already existed) patch posted for review/comments/enhancements... (before I go on vacation, in case someone would work on something equivalent) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 22 Dec '01

22 Dec '01

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > [...] > > > > However, just because it doesn't combine to something normal > > > > doesn't mean that is doesn't combine. > > > > > > And how does it combine exactly? Both the book and the > critic are > > > available independently. > > > > > > You can still read the book independently from the critic so > > > they are obviously two separate pieces of work, not a single one. > > > > > > Or how do you define 'combine'? > > > > I do not define combine in any general way. It depend on > what my intent > > is and on the circumstances. I do not expect others to > nessarily define > > combine in the same way either. > > I would say that piece of work 1 combines with piece of > work 2 if it > alters piece of work 1 and results in an entity that a user would > consider to be a single piece of work of the same type. > > Now I believe this is a more restrictive and reasonable > definition of > 'combine' and should match general expectations better than your > 'everything combines with everything if I decide so' definition. What a user would consider a single piece of work depends on the user so it is very vague and unsuitable definition in a court of law. > [...] > > > So you agree that gratis, open-source and commercial > works are all > > > entitled to the same copyright protection. The last two > paragraphs of > > > your email seemed to imply differently to me. > > > > Yes, it is entitled to the _same_ copyright protection. > > Good. We agree on something! :-) > > > > However since you give away your work gratis to the end user by > > your free choice, you have the right to stop doing this(1), > > if anything I sell to the end user bothers you. > > Yes, or as the copyright owner I have another alternative: choose a > license that restricts what you can do with my work. I can even choose > to use multiple licenses and tell you to which one you must abide by > depending on how much money you give me. And no matter how much or how > little you pay me, you must abide by this license, this at least we > agree on, so that's good. > And if I say that you must not redistribute work based on mine then > you must comply. And basically saying 'take his work and then apply my > modifications' still has the same effect: the user magically > gets a copy > of your work which is clearly based on mine. So the end > result is still > that you are redistributing a work based on mine which is > precisely was > forbidden by the license agreement. No, the license is not a contract, and even if it was it can't override the original contract that you implicitly made with society to get any copy protection at all. The license can only be about the rights granted to you by society to your work and while you certainly can deny me, as normal commercial licenses do, that right do redistribute, you can only deny me the right to do derived works to the extent copyright law defines a derived work.

1 0

License debate conclusion
by Alexandre Julliard 21 Dec '01

21 Dec '01

OK folks, I think we are way past the end of the useful part of this discussion, and it's time to come to a conclusion. I'll ask people who want to continue arguing the fine points of the LGPL to please do it by private mail. My conclusion is that there clearly isn't enough support in the developers community to justify changing the license. So I'm not going to proceed with any change, either now or in the foreseeable future. Thanks to everybody who participated to the discussion, and now let's go back to writing code... -- Alexandre Julliard julliard(a)winehq.com

1 0

Latest OSS changes and Pajam Sam, again
by Ori Pessach 21 Dec '01

21 Dec '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, For what it's worth, I've been testing those troublesome games from Humongous with newer versions of Wine. Up until Nov. 9th, they worked fine. Afterwards, they started failing with a difficult to diagnose error message on startup, saying that the sound card was not detected. I tested this with OSS and ALSA sound drivers. The latest version fails after playing a sound on startup. I get two error dialogs - the first says: "The sound card driver is refusing to accept our sample", the second says "The sound card driver will not unprepare our sample header". I'm also still getting "err:wave:OSS_AddRingMessage buffer overflow !? " messages. I have the feeling that these messages should give someone who's familiar with the code a bit more to go on. waveOutUnprepareHeader() seems like a good place to start, and I'll look at it myself when I have the time for it (not soon), unless somebody else figures it out first. Bye, Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE8Ip0kzA/uWWyw6uQRAgeUAJ9K2NvscRvz0ciAvvsWqVF/3M1qBACfe8QA k8KtoVC5TIP2cYhONTWbLlk= =17aJ -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > [...] > > > - a critic's book about the original is not a derived piece > > > of work. It > > > is clearly specific to the original book but does not > modify it and > > > clearly does not combine with it to form a single piece of work. > > > (no real equivalent to this one, closest thing would be an > > > application/script that uses another, like a script that > calls 'ls') > > > > This is not all clear IMHO. What a single piece of work is not > > well defined. Sure a combined work will not be a book since a book > > normally is something that can be read in linear order and combining > > with the critisism will not likely form a normal linear book. > > > > However, just because it doesn't combine to something normal > > doesn't mean that is doesn't combine. > > And how does it combine exactly? Both the book and the critic are > available independently. > > You can still read the book > independently from > the critic so they are obviously two separate pieces of work, not a > single one. > > Or how do you define 'combine'? I do not define combine in any general way. It depend on what my intent is and on the circumstances. I do not expect others to nessarily define combine in the same way either. However, the problem is that you (or rather the law) must define what combine means for your: "Can't legally distribute, is derived work" to have any meaning. > [...] > > > > > > From my point of view open-source is not any different from any > > > commercial work. Obviously there are legal means to obtain > > > the original > > > work in both cases (whether you have to pay for it is irrelevant). > > > Otherwise the point is moot. > > > > > > But saying that open-source is different would mean that > > > because you > > > are not making a direct profit from this work, you are > not entitled to > > > any protection under copyright law. You can't mean that, can you? > > > > But you _have_ protection from copyright, everybody that > _distribute_ your > > work must fullfill the license otherwise you can sue them. > > So you agree that gratis, open-source and commercial works are all > entitled to the same copyright protection. The last two paragraphs of > your email seemed to imply differently to me. Yes, it is entitled to the _same_ copyright protection. However since you give away your work gratis to the end user by your free choice, you have the right to stop doing this(1), if anything I sell to the end user bothers you. (1) Of course you, by your free choice, choose to give the end user the right to redistribute as well so, he can legally give it to his "friends" all other the world, but that is not my problem either. Note that I not saying that your choice was wrong, but you shouldn't complain that rights that you gave up by _free_ choice have been used against you.

2 1

Re: Visual FoxPro 5 apps
by Rick Romero 21 Dec '01

21 Dec '01

I just noticed that my Foxpro 5 post is on WWN, so I thought I'd share the thread from the wine-users list... Rick On 5 Dec 2001 at 13:34, Rick Romero wrote: > On Wed, 2001-12-05 at 13:22, gerard patel wrote: > > On 05 Dec 2001 11:55:10 -0600, Rick Romero <rick(a)valeoinc.com> wrote: > > > > <snip window problems> > > > > >Now I've tried a few different distro's, and quite a few different > > >releases of wine (been compiling from cvs for the last couple months), > > >so I don't think it's just me... BUT. > > > > Try with Wine from 01 june 2001. > > Huge changes have caused several severe regressions > > after this date and they are mostly unfixed. > > Well, I downloaded Wine-20010510, and the MDI windows work PERFECTLY. > They're highlighted blue when active > The scrollbars work > The mouse click is released. > > Although overall, it doesn't work near as well.. > > > > > If your app has the same glitches with Wine as of 01 june > > 2001, its problems are not related to the general regression. > > In this case try to do this, I'll take a look. > > In the other case, it's unnecessary as I'm already aware of > > these problems. > > If I'm not imposing too much, could you point me in the right direction? > > I don't know if I could come up with anything of 'acceptable patch > quality', but I'd like to try. > > Is the problem in mdi.c? > If it was only a simple bug, I'll have it killed since a long time. I'm mostly in the dark, but I think it's more the progressive passage to a whole new design that has caused a string of regressions. Gerard ----- Valeo, Inc. will be closed for the Holiday season starting on December 20, 2001 through January 1, 2002 resuming business on January 2, 2002. We wish you a Happy Holiday Season! -- Rick Romero IT Manager Valeo, Inc. ph 262.695.4841 fax 262.695.4850 rick(a)valeoinc.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > > > There are many thing that are important in the world not just one, > > so it was just a reaction of your persistance that the spirit of > > something is the only thing that matters. > > I focused on the spirit to put some sense in the discussion, > go get to the > point where we agree to disagree, but you don't seem to want that. > > In computers we have interfaces and implementations. It's healthy to > separate the two. Yes, but this doesn't mean that this is always possible. > In our case, the interface is the spirit of > the LGPL, > while the implementation is the LGPL itself. > > If there are 'Gapping Holes' anywhere, they are in your > arguments. You say > you agree with the interface, but you disagree violently with the > implementation. On the other hand, when I ask you for a different > implementation, you can't it can not be done. I say that it can't be done without having a copyright law that will be unacceptable in other ways. > Patrik, you > can not agree > with an unimplementable interface, for crying out loud!!! You > have to make > up your mind and choose! I would very much like to have "Peace on earth", but I don't think it every will be "Peace on earth". You can call that illogical if you wish. It is up to you.

1 0

license discussions
by Marcus Meissner 21 Dec '01

21 Dec '01

Hi, Could we please create a new mailing list wine-license, where all the people who care about licenses can discuss them? Ciao, Marcus

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Does it nessararily follow that you wish to accept any means to > > achieve this? Including, say, to be really extreme: > > "Nuke the middle east, then it will be peace there" > > and after enough nukes it probably WILL be peace, > > so it would be entire in line with peace on earth. Right? > > Patrik, if you think licensing software under the LGPL is > equivalent to > nuking the middle east out of existence, you need to take a _deep_ > breath, drink some cold water, and stay away from those pills. > > Since we're here, this is the type of attitude that really > destroys the > credibility of much of your arguments. It was purposely extreme to illustrate that you can fullfill the spirit of something good with very bad results. There are many thing that are important in the world not just one, so it was just a reaction of your persistance that the spirit of something is the only thing that matters. > I mean, exagerations > of the form: > 'LGPL gives you nothing, it's a pile of crap' despite the > enormous effort > put in it by various lawyers and law professors from reputable > universities, will not buy you many friends. Do you really > think that the > entire law establishment in the US has all gone mad and can't see the > 'Gapping Hole' in the LGPL, and you were the chosen one to see it? I'm sure they all have worked very hard, however as in the extreme example above, all means to achieve something is not nessarily good, if seen as a whole. The meant this time is the doctrine of derived work, which since it is one of the few means they got it was naturely the choice. However, a to strong doctrine of derived work, is not good from other points of views so it will be entirely possibly that the courts will not rule in their favour.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > No, its not irrelevant because it will effect the advise the company > > lawyers give their clients. > > But know you are inconsistent with yourself. You've been > claiming that it > is the very spirit of the LGPL that would scare companies > away, and I can > see some merit to that idea. No, I have been say that the _means_ to implement the spirit of LGPL might scare away companies. > You've also been claiming that > the LGPL may > not be enforceable, thus in mathematical terms, > the expected value of the LGPL < the intended meaning of the LGPL > it follow directly, that the more you are right, the less negative the > advise of the lawyers. Only if lawyers have certain mathematical properties, which they certainly do not have. Actual most functions don't have such properties either. > So, if you 100% right, the LGPL would become BSD, and the > lawyers would > give the same advise, as for the BSD. If you are 100% wrong, > then we do > get the full protection of the LGPL, and we're happy. > Anything in between > is a linear combination of the two. In any case, there really > is no point > about bitching the doctrine of derived work. QED. LGPL can only be BSD if the doctrine of derived work is very weak, so it does have something to do with that. > In fact, choosing the LGPL is a very nice way of hedging our > bets agains > future changes in copyright law. And this is so because of > the negative > feedback loop that the LGPL introduces agains the copyright > law. Brilliant. Now you are contradicting your self. You said earlier IIRC something about that you shouldn't believe that the license Wine chooses effect copyright law.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Sure it is true that what people (read: companies) believe > is true is > > more important than what really is true. > > So, in fact, you indirctly agree that arguing about the doctrine of > derived work as part of this discussion is irrelevant. No, its not irrelevant because it will effect the advise the company lawyers give their clients. You seem to wish to use ignorance (or uncertainty) as weapon to protect Wine, but know this: Ignorance (or uncertainty) cuts both ways. Gav has said that Transgaming or for that matter Corel would have use Wine if it had been LGPL:ed. Perhaps this was because of ignorance, perhaps not. Anyway even if you would be able to convince Gav that he was/is wrong, you must realize that Gav IIRC have researched legallity issues extensively so it is entirely likely that somebody else spending similar resources would come to the same, in your opinion wrong, conclusion. In short: Ignorance (or uncertainty) is a dangerous weapon. > All you seem to be saying is that you think that the _spirit_ > of the LGPL > would be detrimental to Wine since it will drive companies away. > > Right? No. I have been trying to explain just because to are for the spirit of something it is not nessarily so that you support all possible means to acheive something and sometimes any acceptable means to acheive something might not exists. Do you support the spirit of: "Peace on earth!" Does it nessararily follow that you wish to accept any means to achieve this? Including, say, to be really extreme: "Nuke the middle east, then it will be peace there" and after enough nukes it probably WILL be peace, so it would be entire in line with peace on earth. Right?

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > But why should I do that? > > I can for example write a script that download Wine for the > end user user > > and apply the patch automatically. > > The patch would be considered a derivative work, so distributing it > would also violate the LGPL. That again is dependent of the doctrine of derived work have any meaning since the patch is written by me and only contains my work. Just because you build upon somebody else work doesn't mean it is a derivation. Anyway since it denies my right to speech it must be constitional within the context of the first amendment which is IMHO very unlikely that a strong doctrine of derived work is. The copyright clause exception only reserves only gives congress the right to give exclusive rights to _their_ work not to the work of others (read: me). Note by patch I do not nessarily mean a patch like (diff -u) that contains the (LGPL:ed) context of the patch. An "ed-script" or whatever similar will do. Anyway the LGPL:ed context of a (diff -u) patch might very well be consider fair use so that might not be relevant.

4 4

Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 21 Dec '01

21 Dec '01

On 2001.12.20 11:52 Travis Michielsen wrote: [BIG SNIP] > Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) > and > was going to submit a full patch for it at the end of the week. My > patch, > however, has almost a completely different approach to the problem! > Attached is my version (not quite complete or clean). > > These are the main differences and issues I see between our patches: > > 1) I can successfully acquire/release a context (tested with MSDN sample > code). I have not experienced any problems with <loading> a CSP. Umm, yes, I can successfully acquire and release when testing with the MSDN sample as well, but not with RSAENH.DLL that IE wants. > 2) Currently the ms CSPs can perform but all launch pstores.exe - the > protected stores service. This is fine except that it eventually crashes > > with an unhandled exception c0000005 and then becomes unwilling to start > again. Pardon my ignorance, but I didn't realize that that was what pstores did. > 3) Dependancy functions of pstores and M$ providers not implemented: > (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, > mpr:WNetGetCachedPassword, etc.) Yup, if pstores is necessary, we'll need pstores working, so that's something to add to the task list. > 4) I do not create any list of providers. This should not be required as > the > registry is supposed to contain the list of available providers. Once a > handle is acquired then we can gain access to the provider by this > handle. > Note: Key and hash objects need to link to the provider handle, when they > are > created. As for the key and hash: Yes, I am well aware of this, there is a blatant FIXME in the code since I haven't gotten there yet. And I don't know where you get that I am making a list of all CSPs. What I am doing is making a list of any CSPs which are in use and storing the appropriate function pointers in that object. I could simply do a loadlibrary each time the CSP is loaded and store all of that information for every context. But I thought it would be better to do it the way I did so that if multiple contexts are acquired from the same provider we don't have duplicate information in memory. > 5) I have not yet considered thread or process safing/locking. Nor have I > > done any reference counting. Well, I am not so sure about my thread safety but I think theoretically it is okay. I wrote the thread safety in from the beginning. > 6) Seting and getting Key/Hash/Prov Params doesn't consider flags not > used by > the CSP and have meaning in advapi32.dll. Haven't even really gotten that far yet. > 7) I currently do not allow a CSP to drop any of the stardard functions. > > This only affects a few functions, however, as MSDN states these > functions > are *required* for the CSP to have. If they are not implemented they > must > set the last error as ERROR_CALL_NOT_IMPLEMENTED. Well, CSP.DLL from the CSPDK does not provide a couple things. Originally I required every function to be provided but when I found that CSP.DLL did not provide one of them I decided to err the other way and only require the bare essentiallys like Acquire/ReleaseContext. > 8) You seem to make not use > ?????????? > Anyway I think the correct thing to do right now is to co-ordinate our > work > to make a single patch and implementation. > YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel. > I am currently testing this code against windows 98. > Well, I have Win95osr2 running under Win4Lin and I use that as my C: drive in Wine as well. It works a lot better having everything stored on an ext2 drive than on vfat. I have not yet taken a look at your code but will do so as soon as I finish reading the rest of today's wine-devel. -Dave

1 0

Re: timed-out non-overlapped ReadFile
by Mike McCormack 21 Dec '01

21 Dec '01

Hey Lawson, Cool. i just wanted to get apps like yours back to their working state. Ideally i need to add a bit more code for the case (ReadIntervalTimeout = -1) that waits until at least some data is received before returning.... more trouble :-) The timeouts for non overlapped ReadFile should help alot of the recent problems reported on wine-users... hopefully. Mike Original message from: lawson_whitney(a)juno.com .. >Sorry if that sounded like faint praise. The app works as well with >both patches as it did before with neither, and probably there is some >other app that needs non-overlapped ReadFile to time out. > >Thanks! > >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com 21 Dec '01

21 Dec '01

On Fri, 21 Dec 2001, Mike McCormack wrote: > > This patch handles the special case where > ReadIntervalTimeout=MAXDWORD, ReadTotalTimeoutConstant=0 and > ReadTotalTimeoutMultiplier=0 a little better. We should just wait > until we get some data, then read it and return in that case. > > Mike > > ChangeLog: > * handle ReadIntervalTimeout=MAXDWORD special case a bit better > Sorry if that sounded like faint praise. The app works as well with both patches as it did before with neither, and probably there is some other app that needs non-overlapped ReadFile to time out. Thanks! Lawson Slowly but with considerable uncertainty.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> > You forgot that the end user still need to legally get hold of > > the work somehow. For normal commercial stuff this involves > > paying for it and the author will get payed just like he did in > > the old non-digital world for _each_ copy. > > I did not forget that. Good because this is _very_ important. > But I still do not think a book author would > allow you to publish a patch that would modify the last chapter to > provide a different ending. Why, if people like the alternative ending and recomend it to other he might get increase sales because presumeable they want to read the begining. Anyway, we a talking about what is legal and what is not, so that doesn't matter. > The point is that whatever way you use to distribute your > modifications, they are specific to the original work, alter it and > combines with it to provide a single new work. And these are the > criteria I would use to define a 'derived piece of work'. > > And since > derived pieces of work reuse the original work it seems only fair that > they can only do so if they respect the license of the original work. I might sound good from a open source perspective but it nearly isn't as attrative applied to normal commercial works. > Let's take a couple of common sense examples and assume that the > original work is a book. > - a bottle of black ink is not a derived piece of work. Obviously you > can alter the book quite a bit by dropping its content on it > and the ink > will definitely merge with the book. But just as obviously the ink is > not specific to your book. > (computer science equivalent: a file compression utility) First of all since we have a physical object we defintively in addition have the doctrine of first sale so inkstaining your book and reselling it is specifically allowed by law. By selling it the author lost control over that copy. > - a critic's book about the original is not a derived piece > of work. It > is clearly specific to the original book but does not modify it and > clearly does not combine with it to form a single piece of work. > (no real equivalent to this one, closest thing would be an > application/script that uses another, like a script that calls 'ls') This is not all clear IMHO. What a single piece of work is not well defined. Sure a combined work will not be a book since a book normally is something that can be read in linear order and combining with the critisism will not likely form a normal linear book. However, just because it doesn't combine to something normal doesn't mean that is doesn't combine. > - as long as you have the right to sell the original book, you should > have the right to sell it bundled with other books. The reason is that > this does not alter the original book and that it does not form a > combined piece of work. > (linux distributions) Again, you seem to miss that just because thing does not combine in normal ways it doesn't mean that they don't combine. > - but leaflet that replaces the last chapter of the book to provide a > different ending is a derived piece of work. The reason is that it is > specific to the original book, alters the story (the original work of > which the physical book is nothing but a printed > representation) told by > the book, and combines with it to form a new work (a new story with a > different ending). Thus you can only distribute it with permission of > the original author, even if you do not distribute the original book > with your leaflet. > (that's your patch example) Here it combines in a linear readable way. In short: Everything combines with everything else is some way, so unless you define some exact criteria on where the legal border talking about what can combine is rather pointless. The only trend, in your examples, I can see is that you wish to give work that combine in linear readble way more protection, for some, not mentioned, reason. Can you please explain why? > > No particular problem, > > except that some companies might be greedy and want more, > > but hey, do you really wish to give them more? > > I did not express any wishes and in any case they are irrelevant: I > do not have the power to give companies more or less. Now, when I'm > world-dictator for life... :-) :-) > > Open source is more problematic since the end user legally can > > get hold of the work for free and thus any distribution > > restrictions is meaningless since the end user doesn't distribute. > > From my point of view open-source is not any different from any > commercial work. Obviously there are legal means to obtain > the original > work in both cases (whether you have to pay for it is irrelevant). > Otherwise the point is moot. > > But saying that open-source is different would mean that > because you > are not making a direct profit from this work, you are not entitled to > any protection under copyright law. You can't mean that, can you? But you _have_ protection from copyright, everybody that _distribute_ your work must fullfill the license otherwise you can sue them.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> I see exactly what you mean. You mean a binary patch that says > things like: > * delete bytes 2294 to 2297 > * replace bytes 38455 to 39345 with "...." > * insert "...." at offset 41753 Yes. > Such a patch is very specific to a given source version > but does not > include any of the original source. Yes, but that is not a very problematic restriction. > Well, if you can legally use such a patch to work-around the LGPL > license, then you can use it to get past *any* license: GPL, AFPL, MS > shared-source, .... whatever. And this is not only true of > source files, > this is also true of binary files: you can apply such a patch to > executables, libraries, mp3s, mpegs, ... It means what you mean by get past, but OK for the sake of argument: Yes. > This has already been done and the author very quickly got into hot > water. IIRC it was less that two years ago, about a GPL game and an > individual who published a mod as a patch to the game binaries but > refused to publish his source. I'm not sure how it ended. You can > probably research it in your copious amounts of spare time, I think > there was an article on it on Slashdot at the time. I rememember. Of course it was impopular, I do not question that. The question is: Was it it illegal? > But I can assure you that no company in a 'developped' > country would > try such a thing. In the form above perhaps not so likely, but doing a proprietory Crypto API implementation with a patch to make Wine use it, much more likely. > If such a stunt were recognized as legal > then it would > spell the end of copyright of all electronic forms of songs, movies, > books, ... You can be sure that the RIAA, MPAA and all the other > entertainment companies in the world out would never allow such a > thing... and for once I say that they would be right. Please calm down. You forgot that the end user still need to legally get hold of the work somehow. For normal commercial stuff this involves paying for it and the author will get payed just like he did in the old non-digital world for _each_ copy. No particular problem, except that some companies might be greedy and want more, but hey, do you really wish to give them more? Open source is more problematic since the end user legally can get hold of the work for free and thus any distribution restrictions is meaningless since the end user doesn't distribute. But hey, do you really think this so important that you wish to give companies more power than they already have?

2 1

CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 20 Dec '01

20 Dec '01

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 without actually loading the CSPs themselves. At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project. At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything. 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 image verified before it will load. Or maybe it is something different entirely. Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff. As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there? In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded. -Dave

3 4

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> 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 > > the LGPL is meant to allow linking to proprietary licenses. > > The LGPL allows using LGPLed code from proprietary applications. It > does not allow making the LGPLed code dependent on proprietary code > for its own functionality. > > > I think you have misunderstood something seriously. > > Please, this is the absolute worst argument from you > > as of yet. You can't seriously believe this. > > > > Also note that the code that I wrote above was supplied > under the LGPL, > > so I don't see how you can claim that I violated the LGPL. > > Of course you cannot violate the license of your own code, don't be > silly. Exactly. > But if you put this code in an LGPL library written by someone > else and distribute the end result, you have to make a good faith Yes and DISTRIBUTE the end result is the key. But why should I do that? I can for example write a script that download Wine for the end user user and apply the patch automatically. > effort to ensure that the library works properly even in the absence > of your proprietary library. This means you need to implement the > #else case and release that under the LGPL. Go read the square root > example in section 2 of the LGPL. Perhaps, but I need not distribute so it doesn't matter. The point that I have been tried to make all along that only the doctrine of can make my trickery illegal. Without it, it doesn't matter that I use Wine in a, hmm, let call it a non standard way. Anyway I think this discussion, at least the one between you and me, are running around in circles and doesn't move forward at all, so lets just end it. > > Could it be that they rely on that that the dotrine of derived work > > will save them from people trying to use the lopeholes in > the licenses? > > Sure, maybe you understand the law better than all the lawyers who > looked into this issue. I'm not betting on it. It is not primarily understanding that is the issue here. I have said that I believe, and have tried to explain why, that a strong doctrine of derived work is not good for society, because it leads to all sort of absurd consequences. Therefore is believe (or rather hope) that the courts will se sanity and only constitionally allow a very weak doctrine of derived work and thus render viral licenses such as LGPL of most (all?) of its power since it will be quite easy avoid the requirements with a little trickery. Note that this will almost exclusivly effect viral open source license since normal commersial work will get their $100 or whatever regardless since there is no trickery that can legally avoid it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> But, I hear you say, 'why change the license if it doesn't > give you any > protection?' Well, this is where your reasoning is flawed, because the > LGPL gives you quite a bit of protection. And this is because > there is at > least a 50% chance that it is enforceable, and this is > _good_enough_ in > practice. This is trivial to see: the market place is littered with > unenforceable EULAs, yet they seem to do the job. Why? Because big > companies will have not desire whatsoever to test these > licenses in court, > since they have to much too loose (remember, big companies = > have $$$), > while small companies can build on a business plan based on such shaky > grounds, as no one is going to fund such ventures. Add to > this the immense > public pressure, and you have Protection, with a capital P. Sure it is true that what people (read: companies) believe is true is more important than what really is true. The problem is that the example of things you could do that I consider trickery might be considered perfectly normal for some companies, in fact something are not really something strange at all if you applied to the normal world. I adjust the thing I bought a little and then resell it. Then their lawyers tell them that it is unclear if they can do it. Many might not not bother at all and thoose are lost to Wine, some might risk it a later find themselves it a situation that they can neither move forward nor backwards because of "public presure", and because of the amount of money invested they have little choice but to say the LGPL is absurd, we don't not believe we ingfringe on somebodies rights and move forward hoping that somebody doesn't sue them. > And just for shits and giggles, if you think _any_ license > will give you > absolute protection, you are sadly mistaken. And the reason > this can not > happen is rather simple: the laws change. I have said it before and I say it again: I have no illusions that something gives absolute protection.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> David Elliott <dfe(a)tgwbd.org> 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 new CreateWindow, and links to > user32 for the rest. But the modified user32 you ship must work > properly, it cannot be dependent on your proprietary user32_better for So as an alternative trickery: I distrubute everything just like the example above it just happends that user32 is a symbolic link to user32_orginal. This would be alright wouldn't it? So now I just can distribute a script that move the symbolic link user32 from user32_original to user32_better. Problem solved in a way even more convienient for my end user.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> 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. > > No, I think it makes perfect sense. If your code is sufficiently > independent that it can be put in a separate library, then the LGPL > gives you the right to release it under another license. But in order > to do that, you have to demonstrate that the code is really as > independent as you claim it to be; and requiring you to put it in a > separate library is the best way to ensure that. Somehow I guess you would say that. OK, so now are down to independence. So independence is an issue of whether something is on either side of an artifical barrier in this cases the DLL boundary? Note that you your condition: "If your code is sufficiently independent that it can be put in a separate library" can always be fullfilled with a little trickery. For example: void CryptFoo() { CRYPT32_CryptFoo(); } and release the code above under the LGPL. Note that we now return to the doctrine of derived work for nothing except for it can ever make this illegal. > 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. You can certainly find minor > issues and border cases, but the LGPL is not the useless crap you seem > to think it is. 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.

4 3

TrueColor <16bpp modes
by François Gouget 20 Dec '01

20 Dec '01

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 is an ugly hack but it seems to work relatively well. The trick is to lie to the application about the screen depth. If we have a TrueColor mode but a <16bpp screen depth then we return 16bpp anyway. But then the application is going to create 16bpp bitmaps, and CreateBitmap will try to create a 16bpp pixmap... and this is likely to fail. So in CreateBitmap we reestablish the truth and put the right depth in bitmap.bmBitsPixel. Actually some X servers, especially the 4 series seem to support many pixmap bit depth so this may not always be necessary. Anyway, we then rely on the code in dib.c to do the conversions from one format to the other. The last bit in bitblt.c may not be necessary. It seemed useful once but I'm not convinced anymore. Well, if anyone's interested in hacking more on this, have fun (and let me know if you find interesting stuff or have questions :-). -- François Gouget fgouget(a)codeweavers.com Index: graphics/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitmap.c,v retrieving revision 1.34 diff -u -r1.34 bitmap.c --- graphics/x11drv/bitmap.c 2001/09/07 15:28:10 1.34 +++ graphics/x11drv/bitmap.c 2001/12/20 00:31:19 @@ -156,6 +156,14 @@ GDI_ReleaseObj( hbitmap ); return 0; } + /* In case we lied to the application wrt. the screen depth, then it's + * time to patch things up before X complains it does not support this + * color depth. Of course it means we'll have to convert depths from + * DIB to Bmp. + */ + if (bmp->bitmap.bmBitsPixel==16 && screen_depth<16 && (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL)) + bmp->bitmap.bmBitsPixel=screen_depth; + if ((bmp->bitmap.bmBitsPixel != 1) && (bmp->bitmap.bmBitsPixel != screen_depth)) { ERR("Trying to make bitmap with planes=%d, bpp=%d\n", Index: graphics/x11drv/init.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/init.c,v retrieving revision 1.41 diff -u -r1.41 init.c --- graphics/x11drv/init.c 2001/07/29 20:25:15 1.41 +++ graphics/x11drv/init.c 2001/12/20 00:31:22 @@ -190,7 +190,11 @@ case VERTRES: return screen_height; case BITSPIXEL: - return screen_depth; + /* Some applications assume that if the bpp<16 then we are using a + * palette. This is wrong, we could be in 15bpp, or even bgr233 in VNC. + * So we just lie to them. + */ + return (screen_depth<16 && X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? 16 : screen_depth; case PLANES: return 1; case NUMBRUSHES: @@ -202,10 +206,11 @@ case NUMFONTS: return 0; case NUMCOLORS: - /* MSDN: Number of entries in the device's color table, if the device has - * a color depth of no more than 8 bits per pixel.For devices with greater - * color depths, -1 is returned. */ - return (screen_depth > 8) ? -1 : (1 << screen_depth); + /* MSDN: Number of entries in the device's color table, if the + * device has a color depth of no more than 8 bits per pixel. For + * devices with greater color depths, -1 is returned. + */ + return (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? -1 : (1 << screen_depth); case PDEVICESIZE: return sizeof(X11DRV_PDEVICE); case CURVECAPS: Index: graphics/x11drv/bitblt.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitblt.c,v retrieving revision 1.37 diff -u -r1.37 bitblt.c --- graphics/x11drv/bitblt.c 2001/10/03 18:45:41 1.37 +++ graphics/x11drv/bitblt.c 2001/12/20 00:31:19 @@ -626,7 +626,7 @@ pdata += swap ? start+width-1 : start; if (image->depth == depthDst) /* color -> color */ { - if (X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) + if (!(X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) && X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) if (swap) for (i = 0; i < width; i++) *pdata-- = X11DRV_PALETTE_XPixelToPalette[XGetPixel( image, i, row )]; else for (i = 0; i < width; i++)

1 0

timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com 20 Dec '01

20 Dec '01

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 matter. I don't think I have any other stray comms patches, but ICBW. +comm,+file trace attached. Lawson ---oof---

1 0

Re: Add color cursor support
by Alexandre Julliard 20 Dec '01

20 Dec '01

Duane Clark <dclark(a)leewardfpga.com> 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 probably be a reasonably > safe method, since presumably any cursor will have a high level of > contrast between foreground and background colors. 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. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: overlapped ReadFile should ignore EAGAIN
by Mike McCormack 20 Dec '01

20 Dec '01

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 existing checks in check_async_list and FILE_ReadAsyncService. Do you think it would be better to pick up any problems early? Did you look at my async queues patch? Are you waiting for Martin to respond? The async handling code is a bit of a hacked up mess the moment... i haven't applied the fixes to WriteFile that i've applied to ReadFile, and overlapped WaitCommEvent needs to return immediately if events are already available. I don't want to fix those problems twice, so i'm waiting for the big async patch... Mike Original message from: Alexandre Julliard <julliard(a)winehq.com> > >Mike McCormack <mike_mccormack(a)start.com.au> 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 safe to ignore >all errors. > >-- >Alexandre Julliard >julliard(a)winehq.com ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: overlapped ReadFile should ignore EAGAIN
by Alexandre Julliard 20 Dec '01

20 Dec '01

Mike McCormack <mike_mccormack(a)start.com.au> 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 safe to ignore all errors. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > On the contrary, there will be a lot more reasons. The main market is > not in developing Wine; frankly there isn't that much money to be made > on that. The main market is in using Wine to make money on > applications, and the more complete Wine gets the easier this will be. If the applications is are already proprietary I they can affort to pay to get the whole way to 100% functionallity. If they are open source they have an incentitive to work making Wine complete. I don't really see the problem. > But if Wine never gets complete because some parts are held > proprietary by other companies, it won't be possible to enter that > market. So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it. In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented. You can't seriously believe this?

10 19

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> 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 behaves properly if your CRYPT32 function is not available. Forget for a moment I was trying to circumvent the LGPL. Lets say I just found a crypto library called CRYPTO32 under a proprietory license that I wished to use. It so happends that they had almost 100% the same functions as the Crypto API. 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 the LGPL is meant to allow linking to proprietary licenses. I think you have misunderstood something seriously. Please, this is the absolute worst argument from you as of yet. You can't seriously believe this. Also note that the code that I wrote above was supplied under the LGPL, so I don't see how you can claim that I violated the LGPL. The company that wrote the proprietory library neither knew about the me nor about Wine so how can they have violated the LGPL. > > 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. > > Strangely there are thousands of people, including lawyers, who seem > to think that the LGPL does what it claims to do. If the problems are > so obvious, how come no one else sees them? Could it be that maybe, > just maybe, it is because all these people are right and you are > wrong? Could it be that they rely on that that the dotrine of derived work will save them from people trying to use the lopeholes in the licenses?

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> 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 > a pretty > clean-cut allowed case, a proprietary CreateWindow would not > be allowed. > His argument was that because it would necessarily use > internal functions > and data structures that it would be a derived work and thus > subject to > the license. > > I think what Patrick has been trying to get at is that that > is not very > clean-cut and that in fact there is little to no precedent on > what exactly > a derived work is. If Alexandre is indeed correct then we > are pretty well > protected. If it is at the opposite extreme and anyone could > statically > link in proprietary versions of functions then we have very little > protection and it really makes it not worth it to go LGPL. At > least that > is what I think Patrick has been trying to say. Yes, approximately. > Let me put it to you the way I see it. Whether a function or data > structure is exported or not does not matter. It would be trivial to > declare an internal structure or function as exported and thus the > proprietary function is simply making use of the library and > therefore not > a derived work. Indeed... > 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 seperate object file. That is, to put it > in Slashdot > terms, a "Big Gaping Hole(tm)" ..but you are wrong that just because it falls under use, it is clear from the doctrine of derived work. That is the main problem, I have with it. That it might potentially turn somekind of uses into derivation and thus potential infringement of copyright. > Look at section 5 in the LGPL. If you use (from the header > files) only > numerical parameters, data structure layouts and accessors, and small > macro and inline functions then regardless of whether it would be > considered a derived work it remains a work that uses the library. > > So that's great, after I had pretty much convinced myself > that the LGPL > was still good despite some minor problems, I now find myself > realizing > that the LGPL has major holes written into it! Welcome to the club. :-) > And so I emphasize my original statement now. The only thing > the LGPL > really prevents is the direct use of the source code. Anyone > wanting to > release a proprietary implementation of any function can do so fairly > easily simply by 1) writing that particular function from > scratch, and 2) > keeping it in a seperate object file. Agreed. > > > Try reading section 2C of the LGPL and tell me how it's good for > > commercial > > > companies. > > > To respond to Roger: I fail to see how 2c makes any > difference. It only > applies to derived works and only means that you have to release the > code. Yes, it only applies to derived works, but since it is pretty unclear what a derived work is makes it quite unclear for commercial commpanies what that are legal forced to release or not that can't possibly be good when they are deciding whether to use Wine.

2 1

[SHrinker] gdb still doing funny things
by Robert Baruch 19 Dec '01

19 Dec '01

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 EXC_CallHandler's call. ReadProcessMemory fails with an ACCESS_DENIED, and trips a landmine. 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: read_process_memory() = ACCESS_DENIED { data={} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000000 ret=0075f1c3 However, when I run wine alone, without gdb, that particular landmine is not tripped: 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: *attached* 0806d9e8: *signal* signal=19 0806d9e8: read_process_memory() = 0 { data={ff,75,08,ff,d1,64,8b,25} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000001 ret=0075f1c3 BTW, the data returned by ReadProcessMemory is correct, and also will not trip the "Have I been called from Microsoft's NTDLL.DLL method" landmine. I'll have to think about this for a while, how to use gdb without getting ACCESS_DENIED for ReadProcessMemory. That usually means going off and doing something else until an idea hits me. --Rob

2 2

[Shrinker] Modified EXC_CallHandler
by Robert Baruch 19 Dec '01

19 Dec '01

Well, the assembly-coded EXC_CallHandler works (to my surprise), with a little modification from what I described because after all, no plan survives contact with the enemy. However, we're still getting hit by one of the landmines in Shrinker. The awful thing is that I can't debug this easily with gdb. The first exception that's supposed to take place is a write fault to the code area. But if I set a breakpoint in the process's code area, gdb is going to remove the write protection from the code area because, I guess, it needs to put a breakpoint in there (I thought it would use breakpoint registers instead of int $3?) Anyway, I don't want to release the EXC_CallHandler code until I find out which landmine we're hitting, since I can't be certain the rest of EXC_CallHandler works -- the stuff past calling the exception handler. But if you're interested in a morbid "I-love-assembler" way, here it is: static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_FRAME *frame, CONTEXT *context, EXCEPTION_FRAME **dispatcher, PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) { DWORD tmp = 0; __asm__ __volatile__( "push %1\n\t" // ebp-1c = nested_handler "push %2\n\t" // ebp-18 = handler "push %3\n\t" // ebp-14 = dispatcher "push %4\n\t" // ebp-10 = context "push %5\n\t" // ebp-c = frame "push %6\n\t" // ebp-8 = record "push %%ebp\n\t" // ebp-4 "push %%ecx\n\t" // ebp-0 "movl %%esp,%%ebp\n\t" "movl 0x18(%%ebp),%%ecx\n\t" "pushl 0x1c(%%ebp)\n\t" "pushl %%fs:0\n\t" "movl %%esp,%%fs:0\n\t" "pushl 0x14(%%ebp)\n\t" "pushl 0x10(%%ebp)\n\t" "pushl 0x0c(%%ebp)\n\t" "pushl 0x08(%%ebp)\n\t" "call *%%ecx\n\t" "movl %%fs:0,%%esp\n\t" "popl %%fs:0\n\t" "movl %%ebp,%%esp\n\t" "popl %%ecx\n\t" "popl %%ebp\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "movl %%eax,%0\n\t" : "=&g" (tmp) : "g" (nested_handler), "g" (handler), "g" (dispatcher), "g" (context), "g" (frame), "g" (record) : "memory" ); return tmp; } --Rob

2 2

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