wine-devel April 2003

wine-devel@winehq.org

121 participants
314 discussions

Wintab32 dll devlopment
by Robert North 23 Apr '03

23 Apr '03

I have just posted a status update on my wintab32 development to the following wine bug. http://bugs.winehq.com/show_bug.cgi?id=1160 And following on from that update there are a number of questions I need answered to guide my further development: 1. Cross over office and tablets. I heard somewhere that Crossover office had a tablet implementation. Does anyone know about this, and who to contact to find out more? If they've got an implementation of wintab, I wonder if it's worth continuing the development. 2. When to post patches I could start producing patches quite soon. For instance, I could post patches when the WTInfo function is working. Or, I could wait till the whole system is working fully with at least one app? 3. Size of the patches. Is it better to break patches into small (valid compile, but non-functioning) chunks, or to release large functioning patches? 4. Config files Wintab will need some config data. I assume the best place to put this is in the ~/.wine/config file, within a registry key named "wintab"? 5. Development notes. I have some notes on the design that other developers will probably find useful. Where in the wine project should they go? There seems to be no place for rough notes. 6. x11drv integration. Currently the code is implemented to connect to X11 in a similar way to directX. No additional code is placed in the x11drv dll. This X11 connection should be discarded. To this end I have a number of functions that I'd like to place in x11drv dll. The question is: Should I put them into x11drv before releasing any patches, or maintain the directX style connection in the initial wine patches? 7. Cross-platform abilities Is there any need to think about allowing alternatives to XInput to plug into the wintab dll? Yeah, I know that's a lot of questions, But I hope you guys can give me some guidance. Bye -Rob.

4 4

Re: Winelib CoolPlayer port
by Dimitrie O. Paun 23 Apr '03

23 Apr '03

On April 22, 2003 04:17 pm, Vincent Béron wrote: > Next is the actual Winelib stuff, which is very small. Just a few lines indeed! > The first part is an MFC header (thankfully, nothing else seems to be > needed from MFC). This is the: --- CoolPlayerCVS-20030421-2130-orig/afxres.h 1969-12-31 19:00:00.000000000 -0500 +++ CoolPlayerCVS-20030421-2130/afxres.h 2003-04-21 21:51:07.000000000 -0400 @@ -0,0 +1 @@ +#include "winres.h" right? > The second part is the only problematic thing. The current div > implementation works fine for binary compatibility on i386, but doesn't > work well for source level compatibility on the same platform. I would prefer if we fix this one in Wine, so we don't have to submit this part for inclusion in the CoolPlayer code. This would be _our_ benefit for the port, no? :) -- Dimi.

1 0

Re: Fix trackbar size
by Dimitrie O. Paun 23 Apr '03

23 Apr '03

On April 22, 2003 05:55 pm, Maxime Bellengé wrote: > + * Copyright 2003 Maxime Belleng�<maxime.bellenge(a)laposte.net> > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -231,13 +232,13 @@ > channel->top = lpRect.top + offsetedge; > channel->bottom = lpRect.bottom - offsetedge; > channel->left = lpRect.left + offsetthumb; > - if (dwStyle & (TBS_BOTH | TBS_LEFT)) channel->left += 8; > + if (dwStyle & (TBS_BOTH | TBS_LEFT)) channel->left += > (lpRect.right-lpRect.left-offsetthumb-cyChannel)/2; Unfortunately, the patch seems to be wrapped, and your name did not show up properly in the copyright notice. -- Dimi.

1 0

Re: Fix Maskedit from Delphi - part 2 - Resend as attach to fix formatting
by Alexandre Julliard 23 Apr '03

23 Apr '03

Brad Campbell <brad(a)seme.com.au> writes: > EM_REPLACESTR was not respecting buffer_limit set > by EM_SETLIMITTEXT. Shouldn't the EDIT_MakeFit() call a few lines above already take care of that? Why doesn't it work? -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> On Tue, 22 Apr 2003, Patrik Stridvall wrote: > > > EULAs tries to restrict, yes. However a copyright license > does as well, > > if it, like most copyleft licenses, tries to take back the rights > > you have already given up by allowing redistribution of the work > > in the first place. > > This is the source of the confusion. I don't take back anything, as > I don't allow limitless redistribution. Since you allow everybody that wants the work to legally get it for free, that is just meaningless game withs words. Even if not everybody can (re)distribute it, enough can to make it for all intent and purpose a meaningless distiction. See below. > I allow redistribution only > under certain condition. It's conditional: > A => B > You seem to think that one can not use conditionals. This is obviously > false. "You can do B IF condition A holds" is a very reasonable > statement. It's basic logic, no cake and no eating involved. [You don't really expect me to have missed something as trivial as that, do you?] The problem is that you with the LGPL only have conditionals on who can (re)distribute the work, but no conditional on whom it can be (re)distributed to. While, I suppose, you can have a license the regulates this to, even if the LGPL doesn't, the problem is the doctrine of first sale means anybody that it can be distributed to can resell (or give) that copy to anybody that can't be distributed directly to. Futhermore I would argue that first sale doctrine, for all intent and purpose, means that you as the copyright holder, can't regulate who ultimately a copy of your work, ends up with. So any such clause would be null and void, so no trickery would be needed. Note that copyright is designed that way on purpose, not as a freak accident. So now we are back to: 1. You can give your work away for free 2. You can sell your work for a fee But you can't control whom ultimately recieves and uses your work. So again: "You can't both have the cake and eat it"

3 2

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> On Tue, 22 Apr 2003, Patrik Stridvall wrote: > > > Very, very simplified. You have basicly have two choices: > > 1. Distribute your work (or part of it) for free > > 2. Distribute your work (or part of it) for a fee. > > Says who? Says close to every business who uses copyright. Open sourse is not that large yet, you know. > Why would you think price is *the* fundamental feature? Because in the end there is really nothing else. If the work is useful to some extent, somebody will profit from directly or indirectly. Hopefully the author will as well... Futhermore, since if we are to have things like first sale, which we have, you really can't avoid that somebody converts each copy you have allowed the distribution of, to money. (Except by releasing more copies which will at least in theory drive the price to zero.) So unless you convert each copy you allow to distribute to money somebody else will. Note however this is not nessarily negative for you. Indirectly you might get more back that would have gotten through direct sale. > Copyright law gives you rights (by restricting other's rights) > so that you could use them, if you so desire, to get some money > for your work. Copyleft just says you give up some of your rights, > EULA restricts. Which is fine, but within limits -- it's much > harder (legally) to take from people than to give. EULAs tries to restrict, yes. However a copyright license does as well, if it, like most copyleft licenses, tries to take back the rights you have already given up by allowing redistribution of the work in the first place. That is what I mean by "trying to both have the cake and eat it". You have voluntary "eaten the cake" by allowing redistribution of the work and now you want it back... > As I said, why would we want to give the manufacturer of a TV set > the right to tell me what programs I'm allowed to watch on my TV? > Or what brand of gas to put in my car. Or what brand of detergent > in my washing machine? Agreed. However, your argument supports my position concerning LGPL, more than yours. > Having generally accepted interfaces (steering wheel, pedals, and > stick for a car, gas of certain octane, etc) is good because it > allows for multiple implementations == competition. But this works > as long as you can't restrict what *implementations* you're allowed > to use. Exactly, but again, it support my position more than yours. > I don't know my histroy right, but I believe this sort of > restrictions (among other things) allowed Rockefeller to build his > Standard Oil monopolistic empire, and is now illegal. IIRC the Standard Oil problem, was more a refusal to do business at all unless you cooperated more than anything else. Not really revelevent to this discussing. In the case above you have already done business by allowing redistribution ("eaten the cake") and later through legal wrangling wants to "have it" back.

