- Wine-Devel - list.winehq.org

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard Oct. 11, 2001

Oct. 11, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, after looking at some allocator algorithms, it seems to me there's > no reason to change neither the bin sizes nor the data structures. We just > have to change the free block selection algorithm - from my reading of the > code, right now it seems to always choose the *newest* (most recently > added) free block that's big enough. By changing it to always choose the > *oldest* free block instead, we'd already have a huge improvement. > (That's essentially the effect of Gav's patch, but only for big blocks, > but I suspect that could safely be done for *all* block sizes) I don't think that's a good idea. It's pretty bad for the cache and paging system to reuse oldest blocks first. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Gerard Patel Oct. 10, 2001

Oct. 10, 2001

At 06:46 PM 10/10/2001 +0200, you wrote: >No the application does a SendMessage > >096ed3f8:Call user32.SendMessageA(ffffffff,0000c00c,00000000,00000000) ret=004141aa ffffffff = Broadcast message. Take a look at this /*********************************************************************** * broadcast_message_callback * * Helper callback for broadcasting messages. */ static BOOL CALLBACK broadcast_message_callback( HWND hwnd, LPARAM lparam ) { struct send_message_info *info = (struct send_message_info *)lparam; if (!(GetWindowLongW( hwnd, GWL_STYLE ) & (WS_POPUP|WS_CAPTION))) return TRUE; GetWindowLong does not work currently between processes. There are a lot to do for the whole of Apis to work between processes yes, but there is not so much remaining for this kind of installer to work IMO. Gerard

1 0

Buisness Apps
by Nick Hudson Oct. 10, 2001

Oct. 10, 2001

Greetings, Has anyone got Quick Books Pro 2001 and ACT! 2000 to run on wine? In quick books I get this error when it goes to install it: fixme:ole:CoGetClassObject CLSCTX_LOCAL_SERVER not supported! and it says that the set up failed..... in ACT! 2001 I the install stalls out when I have to say what country I am in.... I have to ctrl+alt+F1 and do a killall to get rid of it. Also its not seeing my ethernet connection.... do I need to add anything to the config file to make this work right? I was trying to install IE over the web.... As far as I can tell it doesnt see that im on the network Thanks Nick Hudson

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Alexandre Julliard Oct. 10, 2001

Oct. 10, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > The WIN_FindWndPtr message flooded the xterm during install, so I supected > soething still wrong... There are still a *lot* of functions that need to be adapted for handles belonging to other processes, so yes if you run multiple processes right now you'll most likely get flooded with messages. Working on it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Alexandre Julliard Oct. 10, 2001

Oct. 10, 2001

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > No the application does a SendMessage > > 096ed3f8:Call user32.SendMessageA(ffffffff,0000c00c,00000000,00000000) ret=004141aa > err:win:WIN_FindWndPtr window 1002a belongs to other process > err:win:WIN_FindWndPtr window 10021 belongs to other process > err:win:WIN_FindWndPtr window 10029 belongs to other process > 096ed3f8:Ret user32.SendMessageA() retval=00000001 ret=004141aa > 096ed3f8:Call user32.SendMessageA(ffffffff,0000c00d,00000000,00000000) ret=004141bc > err:win:WIN_FindWndPtr window 1002a belongs to other process > err:win:WIN_FindWndPtr window 10021 belongs to other process > err:win:WIN_FindWndPtr window 10029 belongs to other process > 096ed3f8:Ret user32.SendMessageA() retval=00000001 ret=004141bc > > 096ed3f8 is a process created with Winexec, so I expect it to be a > sibling. Why isn't the WindowsFunction of at least that process called? It will be called only if the process has created a top-level window. Could you check if this is the case? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: CommandLineToArgvW fix
by Eric Pouech Oct. 10, 2001

Oct. 10, 2001

just a last question (that I didn't check) what if the process name contains spaces like: C:\Program Files\foo\bar.exe what does Windows do ? returns in argv[0] "C:\Program" or "C:\Program Files". The later would also require testing of existence of the directories (doing a more semantical approach while current implementation is purely syntaxical) A+ > > > Here's another version that uses GlobalLock... > I also retested in Windows and I believe the comment about spaces was > wrong. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > It really galls me that most of the computer power in the world > is wasted on screen savers. > Chris Caldwell from the GIMPS project > http://www.mersenne.org/prime.htm > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: wine/ include/win.h include/wine/server_protoc ...
by Gerard Patel Oct. 10, 2001

Oct. 10, 2001

At 04:55 PM 10/10/2001 +0200, you wrote: . > Alexandre> Implemented inter-process FindWindow(). > >Shouldn't this avoid errors like these: >err:win:WIN_FindWndPtr window 1002a belongs to other process >err:win:WIN_FindWndPtr window 10021 belongs to other process >err:win:WIN_FindWndPtr window 10029 belongs to other process Handles of other process windows can be returned by FindWindow, yes. But current Wine returns them also in enumeration functions, like EnumWindows. A functions like SetCursor, when trying to set the cursor for all desktop children, triggers this kind of message. The error message shows that Wine development is not complete because some function fails between processes (in SetCursor case, it is X11DRV_get_whole_window), not necessarily a problem in FindWindow. Try to lookup the origin for the handles : it is a problem only if the app get them from a FindWindow call. Gerard

2 1

Re: Compiling WINE on solaris 7
by Jeremy White Oct. 10, 2001

Oct. 10, 2001

> > First I thought this was a problem caused by the SUN as, but then I > installed the GNU as, and typed > "make clean; rm config.cache; configure && make depend && make" > but the problem remained. I suspect that the problem is that gcc is still invoking 'as' instead of 'gas'. My understanding is the only clean way to get gcc to use the GNU binutils is to rebuild it with such support. What we've done is very hackish, but seems to work - place symlinks called 'as', 'cc', and 'ld' that point to the respective GNU tools ahead of the 'normal' SUN tools in the PATH. HTH Jer

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Uwe Bonnes Oct. 10, 2001

Oct. 10, 2001

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: ... Alexandre> Implemented inter-process FindWindow(). Shouldn't this avoid errors like these: err:win:WIN_FindWndPtr window 1002a belongs to other process err:win:WIN_FindWndPtr window 10021 belongs to other process err:win:WIN_FindWndPtr window 10029 belongs to other process These errors still happens with the Quicklogic Installer. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Nasty Evil Memory Fragmentation fix
by Gavriel State Oct. 10, 2001

Oct. 10, 2001

We just spent about 3 days tracking down a very subtle memory fragmentation problem in an app we're working on. The problem: App allocates lots of little blocks, then a few large blocks, then lots of little blocks. Throughout this process, many blocks would be freed from all over the heap. Repeat ad infinitum. We ended up creating a new subheap every time one of these larger blocks came along. The new space from the subheap then went to the top of the freelist, so all the small allocations then filled it up until the next large block allocation. IE: We never got a chance to reuse freed blocks in older subheaps - at least not very well. This fix addresses the problem by pushing 'large' freed blocks to the end of the free list, leaving 'small' blocks at the front, to be found sooner. The size of 'large' vs 'small' is tunable. Despite the workaround, we're still not too pleased with the current heap allocator. It's quite slow, and still not as efficient as it could be. It would probably be worth the effort to integrate a new allocator - anyone know if there's a high-quality Wine-license- compatible allocator out there? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com --- heap.c Wed Sep 26 19:11:21 2001 +++ /home/gavriels/transgaming/wine/memory/heap.c Tue Oct 9 23:53:15 2001 @@ -59,6 +59,8 @@ #define QUIET 1 /* Suppress messages */ #define NOISY 0 /* Report all errors */ +#define FREE_BLOCK_INSERTION_THRESHOLD 4096 + #define HEAP_NB_FREE_LISTS 4 /* Number of free lists */ /* Max size of the blocks on the free lists */ @@ -229,11 +231,11 @@ /*********************************************************************** - * HEAP_InsertFreeBlock + * HEAP_InsertFreeBlockAtFront * - * Insert a free block into the free list. + * Insert a free block into the front of the free list. */ -static void HEAP_InsertFreeBlock( HEAP *heap, ARENA_FREE *pArena ) +static void HEAP_InsertFreeBlockAtFront( HEAP *heap, ARENA_FREE *pArena ) { FREE_LIST_ENTRY *pEntry = heap->freeList; while (pEntry->size < pArena->size) pEntry++; @@ -244,6 +246,31 @@ pEntry->arena.next = pArena; } +/*********************************************************************** + * HEAP_InsertFreeBlockAtEnd + * + * Insert a free block into the end of the free list. + */ +static void HEAP_InsertFreeBlockAtEnd( HEAP *heap, ARENA_FREE *pArena ) +{ + FREE_LIST_ENTRY *pEntry = heap->freeList; + + /* Determine which free list contains blocks of the appropriate size. */ + while (pEntry->size < pArena->size) pEntry++; + + /* But we want to put this block on the end of said appropriate free list. + * So instead, find the list for the next size up, knowing that they are + * all connected. */ + if (++pEntry == heap->freeList+HEAP_NB_FREE_LISTS) + pEntry = heap->freeList; + + pArena->size |= ARENA_FLAG_FREE; + pArena->next = &pEntry->arena; + pArena->prev = pEntry->arena.prev; + + pArena->next->prev = pArena; + pArena->prev->next = pArena; +} /*********************************************************************** * HEAP_FindSubHeap @@ -372,7 +399,11 @@ /* Last, insert the new block into the free list */ pFree->size = size - sizeof(*pFree); - HEAP_InsertFreeBlock( subheap->heap, pFree ); + + if ((pFree->size & ARENA_SIZE_MASK) > FREE_BLOCK_INSERTION_THRESHOLD) + HEAP_InsertFreeBlockAtEnd( subheap->heap, pFree ); + else + HEAP_InsertFreeBlockAtFront( subheap->heap, pFree ); }

2 1