HI Thank you for the suggestion. Actually there are no errors, just some fixme's, which is not too many. $wine .wine/drive_c/Program\ Files/XX//xxxx.exe fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially implemented fixme:advapi:LsaOpenPolicy ((null),0x32ed54,0x00000001,0x32ed70) stub fixme:advapi:LsaClose (0xcafe) stub fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially implemented fixme:advapi:LsaOpenPolicy ((null),0x32db70,0x00000001,0x32db8c) stub fixme:advapi:LsaClose (0xcafe) stub fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 fixme:class:CLASS_GetClassLong offset -12 (GCLP_HCURSOR) not supported on other process window 0x20030 The GCLP_HCURSOR is the one which comes for any new window popup in the application. We also seen the WINEDEBUG=+relay output, which is quite huge. But most of them are strcmp, readcriticalsections and readfile method calls on ntdll or kernel. So for every window popup CPU is 100%. I am using P4 machine which are quite old with 512MB RAM. One windows with same config system is fine. The same app works fine when I use dual core on linux with wine. DaVince wrote: > > ragsnp wrote: > > I have overridden any of the application dlls except for the wine's oledb32, odbc32, odbccp32. I guess some of this came when I installed MDAC_TYPE. Should I override the application related dll's (like the pb*.dlls) ? will this improve the response time ? > > Did overriding the DLLs actually affect the application in any way? If not, it's probably better to stick with Wine's native DLLs (just to be safe, or relating to other software using the same libraries). It makes for better testing since you're actually using Wine implementations of everything. > > For now, the best thing to do is to post terminal output generated while you try opening any of the slow-loading windows. It should help Wine devs determine and fix the problem. After that, you can experiment with overriding more (non-crucial) DLLs one by one, see if it makes a difference towards window loading time, and report the DLL that made the difference once one does.