2 1

Re: rpc exception
by Robert Shearman 22 Apr '03

22 Apr '03

> I see that Greg's exception stuff is not in Wine yet. Until that's > accepted, this'll have to do. [snip] This is just an idea, but would something like this work (obviously without Intel syntax): #define RpcExcept(expr) \ VOID * FuncPtr = GETEIP; \ if (__wine_in_exception_filter()) \ { \ int retval; \ switch( expr ) \ { \ case -1: \ retval = -1; \ break; \ case 0: \ retval = 0; \ break; \ case 1: \ retval = 1; \ break; \ } \ __asm \ { \ mov eax,retval \ ret 4 \ }; \ } \ __EXCEPT((__WINE_FILTER)FuncPtr) Rob

1 0

another wine apps database
by Dan Kegel 22 Apr '03

22 Apr '03

Anyone seen this one yet? http://thetechnozone.com/pcbuyersguide/software/system/TheWineList.html It seems good enough that perhaps there should be a link to it from http://www.winehq.com/?page=supported_applications We might want to nudge the author into disclosing the version number of the Wine he was using, so non-Knoppix users can compare versions. - Dan p.s. Here's its lead-in text: "The WINE List By Graeme Bennett Posted Aug. 6, 2002; updated Mar. 26, 2003 Introduction Wine (which, its authors say, stands for 'Wine is not an emulator') is a Windows-compatible application launching environment for Linux and several other non-Microsoft other operating systems in which users can run many programs designed for Windows. Since not every Windows program runs correctly under Wine, and many of the programs I tested successfully were not listed on the other Wine compatibility lists I found, I've put together this list of programs that work (or at least seem to work -- I didn't test every function of every program!) more or less as they do under Windows. For these tests, I used the Wine version built into Knoppix versions 3.1 and 3.2. Knoppix is a free Debian-based Linux distribution that requires no installation on or changes to your hard drive. It boots and runs its filesystem directly from a CD. Additionally, it write-protects your Windows hard drive(s) by default, making it an exceptionally safe way to test Wine and/or Linux. Zero Config Wine All programs tested were previously installed and no special setup, configuration or manual file copying under Wine was used. In other words, any program listed below works "as is." ..." -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> > > And the question is: is this enforceable? > > > > And the answer is: if it isn't, neither is the (L)GPL. Why > would MS not > > be able to place restrictions on distribution of their own > copyrighted code? > > > > Not in the case of Microsoft. This should fall under the > sherman Anti-Trust Act. Probably true, but I would hate to use that argument in court, unless as the very last line of defence. > If I buy a copy > of MS Visual Studio and I have to redistribute files to > Windows 9x, NT, 2K, XP, Etc then I should > be able to also redistribute the same files to Linux or ReactOS. Also note that if you for example put it on a web site, you are not really redistributing to a special OS, in fact you are not really even redistributing to a special person or company, you are just redistributing it period....

1 0

Re: NTPL & pthreads locks
by Dan Kegel 22 Apr '03

22 Apr '03

Alexandre Julliard wrote: > I don't think we can implement Win32 primitives on top of pthreads, at > least not in a reasonable way. We may be able to do it on top of the > raw kernel futexes, but that's not exactly libc integration (and it > will most likely require new kernel features too). And the only reason > for doing that would be performance, it's certainly not going to make > things more intuitive or more solid. Somebody begs to differ. From http://downloads.transgaming.com/files/winex-3_0_releasenotes.txt : * The core threading model has moved to pthreads to decouple WineX from the continuing changes to certain core system libraries. If Gav can do it, why can't we? :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

4 5

← Newer
1
...
5
6
7
8
9
10
11
...
32
Older →

Jump to page:

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 April 2003