March 2003 - Wine-devel - list.winehq.org

Re: wine/controls scroll.c
by Eric Pouech 23 Mar '03

23 Mar '03

Alexandre Julliard wrote: > ChangeSet ID: 7402 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/03/07 14:38:20 > > Modified files: > controls : scroll.c > > Log message: > Andrew Johnston <johnstonam(a)logica.com> > - GetScrollRange zeros the return parameters for no infoPtr > - GetScrollRange, GetScrollPos and GetScrollInfo send a message to the > window for the SB_CTL case > - Moved code for GetScroll* to into worker functions > @@ -1736,22 +1804,18 @@ > * RETURNS STD > */ > BOOL WINAPI GetScrollRange( > -HWND hwnd, /* [in] Handle of window */ > -INT nBar, /* [in] One of SB_HORZ, SB_VERT, or SB_CTL */ > -LPINT lpMin, /* [out] Where to store minimum value */ > +HWND hwnd /* [in] Handle of window with scrollbar(s) */, > +INT nBar /* [in] One of SB_HORZ, SB_VERT, or SB_CTL */, > +LPINT lpMin /* [out] Where to store minimum value */, > LPINT lpMax /* [out] Where to store maximum value */) > { > - SCROLLBAR_INFO *infoPtr; > + TRACE("hwnd=%p nBar=%d lpMin=%p lpMax=%p\n", hwnd, nBar, lpMin, lpMax); > > - if (!(infoPtr = SCROLL_GetScrollInfo( hwnd, nBar ))) > - { > - if (lpMin) lpMin = 0; > - if (lpMax) lpMax = 0; > - return FALSE; > - } > - if (lpMin) *lpMin = infoPtr->minVal; > - if (lpMax) *lpMax = infoPtr->maxVal; > - return TRUE; > + /* Refer SB_CTL requests to the window */ > + if (nBar == SB_CTL) > + return SendMessageA(hwnd, SBM_GETRANGE, (WPARAM)lpMin, (LPARAM)lpMax); > + else > + return SCROLL_GetScrollRange(hwnd, nBar, lpMin, lpMax); > } This patch is wrong the hwnd is in fact a 16 bit window I've an old win16 app which got broken because of this (wParam got truncated to a 16 bit value, and of course caused a segfault) A+ -- Eric Pouech

1 0

Re: LockFile() and UnlockFile() are working
by John K. Hohm 23 Mar '03

23 Mar '03

> This resolution will make a ton of business apps based on desktop database > software that much closer to working. I'm not so sure. I expect most database software depends on the mandatory nature of LockFile(), i.e. that a ReadFile() or WriteFile() from another process on a locked region fails with ERROR_LOCK_VIOLATION. Typically, one process will LockFile() an area, then update on-disk structures in such a way that another process reading during the update would get confused were it not for ReadFile() refusing to read the locked bytes. Note that the reading process does not LockFile() to read, it just tries ReadFile() and handles its failure (typically by waiting and trying again later). For database software that uses read/write locks via LockFileEx(), the standard Unix advisory lock semantics are just fine, and those patches are indeed the ticket. However, advisory locking is generally more difficult to manage, and LockFileEx() is not supported on Windows 95/98/Me, so I doubt many apps use it. >From what I can tell, mandatory locking on Linux involves tricks like using a special mount option, and setting the SGID bit of the file to be locked before the locking process starts; I'm not sure which other Unixen even support it.

6 15

Error uninstalling InstallShield 6 application
by Uwe Bonnes 22 Mar '03

22 Mar '03

