January 2005 - Wine-Devel - list.winehq.org

[shlwapi/tests/shreg] Tests question

by Paul Vriens

Hi, I've been testing some of these test extensively and can make them pass on all the windows versions I have running. Doing this however means it breaks the wine test. An example is: /* * string grows during expanding * dwSize is larger then the size of part before the backslash but smaller then the expanded string * if the unexpanded string fits into the buffer it can get cut when expanded */ strcpy(buf, sEmptyBuffer); dwSize = sExpLen2 - 4; dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, buf, &dwSize); ok( (0 == strcmp("", buf)) | (0 == strcmp(sEnvvar2, buf)), "Buffer should be the first part of the string (win98) or empty otherwise, it's (%s)\n", buf); Wine returns a part of the expanded string here: (ImARatherLongButIndeedNeededString\sub) So Wine doesn't do what either win98/winnt/win2k/winxp does (all latest version of the OS's). What's the best approach in this? - fix Wine (but what should be the correct returned buffer?) - extend the ok, by the returned buffer that Wine gives and effectively ignore the differences. Cheers, Paul.

Jan. 29, 2005

[AppDB] Beef up the Application Rating Guidelines

by Francois Gouget

I feel that the current 'Maintainers Ratings System Help' is awfully vague and needs to be beefed up. So I'm attaching a proposal in which I tried to keep the original spirit but make things more precise. * First I'd like to rename this page from Maintainers Ratings System Help to Maintainer's Application Rating Guidelines - I added 'Application' to the title because that's what is being rated, not the maintainers. - I removed 'System' because it does not bring anything. - And I changed 'Help' to 'Guidelines' because this page does not juse tries to help maintainers give a random rating to an application, it tries to define which rating an application can have depending on how it runs. - Finally once the old ratnig system is removed we can remove "Maintainer's" since there will be only one left. * I've also reversed the order of the medals, because it seems a more logical progression and can simplify the explanations: in order to get a Silver medal you must pass all the criterias for a Bronze medal, plus some new ones. * I still feel there's a huge gap between 'Garbage' and 'Bronze' and that it would be interesting to have statistics about the percentage of applications that fail to install, and those that install but crash on startup, both cases which are included in the Garbage category along with those that install and start up but are still not usable. (Chocolate and Tin medals?) I'm attaching the full file as it's much easier to read than a diff. I'll send a diff to wine-patches once the final form has been reached. For reference the original can be found there: http://appdb.winehq.org/help/?topic=maintainer_ratings -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Jan. 29, 2005

Re: Intent to package Winetools for Debian

by Francois Gouget

On Sun, 23 Jan 2005, Scott Ritchie wrote: [...] > Also, I'm thinking of putting winetools in the "recommends" section of > the wine package, so it's installed alongside it by default. Any > objections? I would rather put it as a 'Suggests' since Wine can very well be used without winetools. No other nitpick though. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

Jan. 29, 2005

Re: Slick build output

by Marcus Meissner

On Fri, Jan 28, 2005 at 06:03:20PM -0600, Robert Shearman wrote: > Vincent Béron wrote: > > >Le ven 28/01/2005 à 12:22, Robert Shearman a écrit : > >[snip] > > > > > >>write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used > >>write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used > >>write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used > >> > >>It doesn't give the path, so that approach is useless except when > >>building one directory on its own. > >> > >> > > > >It's not like there are 10 write_msft.c files in the Wine source, so > >it's not useless. > > > > I was going to do an example with regsvr.c, but I thought people would > get the point. The developer can use "make -s" if he wants to see less. vis and emacs automatic errorline jump will also stop working. Ciao, Marcus

Jan. 29, 2005

Re: ptrace single-stepping change breaks Wine

by Kari Hurtta

[ Reading just long long thread (actually from gmane.comp.emulators.wine.devel) ] <Pine.LNX.4.58.0412302141320.2280(a)ppc970.osdl.org> Linus Torvalds <torvalds(a)osdl.org>: > + > + /* > + * Was the TF flag set by a debugger? If so, clear it now, > + * so that register information is correct. > + */ > + if (tsk->ptrace & PT_DTRACE) { > + regs->eflags &= ~TF_MASK; > + tsk->ptrace &= ~PT_DTRACE; ========================= > + if (!tsk->ptrace & PT_DTRACE) ======================= > + goto clear_TF; > + } > } Perhaps, I'm stupid. But is there something strange on that test of tsk->ptrace variable? Before that PT_DTRACE was cleared from that same tsk->ptrace variable. / Kari Hurtta

