wine-devel October 2001

wine-devel@winehq.org

71 participants
173 discussions

Re: PATCH: Fix LoadCursor() under win9x
by Alexandre Julliard 12 Oct '01

12 Oct '01

Andreas Mohr <u4t5s0yq1001(a)sneakemail.com> writes: > Using your exception handler, LoadCursor() *always* returns 0 > on invalid parameter, which is WRONG in the NT 4 case > since it continues program execution without crashing. > > --> GetVersion() is required, check was (nearly) right IMHO. > Probably the best solution would be to use both an exception handler and > call GetVersion() on exception. Come on Andreas, we've been through this before. A version check must be added *only* when there is a real-life application that demonstrably depends on the version difference for proper behavior. So if you want the version check you'll have to show us an application that needs the crash in order to work right... -- Alexandre Julliard julliard(a)winehq.com

1 0

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

12 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, I think we need to differentiate two things: > - circular deps in normal imports > - circular refs of DLLs for delayed imports I consider that both are wrong. I think it's important to maintain proper layers and ensure that dll dependencies always go in one direction. Of course this is not always possible thanks to Microsoft design (or lack of it); but in the cases where we need to hack something I want it to be very explicit that something unusual is going on. If we make it so that any dll can easily import any other one, we'll quickly end up with an inextricable mess of cross-dll dependencies, simply because adding an import in the spec file for any dll that you may need is so much easier than having to use GetProcAddress and think about minimizing inter-dll calls because they are a pain to do. So there aren't really technical reasons we cannot do it, the issue is enforcing a structure by not making it too easy to do things the wrong way. -- Alexandre Julliard julliard(a)winehq.com

1 0

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

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

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 October 2001