December 2005 - Wine-Devel - list.winehq.org

Re: vbrun60sp6.exe doesn't work in Wine

by Dan Kegel

On 12/18/05, Dan Kegel <dank(a)kegel.com> wrote: > Wine-0.9.3 can install vbrun60sp5.exe and earlier just fine, > but for some reason vbrun6sp6.exe silently exits without > installing anything. Anyone know why? You can download it > from http://support.microsoft.com/default.aspx?scid=kb;en-us;290887 Bug filed: http://bugs.winehq.org/show_bug.cgi?id=4098 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 19, 2005

vbrun60sp6.exe doesn't work in Wine

by Dan Kegel

Wine-0.9.3 can install vbrun60sp5.exe and earlier just fine, but for some reason vbrun6sp6.exe silently exits without installing anything. Anyone know why? You can download it from http://support.microsoft.com/default.aspx?scid=kb;en-us;290887 -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 19, 2005

ReactOS has game I see......

by Tom Wickline

Hello, http://vogons.zetafleet.com/viewtopic.php?t=10750 :D Cheers, Tom

Dec. 19, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Paul Millar

Hi, Just a quick email to say Hans' patch on it own fails for me too. His patch with Robert's addition works fine. On Sunday 18 Dec 2005 14:56, Hans Leidekker wrote: > On Sunday 18 December 2005 15:13, Robert Reif wrote: > > Adding this fixes it for me but you may need to check for > > ldap_parse_reference also. > > Yes, strictly speaking we should check all 4 reference handling > functions that are absent from your libldap_r, but I'd rather keep > the configure checks to an absolute minimum. Since these functions > are related I doubt that there are versions of libldap_r around > where less than 4 of them are missing. And when that happens we > can deal with it ;-) Agreed. Cheers, Paul.

Dec. 19, 2005

Page fault: completely lost while debugging

by Sergio

