July 2002 - Wine-Devel - list.winehq.org

Re: heads up: wine 20020605 broken on FreeBSD, workaround included

by Francois Gouget

On Mon, 1 Jul 2002, Marcus Meissner wrote: [...] > The [256] is evaluated and replaced by 256 by m4. So this is not a glibc, > but an autoconf problem. > > What is the autoconf version used there? The problem is with the contents of the 'configure' script in Wine CVS: line 10545 is ok: char buf[256]; but the following occurences are wrong: line 10588, 10631, 10674, 10717: char buf256; So the problem would be either with the autoconf that Alexandre is using, or with the configure.ac file. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

July 1, 2002

Re: heads up: wine 20020605 broken on FreeBSD, workaround included

by Marcus Meissner

On Mon, Jul 01, 2002 at 04:18:47PM +0200, Gerald Pfeifer wrote: > [ I'm now also Cc:ing this to the Wine developers, thus the full-quote. > In fact, all non-GLIBC platforms seem to be affected by this bug! ] > > Based on your pointer, I believe I found the problem. In aclocal.m4 we > have: > > AC_DEFUN([WINE_CHECK_ERRNO], > [AC_CACHE_CHECK([for reentrant libc: $1],[wine_cv_libc_r_$1], > [AC_TRY_RUN([int myerrno = 0; > char buf[256]; > int *$1(){return &myerrno;} > main(){connect(0,buf,255); exit(!myerrno);}], > wine_cv_libc_r_$1=yes, wine_cv_libc_r_$1=no, > wine_cv_libc_r_$1=yes)]) > AS_IF([test "$wine_cv_libc_r_$1" = "yes"],[$2],[$3])]) > > which, in configure, becomes: > > int myerrno = 0; > char buf256; > int *__error(){return &myerrno;} > main(){connect(0,buf,255); exit(!myerrno);} > > That is, instead of an array of 256 characters, we have one character, > and the invocation of connect() is definitely incorrect. > > Could someone more familiar with autoconf please have a look at this? The [256] is evaluated and replaced by 256 by m4. So this is not a glibc, but an autoconf problem. What is the autoconf version used there? Ciao, Marcus

July 1, 2002

Re: Usind win dll with wine

by Andriy Palamarchuk

--- psuchomel(a)volny.cz wrote: > Hi wine gurus > I have some dll, I want to run under Linux. I try to > study Wine > docs, but, if I say the truth, I did not make me > clever so much. > Please, could you help me port this part of win code > (extracted from > my java <--> cpp bridge) under Linux? Petr > > //define dll handler > HINSTANCE hInst = NULL; > //define entry in dll > typedef char* (_pascal * GLL_version)(); > > //here is some call > //load library > if( hInst == NULL ) > hInst = LoadLibrary("mylib"); > if( hInst == NULL ) > return; > //get proc address > FARPROC proc = GetProcAddress(hInst, "GLL_VERSION"); > //and call it > if (proc != NULL) > printf("%s", (char*)(GLL_version)proc()); > //free handler > FreeLibrary(hInst); > hInst = NULL; What exactly problem do you have? AFAICS you do not use anything fancy. Did you try to compile the code above on Windows and then execute on Wine? Does it work? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

July 1, 2002

Re: heads up: wine 20020605 broken on FreeBSD, workaround included

by Gerald Pfeifer

[ I'm now also Cc:ing this to the Wine developers, thus the full-quote. In fact, all non-GLIBC platforms seem to be affected by this bug! ] Based on your pointer, I believe I found the problem. In aclocal.m4 we have: AC_DEFUN([WINE_CHECK_ERRNO], [AC_CACHE_CHECK([for reentrant libc: $1],[wine_cv_libc_r_$1], [AC_TRY_RUN([int myerrno = 0; char buf[256]; int *$1(){return &myerrno;} main(){connect(0,buf,255); exit(!myerrno);}], wine_cv_libc_r_$1=yes, wine_cv_libc_r_$1=no, wine_cv_libc_r_$1=yes)]) AS_IF([test "$wine_cv_libc_r_$1" = "yes"],[$2],[$3])]) which, in configure, becomes: int myerrno = 0; char buf256; int *__error(){return &myerrno;} main(){connect(0,buf,255); exit(!myerrno);} That is, instead of an array of 256 characters, we have one character, and the invocation of connect() is definitely incorrect. Could someone more familiar with autoconf please have a look at this? Gerald On Mon, 1 Jul 2002, Scott Bolte wrote: > Over the weekend I tried to get wine 20020605 to run on a > new installation of FreeBSD 4.6. It took a while, I haven't > tried wine since 1997 after all, but I determined that my > problems were due to configure's reentrant libc test failing > when building the port. > > The wine_cv_libc_reentrant test in configure.ac first checks > for Linux (__errno_location) and then tests for FreeBSD > (__error). I don't have more time to figure out why, but > nesting the FreeBSD test that way results in a false > negative. The configuration will continue, as will the > build, but the resulting non-reentrant code goes into an > endless loop when trying to spawn threads. > > A crude workaround, for FreeBSD users at least, is to > replace the Linux test with the FreeBSD one. This needs to > be done before configure is run. I did it by hand, but I > expect the following code would do the trick. > > % cd /usr/ports/emulators/wine > % make patch > % perl -i -pe 's/__errno_location/__error/' work/wine-20020605/configure.ac > % make > % make install > > Below is the autoconf test script that demonstrates the > problem. It needs to be run in > /usr/ports/emulators/wine/work/wine-20020605/configure.ac > > Scott > > P.S. I'm not on the freebsd-emulators mailing list, but I > see from freebsd-questions that at least one other > person got wine to compile on 4.6. I can't explain > why it worked for him and not for me. However, I > installed a brand new copy of 4.6 from the standard > ISO images just to run wine. > > ---- testconf.ac > dnl Process this file with autoconf to produce a configure script. > dnl Original author: Michael Patra > dnl See ChangeLog file for detailed change history. > > m4_define(WINE_VERSION,regexp(m4_include(VERSION),[version $[-.0-9A-Za-z]+$],[\1])) > > AC_PREREQ(2.53) > AC_INIT([Wine],WINE_VERSION) > AC_CONFIG_SRCDIR(server/atom.c) > AC_CONFIG_AUX_DIR(tools) > > dnl **** Check for some programs **** > > AC_PROG_CC > > dnl **** Check for reentrant libc **** > > wine_cv_libc_reentrant=no > > dnl ##### > dnl ##### There is a problem if the FreeBSD test is nested > dnl ##### after the Linux test. In that instance, it fails. > dnl ##### If, on the other hand, it is tested first, it works. > dnl ##### > dnl ##### Swap the order of two following test case to see > dnl ##### how they differ. (Ignore the second case since it > dnl ##### will use cached data.) > dnl ##### > > dnl FreeBSD style errno location > WINE_CHECK_ERRNO([__error], [wine_cv_libc_reentrant=__error]) > > dnl Linux style errno location > WINE_CHECK_ERRNO([__errno_location], [wine_cv_libc_reentrant=__errno_location], > dnl FreeBSD style errno location > WINE_CHECK_ERRNO([__error], [wine_cv_libc_reentrant=__error] > )) > -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

July 1, 2002

Re: Bug #829 triggers lock-up in Baldur's Gate

by Ian D. Stewart

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 01 July 2002 06:21, Ian D. Stewart wrote: > On Sunday 30 June 2002 23:14, Tony Lambregts wrote: > > >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > > >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > > > > [snip] > > I don't know for sure that direct draw is what is locking it up, but > > this is not good. and could very well be why the program lock up. Why > > don't you start a bug report in bugzilla for this error and we can see > > if we can fix this first. Please include the steps to recreate the bug > > what you see/happens as well as what you expected to see/happen. > > > > >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > > >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > > > > While we are at it we need to fix this too. So if you could be so kind > > as to make a bug report for this one for this too. I will see what I can > > do msdn has this to say about DD_BLT_DDFX > > As noted by Lionel Ulmer, neither of these bugs appear to have any > (non-cosmetic) effect on the game and appear regularly without causing a > lock-up so long as you don't play any movies. > > I will go ahead and file bug reports regardless. Can't hurt having > something on record. Ok. I've filed these as Bug #840 and Bug #841 respectively. Ian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9IFjhAjpHQQmBAUMRApyIAJ91BUhBtx+T6L+R3PDeBJyzF8UuQwCghXrO QANGIqma/qfEEgEI2Yy4lgk= =Yq+n -----END PGP SIGNATURE-----

July 1, 2002

IsDialogMessageA/W question

by Sander van Leeuwen

Hi, Is there a specific reason why unprocessed messages in IsDialogMessage don't get dispatched? Experiments in Windows 2000 show this is not (always) correct. It seems all messages passed on to IsDialogMessage are dispatched and it always returns 1. IsDialogMessage doesn't call DispatchMessage, but the function called internally by DispatchMessage. Changing the behaviour to match Windows 2000 fixes at least one problem I noticed in an MFC application (button getting stuck when using the spacebar). There's not much information in MSDN about this function, so I can't say if IsDialogMessage always behaves like this. Sander

July 1, 2002

Re: Bug #829 triggers lock-up in Baldur's Gate

by Ian D. Stewart

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 30 June 2002 23:14, Tony Lambregts wrote: > > > >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > > [snip] > I don't know for sure that direct draw is what is locking it up, but > this is not good. and could very well be why the program lock up. Why > don't you start a bug report in bugzilla for this error and we can see > if we can fix this first. Please include the steps to recreate the bug > what you see/happens as well as what you expected to see/happen. > > >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > > While we are at it we need to fix this too. So if you could be so kind > as to make a bug report for this one for this too. I will see what I can > do msdn has this to say about DD_BLT_DDFX As noted by Lionel Ulmer, neither of these bugs appear to have any (non-cosmetic) effect on the game and appear regularly without causing a lock-up so long as you don't play any movies. I will go ahead and file bug reports regardless. Can't hurt having something on record. Thanx Again, Ian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9IC0cAjpHQQmBAUMRAnwwAJ9tjUabw/yjH0ogqRWJW9OXNAn+aACeKd9O audOXUKa3AINrEWih5/nF1A= =CJBK -----END PGP SIGNATURE-----

July 1, 2002

Re: Bug #829 triggers lock-up in Baldur's Gate

by Lionel Ulmer

> >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > > [snip] > I don't know for sure that direct draw is what is locking it up, but > this is not good. and could very well be why the program lock up. Why > don't you start a bug report in bugzilla for this error and we can see > if we can fix this first. Please include the steps to recreate the bug > what you see/happens as well as what you expected to see/happen. Well, this is an age old 'error' in Baldur's Gate. I never was able to know if this is a : 1) Wine bug that triggers this feature 2) a Baldur's Gate 'feature' that works also with MS's DirectX (ie that their drivers are doing the same checks than us for the size of the RECT). But it should be pretty harmless. Raise a bug report only if you plan to seriously investigate it (ie by doing a Windows program with a negative LPRECT and checking if it works or fails). Otherwise, I would say not to bother. > > >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > > While we are at it we need to fix this too. So if you could be so kind > as to make a bug report for this one for this too. I will see what I can do > msdn has this to say about DD_BLT_DDFX Well, that should not lock the game up... At worst, you will have some screen corruption (that is the case when choosing all the hardware accelerations on), but it should not lock up. Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 1, 2002

RFC PATCH: Fix unixism in shelllink.c

by Steven Edwards

I dont know if this will work or not and its untested under *nix as wine and my slack 8.1 install are still not getting along. WINE already implements _cwait so we should use it although I think this is wrong. Can someone check and fix it? http://www.opengroup.org/onlinepubs/007908799/xsh/wait.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/h… The next one may be a bigger PITA because shelllink.c calls fork =( Changelog: Replace Unixism in shell32 cvs diff -u Makefile.in Index: Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/shell32/Makefile.in,v retrieving revision 1.50 diff -u -r1.50 Makefile.in --- Makefile.in 14 Jun 2002 23:48:27 -0000 1.50 +++ Makefile.in 1 Jul 2002 08:29:24 -0000 @@ -5,7 +5,7 @@ VPATH = @srcdir@ MODULE = shell32.dll # fixme: avoid ole32.dll import -IMPORTS = ole32 shlwapi comctl32 user32 gdi32 advapi32 kernel32 +IMPORTS = ole32 shlwapi comctl32 user32 gdi32 advapi32 kernel32 msvcrt ALTNAMES = shell.dll EXTRALIBS = $(LIBUUID) $(LIBUNICODE) cvs diff -u shelllink.c Index: shelllink.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shelllink.c,v retrieving revision 1.40 diff -u -r1.40 shelllink.c --- shelllink.c 31 May 2002 23:25:52 -0000 1.40 +++ shelllink.c 1 Jul 2002 08:29:52 -0000 @@ -720,7 +720,7 @@ _exit(1); } - while (waitpid( pid, &status, 0 ) == -1) + while (_cwait( &status, pid, 0 ) == -1) { if (errno != EINTR) {

July 1, 2002

Re: Bug #829 triggers lock-up in Baldur's Gate

by Tony Lambregts

Ian D. Stewart wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Sunday 30 June 2002 20:02, Tony Lambregts wrote: > > >>Ian D. Stewart wrote: >> >> >>>After further research, it looks as if the lock-up in Baldur's Gate is >>>being triggered by an unsupported API Call. >>> >>>Here is the pertinent error message from Wine: >>> >>> fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or >>>DDBLT_ASYNC: can't handle right now. >>> >>>This fixme is only encountered during game 'movies' (including resting and >>>death scenes). >>> >>>I have a full logfile if anyone is interested. >>> >>> >>I am inclined to think that what is causing Baldur's Gate is not this >>but something else. The way that DDBLT_WAIT and DDBLT_ASYNC are handled >>is unlikely to cause a crash. However in order to determine if it is >>related I would be interested in the last 1000 lines of the trace. (for >>now). >> >> > >Tony, > >Thanx for looking at this. I've attached the last 1000 lines from the log >file. The log file was generated by running wine --debugmsg warn+ddraw. I >can also generate a trace+relay for you if you think it will help, but as I >mentioned in a previous e-mail, this particular combination hides the bug. > > >Ian > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.7 (GNU/Linux) > >iD8DBQE9H75oAjpHQQmBAUMRAtt5AKDGgXaTPyA1qgSTxzqH/F1onjDvUgCfYnIk >AFEq8qZ/Yq07MuvZg0SXaPs= >=buKS >-----END PGP SIGNATURE----- > > >------------------------------------------------------------------------ > >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! >err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! > > [snip] I don't know for sure that direct draw is what is locking it up, but this is not good. and could very well be why the program lock up. Why don't you start a bug report in bugzilla for this error and we can see if we can fix this first. Please include the steps to recreate the bug what you see/happens as well as what you expected to see/happen. >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX >fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX > > While we are at it we need to fix this too. So if you could be so kind as to make a bug report for this one for this too. I will see what I can do msdn has this to say about DD_BLT_DDFX > DDBLT_DDFX > Uses the *dwDDFX* member of the *DDBLTFX* > <http://msdn.microsoft.com/archive/en-us/ddraw7/directdraw7/ddref_0xmf.asp> > structure to specify the effects to use for this blit. > and these are the possible effects that need to be covered. of course we can only fix what we can test so it probably is only a subset of this . > *dwDDFX* > Type of FX operations. The following types are defined: > > DDBLTFX_ARITHSTRETCHY > Uses arithmetic stretching > <http://msdn.microsoft.com/archive/en-us/ddraw7/directdraw7/glossary_459v.as…> > along the y-axis for this blit. DDBLTFX_MIRRORLEFTRIGHT > Turns the surface on its y-axis. This blit mirrors the surface > from left to right. DDBLTFX_MIRRORUPDOWN > Turns the surface on its x-axis. This blit mirrors the surface > from top to bottom. DDBLTFX_NOTEARING > Schedules this blit to avoid tearing > <http://msdn.microsoft.com/archive/en-us/ddraw7/directdraw7/glossary_85rn.as…>. > DDBLTFX_ROTATE180 > Rotates the surface 180 degrees clockwise during this blit. > DDBLTFX_ROTATE270 > Rotates the surface 270 degrees clockwise during this blit. > DDBLTFX_ROTATE90 > Rotates the surface 90 degrees clockwise during this blit. > DDBLTFX_ZBUFFERBASEDEST > Adds the *dwZBufferBaseDest* member to each of the source > z-values before comparing them with the destination z-values > during this z-blit. DDBLTFX_ZBUFFERRANGE > Uses the *dwZBufferLow* and *dwZBufferHigh* members as range > values to specify limits to the bits copied from a source > surface during this z-blit. > Submit the bugs and lets see what can be done. Tony Lambregts

July 1, 2002