wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Problem cloning wine repository with git...
by Scott Bambrough 05 Apr '06

05 Apr '06

I'm having trouble cloning the wine repository. I attempt to clone it and never get any files. All I ever see is: $ git clone http://source.winehq.org/git/wine.git wine-git defaulting to local storage area I've followed the instructions found here: http://wiki.winehq.org/GitWine I've tried the following commands in an attempt to clone the wine repository: git clone git://source.winehq.org/git/wine.git wine-git git clone http://source.winehq.org/git/wine.git wine-git I'm using git version 1.0.4. I've also tried the latest version of the getwinegit.sh shell script with the same results. I've managed to use git to clone the kernel and git source trees, so git is working on my system. I started the clone of the wine source and let it run over lunch for an hour with no files. If anyone has an idea of what I'm doing wrong, or how to debug the problem I'd appreciate the help. I'm a git newbie. Cheers, Scott

2 2

Re: Alexandre Julliard : configure: Filter out garbage from arts-config --libs too.
by Marcus Meissner 05 Apr '06

05 Apr '06

On Tue, Apr 04, 2006 at 05:37:44AM -0500, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 197a7d0422b2dd60009e405bc254ca616327fbf0 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=197a7d0422b2dd60009e405… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Apr 4 12:08:30 2006 +0200 > > configure: Filter out garbage from arts-config --libs too. > > --- > > configure | 9 ++++++++- > configure.ac | 9 ++++++++- > 2 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index 9bffafd..c825171 100755 > --- a/configure > +++ b/configure > @@ -10855,7 +10855,14 @@ then > -I*) ARTSC_CFLAGS="$ARTSC_CFLAGS $i";; > esac > done > - ARTSC_LIBS=`$ARTSCCONFIG --libs` > + ARTSC_LIBS="" > + for i in `$ARTSCCONFIG --libs` > + do > + case "$i" in > + -L/usr/lib|-L/usr/lib64) ;; > + -L*|-l*) ARTSC_LIBS="$ARTSC_LIBS $i";; > + esac > + done It also adds -L/opt/kde/lib64 for me, so this will likely not fully work. I would say we just do not configure arts and esd on 64->32 compiles. :/ Ciao, Marcus

2 4

Re: [PATCH] - rewrote toolhelp implementation only on top of ntdll functions
by Alexandre Julliard 05 Apr '06

05 Apr '06

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > + l = min(ldr_mod[i].BaseDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szModule, ldr_mod[i].BaseDllName.Buffer, l); > + mod->szModule[l / sizeof(WCHAR)] = '\0'; > + l = min(ldr_mod[i].FullDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szExePath, ldr_mod[i].FullDllName.Buffer, l); This can't work, the dll name and path are in the address space of the target process. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wined3d/OpenGL question
by Jason Green 05 Apr '06

05 Apr '06

I may be barking up the wrong tree here, but I'm trying to debug the cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in drawprim.c (line 1251). This is for Civilization 4 using both hardware vertex & pixel shaders. I've only noticed this error when it is passed GL_TRIANGLES with a large number of vertices. Here's a sample output with a little extra debugging info, and cleaned up a little: trace:d3d_draw:primitiveToGl TRIANGLES trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, number of vertices1156 trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, number of vertices1156 ... trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader trace:d3d_draw:drawPrimitiveDrawStrided glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok drawprim.c / 1846 trace:d3d_draw:drawPrimitiveDrawStrided glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from glDrawRangeElements @ drawprim.c / 1251 Often, a series of these errors will result in an unhandled exception in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 kernel). I read up on the glDrawElements() function and it refered to the GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call that function, it returns 4096, and the number of vertices that it's trying to pass is larger than that. I've tried doing a min() of the max and the actual # of vertices, but the results are the same. So, the question is: Could this be one of the causes of the graphical glitches I'm seeing? I can toy around with these functions all day, but I don't really understand them all that well. Does that routine need to be reworked to split up a D3DPT_TRIANGLELIST into multiple calls if the calculated number of vertices/indices is too high for the user's graphics card? Or, am I way off base thinking this has any bearing on my real issues? Thanks, Jason

3 4

d3d: unhandled texture formats
by Ivan Gyurdiev 05 Apr '06

05 Apr '06