Jan. 29, 2005

Re: [Fwd: Wine-Wiki.org]

by Tony Lambregts

Francois Gouget wrote: > On Thu, 27 Jan 2005 tony_lambregts(a)telusplanet.net wrote: > > > > Wine's release cycle is simply irrelevant to the Application > Maintainer's Guide. > No, it is not important to you. To me its about what is resonable to ask a maintainer to do. At some point in time we will be stable and we will need these guys to ensure that their application works from one release to the next. In anticipation of that time I tried to see what we could do today. I know that your responce is going to go something like this. So I will stop banging my head for now. -- Tony Lambregts Francois Gouget wrote: > > That the problem: a "Stable Wine release" has been six months away since > 1998 and even before. But we still don't have one, have no idea when > there will be one and thus we should not do stuff that will only makes > sense once we will have a stable release and are just confusing and > meaningless until then.

Jan. 29, 2005

Re: unicode "tables"

by Andrew Bartlett

On Fri, 2005-01-28 at 23:47 +0800, Dmitry Timoshkov wrote: > "Mike McCormack" <mike(a)codeweavers.com> wrote: > > > Jonathan Wilson wrote: > > > I remember some people talking about some kind of "unicode tables" that > > > WINE has but that dont match with the MS implementation. > > > What are the tables for? > > > And what API call(s) are involved? > > > > StringCompareA/W and related functions won't do the exactly the same > > thing as Windows, as Wine uses standard Unicode collation tables. > > Actually everything else under libs/unicode has lots of differences > with microsoft's implementation. Just so you know, Samba has and uses the Microsoft tables, extracted (in short) over the network by performing operations that cause the Microsoft servers to use those tables. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net

Jan. 29, 2005

Re: MSVCRT: Re-implement *printf

by Jesse Allen

On Fri, 28 Jan 2005 12:48:12 +0000, Aneurin Price <alp108(a)cs.york.ac.uk> wrote: > Changelog: > > > Re-implement all *printf functions in msvcrt.dll, according to > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… > > > > and descriptions of appropriate functions. > > This should fix, among other things, bugs 321 and 2075. > > > > Nobody has any comments about this? > > Sorry for being late at responding. I took a look at it finally like a week ago. You can definately break up the patch. I'd say make the moving of the functions from file.c into printf.c a seperate patch, the last one really. It's extra noise right now. You could also handle the wide-char printf changes seperate as well as changes to the fprintfish functions. Maybe if you do this, you can migrate printf in steps. wide-char printf and fprintf's already work for what they do, so we can impliment the standard printf first, test it out itself and then moving in the other patches should be dead simple. I'm not sure 100% on this, because... I've never done this before! But since I've been studying this for some time I think I can least make the suggestion =). Jesse

Jan. 29, 2005

Re: [IWineD3d + d3d9] bogus query implemetation

by Oliver Stieber

While we're being picky about silly details, normal > Wine code style is to > have a space between the comment markers and the > comment, ie > > /* foo */ > > not > > /*foo*/ > > thanks -mike > > opps, missed this in v3, I'll send up a incremental with cosmetics in later, and try to make sure everything else conforms a bit better in feature. I've got another few days worth of patches ahead, so I expect there will be a few more mistakes and non standards bits coming up until I get used to breaking patches properly. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Jan. 29, 2005

Re: Slick build output

by Robert Shearman

Vincent Béron wrote: >Le ven 28/01/2005 à 12:22, Robert Shearman a écrit : >[snip] > > >>write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used >>write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used >>write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used >> >>It doesn't give the path, so that approach is useless except when >>building one directory on its own. >> >> > >It's not like there are 10 write_msft.c files in the Wine source, so >it's not useless. > I was going to do an example with regsvr.c, but I thought people would get the point. >Even if find finds multiple instances of a similarly >named file, it's usually pretty easy to find the originating file of a >warning. > > I prefer to leave the gambling at the casino. Rob

Jan. 29, 2005