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

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

by David Laight

> > If VC does have a "one correct way", while gcc doesn't, shouldn't we > prefer the VC correct one? No - you should the one that is in the C standard. In this case '0' should be ok under ALL circumstances. (Unless M$ have completely stuffed their compiler) David -- David Laight: david(a)l8s.co.uk

July 15, 2002

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

by Uwe Bonnes

>>>>> "Shachar" == Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: Shachar> Not trying to be a hard head here, and I'm not even remotely Shachar> trying to suggest that this particular line of code is a Shachar> crucial point. It's just that my understanding of this project Shachar> and the way code should be with it, all WINE DLLs are actually Shachar> WineLib code. All WineLib code should duel compile on Windows Shachar> and Unix. In theory, there should not be a problem compiling Shachar> our sources of USER.DLL on Visual C, and running it on Windows Shachar> instead of the native DLL (far fetched example, I know). Shachar> If VC does have a "one correct way", while gcc doesn't, Shachar> shouldn't we prefer the VC correct one? With VC++ you either compile an ASCII or an Unicode version. In this case you know whether to treat a char or string as ascii or unicode. In Wine you have both ASCII and Unicode in one executable/library. Here you have to be explicit what you mean. 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 15, 2002

fix for bug #24

by Michael Stefaniuc

Hello, 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 bye michael -- 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 15, 2002

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

by Francois Gouget

On Mon, 15 Jul 2002, Shachar Shemesh wrote: [...] >+ LPWSTR lpText = (LPWSTR)lParam; >+ lpText[0] = '\0'; [...] >+ lpText[0] = L'\0'; [...] >+ lpText[0] = 0; [...] > Not trying to be a hard head here, and I'm not even remotely trying to > suggest that this particular line of code is a crucial point. It's just > that my understanding of this project and the way code should be with > it, all WINE DLLs are actually WineLib code. All WineLib code should > duel compile on Windows and Unix. In theory, there should not be a > problem compiling our sources of USER.DLL on Visual C, and running it on > Windows instead of the native DLL (far fetched example, I know). > > If VC does have a "one correct way", while gcc doesn't, shouldn't we > prefer the VC correct one? That's a good point. All three ways would work in Visual C++ but as you pointed out, L'\0' would be the most correct one. So it would make sense to prefer it when assigning to WCHARs (too bad we cannot do the same for strings as this would not work in gcc). -- 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. `

July 15, 2002

Re: About VirtualQueryEx hack

by Eric Pouech

