- Wine-devel - list.winehq.org

Problem in scheduler/process.c
by Dustin Navea 17 May '02

17 May '02

ok, so I have found the cause of the problem in scheduler/process.c that is making ut-based installers not work. the problem is the code from line 450 to line 461 inclusive. in all programs, PROCESS_InitWine is called from int main in miscemu/main.c, then open_winelib_app is called from PROCESS_InitWine (always) where things go wrong... in a normal program, 1 of 2 things (im not sure which though) happens... 1) line 451 evaluates to false so that section is skipped and then line 461 is also evaluated to false, so it is also skipped, so open_winelib_app returns either null or " " (not sure of the difference) -or- 2) line 451 evaluates to true, and then 457 also evaluates to true, so open_winelib_app returns NULL. with the ut-based installer that is the case, but the Setup.exe that is on the root of the cd acts differently... 1) 451 evaluates to false and then 461 evaluates to true, causing wine to attempt to load the real installer (called by the one in the root of the cd) as a .so, which doesn't work. -or- 2) 451 evaluates to true and 457 evaluates to false, so it goes on to 461, which evaluates to true... with winelib apps the same thing happens as with the "root-of-cd" installer except that the .so file does exist and so it gets loaded... so, i think what needs to be done is a check in PROCESS_InitWine for the kind of binary (windows or winelib). and if it is a winelib binary, then run call open_winelib_app, otherwise proceed with normal loading... probably the easiest way to do this would be like this line 491-494 if (argv[0] != 'wine') { if (open_winelib_app( app_argv )) goto found; } that way you could probably completely remove lines 450-459 which are in open_winelib_app, since all it does is check to make sure argv[0] doesn't equal wine... i would try this method out and submit it, but i won't be back at home until tonight, so i can't make any diff's. if someone wants to give it a go and let us know if it works, please give me credit for the _idea_. hopefully this solves some other problems too... comments appreciated. -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: Fix for focus loops
by Jukka Heinonen 17 May '02

17 May '02

On Tue, May 07, 2002, Alexandre Julliard wrote: > I've been working on this too, and I found that the locally active > model seems to work better with most window managers, even though it's > not 100% correct per the spec. Here's the patch I have, please give it > a try and let me know how it works for you. If your patch is used in globally active mode (Wine config file has "UseTakeFocus" = "Y"), focus loop problem is fixed. However, if I try locally active mode, Wine still enters focus loop. Some comments about the patch and Wine focus handling: - Timestamp used in X11DRV_SetFocus is wrong when focus has been gained either due to WM_TAKE_FOCUS or due to FocusIn. - Routine X11DRV_SetFocus may fail to set focus because focus might have already been passed to another X11 window. In unmanaged mode this is fatal: override_redirect windows receive neither WM_TAKE_FOCUS nor FocusIn and if Wine believes that a window already has focus it won't call X11DRV_SetFocus even when the window receives mouse clicks. - If X11DRV_SetFocus fails, Wine routine that triggered this call (SetForegroundWindow, SetActiveWindow, SetFocus, etc) should also fail. This is what NT5.0 does according to docs, by the way. This would make it easy to see which window really has focus. - It is likely that last_focus will be wrong if routine X11DRV_SetFocus fails as described above. - All Wine windows using override_redirect break ICCCM. This includes all windows in unmanaged mode. In general, it is not possible for override_redirect windows to gain input focus without confusing focus handling of window managers. There are two exceptions to this generalization which likely apply to full-screen applications and menus. - In locally active model, transferring focus from top-level window to active dialog window requires timestamp CurrentTime which breaks ICCCM compliance. This can break window manager focus handling in some cases. This is likely not very big an issue, but I believe that everything that breaks standards should be properly commented. - One not directly focus relared problem is that some window managers always put override_redirect windows on top of managed windows. And when you run some applications in managed mode, Wine creates a full screen override_redirect window which has managed dialog window... Looking at this list makes me believe that fixing Wine focus handling should be assigned much higher priority than it has been so far. -- Jukka Heinonen <http://www.iki.fi/jhei/>

4 6

Problem after update
by Marcelo Welter 17 May '02

17 May '02

Hello I make cvs update -RdP configure make depend make ./snmpapi.spec:6: Expected name, id, length or ordinal make[2]: *** [snmpapi.spec.c] Error 1 make[2]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls/snmpapi' make[1]: *** [snmpapi/snmpapi.dll.so] Error 2 make[1]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls' make: *** [dlls] Error 2 what happen? the syntax of cvs that i use are correct...? Thanks Marcelo

3 2

Component owner for window management/painting
by Andriy Palamarchuk 17 May '02

17 May '02

Any volunteers for handing this kind of problems? Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: Patch - check for msghdr.msg_control on Sparc-Solaris
by Warren_Baird＠cimmetry.com 17 May '02

17 May '02

> I think it would be better to do it using a technique similar to how it > is done in scheduler/client.c on line 255: Makes sense to me - it wasn't obvious that msg_control and msg_accrights are always mutually exclusive, which is why I added a separate test... But if we're sure they are always mutally exclusive, this approach makes more sense... Warren

1 0

err:heap:HEAP_ValidateInUseArena
by John K. Hohm 17 May '02

17 May '02

