- Wine-Devel - list.winehq.org

Re: Packing in mmsystem16 and supporting broken GetWindowLong use cases
by Joshua Thielen Nov. 21, 2001

Nov. 21, 2001

Jukka Heinonen wrote: >The second patch is because Wine mmsystem16 header does not use >correct packing which results into 48 byte structure taking >52 bytes and overwriting a pointer. This makes Civilization 2 >quite unhappy. Took almost a day to debug the game and >find out that the bugger who messes the pointer is really >waveOutGetDevCaps16... > Yessss! Thanks for finding this bug! It would have taken me ages to find it. Finale was choking awfully after calling midiInGetDevCaps. It would go into an endless loop, trashing my hard-drive and forcing me to do a hard reset on my box. Your patch fixes the problem. Cheers! Josh Thielen

1 0

Which is correct? listview or treeview?
by Bill Medland Nov. 21, 2001

Nov. 21, 2001

With regard to my problem that I was getting infinite redraws in my listview following Alexandre's change to server/user/message.c: I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be demonstrated easily on e.g. the MFC RowList sample with a two-line change). Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's data. Which is (more) correct? (And how does calling RedrawWindow once result in the repeated repainting of the treeview anyway?) I'm prepared to do the fix if no-one else can but I must admit that I am not really up on the details of the invalidation/paint etc Bill

1 0

New level of Shlwapi (parts 1 & 2)
by Guy L. Albertelli Nov. 21, 2001

Nov. 21, 2001

Most of the shlwapi upgrades have been driven by my desire to be able to run Outlook Express under Wine. (I know that there are other mail packages, but the rest of the home uses Windows - anyway it is a great test vehicle, uses everything ever implemented). The current status is as follows: With V4 or IE and OE - with builtin shlwapi,commctrl,comctl32 . IE displays page, can even do www.cnn.com, even runs javascript. + Certain menu popups either fail to display, or bomb. + Needs work in comctl32 rebar for extra space. . OE seems to basicly work. + Can display messages, change folders, and create messages. + Cannot invoke address book, but can request address list when creating new message. V5 of OE - requires native commctrl, comctl32: . With builtin comctl32 + OE fails to startup . With native commctrl, comctl32: + OE comes up but is mostly non-functional. Bombs on shutdown due to shlwapi.208 and shlwapi.210 V5 of IE - Does not start up yet. Requires native shlwapi . With native shlwapi, builtin comctl32 + IE has black toolbars with white lines. Menu line real small. . With native shlwapi and comctl32: + IE has black bitmaps for button bar. Mostly functional, however cannot access dropdown arrow for address bar. <sarcasm> I really appreciate the MS developer that decided to implement menus in OE5 with objects and put some of his "common" code in shlwapi. </sarcasm> Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: Improving DIB support for SHM
by Gavriel State Nov. 21, 2001

Nov. 21, 2001

