wine-devel

wine-devel@winehq.org

3 participants
84399 discussions

Bugs involving returning strings from API functions
by Justin Santa Barbara 04 Sep '01

04 Sep '01

There are a group of functions in the kernel that appear to be broken in that they don't follow the Windows API specification. The general convention for these functions is as follows: The function is called with a pointer to a buffer and the size of the buffer, and returns the number of characters copied to the buffer, excluding the null terminator, unless the buffer is too small when the total size in characters of the buffer needed (with a null terminator) is returned. If the buffer is too small, the string is not copied at all. Several functions that I have spotted don't implement this correctly - particularly ones in files/directory.c. eg GetSystemDirectory. They count the Null Terminator. A typical symptom of this is that an installation program attempts to call LoadLibrary on "C:\\WINDOWS\\SYSTEM", because it's appended eg "OLE32.DLL" after the null character. This is one of the problems when installing the Microsoft installer, for example. While looking for other functions that might do the same thing, I came across this: /*********************************************************************** * GetCurrentDirectoryW (KERNEL32.@) */ UINT WINAPI GetCurrentDirectoryW( UINT buflen, LPWSTR buf ) { LPSTR xpath = HeapAlloc( GetProcessHeap(), 0, buflen+1 ); UINT ret = GetCurrentDirectoryA( buflen, xpath ); if (ret < buflen) ret = MultiByteToWideChar( CP_ACP, 0, xpath, -1, buf, buflen ) - 1; HeapFree( GetProcessHeap(), 0, xpath ); return ret; } But HeapAlloc takes a number of bytes, whereas buflen is in (two-byte) characters. ie a small buffer would appear to crash this code. (right?) While I have succesfully patched these bugs on my machine, I'm not sure that going through and looking for every function that may be broken in some similar way and changing them one-by-one is a good way to proceed. These bugs all have to do with returning strings - it would probably be better to attempt to have functions that 'copy out an ANSI string' or 'copy out a UNICODE string' according to this API. Without meaning to be critical, the problem appears to be that the same functionality has been written many times throughout the code, and so multiple and different bugs have crept in. However, I'm quite new to using wine, and so would like the advice and opinions of those more experienced. My questions: 1) Is there a design reason why a single common function for string copying is not used? Maybe something to do with separate libraries, some of which may be replaced by native windows DLLs? Maybe someone more knowledgeable than myself could direct me as to the best place to put the helper function implementations. 2) Would writing these string helper functions and changing (most) string-returning functions to use them be worthwhile (or indeed even welcome)? 3) Is there a move to using UNICODE internally in the kernel that means that this would be best combined with some other effort? Certainly if this were an eventual design goal then using helper functions would make that job a little easier. Comments? Justin SB

2 3

CryptoAPI
by Travis Michielsen 04 Sep '01

04 Sep '01

Hi, I was going to start implementing the Cypto API (in advapi32.dll) over the next few weeks. As of yet these functions are no more than stubs. However, I am finding increased use of this API as more applications becomed networkable and relying more heavily on internet connections. I was hoping to implement these functions by using the OpenSSL library (if/when available). This library seems to have similar capabilities. One of my concerns is about legal issues. What special concerns should I note about cryptographic software? Are there any special copyright issues I should be aware of? Another question is about design. M$ seems to split the cryptographic software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). Should I do this as well so that, applications can use the native dlls if necessary or should I simply implement it entirely though advapi32.dll which and avoid the need to create several new (and very small) dlls under wine? Because most of the code is already in another library (OpenSSL) creating extra dlls seems abit unnecessary. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

3 4

Two threads waiting for a critical section
by Uwe Bonnes 03 Sep '01

03 Sep '01

Hallo, appended log seems fishy to me: trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 (0) trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d34a0 (fs 01cf, pid 15616) count before 0 (1) ^^^^ ^^^^^^^^ trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d5280 (fs 07bf, pid 15623) count before 0 (2) ^^^^ ^^^^^^^^ trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 1 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 1 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 0 (3) err:ntdll:RtlpWaitForCriticalSection section 0x4010f7d4 "syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) fs=07bf err:ntdll:RtlpWaitForCriticalSection section 0x4010f7d4 "syslevel.c: Win16Mutex" wait timed out, retrying (5 min) fs=07bf At (0) 0x96d41a0 holds the Mutex. At (1) 0x96d34a0 tries to get it, but as 0x96d41a0 has the Mutex, it waits. At (2) 0x96d5280 also tries to get the lock and must also wait. At (3) 0x96d41a0 releases the lock, but neither 0x96d34a0 nor 0x96d5280 start to aquire the lock. Why doesn't one of them continue? This happens with the installer from the recent RS Components CD-ROM running SETUP.EXE with --winver nt40. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