The F.E.A.R and BF2 demos crash immediately after complaining about: fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16) fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT! I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that have no wine implementation. According to msdn: D3DFMT_A16B16G16R16 36 64-bit pixel format using 16 bits for each component. D3DFMT_L16 81 16-bit luminance only. The second one is missing from wined3d_private.h Both are missing from D3DFmtGetBpp. Also note that there's default handling in D3DFmtGetBpp that says: /* Guess at the highest value of the above */ and selects 4 bytes per pixel, but the highest value of the above is 8 - and it's used by D3DFMT_A16B16G16R16 - maybe that's why it crashes.

3 4

XVidMode is required for Gamma Control
by Jesse Allen 05 Apr '06

05 Apr '06

I've found that XVidMode is required for gamma control, and that it defaults to off. There are two bug reports about gamma. One is Diablo 2 as it fails to run at all in D3D mode because of it (and with a cryptic error too). The other is the gamma slider fails to produce the effect. There are three ways to fix the problem: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this. 2) Make UseXVidMode default to "Y". 3) Tell people to set UseXVidMode manually. Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default. Jesse

7 16

Re: wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi 05 Apr '06

05 Apr '06

[ Charset UTF-8 unsupported, converting... ] > hurtta+wine(a)leija.mh.fmi.fi wrote: > > >http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > > > > > > > >>It's OK that most people don't have fontforge installed, that just > >>means that people who can't cope with compiling from source and can't > >>satisfy all the required dependencies to create a working binary > >>shouldn't do it. They need to use a prepackaged one from a > >>confidential source who knows what is needed and how to resolve the > >>dependencies. > >> > >> > > > > > >Perhaps because there is NO binary available on > >list of http://www.winehq.org/site/download > Then they can check their distributions source package tree (pkgsrc, > ports, etc.) or binary tree (which compliments pkgsrc, ports, etc. and > is compatable.) > > I mean, come on, can it be that hard to look in ports? If distribution is 4 years old, wine is also. Distributions works good enough, but 4 year old is little different. Or have you different opinion?

1 0

Re: richedit20: Implement EM_FORMATRANGE
by Phil Krylov 04 Apr '06

04 Apr '06

On Tue, 4 Apr 2006 11:46:18 +1000 Troy Rollo <wine(a)troy.rollo.name> wrote: > + * *** Notes on tables *** > + * > + * The CHARRANGE structure passed in the FORMATRANGE structure is not > + * sufficient to deal with tables, where we would need information on the > + * start position for text in each column of the table. > + * > + * Testing on Windows NT shows that the Microsoft Rich Edit control gives > + * pathological results when there are tables in the document - both in edit > + * mode and for EM_FORMATRANGE. The Microsoft Rich Edit control uses the > + * table solely as a hint to where the paragraph should start. The table > + * does not expand to fit its text. Long paragraphs wrap when you hit the > + * right page margin and continue at the left page margin. This is only true for RichEdit 2.0 - later versions have better table support, while our current implementation is approximately at 2.0 level. -- Ph.

2 1

wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi 04 Apr '06

04 Apr '06

http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > It's OK that most people don't have fontforge installed, that just > means that people who can't cope with compiling from source and can't >satisfy all the required dependencies to create a working binary > shouldn't do it. They need to use a prepackaged one from a > confidential source who knows what is needed and how to resolve the > dependencies. Perhaps because there is NO binary available on list of http://www.winehq.org/site/download / Kari Hurtta

1 0

cvs help for bug #4541, Wine > 20050725 with FreeBSD 6.0
by Lee Parsons 04 Apr '06

04 Apr '06

Hello I submitted the bug #4541 regarding running the application WinMDI on wine in FreeBSD 6.0: http://bugs.winehq.org/show_bug.cgi?id=4541 I have begun regression testing on this bug. I have determined that it seems to break on 20050921, as 0921 works and 0922 does not. However, I have been unable to cvs checkout any particular versions of wine for that day. For example, if I look at the wine-cvs archives for that day, and want to checkout for the patch submitted 05:20:20, I run the command: lparsons@r32_1600$ cvs -d $CVSROOT checkout wine "2005-09-21 05:20 CDT" which ends up returning: cvs checkout: cannot find module `2005-09-21 05:20:20 CDT' - ignored I would like to be able to determine which patch specifically is responsible. Any help with CVS would be useful here. thank you Lee Parsons

2 1

