wine-devel March 2005

wine-devel@winehq.org

178 participants
443 discussions

Re: [patch] x86: fix ESP corruption CPU bug
by Stas Sergeev 14 Mar '05

14 Mar '05

Hi, Linus Torvalds wrote: > Btw, Stas, one thing I'd really like to see is even a partial list of > anything that actually cares about this. Ie, if there is some known > Windows app where Wine works better or something like that, just adding I am not using Wine too much, but I've found this: http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/winedos/int31.c?rev=1.41&… --- /* due to a flaw in some CPUs (at least mine), it is best to mark stack segments as 32-bit if they can be used in 32-bit code. Otherwise, these CPUs may not set the high word of esp during a ring transition (from kernel code) to the 16-bit stack, and this causes trouble if executing 32-bit code using this stack. */ --- I added win-devel to CC, maybe people there can tell if that patch has any value for them or not. The reference to the original patch: http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/1794.html Dosemu looks a little better on that, the whole chapter of the docs is dedicated to that problem: http://dosemu.sourceforge.net/docs/EMUfailure/t1.html#AEN55 There you can find a (relatively small) list of the programs that are affected, but I personally have the old Microsoft linker that crashes, and a few more DOS games. > Another way of saying the same thing: I absolutely hate seeing patches > that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS. > So I'd like to have a bit more of a case for this patch, since I know what > the case against it is ;) Yep, and the informational leak it closes, looks also rather minor. So it is only a matter of how do you care about the dosemu and the DOS games under linux. Considering the amount of the dosemu-related code in vm86.c, I guess you care:) And uhm, adding the list of the DOS games to the comments of the Linux kernel code, doesn't sound like a good idea to me:)

6 7

Re: shlapi: Fixes for UrlIsW and UrlIsA
by Mike McCormack 14 Mar '05

14 Mar '05

Troy Rollo wrote: > Testing under Windows shows that UrlIsW and UrlIsA should: Would you be able to write a conformance test using what you've found, to make sure it doesn't break again? Even just posting the test program to wine-patches so somebody could create a conformance test out of it would be great... Mike

2 1

richedit patches by Phil Krylov
by Krzysztof Foltman 14 Mar '05

14 Mar '05

> ChangeLog: > Initial implementation of EM_STREAMOUT and RTF writer. Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks. IMHO the patch can be applied without changes. The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later. Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code. > Added "generator" RTF destination handling. > Added missing PFA_JUSTIFY definition to richedit.h. Thanks for the fixes, I really didn't know how to get rid of the \generator. Maybe it will help me figure out how to ignore the rest of the RTF junk that I can't use anyway (\pgdsctbl and others). Krzysztof

3 3

Let's fix Steam!
by Scott Ritchie 14 Mar '05

14 Mar '05

Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. What's interesting, however, is that Steam works perfectly in Crossover 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine. This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :) So, where do we go about this? The installer demonstrating the error can be downloaded easily from http://www.steampowered.com/ - however, I'm not sure if it's plausible to run a regression analysis since there are no patches available against the direct crossover version of Wine. At this point, I'm not even sure which file has broken, although I do know that it's one we've had problems with in the past based off of IRC conversations. If anyone could follow up with more info, particularly about the specifics of the error, I'm sure we'd all appreciate it greatly. Thanks, Scott Ritchie

3 11

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

14 Mar '05

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 14 Mar '05

14 Mar '05

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 14 Mar '05

14 Mar '05

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 14 Mar '05

14 Mar '05

--- 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 14 Mar '05

14 Mar '05

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 14 Mar '05

14 Mar '05

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

← Newer
1
...
21
22
23
24
25
26
27
...
45
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2005