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

Re: Test for LoadString
by Dmitry Timoshkov Jan. 30, 2007

Jan. 30, 2007

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > Add tests for LoadString, completed on Windows. > > As I see, > 1. LoadStringA with buf = NULL segfaults in Windows, we have to produce ERR > message instead > 2. LoadStringA with buf = NULL, buflen = 0 returns -1 > 3. LoadStringW with some buf, buflen = 0 returns length of the resource string > and puts some strange chars (F%O f.i.) in the buffer. > 4. LoadStringW with buf = NULL, buflen!=0 returns 0 > 5. LoadStringA/W segfaults on negative buflen Unfortunately the tests don't show whether last error value should be set in the case of a failure or not, please add that as well. -- Dmitry.

1 0

Re: Do not use LoadStringW for get strlen of resource string
by James Hawkins Jan. 30, 2007

Jan. 30, 2007

On 1/30/07, Vitaly Lipatov <lav(a)etersoft.ru> wrote: > As LoadStringW(...NULL,0) returns length of resource string only in Wine, > rewrote this part in independent manner. > > Changelog: > - do not use LoadStringW for get strlen of resource string > This is wrong: > @@ -75,15 +75,16 @@ static LPWSTR HH_ANSIToUnicode(LPCSTR an > /* Loads a string from the resource file */ > static LPWSTR HH_LoadString(DWORD dwID) > { > - LPWSTR string = NULL; > + WCHAR buf[1024]; > + LPWSTR string; > int iSize; > > - iSize = LoadStringW(hhctrl_hinstance, dwID, NULL, 0); > + iSize = LoadStringW(hhctrl_hinstance, dwID, buf, sizeof(buf)/sizeof(buf[0])); > iSize += 2; /* some strings (tab text) needs double-null termination */ > > string = HeapAlloc(GetProcessHeap(), 0, iSize * sizeof(WCHAR)); > LoadStringW(hhctrl_hinstance, dwID, string, iSize); > - > + string[iSize] = 0; /* add second null termination */ > return string; > } Why are you adding string[iSize] = 0...? This is an internal wrapper around LoadString that makes no promises about double-null termination, etc. Don't make assumptions. Also, you need to keep the style of the original code when making changes. There was an empty line where you added the aforementioned pieced of code, and that empty line separates logically different pieces of the function. 1024 is a magic number and it needs to go. You're putting a limitation of 1024 length on HH_LoadString that didn't exist before. -- James Hawkins

1 0

Re: [PATCH 7/7] server/kernel32: Marshal security descriptor to server for a new process.
by Mirek Jan. 30, 2007

Jan. 30, 2007

Hi, i cant compile wine with this patch, do you know why? gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o regsvr.o regsvr.c make[2]: Leaving directory `/root/.WineCVS/sources/cvswine/wine/dlls/mmdevldr.vxd' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o profile.o profile.c process.c: In function ‘create_process’: process.c:1314: error: ‘struct new_process_request’ has no member named ‘sd_len’ process.c:1318: error: ‘struct new_process_request’ has no member named ‘sd_len’ process.c:1320: error: ‘struct new_process_request’ has no member named ‘sd_len’ process.c:1322: error: ‘struct new_process_request’ has no member named ‘sd_len’ process.c:1323: error: ‘struct new_process_request’ has no member named ‘sd_len’ process.c:1325: error: ‘struct new_process_request’ has no member named ‘sd_len’ process.c:1327: error: ‘struct new_process_request’ has no member named ‘sd_len’ make[2]: *** [process.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Entering directory `/root/.WineCVS/sources/cvswine/wine/dlls/monodebg.vxd' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o monodebg.o monodebg.c ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./monodebg.vxd.spec monodebg.o -o monodebg.vxd.so -lkernel32 ../../libs/port/libwine_port.a ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./mlang.spec mlang.o regsvr.o -o mlang.dll.so -loleaut32 -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -Wb,-doleaut32 -luuid ../../libs/port/libwine_port.a make[2]: Leaving directory `/root/.WineCVS/sources/cvswine/wine/dlls/kernel32' make[1]: *** [kernel32] Error 2 make[1]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/root/.WineCVS/sources/cvswine/wine/dlls/mlang' make[2]: Leaving directory `/root/.WineCVS/sources/cvswine/wine/dlls/monodebg.vxd' make[1]: Leaving directory `/root/.WineCVS/sources/cvswine/wine/dlls' make: *** [dlls] Error 2 Mirek Vitaliy Margolen napsal(a): > We are limited to only 5 server data calls. Here it would have been 7. > And possibly 12 in the future. Hence decision to send self-relative > SECURITY_DESCRIPTOR. > --- > dlls/kernel32/process.c | 25 +++++++++++++++++++++++++ > server/process.c | 8 ++++++-- > server/protocol.def | 2 ++ > 3 files changed, 33 insertions(+), 2 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c > index 8cdcd72..463071d 100644 > --- a/dlls/kernel32/process.c > +++ b/dlls/kernel32/process.c > @@ -1277,6 +1277,8 @@ static BOOL create_process( HANDLE hFile > > SERVER_START_REQ( new_process ) > { > + PSECURITY_DESCRIPTOR p_sd = NULL; > + > req->inherit_all = inherit; > req->create_flags = flags; > req->socket_fd = socketfd[1]; > @@ -1303,6 +1305,27 @@ static BOOL create_process( HANDLE hFile > if (is_console_handle(req->hstderr)) req->hstderr = console_handle_unmap(req->hstderr); > } > > + /* marshal security descriptor */ > + if (psa && psa->lpSecurityDescriptor) > + { > + SECURITY_DESCRIPTOR_CONTROL control; > + DWORD revision; > + > + req->sd_len = RtlLengthSecurityDescriptor( psa->lpSecurityDescriptor ); > + RtlGetControlSecurityDescriptor( psa->lpSecurityDescriptor, &control, &revision ); > + > + if (control & SE_SELF_RELATIVE) > + wine_server_add_data( req, psa->lpSecurityDescriptor, req->sd_len ); > + else > + if ((p_sd = HeapAlloc( GetProcessHeap(), 0, req->sd_len ))) > + { > + RtlMakeSelfRelativeSD( psa->lpSecurityDescriptor, p_sd, &req->sd_len ); > + wine_server_add_data( req, p_sd, req->sd_len ); > + } > + else req->sd_len = 0; > + } > + else req->sd_len = 0; > + > wine_server_add_data( req, params, params->Size ); > wine_server_add_data( req, params->Environment, (env_end-params->Environment)*sizeof(WCHAR) ); > if ((ret = !wine_server_call_err( req ))) > @@ -1313,6 +1336,8 @@ static BOOL create_process( HANDLE hFile > info->hThread = reply->thandle; > } > process_info = reply->info; > + > + HeapFree( GetProcessHeap(), 0, p_sd ); > } > SERVER_END_REQ; > > diff --git a/server/process.c b/server/process.c > index 1c53f49..21dd8cb 100644 > --- a/server/process.c > +++ b/server/process.c > @@ -820,6 +820,7 @@ DECL_HANDLER(new_process) > struct thread *thread; > struct process *process; > struct process *parent = current->process; > + const SECURITY_DESCRIPTOR *p_sd = get_req_data(); > int socket_fd = thread_get_inflight_fd( current, req->socket_fd ); > > if (socket_fd == -1) > @@ -841,14 +842,14 @@ DECL_HANDLER(new_process) > info->hstderr = req->hstderr; > info->exe_file = NULL; > info->process = NULL; > - info->data_size = get_req_data_size(); > + info->data_size = get_req_data_size() - req->sd_len; > info->data = NULL; > > if (req->exe_file && > !(info->exe_file = get_file_obj( current->process, req->exe_file, FILE_READ_DATA ))) > goto done; > > - if (!(info->data = memdup( get_req_data(), info->data_size ))) goto done; > + if (!(info->data = memdup( (char*)get_req_data() + req->sd_len, info->data_size ))) goto done; > > if (!(thread = create_process( socket_fd, current, req->inherit_all ))) goto done; > process = thread->process; > @@ -900,6 +901,9 @@ DECL_HANDLER(new_process) > reply->phandle = alloc_handle( parent, process, req->process_access, req->process_attr ); > reply->thandle = alloc_handle( parent, thread, req->thread_access, req->thread_attr ); > > + if (req->sd_len) > + set_object_sd( &process->obj, p_sd, OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION | > + SACL_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION ); > done: > release_object( info ); > } > diff --git a/server/protocol.def b/server/protocol.def > index f49f331..9ebbcbc 100644 > --- a/server/protocol.def > +++ b/server/protocol.def > @@ -436,6 +436,8 @@ typedef union > unsigned int process_attr; /* attributes for process object */ > unsigned int thread_access; /* access rights for thread object */ > unsigned int thread_attr; /* attributes for thread object */ > + data_size_t sd_len; /* length of process' security descriptor */ > + VARARG(sd,bytes,sd_len); /* process' security descriptor to set */ > VARARG(info,startup_info); /* startup information */ > VARARG(env,unicode_str); /* environment for new process */ > @REPLY > > > > ------------------------------------------------------------------------ > >

2 1

Re: Test case for Bug 50 [Was: Bug 50]
by Pedro Araujo Chaves Jr. Jan. 30, 2007

Jan. 30, 2007

On 2007-01-29, Duane Clark wrote: > GetTextExtentPoint32 > > For some examples in Wine, look at almost any control in comctl32. I was afraid somebody would answer that... Thanks for the quick reply, but that isn't exactly what I need. Here's the picture: when an application calls TextOut() for printing text, the usual (at least in my case) call sequence in Wine is TextOut() TextOutA() ExtTextOutA() ExtTextOutW() (the one I patched) GetTextExtentPointW() GetTextExtentPoint32W() (the wide-char version of the one you mentioned) GetTextExtentExPointW() WineEngGetTextExtentExPoint() (the one that actually gets the individual character widths) That is, at some point, TextOut() indirectly uses GetTextExtentPoint32() to get the dimensions, okay. But what I need is to check the text width *after* it was output by TextOut() -- in other words, after the function has returned, to see if it output the text properly. In Wine, I tried the trick of making ExtTextOutW() return the said value, and the tests passed without a hitch, which means the text is being properly justified. The problem is that such is not an acceptable way of doing things, and, to use Dan Kegel's words, that is not going to fly on Windows. To be a bit clearer, in my tests I do call GetTextExtent32() in order to compute the remaining white space for the justification part, and what I want to check is whether TextOut() understood it right or not. - Pedro.

2 2

Re: [msvcrt] stat64 (1/3) add declarations for stat64, fstat64 and wstat64
by Francois Gouget Jan. 30, 2007

Jan. 30, 2007

On Tue, 30 Jan 2007, Damjan Jovanovic wrote: > Changelog: > * Added declarations for stat64, fstat64 and wstat64 --- a/include/msvcrt/sys/stat.h 2006-11-24 18:18:04.000000000 +0200 +++ b/include/msvcrt/sys/stat.h 2007-01-28 15:48:28.000000000 +0200 @@ -104,6 +104,20 @@ +struct __stat64 { + _dev_t st_dev; + _ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + _dev_t st_rdev; + __int64 st_size; + __time64_t st_atime; + __time64_t st_mtime; + __time64_t st_ctime; +}; This structure is called _stat64 in Visual Studio 2005. Has it changed in more recent versions? If not I would stick to it otherwise Windows code that uses 'struct _stat64' would fail to compile with Winelib. [...] +int _fstat64(const char*,struct __stat64*); +int _stat64(int,struct __stat64*); You have reversed the _fstat64() and _stat64() prototypes. --- a/include/msvcrt/sys/types.h 2006-11-24 18:18:04.000000000 +0200 +++ b/include/msvcrt/sys/types.h 2007-01-28 14:23:09.000000000 +0200 @@ -56,6 +56,11 @@ +#ifndef _TIME64_T_DEFINED +typedef __int64 __time64_t; +#define _TIME64_T_DEFINED +#endif I'd write it as below but that's purely an aesthetic thing (I like how the #ifndef and the #define line up): +#ifndef _TIME64_T_DEFINED +#define _TIME64_T_DEFINED +typedef __int64 __time64_t; +#endif -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

Re: [ws2_32] INET_ADDRSTRLEN (1/2) add INET_ADDRSTRLEN and INET_ADDRSTRLEN6
by Francois Gouget Jan. 30, 2007

Jan. 30, 2007

On Tue, 30 Jan 2007, Damjan Jovanovic wrote: > Changelog: > * Added INET_ADDRSTRLEN and INET_ADDRSTRLEN6 defines. > > --- a/include/ws2tcpip.h 2006-11-24 18:18:04.000000000 +0200 > +++ b/include/ws2tcpip.h 2007-01-26 21:14:25.000000000 +0200 > @@ -204,6 +204,9 @@ > # define WS_EAI_SOCKTYPE WSAESOCKTNOSUPPORT > #endif > > +#define INET_ADDRSTRLEN 16 > +#define INET6_ADDRSTRLEN 46 The PSDK says that the values for these are respectively 22 and 65. Also the latest PSDK defines these in ws2ipdef.h which is a new header which is included from ws2tcpip.h. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

1 0

Re: Make.rules.in: Generate better output
by Francois Gouget Jan. 30, 2007

Jan. 30, 2007

On Tue, 30 Jan 2007, Bang Jun-Young wrote: > It's quite annoying to see tons of ugly "gcc -I. -I. -I../../include > -I../../include" > on the screen during build and in the log file thereafter, so... [...] > +ifeq ($(TOPSRCDIR),$(TOPOBJDIR)) > +ifeq ($(SRCDIR),.) > +INCLUDES = -I. -I$(TOPSRCDIR)/include $(EXTRAINCL) 'ifeq' is a GNU Make extension and thus the policy is to avoid it, especially for purely cosmetic issues. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

1 0

Another report of malware running on Wine
by Dan Kegel Jan. 30, 2007

Jan. 30, 2007

A user reports that a trojan horse runs ok on wine, and indeed it had him fooled (right up to the point where it popped up a window offering to optimize his registry, anyway): http://www.postproductie.nl/?p=9

2 1

Please help me debug wineserver
by Misha Koshelev Jan. 29, 2007

Jan. 29, 2007

Hi, I am new to wine programming but have a fair amount of experience with C/C++ programming in general. I have recently decided to make the Vector NTI application work on Wine, and after overcoming quite a few installation difficulties by making an install shell script, I have run in to a problem that I have traced down to wineserver. This problem occurs after repeatedly changing folders in the Vector NTI "Open Molecule File" dialog, which does not use the standard open file Windows dialog (e.g., the "Open Shortcut" dialog in the same program works fine). Wineserver crashes with the following error message: wineserver: object.c:274: release_object: Assertion `obj->refcount' failed. On looking at the output of WINEDEBUG=+server, it seems that the "Vector NTI" thread is woken up, and then receives a USER_APC, at which time this crash occurs. I am including at the end of this message a wineserver gdb backtrace and the last few lines of the WINEDEBUG=+server output. If anyone sees anything that jumps out, I would appreciate your help. Thank you very much. Misha --- Backtrace: #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d56770 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7d57ef3 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d4fdbb in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0x0805ad0a in release_object (ptr=0x83ad0a0) at object.c:274 #5 0x0806c196 in end_wait (thread=0x83ad100) at thread.c:451 #6 0x0806c9b7 in wake_thread (thread=0x83ad100) at thread.c:578 #7 0x0806cddd in queue_apc (process=<value optimized out>, thread=0x83ad100, apc=0x83ad888) at thread.c:751 #8 0x0806cebb in thread_queue_apc (thread=0x83ad100, owner=0x0, call_data=0xbffe77b8) at thread.c:764 #9 0x08052dc2 in async_terminate (async=0x82e7780, status=6) at fd.c:1294 #10 0x0804bf70 in dir_destroy (obj=0x83ad0a0) at file.h:131 #11 0x0805ac9a in release_object (ptr=0x83ad0a0) at object.c:279 #12 0x0806c196 in end_wait (thread=0x83ad100) at thread.c:451 #13 0x0806cf30 in thread_timeout (ptr=0x83aa1c0) at thread.c:598 #14 0x08051e3a in get_next_timeout () at fd.c:688 #15 0x08052ea0 in main_loop () at fd.c:456 #16 0x08057c4a in main (argc=2, argv=0xbffe8034) at main.c:136 Last few lines of WINEDEBUG=+server output: 0009: create_key() = 0 { hkey=0x168, created=0 } 0009: get_key_value( hkey=0x168, name=L"Desktop" ) 0009: get_key_value() = 0 { type=2, total=44, data={25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,4c,00,45,00,25,00,5c,00,44,00,65,00,73,00,6b,00,74,00,6f,00,70,00,00,00} } 0009: create_key( parent=0x6c, access=000f003f, attributes=00000000, options=00000000, modif=0, namelen=112, name=L"Software\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList", class=L"" ) 0009: create_key() = 0 { hkey=0x16c, created=0 } 0009: get_key_value( hkey=0x16c, name=L"ProfilesDirectory" ) 0009: get_key_value() = 0 { type=2, total=40, data={63,00,3a,00,5c,00,77,00,69,00,6e,00,64,00,6f,00,77,00,73,00,5c,00,70,00,72,00,6f,00,66,00,69,00,6c,00,65,00,73,00,00,00} } 0011: *wakeup* signaled=258 STATUS_TIMEOUT cookie=0x7bbfe880 0011: *wakeup* signaled=192 STATUS_USER_APC cookie=0x7bbfe880 wineserver: object.c:274: release_object: Assertion `obj->refcount' failed.

1 0

Re: Test case for Bug 50 [Was: Bug 50]
by Pedro Araujo Chaves Jr. Jan. 29, 2007

Jan. 29, 2007

I think I've managed to patch [1] bug 50 [2], but I'm having a little trouble coming up with a proper test case... I'm already at it, studying and investigating, but could someone test that, too? [1] http://bugs.winehq.org/attachment.cgi?id=4543&action=view [2] http://bugs.winehq.org/show_bug.cgi?id=50 TIA, - Pedro.

2 3