November 2001 - Wine-Devel - list.winehq.org

wineconsole compile error
by Andreas Mohr Nov. 24, 2001

Nov. 24, 2001

Hi all, people get make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o dialog.o dialog.c dialog.c: In function `WCUSER_GetProperties': dialog.c:492: structure has no member named `u' dialog.c:496: structure has no member named `u' dialog.c:500: structure has no member named `u' dialog.c:509: structure has no member named `u3' This is happening on gcc 3.0.2 (nameless union support, I suppose). On my system, this file compiles painlessly: root(a)andi:/root# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20010902 (Debian prerelease) (no nameless union support, I suppose) I told this guy to replace .u. and .u3. in dialog.c with DUMMYUNIONNAME and DUMMYUNIONNAME3, respectively. This caused: dialog.c:492: parse error before `.' dialog.c:496: parse error before `.' dialog.c:500: parse error before `.' dialog.c:509: parse error before `.' I thought that this particular error was caused by a missing #include "winnt.h", but adding this didn't help either. Please fix this "mess" ASAP (in an appropriate way, one that I seem to not be able to find out :-\). Thank you ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany "Point is, nothing here is unfamiliar or unexpected. How long does it take before there's general recognition that Microsoft software has no business on the Internet? - Dennis E. Powell re: Code Red

1 0

Re: Where are we going on multiuser?
by Alexandre Julliard Nov. 23, 2001

Nov. 23, 2001

"Bill Medland" <medbi01_1(a)accpac.com> writes: > What is our vision on support for multiple users on a single computer? > > I know that WINEPREFIX allows us to use something other than $HOME/.wine for > the base of everything but as far as I can see the whole design still > requires a different WINEPREFIX for each user. (e.g. the socket is in > wine-server-<hostname> and there is no apparent support for the system.reg, > user.reg and userdef.reg being in different places). You need one WINEPREFIX per user yes. You can use global registry files by creating symlinks to global files in the user WINEPREFIX. The usual way is to wrap your app in a shell script that will populate the user's WINEPREFIX if it doesn't exist yet. There are plans for splitting registry files into separate sections with some kind of include mechanism, but nothing implemented yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

Where are we going on multiuser?
by Bill Medland Nov. 23, 2001

Nov. 23, 2001

What is our vision on support for multiple users on a single computer? I know that WINEPREFIX allows us to use something other than $HOME/.wine for the base of everything but as far as I can see the whole design still requires a different WINEPREFIX for each user. (e.g. the socket is in wine-server-<hostname> and there is no apparent support for the system.reg, user.reg and userdef.reg being in different places). Bill

1 0

Re: fix documentation compilation error
by Andreas Mohr Nov. 23, 2001

Nov. 23, 2001

On Fri, Nov 23, 2001 at 01:35:14AM +0100, Michael Stefaniuc wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Add missing </para> in documentation/packaging.sgml Ouch ! Hmm, better make an actual compile next time :-\ Sorry !! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

A window painting problem.
by Duane Clark Nov. 22, 2001

Nov. 22, 2001

Howdy, Perhaps this is one of those things that is in work. But this patch causes one of the (sub)windows in the app Xilinx fpga_editor (commercial) to never get painted. The app has several windows within a window, including a scrolled window, which after the patch I can zoom in and out and move the scrollbars just fine. But the contents never get painted, no matter what I do, including hiding and reshowing, etc. All the other pieces and windows are painted fine. http://cvs.winehq.com/patch.py?id=1005773317852080273907632 Log message: Moved WIN_FindWinToRepaint functionality to the server. Duane

1 0

Re: Which is correct? listview or treeview?
by Gerard Patel Nov. 22, 2001

Nov. 22, 2001