Hello, running the uninstaller of some application with builtin DLLs, the uninstall fails with a messagebox telling about a 80004005 error. Is following log usefull? Running with --dll ole32,oleaut32,rpcrt4=n succeeds with the deinstallation. Thanks 0019:Call kernel32.ReadFile(0000005c,4294fbe0,000000fa,41ec2eac,00000000) ret=40aaa70a 0019:Ret kernel32.ReadFile() retval=00000001 ret=40aaa70a trace:ole:TMStubImpl_Invoke ... trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 0 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 1 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 2 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 3 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 4 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 5 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 6 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 7 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 8 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 9 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 10 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 11 trace:ole:ITypeInfo_fnGetFuncDesc (0x4277c398) index 12 trace:ole:ITypeInfo_fnGetNames (0x4277c398) memid=0x0000001f Maxname=10 0019:Call kernel32.lstrlenW(4273aad4 L"Create") ret=40b8acc0 0019:Ret kernel32.lstrlenW() retval=00000006 ret=40b8acc0 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,00000012) ret=40b8ad3d 0019:Ret ntdll.RtlAllocateHeap() retval=428a1008 ret=40b8ad3d 0019:Call kernel32.lstrlenW(4273ab5c L"hWnd") ret=40b8acc0 0019:Ret kernel32.lstrlenW() retval=00000004 ret=40b8acc0 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,0000000e) ret=40b8ad3d 0019:Ret ntdll.RtlAllocateHeap() retval=4294f480 ret=40b8ad3d 0019:Call kernel32.lstrlenW(4273aba4 L"BmpResourceFile") ret=40b8acc0 0019:Ret kernel32.lstrlenW() retval=0000000f ret=40b8acc0 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,00000024) ret=40b8ad3d 0019:Ret ntdll.RtlAllocateHeap() retval=4294fce8 ret=40b8ad3d 0019:Call kernel32.lstrlenW(4273abd4 L"BmpResourceID") ret=40b8acc0 0019:Ret kernel32.lstrlenW() retval=0000000d ret=40b8acc0 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,00000020) ret=40b8ad3d 0019:Ret ntdll.RtlAllocateHeap() retval=4294fd18 ret=40b8ad3d 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,00000010) ret=40b98062 0019:Ret ntdll.RtlAllocateHeap() retval=4294fd40 ret=40b98062 0019:Call kernel32.IsBadStringPtrW(4294f484,00000001) ret=40b984cf 0019:Ret kernel32.IsBadStringPtrW() retval=00000000 ret=40b984cf 0019:Call kernel32.lstrcmpW(4294f484 L"hWnd",40bb4550 L"riid") ret=40b984eb 0019:Ret kernel32.lstrcmpW() retval=fffffff6 ret=40b984eb 0019:Call kernel32.lstrcmpW(4294f484 L"hWnd",40bb455a L"pdispparams") ret=40b9850c 0019:Ret kernel32.lstrcmpW() retval=fffffff8 ret=40b9850c 0019:Call kernel32.lstrcmpW(4294f484 L"hWnd",40bb4572 L"ppvObject") ret=40b9855e 0019:Ret kernel32.lstrcmpW() retval=fffffff8 ret=40b9855e trace:ole:deserialize_param vt 3 at 0x4294fd44 0019:Call kernel32.IsBadStringPtrW(4294fcec,00000001) ret=40b984cf 0019:Ret kernel32.IsBadStringPtrW() retval=00000000 ret=40b984cf 0019:Call kernel32.lstrcmpW(4294fcec L"BmpResourceFile",40bb4550 L"riid") ret=40b984eb 0019:Ret kernel32.lstrcmpW() retval=ffffffd0 ret=40b984eb 0019:Call kernel32.lstrcmpW(4294fcec L"BmpResourceFile",40bb455a L"pdispparams") ret=40b9850c 0019:Ret kernel32.lstrcmpW() retval=ffffffd2 ret=40b9850c 0019:Call kernel32.lstrcmpW(4294fcec L"BmpResourceFile",40bb4572 L"ppvObject") ret=40b9855e 0019:Ret kernel32.lstrcmpW() retval=ffffffd2 ret=40b9855e trace:ole:deserialize_param vt 8 at 0x4294fd48 0019:Call ntdll.RtlAllocateHeap(40360000,00000008,000000f0) ret=40b960c1 0019:Ret ntdll.RtlAllocateHeap() retval=4294fd60 ret=40b960c1 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,000001e2) ret=40b8ad3d 0019:Ret ntdll.RtlAllocateHeap() retval=4294fe58 ret=40b8ad3d 0019:Call ntdll.RtlFreeHeap(40360000,00000000,4294fd60) ret=40b96119 0019:Ret ntdll.RtlFreeHeap() retval=00000001 ret=40b96119 0019:Call kernel32.IsBadStringPtrW(4294fd1c,00000001) ret=40b984cf 0019:Ret kernel32.IsBadStringPtrW() retval=00000000 ret=40b984cf 0019:Call kernel32.lstrcmpW(4294fd1c L"BmpResourceID",40bb4550 L"riid") ret=40b984eb 0019:Ret kernel32.lstrcmpW() retval=ffffffd0 ret=40b984eb 0019:Call kernel32.lstrcmpW(4294fd1c L"BmpResourceID",40bb455a L"pdispparams") ret=40b9850c 0019:Ret kernel32.lstrcmpW() retval=ffffffd2 ret=40b9850c 0019:Call kernel32.lstrcmpW(4294fd1c L"BmpResourceID",40bb4572 L"ppvObject") ret=40b9855e 0019:Ret kernel32.lstrcmpW() retval=ffffffd2 ret=40b9855e trace:ole:deserialize_param vt 3 at 0x4294fd4c Calling 0x4261b0ea(43751cb0,00010020,4294fe5c,00002841,) 0019:Call kernel32.GetLastError() ret=42614f6b 0019:Ret kernel32.GetLastError() retval=00000057 ret=42614f6b 0019:Call oleaut32.SysAllocStringLen(00000000,00000021) ret=42611e32 0019:Call ntdll.RtlAllocateHeap(40360000,00000000,00000048) ret=40b8ad3d 0019:Ret ntdll.RtlAllocateHeap() retval=42950048 ret=40b8ad3d 0019:Ret oleaut32.SysAllocStringLen() retval=4295004c ret=42611e32 0019:Call kernel32.SetLastError(00000057) ret=42614fc0 0019:Ret kernel32.SetLastError() retval=00000057 ret=42614fc0 0019:Call kernel32.WideCharToMultiByte(00000000,00000000,4295004e L"D:\\WINDOWS\\TEMP\\",00000011,00000000,00000000,00000000,00000000) ret=42614533 0019:Ret kernel32.WideCharToMultiByte() retval=00000011 ret=42614533 0019:Call kernel32.WideCharToMultiByte(00000000,00000000,4295004e L"D:\\WINDOWS\\TEMP\\",00000011,43751b80,00000040,00000000,00000000) ret=4261457a 0019:Ret kernel32.WideCharToMultiByte() retval=00000011 ret=4261457a 0019:Call kernel32.LoadLibraryA(43751b80 "D:\\WINDOWS\\TEMP\\") ret=4261b11e 0019:Ret kernel32.LoadLibraryA() retval=00000000 ret=4261b11e 0019:Call kernel32.GetLastError() ret=42611453 0019:Ret kernel32.GetLastError() retval=0000054f ret=42611453 0019:Call oleaut32.SysFreeString(00000000) ret=42611471 0019:Ret oleaut32.SysFreeString() retval=00000000 ret=42611471 0019:Call oleaut32.SysFreeString(4295004c L"") ret=42611d6b 0019:Call ntdll.RtlFreeHeap(40360000,00000000,42950048) ret=40b8acfd 0019:Ret ntdll.RtlFreeHeap() retval=00000001 ret=40b8acfd 0019:Ret oleaut32.SysFreeString() retval=00000001 ret=42611d6b 0019:Call kernel32.SetLastError(0000054f) ret=42611491 0019:Ret kernel32.SetLastError() retval=0000054f ret=42611491 trace:ole:_invoke returns 80004005 0019:Call kernel32.IsBadStringPtrW(4294f484,00000001) ret=40b98350 0019:Ret kernel32.IsBadStringPtrW() retval=00000000 ret=40b98350 0019:Call kernel32.lstrcmpW(4294f484 L"hWnd",40bb4550 L"riid") ret=40b9836c 0019:Ret kernel32.lstrcmpW() retval=fffffff6 ret=40b9836c 0019:Call kernel32.lstrcmpW(4294f484 L"hWnd",40bb455a L"pdispparams") ret=40b9838d 0019:Ret kernel32.lstrcmpW() retval=fffffff8 ret=40b9838d 0019:Call kernel32.lstrcmpW(4294f484 L"hWnd",40bb4572 L"ppvObject") ret=40b983a5 0019:Ret kernel32.lstrcmpW() retval=fffffff8 ret=40b983a5 trace:ole:serialize_param (tdesc.vt 3) -- 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