' ' & '"' handling in the command line
by Francois Gouget 03 Sep '01

03 Sep '01

Hi, Some time ago I realized that the command line handling in Wine did not work properly when arguments with spaces or double-quotes are involved. For instance I would start a Wine application like this: main "a b" c and it would tell me something like this: GetCommandLine=[./main a b c] Or I would call CreateProcess(... "main \"a b\" c" ...) and main would get: main -> argc=4 0 [./main] 1 [a] 2 [b] 3 [c] So I investigated this and found that * double-quotes, '"', have the same meaning in win32 as in unix (tested on Win95 & Win2000) * backslash, '\', work as on unix, especially wrt double-quotes * single-quotes, ''', have no special meaning So CreateProcess(... "main \"a b\" c" ...) should give me: GetCommandLine=[./main "a b" c] main -> argc=3 0 [./main] 1 [a b] 2 [c] I searched for places where we convert command lines to argv lists and reciprocally and modified them to work as on windows. With this patch things should be correct, whether you call a Wine application from Unix, from another Wine application via CreateProcess, or if you call a Unix application from Wine. There's just one little bit in the msvcrt code which I treated in a separate patch (p20010902-cmdline2.diff). In the process I wrote a few test applications: * hello regular hello world unix app * main A Wine console application which dumps its argc/argv and then calls GetCommandLine, ... You can also call it with a '-i' parameter to test CommandLineToArgvW, except that _getws is not implemented in Wine so you can only do that on windows * winmain A Wine Gui application which dumps lpCmdLine and then calls __getmainargs, CommandLineToArgvW(GetCommandLineW), ... * createp Which reads a command line from stdin and calls CreateProcess with it * spawnv Reads a list of arguments from stdin and calls spawnv with it (spawn* don't handle ' ' and '"', see p20010902-cmdline3.diff) * spawn Same but the command is fixed I know that there has been discussions about the command line handling before and that some applications do very weird things. Please test this patch and let me know how it goes. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: pe format
by Dan Kegel 02 Sep '01

02 Sep '01

tiago r wrote: > From: Dan Kegel <dank(a)kegel.com> > > > tiago r wrote: > > > i know this doesn't got direct link with wine development, but i was wondering if someone has a complete reference of the portable executable format including BOUND_IMPORT_DIRECTORY description. > > > > google finds > > http://www.microsoft.com/hwdev/hardware/PECOFF.htm > > http://www.windowsitlibrary.com/Content/356/11/1.html > > http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile.html > > http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile2.html > > In fact all of this (and other) documents describe the pe format but none of them describe the BOUND_IMPORT_DIR. Hmm. Searching for BOUND_IMPORT with google yields two links: http://www.radsoft.net/gallery/bv/ http://members.internettrash.com/astalalista/ac/pe_tut2.html plus one hit on groups.google.com (a guy doing a minimal hello_world.exe mentioned it). Maybe try asking on comp.lang.asm.x86, or some microsoft group... - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

pe format
by tiago r 01 Sep '01

01 Sep '01

i know this doesn't got direct link with wine development, but i was wondering if someone has a complete reference of the portable executable format including BOUND_IMPORT_DIRECTORY description. regards, Tiago -- _______________________________________________ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! http://www.net2phone.com/cgi-bin/link.cgi?143

2 1

Race condition?
by lawson_whitney＠juno.com 01 Sep '01

01 Sep '01