Re: wined3d: Also print the format like a fourcc if unknown in debug_d3dformat.
by Alexandre Julliard 04 Apr '06

04 Apr '06

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -94,7 +94,7 @@ const char* debug_d3dformat(WINED3DFORMA > FMT_TO_STR(WINED3DFMT_CxV8U8); > #undef FMT_TO_STR > default: > - FIXME("Unrecognized %u D3DFORMAT!\n", fmt); > + FIXME("Unrecognized %u (as fourcc: %s) D3DFORMAT!\n", fmt, debugstr_an((CHAR*)&fmt,4)); Using %c%c%c%c as format would be better than a debugstr hack. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: Wined3d/OpenGL question
by James Trotter 04 Apr '06

04 Apr '06

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Apr 4, 2006 8:16 PM Subject: Re: Wined3d/OpenGL question To: Jason Green <jave27(a)gmail.com> On 4/4/06, Jason Green <jave27(a)gmail.com> wrote: > > I may be barking up the wrong tree here, but I'm trying to debug the > cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in > drawprim.c (line 1251). This is for Civilization 4 using both > hardware vertex & pixel shaders. I've only noticed this error when it > is passed GL_TRIANGLES with a large number of vertices. > > Here's a sample output with a little extra debugging info, and cleaned > up a little: > > trace:d3d_draw:primitiveToGl TRIANGLES > trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, > number of vertices1156 > trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, > number of vertices1156 > ... > trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader > trace:d3d_draw:drawPrimitiveDrawStrided > glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok > drawprim.c / 1846 > trace:d3d_draw:drawPrimitiveDrawStrided > glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 > trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) > fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from > glDrawRangeElements @ drawprim.c / 1251 > > Often, a series of these errors will result in an unhandled exception > in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 > kernel). > > I read up on the glDrawElements() function and it refered to the > GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call > that function, it returns 4096, and the number of vertices that it's > trying to pass is larger than that. I've tried doing a min() of the > max and the actual # of vertices, but the results are the same. > > So, the question is: Could this be one of the causes of the graphical > glitches I'm seeing? I can toy around with these functions all day, > but I don't really understand them all that well. Does that routine > need to be reworked to split up a D3DPT_TRIANGLELIST into multiple > calls if the calculated number of vertices/indices is too high for the > user's graphics card? Or, am I way off base thinking this has any > bearing on my real issues? > > Thanks, > Jason > > > GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES are just performance hints, and not actual limits to how many vertices or indices that the driver can handle. From http://pyopengl.sourceforge.net/documentation/manual/glDrawRangeElements.3G… : "Implementations denote recommended maximum amounts of vertex and index data, which may be queried by calling glGet with argument GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES. If end - start + 1 is greater than the value of GL_MAX_ELEMENTS_VERTICES, or if count is greater than the value of GL_MAX_ELEMENTS_INDICES, then the call may operate at reduced performance. There is no requirement that all vertices in the range [start,end] be referenced. However, the implementation may partially process unused vertices, reducing performance from what could be achieved with an optimal index set." Also, "GL_INVALID_OPERATION is generated if glDrawRangeElements is executed between the execution of glBegin and the corresponding glEnd."

1 0

wine / fontforge regression
by Molle Bestefich 04 Apr '06

04 Apr '06

Hello, This patch from Mar 9: http://www.winehq.org/pipermail/wine-cvs/2006-March/021502.html causes all applications run with Wine to continually emit: err:font:ReadFontDir Can't open directory "/usr/local/bin/../lib/../share/wine/fonts/" when fontforge isn't installed. Also, take a look at the path above. It's relative to '/usr/local/bin', ok - but why the double descend into the parent directory? The "../lib" seems completely redundant with the "../share" coming right after it. Regards

8 13

Re: compile error
by Tom Spear 04 Apr '06

04 Apr '06

On 4/4/06, MF <mforcada(a)freesurf.ch> wrote: > > Hi Tom, > > After make depend, last lines give this message: > quote > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.UrlAln.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > unquote Aha! Ok, so make dep and make are failing before they are able to build any of the tools like winecfg and wineprefixcreate... That is due to your 64-bit libraries being installed in the default location, and your 32-bit ones being installed elsewhere.. Do you happen to have a /usr/lib32 directory? If so, try doing the build like this: make distclean LDFLAGS=/usr/lib32 ./configure make dep make sudo make install and then do the wineprefixcreate and run winecfg.. Let us know if you have any problems after that.. Of course if you do have a lib32 dir, but it is not /usr/lib32, substitute the path to your lib32 dir where I put /usr/lib32 (it shouldn't be just /lib32).. Of course someone on the list could tell you the exact path to the directory if you would be so kind as to tell us what distro you are using. :-) Tom

1 0

re: richedit20: Implement EM_FORMATRANGE
by Dan Kegel 04 Apr '06

04 Apr '06

Hi Troy, any chance you can also provide a conformance test, however trivial? (Also, from reading http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=973… http://support.microsoft.com/default.aspx?scid=kb%3Ben%3B129860 http://www.codeproject.com/printing/richeditprint.asp I gather that some but not all apps will also require EM_DISPLAYBAND to make use of this, right? Just curious.) Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

compile error
by MF 04 Apr '06

04 Apr '06

Hi, System: Dell Power Edge 830, Intel Dual Core, Linux Ubuntu 5.10, 64 bits version Tried to compile Wine with the ./tools/wineinstall as per recommended procedure in readme file, from sources package downloaded with apt-get build-dep wine and apt-get --build source wine wich did not go 100% well...: quote Reading package lists... Done Building dependency tree... Done Need to get 13.5MB of source archives. Get:1 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (dsc) [1209B] Get:2 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (tar) [13.5MB] Get:3 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (diff) [47.0kB] Fetched 9537kB in 35s (268kB/s) dpkg-source: extracting wine in wine-0.9.10~winehq1 dpkg-source: unpacking wine_0.9.10~winehq1.orig.tar.gz dpkg-source: applying ./wine_0.9.10~winehq1-2.diff.gz dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.10~winehq1-2 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot dh_testroot: You must run this as root (or use fakeroot). make: *** [clean] Error 1 Build command 'cd wine-0.9.10~winehq1 && dpkg-buildpackage -b -uc' failed. E: Child process failed end quote The directory "wine-0.9.10~winehq1" was created OK and the package source seemed to be there. So I tried "./tools/wineinstall" and got the following message: quote configure: creating cache config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Configure failed, aborting install. end quote re-did the whole thing after clean up and tried the dpkg command in sudo and got quote ~/wine-0.9.10~winehq1$ sudo dpkg-buildpackage -b -uc dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.10~winehq1-2 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot rm -f build-stamp # Add here commands to clean up after the build process. /usr/bin/make distclean make[1]: Entering directory `/home/formig/wine-0.9.10~winehq1' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/formig/wine-0.9.10~winehq1' make: [clean] Error 2 (ignored) #-/usr/bin/make -C documentation clean dh_clean debian/rules build dh_testdir # Add here commands to configure the package. CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... yes checking for x86_64-linux-gnu-gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [config.status] Error 77 unquote Seems to be an error with my C compiler ? GCC IS 4:4.0.1-3 I attach config.log for more details. Any idea ? With kindest regards, Miguel

4 5

Re: advpack: Rewrite get_parameter so that it can handle empty parameters [RESEND]
by Alexandre Julliard 04 Apr '06

04 Apr '06

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Rewrite get_parameter so that it can handle empty parameters. You are still parsing the whole string for every parameter, this is O(n^2) which isn't very nice. What you want is a strtok-style function to retrieve parameters sequentially. -- Alexandre Julliard julliard(a)winehq.org

1 0

Pegasus Mail via Wine
by James E. Lang 04 Apr '06

04 Apr '06

I have been using Pegasus Mail via Wine for nearly two years. Before that I used Pegasus Mail on a Win98 system for several years. Since Wine officially entered Beta category in late 2005, I have tried most of the releases (starting with 0.9.3). Pegasus functioned quite well with Wine Versions 0.9.3, 0.9.5, 0.9.6, 0.9.7, & 0.9.8. Wine Version 0.9.4 was unusable. Wine Versions 0.9.9 and 0.9.10 both sent Pegasus a signal to shut itself down when the message composition window got closed. As Rein Klazes wrote on 11 Mar 06 @ 06:20 re: user32: Handle WM_ENDSESSION in DefWinProc(): > On Fri, 24 Feb 2006 14:29:45 -0600, you wrote: > > Author: Francois Gouget <fgouget(a)codeweavers.com> > > Date: Fri Feb 24 15:34:09 2006 +0100 > > > > user32: Handle WM_ENDSESSION in DefWinProc(). > > DefWinProc() should call PostQuitMessage() on WM_ENDSESSION if the > > shutdown is proceeding. > > Hi Francois, > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. > Here is a part of SPY++ log when run under win2000, when I close the > edit new mail dialog ... I don't know whether this is fixed in Wine Version 0.9.11 since I cannot get Pegasus Mail to perform any useful function with that version of Wine. With Wine Version 0.9.8 Pegasus Mail would load on my computer and display my list of e-mail folders within 30 seconds. With Wine Version 0.9.11 Pegasus Mail still does not display the folder list after 15 minutes. Pegasus Mail's startup window *does* display for the proper time interval. "Technical" Observations: When I use Wine Version 0.9.8 and use KDE System Guard to view the running processes I see that the process that is running the bash shell that runs Pegasus Mail has one Wine related offspring process ("Wine-preloader") and that offspring uses about 598,000 bytes of RAM. When I use Wine Version 0.9.11 there is that same process but it in turn has an offspring process of its own (also "Wine-preloader") which uses about 41,500 bytes of RAM. During the time that Wine was failing to display the normal things for Pegasus Mail I noticed that the value of VmRss (resident virtual memory?) increased in very small increments (usually 8 bytes at a time) two or three times a minute. The total VmSize (Virtual Memory Size?) value did not change. It is remotely possible that given enough time (measured in hours maybe) that Pegasus Mail would have finally displayed something useful. What I'm trying to say is that I have not been able to use any version of Wine after 0.9.8 to support Pegasus Mail and I'm trying to pass along a description of what I see. I have no debug code activated and do not know what debug options would be appropriate. -- Jim

1 0

[opengl] Another possible fix for the BadMatch error
by Leon Freitag 03 Apr '06

03 Apr '06

Someone mentioned earlier that the code in wgl.c in DescribeDrawable() violates the GLX specification and therefore causes bogus return values for the visualid. However this code has been already present before the regression, but worked somehow. So the regression can't be caused by this violation. I tried to correct this violation by calling glXChooseFBConfig and then glXGetChooseConfigAttrib, as suggested in the spec, and glXChooseFBConfig returns NULL for the appropriate FBCONFIG_ID. However the problem seems to be in getting Drawable which is then passed to DescribeDrawable. The VisualID of the Drawable isn't needed at all, since before calling the glXMakeCurrent, we just want to know if the context visualid differs from visualid of Wine desktop. This one-liner should fix the BadMatch errors. Tested on Warcraft 3. http://winehq.org/pipermail/wine-devel/2006-March/thread.html ------ diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c index c7d3147..e9046ca 100644 --- a/dlls/opengl32/wgl.c +++ b/dlls/opengl32/wgl.c @@ -551,7 +551,7 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, draw_vis_id = describeDrawable(ctx, drawable); ctx_vis_id = describeContext(ctx); - if (-1 == draw_vis_id || (draw_vis_id == visualid && draw_vis_id != ctx_vis_id)) { + if (visualid != ctx_vis_id) { /** * Inherits from root window so reuse desktop visual */ Please test this patch and report if it works. If it works fine (and doesn't introduce any regressions) then I'll submit it to wine-patches. Leon

3 2

Re: winebuild: Add an "x86_64" flag
by Alexandre Julliard 03 Apr '06

03 Apr '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Add an "x86_64" flag in winebuild so we can export 64-bit-only > functions in a 64-bit build. Are there really enough functions that would need this to justify adding a new flag? -- Alexandre Julliard julliard(a)winehq.org

2 2

AppDB email address obfuscation
by n0dalus 03 Apr '06

03 Apr '06

Hi, I am concerned that the email addresses on the appdb are too easily harvestable. Is there a reason no effort seems to be made to hide the email addresses of users on there? Also, when getting a notification of a post, you can see everyone's email addresses in the To: field. Should these be Bcc? Just curious, n0dalus.

3 2

Re: Implement THREAD_PRIORITY_TIME_CRITICAL
by Andreas Mohr 03 Apr '06

03 Apr '06

Hi, On Fri, Mar 31, 2006 at 02:06:23PM +0100, Mike Hearn wrote: > This patch gives me rock solid audio in Imperium Galactica 2, so now the > game works perfectly. > > There has been discussion around this issue with respect to security in > the past, however, regardless of what approach is adopted this code will > have to be written anyway. Ah, thanks, nice to see that it actually helps. > + scheduler = SCHED_FIFO; IMHO we should really add some smart detection of SCHED_ISO kernel capability and *much* prefer to use that one then. One really wouldn't want to hang the box... Not to mention that SCHED_FIFO requires root, which is an absolute PITA. Nice To Have would be support for stuff such as SCHED_IDLEPRIO and SCHED_BATCH... > + if (result == -EPERM) > + { > + static int need_warning = 1; > + > + if (need_warning) > + { > + fprintf( stderr, "\nwineserver: Failed to promote the priority of a time critical thread.\n" ); > + fprintf( stderr, "Audio may destabilise. To fix this re-run the application as root.\n\n" ); > + need_warning = 0; > + } > + > + return; > + } Make that static int already_warned; /* static: = 0! */ Since static uses 0 as default and you don't want to waste space in the .bss(?) segment for an explicit 1 init. Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)

8 18

Re: [Bug 4979] New: wine .9.11 make fails on AMD64
by Tom Spear (Dustin Booker, Dustin Navea) 03 Apr '06

03 Apr '06

Wine Bugs wrote: > http://bugs.winehq.org/show_bug.cgi?id=4979 > > Summary: wine .9.11 make fails on AMD64 > Product: Wine > Version: 0.9.11. > Platform: PC-x86-64 > OS/Version: Linux > Status: UNCONFIRMED > Severity: normal > Priority: P2 > Component: wine-patches > AssignedTo: wine-bugs(a)winehq.org > ReportedBy: nospam(a)thenerdshow.com > > > Seems like this old bug is back, identical to this one, possibly? > http://www.winehq.com/hypermail/wine-devel/2004/01/0598.html > > Trouble building wine .9.11 & CVS on AMD64. It's linking 64 bit libraries again > :( Passing LDFLAGS="-L/usr/lib" --libdir=/usr/lib to configure doesn't help, > either. > > make[2]: Entering directory `/home/fozner/install/wine/dlls/winmm/winearts' > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -shared > ./winearts.drv.spec arts.o audio.o > -Wl,--rpath,\$ORIGIN/`../../../tools/relpath /usr/local/lib/wine /usr/local/lib` > -o winearts.drv.so -L../../../dlls -lwinmm -luser32 -lkernel32 -lntdll > -L../../../libs -lwine -L/usr/lib64 -ldl -lartsc -lpthread -lgmodule-2.0 -ldl > -lgthread-2.0 -lglib-2.0 -L../../../libs/port -lwine_port > /usr/lib64/libdl.so: could not read symbols: File in wrong format > > Rudimentary regression test: > wine .9.10 works fine with just ./configure && make depend && make. > wine .9.11 fails with above error > Today's CVS also fails. > > I can get it to build with some editing of the makefiles, but that's not the > point of this exercise. > > I figured this was important enough to forward to the list. Alexandre, could (should) there be a --dont-link-64bit-libs flag added to configure please, or maybe a --without-64bit-libs? Tom

3 4

You don't have administrator privileges on this computer ... (whats changed in 0.9.11?)
by Roland Kaser 03 Apr '06

03 Apr '06

Hello I just tried to make my usual test installations on the new 0.9.11 release. But at this time the setup responses (in german) Sie haben keine Verwaltungsprivilegien auf diesem Computer. Setup kann nicht fortgesetzt werden. (You don't have administrator privileges on this computer. Setup cannot be continued..). Can somebody tell me whats happend to the username mapping in 0.9.11 what can I do to avoid those messages? Thanks Roland Kaeser

3 2

What's uuid 33ad4ed2-6699-11cf-b70c-00aa0060d393?
by Dan Kegel 03 Apr '06

03 Apr '06

http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=33ad4… turns up seven apps which fail with errors like fixme:ole:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393} http://www.google.com/search?q=33ad4ed2-6699-11cf-b70c-00aa0060d393 turns up quite a few hits for 33ad4ed2-6699-11cf-b70c-00aa0060d393, but they're all wine errors, no definitions. I presume this UUID is associated with riched20's COM interface, but I don't know how to check. Anyone know? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

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