Regression in latest CVS
by Vitaliy Margolen 22 Mar '03

22 Mar '03

I have a problem with latest CVS in the past several days. Every app locking up. Any suggestions where should I look. It's not a dead loop. Something happening, according to trace. Here is the trace where I think the problem starts: 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=0040f8d5 0009:Call user32.IsWindowVisible(00010021) ret=00444671 0009:Call kernel32._EnterSysLevel(4071cc58) ret=406c6793 0009:trace:win32:_EnterSysLevel (0x4071cc58, level 2): thread 9 (fs 008f, pid 2321) count before 0 0009:trace:win32:_EnterSysLevel (0x4071cc58, level 2): thread 9 (fs 008f, pid 2321) count after 1 0009:Ret kernel32._EnterSysLevel() retval=400d9d20 ret=406c6793 0009:Call kernel32._LeaveSysLevel(4071cc58) ret=406c67b3 0009:trace:win32:_LeaveSysLevel (0x4071cc58, level 2): thread 9 (fs 008f, pid 2321) count before 1 0009:trace:win32:_LeaveSysLevel (0x4071cc58, level 2): thread 9 (fs 008f, pid 2321) count after 0 0009:Ret kernel32._LeaveSysLevel() retval=00000063 ret=406c67b3 0009:Ret user32.IsWindowVisible() retval=00000000 ret=00444671 0009:Call ntdll.RtlEnterCriticalSection(41370830) ret=0040b6c4 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=0040b6c4 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40eeb2 0009:trace:seh:EXC_RtlRaiseException info[0]=00000000 0009:trace:seh:EXC_RtlRaiseException info[1]=0000000c 0009: queue_exception_event( first=1, record={context={flags=00000000,eax=00000000,ebx=00457bec,ecx=400f8600,edx=400f2c30,esi=413710cc,edi=00457bec,ebp=40592d04,eip=0040eeb2,esp=40592ce4,eflags=00010246,cs=0023,ds=002b,es=002b,fs=008f,gs=004f,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x40eeb2,params={0,c}} ) 0009: queue_exception_event() = 0 { handle=(nil) } 0009:trace:seh:EXC_CallHandler calling handler at 0x40f106 code=c0000005 flags=0 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x43cfa8 code=c0000005 flags=0 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x43cfe0 code=c0000005 flags=0 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x43d000 code=c0000005 flags=0 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x402ffd code=c0000005 flags=0 0009:Call user32.LoadStringA(00400000,0000ffd0,40480334,00000400) ret=00405712 0009:trace:resource:LoadStringA instance = 0x400000, id = ffd0, buffer = 40480334, length = 1024 0009:Call ntdll.RtlAllocateHeap(40240000,00000000,00000800) ret=406e9eb6 0009:trace:heap:RtlAllocateHeap (0x40240000,00000002,00000800): returning 4027d068 0009:Ret ntdll.RtlAllocateHeap() retval=4027d068 ret=406e9eb6 0009:trace:resource:LoadStringW instance = 0x400000, id = ffd0, buffer = 4027d068, length = 1024 0009:Call kernel32.FindResourceW(00400000,00000ffe,00000006) ret=406e9d4d 0009:trace:resource:RES_FindResource2 (0x400000, 00000006, 00000ffe, 0000, W, PE) 0009:Ret kernel32.FindResourceW() retval=00468998 ret=406e9d4d 0009:Call kernel32.LoadResource(00400000,00468998) ret=406e9d5c 0009:trace:resource:RES_LoadResource (0x400000, 0x468998, PE) 0009:Ret kernel32.LoadResource() retval=0046c6f0 ret=406e9d5c 0009:Call kernel32.LockResource(0046c6f0) ret=406e9d6a 0009:trace:resource:LockResource (0x46c6f0) 0009:Ret kernel32.LockResource() retval=0046c6f0 ret=406e9d6a 0009:trace:resource:LoadStringW strlen = 4 0009:trace:resource:LoadStringW L"Read" loaded ! 0009:Call kernel32.WideCharToMultiByte(00000000,00000000,4027d068 L"Read",00000004,40480334,000003ff,00000000,00000000) ret=406e9eee 0009:Ret kernel32.WideCharToMultiByte() retval=00000004 ret=406e9eee 0009:trace:resource:LoadStringA "Read" loaded ! 0009:Call ntdll.RtlFreeHeap(40240000,00000000,4027d068) ret=406e9f43 0009:trace:heap:RtlFreeHeap (0x40240000,00000002,4027d068): returning TRUE 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=406e9f43 0009:Ret user32.LoadStringA() retval=00000004 ret=00405712 0009:Call kernel32.VirtualQuery(0040eeb2,404808a4,0000001c) ret=0040a8c0 0009:Ret kernel32.VirtualQuery() retval=0000001c ret=0040a8c0 0009:Call kernel32.GetModuleFileNameA(00400000,4048079f,00000105) ret=0040a8e2 0009:trace:heap:RtlAllocateHeap (0x40240000,00000002,00000210): returning 4027d068 0009:trace:string:lstrcpynW (0x4027d068, L"F:\\wine\\Virtual_Listview\\virtuallistview.exe", 261) 0009:trace:module:GetModuleFileNameW L"F:\\wine\\Virtual_Listview\\virtuallistview.exe" 0009:trace:heap:RtlFreeHeap (0x40240000,00000002,4027d068): returning TRUE 0009:Ret kernel32.GetModuleFileNameA() retval=0000002c ret=0040a8e2 0009:Call user32.LoadStringA(00400000,0000ffdb,4048032c,00000400) ret=00405712 0009:trace:resource:LoadStringA instance = 0x400000, id = ffdb, buffer = 4048032c, length = 1024 0009:Call ntdll.RtlAllocateHeap(40240000,00000000,00000800) ret=406e9eb6 0009:trace:heap:RtlAllocateHeap (0x40240000,00000002,00000800): returning 4027d068 0009:Ret ntdll.RtlAllocateHeap() retval=4027d068 ret=406e9eb6 0009:trace:resource:LoadStringW instance = 0x400000, id = ffdb, buffer = 4027d068, length = 1024 0009:Call kernel32.FindResourceW(00400000,00000ffe,00000006) ret=406e9d4d 0009:trace:resource:RES_FindResource2 (0x400000, 00000006, 00000ffe, 0000, W, PE) 0009:Ret kernel32.FindResourceW() retval=00468998 ret=406e9d4d 0009:Call kernel32.LoadResource(00400000,00468998) ret=406e9d5c 0009:trace:resource:RES_LoadResource (0x400000, 0x468998, PE) 0009:Ret kernel32.LoadResource() retval=0046c6f0 ret=406e9d5c 0009:Call kernel32.LockResource(0046c6f0) ret=406e9d6a 0009:trace:resource:LockResource (0x46c6f0) 0009:Ret kernel32.LockResource() retval=0046c6f0 ret=406e9d6a 0009:trace:resource:LoadStringW strlen = 63 0009:trace:resource:LoadStringW L"Access violation at address %p in module '%s'. %s of address %p" loaded ! 0009:Call kernel32.WideCharToMultiByte(00000000,00000000,4027d068 L"Access violation at address %p in module '%s'. %s of address %p",0000003f,4048032c,000003ff,00000000,00000000) ret=406e9eee 0009:Ret kernel32.WideCharToMultiByte() retval=0000003f ret=406e9eee 0009:trace:resource:LoadStringA "Access violation at address %p in module '%s'. %s of address %p" loaded ! 0009:Call ntdll.RtlFreeHeap(40240000,00000000,4027d068) ret=406e9f43 0009:trace:heap:RtlFreeHeap (0x40240000,00000002,4027d068): returning TRUE 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=406e9f43 0009:Ret user32.LoadStringA() retval=0000003f ret=00405712 0009:Call ntdll.RtlUnwind(40592d30,00403217,404809c8,00000000) ret=00403217 fs=008f eax=404809c8 ebx=4048090c ecx=0040eeb2 edx=40592d30 esi=404809c8 edi=400dbcc1 ebp=40480928 esp=404808d8 ds=002b es=002b gs=0000 flags=00000246 0009:trace:seh:EXC_RtlUnwind code=c0000005 flags=2