Good day! My app just crashed, after I logged in and dismissed its modal nuisance ad. Normally it doesn't, so I guess this might be some kind of race condition? Here is a backtrace, in case it might be useful. If not, sorry for the noise. Oh, load order is: [DllOverrides] "*" = "builtin, so, native" [AppDefaults\\juno.exe\\DllOverrides] "msvcrt" = "native" "riched32" = "native" Haven't seen anything on wine-cvs since 29 August, but the local wine is up to that. No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42LOC.DLL' (0x76020000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RICHED32.DLL' (0x6c000000) Unhandled exception: page fault on read access to 0x2e6873f4 in 32-bit code (0x5f404eca). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x5f404eca (MFC42.DLL.2028+0xf in C:\AWAY\BIN\MFC42.DLL): cmpl $1,0xfffffff4(%eax) Wine-dbg>bt Backtrace: =>0 0x5f404eca (MFC42.DLL.2028+0xf in C:\AWAY\BIN\MFC42.DLL) (ebp=405b5b88) 1 0x15030f38 (JSESSION.DLL.2914+0x30d8 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5ca0) 2 0x150257a3 (JSESSION.DLL.2141+0xad3 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5cb4) 3 0x1502c816 (JSESSION.DLL.2606+0x766 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5e54) 4 0x1502d27a (JSESSION.DLL.2606+0x11ca in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5edc) 5 0x150249f9 (JSESSION.DLL.2039+0x699 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5f7c) 6 0x15049088 (JSESSION.DLL.3948+0x988 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b6088) 7 0x1502d45a (JSESSION.DLL.2707+0x5a in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b61ac) 8 0x150241e8 (JSESSION.DLL.2035+0x88 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b61f4) 9 0x0042aff0 (juno.exe..text+0x29ff0 in C:\away\bin\juno.exe) (ebp=405b623c) 10 0x5f4019f0 (MFC42.DLL.5163+0x31c in C:\AWAY\BIN\MFC42.DLL) (ebp=405b62bc) 11 0x5f4016b2 (MFC42.DLL.6374+0x22 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b62dc) 12 0x5f40163b (MFC42.DLL.1109+0x71 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b633c) 13 0x5f4015c6 (MFC42.DLL.1578+0x2a in C:\AWAY\BIN\MFC42.DLL) (ebp=405b6358) 14 0x5f40157d (MFC42.DLL.1579+0x39 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b6384) 15 0x40665a07 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b63a8) 16 0x40665a8d (WINPROC_CallWndProc+0x7d(proc=0x5f401544, hwnd=0x6005d, msg=0x403, wParam=0x0, lParam=0x0) [winproc.c:172] in libuser32.so) (ebp=405b63d8) 17 0x4066b417 (CallWindowProcA+0x93(func=0x40d31c44, hwnd=0x6005d, msg=0x403, wParam=0x0, lParam=0x0) [winproc.c:2639] in libuser32.so) (ebp=405b6400) 18 0x4064e822 (DispatchMessageA+0xd6(msg=0x4920dc) [message.c:922] in libuser32.so) (ebp=405b6444) 19 0x5f401226 (MFC42.DLL.5307+0x3a in C:\AWAY\BIN\MFC42.DLL) (ebp=004920dc) 20 0x00000403 (ebp=0006005d) Wine-dbg>info local MFC42.DLL.2028: Wine-dbg>up 15 Wine-dbg>info local WINPROC_wrapper: Wine-dbg>up 172 retvalue = WINPROC_wrapper( proc, hwnd, msg, wParam, lParam ); Wine-dbg>info local WINPROC_CallWndProc: long int(*none)()* proc == 0x5f401544 unsigned int hwnd == 0x0006005d unsigned int msg == 0x00000403 unsigned int wParam == 0x00000000 long int lParam == 0x00000000 unsigned int hwnd (optimized into register $edi) == 0x00000003 long int retvalue == 0x00000000 int iWndsLocks (optimized into register $esi) == 0x410f84ac long unsigned int ret (optimized into register $eax) == 0x2e687400 long unsigned int ret (optimized into register $eax) == 0x2e687400 Wine-dbg>up 2639 return WINPROC_CallWndProc( proc->thunk.t_from16.proc, Wine-dbg>info local CallWindowProcA: long int(*none)()* func == 0x40d31c44 unsigned int hwnd == 0x0006005d unsigned int msg == 0x00000403 unsigned int wParam == 0x00000000 long int lParam == 0x00000000 unsigned int wParam (optimized into register $edi) == 0x00000003 long int lParam (optimized into register $esi) == 0x410f84ac struct tagWINDOWPROC* proc (optimized into register $eax) == 0x2e687400 Wine-dbg>up 922 retval = CallWindowProcA( (WNDPROC)wndPtr->winproc, Wine-dbg>info local DispatchMessageA: struct tagMSG* msg == 0x004920dc struct tagMSG* msg (optimized into register $edi) == 0x00000003 struct tagWND* wndPtr (optimized into register $esi) == 0x410f84ac long int retval == 0x004920a8 int painting == 0x00000000 Wine-dbg> Regards, Lawson ---oof---cut here---- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: wine-devel digest, Vol 1 #445 - 9 msgs
by Robert Lunnon 30 Aug '01

30 Aug '01

Attempt 2 :-) I am trying to get winsock to work under Solaris and need a little help. When connecting, the call to connect doesn't generate a syn packet as expected, The problem appears to be WSOCK32_socket, where the type of socket is passed as type 1 for a tcp service, as it turns out the Solaris header file defines SOCK_STREAM as 2 and SOCK_DGRAM as 1 which makes the subsequent call to connect succeed without establishing a connection because a UDP endpoint was created instead of a tcp one. Now to find out where SOCK_STREAM is getting defined as 1 :-/ I probably need to check the standard function calls between a solaris binary and a windows one so does someone have a simple test program and a unix source (IE windows binary with unix compatible source code) that I can use to compare behaviours between the two environments ? Thanks Bob

2 1

Re: [PATCH] DestroyWindow16
by eric pouech 30 Aug '01

30 Aug '01

Gerard Patel wrote: > > As DestroyWindow does a lot of handle comparaisons, it is necessary > to give it a real 32 bit handle. This avoids a systematic crash when > ForteFreeAgent 16 bit exits. I have not looked for other places where > this can be necessary - but it would not be surprising that this happens. perhaps as an extension of the relay code ? (it would mean typing correctly windows handles in spec files though) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Problems with WM_PAINT and threads
by Ove Kaaven 30 Aug '01

30 Aug '01

After trying to merge Wine 20010824 into WineX, I've encountered a threading issue. A window is created in an app thread: 0806d1f0:Call user32.CreateWindowExA(00000000, 403cb0d4 "Afx:400000:3",0055b674 "3DMark - Display Window", 80000000,00000000,00000000,00000280,000001e0,00000000, 00000000,00400000,00000000) ret=5f40c486 trace:win:WIN_CreateWindowEx "3DMark - Display Window" "Afx:400000:3" 00000000 80000000 0,0 640x480 0000 0000 00400000 (nil) trace:win:WIN_CreateWindowEx winproc type is 2 (WIN_PROC_32A) ... This works fine, until our ddraw update thread somehow decides to send it a message after syncing its own window 31bc: 08107170:Ret x11drv.CreateWindow() retval=00000001 ret=407f542f trace:win:WIN_CreateWindowEx created window 31bc 08107170:Call x11drv.SetWindowPos(44a12e88) ret=407fb159 trace:x11drv:X11DRV_SetWindowPos hwnd 31bc, swp (0,0)-(0,0) flags 0000255b trace:x11drv:X11DRV_SetWindowPos current (0,0)-(800,600), style 84000000 warn:x11drv:SWP_DoOwnedPopups (31bc) hInsertAfter = 0000 trace:x11drv:X11DRV_sync_whole_window_position setting win 3200001 pos 0,0,800x600 after 8081268 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 31bc trace:x11drv:X11DRV_SetWindowPos status flags = 1843 08107170:Ret x11drv.SetWindowPos() retval=00000001 ret=407fb159 trace:win:RedrawWindow 31bc (0000) NULL 0,0-0,0 0000 flags=0180 trace:win:RDW_UpdateRgns hwnd 31bc [0000] -> hrgn [0000], flags [0180] trace:win:RDW_Paint hwnd 31bc [0000] -> hrgn [0000], flags [0180] 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000002,44a12da4,ffffffff,000000ff,00000000) ret=407e4237 trace:x11drv:X11DRV_Expose win 31bc (3200002) 0,0 800x600 trace:win:RedrawWindow 31bc (0000) rect 0,0-800,600 0000 flags=0005 trace:win:RDW_UpdateRgns hwnd 31bc [174a] -> hrgn [0000], flags [0005] trace:win:RDW_Paint hwnd 31bc [174a] -> hrgn [0000], flags [0005] 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000002 ret=407e4237 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=407a1ca4 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=407a1ca4 trace:msg:MSG_peek_message got type 5 msg f hwnd 0 wp 0 lp 0 trace:win:WIN_FindWinToRepaint found 3124 trace:win:RedrawWindow 3124 (1746) NULL 0,0-0,0 0000 flags=0050 trace:win:RDW_UpdateRgns hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:message:SPY_EnterMessage (00003124) "3DMark - D..." message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 08107170:Call window proc 0x5f4019fa (hwnd=00003124,msg=WM_PAINT,wp=00000000,lp=00000000) ^^^^^^^^ ^^^^^^^^ After Wine dispatches this WM_PAINT message from the wrong thread, 3DMark2000 fails to locate its thread-local data, gets confused, and crashes. Maybe Alexandre did a mistake somewhere in his restructures?

1 0

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