December 2004 - Wine-devel - list.winehq.org

Re: Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

On Tue, 28 Dec 2004 14:46:58 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 2:39 PM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > I'm guessing this means WIne is compiled on this machine in a way that > > doesn't output debug information? > > > > If so (please let me know) then I'll have to look up how to compile > > to include this output. > > I installed my copy on Fedora Core 2 by building an RPM, and WINE is pretty > chatty, so the default configure options in the RPM spec file must be what > you need. > I'm on Gentoo. It sticks in my mind that there is a configure option that turns this on. It's not on by default. I'm doing this on a relative's Gentoo box right now. On my Gentoo system at home I have debugging turned on so I'll wait until I get there in a couple of days and try again with debugging turned on. My though, having poked around a bit, is that there is a registry entry for each user that says whether the user has admin rights. I think that's not turned on, but I don't know if I turn it on whether it will actually work. This is all guessing. Again, Wine is not bombing out at all. I'm just getting a Windows dialog telling me that I need to be an administrator. - Mark

1 0

Re: Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

Kenneth, There are no messages when I run Wine like this: WINEDEBUG=+all wine setup.exe I'm guessing this means WIne is compiled on this machine in a way that doesn't output debug information? If so (please let me know) then I'll have to look up how to compile to include this output. - Mark On Tue, 28 Dec 2004 14:21:32 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 11:12 AM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > How can I tell Wine to trick an install program into thinking the user > > has administrator rights under Windows XP? I've switched the windows > > type in the config file to winxp but the install program for Autocad > > 2005 tells me to log in again as an administrator. > > My guess is that it's either unable to write to a system directory or it's > looking for a certain group membership. Try tracing the installer and see > if it's doing something like that. > >

2 1

Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

Hi - Sorry for cross posting to both winde-devel and wine-users but I need to try and get an answer today on this. I'm at my dad's house and using Wine on his computer. How can I tell Wine to trick an install program into thinking the user has administrator rights under Windows XP? I've switched the windows type in the config file to winxp but the install program for Autocad 2005 tells me to log in again as an administrator. Thanks in advance, Mark

2 1

ptrace + Warcraft 3 issues remain (2.6.10)
by Jesse Allen 28 Dec '04

28 Dec '04

Last I reported on Warcraft 3 with the ptrace changes in 2.6.10-rc3 is that it made some improvement, but still doesn't work. I'll will describe in detail what I know now. Since the changes in 2.6.10-rc3, Linus made a very good clean up of ptrace.c and signal.c in arch/i386/kernel. I don't want to necessarily reverse all these changes because they are good changes (ie easier to understand and hack now). So I hacked the kernel to change what is necessary to make the game run again. I have attached the patch against 2.6.10 to show the required changes. Comments on what I have learned about the 3 ptrace changes (see my original report): #1 ptrace.c In set_singlestep() and clear_singlestep(), the flag TIF_SINGLESTEP is now set and cleared. In the header file in include/asm-i386/thread_info.h, it seems to indicate to me that it is an internal flag to remember to re enable single-stepping for a thread on returning to the program. While speaking to my brother on this, we believe that this change was done correctly. But this change alone will break the game. I have looked in both wine for PTRACE_SINGLESTEP to see what it does and in the kernel for TIF_SINGLESTEP. Since set/clear TIF_SINGLESTEP causes the problem, I really need more information on everything about TIF_SINGLESTEP. #2 signal.c - Not single-stepping into signal handlers unless the tracer requests it Previous to 2.6.9-rc2, my understanding is that a call to setup_frame() would clear the trap flag in preparation for a signal delivery. Roland made a slight tweak to it and an example of it is this: if (regs->eflags & TF_MASK) { if (current->ptrace & PT_PTRACED) { ptrace_notify(SIGTRAP); } else { regs->eflags &= ~TF_MASK; } } Linus later changed it to: /* * 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) { regs->eflags &= ~TF_MASK; if (current->ptrace & PT_DTRACE) ptrace_notify(SIGTRAP); } In 2.6.10, this new piece of code actually works with Warcraft III. I no longer have to reverse this change. The result is obvious because it makes it so you don't automatically single step into the handler, which wine doesn't really want. #3 signal.c - Clearing the trap flag if being traced by debugger in setup_sigcontext() For some reason, Warcraft III doesn't work if it is cleared here. I have no idea if this TF clear is really necessary. However, everything I've read on this seems to indicate to me that this change is important, so I need to find out what this causes to the game. I captured a log of the seh debug messages because I think this is may be where to look. I also hacked in to display trace messages in wine's dlls/ntdll/signal_i386.c showing eflags and whether TF is cleared in trap_handler() and raise_trap_exception(). I ran the game under 2.6.10 and the modded 2.6.10, to capture the working version, and the failing version. The results are fairly nonrandom and comparable and you can identify differences. Unfortunately, I cannot upload them at the moment because my connection is slow and the files are large. I'll upload it another time. Jesse

