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

CreateNamedPipe error values?
by Dan Kegel 12 Feb '03

12 Feb '03

I wrote a humble beginning of a conformance test for named pipes, in hopes of preventing regressions like the one which is currently breaking Installshield installs (or was last I checked). Later it's going to verify that named pipes like the ones Wine uses internally (e.g. in ole32/rpc.c) actually work, For now I thought I'd just make sure we return the right error code if you pass a bogus filename to CreateNamedPipe. But, um, we don't return any error code; we happily succeed. Can somebody who has Windows Server run this little test, and tell me what it outputs? You can build it as part of the wine test suite, or standalone with the commands call \vcvars32.bat cl /D STANDALONE /D _X86_ /D _M_IX86 /D WIN32 /D _WINDOWS pipe.c Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 0a1,61 > /* > * Unit tests for named pipe functions in Wine > * > * Copyright (c) 2002 Dan Kegel > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > * License as published by the Free Software Foundation; either > * version 2.1 of the License, or (at your option) any later version. > * > * This library is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > * Lesser General Public License for more details. > * > * You should have received a copy of the GNU Lesser General Public > * License along with this library; if not, write to the Free Software > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > > #include <stdlib.h> > #include <stdio.h> > #include <time.h> > > #ifndef STANDALONE > #include "wine/test.h" > #else > #include <assert.h> > #define START_TEST(name) main(int argc, char **argv) > #define ok(condition, msg) assert(condition) > #endif > > #include <windef.h> > #include <winbase.h> > #include <winerror.h> > #include <wtypes.h> > > void test_CreateNamedPipeA(void) > { > HANDLE hnp; > char filename[MAX_PATH]; > > sprintf(filename, "not a named pipe name"); > hnp = CreateNamedPipeA(filename, > PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_READMODE_BYTE|PIPE_WAIT, > /* nMaxInstances */ 1, > /* nOutBufSize */ 1024, > /* nInBufSize */ 1024, > /* nDefaultWait */ 1000, > /* lpSecurityAttrib */ NULL); > > printf("h %p, err %ld\n", hnp, GetLastError()); > ok(hnp == INVALID_HANDLE_VALUE && GetLastError() == ERROR_INVALID_NAME, > "CreateNamedPipe should fail if name doesn't start with \\\\.\\pipe"); > } > > START_TEST(pipe) > { > test_CreateNamedPipeA(); > } >

4 3

seg fault in exception handler running starcraft?
by SodaPop 12 Feb '03

12 Feb '03

Starcraft crashes for me with the 20030115 wine release, every time I try to actually start playing a map. The wine debugger isn't invoked when the crash happens, I just get a 'Segmentation fault' message and control is returned to my shell. Some wine threads are still running however, as the music keeps playing and the main starcraft window does redraws as needed. Here is the backtrace from regular gdb: #0 0x00000000 in ?? () #1 0x400be693 in EXC_CallHandler (record=0x40691c10, frame=0x40691d80, context=0x406918ac, dispatcher=0x40691848, handler=0, nested_handler=0x400be5d0 <EXC_RaiseHandler>) at exception.c:117 #2 0x400be9b9 in EXC_RtlRaiseException (rec=0x40691c10, context=0x406918ac) at exception.c:213 #3 0x400cdd99 in __wine_call_from_32_regs () from /usr/local/lib/libntdll.dll.so #4 0x400be8b5 in RtlRaiseException () from /usr/local/lib/libntdll.dll.so #5 0x40aa31ec in __wine_stub_rpcrt4_dll_314 () at rpcrt4.spec.c:356 #6 0x788f6974 in ?? () #7 0x788f31b8 in ?? () #8 0x788f5a65 in ?? () #9 0x7ca0ac41 in ?? () #10 0x7ca09194 in ?? () #11 0x4091640f in CryptAcquireContextA (phProv=0x40691f60, pszContainer=0x1502b5f0 "Blizzard_Storm", pszProvider=0x1502b600 "Microsoft Base Cryptographic Provider v1.0", dwProvType=1, dwFlags=8) at crypt.c:332 #12 0x1500f568 in ?? () Please let me know if you need any additional data, I'll try to scrape it out of the debugger. This happens both with starcraft versions 1.00 and 1.05 patched. Broodwar is not installed. Please cc me, I normally only read the archives and am not subscribed. -dennis T

2 1

cvs wine + win2k ole + installshield = unhappy
by Dan Kegel 12 Feb '03

12 Feb '03