Hi all, I am having one problem with one project I have just made compile. It's one of the plugins of the windows' multiprotocol IM program, Miranda. I will try to explain what my problem is. After solving some issues with compilation (mainly some undefined names - functions - in std namespace - it's a C++ project), I tried to run the application and when asking the plugin to connect to one IRC server (it is the application's IRC protocol plugin) it crashes with this error: Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x41d551de). In 32 bit mode. fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for irc<elf> Register dump: CS:0073 SS:007b DS:007b ES:007b FS:174f GS:0033 EIP:41d551de ESP:43510adc EBP:43510af8 EFLAGS:00210206( - 00 - RIP1) EAX:00000004 EBX:41db6434 ECX:00000000 EDX:7c0cbe30 ESI:00000000 EDI:41c14f10 Stack dump: 0x43510adc: 41d5514e 01000000 4f4d2e6c 41db6434 0x43510aec: 7c126a38 4017c0d4 41db6434 43510b28 0x43510afc: 41d9b4b5 7c126a38 00000000 00000000 0x43510b0c: 41d9b45c 401f6b31 407bdbd0 4078f8e0 0x43510b1c: 41d55142 7c126a38 407d4528 43510b40 0x43510b2c: 407c9e31 4078f8e0 41d9b450 4078f8e0 02e9: sel=174f base=41c14000 limit=00001fff 32-bit rw- Backtrace: =>1 0x41d551de in irc (+0x51de) (0x41d551de) 2 0x41d9b4b5 in irc (+0x4b4b5) (0x41d9b4b5) 3 0x407c9e31 in msvcrt (+0x29e31) (0x407c9e31) 4 0x404ebbfb in kernel32 (+0x6bbfb) (0x404ebbfb) 5 0x401d6cd3 in ntdll (+0x36cd3) (0x401d6cd3) 6 0x40051297 start_thread+0x87 in libpthread.so.0 (0x40051297) 7 0x4011c37e __clone+0x5e in libc.so.6 (0x4011c37e) 0x41d551de: movl 0x0(%eax),%eax Which if I understand the dump well is due to a problem in __clone function trying to access 0x00000004 (eax). Am I right? Then I tried to debug and to get more information. I got this other line in the new dump: wine: Unhandled page fault on read access to 0x00000004 at address 0x41d551de (thread 005d), starting debugger... And here I am copying the previous lines of the debug information on that thread (005d): 005d:Call ntdll.RtlFreeHeap(40350000,00000000,42cef188) ret=407bdbd0 005d:Ret ntdll.RtlFreeHeap() retval=00000001 ret=407bdbd0 005d:Call ntdll.RtlEnterCriticalSection(40654b04) ret=405c1ee1 005d:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=405c1ee1 005d:Call ntdll.RtlLeaveCriticalSection(40654b04) ret=405c1f2e 005d:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=405c1f2e 005d:Call kernel32.ResetEvent(000000d4) ret=405bf4d0 005d:Call ntdll.NtResetEvent(000000d4,00000000) ret=404e45d8 005d:Ret ntdll.NtResetEvent() retval=00000000 ret=404e45d8 005d:Ret kernel32.ResetEvent() retval=00000001 ret=405bf4d0 005d:Call kernel32.WaitForSingleObject(000000cc,ffffffff) ret=405bf4e6 005d:Call ntdll.NtWaitForMultipleObjects(00000001,435108a4,00000000,00000000,00000000) ret=404e3dd1 005d:Ret ntdll.NtWaitForMultipleObjects() retval=00000000 ret=404e3dd1 005d:Ret kernel32.WaitForSingleObject() retval=00000000 ret=405bf4e6 005d:Call kernel32.GetCurrentProcess() ret=405bf4fd 005d:Ret kernel32.GetCurrentProcess() retval=ffffffff ret=405bf4fd 005d:Call kernel32.GetCurrentThread() ret=405bf504 005d:Ret kernel32.GetCurrentThread() retval=fffffffe ret=405bf504 005d:Call kernel32.GetCurrentProcess() ret=405bf50b 005d:Ret kernel32.GetCurrentProcess() retval=ffffffff ret=405bf50b 005d:Call kernel32.DuplicateHandle(ffffffff,fffffffe,ffffffff,43510ab8,00000010,00000000,00000000) ret=405bf522 005d:Call ntdll.NtDuplicateObject(ffffffff,fffffffe,ffffffff,43510ab8,00000010,00000000,00000000) ret=404cda94 005d:Ret ntdll.NtDuplicateObject() retval=00000000 ret=404cda94 005d:Ret kernel32.DuplicateHandle() retval=00000001 ret=405bf522 005d:Call msvcrt.realloc(42d02040,00000050) ret=405bf547 005d:Call ntdll.RtlReAllocateHeap(40350000,00000000,42d02040,00000050) ret=407bdc8f 005d:Ret ntdll.RtlReAllocateHeap() retval=42d02040 ret=407bdc8f 005d:Ret msvcrt.realloc() retval=42d02040 ret=405bf547 005d:Call kernel32.GetCurrentThreadId() ret=405bf58e 005d:Ret kernel32.GetCurrentThreadId() retval=0000005d ret=405bf58e 005d:Call kernel32.ReleaseMutex(000000cc) ret=405bf5b4 005d:Call ntdll.NtReleaseMutant(000000cc,00000000) ret=404e47d3 005d:Ret ntdll.NtReleaseMutant() retval=00000000 ret=404e47d3 005d:Ret kernel32.ReleaseMutex() retval=00000001 ret=405bf5b4 005d:Call kernel32.SetEvent(00000184) ret=41d9b4a7 005d:Call ntdll.NtSetEvent(00000184,00000000) ret=404e4488 005d:Ret ntdll.NtSetEvent() retval=00000000 ret=404e4488 005d:Ret kernel32.SetEvent() retval=00000001 ret=41d9b4a7 005d:Call ntdll.RtlEnterCriticalSection(41dc78f8) ret=41d55164 005d:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=41d55164 005d:Call kernel32.lstrlenA(7c0f9d2a "") ret=41d55193 005d:Ret kernel32.lstrlenA() retval=00000000 ret=41d55193 005d:Call ntdll.RtlEnterCriticalSection(41164de8) ret=4111a00c 005d:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4111a00c 005d:Call ntdll.RtlLeaveCriticalSection(41164de8) ret=4111a044 005d:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4111a044 005d:Call ntdll.NtCreateEvent(43510648,001f0003,43510608,00000001,00000000) ret=4049fb55 005d:Ret ntdll.NtCreateEvent() retval=00000000 ret=4049fb55 All this is absolutely cryptic to me. Does anyone ge something from this information? Is there any way to get to know where the aplication is crashing? Thank you. Sergio.

