July 2002 - Wine-Devel - list.winehq.org

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Dmitry Timoshkov

"Francois Gouget" <fgouget(a)free.fr> wrote: > 'H','e','n','c','e',' ','t','h','e',' ','t','e','r','m',' ', > 'k','l','u','d','g','e','.', > ';','-',')' Especially taking into account that it's very unlikely that anybody will write such strings using anything except plain ASCII. UNICODE_STRING fooW; char foo[] = "This is my answer in English. It's not a kluge." "Это мой ответ на русском. Не такой уж и ужасный :-)"; RtlCreateUnicodeStringFromAsciiz(&fooW, foo); CreateFileW(fooW.Buffer, ....); -- Dmitry.

July 17, 2002

Re: autoconf 2.52

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > I have a feeling this isn't the way to do this, but this allows > configure to be regenerated with autoconf 2.52. With this version of > autoconf the PACKAGE_ defines are left commented out in > include/config.h after regenerating and running configure. > > Is there a better way to do this? Upgrade your autoconf? <g> Seriously, the reason we have the generated configure in CVS is so that most people never need to worry about autoconf at all. Conversely, I think it's quite reasonable to ask the few developers that need to change configure to install the latest autoconf, so that we don't have to worry about compatibility. -- Alexandre Julliard julliard(a)winehq.com

July 17, 2002

Re: fix for bug #24

by Michael Stefaniuc

Hello, i forgot the license for this patch. It's a trivial patch so it has the X11 license. bye michael On Mon, Jul 15, 2002 at 09:53:34PM +0200, Michael Stefaniuc wrote: > at least the attached patch fixes the problem described in the summary > of bug #24 (in the description there are some other problems described > too. That's why i CC wine-devel to let one of the bugzilla guru's decide > how to proceed with that bug report). > ImageList_Remove when called to remove all images on an empty ImageList > returns TRUE. Checked with the ControlSpy on Windows 98SE (MSDN wasn't > helpfull in this case). > > Changelog: > - Michael Stefaniuc <mstefani(a)redhat.com> > ImageList_Remove returns TRUE when removing all images of an > empty ImageList -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Francois Gouget

