November 2003 - Wine-Devel - list.winehq.org

Re: Dropped wildcards patch

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > Are you sure you want the functions to only return the invalid > argument error if the file is actually not found? It creates > inconsistancies. An invalid argument is invalid whether the file is > there or not. It's not invalid on Unix, that's the whole point. If we make them illegal right away it means you won't be able to access legally named Unix files. While checking for existence first will make no difference in 99% of the cases, it will do the right thing when a file with a wildcard exists in the file system, and I think that's worth a little inconsistency. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003

Re: shlwapi: optimise path functions

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, I'm not sure this is worth doing. First off, we're not fixing any > app that makes use of CharNext{A,W}(). Second, why is your static method > any faster than the real CharNextA()? Third, it's not correct to replace > CharNextW() with an array increment. While it is true that currently our > CharNextW() simply does the same thing, it should be fixed in the long > run to properly deal with Unicode Surrogate Pairs: While that's true in general, for the path functions it doesn't really matter since surrogates will never be path separators, so getting rid of CharNextW in that case is OK. CharNextA is another story however... -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003

Re: Dropped wildcards patch

by Shachar Shemesh

Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > > > >>Just wondering whether there was a reason that the patch at >>http://www.winehq.org/hypermail/wine-patches/2003/11/0339.html was not >>commited. My understanding of the ensuing debate was that it was >>acceptable. >> >> > >No, I'm afraid it's not. As I explained, you need to check that the >file exists first. Also, DOSFS_GetFullName is called all over the >place, so we need to go through all of them to make sure the behavior >is correct; for instance your patch will break FindFirstFile since we >have to allow wildcards there. > > > Ok, that wasn't clear. I'll have a look. Are you sure you want the functions to only return the invalid argument error if the file is actually not found? It creates inconsistancies. An invalid argument is invalid whether the file is there or not. Maybe there are other ways to deal with the FindFirst/Next? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...

Nov. 30, 2003

Nice work - OpenOffice 1.1 under WINE

by Steven Edwards

Hello, I have just compleated a full install of OO 1.1 under WINE. No outsite packages are required to install and configure OpenOffice for Win32 under Wine. There are a few minor bugs with some of the strings in menus but I would rate it at 99%. If anyone is interested in a good hobby project a Winelib port of this would be nice to see. With a little luck we may be able to have this running for WineConf under ReactOS. Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

Nov. 30, 2003

Re: [Curses] Choose curses so library at startup (4/5)

by Alexandre Julliard

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > - Try ncursesw, ncurses and curses so library before giving up at startup You can't do that, there's no guarantee that the different libraries are binary compatible. We need to load the one we built against. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003

Re: Splitting out shared Win16/Win32 code

by Dimitrie O. Paun

On November 29, 2003 03:59 pm, Casper Hornstrup wrote: > 2) Duplicate the shared code in a Win32 specific file and Win16 > specific file. I haven't looked if the code can be duplicated, but by the size of the function (it's not big), I'd say duplicating is the way to go (added bonus if by doing so we can simplify a bit each of them). -- Dimi.

Nov. 30, 2003

Re: shlwapi: optimise path functions

by Dimitrie O. Paun

On November 29, 2003 06:27 pm, Andrew de Quincey wrote: > I've replaced the calls to CharNextA()/CharNextW() with array increments > and a local static function. This knocks 3.5 seconds off the file open > dialogue in IDA. Well, I'm not sure this is worth doing. First off, we're not fixing any app that makes use of CharNext{A,W}(). Second, why is your static method any faster than the real CharNextA()? Third, it's not correct to replace CharNextW() with an array increment. While it is true that currently our CharNextW() simply does the same thing, it should be fixed in the long run to properly deal with Unicode Surrogate Pairs: http://uk.geocities.com/BabelStone1357/Unicode/surrogates.html In other words, I don't think the patch is acceptable. What I'd suggest: -- figure out why the real CharNextA() is slow, and try to fix that -- figure out why it takes so long to call CharNextW() -- Dimi.

Nov. 30, 2003

Re: Splitting out shared Win16/Win32 code

by Alexandre Julliard

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > It submitted a patch for this problem a while back in comdlg32 and it > went to the silent void that is Alexandres patch rejection que.... > http://www.winehq.org/hypermail/wine-patches/2003/10/0265.html Can't say that I remember that patch, I must have dropped it. Could you please resumit? >> How should it be handled? Wherever possible, by having the 16-bit code call the 32-bit code. Where this is really not possible, by duplicating the necessary code, but that should be the last resort. There is no #ifdef we can use for that purpose, and we shouldn't add one. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003

Re: Dropped wildcards patch

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > Just wondering whether there was a reason that the patch at > http://www.winehq.org/hypermail/wine-patches/2003/11/0339.html was not > commited. My understanding of the ensuing debate was that it was > acceptable. No, I'm afraid it's not. As I explained, you need to check that the file exists first. Also, DOSFS_GetFullName is called all over the place, so we need to go through all of them to make sure the behavior is correct; for instance your patch will break FindFirstFile since we have to allow wildcards there. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003

Re: version resource for regsvr32

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > It's too late since Alxandre has committed the patch, but > it's worth to mention that it's better to use a common > pattern for creating version resources for Wine DLLSs, > which uses wine/wine_common_ver.rc. Currently wine_common_ver.rc sets the file type to dll, so it's not really appropriate for programs. We'll probably need to add another define for that. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003