4 7

Re: WineHQ redesign - TODO
by Brian Vincent (C) 22 Mar '03

22 Mar '03

> Also, I am serious about the "Latest News" box. We need an agreement -- > what about a patch implementing the idea, so people can have a more > informed opinion? Here's my $.02: I think the "Wine Weekly News" heading on the right should just be changed to "News". Instead of something like "Issue: 162" maybe it should say something like "Wine Weekly News #162". Interspersed with the WWN issues can be other news, for example the interviews that will start going up next week. Over time I'm sure there will be things of interest to add there. As far as the News section that goes into WWN, I don't think it's appropriate to break those items out into their own announcements. For one thing, the same XML goes to www.kerneltraffic.org and I'm going to continue having the first section be News. The bigger problem is announcing commercial development projects. I'm sure we'd all agree that TransGaming and CodeWeavers announcements would be fine to add, but there's a lot of gray area outside of that. For example, Lindows.com had (has) a press release about once a week. They made it into quite a few WWN issues before I stopped covering them. Splashing press releases on the front page doesn't necessarily make it news. I'll still have most of that stuff in the WWN anyway. So.. my vote is for a general "News" box that will mostly end up containing WWN issues, the interview series that's going to stretch through summer, and any other items that are non-commercial (updates to the status page, etc). Maybe if we could get people using the app DB we could put a news heading like "How to Install IE 5.5" and link to instructions in the app DB. PS. I love the "got Wine?" banner -brian