Dec. 19, 2005

Switching from INI-Files (win9x) to Registry (NT)?

by Detlef Riekenberg

Hi. With NT, Windows did a Switch from INI-Files to the Registry and use "IniFileMapping" for compatibility with win9x-Apps. (see http://bugs.winehq.org/show_bug.cgi?id=4096) Wine is using both Methods when settings are changed (more code), and this introduce bugs if a Setting-Target is missing: (Example: http://bugs.winehq.org/show_bug.cgi?id=4097) Should we follow the Path of NT and implement the things around IniFileMapping to be compatible with every App that uses the API for INI-Files? We already do caching for INI-Files, so there is no additional incompatibility for very ugly Applications that modify INI-Files manual (open, read/write, close). -- By By ... ... Detlef

Dec. 18, 2005

what happen with my dinput patch and and langues patch for alot of wine dll

by Magnus Olsen

Hi I wonder what happen with my dinput patch and and langues patch for japnise from reactos translator for wine dll files Sorry for the grama spelling and speliing erros now Bestreagds Magnus Olsen

Dec. 18, 2005

Re: ntdll: Implement few Dbg* functions.

by Vitaliy Margolen

Sunday, December 18, 2005, 2:06:55 PM, Eric Pouech wrote: >> The problem here is that we need handle to the debug object which we >> don't have and don't have. And I haven't found how to get a handle to it >> either. > NtCreateDebugObject > we already have a context object (for debugger) in server, it shouldn't > be too hard to implement it that way. Well sure but how to open an existent one? To stop/detach debugger? And what I meant is that what ever we do inside is a Wine's thing anyway. The functions I used seemed more suited to be called from kernel32. As well as the names "Ui" suggest. Which I take means "User Interface". Vitaliy.

Dec. 18, 2005

Re: ntdll: Implement few Dbg* functions.

by Eric Pouech

> The problem here is that we need handle to the debug object which we > don't have and don't have. And I haven't found how to get a handle to it > either. NtCreateDebugObject we already have a context object (for debugger) in server, it shouldn't be too hard to implement it that way. A+ -- Eric Pouech

Dec. 18, 2005

Re: ntdll: Implement few Dbg* functions.

by Vitaliy Margolen

Sunday, December 18, 2005, 1:04:33 PM, Eric Pouech wrote: > Vitaliy Margolen wrote: >> ChangeLog: >> ntdll: Implement few Dbg* functions. >> kernel32: Use new Dbg* functions instead of server calls. >> + status = DbgUiDebugActiveProcess( hProc ); >> + status = DbgUiStopDebugging( hProc ); >> - if (self) DbgBreakPoint(); > I wonder if we shouldn't use NtDbgActiveProcess, NtRemoveProcessDebug > instead. >From what I could find with Google, it looks like: DbgUiDebugActiveProcess is using NtDbgActiveProcess DbgUiStopDebugging is using NtRemoveProcessDebug The problem here is that we need handle to the debug object which we don't have and don't have. And I haven't found how to get a handle to it either. Vitaliy.

Dec. 18, 2005