At 01:58 PM 21/11/2001 -0800, you wrote: >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? I have seen the same problem with the plain listbox I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing directly a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway. So I intended at some point to look at Listview and Treeview (with the nasty intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it. OTOH, I have myself - at least ;-( - one regression pending for this patch. The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ? I'm not too hopeful as it does not seem related but you never know. Gerard --- winpos.c.orig Tue Nov 13 23:02:20 2001 +++ winpos.c Thu Nov 22 00:24:35 2001 @@ -1464,6 +1464,14 @@ /*********************************************************************** * X11DRV_ConfigureNotify */ + +Bool predicate(Display *display, XEvent *event, char *arg) +{ + Window w = *((Window *) arg); + return ((event->type == ConfigureNotify) && + (event->xany.window == w)); +} + void X11DRV_ConfigureNotify( HWND hwnd, XConfigureEvent *event ) { HWND oldInsertAfter; @@ -1472,8 +1480,20 @@ RECT rect; WINDOWPOS winpos; int x = event->x, y = event->y; + XConfigureEvent ev; if (!(win = WIN_GetPtr( hwnd ))) return; + + while (XCheckIfEvent(event->display, (XEvent *)&ev, + predicate, (XPointer)&event->window)) + { + event->x = ev.x; + event->y = ev.y; + event->width = ev.width; + event->height = ev.height; + event->above = ev.above; + event->send_event = ev.send_event; + } data = win->pDriverData; /* Get geometry */

2 1

thanksgiving prayer
by lee Nov. 22, 2001

Nov. 22, 2001

...wishing everyone a special thanksgiving filled with great joy, special friends and loved ones as we move forward to a brighter tomorrow, carrying with us the best of yesterday and the promise of today- lee

1 0

Crashing menus, event handling broken?
by Jukka Heinonen Nov. 22, 2001

Nov. 22, 2001

While playing Civilization 2, I noticed that Wine crashes if I click menu bar twice while the game is thinking. The reason for this is that raw hardware messages get processed before menu event loop starts. Raw event processing turns raw events into cooked events and because menu event loop has not started yet, game window is not capturing events and thus clicks on menu bar are turned into nonclient messages. These cooked messages are put back into message queue. When menu event loop starts, it receives the second nonclient button press event and passes it to DispatchMessage. Default window procedure creates a new menu event loop and since the nonclient message was still in the event queue (it would have been removed if DispatchMessage had returned), we get a nice stack overflow. The real problem is not in menu event loop but in the fact that Wine event handling forgets that we can't determine whether a mouse event is nonclient event or not unless we have already called window procedure for all previous mouse events. This is because one of those calls might have for example captured mouse input after which we no longer report nonclient events. Since event handling is quite complicated and this flaw looks more like a design error than coding bug, I would like to get some discussion about what should be done to fix this problem. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

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

Re: LibaudioIO Patch for Solaris
by eric pouech Nov. 20, 2001

Nov. 20, 2001

Robert Lunnon wrote: > > Attached find files for libaudioio patch for audio on solaris 7 > > winmm.diff - Only the makefile patch is significant wavemap, just contains > some extra debugging traces > > libaudioio.tar, libaudioio goes under winmm > > base.diff, Patches to configure.in and Makefile.in to better support Solaris > and Libaudioio > > config.h.in added HAVE_SOLARIS and HAVE_LIBAUDIOIO and added a way for force > a 32 bit mmap. a few comments : - why do you add the libaudioio lib to winmm ? it should only be linked against the libaudioio (or whatever) driver... winmm should be independant of any driver... - in the libaudioio subdir: + you shouldn't use C++ comment. wine is a C project + it would a good idea to remove any reference to OSS in libaudioio... + I don't think that libaudioio supports midi... so, the preferred way to handle this would be to create a driver which doesn't export the midMessage and modMessage, and to get rid of midi.c and midipatch.c (same for mixMessage/mixer.c and auxMessage/aux.c) (it seems midi.c and mixer.c are protected by non existent HAVE_LIBAUDIO_MIDI and HAVE_LIBAUDIOIO_MIXER which are defined nowhere) + so the driver should only be made of the wave.c part and oss.c (which should be renamed to IMO) + anyway, I think that the libaudioio subdir should be named against the name of the DLL, which is audioio (eventually, since it's a wine only DLL, and to prevent DLL name collisions, I'd call it wineaudioio(.drv) - I don't see any reasons to define HAVE_SOLARIS... this is a wrong practice for system dependancies anyway A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

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: > Can you please explain how this is namespace pollution on the > part of the OS? AFAIK, <sys/user.h> is not specified by any > Standard (ISO C89, C90, or C99). <sys/user.h> can include > any (unprotected) variable name. Yes of course it can, but the fact that this isn't explicitly forbidden by some standard doesn't mean it's good practice or that it doesn't pollute the namespace. sys/user.h is also legally allowed to do "#define if else"; that doesn't make it a good idea. > If an application includes > <sys/user.h>, then the application should be prepared to > deal with conflicts. Great, then you need to fix all applications every time someone feels like exporting a new symbol from user.h. Of course user.h is a pretty obscure header so it's no big deal, but it would be easier to avoid exporting stuff under such common names as "struct thread". -- Alexandre Julliard julliard(a)winehq.com

4 4

interesting comment about WINE from MS
by Igor Nov. 20, 2001

Nov. 20, 2001

As far as WINE and Mono are concerned, I'm just not sure whether these organizations will end up being able to produce satisfactory products. The real problem is this: it is not good enough for WINE to run some Windows apps. If the general public is going to consume it, it must run all Windows apps. Windows 2000/XP has a significant level of POSIX compliancy, but many developers just don?t write their apps with these standards in mind. You'll find pieces of code everywhere in third party apps which run statements like if (WINVER==4.0 && GrokTheBIOSForSomeACPIGoo()), which have not been tested to see whether they will run on non-Windows/x86 platforms. In fact, Microsoft has had to put in significant time and effort to insure that older Win32 applications originally written to run in Win95 will run in NT." original article is here http://www.osnews.com/story.php?news_id=314

1 0

Implementation of TB_REPLACEBITMAP
by Marco Bizzarri Nov. 20, 2001

Nov. 20, 2001

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I'm trying to provide an implementation of TB_REPLACEBITMAP Included is the patch I've done to record the bitmaps which are provided to the toolbar and to replace them when the message arrives. Even though the number of buttons displayed is correct, the output is otherwise garbled. I would appreciate any suggestion on this topic. The platform is a RH Linux 6.2. wine is from CVS (20/11/2001) - -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE7+oUXXhfyAQQVoaIRAudsAJ9QEbPYChk0YpTonozvkjUge4HtjACgl8cg A87v4vPHKOeeCgj6LpW18dw= =J2rq -----END PGP SIGNATURE-----

1 0

audio.c fault reproduction
by Simon Britnell Nov. 20, 2001

Nov. 20, 2001

I downloaded and ran the QuickTime installer and the Pajama Sam demo last PM. I have reproduced the problem with Pajama Sam (it seems that ends of samples are either not playing or being overwritten), but I can't get QuickTimePlayer.exe to do anything at all. I'll investigate the Pajama Sam problems over the remainder of the week. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

RE: MIDL and COM
by Patrik Stridvall Nov. 20, 2001

Nov. 20, 2001

> On 16 Nov 2001, Alexandre Julliard wrote: > > > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > > > But can the machine-generated sources that MIDL outputs > be put into the > > > official Wine source? > > > > I'd prefer not. If we want to use .idl files we'll have to come up > > with our own compiler, and then we can put the .idl source > in the tree > > and compile it at build time. > > Hmm. Even when using flex and bison, it sounds like a fair amount of > work... wonder who would volunteer? There already are a multitude of open souce (GPL and otherwise) CORBA .idl compilers. Of course Wine have probably slightly different requirements but I should guess that we could save 90% of the work compared to writing it from scratch. Alexandre: Is a GPL:ed (or possible different licenced) .idl compiler acceptable? > > > And how about source IDL files? Can we put into Wine IDL > extracted from > > > real Windoze .tlb files with a tool like oleview.exe, or > IDL parsed from > > > MIDL-generated Windows SDK .h files, like objidl.h, with a script? > > > > No, anything generated from a Windows file is copyrighted by > > Microsoft, so we cannot distribute it. We need to rewrite > these files > > from scratch, just like we do for the normal headers. > > Now where are all the usual non-lawyers on this list who > would argue that > API definitions, like prototypes in header files (which of > course IDL, as > a formalized API spec format, is all about), cannot be copyrighted? > Oh well... I'm here. :-) Well, I wouldn't really go quite that far. The API definitions in themselves can't be copyrighted, true. But a specific way of expressing them is, so compiling any Microsoft file will generate create a derived work copyrighted by Microsoft as the main rule. However it is not quite that easy, since only the specific expression is protected, the compilation result is only a derived work if it still contains any protected expression. In light of this you could argue that since, I presume, MIDL removes whitespace and commments which is IIRC the only really expression, since the rest the API defintions are just facts, that the MIDL compiled files just contains facts not any part of the protected expression. However that is a little thin line to walk, since there is quite of lack of real cases in the area, so I would recommend that we do as Alexandre suggest. Beside having the real .idl files in the Wine tree might be useful for other things as well.

1 0

Re: MIDL and COM
by Alexandre Julliard Nov. 20, 2001

Nov. 20, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Problem 1: MIDL-generated code. > midl.exe is Microsoft's IDL compiler, it reads .idl files which describe > RPC and COM interface, from which it generates .c files, .h files, and > typelibs. (It is possible to find copies of midl.exe floating on the net, > as some people have put together "COM kits" for Borland C++ that contains > midl.exe and some standard .idl files and put them on the web) > > But can the machine-generated sources that MIDL outputs be put into the > official Wine source? I'd prefer not. If we want to use .idl files we'll have to come up with our own compiler, and then we can put the .idl source in the tree and compile it at build time. > And how about source IDL files? Can we put into Wine IDL extracted from > real Windoze .tlb files with a tool like oleview.exe, or IDL parsed from > MIDL-generated Windows SDK .h files, like objidl.h, with a script? No, anything generated from a Windows file is copyrighted by Microsoft, so we cannot distribute it. We need to rewrite these files from scratch, just like we do for the normal headers. > Problem 2: RPCSS > rpcss.exe is the place that keeps track of which process owns which RPC > endpoints, exported COM objects, and object activation tables. > The IRunningObjectTable interface, for example, is managed by rpcss.exe, > and keeps track of certain kinds of COM objects on the computer, so that > other processes can connect to running COM objects. We probably don't want > Wine to have to run a separate process for this? If not, can we put this > kind of COM stuff into the wineserver? I'd prefer having a separate process, at least in the first stage. -- Alexandre Julliard julliard(a)winehq.com

2 1