http://bugs.winehq.org/show_bug.cgi?id=19412
Summary: Red Alert 3: GL_INVALID_VALUE when rendering text on Mac OS Product: Wine Version: unspecified Platform: Macintosh URL: http://na.llnet.cnc3tv.ea.com/u/f/eagames/cnc3/cnc3tv/ RedAlert/RedAlert3PCDemo.exe OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: cdavis@mines.edu
In C&C: Red Alert 3 running under the latest git on a Mac running Leopard, text characters will often fail to render. This only happens in RA3 AFAICT. Other programs render text fine. It happens with every version of RA3 to date (including 1.12).
I noticed that every time D3D fails to render a character (or a group of characters), this (or something like it) shows up in the log:
fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glCompressedTexImage2DARB @ surface.c / 526
3D graphics appear to be otherwise unaffected.
I didn't actually start a game; this even happens in the menus. It is particularly noticeable on the Settings screen (from the main menu, expand the Options menu, then click on Settings). You can't see any of the text in the drop-down list boxes, and if you're REALLY unlucky, some of the title text will be missing.
It's been like this with GLSL as long it's worked under Wine on Mac OS. (It doesn't work at all under ARB. By the time the necessary functionality was implemented, ARBvp was broken on Mac OS.) From what I can tell, it works fine on Linux, so this might be a bug in Xquartz instead of Wine. Perhaps I should file a bug with the Xquartz people as well.
Setting the offscreen rendering mode to backbuffer doesn't help. Neither does turning off rendering fonts with XRender. (It doesn't work at all with pbuffer as the offscreen rendering mode.) Even turning the in-game settings all the way down doesn't help.
My computer is a Santa Rosa MacBook Pro with a 2.4 GHz Intel Core 2 Duo T7700 CPU and an nVidia GeForce 8600M GT GPU. I'm using THE driver for Mac OS (the one that came with the OS). I'm pretty sure that this is NOT a dupe of bug 16146.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #1 from Charles Davis cdavis@mines.edu 2009-07-21 22:30:05 --- Uhh, for some reason, I can't seem to attach logs, patches, screenshots, etc. to bugs. If you need a log, please email me.
http://bugs.winehq.org/show_bug.cgi?id=19412
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Red Alert 3: |Red Alert 3: fails to |GL_INVALID_VALUE when |render a character |rendering text on Mac OS |
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2009-07-22 07:39:40 --- Wine version?
http://bugs.winehq.org/show_bug.cgi?id=19412
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Platform|Macintosh |PC
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #3 from Charles Davis cdavis@mines.edu 2009-07-22 14:45:31 --- I thought I said "latest git," as in the latest Wine sources from WineHQ's git repository. As I write this, that puts it after Wine 1.1.26.
It happens with earlier versions, too. I even did a regression test to see if it was a regression or not. (It's not as far as I can tell.)
I see you changed the summary. Is this a problem on other platforms too? I got the impression that it worked very well on Linux (seeing that one person gave it a "Platinum" rating in the AppDB). Then again, not all Linux distros are equal.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #4 from Charles Davis cdavis@mines.edu 2009-07-23 03:42:53 --- Created an attachment (id=22547) --> (http://bugs.winehq.org/attachment.cgi?id=22547) Screenshot of problem
Here's a screenshot that clearly shows the problem. Note how most of the text is either missing or rendered incompletely.
I cropped it to make it fit in less than 1 MB (the maximum size for attachments).
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #5 from Charles Davis cdavis@mines.edu 2009-07-24 14:00:56 --- Created an attachment (id=22583) --> (http://bugs.winehq.org/attachment.cgi?id=22583) Wine Log with +d3d_surface
Here's a log with WINEDEBUG=+d3d_surface. It's too big without compression, so I bzip2-compressed it, then stored the bzip2-compressed log in a zip archive. Hope this helps.
http://bugs.winehq.org/show_bug.cgi?id=19412
Charles Davis cdavis@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.1.26
--- Comment #6 from Charles Davis cdavis@mines.edu 2009-07-27 18:08:56 --- Oh yeah. One more detail. Right now, I'm running Xquartz 2.4.0 RC1 (with fix for bug 287, which I reported; see http://xquartz.macosforge.org/trac/ticket/287).
It's been about a week and nobody has said anything about this bug. I understand that Wine users on Mac OS are far and few between, but come on!
By the way, I changed the version against which I reported the bug. Happy now, vitamin? (IMHO, there really needs to be an entry for the version in git.)
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #7 from Charles Davis cdavis@mines.edu 2009-07-27 18:12:25 --- Hmm... Bugzilla seems to think that by "bug 287," I was referring to Wine. I wasn't. I was referring to Xquartz, in case that wasn't clear earlier. Please don't follow the "bug 287" links that Bugzilla "helpfully" created for me; they aren't relevant to this bug. (That feature is useful sometimes, but I wish there were a way to turn that off for selected comments. Maybe I should go to Bugzilla and ask for this feature...)
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #8 from Henri Verbeet hverbeet@gmail.com 2009-07-28 05:15:21 --- (In reply to comment #6)
It's been about a week and nobody has said anything about this bug. I understand that Wine users on Mac OS are far and few between, but come on!
The issue isn't so much the amount of users on OS X, but the amount of developers. Afaik that's only Stefan and me for D3D, and mostly because CodeWeavers pays us to care about OS X.
As for the actual bug, does disabling the PBO extension make it any better?
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #9 from Charles Davis cdavis@mines.edu 2009-07-28 12:44:52 --- (In reply to comment #8)
(In reply to comment #6)
It's been about a week and nobody has said anything about this bug. I understand that Wine users on Mac OS are far and few between, but come on!
The issue isn't so much the amount of users on OS X, but the amount of developers.
Right. That's what I meant to say. (For some reason, stuff I say often comes out wrong...)
Afaik that's only Stefan and me for D3D, and mostly because CodeWeavers pays us to care about OS X.
Well, at least someone cares, so I don't care if it's because you're getting paid to care. I'd offer to help you guys out, but I'm not very familiar with OpenGL or Direct3D.
As for the actual bug, does disabling the PBO extension make it any better?
Actually, yes it does. I can tell you're onto something here.
I noticed something else that might be interesting. When I first start the game (this is with the PBO extension on), the problem is at its worst, even interfering with gameplay. But after I played one game of RA3, I noticed that the problem was not as severe. In fact, it was barely noticeable. I wonder why...
http://bugs.winehq.org/show_bug.cgi?id=19412
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #10 from Henri Verbeet hverbeet@gmail.com 2009-07-28 13:45:48 --- This is probably an interaction between PBOs and client storage. Although neither extension explicitly mentions this, it would make sense that you can't use both client storage and a PBO when specifying a texture image. The comment in surface_allocate_surface() seems to agree.
Unfortunately we don't use glCompressedTexSubImage2D() but glCompressedTexImage2D() in surface_upload_data(), which respecifies the texture. The comment there seems to indicate this was a workaround for a driver bug, but perhaps we should get rid of that. The other option would probably be to disable either PBOs or client storage for compressed textures if both extensions are available.
Stefan added the client storage code, so adding him to CC.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #11 from Charles Davis cdavis@mines.edu 2009-07-28 14:30:37 --- (In reply to comment #10)
This is probably an interaction between PBOs and client storage. Although neither extension explicitly mentions this, it would make sense that you can't use both client storage and a PBO when specifying a texture image. The comment in surface_allocate_surface() seems to agree.
Unfortunately we don't use glCompressedTexSubImage2D() but glCompressedTexImage2D() in surface_upload_data(), which respecifies the texture. The comment there seems to indicate this was a workaround for a driver bug, but perhaps we should get rid of that. The other option would probably be to disable either PBOs or client storage for compressed textures if both extensions are available.
Stefan added the client storage code, so adding him to CC.
That makes sense--well, as much sense as I can make out of the extremely complex wined3d code. (Not for OpenGL neophytes... at least I understand the comments.) That also explains why it only happens on Mac OS (client storage is one of Apple's GL extensions).
Seriously, how many people still have an ATI R200 chip? I don't. Then again, I wonder, considering that Apple, not nVidia, wrote the Mac OS X GeForce drivers, if their driver has many of the same quirks as their ATI drivers.
http://bugs.winehq.org/show_bug.cgi?id=19412
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #12 from Stefan Dösinger stefandoesinger@gmx.at 2009-07-28 14:36:32 --- Actually the comment wrt the glCompressedTexSubImage2D needs to be updated. Its not just the r200 chip that has this problem, this GL call is fubar on Macs too(Nvidia, Intel, maybe even ATI). If you make Wine use it, it will break pretty badly.
If you think this is a problem of PBOs vs client storage, try to disable client storage and keep PBOs on. If it still works, Henri's suspicion is right. If it doesn't, but disabling PBOs helps its a PBO problem(most likely a mac driver bug if it works on Linux). Xquartz usually cannot be blamed for GL rendering issues, it just passes any non-GLX calls through to OSX 1:1.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #13 from Henri Verbeet hverbeet@gmail.com 2009-07-28 14:43:17 --- It does mention the "MacOS ATI driver", but isn't very specific about which version of OS X or which cards. I don't see how client storage can work without an actual client pointer.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #14 from Charles Davis cdavis@mines.edu 2009-07-28 15:13:53 --- (In reply to comment #12)
Actually the comment wrt the glCompressedTexSubImage2D needs to be updated. Its not just the r200 chip that has this problem, this GL call is fubar on Macs too(Nvidia, Intel, maybe even ATI). If you make Wine use it, it will break pretty badly.
That's a shame.
If you think this is a problem of PBOs vs client storage, try to disable client storage and keep PBOs on. If it still works, Henri's suspicion is right. If it doesn't, but disabling PBOs helps its a PBO problem(most likely a mac driver bug if it works on Linux).
Disabling GL_APPLE_client_storage while keeping GL_ARB_pixel_buffer_object on causes the problem to disappear, too. Henri is right: this is definitely a PBO-client storage interaction issue.
Xquartz usually cannot be blamed for GL rendering issues, it just passes any non-GLX calls through to OSX 1:1.
I knew that, but it's just that the Xquartz libGL didn't even support shaders properly until 2.3.2, and it didn't support GLSL at all until around 2.3.3. (Of course, GLSL support on Mac OS didn't matter with Wine until you worked around a bug in OS X GLSL support.)
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #15 from Charles Davis cdavis@mines.edu 2009-07-28 17:35:48 --- I seem to have better luck with GL_APPLE_client_storage than with GL_ARB_pixel_buffer_object. (With PBOs, for some reason, I get stack overflow exceptions somewhere in the heap manager. I know I get them in the heap manager because it takes the exception while holding the heap critical section, so when another thread tries to allocate memory, that thread blocks. But that's another bug, for another day.)
So, my recommendation is to disable PBOs where GL_APPLE_client_storage is supported (e.g. Mac OS) until you can come up with a proper fix.
http://bugs.winehq.org/show_bug.cgi?id=19412
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #16 from Stefan Dösinger stefandoesinger@gmx.at 2009-07-29 05:19:07 --- Disabling client storage is not that easy either, I originally added it to work around bugs in the Mac GL driver, and to gain a few megabytes of address space.
The problem is that I don't know enough about the nature of the bugs worked around with client storage. When I added it 2 or 3 years ago, the symptom was random texture loss. By now I have broken down the texture loss bug into a few separate issues that cause the same symptoms and reported them to Apple. Apple might have fixed some problems too, but I don't know how many remain.
Since Radar reports are not publically accessible I'll dump a few details here:
6965386: glGetCompressedTexImage fails on srgb compressed textures Reproduced on a GMA X3100 and Radeon X1600, so probably a bug in the general framework. Wine by default releases resource->HeapMemory after loading the GL texture, and loads the GL texture back if it needs it(unless this happens all the time, then wine keeps the copy). The client storage code happens to work around this bug because the heapMemory copy is never released. The use of the GL extension doesn't have anything to do with the workaround, its just a different behavior of the wine code that does this.
???????: glTexImage2D with NULL pointers fails. Maybe that's the bug I worked around originally with client storage, but I am not entirely sure. Its also a by luck workaround, since just always passing a valid pointer to glTexImage2D is enough, you don't have to use client storage. I think I reported this to apple, but I can't find it in my radar list atm. (No sRGB textures or compression involved here, fwiw)
6958082: glCompressedTexSubImage2D fails with sRGB compressed textures Only partially related, but that's one of the reasons why we can't use compressedTexSubImage. Reproduced on a GMA X3100, but maybe affects other cards too.
???????: compressed sRGB textures fail with client storage. That one was reported by Ken, so I can't look up the number. It is fixed in Snow Leopard, and actually an argument against using client storage. Just including it here for completeness. The bug results in a div by zero exception in the GL code.
The phantom menace bug is a random texture loss without actually doing anything with the texture. You load it, it works for a while, and boom, it is random garbage. My suspicion is that this happens when the texture is not used for a while, paged out of video memory and reloaded. Either OSX mismanages the backup copy, or fails to download it due to VM pressure, I don't know. People from Transgaming also say they see this bug, so I am not hallucinating. It is possible that this was fixed in Leopard. I saw it in Tiger, but TG claims it still exists even in Snow Leopard. The real-life symptom is that e.g. in HL2, you look at a scene, it looks fine. You turn around, shoot a few zombies, everything's ok. You turn around again, look at the original scene, and walls are complete garbage. Textures can turn into garbage while you look at them too, but that's comparably rare. The garbage can look like this for example: http://stud4.tuwien.ac.at/~e0526822/hl2_texture_1.jpg
Using client storage works around this issue.
The other reason for using client storage is to move the backup copy into VM areas managed by Wine, thus reducing the pressure in the small address space areas Wine does not have to block. However, we probably have enough leeway to disable client storage for selected textures.
There are a few PBO related bugs too, but those should be fixed by now. One of those bugs affected geforce 8 cards(texture uploads just fail with PBOs - the extension was just broken). This bug was fixed I think in 10.5.4. Then there was 5829994 - glRasterPos and glPixelZoom were ignored with PBos in glDrawPixels. Unrelated to client storage, and fixed a while ago as well. I think both bugs are still present in Tiger though, but I don't care about Tiger any longer.
I think we should find out more about this issue, for example where the heap errors come from. I prefer to disable PBOs on compressed textures if client storage is used, rather than the other way around. And what's also worth testing is where the error exactly comes from. Ie, does it happen just by using PBOs+Client storage, or is it the NULL pointer that's passed in if a PBO is used? glTexImage2D + Client storage + NULL pointer -> error, even though the extension specifically says that no additional errors should be generated, and if the driver can't use client storage it should just not use it, even if enabled.
I recommend to touch OSX only with a hazmat suit, and if I wasn't paid by codeweavers to care for it I probably wouldn't care for it at all. There are a few more workarounds for OSX bugs in CrossOver Games. If you're interested in them you can download the cxgames wine tree source and diff it against the Wine version it was branched from.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #17 from Henri Verbeet hverbeet@gmail.com 2009-07-29 09:11:17 --- Created an attachment (id=22673) --> (http://bugs.winehq.org/attachment.cgi?id=22673) patch
Out of curiosity, does this patch make it better or worse on your machine?
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #18 from Charles Davis cdavis@mines.edu 2009-07-29 12:15:51 --- (In reply to comment #17)
Out of curiosity, does this patch make it better or worse on your machine?
As a matter of fact, it does. Now the text works properly even with PBOs and client storage enabled at the same time.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #19 from Charles Davis cdavis@mines.edu 2009-07-29 13:26:49 --- (In reply to comment #18)
(In reply to comment #17)
Out of curiosity, does this patch make it better or worse on your machine?
As a matter of fact, it does. Now the text works properly even with PBOs and client storage enabled at the same time.
Sorry, I wasn't clear enough. When I said "it does," I meant "it makes it better."
From what I can tell, the patch gets rid of the workaround for that driver bug,
and uses glCompressedTexSubImage2DARB()/glTexSubImage2D() to upload surface data. Looks like Apple fixed some of the problems Stefan was talking about.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #20 from Henri Verbeet hverbeet@gmail.com 2009-07-29 13:30:10 --- (In reply to comment #19)
From what I can tell, the patch gets rid of the workaround for that driver bug, and uses glCompressedTexSubImage2DARB()/glTexSubImage2D() to upload surface data.
Yeah.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #21 from Stefan Dösinger stefandoesinger@gmx.at 2009-07-29 15:30:43 --- Created an attachment (id=22689) --> (http://bugs.winehq.org/attachment.cgi?id=22689) Test case for the glCompressedTexImage2D bug
The glCompressedTexSubImage2D bug never occured on Macs with Nvidia cards. I only positively reproduced it on Intel GMA X3100 macs, and I think it also occurs on ATI cards, but I have to test there.
Attached is the test case I sent to Apple for this bug. If it runs properly, it should show one of Half Life 2's static backgrounds(pretty dark, because its sRGB'ed). If the driver has the bug, the app shows either a static color or random garbage.
Compile with gcc srgbtexture.c -o srgbtexture -framework opengl -framework glut. There might be a bunch of compile errors due to the way I include the glut headers(or rather, do not include them)
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #22 from Charles Davis cdavis@mines.edu 2009-07-29 16:40:42 --- (In reply to comment #21)
Created an attachment (id=22689)
--> (http://bugs.winehq.org/attachment.cgi?id=22689) [details]
Test case for the glCompressedTexImage2D bug
The glCompressedTexSubImage2D bug never occured on Macs with Nvidia cards. I only positively reproduced it on Intel GMA X3100 macs, and I think it also occurs on ATI cards, but I have to test there.
Attached is the test case I sent to Apple for this bug. If it runs properly, it should show one of Half Life 2's static backgrounds(pretty dark, because its sRGB'ed). If the driver has the bug, the app shows either a static color or random garbage.
Compile with gcc srgbtexture.c -o srgbtexture -framework opengl -framework glut. There might be a bunch of compile errors due to the way I include the glut headers(or rather, do not include them)
Funny... it crashes and burns on my system with a SIGBUS. When I debugged your test program, I found that the stack was corrupted somehow, and the CPU had jumped to some random address. Note the value in EAX:
(gdb) bt #0 0xffff08ab in ?? () #1 0x00000001 in ?? () (gdb) info reg eax 0xffff088b -63349 ecx 0x0 0 edx 0xfffffc80 -896 ebx 0x11f07b7a 300972922 esp 0xbfffea90 0xbfffea90 ebp 0xbfffea98 0xbfffea98 esi 0x25360 152416 edi 0x15a56ca0 363162784 eip 0xffff08ab 0xffff08ab eflags 0x10282 66178 cs 0x17 23 ss 0x1f 31 ds 0x1f 31 es 0x1f 31 fs 0x0 0 gs 0x37 55
Is this why you could never reproduce this with an nVidia card, or is something else at work? (I think it's the latter; see below.)
The odd part is that Henri's patch works fine as far as I can tell. Maybe wined3d does something that your test program isn't doing (or the other way around).
(And personally, I'd never even consider gaming with Intel's integrated graphics solutions.)
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #23 from Henri Verbeet hverbeet@gmail.com 2009-07-29 16:48:43 --- RA3 probably doesn't use sRGB textures.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #24 from Charles Davis cdavis@mines.edu 2009-07-29 17:57:58 --- (In reply to comment #23)
RA3 probably doesn't use sRGB textures.
Good point.
I guess (if we go with your patch) we'll have to disable the glCompressedTexSubImage2DARB() path when we're dealing with sRGB textures. But (in addition to making wined3d even more convoluted than it already is) we'll then need a way to distinguish sRGB textures from others. I don't know if this is worth pursuing. You're the D3D/GL experts.
Or, the crash in Stefan's test app might have some other cause. There's lots of strange bugs in the Mac OS GL implementation, as you are both well aware (and you know about these primarily because CodeWeavers pays you in part to work around them for CrossOver Games :). I suspect the reason is that, like much of Mac OS X, it was (re)written from scratch. (Under the hood, it seems like a completely different beast from the various Linux OpenGLs, from what I can tell.) New code tends to have more bugs than older code. That, and the fact that most of the upper OS layers, including the OpenGL framework, aren't open source (so nobody outside of Apple gets to take a good look at them).
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #25 from Charles Davis cdavis@mines.edu 2009-07-29 19:32:30 --- Hmm... on closer inspection, that "random address" was actually valid after all. It is, in fact, in the middle of the System library's shared kernel/user page (specifically, the memcpy() function).
So it's crashing trying to copy memory with a bad address.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #26 from Stefan Dösinger stefandoesinger@gmx.at 2009-07-30 10:51:11 --- I'm not aware of crashes of this test app, but probably I didn't test on your type of card. There are way too many different combinations(linux/mac/ati/nvidia/intel/dx9 class card/dx10 class card), so I keep losing overview.
A crash certainly makes this issue more difficult to deal with this bug. If the upload is failing, we can test for that. If the test crashes the app, not so much. The only thing worse is if the bug causes a kernel panic or window server crash.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #27 from Charles Davis cdavis@mines.edu 2009-08-03 01:38:45 --- I see Henri sent the patch he attached to this bug. Tomorrow (or sometime this week) we'll see if it gets in, and then if so we can close this bug. Hopefully, they did fix the bugs in the GL driver... and hopefully, if I play a game with sRGB textures, it won't crash and burn.
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #28 from Henri Verbeet hverbeet@gmail.com 2009-08-03 01:50:50 --- We may end up having to add a workaround for compressed sRGB textures, but that would already be more specific than the current code.
http://bugs.winehq.org/show_bug.cgi?id=19412
Charles Davis cdavis@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #29 from Charles Davis cdavis@mines.edu 2009-08-03 17:55:09 --- Alright, the patch made it in!
Now I can mark the bug as resolved fixed.
Still, the fact that Stefan's test program crashed on me seems like a bad sign. Oh well, if I have trouble with sRGB DXT1-compressed textures, I'll just file another bug. Maybe I'll file one with Apple while I'm at it. (Not that they really pay attention unless you're a paying ADC member, but why not?)
http://bugs.winehq.org/show_bug.cgi?id=19412
--- Comment #30 from Charles Davis cdavis@mines.edu 2009-08-03 21:34:21 --- Oops, forgot to mention: the bug was fixed by commit b7812932bc74cf4411bfdbb2277fb0aaf8e24b04.
http://bugs.winehq.org/show_bug.cgi?id=19412
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #31 from Alexandre Julliard julliard@winehq.org 2009-08-07 12:59:14 --- Closing bugs fixed in 1.1.27.
http://bugs.winehq.org/show_bug.cgi?id=19412
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.5 |Mac OS X
-
wine-bugs＠winehq.org