> > I have a hack for VirtualQueryEx for Linux, but Alexandre will never > > accept it (but if someone needs it, I can provide it) > > May you post it to me ? cc'ing wine-devel if others are interested of course, it'll only work on linux (but it wouldn't be too hard to make it work on other OSes) (you need to run tools/make_request after applying the patch and before re-configuring and re-compiling) A+ Name: vqex ChangeLog: added implementation for VirtualQueryEx (linux only) License: X11 GenDate: 2002/07/15 18:59:12 UTC ModifiedFiles: memory/virtual.c server/Makefile.in server/protocol.def AddedFiles: server/virtual.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/memory/virtual.c,v retrieving revision 1.80 diff -u -u -r1.80 virtual.c --- memory/virtual.c 3 Jul 2002 21:10:44 -0000 1.80 +++ memory/virtual.c 10 Jul 2002 21:46:31 -0000 @@ -1243,15 +1243,42 @@ * Number of bytes returned in information buffer */ DWORD WINAPI VirtualQueryEx( - HANDLE handle, /* [in] Handle of process */ - LPCVOID addr, /* [in] Address of region */ - LPMEMORY_BASIC_INFORMATION info, /* [out] Address of info buffer */ - DWORD len /* [in] Size of buffer */ ) + HANDLE handle, /* [in] Handle of process */ + LPCVOID addr, /* [in] Address of region */ + LPMEMORY_BASIC_INFORMATION pinfo, /* [out] Address of info buffer */ + DWORD len /* [in] Size of buffer */ ) { + int res; + MEMORY_BASIC_INFORMATION info; + if (MapProcessHandle( handle ) == GetCurrentProcessId()) - return VirtualQuery( addr, info, len ); - ERR("Unsupported on other process\n"); - return 0; + return VirtualQuery( addr, pinfo, len ); + + if (addr >= (void*)0xc0000000) return 0; + + SERVER_START_REQ( query_virtual_memory_info ) + { + req->handle = handle; + req->addr = ROUND_ADDR( addr, page_mask ); + + res = wine_server_call_err( req ); + if (!res) + { + info.State = reply->state; + info.Protect = VIRTUAL_Win32Flags[reply->protect]; + info.AllocationProtect = VIRTUAL_Win32Flags[reply->protect_other]; + info.Type = reply->type; + info.BaseAddress = reply->base_address; + info.AllocationBase = reply->alloc_base; + info.RegionSize = reply->size; + } + } + SERVER_END_REQ; + if (res) return 0; + + len = min(len, sizeof(info)); + memcpy(pinfo, &info, len); + return len; } Index: server/Makefile.in =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/server/Makefile.in,v retrieving revision 1.33 diff -u -u -r1.33 Makefile.in --- server/Makefile.in 9 May 2002 04:31:40 -0000 1.33 +++ server/Makefile.in 14 Jul 2002 17:00:22 -0000 @@ -39,6 +39,7 @@ trace.c \ unicode.c \ user.c \ + virtual.c \ window.c PROGRAMS = wineserver Index: server/protocol.def =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/server/protocol.def,v retrieving revision 1.39 diff -u -u -r1.39 protocol.def --- server/protocol.def 2 Jun 2002 21:22:22 -0000 1.39 +++ server/protocol.def 10 Jul 2002 21:44:11 -0000 @@ -1038,6 +1038,21 @@ @END +/* query a process virtual memory */ +(a)REQ(query_virtual_memory_info) + obj_handle_t handle; /* handle to the process */ + void* addr; /* address where to look at */ +(a)REPLY + int state; + int protect; + int protect_other; + int type; + void* base_address; + void* alloc_base; + int size; +(a)END + + /* Create a file mapping */ @REQ(create_mapping) int size_high; /* mapping size */ --- /dev/null Thu Jan 1 01:00:00 1970 +++ server/virtual.c Wed Jul 10 23:31:31 2002 @@ -0,0 +1,103 @@ +#include "config.h" +#include "wine/port.h" + +#include <assert.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +#include "process.h" +#include "request.h" + +static void query_virtual_memory_info(struct process* process, unsigned base, + struct query_virtual_memory_info_reply* reply) +{ + char buffer[MAX_PATH]; + FILE* file = NULL; + unsigned alloc_base = 0; + unsigned size = 0; + unsigned start, end; + unsigned vprot; + +#ifdef linux + if (process->thread_list) + { + sprintf(buffer, "/proc/%d/maps", process->thread_list->unix_pid); + file = fopen(buffer, "r"); + } +#endif + if (!file) + { + set_error(STATUS_NOT_SUPPORTED); + return; + } + + while (fgets(buffer, sizeof(buffer) - 1, file)) + { +#ifdef linux + char prot[5]; + unsigned shift, minor, major; + /* 407ac000-407ae000 rw-p 00007000 */ + + if (sscanf(buffer, "%x-%x %4s %08x %x:%x", &start, &end, prot, &shift, &major, &minor) != 6) + { + if (sscanf(buffer, "%x-%x %4s", &start, &end, prot) != 3) continue; + shift = 0; + major = minor = 0; + } + + vprot = 0; + if (prot[0] == 'r') vprot |= VPROT_READ; + if (prot[1] == 'w') vprot |= VPROT_WRITE; + if (prot[2] == 'x') vprot |= VPROT_EXEC; + if (prot[3] == 'p') vprot |= VPROT_WRITECOPY; +#endif + + if (end <= base) + continue; + if (base < start) + { + size = start - alloc_base; + goto noMap; + } + if (base < end) + { + alloc_base = start; + size = end - start; + + reply->state = MEM_COMMIT; /* FIXME: hard to tell MEM_RESERVE */ + reply->protect = vprot; + reply->protect_other = reply->protect; /* FIXME: hard to guesss */ + + reply->type = (major && minor) ? MEM_MAPPED : 0; /* FIXME */ + goto final; + } + alloc_base = end; + } + + size = 0xffff0000 - alloc_base; + + noMap: + reply->state = MEM_FREE; + reply->protect = 0; + reply->protect_other = 0; + reply->type = 0; + final: + reply->base_address = (LPVOID)base; + reply->alloc_base = (LPVOID)alloc_base; + reply->size = size - (base - alloc_base); + + fclose(file); + return; +} + +/* query information about a part of the memory */ +DECL_HANDLER(query_virtual_memory_info) +{ + struct process* process; + + if (!(process = get_process_from_handle( req->handle, PROCESS_VM_READ ))) + return; + + query_virtual_memory_info(process, (unsigned)req->addr, reply); +}

July 15, 2002

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

by Shachar Shemesh

Francois Gouget wrote: >On Mon, 15 Jul 2002, Shachar Shemesh wrote: > > > >>+ LPWSTR lpText = (LPWSTR)lParam; >>+ lpText[0] = '\0'; >> >> >>Shouldn't it be >> >>+ LPWSTR lpText = (LPWSTR)lParam; >>+ lpText[0] = L'\0'; >> >> > >It does not matter. Both are equivalent to: > > >>+ lpText[0] = 0; >> >> > >'\0' is a single byte 0 value (IOW a char) which is expanded to 16bits, >and assigned to the WCHAR. L'\0' is a 32bit 0 Unicode character (a >wchar_t) which is scaled down to 16bits and assigned to the WCHAR. And >the last one is a 32bit integer which too is scaled down to 16bits and >assigned to the WCHAR. > >The thing is Unix C compilers don't have 16bit literal Unicode >characters (except in some cases g++ 3.x) so you cannot write code that >does not imvolve a conversion of some sort. > > Not trying to be a hard head here, and I'm not even remotely trying to suggest that this particular line of code is a crucial point. It's just that my understanding of this project and the way code should be with it, all WINE DLLs are actually WineLib code. All WineLib code should duel compile on Windows and Unix. In theory, there should not be a problem compiling our sources of USER.DLL on Visual C, and running it on Windows instead of the native DLL (far fetched example, I know). If VC does have a "one correct way", while gcc doesn't, shouldn't we prefer the VC correct one?

July 15, 2002

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

by Francois Gouget

On Mon, 15 Jul 2002, Shachar Shemesh wrote: > + LPWSTR lpText = (LPWSTR)lParam; > + lpText[0] = '\0'; > > > Shouldn't it be > > + LPWSTR lpText = (LPWSTR)lParam; > + lpText[0] = L'\0'; It does not matter. Both are equivalent to: > + lpText[0] = 0; '\0' is a single byte 0 value (IOW a char) which is expanded to 16bits, and assigned to the WCHAR. L'\0' is a 32bit 0 Unicode character (a wchar_t) which is scaled down to 16bits and assigned to the WCHAR. And the last one is a 32bit integer which too is scaled down to 16bits and assigned to the WCHAR. The thing is Unix C compilers don't have 16bit literal Unicode characters (except in some cases g++ 3.x) so you cannot write code that does not imvolve a conversion of some sort. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

July 15, 2002

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

by Shachar Shemesh

+ LPWSTR lpText = (LPWSTR)lParam; + lpText[0] = '\0'; Shouldn't it be + LPWSTR lpText = (LPWSTR)lParam; + lpText[0] = L'\0'; ? Carl Sopchak wrote: >I found this while trying to get Quicken 2000 Deluxe to run under wine. Q2k >was crashing when adding a new security (stock) if nothing was seleted in the >Asset Class ListBox. (It doesn't do this under "real Win NT"...) It turns >out that Q2k seems to keep processing the value returned by WM_GETTEXT >regardless of the number of characters WM_GETTEXT returns. Since wine's >WM_GETTEXT was not returning a NULL string (='\0'), a subsequent strcpy (or >some such) was choking because the string was not null terminated. > >The attached patch sets the return string to '\0' if LB_GETCURSEL returns >LB_ERR. (Although this behaviour is not specified on msdn.microsoft.com, I >figure it can't hurt, since the program calling WM_GETTEXT should be >expecting the buffer to get changed by the call...) I don't know (and have >not checked) to see if other *_GETTEXT message handlers need to do the >same... > >One last point: I'm fairly new at C coding. If there's a better way to do >what this patch does, feel free to improve upon it... <grin> > >Carl > > >------------------------------------------------------------------------ > >Index: controls/combo.c >=================================================================== >RCS file: /home/wine/wine/controls/combo.c,v >retrieving revision 1.85 >diff -u -r1.85 combo.c >--- controls/combo.c 10 Jul 2002 23:11:28 -0000 1.85 >+++ controls/combo.c 15 Jul 2002 17:02:47 -0000 >@@ -1603,6 +1603,15 @@ > return (LRESULT)n; > } > } >+ /* LB_GETCURSEL returned LB_ERR - truncate string, return zero */ >+ if (unicode) >+ { >+ LPWSTR lpText = (LPWSTR)lParam; >+ lpText[0] = '\0'; >+ } else { >+ LPSTR lpText = (LPSTR)lParam; >+ lpText[0] = '\0'; >+ } > return 0; > } > > >