Doh! I guess we've been too lax about integrating some of our non D3D work back into WineHQ. We did this in WineX some time ago, but with a couple of differences: 1) We don't restrict using XShmGetImage to the whole-screen case and 2) We save and restore the XImage mask fields around the call to XShmGetImage, which seems to like to write over those fields to no useful purpose. IE: /* We must save and restore the bmpImage's masks in order * to preserve them across the call to XShmGetImage, which * decides to eliminate them since it doesn't happen to know * what the format of the image is supposed to be, even though * we do. */ saveRed = bmpImage->red_mask; saveBlue= bmpImage->blue_mask; saveGreen = bmpImage->green_mask; XShmGetImage( gdi_display, descr->drawable, bmpImage, descr->xSrc, descr->ySrc, AllPlanes); bmpImage->red_mask = saveRed; bmpImage->blue_mask = saveBlue; bmpImage->green_mask = saveGreen; We'll probably get around to doing some merging back into WineHQ after our next release. -Gav Jukka Heinonen wrote: > > The following patch halves the time it takes to move units > from one square to another in Civilization 2. If SHM is supported, > the patch uses XShmGetImage instead of XGetSubImage when filling > the whole XImage (which is probably way too careful since SHM is > much faster than the alternative...). Hopefully this > version is paranoid enough to work with older XFree86 servers > where XShmGetImage might change the underlying XImage format > into XYPixmap. > > Changelog: > Try to use XShmGetImage instead of XGetSubImage if SHM is supported. > Do a sanity check before using XShmPutImage. > > Index: wine/graphics/x11drv/dib.c > =================================================================== > RCS file: /home/wine/wine/graphics/x11drv/dib.c,v > retrieving revision 1.82 > diff -u -r1.82 dib.c > --- wine/graphics/x11drv/dib.c 2001/11/05 23:52:18 1.82 > +++ wine/graphics/x11drv/dib.c 2001/11/21 12:39:42 > @@ -4473,7 +4473,7 @@ > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > descr->width, descr->height); > #ifdef HAVE_LIBXXSHM > - if (descr->useShm) > + if (descr->useShm && descr->image) > { > XShmPutImage( gdi_display, descr->drawable, descr->gc, bmpImage, > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > @@ -4519,9 +4519,26 @@ > TRACE("XGetSubImage(%ld,%d,%d,%d,%d,%ld,%d,%p,%d,%d)\n", > descr->drawable, descr->xSrc, descr->ySrc, descr->width, > lines, AllPlanes, ZPixmap, bmpImage, descr->xDest, descr->yDest); > - XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > - descr->width, lines, AllPlanes, ZPixmap, > - bmpImage, descr->xDest, descr->yDest ); > + > +#ifdef HAVE_LIBXXSHM > + if (descr->useShm && descr->image && > + descr->xDest == 0 && descr->yDest == 0 && > + descr->width == bmpImage->width && > + lines == bmpImage->height && > + XShmPixmapFormat( gdi_display ) == ZPixmap) > + { > + XShmGetImage( gdi_display, descr->drawable, bmpImage, > + descr->xSrc, descr->ySrc, AllPlanes ); > + if (bmpImage->format != ZPixmap) > + ERR( "XShmGetImage changed image format!\n" ); > + } > + else > +#endif > + { > + XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > + descr->width, lines, AllPlanes, ZPixmap, > + bmpImage, descr->xDest, descr->yDest ); > + } > > TRACE("Dib: depth=%2d r=%lx g=%lx b=%lx\n", > descr->infoBpp,descr->rMask,descr->gMask,descr->bMask); > > -- > Jukka Heinonen <http://www.iki.fi/jhei/> -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

cleaning up pthreads implementation - ABI problem
by Peter Hunnisett Nov. 21, 2001

Nov. 21, 2001

