November 2006 - Wine-Devel - list.winehq.org

mscoree: change WCHAR version[ ] in GetCORVersion to prevent a crash

by Louis. Lenders

> >This will break the Acid Pro Media installer. It specifically checks >for the first value. I'm guessing your installer specifically checks >for the second value. I don't have a proper solution, just letting >you know that another installer will break. -- >James Hawkins Looks like it needs more testing then. will have another look later. Regards --------------------------------- Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal

Nov. 3, 2006

ntdll: Add a stub implementation for RtlDllShutdownInProgress

by Louis. Lenders

a little test shows it returns some unknown status on my xp lap[top: 0x7c927f00, so likely not STATUS_SUCCESS. diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c index 59871de..588e33e 100644 --- a/dlls/ntdll/tests/rtl.c +++ b/dlls/ntdll/tests/rtl.c @@ -66,6 +66,7 @@ static RTL_HANDLE * (WINAPI * pRtlAlloca static BOOLEAN (WINAPI * pRtlFreeHandle)(RTL_HANDLE_TABLE *, RTL_HANDLE *); static NTSTATUS (WINAPI *pRtlAllocateAndInitializeSid)(PSID_IDENTIFIER_AUTHORITY,BYTE,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,PSID*); static NTSTATUS (WINAPI *pRtlFreeSid)(PSID); +static NTSTATUS (WINAPI *pRtlDllShutdownInProgress)(void); #define LEN 16 static const char* src_src = "This is a test!"; /* 16 bytes long, incl NUL */ static ULONG src_aligned_block[4]; @@ -97,6 +98,7 @@ static void InitFunctionPtrs(void) pRtlFreeHandle = (void *)GetProcAddress(hntdll, "RtlFreeHandle"); pRtlAllocateAndInitializeSid = (void *)GetProcAddress(hntdll, "RtlAllocateAndInitializeSid"); pRtlFreeSid = (void *)GetProcAddress(hntdll, "RtlFreeSid"); + pRtlDllShutdownInProgress = (void *)GetProcAddress(hntdll, "RtlDllShutdownInProgress"); } strcpy((char*)src_aligned_block, src_src); ok(strlen(src) == 15, "Source must be 16 bytes long!\n"); @@ -848,6 +850,13 @@ static void test_RtlComputeCrc32(void) ok(crc == 0x40861dc2,"Expected 0x40861dc2, got %8x\n", crc); } +static void test_RtlDllShutdownInProgress(void) +{ + DWORD ret; + + ret = pRtlDllShutdownInProgress(); + ok(0x7c927f00 == ret,"Expected 0x7c927f00, got %08x\n", ret); +} typedef struct MY_HANDLE { @@ -933,4 +942,6 @@ START_TEST(rtl) test_HandleTables(); if (pRtlAllocateAndInitializeSid) test_RtlAllocateAndInitializeSid(); + if (pRtlDllShutdownInProgress) + test_RtlDllShutdownInProgress(); } Send instant messages to your online friends http://uk.messenger.yahoo.com

Nov. 3, 2006

Re: Tracking memory allocation

by Jeff L

Robert Shearman wrote: > Yes, it does. You can look at dlls/ntdll/tests/rtl.c to see how the > functions can be used. Looking at the tests as example it seems that you need to run InitFunctionPtrs() to set up pointers to the functions. I would want to do this in DllMain() as part of DLL_PROCESS_ATTACH: so the static pointers could be set up once however you can't issue a LoadLibraryA() inside DllMain(). The only other way to initialise the function pointers appears to be to use an Initialise routine that is called as part of any routine that may use the Table functions. I assume that it will be the latter option that I need to pursue. Is this the only way to access the Table functions? Jeff Latimer

Nov. 3, 2006

Re: configure.ac: Turn off the stack protector for the preloader. (resend)

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > --- > configure.ac | 14 ++++++++++++++ > loader/Makefile.in | 1 + > 2 files changed, 15 insertions(+), 0 deletions(-) It's better to fix the preloader to setup the proper environment, like we already do for some other variants of that problem. -- Alexandre Julliard julliard(a)winehq.org

Nov. 3, 2006

Re: shlexec: buffer work

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + len = ExpandEnvironmentStringsW(sei_tmp.lpFile, NULL, 0); > + if (len>0) > + { > + LPWSTR buf; > + buf = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); > + > + ExpandEnvironmentStringsW(sei_tmp.lpFile, buf, len+1); > + HeapFree(GetProcessHeap(), 0, wszApplicationName); > + dwApplicationNameLen = len+1; > + wszApplicationName = buf; > + > + sei_tmp.lpFile = wszApplicationName; > + } The indentation is all messed up, please fix your editor settings. -- Alexandre Julliard julliard(a)winehq.org

Nov. 3, 2006

Re: Patch for opengl32.dll.so

by Christoph Frick

On Thu, Nov 02, 2006 at 05:46:07PM +0100, Christoph Frick wrote: > > Hmm, if that is indeed the case this patch could work for them. The > > whole issue is new for me, I'll see what I can do about it. Right now > > there's some GLX code in opengl32 which creates an opengl context. I > > was planning to replace it with WGL code, that might help too (if I > > load the function pointers afterwards). Perhaps Alexandre has an idea > > how to correctly fight the race condition. > just for the files: the glGetIntegerv is also the last thing that the > java stacktrace of IL2 shows up. i will try this patch against all the > games, that are no longer working on my end. one of the patches from 2006-10-31 fixed my problems as it seems. IL2 now crashed out 1 of 4 starts but with another error. the remaining stuff is fine - although NASCAR 2003 is very slow now. -- cu

Nov. 3, 2006

Re: ntdll: Add a stub implementation for RtlDllShutdownInProgress.

by Mike McCormack

Robert Shearman wrote: >> +NTSTATUS WINAPI RtlDllShutdownInProgress(void) > For undocumented functions like this, you should add a test case. That's unreasonable. A stub isn't meant to work correctly, just stop an application from crashing. What will a test case prove? Mike

Nov. 3, 2006

Re: winex11.drv: Bug#6501. XIM problem with XInitThreads().

by Dmitry Timoshkov

"Byeong-Sik Jeon" <wjsqudtlr(a)gmail.com> wrote: > http://www.winehq.org/pipermail/wine-cvs/2006-October/026680.html >> winex11.drv: Give XInitThreads another chance. >> >> --- >> >> dlls/winex11.drv/x11drv_main.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c >> index 0403b5d..95f9d10 100644 >> --- a/dlls/winex11.drv/x11drv_main.c >> +++ b/dlls/winex11.drv/x11drv_main.c >> @@ -383,6 +383,8 @@ static BOOL process_attach(void) >> >> /* Open display */ >> >> + if (!XInitThreads()) ERR( "XInitThreads failed, trouble ahead\n" ); >> + >> if (!(display = XOpenDisplay( NULL ))) return FALSE; >> > Hi, > > This patch makes the Bug #6501. Also Korean XIM(nabi, scim) have the > same problem. > > Please fix this problem. My impression is that it's an X11 bug, not a Wine one. So a proper place to send such a request is most likely the Xorg bug tracker. -- Dmitry.

Nov. 3, 2006

winex11.drv: Bug#6501. XIM problem with XInitThreads().

by Byeong-Sik Jeon

http://www.winehq.org/pipermail/wine-cvs/2006-October/026680.html > winex11.drv: Give XInitThreads another chance. > > --- > > dlls/winex11.drv/x11drv_main.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c > index 0403b5d..95f9d10 100644 > --- a/dlls/winex11.drv/x11drv_main.c > +++ b/dlls/winex11.drv/x11drv_main.c > @@ -383,6 +383,8 @@ static BOOL process_attach(void) > > /* Open display */ > > + if (!XInitThreads()) ERR( "XInitThreads failed, trouble ahead\n" ); > + > if (!(display = XOpenDisplay( NULL ))) return FALSE; > Hi, This patch makes the Bug #6501. Also Korean XIM(nabi, scim) have the same problem. Please fix this problem.

Nov. 3, 2006

Re: winhlp32 implementation

by Frank Richter

On 02.11.2006 22:04, Eric Pouech wrote: > Kirill K. Smirnov wrote: > >> Eric, >> there is a mess in winhelp and winhlp32 in "Context" and "Topic" concept: >> what winhelp calls "topic", winhlp32 calls "context", and what winhelp >> calls "Context" winhlp32 calls "Topic without CNT section". >> So, the buttons are messed too. >> >> I suspect there are other "features". >> >> We couldn't implement winhlp32 and winhelp in one box. >> >> > well, this still could be possible, even if it's a bit more complex to > handle > IMO, the differences are, in most of the cases, cosmetics (name of > buttons, positions of menu), but also in MS way, new features only in > winhlp32 > so I was calling for a unified tool that would be doing what the two > original programs were doing, even if the user interface doesn't match > everything perfectly FWIW, winhelp.exe is a 16-bit executable in Win XP. If I had to guess why, I'd say it's for compatibility: iirc you can call DLL functions from help files; so the 16-bit winhelp is kept to allow 16-bit .hlp files using DLLs to continue to work. -f.r.

Nov. 2, 2006