July 15, 2002

Re: CxxFrameHandler problem

by Jürgen Schmied

Hmm, I think these FIXME messages should be considered as a real FIXME. The application might throw a exception and catch it later as a normal behaviour. As long as our implementation of CxxFrameHandler does not behave right is has to be fixed. Then we can blame the application. juergen > --- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > > If anyone is working on the CxxFrameHandler I have > > two > > applications I have been working on that may help in > > testing/tracking down the problems. Currently both > > WinCVS and geoshell suffer from this problem. Both > > applications are GPL so if you need to look at the > > source to find out what is going on you can. > > Steven, these FIXME messages are only traces of an > exception thrown by application and are not related to > real problem in any way. We should find out why an > exception is thrown in the first place. > > I recommend you to to file a separate bug report for > each case. > > Andriy > > __________________________________________________ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com > > --- juergen.schmied(a)debitel.net

July 15, 2002

Re: CxxFrameHandler problem

by Uwe Bonnes

>>>>> "Andriy" == Andriy Palamarchuk <apa3a(a)yahoo.com> writes: Andriy> --- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: >> If anyone is working on the CxxFrameHandler I have two applications I >> have been working on that may help in testing/tracking down the >> problems. Currently both WinCVS and geoshell suffer from this >> problem. Both applications are GPL so if you need to look at the >> source to find out what is going on you can. Andriy> Steven, these FIXME messages are only traces of an exception Andriy> thrown by application and are not related to real problem in any Andriy> way. We should find out why an exception is thrown in the first Andriy> place. Andriy> I recommend you to to file a separate bug report for each case. However out CxxFrameHandler implementation normally makes the real culprit very hard to find. Nearly never a good backtrace is produced when CxxFrameHandler is involved, sometimes the backtrace goes in a loo or something else happens. To make builtin msvcrt usable or even debugable, we need a working CxxFrameHandler implementation. I looked at http://www.thecodeproject.com/cpp/Exceptionhandler.asp, but I didn't feel like implementing it... 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 15, 2002