- Wine-Devel - list.winehq.org

Re: Ptrace problem on amd64? (Was: Re: Warcraft III can't find cdrom)
by Mike Hearn March 14, 2005

March 14, 2005

T.J. Zeeman wrote: >>>Warcraft still complains about the CD-rom being MIA though :( I'll see >>>if I can dig up a few hints from the log this weekend. >> >>Make sure your kernel hsa the ptrace regression fixes in. > > > I guess you meant the problems refered to in WWN250 > (http://www.winehq.com/?issue=250) I checked and the patch there is > only for i386. I ported those to the x86_64 files (see attachments) and > tried again to no avail. > > I also tried the test app as posted by Linus Torvalds here: > http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html > When trying that on amd64 with the ptrace patches it does not even want > to compile (not completely surprising). In the chroot it segfaults. > A strace showed the following: > > x5556c000 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0 > old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000 > close(3) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/lib/tls/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1"..., > 512) = 512 > fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0 > old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x55576000 > old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 3, 0x129000) = 0x5569f000 > old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| > MAP_ANONYMOUS, -1, 0) = 0x556a7000 > close(3) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x556aa000 > set_thread_area({entry_number:-1 -> 11, base_addr:0x556aa2a0, > limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, > limit_in_pages:1, seg_not_present:0, useable:1}) = 0 > munmap(0x5556d000, 32850) = 0 > rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0 > mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > > > I haven't been this deep into low level code in a long time (and that > was 8086 asm simulated on a sparc), but I thought this would work and > not segfault. Anybody around here that can comment on that? Or should I > take this to another forum to further investigate? If so, where would > you suggest I take it? I'm not sure, probably lkml would be best but I'm not subscribed to that. I'll CC wine-devel and maybe somebody there can help. I'd recommend pinging Linus and asking about whether the ptrace regressions still affect x86-64. thanks -mike > regards, > Thomas > > > > > ------------------------------------------------------------------------ > > --- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/ptrace.c 2004-12-24 22:34:30.000000000 +0100 > +++ ptrace.c 2005-03-01 20:32:29.713639136 +0100 > @@ -79,6 +79,28 @@ > return 0; > } > > +static void set_singlestep(struct task_struct *child) > +{ > + long eflags; > + > + set_tsk_thread_flag(child, TIF_SINGLESTEP); > + eflags = get_stack_long(child, EFL_OFFSET); > + put_stack_long(child, EFL_OFFSET, eflags | TRAP_FLAG); > + child->ptrace |= PT_DTRACE; > +} > + > +static void clear_singlestep(struct task_struct *child) > +{ > + if (child->ptrace & PT_DTRACE) { > + long eflags; > + > + clear_tsk_thread_flag(child, TIF_SINGLESTEP); > + eflags = get_stack_long(child, EFL_OFFSET); > + put_stack_long(child, EFL_OFFSET, eflags & ~TRAP_FLAG); > + child->ptrace &= ~PT_DTRACE; > + } > +} > + > /* > * Called by kernel/ptrace.c when detaching.. > * > @@ -86,11 +108,12 @@ > */ > void ptrace_disable(struct task_struct *child) > { > - long tmp; > +/* long tmp; > > clear_tsk_thread_flag(child, TIF_SINGLESTEP); > tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > + put_stack_long(child, EFL_OFFSET, tmp); */ > + clear_singlestep(child); > } > > static int putreg(struct task_struct *child, > @@ -338,8 +361,6 @@ > break; > case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */ > case PTRACE_CONT: { /* restart after signal. */ > - long tmp; > - > ret = -EIO; > if ((unsigned long) data > _NSIG) > break; > @@ -347,12 +368,9 @@ > set_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > else > clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > - clear_tsk_thread_flag(child, TIF_SINGLESTEP); > child->exit_code = data; > /* make sure the single step bit is not set. */ > - tmp = get_stack_long(child, EFL_OFFSET); > - tmp &= ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET,tmp); > + clear_singlestep(child); > wake_up_process(child); > ret = 0; > break; > @@ -394,34 +412,23 @@ > * exit. > */ > case PTRACE_KILL: { > - long tmp; > - > ret = 0; > if (child->exit_state == EXIT_ZOMBIE) /* already dead */ > break; > clear_tsk_thread_flag(child, TIF_SINGLESTEP); > child->exit_code = SIGKILL; > /* make sure the single step bit is not set. */ > - tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > + clear_singlestep(child); > wake_up_process(child); > break; > } > > case PTRACE_SINGLESTEP: { /* set the trap flag. */ > - long tmp; > - > ret = -EIO; > if ((unsigned long) data > _NSIG) > break; > clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > - if ((child->ptrace & PT_DTRACE) == 0) { > - /* Spurious delayed TF traps may occur */ > - child->ptrace |= PT_DTRACE; > - } > - tmp = get_stack_long(child, EFL_OFFSET) | TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > - set_tsk_thread_flag(child, TIF_SINGLESTEP); > + set_singlestep(child); > child->exit_code = data; > /* give it a chance to run. */ > wake_up_process(child); > > > ------------------------------------------------------------------------ > > --- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/signal.c 2004-12-24 22:35:23.000000000 +0100 > +++ signal.c 2005-03-01 20:33:11.425298000 +0100 > @@ -205,8 +205,14 @@ > err |= __put_user(me->thread.trap_no, &sc->trapno); > err |= __put_user(me->thread.error_code, &sc->err); > err |= __put_user(regs->rip, &sc->rip); > + > + /* > + * Iff TF was set because the program is being single-stepped by a > + * debugger, don't save that information on the signal stack.. We > + * don't want debugging to change state. > + */ > eflags = regs->eflags; > - if (current->ptrace & PT_PTRACED) { > + if (current->ptrace & PT_DTRACE) { > eflags &= ~TF_MASK; > } > err |= __put_user(eflags, &sc->eflags); > @@ -324,12 +330,16 @@ > regs->rsp = (unsigned long)frame; > > set_fs(USER_DS); > + /* > + * Clear TF when entering the signal handler, but > + * notify any tracer that was single-stepping it. > + * The tracer may want to single-step inside the > + * handler too. > + */ > if (regs->eflags & TF_MASK) { > - if ((current->ptrace & (PT_PTRACED | PT_DTRACE)) == (PT_PTRACED | PT_DTRACE)) { > + regs->eflags &= ~TF_MASK; > + if (current->ptrace & PT_DTRACE) > ptrace_notify(SIGTRAP); > - } else { > - regs->eflags &= ~TF_MASK; > - } > } > > #ifdef DEBUG_SIG

6 14

Re: STI, device drivers and stuff
by Steven Edwards March 14, 2005

March 14, 2005

Hi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > 2. STI has kernel mode components to deal USB / SCSI / > > serial / parallel ports. Is there any attempt to bring > > kernel mode support into Wine (ReactOS/Wine merger?) > > any time soon? If not, should I implement USB support > > using libusb in user-space? > > Wine is purely user-space, so yes, use libusb I guess. CrossOver is using libusb for the iPod stuff. There is little chance of sharing much of the hardware support with ReactOS however the higher level stuff is being shared such as setupapi. Having a wineserver thread or something that acts like the umpnpmgr on Windows would allow us to share a bit more code as well. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

DOS interrupts in Wine
by Sam Lauber March 14, 2005

March 14, 2005

Does Wine correctly implement all the DOS Services and interrupts? Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

3 2

Re: MSI: add property IDs for MSI summary information
by Juan Lang March 14, 2005

March 14, 2005

--- Mike McCormack <mike(a)codeweavers.com> wrote: > Yes, it's really in MsiDefs.h from the Windows Platform SDK. Weird. > As far as I can tell, MSI also reimplements the property set storage > code, as it makes no calls to the ole storage implementation of > IPropertySetStorage. Perhaps there is some subtle difference between > the two implementations? Or maybe they did that because > IPropertySetStorage isn't available on earlier OLE implemenations? More likely the former, though I wouldn't hazard a guess as to why. MS allows you to reimplement these, they just provide a default impl. It's been around for quite a while, though, the best description I've found is from 1993-1995, well before MSI: http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/dnarolegen… --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: MSI: add property IDs for MSI summary information
by Juan Lang March 14, 2005

March 14, 2005

Hi Mike, > +#define PID_DICTIONARY 0 > +#define PID_CODEPAGE 1 > +#define PID_TITLE 2 Is it really like this in the PSDK? Some of these are already defined in propidl.idl. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Zuma
by Juan Pablo Sousa March 14, 2005

March 14, 2005

Hi, I'm trying to make the game Zuma work you can get the demo from: http://www.popcap.com/launchpage.php?theGame=zuma i've tried setting version to both win98 and winxp, in both cases I get very similar results I don't know where to start, the last line gives me the idea it's even chrashing the debugger, any ideas? here are the last lines running with +relay: 0009:Ret ntdll.RtlAcquirePebLock() retval=00000000 ret=77b18896 0009:Call ntdll.RtlUnicodeStringToAnsiString(7792fa0c,77eff920,00000001) ret=77b188bd 0009:Ret ntdll.RtlUnicodeStringToAnsiString() retval=00000000 ret=77b188bd 0009:Call ntdll.RtlReleasePebLock() ret=77b188d4 0009:Ret ntdll.RtlReleasePebLock() retval=00000000 ret=77b188d4 0009:Call ntdll.RtlEnterCriticalSection(77bde3c0) ret=77b27ed0 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b27ed0 0009:Call ntdll.RtlLeaveCriticalSection(77bde3c0) ret=77b27f00 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b27f00 0009:Call ntdll.RtlEnterCriticalSection(77bde3c0) ret=77b27ed0 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b27ed0 0009:Call ntdll.RtlLeaveCriticalSection(77bde3c0) ret=77b27f00 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b27f00 0009:Call ntdll.NtCreateEvent(77bf0974,001f0003,00000000,00000001,00000000) ret=77b5ffb7 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=77b5ffb7 0009:Ret PE DLL (proc=0x77afdef0,module=0x77af0000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0009:Ret ntdll.LdrInitializeThunk() retval=00000000 ret=77b44b6b 0009:Call ntdll.RtlImageNtHeader(00400000) ret=77b44b79 0009:Ret ntdll.RtlImageNtHeader() retval=004000f8 ret=77b44b79 0009:Starting process L"C:\\Program Files\\PopCap Games\\Zuma Deluxe\\Zuma.exe" (entryproc=0x856000) wine_dbg_vprintf: debugstr buffer overflow (contents: '0009:Call kernel32.VxDCall0(0086e000,0000000a,00857cf4 "\x8b\\$\x0c\xeb\x03\xeb\xfc\xeb\xeb\x01\xeb\xff\x8b\xb0",7792ff38 L"\ffff\ffff\de98\77af\96b0\77b1\7928\77bc",00856030,77b44ba2,77eff6c0 "",00000009,77eff04c,00856000,ffffffff (invalid),77afde98 L"\25ff\f4e4\77bc\f689\25ff\f4e8\77bc\f689\25ff\f4ec\77bc\f689\25ff\f4f0\77bc\f689\25ff\f4f4\77bc\f689\25ff\f4f8\77bc\f689\25ff\f4fc\77bc\f689\25ff\f500\77bc\f689\25ff\f504\77bc\f689\25ff\f508\77bc\f689\25ff\f50c\77bc\f689\8955\53e5\ec83\e814\81d8\fffe\c381\9a2c\000c\7d83\010c\3175\bb83\6e5c\0001\7501\8b28"...,77b196b0,77bc7928,00000000,00000000,7792fff4,7792ff28,77b44b1a,00000001,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,00000000,00000000,00000000,00000000,00000000,00000000,77bc7928,00000000,00000000,00000000,b7fb6dd1,00000000,Exception frame is not in st') err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception.

1 0

[advpack] Implement RegisterOCX and stub out DelNodeRunDLL32
by Matthew Mastracci March 14, 2005

March 14, 2005

This patch helps the IE6 installer get past the DLL registration stage. The DelNodeRunDLL32 function is stubbed out, but RegisterOCX will correctly register a COM DLL by calling its DllRegisterServer function. ChangeLog: * dlls/advpack/advpack.c Matthew Mastracci <mmastrac(a)canada.com> Implement RegisterOCX Stub for DelNodeRunDLL32 Index: dlls/advpack/advpack.c =================================================================== RCS file: /home/wine/wine/dlls/advpack/advpack.c,v retrieving revision 1.7 diff -u -r1.7 advpack.c --- dlls/advpack/advpack.c 20 Jan 2005 20:03:13 -0000 1.7 +++ dlls/advpack/advpack.c 14 Mar 2005 07:35:54 -0000 @@ -32,6 +32,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(advpack); +typedef HRESULT (*DLLREGISTER) (void); + /*********************************************************************** * DllMain (ADVPACK.@) @@ -172,3 +174,60 @@ return S_OK; } + +/*********************************************************************** + * RegisterOCX (ADVPACK.@) + */ +void WINAPI RegisterOCX( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) +{ + WCHAR wszBuff[MAX_PATH]; + WCHAR* pwcComma = &wszBuff[0]; + HMODULE hm; + DLLREGISTER pfnRegister; + HRESULT hr; + + TRACE("(%s)\n", cmdline); + + MultiByteToWideChar(CP_ACP, 0, cmdline, strlen(cmdline), wszBuff, MAX_PATH); + while (!(*pwcComma == ',' ) && *pwcComma) + { + pwcComma++; + } + *pwcComma = '\0'; + + TRACE("Parsed DLL name (%s)\n", debugstr_w(wszBuff)); + + hm = LoadLibraryExW(wszBuff, 0, LOAD_WITH_ALTERED_SEARCH_PATH); + if (!hm) + { + ERR("Couldn't load DLL: %s\n", debugstr_w(wszBuff)); + return; + } + + pfnRegister = (DLLREGISTER)GetProcAddress(hm, "DllRegisterServer"); + if (pfnRegister == NULL) + { + ERR("DllRegisterServer entry point not found\n"); + } + else + { + hr = pfnRegister(); + if (hr != S_OK) + { + ERR("DllRegisterServer entry point returned %08lx\n", hr); + } + } + + TRACE("Successfully registered OCX\n"); + + FreeLibrary(hm); +} + +/*********************************************************************** + * DelNodeRunDLL32 (ADVPACK.@) + */ +void WINAPI DelNodeRunDLL32( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) +{ + FIXME("(%s) FIXME: stub\n", cmdline); +} + Index: dlls/advpack/advpack.spec =================================================================== RCS file: /home/wine/wine/dlls/advpack/advpack.spec,v retrieving revision 1.5 diff -u -r1.5 advpack.spec --- dlls/advpack/advpack.spec 20 Jan 2005 20:03:13 -0000 1.5 +++ dlls/advpack/advpack.spec 14 Mar 2005 07:35:54 -0000 @@ -2,7 +2,7 @@ @ stub AdvInstallFile @ stub CloseINFEngine @ stub DelNode -@ stub DelNodeRunDLL32 +@ stdcall DelNodeRunDLL32(ptr ptr str long) @ stdcall DllMain(long long ptr) @ stdcall DoInfInstall(ptr) @ stub ExecuteCab @@ -23,10 +23,11 @@ @ stub RegRestoreAll @ stub RegSaveRestore @ stub RegSaveRestoreOnINF -@ stub RegisterOCX +@ stdcall RegisterOCX(ptr ptr str long) @ stub RunSetupCommand @ stub SetPerUserSecValues @ stub TranslateInfString @ stub TranslateInfStringEx @ stub UserInstStubWrapper @ stub UserUnInstStubWrapper

2 3

Window style problem with Steam
by Stefan Dösinger March 14, 2005

March 14, 2005

Hello! I had a look at the "no keyboard problem" with Steam. A little reseach showed that Steam creates its main Window with WS_SYSMENU set but WS_CAPTION not set. MSDN says that WS_CAPTION must be set if WS_SYSMENU is used: WS_SYSMENU Creates a window that has a window menu on its title bar. The WS_CAPTION style must also be specified. (from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu…) If I check for this case in WIN_CreateWindowEx and set WS_CAPTION, the Window is controlled by KWM and I can type in the Steam window. But KWM draws the normal Window boarder and it overlaps the rest of the Window and confuses the mouse. Furthermore the menu of the systray applet has a Caption. The solution I've found is to set the WS_EX_APPWINDOW flag in cs->dwExStyle. In this case Steam behaves as I'd expect it. But is this a correct solution? Any suggestions? Stefan

1 0

Scrollkeeper, the documentation, XML, and the way forward
by Scott Ritchie March 14, 2005

March 14, 2005

I wanted the Wine documentation to appear on the nice help menus, like other standard apps. I learned that the way to do this is to write an OMF file for each document, which scrollkeeper can then look at to find the metadata about where the document is and how to index it and such. The trouble is, Scrollkeeper and the Gnome help menus no longer support SGML, as XML is the current new and hip thing. The Wine documentation is in SGML. There are quite a few reasons to move forward. The Wine documentation is also a bit separate (requiring its own compiling, for example) from the main code, and this should change. This link: http://scrollkeeper.sourceforge.net/documentation/scrollkeeper_example2_man… has some good information about how Wine should look to play well with Scrollkeeper and modern distros. I propose we attack this in phases, and create the following plan of attack: 1) Create a new directory for all XML documentation at wine/doc. This will also bring us to be more standard. 2) When we convert old SGML documents to XML and move them there, we write an OMF file for them then and there (I'll do it if you like). We also make sure the build process is aware of this stuff and is installing the xml and omf files in the right place so scrollkeeper can find them when it runs after build time. 3) We follow the steps at the above link to add scrollkeeper into the configure scripts after we convert the first document to XML. I vote for the Wine User Guide, since I'm working on it. 4) We inform the packagers once scrollkeeper is working in a release, as there are sometimes little tricks for it (one for rpms is on the page) So, beyond that, the first step seems pretty simple: convert the sgml stuff into xml format and put it into the new doc folder. Can someone point me to some good tools to do this? Thanks, Scott Ritchie

6 8

Re: shlapi: Fixes for UrlIsW and UrlIsA
by Andreas Mohr March 14, 2005

March 14, 2005

Hi, On Mon, Mar 14, 2005 at 09:07:57PM +1100, Troy Rollo wrote: > Testing under Windows shows that UrlIsW and UrlIsA should: Since you already did testing under Windows, adding proper tests would make sense, I guess... Or in other words: I'm not sure whether your current patch would get applied. Andreas Mohr

1 0