2 1

LockFile() and UnlockFile() are working
by Paul McNett 22 Mar '03

22 Mar '03

As of yesterday, 3/18/2003, LockFile() and UnlockFile() are now implemented, and seem to be working perfectly on my end, testing with the Visual FoxPro native functions of flock(), rlock(), and unlock(). This resolution will make a ton of business apps based on desktop database software that much closer to working. Thanks Alexandre for slipping that one in to the 20030318 release! :) -- Paul McNett - p(a)ulmcnett.com Hollister, California, USA

6 8

Re: winehq/ images/winehq_border_top_left.gif imag ...
by Dimitrie O. Paun 21 Mar '03

21 Mar '03

On Fri, 21 Mar 2003, Jeremy Newman wrote: > the corners no longer freak out when you use zoom. Your welcome Dimi! Thank YOU! -- Dimi.

1 0

Wine and glibc 3.2.x
by Davide Giannotti 21 Mar '03

21 Mar '03

Ok, i recently compiled and upgraded to glibc 3.2.1 and there's no way to make wine work. There's thread related bug. New Red Hat, Suse and Mandrake will be shipped with this new version of glibc, so i think that's a serious bug. (See also http://www.winehq.com/hypermail/wine-devel/2003/03/0570.html) Configure cannot even check that libc are reentrant, i'm not a glibc expert but there's some error with _errno and _errno_location. I tried to apply a patch i found in the patch mailing list, but it didn't work either. ( http://www.winehq.com/hypermail/wine-patches/2003/01/0338.html ) So, consider that every linux distribution will be shipped with the new glibc, and that there will be really a few windows programs that can work without thread support.... well... i'd think about give priority to solve this one. If anybody found a workaround or wrote some patches... please let me now. For now, i'll not downgrade my libc for sure. I'm without wine. Thank you all, guys. Davide

1 0

patch: macros changed to inline functions (msvcrt headers)
by madhura sahasrabudhe 21 Mar '03

21 Mar '03

Hi, I have changed the macros in the msvcrt headers to static inline functions. The modified files are: conio.h, ctype.h, direct.h, malloc.h, process.h, search.h, stdio.h, stdlib.h and string.h (in the include/msvcrt directory). I have attached a patch for the same. Thank you. Madhura Sahasrabudhe >Re: Middleware regression test suites, e.g. ACE >From: Dimitrie O. Paun (dpaun(a)rogers.com) >Date: Thu Feb 27 2003 - 07:49:55 CST >-------------------------------------------------------------------------------- >>On February 25, 2003 02:08 pm, Dan Kegel wrote: >> ACE is a set of object-oriented >> wrappers around operating system primitives, >> See http://www.cs.wustl.edu/~schmidt/ACE.html >A perfect test for my winegcc/wineg++ stuff, and >for our C++ Winelib support! I've tried a little >bit, it breaks badly because we use lots of macros >in the msvcrt headers and the code expects functions >(which, unlike macros, respect scope). I've signaled >this problem before, and I've send a patch for >include/msvcrt/io.h transforming those macros into >inline functions, but a lot more is left to do. >That is to say, all things from include/msvcrt/* of the form: >#define isascii __isascii >must become: >static inline int isascii(int c) { return __isascii(c); } >Any takers? :) >-- >Dimi.

1 0

glibc 2.3
by Kevin DeKorte 21 Mar '03

21 Mar '03

Hello, I was just wondering if there was a fix for the glibc 2.3 problem. I recently did an up2date of my RedHat 8.0 box and RedHat shipped me a glibc 2.3 and now wine does not work. glibc-2.3.2-4.80 kernel-2.4.18-24.8.0 I tried both of these from info gathered from google export LD_PRELOAD=~/bin/q.so and export LD_ASSUME_KERNEL=2.2.5 > wine nlnotes.exe fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x1161a90,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoRegisterMessageFilter stub FIXME:pthread_cond_init fixme:console:SetConsoleCtrlHandler (0x1161a90,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet Any help would be appreciated. Kevin

2 2