wine-devel

wine-devel@winehq.org

3 participants
84481 discussions

Buisness Apps
by Nick Hudson 10 Oct '01

10 Oct '01

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 10 Oct '01

10 Oct '01

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 10 Oct '01

10 Oct '01

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 10 Oct '01

10 Oct '01

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 10 Oct '01

10 Oct '01

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 10 Oct '01

10 Oct '01

> > 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 10 Oct '01

10 Oct '01

>>>>> "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 10 Oct '01

10 Oct '01

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

Fwd: Re: Remove annoying fatal_error() after wineserver crash
by Malte Starostik 10 Oct '01

10 Oct '01

Seems I'm too used to mailing lists which set Reply-to to the list... Am Wednesday 10 October 2001 01:15 schrieben Sie: > Malte Starostik <malte(a)kde.org> writes: > > not sure about the reason for that "the socket exists, but I can't > > connect" message, but IMHO it's pretty annoying. I hit this fatal_exit() > > very often while debugging reaktivate. And in such cases - or when > > starting an app from a desktop / startmenu icon - when wine's STDERR goes > > to ~/.xsession-errors instead of a shell, the user has no chance to > > figure why an app won't start. Well, long story, short patch which Works > > for Me (TM) but I don't know if there's anything wrong with doing this... > > The problem with this is that it creates a race condition and we may > end up with two servers running in the same directory, which is bad. > > The error message should only happen when a previous server has > crashed, which is a critical error (the server should never crash no > matter what the app does). In that case you should also have a core > file in the same directory as the socket, which you can use to debug > and fix the crash. Thanks for the hint, I'll try to reproduce it with an appropriate ulimit set. But right, an actual wineserver crash didn't happen in a while. Unfortunately I have some system instability currently, so many times the message was caused by a stale socket lying around after a solid lockup of my box. What tends to happen rather often though is that wineserver keeps running after I quit all windows/winelib apps and consumes 100% CPU. In some of such cases, it'll only die on SIGKILL, which also leaves a socket around. I agree that neither a system lockup nor a hanging wineserver should happen though :) Maybe there could be a wineserver.pid file in the same dir and only if the process identified therein doesn't exist anymore, the socket will be autoremoved? But after all it's not too big a problem, guess there are more important issues. -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]

2 1

Re: Remove annoying fatal_error() after wineserver crash
by Alexandre Julliard 09 Oct '01

09 Oct '01

Malte Starostik <malte(a)kde.org> writes: > not sure about the reason for that "the socket exists, but I can't connect" > message, but IMHO it's pretty annoying. I hit this fatal_exit() very often > while debugging reaktivate. And in such cases - or when starting an app from > a desktop / startmenu icon - when wine's STDERR goes to ~/.xsession-errors > instead of a shell, the user has no chance to figure why an app won't start. > Well, long story, short patch which Works for Me (TM) but I don't know if > there's anything wrong with doing this... The problem with this is that it creates a race condition and we may end up with two servers running in the same directory, which is bad. The error message should only happen when a previous server has crashed, which is a critical error (the server should never crash no matter what the app does). In that case you should also have a core file in the same directory as the socket, which you can use to debug and fix the crash. -- Alexandre Julliard julliard(a)winehq.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel