wine-devel

wine-devel@winehq.org

84463 discussions

Re: winebuild and circular DLL dependencies
by Alexandre Julliard 12 Oct '01

12 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, can this be done with delayed imports yet? I have a situation here > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed > imports). It would be nice if I could use the winebuild delayed import > mechanism to achieve this, instead of doing it manually with callout > tables and stuff... but I suppose winebuild has to be changed to read > the .spec files instead of using nm on compiled libraries... anyone > working on it? No, and I don't think it's a desirable feature, it's too error-prone. Besides, circular dependencies are really something to avoid, so it must not be too easy to do... (what does rpcrt4 need from ole32 BTW?) -- Alexandre Julliard julliard(a)winehq.com

3 2

BUG: mouse_event does not move pointer for relative coordinates
by Andriy P 12 Oct '01

12 Oct '01

The attached test program moves pointer under Windows NT. Under Wine the pointer changes position on move request in absolute coordinates and does not move for relative coordinates. I found out that variables PosX and PosY ARE updated in queue_mouse_event in windows/input.c. Can somebody give me a hint where to go from there? I don't see further any difference in processing between absolute and relative movement. In case somebody will fix this bug, don't worry about different relative distance reported under Windows and in Wine. I alredy fixed that part and will submit the patch soon. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re:winebuild and circular DLL dependencies
by Eric Pouech 12 Oct '01

12 Oct '01

well, I must have this somewhere in my tree, but didn't publish it because Alexandre was somehow reluctant to use this type of features (not the reading of missing symbols from .spec files, but the circular deps). Alexandre, any "new" comments ? A+ > Well, can this be done with delayed imports yet? I have a situation here > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed > imports). It would be nice if I could use the winebuild delayed import > mechanism to achieve this, instead of doing it manually with callout > tables and stuff... but I suppose winebuild has to be changed to read > the .spec files instead of using nm on compiled libraries... anyone > working on it? > > > > --------------- 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

1 0

winebuild and circular DLL dependencies
by Ove Kaaven 12 Oct '01

12 Oct '01

Well, can this be done with delayed imports yet? I have a situation here where ole32 imports stuff from rpcrt4 (windows uses delayed imports for that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed imports). It would be nice if I could use the winebuild delayed import mechanism to achieve this, instead of doing it manually with callout tables and stuff... but I suppose winebuild has to be changed to read the .spec files instead of using nm on compiled libraries... anyone working on it?

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Not that much. Wine's allocator already implements the *features* of that > allocator (boundary tags, bins), it just doesn't implement all the > *strategies* used for selecting which free block to allocate memory from > (though the only big things we lack there is "best fit" and "wilderness > preservation", the latter of which Alexandre talked about). Well, we do have (almost) best fit, that's the only reason for having multiple free lists. It's just that we probably need more bins sizes to make it really useful. > We just need > to make sure Wine's free block selection routine uses the same strategies > as this allocator, and we'd get exactly the same performance as that > allocator, but without replacing the whole thing and sacrificing the > compatibility we have or introducing new bugs. Well, this depends how easy it is to plug the new allocator in; but if it doesn't require too many changes, it will certainly introduce less bugs than trying to tweak the existing code. Plus all the profiling work has been done already, which would have to be done on the Wine code. -- Alexandre Julliard julliard(a)winehq.com

1 0

FIXME:pthread_rwlock_rdlock
by 510045342665-0001＠t-online.de 11 Oct '01

11 Oct '01

Hi, I am running a compiler with wine. There are many fixme message that I can't switch off. What do they mean, is someone working on it, is the problem serious ? Not having them at stdout would be great :-) as the compiler output + wine fixmes get a little confusing... [scan1.c] FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock --Dirk

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Gavriel State <gav(a)transgaming.com> writes: > 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. That's why we have multiple free lists. The code is using the Win95 values now, but there is no reason we couldn't add a few larger values in the HEAP_freeListSizes array, instead of creating a new mechanism. > 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? A new allocator would definitely be a good thing. This one was done the way it is in order to use a compatible memory layout, but it turns out this is not necessary so we could scrap it. -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: fixed FILE_GetUnixHanlde for sockets
by Andreas Mohr 11 Oct '01

11 Oct '01

On Thu, Oct 11, 2001 at 06:53:33PM +0200, Kai Morich wrote: > added sock_get_info in server/sock.c (patch includes changelog) "Patch includes changelog". hmm, patch. which patch ? which changelog ? ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

SHGetSpecialFolderPathA and CSIDL_FOLDER_MASK
by Chris Green 11 Oct '01

11 Oct '01

I've been looking at this function, and I am starting to suspect we have the wrong definition of CSIDL_FOLDER_MASK (currently 0x00ff). What I've been seeing (eg. installing MS Office 97) seems to imply that only the lower 6 bits, rather than 8, are related to the folder, and the others are something else. Does anyone else think that the mask should be 0x003f? regards Chris _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Gavriel State <gav(a)transgaming.com> writes: > This still doesn't help us: as Ove points out, we still end up allocating > from newly created free blocks even if old blocks would suit us better. But you want to use new blocks in general. The exception is that you want to avoid using the uncommitted part at the end of the heap, and I agree we could do a special case for that. But it has nothing to do with the size of the block. > I've had a brief look at the code referenced by Adam Moss (found at > http://g.oswego.edu/dl/html/malloc.html), and it looks like it would > be a vast improvement over Wine's current Heap manager. It even has > Windows code that uses VirtualAlloc to reserve actual memory. Yes, that would certainly be better that tweaking the existing code. You may want to look at ptmalloc too, it's supposed to be better at multi-threading (at least to get some ideas, the license is not 100% compatible with ours). -- 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