1 0

Re: [OLE #16] Comment out an assert, as we don't yet implement IRemUnknown
by Andreas Mohr 28 Dec '04

28 Dec '04

Hi, On Tue, Dec 28, 2004 at 03:37:17PM +0000, Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Comment out an assert, as we don't yet implement IRemUnknown > > --- dlls/ole32/stubmanager.c (revision 9) > +++ dlls/ole32/stubmanager.c (local) > @@ -171,8 +175,10 @@ int stub_manager_unref(struct stub_manag > EnterCriticalSection(&m->lock); > if (!list_empty(&m->ifstubs)) > { > - ERR("PANIC: Stub manager is being destroyed with outstanding interface stubs\n"); > - assert( FALSE ); > + ERR("PANIC: Stub manager %s is being destroyed with outstanding interface stubs\n", wine_dbgstr_longlong(m->oid)); > + > + /* assert( FALSE ); */ > + /* fixme: this will happen sometimes until we do proper lifecycle management via IRemUnknown */ > } > > /* fixme: the lifecycle of table-weak marshals is not $ find|xargs grep FIXME|wc -l 11011 $ find|xargs grep fixme|wc -l 83 Might be good to keep it that way... Andreas Mohr

3 3

[AppDB] Get rid of value fillers in appSubmit.php for a new version
by Paul van Schayck 28 Dec '04

28 Dec '04

Those value fillers are not used. We never send users back to the page when errors are found (maybe we should). Changelog: Remove registered globals from the new-version submit. They are not used.

3 4

wine: could not load kernel32.dll, status c000007b
by Serge S. Spiridonoff 28 Dec '04

28 Dec '04

Hi, I've compiled a Win32 GUI app under Linux using WineLib but it fails to start. Any ideas what's wrong with the program? [test]WINEDEBUG=+loaddll ./dlg1 trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\msvcrt.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\advapi32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\gdi32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\user32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\winspool.drv" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\comctl32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\iphlpapi.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\rpcrt4.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\ole32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shell32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\comdlg32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "GDI.EXE" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "USER.EXE" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\x11drv.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\imm32.dll" : builtin wine: could not load kernel32.dll, status c000007b Thanks in advance, Serge

1 0

Re: MSI: free allocated buffers
by Joris Huizer 28 Dec '04

28 Dec '04

Mike McCormack wrote: > > ChangeLog: > <aric(a)codeweavers.com> > * free allocated buffers > > The other daty I saw a lot of patches changing things like if (buffer) HeapFree(GetProcessHeap(),0,buffer); To HeapFree(GetProcessHeap(),0,buffer); Why are you adding new code with the if() statement in place again? Just curious regards, Joris

3 2

Re: Unicodify System Metrics
by Mike Hearn 28 Dec '04

28 Dec '04

On Tue, 28 Dec 2004 00:26:36 -0500, jchevrier wrote: > --- sysparams.c.orig 2004-12-27 20:09:20.000000000 -0500 > +++ sysparams.c 2004-12-27 21:45:02.674627072 -0500 Hi, The patch looks OK at a first glance but in future please diff from the source root, preferably against CVS. thanks -mike

1 0

[AppDB] naming convention
by Jonathan Ernst 28 Dec '04

28 Dec '04

As discussed with Chris and others on IRC we'd like to use a new variable naming convention in AppDB code. The proposed scheme is the following ("hungarian notation"): handles: $hSomeHandle integer: $iSomeInteger objects: $oSomeObject arrays: $aSomeArray strings: $sSomeString and so on. constants will still be uppercase without prefix. Do someone object this ? Jonathan

2 2