On Tue, 16 Jul 2002, Shachar Shemesh wrote: > > > Francois Gouget wrote: > > >Clumsy but this is the only way. > > > > > >(for Winelib we play tricks with WINE_UNICODE_TEXT but these are not > >perfect and must not be used in Wine. That's why they are in an #ifndef > >__WINE__ anyway) > > > > > didn't you just spot a serious problem with winelib? Oh, no. I've known and dealt with this issue quite some time ago. To summarise the situation: * gcc 2.95: does not support 16bit Unicode at all * gcc 3.x: has a -fshort-wchar option that defines wchar_t as an unsigned short. Unfortunately I am not sure all distributions of gcc 3.x include this option. For Wine: * it should have some degree of portability across compilers. * right now it has to support gcc 2.95 * using the 'array of chars' approach is acceptable since we write the code For Winelib: * requiring that Winelib users modify their application to use 32bit unicode characters is not an option. This is fine for one page applications but not for applications with hundreds of thousands of lines of code. Btw, this would require more work than just modifying the literal string declarations.` * it is reasonable to require gcc/g++ 3.x for porting, especially since it will help a lot for many other C++ features * thus we can strongly recommend the use of -fshort-wchar * if a Winelib user cannot/does not want to use gcc/g++ 3.x, then we still have a fallback mechanism that, while it won't work in 100% cases, will still cover most of the situations. That mechanism uses the _TEXT macro (which all well written Windows applications should use) to convert a 32bit Unicode string to a 16bit Unicode string in place at runtime (which means you have to use -fwritable-strings). See WINE_UNICODE_REWRITE and the block that follows in 'include/winnt.h'. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

July 16, 2002

Re: FindFirstFile/FindNextFile on SMB shares

by Uwe Bonnes

>>>>> "Mike" == Mike McCormack <mikem(a)codeweavers.com> writes: ... Mike> The blocker for #1 is to convince Alexandre that NT really deals Mike> with pathes the way my patch does... which involves writing some Mike> test programs on NT. We need to understand the Mike> NtQueryDirectoryFile function in more detail to do this. Can http://www.codepile.com/tric18.shtml be of some help for that program? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Francois Gouget

On Tue, 16 Jul 2002, Dmitry Timoshkov wrote: [...] > Personally I do not consider using explicit unicode strings such as 'f','o',o',0 > as nasty workarounds. It's a quite acceptable approach. 'S','u','r','e',' ','i','t','\'','s',' ','t','h','e',' ','o','n','l','y',' ','u','s','a','b','l','e',' ','a','p','p','r','o','a','c','h','.', 'B','u','t',' ','I',' ','s','t','i','l','l',' ','t','h','i','n','k',' ', 'w','r','i','t','i','n','g',' ','s','t','r','i','n','g','s',' ', 'l','i','k','e',' ','t','h','i','s',' ','i','s',' ', 'a','w','f','u','l','.', 'H','e','n','c','e',' ','t','h','e',' ','t','e','r','m',' ', 'k','l','u','d','g','e','.', ';','-',')' -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

July 16, 2002

Re: FindFirstFile/FindNextFile on SMB shares

by Mike McCormack

Hi Eric, I agree with you, the FS implementation is a total mess. My thoughts for the FS implementation are this: * Modify the wineserver interface to pass NT pathnames. Wineserver will decide what is a device, a path etc. One possible exception is UNC path names. (preliminary patch already posted to wine-patches) * In the client side, convert dos path names, device names and any other filenames to NT path names. Call NTDLL functions only and let NTDLL talk to the server. Kernel32 should contain few or no server calls. The server should decide whether the file is a device or a normal disk file. eg. CreateFile("COM1:") -> NtCreateFile("\Devices\Serial0") -> server CreateFile("A:) -> NtCreateFile("\Devices\A:") -> server CreateFile("C:\xyz.txt") -> NtCreateFile("\Devices\C:\xyz.txt") * Implement "a real driver model" in the client side for dealing with ReadFile, WriteFile, delete, rename, SetFilePointer, etc. Probably a structure containing function pointers for each operation, which can be registered with the client and refered to from wineserver by an index. * Make directories use real server handles, rather than pointers to client structures. NtCreateFile supports taking a directory handle and a relative path name from that directory to open files. I've tried to keep my SMB implementation seperate from everything else to facilitate this. As you probably know, I've been working on #1 (see my patch from a few weeks ago). Dmitry Tmishkov has also been doing some work to unicodify the entire file API. His work should be available in two weeks or so. The blocker for #1 is to convince Alexandre that NT really deals with pathes the way my patch does... which involves writing some test programs on NT. We need to understand the NtQueryDirectoryFile function in more detail to do this. Mike Eric Pouech wrote: ... > I think the FS implementation gets more and more awful > we need to structure it a bit more (like introducing a real FS driver > model in Wine, and then implement several drivers DOS, SMB...) > comments are welcome > > A+

July 16, 2002

Re: WSAStartup fix

by Rein Klazes

On Tue, 16 Jul 2002 19:30:53 +0200, you wrote: > Rein Klazes a écrit : > > > > Hi, > > > > This fixes a case of stack corruption in "the bat!" email program. > > > > Windows WSAStartup() (tested with win98 and win2K') doesn't fill in or > > use the WSADATA's lpVendorInfo field, and apparently this program has > > cut the field from the structure accordingly > according to MSDN, this should only be done if version >= 2 is requested > IMO, your patch should take care of the version requested before filling > the different fields > A+ The program requests version 1.1; I tested with the same value under real windows. Rein -- Rein Klazes rklazes(a)xs4all.nl

July 16, 2002

Re: FindFirstFile/FindNextFile on SMB shares

by Eric Pouech

Mike McCormack a écrit : > > Hi, > > This is patch allows FindFirstFile/FindNextFile on public windows > shares. It is (artificially) limited to the first 7 files, since some > protocol features that allow transfering larger directories are lacking > in my implementation. I think the FS implementation gets more and more awful we need to structure it a bit more (like introducing a real FS driver model in Wine, and then implement several drivers DOS, SMB...) comments are welcome A+

July 16, 2002

Re: WSAStartup fix

by Eric Pouech

Rein Klazes a écrit : > > Hi, > > This fixes a case of stack corruption in "the bat!" email program. > > Windows WSAStartup() (tested with win98 and win2K') doesn't fill in or > use the WSADATA's lpVendorInfo field, and apparently this program has > cut the field from the structure accordingly according to MSDN, this should only be done if version >= 2 is requested IMO, your patch should take care of the version requested before filling the different fields A+

July 16, 2002