I am implementing a COM object in comcat.dll that allocates itself with HeapAlloc and frees itself on its last Release with HeapFree. I am using it in a simple test program that creates it and releases it, and when the Release happens I get this: err:heap:HEAP_ValidateInUseArena Heap 40340000: in-use arena 40378878 next block has PREV_FREE flag It seems to be saying that I'm freeing an already-free block. I ran the test program with --debugmsg trace+all, and I can see that the only uses of the heap during the lifetime of my object instance are one ntdll.RtlAllocateHeap that returns 40378880, and one ntdll.RtlFreeHeap that gets 40378880 as its third param. The RtlFreeHeap is immediately followed by the err:heap, which then spits out a bunch of heap info. It seems pretty obvious that I'm freeing the block of memory I had just allocated; what else might be causing the err:heap? Here is the interesting section of the trace: 080701d0:trace:ole:COMCAT_ICatInformation_EnumCategories 080701d0:Call ntdll.RtlAllocateHeap(40340000,00000008,00000020) ret=4397c0f3 080701d0:trace:heap:RtlAllocateHeap (40340000,0000000a,00000020): returning 40378880 080701d0:Ret ntdll.RtlAllocateHeap() retval=40378880 ret=4397c0f3 080701d0:trace:ntdll:NTDLL_vsnwprintf (2147483647,L"%lX") 080701d0:Call advapi32.RegOpenKeyExW(80000000,40566ce8 L"Component Categories",00000000,00020019,40378898) ret=4397c170 080701d0:Call ntdll.RtlInitUnicodeString(40566bd8,40566ce8 L"Component Categories") ret=40660189 080701d0:Ret ntdll.RtlInitUnicodeString() retval=0000002a ret=40660189 080701d0:Call ntdll.NtOpenKey(40378898,00020019,40566be0) ret=40660194 080701d0:trace:reg:NtOpenKey (0x80000000,L"Component Categories",20019,0x40378898) 080701d0: open_key( parent=-2147483648, access=00020019, name=L"Component Categories" ) Open key ERROR 080701d0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080701d0:trace:reg:NtOpenKey <- 0x0000 080701d0:Ret ntdll.NtOpenKey() retval=c0000034 ret=40660194 080701d0:Call ntdll.RtlNtStatusToDosError(c0000034) ret=4066019a 080701d0:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=4066019a 080701d0:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=4397c170 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_AddRef 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Next 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Release 080701d0:Call ntdll.RtlFreeHeap(40340000,00000000,40378880) ret=4397be9d 080701d0:err:heap:HEAP_ValidateInUseArena Heap 40340000: in-use arena 40378878 next block has PREV_FREE flag

2 1

Re: wine/ dlls/Makefile.in dlls/avicap32/Makefile. ...
by Dimitrie O. Paun 17 May '02

17 May '02

On May 16, 2002 11:37 pm, Alexandre Julliard wrote: > Log message: > Removed most imports of ntdll since we no longer import Wine internal > functions from there. Yay! I've been advocating putting all the wine-specific stuff in a "helper" dlls (libwine) for soo long now, specifically for the purpose of the "Windows" port. Now, the linking things is still a bit of mistery to me. Let's see: -- libwine is linked with all DLLs using the host's native dynlinking tool -- when a program is loaded, _wine_ loads the required DLLs which in turns gets linked by the OS to libwine. Is that so? To be honest, this is how I *think* it works, I haven't actually gone through the code, but I'm feeling lazy tonight :))) -- Dimi.

2 1

Re: wine/ controls/menu.c dlls/commdlg/cdlg32.c dl ...
by Dimitrie O. Paun 17 May '02

17 May '02

On May 16, 2002 10:55 pm, Alexandre Julliard wrote: > > Log message: > Export the debugging API from libwine instead of ntdll. > Removed debugres_[aw]. I think you need to test for null strings in default_dbgstr_[aw]n, no? Also, the default implementations are there for the mingw port? We normally use the ones from NTDLL_dbgstr_*, right? -- Dimi.

2 1

64bit values in API args...
by Vincent Béron 17 May '02

17 May '02

I have a little problem implementing VerifyVersionInfo{A,W}. Here's the prototype of the function (W): BOOL WINAPI VerifyVersionInfoW( LPOSVERSIONINFOEXW lpVersionInfo, DWORD dwTypeMask, DWORDLONG dwlConditionMask) with DWORDLONG being a 64bit value. Now, how do I translate that in kernel32.spec? The current declaration in kernel32.spec is @ stdcall VerifyVersionInfoW(long long long long) VerifyVersionInfoW with either a try to get a "long long" type (undistinguishable from 2 longs), or by just assuming a virtual fourth argument to get the right total argument size. Now, this seems really fishy. I'm not very familiar with the way a C compiler places arguments either in registers or on the stack, but I'm not sure the way it is currently declared is the best way to do it. I'd prefer to define a new type for use in spec files, meaning a 64bit argument. Comments? BTW, for the moment VerifyVersionInfo seems to be the only place in Wine where the DWORDLONG type is used, but that doesn't mean there are no other unimplemented API using it. Vincent

1 0

Component owner for controls
by Andriy Palamarchuk 17 May '02

17 May '02

Does anybody want to voluteer to take ownership over usual controls? I already have owners for common controls Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

2 1