Howdy, I was just looking at cleaning up the pthreads implementation but I don't think that it's possible to have our pthreads implementation without providing binary compatibility with the pthread implementation we're hijacking. The reason is that the mutex and rwlock objects are supposed to be opaque to the programmer but in fact they are not opaque to the compiler. According to the standard, one doesn't have to call pthread_{mutex,rwlock}_init before using a {mutex,rwlock} as would be required with a totally opaque type. The standard allows for static initialization of the mutex and rwlock using PTHREAD_{MUTEX,RWLOCK}_INITIALIZER if you don't want any special attributes. libc does just this with its rwlock for gettext's global data. If you look at the ream of FIXME:pthread_rwlock_{rd,un}lock that sometimes come out starting wine you'll see that there's no call to pthread_rwlock_init. Of course, this stuff is safe because there's generally no writers wanting the pthread_rwlock_wrlock. So our current pthreads mutex implementation works in Linux by the skin of its teeth, becuase the first field in the mutex is reserved and initialized to 0 (in both the static and pthread_mutex_init cases), provided the version of LinuxThreads is new enough and a pointer is the same size as an int. Now I assume that this would mean it fails curiously for things that don't use LinuxThreads. This would also seem to mean, since we need binary compatibility, that things could even fail if someone upgrades their libc :( BTW, our check is presently basically only on __GLIBC__. Flavour me ignorant, and lazy, but I would assume that this not a Linux only symbol. So in fact the wine pthreads implementation might be already used incorrectly. Reader/Writer locks can be made to work the same way, as the mutex, since there are several fields which are initialized to NULL and we can then HeapAlloc our own structure off that field. We can then come up with weird and wonderful exceptions for the wonky cases that are sure to exist in some implementation of pthreads. Can anyone see a nice way out of this that I'm remaining ignorant to? I can't even think of a runtime way of detecting if our implementation is going to work. All in all I'm not too enthusiatic about the potential maintenance nightmare that this may provide but it would seem the only way is to have different mutex and rwlock structures depending on the pthreads implementation we're hijacking. Some code if people are more interested in details: >From glibc 2.2.4 /* Mutexes (not abstract because of PTHREAD_MUTEX_INITIALIZER). */ /* (The layout is unnatural to maintain binary compatibility with earlier releases of LinuxThreads.) */ typedef struct { int __m_reserved; /* Reserved for future use */ int __m_count; /* Depth of recursive locking */ _pthread_descr __m_owner; /* Owner thread (if recursive or errcheck) */ int __m_kind; /* Mutex kind: fast, recursive or errcheck */ struct _pthread_fastlock __m_lock; /* Underlying fast lock */ } pthread_mutex_t; #define PTHREAD_MUTEX_INITIALIZER \ {0, 0, 0, PTHREAD_MUTEX_TIMED_NP, __LOCK_INITIALIZER} What WINE uses (scheduler/pthread.c): /* assume that pthread_mutex_t has room for at least one pointer, * and hope that the users of pthread_mutex_t considers it opaque * (never checks what's in it) */ typedef struct { CRITICAL_SECTION *critsect; } *wine_mutex; rwlocks on the other hand are not so lucky as there's no unused bits: >From glibc-2.2.4 /* Read-write locks. */ typedef struct _pthread_rwlock_t { struct _pthread_fastlock __rw_lock; /* Lock to guarantee mutual exclusion */ int __rw_readers; /* Number of readers */ _pthread_descr __rw_writer; /* Identity of writer, or NULL if none */ _pthread_descr __rw_read_waiting; /* Threads waiting for reading */ _pthread_descr __rw_write_waiting; /* Threads waiting for writing */ int __rw_kind; /* Reader/Writer preference selection */ int __rw_pshared; /* Shared between processes or not */ } pthread_rwlock_t; # define PTHREAD_RWLOCK_INITIALIZER \ { __LOCK_INITIALIZER, 0, NULL, NULL, NULL, \ PTHREAD_RWLOCK_DEFAULT_NP, PTHREAD_PROCESS_PRIVATE } Ciao, Peter hunnise(a)yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

Re: _dev_t for MSVCRT
by Marcus Meissner Nov. 21, 2001

Nov. 21, 2001

On Tue, Nov 20, 2001 at 10:16:14PM +0100, Uwe Bonnes wrote: > Changelog: > include/msvcrt/sys/types: > _dev_t in a unsigned integer > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > Index: wine/include/msvcrt/sys/types.h > =================================================================== > RCS file: /home/wine/wine/include/msvcrt/sys/types.h,v > retrieving revision 1.2 > diff -u -r1.2 types.h > --- wine/include/msvcrt/sys/types.h 2001/10/22 18:59:24 1.2 > +++ wine/include/msvcrt/sys/types.h 2001/11/20 19:44:21 > @@ -15,7 +15,7 @@ > #endif > > > -typedef unsigned short _dev_t; > +typedef unsigned _dev_t; Dann sollte da aber 'unsigned int' stehen ;) Ciao, Marcus

1 1

Re: (no subject) (msvcrt.getenv)
by Francois Gouget Nov. 20, 2001

Nov. 20, 2001

On Tue, 20 Nov 2001, Uwe Bonnes wrote: > > Changelog: > dlls/msvcrt/environ.c: MSVCRT_getenv > Compare for the length of the key and return NULL in case of failure Good catch. Another thing to keep in mind: IIRC environment strings are not case sensitive on Windows. This means that normally getenv("PATH")==getenv("path") and that putenv("Path") would overwrite that same environment variable... This does not appear to be the case in the current code. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

1 0

winsock2.h
by lawson_whitney＠juno.com Nov. 20, 2001

Nov. 20, 2001

Good day! To try debugging techniques for winelib apps, I had in mind to make a winelib app with an intentional segment fault, and found that _my_ winelib app will no longer compile. (gcc-2.95.3, glibc-2.2.3, current wine CVS). Please, it needs unistd.h so it can comfortably log to syslog. running winemaker on it again didn't help. checking for wrc... /usr/local/bin/wrc updating cache ./config.cache creating ./config.status creating Make.rules creating Makefile creating launcher Configure finished. Do 'make' to build the project. [whit(a)giftie wlp]$ make gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o t oj2.o toj2.c In file included from /usr/local/include/wine/winsock2.h:30, from /usr/local/include/wine/windows.h:39, from toj2.h:29, from toj2.c:19: /usr/local/include/wine/winsock.h:886: conflicting types for `gethostname' /usr/include/unistd.h:734: previous declaration of `gethostname' make: *** [toj2.o] Error 1 [whit(a)giftie wlp]$ I would be glad of a bit of advice thanks, Lawson Constants aren't, and variables won't.

2 4

Civilization2 segment register troubles
by Jukka Heinonen Nov. 20, 2001

Nov. 20, 2001

Hi. I noticed that Civilization 2 has several problems under Wine. First, the game wants to access memory using segment register value zero, which causes protection exception since that is not allowed in protected mode. Second problem is that the game uses segment register value 0xf8, which Wine does not like. If I drop null-pointer protection [call to DOSMEM_Init(TRUE)], emulate cmp and mov commands so that they work even if using segment register value zero [added stuff to memory/instr.c] and make Wine accept segment register value 0xf8 [by hacking INSTR_ReplaceSelector], Civilization 2 starts to work without any problems. There are several possible reasons why the above changes make the game work: Wine corrupts segment registers somewhere, Civilization 2 wants to use privileged commands and Windows emulates them or the game runs in VM86 mode under Windows. So, I would like to get some ideas what should be done with Wine in order to get the game working. Oh, the above modifications fix protection faults that happen when the game tries to access the following addresses: 0x22, 0xc8, 0xf6, 0xf07c and 0xf0aa. P.S. Civilization 2 seems to work almost perfectly but it is painfully slow. I am pretty certain that I know the reason for this, but I would like to get the game working under official Wine before trying to make it run faster. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 2

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard Nov. 20, 2001

Nov. 20, 2001

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > What I questioned was the criticism that FreeBSD was guilty > of namespace pollution. Alexandre isn't the only wine > developer who made this statement (check usenet). The header > files in question are implementation dependent and can > contain any variable name or #define or typedef. The fact is > that both wine and FreeBSD have struct thread in implementation > header files. AFAICT, neither is incorrect. The Wine headers that define struct thread are only used inside Wine; the FreeBSD headers are used by applications, no matter how much you argue they are internal headers. So the situation is very different. > But, to have > a wine developer emphatically state that FreeBSD needs to > fix its system header files is somewhat surprising. Why is > it surprising to me? Because this reminds me a company here > in Seattle. I couldn't care less whether FreeBSD fixes its headers or not; we will need to work around the problem in Wine in any case. I was simply expressing the opinion that changing this would make FreeBSD better. I'm certainly not demanding that the FreeBSD guys fix it, if they feel exporting struct thread is a good idea it's their choice. -- Alexandre Julliard julliard(a)winehq.com

1 0