wine-devel March 2005

wine-devel@winehq.org

178 participants
443 discussions

Re: dlls/advapi32/tests/security.c - Bugfix in test!
by Alexandre Julliard 19 Mar '05

19 Mar '05

Jakob Eriksson <jakov(a)vmlinux.org> writes: > --- dlls/advapi32/tests/security.c 14 Mar 2005 17:20:58 -0000 1.12 > +++ dlls/advapi32/tests/security.c 16 Mar 2005 09:32:28 -0000 > @@ -289,8 +289,8 @@ > luid.LowPart = i; > cchName = sizeof(buf); > ret = pLookupPrivilegeNameA(NULL, &luid, buf, &cchName); > - ok( ret && GetLastError() != ERROR_NO_SUCH_PRIVILEGE, > - "LookupPrivilegeNameA(0.%ld) failed: %ld\n", i, GetLastError()); > + if (GetLastError() != ERROR_NO_SUCH_PRIVILEGE) > + ok( ret, "LookupPrivilegeNameA(0.%ld) failed: %ld\n", i, GetLastError()); It doesn't really make sense to check the last error if the function succeeded. -- Alexandre Julliard julliard(a)winehq.org

4 4

Re: Wine FAQ removed from the doc tarballs
by Hiji 19 Mar '05

19 Mar '05

> I always find it annoying when I cannot go to > /usr/share/doc/<package> I suppose the other option is to provide all docs as a seperate package on a release basis (like any other package.) I could be wrong on this, but I don't think the docs are updated on a monthly basis. :) For example, a user could see that the newest Wine package released thus far is from March and the newest Wine docs package could be November of last year (arbitrary date). And if its only 23kb, it shouldn't be much of a problem for modem users; escpecially since it saves them from having to download an extra 23kb with every Wine release when they don't really need it. :) Hiji P.S. Looking at http://www.gimp.org/downloads/ , it looks like they are already doing something similar with their help files. They offer them as a seperate download. __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: RICHED20: remove casts and unused code
by Dimitrie O. Paun 19 Mar '05

19 Mar '05

> +static inline char *RTFStrSave(char *s) Not a big deal, but the name is a bit uncommon. Wouldn't RTFStrDup() be a better/more recognizable name? -- Dimi.

1 0

Re: Wine FAQ removed from the doc tarballs
by Hiji 19 Mar '05

19 Mar '05

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On Fri, Mar 18, 2005 at 02:04:08PM +0100, Francois > Gouget wrote: > > But I don't see any reason not to put it in > wine-doc-html.tar.gz or > > wine-doc-txt.tar.gz. The idea of these tar files > is so that one can get > > all the Wine documentation with just one download > and the FAQ is part of > > the documentation. > > Yes, but I can not possibly see why would anyone > want to download and > read the FAQ like this. A FAQ is essentially a Web > type of document, > best view and browsed on the Web. By including it in > those packages, > we just make them bigger for 99.99% of the users > that don't care > about the FAQ, and those users are probably the ones > that have most > bandwidth restrictions anyway. > > But I'm not totally against it being there, if > people feel strongly > that we must, I'll go with the flow. As a web developer (and Wine user), I feel inclined to believe that all major documentation should be removed from the source. A README file pointing the user to the web site for the latest documentation would be most efficient and beneficial. Basically, by doing this, users will begin realizing that if they want documentation, WineHQ is the place to go. In a sense, it is streamlining information. Not only does this reduce user confusion, but it also minimizes the propagation of old documentation which no one will have the power to update. By not consolidating the documentation resource, there will eventually be a certain percentage of the Wine userbase trying to follow outdated Wine documents. Hiji __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

TlsAlloc limitation in winxp mode
by Michael Ost 19 Mar '05

19 Mar '05

With the emulation mode set to "winxp" I can only TlsAlloc 64 indexes, even though the MSDN docs say there should be at least 20 million. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… Has anyone done any work on this? Any workaround/hackarounds? ... mo

3 3

Re: [WINEOSS] use default prepare functions
by Francois Gouget 18 Mar '05

18 Mar '05

On Thu, 17 Mar 2005, Robert Reif wrote: > Fall back to default header prepare and unprepare functions. > > A driver only needs to support prepare and unprepare functions > when it is doing something special like allocating a DMA buffer for > each header. Since we don't do anything special, just fall back > to the default functions. Removes redundant code. Does that mean we could do the same wor winealsa, winearts, etc? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

3 4

Re: RICHEDIT: RTF reader i18n (now with font charset support)
by Vitaly Lipatov 18 Mar '05

18 Mar '05

В сообщении от 17 Март 2005 13:20 Phil Krylov написал(a): > this patch replaces my precious patch "RICHEDIT: RTF reader i18n" and > needs to be applied after Krzysztof Foltman's "RICHEDIT: RTF reader > improvements and optimizations (TAB craziness fixed)" patch. > > ChangeLog: > > Replaced slow and outdated character set handling in RTF reader by > Unicode/codepages support. Added charset->codepage conversion. Will we do this code in locale independent manner? Why we have ansiCodePage=1252 by default? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Registration of dlls - proposition
by Jacek Caban 18 Mar '05

18 Mar '05

Hi, Currently functions Dll[Un]RegisterServer in Wine look strange to me. It's a great code duplication. As we have ATLRegistrar implementation right now it can be changed. We can use ATL to register dlls. This way functions Dll[Un]RegisterServer can be really simple and registry can be described by elastic and simple rgs scripts. You can see example of rgs script here: http://cvs.winehq.org/cvsweb/wine/dlls/atl/atl.rgs?rev=1.2&content-type=tex… and documentation of ATLRegistrar here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/ht… There are two more aspects of this solution: - dependence on atl I don't think it's a true problem as we can create ATLRegistrar by CoCreateInstance and finally we depend on atl _only_ while registering, so it's not a great dependency... - header file We would need to make atliface.idl accessible for other dlls. Actually it is a public ATL header file, so there is nothing wrong in doing this. We could just move it to include/ (or maybe include/atl where, in future, more headers of ATL could be placed). The benefit is: no code duplication, more elastic and clean registration code. What do you think? Is it a good idea? Thanks, Jacek

2 1

Re: Add some autoconf warnings
by Alexandre Julliard 18 Mar '05

18 Mar '05

Francois Gouget <fgouget(a)free.fr> writes: > I thought I had sent this patch months ago but apparently not. The > idea is to warn the user when some often used libraries are missing > and is based on the warnings issued for bad Mesa or X > configurations. Let me know if the range of checks should be expanded > or reduced or otherwise tweaked. We've discussed this before, I don't think we should warn about these things, it's perfectly harmless in most cases and will just alarm users for no good reason. -- Alexandre Julliard julliard(a)winehq.org

5 5

Re: Wine FAQ removed from the doc tarballs
by wino＠piments.com 18 Mar '05

18 Mar '05

>> A FAQ is essentially a Web type of document, best view and browsed on the Web. This does not ring true. I dont see that any part of the doc "best viewed on the web" unless it's something like a change log or last minute info. Someone with limitted acces time or pay by the minute may well want to grab the whole thing at full speed and read it later off line. Neither do I think that the FAQ represents such a large percentage of the total that it merits speciail treatment. If the doc as a whole is deemed too big split it, I doubt that this is necessary. Regards. -- Opera 7 mail on Linux

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
45
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2005