I'm trying to run a particular installer made with Installshield on cvs wine without any Windows DLLs. This used to work (on a different machine, with who knows what other changes). Now I just get an empty InstallShield wizard frame, and then it hangs. Hrmph. Maybe installshield wants some new spiffy ole stuff. Now, this machine dual-boots with win2k, so I thought I'd try native dlls for a few things: $ cd ~/c/windows/system $ cp /dos/c/WINNT/system/stdole.tlb . $ cp /dos/c/WINNT/system32/compobj.dll . $ cp /dos/c/WINNT/system32/storage.dll . $ cp /dos/c/WINNT/system32/ole{2,32}.dll . $ cd ~/c/temp/disk1 $ ~/wine/wine --dll compobj,storage,ole,ole2,ole32=n Setup.exe Unfortunately, that crashes. Rerunning with +relay > log 2>&1, and doing egrep 'fixme|^wine|^Unhand' log, I see: fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE fixme:seh:check_resource_write Broken app is writing to the resource data, enabling work-around fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE fixme:win:GetProcessWindowStation (void): stub fixme:win:GetThreadDesktop (9): stub fixme:win32:GetUserObjectInformationW (0x1 2 0x406817cc 64 0x4068181c),stub! fixme:win32:GetUserObjectInformationW (0x1 2 0x4068178c 64 0x4068181c),stub! fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a7abc8,pFormat = ^0x77a7ac1a,...): semi-stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000004,0x00000001,0x4068181c): stub fixme:advapi:SetThreadToken ((nil), (nil)): stub (NT impl. only) fixme:ntdll:NtOpenProcessToken (0xffffffff,0x00000008,0x40681828): stub fixme:ntdll:NtQueryInformationToken (0xcafe,1,0x406817d0,52,0x40681824): stub fixme:advapi:LookupAccountSidW ((null),sid=0x406817d8,0x40681724,0x40681830(80),0x403c61d8,0x4068182c(80),0x40681820): semi-stub fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a8c4b8,pFormat = ^0x77a8c572,...): semi-stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000004,0x00000001,0x40681898): stub fixme:advapi:SetThreadToken ((nil), (nil)): stub (NT impl. only) fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) wine: Unhandled exception, starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x77a539ca). There are enough fixmes there that I can believe something crucial isn't implemented yet. Here's the last few lines of relay, plus the backtrace: fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) 00000009:Ret advapi32.SetThreadToken() retval=00000000 ret=77a5e17f 00000009:Call kernel32.CloseHandle(0000cafe) ret=77a5e186 00000009:Ret kernel32.CloseHandle() retval=00000000 ret=77a5e186 00000009:Call ntdll.RtlLeaveCriticalSection(77b32b68) ret=77a5db8f 00000009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77a5db8f 00000009:Call kernel32.GetCurrentProcessId() ret=77a5b6a5 00000009:Ret kernel32.GetCurrentProcessId() retval=00000008 ret=77a5b6a5 00000009:Call kernel32.OpenEventA(001f0003,00000000,4068187c "MSFT.VSA.COM.DISABLE.8") ret=77a5b6cc 00000009:Ret kernel32.OpenEventA() retval=00000000 ret=77a5b6cc 00000009:Call kernel32.OpenEventA(00100002,00000000,77a5b6f4 "MSFT.VSA.IEC.STATUS.6c736db0") ret=77a5b6e1 00000009:Ret kernel32.OpenEventA() retval=00000000 ret=77a5b6e1 00000009:Call ntdll.RtlLeaveCriticalSection(77b333c0) ret=77b295c0 00000009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b295c0 00000009:Call ntdll.RtlEnterCriticalSection(77b326a0) ret=77a51d8e 00000009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77a51d8e wine: Unhandled exception, starting debugger... ... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x77a539ca). In 32-bit mode. 0x77a539ca (OLE32.DLL.StringFromCLSID+0x137 in C:\WINDOWS\SYSTEM\OLE32.DLL): movw 0x0(%edx),%dx Backtrace: =>0 0x77a539ca (OLE32.DLL.StringFromCLSID+0x137 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40681858) 1 0x77a5b2be (OLE32.DLL.CoRegisterMessageFilter+0x324 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=406818ac) 2 0x77a7e5f0 (OLE32.DLL.CoCreateGuid+0x1114 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=406818e4) 3 0x77a7d103 (OLE32.DLL.CoFreeUnusedLibraries+0x45b in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=406818fc) 4 0x77a6f555 (OLE32.DLL.OleCreateEx+0x1305 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=4068194c) 5 0x77a58359 (OLE32.DLL.CoCreateInstance+0x3ca1 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40681b94) 6 0x77a582ca (OLE32.DLL.CoCreateInstance+0x3c12 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40681bb0) 7 0x77a54518 (OLE32.DLL.CoCreateInstanceEx+0x223 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=4068231c) 8 0x77a5431d (OLE32.DLL.CoCreateInstanceEx+0x28 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40682344) 9 0x77a546ea (OLE32.DLL.CoCreateInstance+0x32 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40682374) 10 0x00403a0f (Setup.exe.EntryPoint+0x1eb5 in C:\temp\Disk1\Setup.exe) (ebp=406823ec) 11 0x0040258b (Setup.exe.EntryPoint+0xa31 in C:\temp\Disk1\Setup.exe) (ebp=40682448) 12 0x004022c4 (Setup.exe.EntryPoint+0x76a in C:\temp\Disk1\Setup.exe) (ebp=406828a4) 13 0x00401ff9 (Setup.exe.EntryPoint+0x49f in C:\temp\Disk1\Setup.exe) (ebp=40682e34) 14 0x00401be6 (Setup.exe.EntryPoint+0x8c in C:\temp\Disk1\Setup.exe) (ebp=40682e9c) 15 0x4009dd90 (start_process+0x21c [process.c:564] in libntdll.dll.so) (ebp=40682f38) 16 0x400a212d (call_on_thread_stack+0x1d(func=0x4009db74) [sysdeps.c:171] in libntdll.dll.so) (ebp=40682ff4) 17 0x400a22c0 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) I'd be happy to send a better log or implement some small missing call if someone wants to point me in the right direction. - Dan

