August 2004 - Wine-Devel - list.winehq.org

Re: Debug Channels trashed

by Mike Hearn

On Sun, 29 Aug 2004 21:30:50 +0200, Uwe Bonnes wrote: > Why does this double restoring ebx help? Good question. I don't know. Possibly the window procedure is declared using a calling convention that somehow mangles even the wrapper stack, so we're popping garbage off it into %ebx. But I'm out of ideas for now.

Aug. 29, 2004

Re: CommonUnimpStub looping

by Mike Hearn

On Sun, 29 Aug 2004 09:23:31 -0700, Steven Edwards wrote: > I dont see how native loading of Advapi32 ever worked anyway. Its a > case like ntdll, kernel32, user32 or gdi. Maybe the Win9x advapi32 > can..... I thought native NT advapi just forwarded to ntdll?

Aug. 29, 2004

Re: Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Ove Kaaven

søn, 29.08.2004 kl. 13.31 skrev Mike Hearn: > On Sun, 29 Aug 2004 09:51:30 +0200, Ove Kaaven wrote: > > A book I have described how it works... > > Hi Ove, > > I remember TransGaming had some problems with kernel 2.6 scheduling: did > you guys ever get to the bottom of it? Not in detail, we still consider 2.6 too unstable to support the use of, but the problem is probably related to what's being discussed here, which is why I'm interested. One interesting problem we've seen is the one of wineserver using a whole lot more CPU now than before. A scenario where this could happen is if the game has a relatively low-priority thread which gets to do a lot of waits on critical sections, and some high-priority threads that does interesting stuff, also usually holding those critical sections, so there's always contention. The game might not care much exactly how often the low-priority thread gets scheduled, as long as the resource protected by the critical section is not in use whenever it does get scheduled (which it probably usually isn't if the Win32 thread priority system is used). Well, my theory is that in this situation, with the great new interactivity-boosting Linux scheduler, the wineserver is considered very interactive, and gets scheduled a lot more than the high-priority threads, just so it can satisfy the wait requests of the low-priority thread. This particular situation is a problem which the shared-memory wineserver we have in Cedega now should help somewhat against, I suppose, but that probably doesn't make this problem less interesting for you. And of course there are threads we use that gets penalized a lot. For example, the DirectSound mixing thread would by no means be considered interactive by the scheduler. We would love to elevate the priority of this thread, for example, but it's not possible because of permissions. > What are you recommending your > users do if not? There's now an option in Point2Play to renice the wineserver to a lower priority if you need to. I'm hoping this thread can help bring answers to the other issues with the scheduler...

Aug. 29, 2004

Re: mixing SHELL32.DLL and SHFOLDER.DLL

by Saulius Krasuckas

On Sun, 29 Aug 2004, Saulius Krasuckas wrote: > Lets try. I am not sure about many things: > > 1, whether is better to duplicate code SHGetFolderPathW() or to try > finding it by an ordinal its value (the case for the older versions of > SHELL32.DLL) as it was stated by Juergen? > > 2, shouldn't we output the whole string of pszPath instead of printing > just a pointer value? (I mean in the TRACE() call) 3, should I call DisableThreadLibraryCalls() when dll is being loaded? Lots of dll are doing this. 4, MSDN tells that A and W versions of this function fail differently at the same some conditions. Do we need to write additional test case to be sure?

Aug. 29, 2004

Re: mixing SHELL32.DLL and SHFOLDER.DLL

by Saulius Krasuckas

On Sun, 29 Aug 2004, Steven Edwards wrote: > --- Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > should I wait even more, or should I try writing a patch on my own? > > Write your own. Everyone else seems to have other stuff they are > working on. Lets try. I am not sure about many things: 1, whether is better to duplicate code SHGetFolderPathW() or to try finding it by an ordinal its value (the case for the older versions of SHELL32.DLL) as it was stated by Juergen? 2, shouldn't we output the whole string of pszPath instead of printing just a pointer value? Waiting for the corrections. Changelog: Initial code for the Dll. Stop forwarding SHGetFolderPath[AW] exports to SHELL32.DLL. Instead try locating SHGetFolderPathW() dynamically. Index: dlls/shfolder/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/shfolder/Makefile.in,v retrieving revision 1.7 diff -u -r1.7 Makefile.in --- dlls/shfolder/Makefile.in 11 Oct 2003 01:09:17 -0000 1.7 +++ dlls/shfolder/Makefile.in 29 Aug 2004 19:19:31 -0000 @@ -3,7 +3,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = shfolder.dll -IMPORTS = shell32 +IMPORTS = shell32 kernel32 C_SRCS = shfolder_main.c Index: dlls/shfolder/shfolder.spec =================================================================== RCS file: /home/wine/wine/dlls/shfolder/shfolder.spec,v retrieving revision 1.7 diff -u -r1.7 shfolder.spec --- dlls/shfolder/shfolder.spec 17 Mar 2003 00:17:01 -0000 1.7 +++ dlls/shfolder/shfolder.spec 29 Aug 2004 19:19:31 -0000 @@ -1,2 +1,2 @@ -@ stdcall SHGetFolderPathA(long long long long ptr) shell32.SHGetFolderPathA -@ stdcall SHGetFolderPathW(long long long long ptr) shell32.SHGetFolderPathW +@ stdcall SHGetFolderPathA(long long long long ptr) +@ stdcall SHGetFolderPathW(long long long long ptr) Index: dlls/shfolder/shfolder_main.c =================================================================== RCS file: /home/wine/wine/dlls/shfolder/shfolder_main.c,v retrieving revision 1.1 diff -u -r1.1 shfolder_main.c --- dlls/shfolder/shfolder_main.c 26 Jul 2000 18:30:38 -0000 1.1 +++ dlls/shfolder/shfolder_main.c 29 Aug 2004 19:19:31 -0000 @@ -1 +1,90 @@ -/* nothing here yet */ +/* + * Shell Folder Service + * + * Copyright 2000 Juergen Schmied + * Copyright 2004 Saulius Krasuckas + * + * 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 "wine/debug.h" +#include "winbase.h" +#include "winnls.h" + +WINE_DEFAULT_DEBUG_CHANNEL(shfolder); + + +HINSTANCE SHELL32_hInstance = 0; + +BOOL (WINAPI *SHFOLDER_SHGetFolderPathW)(HWND,int,HANDLE,DWORD,LPWSTR); + + +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) +{ + TRACE("(hinstDLL=%p, fdwReason=%lx, lpvReserved=%p)\n", hinstDLL, fdwReason, lpvReserved); + switch (fdwReason) + { + case DLL_PROCESS_ATTACH: + SHELL32_hInstance = GetModuleHandleA("SHELL32.DLL"); + if (!SHELL32_hInstance) + { + ERR("failed to retrieve handle for SHELL32.DLL\n"); + return FALSE; + } + + SHFOLDER_SHGetFolderPathW = GetProcAddress(SHELL32_hInstance, "SHGetFolderPathW"); + if (!SHFOLDER_SHGetFolderPathW) + ERR("failed to get entry point for SHGetFolderPathW() in SHELL32.DLL\n"); + break; + } + return TRUE; +} + +HRESULT WINAPI SHGetFolderPathW( + HWND hwndOwner, + int csidl, + HANDLE hToken, + DWORD dwFlags, + LPWSTR pszPath) +{ + if (!SHFOLDER_SHGetFolderPathW) + { + FIXME("is a semi-stub: SHELL32.DLL code is still not duplicated neither imported by an ordinal value"); + return E_FAIL; + } + return SHFOLDER_SHGetFolderPathW(hwndOwner, csidl, hToken, dwFlags, pszPath); +} + +HRESULT WINAPI SHGetFolderPathA( + HWND hwndOwner, + int csidl, + HANDLE hToken, + DWORD dwFlags, + LPSTR pszPath) +{ + WCHAR szTempPath[MAX_PATH]; + HRESULT hr; + + if (!pszPath) return E_INVALIDARG; + + *pszPath = '\0'; + hr = SHGetFolderPathW(hwndOwner, csidl, hToken, dwFlags, szTempPath); + if (SUCCEEDED(hr)) + WideCharToMultiByte(CP_ACP, 0, szTempPath, -1, pszPath, MAX_PATH, NULL, NULL); + + TRACE("%p, %p, csidl=0x%04x\n", hwndOwner, pszPath, csidl); + return hr; +} +

Aug. 29, 2004

Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Michael Buesch

Quoting Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>: > Hi, > > On Sun, Aug 29, 2004 at 10:07:18PM +1000, Con Kolivas wrote: > > Audio runs as a separate thread outside of wine potentially through who > > knows how many layers as a combination of both process and kernel > > context so that's already complicating the issue by having a separate > > thread. X does the same again. So what the win32 game is doing under > > wine when it asks for audio or graphics to be done will be handled > > completely differently to windows. How blocking is done between the > > graphics and audio calls, when you have a highly cpu bound task (the > > game) as well is definitely complex and not just the kernel that is > > responsible here. Add to that the fact that wine itself runs a few > > threads and as I said before, it's a miracle it runs smoothly at all. > This shows that dynamic reloading of different schedulers > is a very useful thing: if playing some game on Wine doesn't work with the > currently used scheduler, you just load a specially adapted scheduler (say a > "Wine" scheduler for close Windows scheduling compatibility ;) in order to > have some great gaming session, and that's it. > (of course it'd be useful to have a universally usable scheduler instead, > but that is very difficult if not impossible to achieve) Isn't Nick Piggin maintaining such a dynamic scheduler loader? I can't remember exactly, but I think he has patches for runtime switching between his single priority array scheduler and even staircase with single priority array. Please correct me, if I'm wrong. > Andreas Mohr -- Regards Michael Buesch [ http://www.tuxsoft.de.vu ]

Aug. 29, 2004

Re: mixing SHELL32.DLL and SHFOLDER.DLL

by Filip Navara

Saulius Krasuckas wrote: >Lets try. I am not sure about many things: > >1, whether is better to duplicate code SHGetFolderPathW() or to try >finding it by an ordinal its value (the case for the older versions of >SHELL32.DLL) as it was stated by Juergen? > > ShFolder is redistributable. I believe the best solution would be to move the code from Shell32 to ShFolder and then making the Shell32 exports forwarders to ShFolder. Regards, Filip

Aug. 29, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Andreas Mohr

Hi, On Sun, Aug 29, 2004 at 10:07:18PM +1000, Con Kolivas wrote: > Audio runs as a separate thread outside of wine potentially through who > knows how many layers as a combination of both process and kernel > context so that's already complicating the issue by having a separate > thread. X does the same again. So what the win32 game is doing under > wine when it asks for audio or graphics to be done will be handled > completely differently to windows. How blocking is done between the > graphics and audio calls, when you have a highly cpu bound task (the > game) as well is definitely complex and not just the kernel that is > responsible here. Add to that the fact that wine itself runs a few > threads and as I said before, it's a miracle it runs smoothly at all. This shows that dynamic reloading of different schedulers is a very useful thing: if playing some game on Wine doesn't work with the currently used scheduler, you just load a specially adapted scheduler (say a "Wine" scheduler for close Windows scheduling compatibility ;) in order to have some great gaming session, and that's it. (of course it'd be useful to have a universally usable scheduler instead, but that is very difficult if not impossible to achieve) Andreas Mohr

Aug. 29, 2004

Re: Debug Channels trashed

by Andreas Mohr

Hi, On Sun, Aug 29, 2004 at 09:30:50PM +0200, Uwe Bonnes wrote: > Unhandled exception: page fault on read access to 0x59535445 in 32-bit code SYSTEM? ("YSTE") Andreas Mohr -- Softwarepatente: der pure ausgekochte Oberschwachsinn! 20(!!) Jahre Gueltigkeit im schnelllebigen Software-Bereich, jahrelanger Anmeldungsvorsprung von USA/Japan gegenueber Europa (die machen uns platt), neuer, radikaler Entwurf des Europarates (selbstverstaendlich ohne Berueck- sichtigung jeglicher sinnvoller abmildernder Kompromissvorschlaege) unter Missachtung der direkt gegenlaeufigen Vorentscheidung des Europa-Parlaments, getrickster Verrat Deutschlands ("wir sind dagegen" -- und wie sie das waren!) durch unsere werte ganz offensichtlich hochkorrupte BundesInJustizMinisterin Zypries (welche Gegner der EU-Richtlinie voellig im Regen stehen laesst und hanebuechene Begruendungen fuer Entscheidungen abgibt). Fazit: kuenstliche Monopol-Foerderung bei Grosskonzernen mit grossem Patent- Portfolio (Cross-Licensing), waehrend KMUs in die Roehre schauen (massiver Ausbau der Rechtsabteilung noetig, da jede einzelne Codezeile gegen ein Patent verstossen kann). [Sorry, Sig zu lang, aber es ist wirklich noetig...]

Aug. 29, 2004

Re: Debug Channels trashed

by Uwe Bonnes

>>>>> "Mike" == Mike Hearn <mike(a)navi.cx> writes: Mike> On Sat, 28 Aug 2004 19:30:58 +0200, Uwe Bonnes wrote: >> It seems the location of the debug channels is picked up from the ebx >> register Mike> %ebx is supposed to point to the ELF global offset table, iirc. If Mike> it's been reset somewhere then it could cause this sort of crash Mike> when accessing global vars in an external library as I imagine Mike> debug channels are. Mike> The offending line is printing the *return* value of the function Mike> so I really suspect this is similar to a problem reported earlier Mike> this year (?) where some win32 code wasn't performing register Mike> saves correctly. I bet this is the same problem. >> I wonder what can trash the testing of the debug channels. I ran with >> +heap to look for heap corruption, but couldn't find something. Mike> Try wrapping the window proc callout with some code that saves Mike> %ebx on the stack. There is an example in another part of the code Mike> but I can't remember what! :( Mike> If you compile the relevant DLL with optimization off you may be Mike> able to get away with this for testing the theory: Mike> __asm__("push %ebx") // make the call to the wndproc here Mike> __asm__("pop %ebx") // now test the debug channel and carry on Mike> The reason it works if you comment out the debug channel code is Mike> that %ebx is reset by gcc generated code on entry to an ELF Mike> exported function. With -O2: fixme:dbghelp:elf_lookup_symtab Already found symbol add_paint_count (/spare/wine/wine/dlls/user/../../windows/painting.c) in symtab painting.c @0007c970 and painting.c @000abd40 0x40740f48 WINPROC_CallWndProc [/spare/wine/wine/dlls/user/../../windows/winproc.c:231] in user32: testb $0x8,0x0(%eax) 231 if (TRACE_ON(relay)) 231 if (TRACE_ON(relay)) With -O2 removed from dlls/user/Makefile and winproc.c recompiled WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x59535445 in 32-bit code (0x40740f9f). In 32 bit mode. fixme:dbghelp:elf_lookup_symtab Already found symbol add_paint_count (/spare/wine/wine/dlls/user/../../windows/painting.c) in symtab painting.c @0007c970 and painting.c @000acd90 0x40740f9f WINPROC_CallWndProc [../../windows/winproc.c:231] in user32: movsbl 0x0(%eax),%eax Unable to open file ../../windows/winproc.c With -O2 removed from dlls/user/Makefile, retvalue = WINPROC_wrapper( proc, hwnd, msg, wParam, lParam ) surrounded with __asm__("push %ebx") and __asm__("pop %ebx") the installer doesn't crash at that place. However I wonder: __ASM_GLOBAL_FUNC( WINPROC_wrapper, ... has also "pushl %ebx\n\t" and "popl %ebx\n\t" surrounding "call *%eax\n\t" Why does this double restoring ebx help? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 29, 2004