9 16

winedos/int10 clearscreen fix
by Ulrik Mikaelsson 12 Feb '03

12 Feb '03

Hi I've had issues with a console program not clearing the screen when it's supposed to. I've traced the problem down to dlls/winedos/int10.c function DOSVM_Int10Handler() with and AH reg of 0x0b. I've added code for clearing the screen with the specified color, as well as added a method for doing a total clearscreen to vga.c and vga.h. It's only tested for textmode and propably won't work for anything else so I think the fixme should be left for anyone who's up for the task. A patch is attached, please feel free to comment before i submit to wine-patches. Regards Ulrik

1 0

dos4gw saga continues
by Enrico Horn 11 Feb '03

11 Feb '03

Hi, here are two things I find interesting about dos4gw: 1.it will allocate 1 para of memory than resize to available memory allocate another para of memory(this doesnt fail although all memory should be already allocated) and resize it to available memory(which is zero!?) 2. does a close file by handle with handle value 0xffff do something special dos4gw does this too and it fails because there is no handle value 65535. any ideas Enrico Horn farmboy1(a)subdimension.com

2 1

Re: wine/dlls/ntdll exception.c
by Gregory M. Turner 11 Feb '03

11 Feb '03

On Tuesday 11 February 2003 03:56 pm, Alexandre Julliard wrote: > ChangeSet ID: 7195 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/02/11 15:56:59 > > Modified files: > dlls/ntdll : exception.c > > Log message: > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> > Added FIXME on stub exception. > > Patch: http://cvs.winehq.com/patch.py?id=7195 > > Old revision New revision Changes Path > 1.51 1.52 +2 -1 wine/dlls/ntdll/exception.c uh-oh, I sense a flood coming on! WB Alexandre! -- gmt "Once a nation becomes a democracy, the whole purpose of government changes. Instead of the government's goal being that of guaranteeing liberty, equal justice, private property, and voluntary exchange, the government embarks on the impossible task of achieving economic equality, micromanaging the economy, and protecting citizens from themselves and all their activities. The destruction of the wealth-building process, which is inherent in a free society, is never anticipated. Once it's realized that it has been undermined, it is too late to easily reverse the attacks against limited government and personal liberty." -- Ron Paul

1 0

Re: [DInput] Tribes fix...
by Ove Kaaven 11 Feb '03

11 Feb '03

man, 2003-02-10 kl. 23:21 skrev Lionel Ulmer: > Hi all, > > With this patch, Tribes1 now likes our DInput driver. > > Lionel (who waits for his beer when he will visit Sweden :-) ) > > Changelog: > Implement EnumObjects for the keyboard device > strcpy(ddoi.tszName, "a"); /* This should be better handled :-/ */ Perhaps the right way to do this would be something like GetKeyNameTextA(((i & 0x7f) << 16) | ((i & 0x80) << 17), ddoi.tszName, sizeof(ddoi.tszName));

2 1

err:keyboard:X11DRV_ToUnicode Please report
by Duane Clark 11 Feb '03

11 Feb '03

Originally discovered (as far as I know) by Paul McNett and mentioned in bug 1264, typing a shift-tab in an app under Wine generates the message: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE20 (ISO_Left_Tab) : err:keyboard:X11DRV_ToUnicode (virtKey=9,scanCode=F,keycode=17,state=1) So here is a report.

1 0

Where oh where has Alexander gone?
by Shachar Shemesh 11 Feb '03

11 Feb '03

Hi, The last commit to wine has been done almost two weeks ago. I understood from half an email that Dimi wrote that Alexander was away from the Internet (away for almost two weeks! *shudder*). Anyone knows where, when and what? Is all ok? -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/

2 1

Treeview Error.
by Drew "DanteAliegri" Ogle 11 Feb '03

11 Feb '03

I've found the problem, but I'm not sure how to fix it. Just to explain the error, putty and some other things that use treeviews stopped working. The treeview would appear, but content to its left would not. The problem is this: in TREEVIEW_DoSelectItem of dlls/comctl32/treeview.c sends a TVN_SELCHANGINGW and then a TVN_SELCHANGEDW, however putty at least, is looking for a TVN_SELCHANGED , which compiles to a TVN_SELCHANGEDA. Changing these there restores putty and winamp's preference dialog to the way they worked before. What needs to happen then, is somewhere we know that we are calling into a A callback, so we can change the TVN_SELCHANGEDW code to TVN_SELCHANGEDA.

1 0