Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
Christoph cr2005 at u-club.de writes: Hi http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html With the attached patch WoW is working for me, clicks on the playfield are now ok! I used a derived work [1] of your patches and it worked for me but not for others. The patch I tested seems to make wineserver eats a lot of memory in some implementations. chris Thanks for the work you've done and for digging in the transgaming mailing lists. [1] http://forums.gentoo.org/viewtopic-p-2800297.html -- Eddahbi Karim Freelance
Bug: kernel: file.c
This makes the Battlefield 2 demo go a bit further, before crashing
again, due to unimplemented call ntdll.dll.NtSetSystemInformation.
The mask parameter is not initialized by RtlDosPathNameToNtPathName_U
(it returns TRUE in that first block), and then you get an invalid
dereference later.
diff -Naurp kernel/file.c kernel.new/file.c
--- kernel/file.c 2005-10-15 04:54:41.0 -0400
+++ kernel.new/file.c 2005-10-15 04:51:36.0 -0400
@@ -1435,7 +1435,7 @@ HANDLE WINAPI FindFirstFileExW( LPCWSTR
LPVOID data, FINDEX_SEARCH_OPS search_op,
LPVOID filter, DWORD flags)
{
-WCHAR *mask, *p;
+WCHAR *mask = NULL, *p;
FIND_FIRST_INFO *info = NULL;
UNICODE_STRING nt_name;
OBJECT_ATTRIBUTES attr;
Debuging Splinter Cell 1 - found bug in kernel32?
Hi. I have read this tutorial http://wiki.winehq.org/Debugging_'Wild_Metal_Country' and tought that i can maybe find the problem, why splinter cell 1 wont start. Here is the importat part (i think): 000b:Call kernel32.RaiseException(c08f,0001,0002,7fbef5e4) ret=66024d53 000b:Call ntdll.RtlRaiseException(7fbef4c4) ret=7fc48163 fs=003b eax=7fc319ad ebx=7fcb088c ecx= edx=0008 esi=7fbef5ec edi=7fbef4e0 ebp=7fbef520 esp=7fbef4c4 ds=007b es=007b gs=0033 flags=00200202 000b:trace:seh:__regs_RtlRaiseException code=c08f flags=1 addr=0x7fc480d0 000b:trace:seh:__regs_RtlRaiseException info[0]=deadcafe 000b:trace:seh:__regs_RtlRaiseException info[1]=deadcafe 000b:trace:seh:__regs_RtlRaiseException eax=7fc319ad ebx=7fcb088c ecx= edx=0008 esi=7fbef5ec edi=7fbef4e0 000b:trace:seh:__regs_RtlRaiseException ebp=7fbef520 esp=7fbef4c4 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00200202 000b:trace:seh:EXC_CallHandler calling handler at 0x402586 code=c08f flags=1 000b:Call kernel32.IsBadReadPtr(004012b0,0004) ret=66024da1 000b:Ret kernel32.IsBadReadPtr() retval= ret=66024da1 000b:Call kernel32.TlsGetValue(0003) ret=66024eda 000b:Ret kernel32.TlsGetValue() retval=7fd5af10 ret=66024eda 000b:Call ntdll.RtlUnwind(7fbef69c,661001ad,,) ret=661001ad fs=003b eax=0001 ebx=7fcbbbac ecx=7fbef69c edx=0003 esi=004012b0 edi=7fbef69c ebp=7fbeef50 esp=7fbeef44 ds=007b es=007b gs=0033 flags=00200206 The full log can be found here: http://x-factor.dyndns.org/~austriancoder/splinter_cell1.log.bz2 (1,5 M) Maybe somebody can confirm that it is a kernel32 bug and may can fix it, or give me a hint were i can fix it. Thanks, Christian -- Christian Gmeiner Developer for Rockbox (http://www.rockbox.org) Maintainer of the DXR3-Plugin for VDR: http://sourceforge.net/projects/dxr3plugin/ Maintainer of VDR-Ebuilds at Gentoo.de
Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
On Fri, 14 Oct 2005 19:02:02 +0200, Christoph wrote: WoW really seems to relay on this magic address. And yet it works in Windows which presumably does not have any WoW specific appgoo in it. So I imagine it's actually some weird quick of the NT kernel we're not emulating correctly here, but Alexandre is the true man to ask.
Re: Debuging Splinter Cell 1 - found bug in kernel32?
On Sat, 15 Oct 2005 12:44:35 +, Christian Gmeiner wrote: Maybe somebody can confirm that it is a kernel32 bug and may can fix it, or give me a hint were i can fix it. Good to see the tutorials are helping! This is a curious one indeed. The exception code, 0xC08f is STATUS_FLOAT_INEXACT_RESULT which I've never seen before. To find out why it's being thrown you need to look *before* the RaiseException line, not after it. That tells you what's going on after the error occurred but we are interested in what's happening before it. thanks -mike
Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
Mike Hearn schrieb: On Fri, 14 Oct 2005 19:02:02 +0200, Christoph wrote: WoW really seems to relay on this magic address. And yet it works in Windows which presumably does not have any WoW specific appgoo in it. So I imagine it's actually some weird quick of the NT kernel we're not emulating correctly here, but Alexandre is the true man to ask. I tested my patch yesterday for about 4 hours and I only had one crash. Game freezed. Got lock in ntdll, no run out of memory! Here is maybe a clue. Can anyone outline the role of imm32.dll and if it can be involved in our problem? I looked at the output, and this catched my eye. Here I started WoW without any wine hacks, just with my dropped MESSAGE lines, so with mouse click problem : trace:loaddll:load_builtin_dll Loaded module LC:\\windows\\system\\opengl32.dll : builtin EXE not mmap 0xbfe2, 16384, 7, 50, -1 = 0xbfe2 trace:loaddll:load_native_dll Loaded module LC:\\windows\\system\\IMM32.dll : native EXE not mmap 0x1000, 430080, 7, 50, -1 = 0x1000 trace:loaddll:load_native_dll Loaded module LE:\\World of Warcraft\\DivxDecoder.dll : native not mmap 0x7ff9, 4096, 3, 50, -1 = 0x7ff9 trace:loaddll:load_builtin_dll Loaded module LC:\\windows\\system\\winmm.dll : builtin EXE set mmap (nil), 655360, 7, 34, -1 = 0x7fedd000 imm32 is the only one loaded in 0x1xxx. I tried buildin and native version, no difference. later, WoW uses adresses like this: not mmap 0x7d601000, 32768, 0, 50, -1 = 0x7d601000 not mmap 0x79b2, 4096, 0, 50, -1 = 0x79b2 not mmap 0x79921000, 1048576,0, 50, -1 = 0x79921000 not mmap 0x6249d000, 4096, 0, 50, -1 = 0x6249d000 not mmap 0x7d641000, 212992, 0, 50, -1 = 0x7d641000 ... mouse clicks do not work. Here with my patch, mouse working trace:loaddll:load_builtin_dll Loaded module LC:\\windows\\system\\opengl32.dll : builtin not mmap 0xbfe2, 16384, 7, 50, -1 = 0xbfe2 trace:loaddll:load_native_dll Loaded module LC:\\windows\\system\\IMM32.dll : native set mmap 0x10246000, 495616, 7, 50, -1 = 0x10246000 trace:loaddll:load_native_dll Loaded module LE:\\World of Warcraft\\DivxDecoder.dll : native not mmap 0x7ff9, 4096, 3, 50, -1 = 0x7ff9 trace:loaddll:load_builtin_dll Loaded module LC:\\windows\\system\\winmm.dll : builtin set mmap 0x102bf000, 655360, 7, 50, -1 = 0x102bf000 not mmap 0x7ff6, 4096, 3, 50, -1 = 0x7ff6 and later game running: not mmap 0x107c5000, 0, 0, 50, -1 = 0x107c5000 not mmap 0x1074d000, 4096, 0, 50, -1 = 0x1074d000 not mmap 0x1074e000, 4096, 0, 50, -1 = 0x1074e000 not mmap 0x1074c000, 4096, 0, 50, -1 = 0x1074c000 not mmap 0x10749000, 0, 0, 50, -1 = 0x10749000 not mmap 0x122ed000, 4096, 0, 50, -1 = 0x122ed000 not mmap 0x122ee000, 4096, 0, 50, -1 = 0x122ee000 not mmap 0x122ec000, 4096, 0, 50, -1 = 0x122ec000 not mmap 0x122e9000, 0, 0, 50, -1 = 0x122e9000 not mmap 0x107bf000, 4096, 0, 50, -1 = 0x107bf000 not mmap 0x107be000, 4096, 0, 50, -1 = 0x107be000 ... just for fun I tested with 0x2000. imm32.dll still at 0x1000, wow uses 0x2xxx, mouse working. 0x3000 works either, all other segfault or game starts but crash while entering the world. chris
Re: Reality check
If you want someone to work for you, for free, I don't. In fact, I don't care about those bugs at all. Once again (for the 3rd time, BTW): I just tried to make Wine a little bit more compatible with 3rd-party applications (by supporting a way for Win programmers to specify WINE config parameters within executable). I was told that it doesn't make sense, as 'bugs are usually fixed within 2-3 days', which I had serious doubts about (it just doesn't work that way), so I've made a little experiment. I was right, you guys were wrong, and now you're trying to blame me? I don't really think that after all that heated conversation somebody is going to consider my original proposal, but frankly I don't care about WIne anymore - I definitely don't like this 'pay me' attitude (rather than normal 'sorry, we didn't have time to fix it yet' attitude). you have to recognize that they are giving you a gift - a gift of their time. Come on, with this attitude we won't get anywhere. I'm also spending my time reporting the bugs I don't really care about (except generic 'making Wine better'). We are all in the same boat, and on other open source projects (the one I'm working on - on my own, not employer time, BTW - included) reported bugs are treated as a help from the users, not with 'pay me to fix it' attitude. _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
Re: Reality check
On Sat, 2005-10-15 at 13:27 +, John Smith wrote: Come on, with this attitude we won't get anywhere. I'm also spending my time reporting the bugs I don't really care about (except generic 'making Wine better'). And that's appreciated. Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner. Not an excuse -- I'm just trying to explain why we don't just on the bugs when they are filled in Bugzilla. Now that we have 0.9 on the way (hopefully followed by 1.0), this attitude seems to be changing. We are all in the same boat, and on other open source projects (the one I'm working on - on my own, not employer time, BTW - included) reported bugs are treated as a help from the users, not with 'pay me to fix it' attitude. That's a misunderstanding. I agree with you that the conversation has derailed rather sharply in that direction. However, this is not the attitude around here. It was a reaction to your perceived approach to the problem. While well intentioned, you came of as demanding stuff (bugs fixed, apologies, whatever). It was a rough start -- it's easy to be misunderstood on mailing lists. Lets just relax and start fresh :) As for your original proposal, the problem with it is that long term will hurt the project -- it will encourage people to work around bugs rather then help us fix them. That makes most sense for a company. We want the project to go forward, so we can not accept such a solution. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Debuging Splinter Cell 1 - found bug in kernel32?
Hi, On Sat, Oct 15, 2005 at 12:44:35PM +, Christian Gmeiner wrote: Hi. I have read this tutorial http://wiki.winehq.org/Debugging_'Wild_Metal_Country' and tought that i can maybe find the problem, why splinter cell 1 wont start. Here is the importat part (i think): 000b:Call kernel32.RaiseException(c08f,0001,0002,7fbef5e4) ret=66024d53 000b:Call ntdll.RtlRaiseException(7fbef4c4) ret=7fc48163 fs=003b eax=7fc319ad ebx=7fcb088c ecx= edx=0008 esi=7fbef5ec edi=7fbef4e0 ebp=7fbef520 esp=7fbef4c4 ds=007b es=007b gs=0033 flags=00200202 000b:trace:seh:__regs_RtlRaiseException code=c08f flags=1 addr=0x7fc480d0 000b:trace:seh:__regs_RtlRaiseException info[0]=deadcafe 000b:trace:seh:__regs_RtlRaiseException info[1]=deadcafe 000b:trace:seh:__regs_RtlRaiseException eax=7fc319ad ebx=7fcb088c ecx= edx=0008 esi=7fbef5ec edi=7fbef4e0 000b:trace:seh:__regs_RtlRaiseException ebp=7fbef520 esp=7fbef4c4 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00200202 000b:trace:seh:EXC_CallHandler calling handler at 0x402586 code=c08f flags=1 000b:Call kernel32.IsBadReadPtr(004012b0,0004) ret=66024da1 000b:Ret kernel32.IsBadReadPtr() retval= ret=66024da1 000b:Call kernel32.TlsGetValue(0003) ret=66024eda 000b:Ret kernel32.TlsGetValue() retval=7fd5af10 ret=66024eda 000b:Call ntdll.RtlUnwind(7fbef69c,661001ad,,) ret=661001ad fs=003b eax=0001 ebx=7fcbbbac ecx=7fbef69c edx=0003 esi=004012b0 edi=7fbef69c ebp=7fbeef50 esp=7fbeef44 ds=007b es=007b gs=0033 flags=00200206 The full log can be found here: http://x-factor.dyndns.org/~austriancoder/splinter_cell1.log.bz2 (1,5 M) Maybe somebody can confirm that it is a kernel32 bug and may can fix it, or give me a hint were i can fix it. That one is certainly not a kernel32 bug. Well, at least that crash (and the part you showed) doesn't show anything pointing at kernel32, what makes you think it's such a problem? In fact that crash occurs out of the blue, with no indications what is causing it AFAICS. But I see that the program makes extensive use of oleaut32, which might be a bad idea in case our implementation is still weak. Try using a native oleaut32.dll to see if this fixes it and thus nails the problem down to somewhere in oleaut32... Hmm, but another thing is that the exception code here is very interesting: include/ntstatus.h:#define STATUS_FLOAT_INEXACT_RESULT 0xC08F which is rather different from the all-too-common #define STATUS_ACCESS_VIOLATION 0xC005 And 000b:trace:seh:__regs_RtlRaiseException info[0]=deadcafe 000b:trace:seh:__regs_RtlRaiseException info[1]=deadcafe deadcafe is another special magic value that might have been set by Wine code to indicate a problem... Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: Bug: kernel: file.c
On 10/15/05, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Ivan Gyurdiev wrote: This makes the Battlefield 2 demo go a bit further, before crashing again, due to unimplemented call ntdll.dll.NtSetSystemInformation. The mask parameter is not initialized by RtlDosPathNameToNtPathName_U (it returns TRUE in that first block), and then you get an invalid dereference later. Never mind, I see this is being fixed differently by James Hawkins. When I was first looking through this bug, I tried setting mask to NULL as well, but that just hides the fact that RtlDosPathNameToNtPathName_U doesn't fill in the file_part parameter for long file names as it should. My approach was incorrect, but I'll go back and work something else out. -- James Hawkins
Re: D3D7 - WineD3D, 2nd attempt
Hello, Just one question about thread safety: The openGL crash I am struggling with seems related to threading: ~3 lines of debug output from thread 0xb 000b:trace:ddraw:Main_DirectDrawSurface_Unlock (0x7c8a3910)-Unlock((nil)) 000b:trace:d3d_surface:IWineD3DSurfaceImpl_UnlockRect (0x7c8a3cb8 ) : dirtyfied(1) 000b:fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to surface [EMAIL PROTECTED] usage(512) 000b:trace:ddraw:Main_DirectDrawSurface_Unlock (0x7c8a2e60)-Unlock((nil)) 000b:trace:d3d_surface:IWineD3DSurfaceImpl_UnlockRect (0x7c8a3208 ) : dirtyfied(1) 000b:fixme:d3d_surface:IWineD3DSurfaceImpl_UnlockRect unsupported unlocking to surface [EMAIL PROTECTED] usage(512) 001c:trace:ddraw:Main_IDirect3DDeviceImpl_7_Clear (0x7c7e0cd8/0x7c7e0cd8)-(0001,0x5c59f4e4,0002,,0.00,) 001c:trace:ddraw:d3ddevice_clear (0x7c7e0cd8) Relay 001c:trace:d3d:IWineD3DDeviceImpl_Clear (0x7c833250) Count (1), pRects (0x5c59f4e4), Flags (2), Z (0.00), Stencil (0) 001c:trace:d3d:IWineD3DDeviceImpl_Clear glEnable GL_SCISSOR_TEST call ok device.c / 4666 001c:trace:d3d:IWineD3DDeviceImpl_Clear glClearDepth call ok device.c / 4688 001c:trace:d3d:IWineD3DDeviceImpl_Clear (0x7c833250) 0x5c59f4e4 Rect=(662,430)-(0,0) glRect=(662,768), len=-662, hei=-430 001c:fixme:d3d:IWineD3DDeviceImpl_Clear 501 from glScissor @ device.c / 4717 001c:trace:d3d:IWineD3DDeviceImpl_Clear glClear call ok device.c / 4729 001c:trace:d3d:IWineD3DDeviceImpl_Clear glDisable call ok device.c / 4756 001c:trace:ddraw:WineD3D_IDirect3DDeviceImpl_7_3T_2T_1T_BeginScene (0x7c7e0cd8/0x7c7e0cd8)-(): Relay! 001c:trace:d3d:IWineD3DDeviceImpl_BeginScene (0x7c833250) : stub 001c:trace:ddraw:WineD3D_IDirect3DDeviceImpl_7_3T_2T_SetRenderState (0x7c7e0cd8/0x7c7e0cd8)-(0089,): Relay! 001c:err:ddraw:WineD3D_IDirect3DDeviceImpl_7_3T_2T_SetRenderState Calling glBegin 001c:err:ddraw:WineD3D_IDirect3DDeviceImpl_7_3T_2T_SetRenderState Calling glEnd 001c:err:ddraw:WineD3D_IDirect3DDeviceImpl_7_3T_2T_SetRenderState Done! 001c:trace:d3d:IWineD3DDeviceImpl_SetRenderState (0x7c833250)-state = WINED3DRS_LIGHTING(137), value = 0 001c:trace:d3d:IWineD3DDeviceImpl_SetRenderState glDisable GL_LIGHTING call ok device.c / 2817 001c:err:ddraw:WineD3D_IDirect3DDeviceImpl_7_3T_2T_SetRenderState Calling glBegin ---Crash in fglrx--- The nvidia OpenGL implementation crashes in IWineD3DDeviceImpl_Clear, the fglrx implementation on the first glBegin or glReadPixels call after the thread switch - Here an injected glBegin()-glEnd call after SetRenderState. Is WineD3D threading safe yet? Or might be the underlying OpenGL layer have problems with threading? On the fglrx side glDisable(GL_LIGHTNING) comes into play somewhere. Without this call there's no crash, but a completely blocked X server. However, I don't think it's related to the cause, but it only changes the symptom. Without Hardware accellerated OpenGL there's no crash in OpenGL, but there's a DIB crash later on. With the old D3D7 Implementation I've also seen texture problems after the thread switch. Thanks, Stefan
Commctl32 and uxtheme bugs
Hi all, I just found this on msdn http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/userex/themes.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xptheming.asp I think it does tell us that we need commctl version 6 in order to get theming, but we are using version 5.0 implementation. The above article also mentions how to use commctl version 5 with uxtheme, but we need some concrete theming/non theming examples inorder to fix the notiious WMGETTEXT bug that came with unicodification of controls. I will be searching msdn for more info bye, Vijay
Re: Reality check
responsibility. Money or not. Fixing what you broke is the right thing to do -- regardless of the disclaimer. Actually, there is an important point being overlooked here that deserves being brought out. Wine regresses all the time. Any decent programmer worth her salt would be embarrased to work on a finished product that regressed all the time. Yet I think we are blessed with many decent programmers on the Wine project. So that's why Wine is officially labeled 'Alpha' software. It's labeled as such, in recognition by the developers of Wine that fundamental pieces of the puzzle are not yet done correctly, and that future breakage is likely. So, for example, years ago we had no process separation. Lots of programs worked because cross process messaging 'worked'. Of course, lots of others failed to work, because their memory space was corrupted. Now we fixed this, so suddenly lots of applications stopped working. A regression? From a user perspective, yes. The right thing to do? Absolutely. The good news is the whole point of the 0.9 release is to mark the turning point where we shift out of Alpha and towards 'Beta'. In other words, the supposedly decent programmers now think regressions will happen less frequently, and will purportedly take them more seriously in the future. grin Cheers, Jeremy
Re: Reality check
--- Vitaliy Margolen [EMAIL PROTECTED] wrote: What do you expect from poor open-source copy of it? g To help the Wine community realize that even though it is poor, it is stronger than it thinks. I truely see Wine as the David in the Goliath world of Microsoft - and Linux is the stone. (Or is Linux the David, and Wine the stone?) ;) Hiji __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
Re: Reality check
Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner. Sure; that's why I was really surprised when I was told that 'usually bugs are fixed in 2 or 3 days'. While well intentioned, you came of as demanding stuff (bugs fixed, apologies, whatever). Nope. I tried to get attention and I succeeded with it, though this kind of 'pay me' reaction was unexpected. As for your original proposal, the problem with it is that long term will hurt the project -- it will encourage people to work around bugs rather then help us fix them. At least arguable. Looking from outside world, I would say that at current stage WINE needs as much 3rd-party applications as possible. If this is true, and given the (currently proven and admitted) fact that you guys do have lots of stuff to do even without additional feedback, I'd say that adding a regular workaround mechanism (with lots of disclaimers that it will be deprecated in the future) would help to increase WINE popularity as of now. In addtion, similar workarounds do exist now, but they are: a) tricky, b) irregular, c) undocumented. From: Dimi Paun [EMAIL PROTECTED] To: John Smith [EMAIL PROTECTED] CC: [EMAIL PROTECTED], wine-devel@winehq.org Subject: Re: Reality check Date: Sat, 15 Oct 2005 09:59:51 -0400 On Sat, 2005-10-15 at 13:27 +, John Smith wrote: Come on, with this attitude we won't get anywhere. I'm also spending my time reporting the bugs I don't really care about (except generic 'making Wine better'). And that's appreciated. Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner. Not an excuse -- I'm just trying to explain why we don't just on the bugs when they are filled in Bugzilla. Now that we have 0.9 on the way (hopefully followed by 1.0), this attitude seems to be changing. We are all in the same boat, and on other open source projects (the one I'm working on - on my own, not employer time, BTW - included) reported bugs are treated as a help from the users, not with 'pay me to fix it' attitude. That's a misunderstanding. I agree with you that the conversation has derailed rather sharply in that direction. However, this is not the attitude around here. It was a reaction to your perceived approach to the problem. While well intentioned, you came of as demanding stuff (bugs fixed, apologies, whatever). It was a rough start -- it's easy to be misunderstood on mailing lists. Lets just relax and start fresh :) As for your original proposal, the problem with it is that long term will hurt the project -- it will encourage people to work around bugs rather then help us fix them. That makes most sense for a company. We want the project to go forward, so we can not accept such a solution. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
correct ismbblead implementation
Hi, we can use the following registrykey HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Control\NLS\CodePage\EUDCCodeRange to get the correct key range and also for correct implementation of ismbblead in msvcrt its documented here http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_3rfp.asp Thanks, Vijay
Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
On 10/15/05, Christoph [EMAIL PROTECTED] wrote: Mike Hearn schrieb: Here is maybe a clue. Can anyone outline the role of imm32.dll and if it can be involved in our problem? imm32.dll seems to be a dll for internationalizing certain text.
Re: D3D7 - WineD3D, 2nd attempt
--- Stefan Dösinger [EMAIL PROTECTED] wrote: Hello, Just one question about thread safety: The openGL crash I am struggling with seems related to threading: ---Crash in fglrx--- The nvidia OpenGL implementation crashes in IWineD3DDeviceImpl_Clear, the fglrx implementation on the first glBegin or glReadPixels call after the thread switch - Here an injected glBegin()-glEnd call after SetRenderState. Is WineD3D threading safe yet? Or might be the underlying OpenGL layer have problems with threading? Wined3d isn't thread safe yet. Threading will cause lots of problems because when you call MakeActive with the OpenGL context it only makes the context active on the current thread so when you switch threads you may be using a different OpenGL context. This also means that wined3d cannot support multiple concurrent devices, unless the application is using one device per thread, because the OpenGL context isn't being switched when the device changes. Oliver. Thanks, Stefan ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote: Hello, Just one question about thread safety: The openGL crash I am struggling with seems related to threading: A, you fell again in the (in)famous multi-threaded D3D applications :-) Alas, for now, this is an unsolved issue for which no clear plan is put in place. So I guess it would be best to choose another game to do your DDraw = WineD3D port as neither DDraw not WineD3D support (yet) these kind of applications. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
Wined3d isn't thread safe yet. Threading will cause lots of problems
because when you call MakeActive with the OpenGL context it only makes the
context active on the current thread so when you switch threads you may be
using a different OpenGL context. This also means that wined3d cannot
support multiple concurrent devices, unless the application is using one
device per thread, because the OpenGL context isn't being switched when the
device changes.
I've written a little function:
void check_thread(IWineD3DDeviceImpl *This)
{
DWORD tid = GetCurrentThreadId();
if(This-LastTid != tid)
{
WARN( (%p) Current thread has changed! Updating OpenGL context\n,
This);
TRACE( (%p) Old tid=0x%lx, new tid=0x%lx\n, This, This-LastTid,
tid);
/* Find the implicit swapchain and restore the GL context */
if(This-swapchains)
{
if(This-swapchains-swapchain)
{
IWineD3DSwapChainImpl *swapchain = (IWineD3DSwapChainImpl *)
This-swapchains-swapchain;
/* Restore the glX context */
if(glXMakeCurrent(swapchain-display, swapchain-win,
swapchain-glCtx) == FALSE)
{
ERR(Error in setting current context (display %p context
%p drawable %ld)!\n, swapchain-display, swapchain-glCtx, swapchain-win);
}
checkGLcall(glXMakeCurrent);
/* Todo: Restore the viewport */
}
else
{
ERR( (%p) Swapchain list found, but it doesn't contain a
swapchain\n, This);
}
}
else
{
ERR( (%p) No swapchains found - Expect a crash\n, This);
}
This-LastTid = tid;
}
}
It restored the glx context based on the one in the implicit swapchain. I call
it in WineD3DDeviceImpl_Clear. This solved the GL crash, and I rush into a
blocked Desktop in surface UnlockRect, which can only be solved by killing
wine via acpi hotkeys or ssh. Eighter my solution is incorrect or these
crashes are not related.
Stefan
PS: I've a Direct3D 9 test if you are interested.
Re: D3D7 - WineD3D, 2nd attempt
Am Samstag, 15. Oktober 2005 20:11 schrieben Sie: On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote: Hello, Just one question about thread safety: The openGL crash I am struggling with seems related to threading: A, you fell again in the (in)famous multi-threaded D3D applications :-) Alas, for now, this is an unsolved issue for which no clear plan is put in place. So I guess it would be best to choose another game to do your DDraw = WineD3D port as neither DDraw not WineD3D support (yet) these kind of applications. Well any suggestions? I don't know many D3D7 games. There should be at least a free demo downloadable. I'll try my wined3d glXMakeCurrent hack on old ddraw, just out of curiosity. Stefan
Re: D3D7 - WineD3D, 2nd attempt
--- Lionel Ulmer [EMAIL PROTECTED] wrote: On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote: Hello, Just one question about thread safety: The openGL crash I am struggling with seems related to threading: A, you fell again in the (in)famous multi-threaded D3D applications :-) Alas, for now, this is an unsolved issue for which no clear plan is put in place. So I guess it would be best to choose another game to do your DDraw = WineD3D port as neither DDraw not WineD3D support (yet) these kind of applications. It fairly easy to make things thread safe and support multiple devices per thread, very roughly you have to: Add the OpenGL context to the device structure. Make a per-device critical section. Whenever a call is made enter the critical section Then check that the current active context is the same as the context on the device. If not then make the device context active. I wanted to finish state management before making things threadsafe and support multiple devices per thread. Oliver. Lionel -- Lionel Ulmer - http://www.bbrox.org/ ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:25:18PM +0200, Stefan Dösinger wrote: I'll try my wined3d glXMakeCurrent hack on old ddraw, just out of curiosity. I checked your code you sent in the other part of the thread and it seems strange... According to the man page: BadAccess is generated if ctx was current to another thread at the time glXMakeCurrent was called. So if you are in thread B and thread A has the control of your context, doing a 'glXMakeCurrent' on the shared context should fail as the context is currently active in thread A. To have this method work properly, one would have to somehow make 'glXMakeCurrent(NULL)' run in the context of thread A before doing what you did. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote: Add the OpenGL context to the device structure. Make a per-device critical section. Whenever a call is made enter the critical section Then check that the current active context is the same as the context on the device. If not then make the device context active. How did you plan to solve the 'one needs to release a context before it is free to be used in another thread' problem ? The only 'easy' way out I can see would be to always release the context at the end of each processing so that any subsequent thread could, if needed, get the context. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
--- Stefan Dösinger [EMAIL PROTECTED] wrote:
Wined3d isn't thread safe yet. Threading will cause lots of problems
because when you call MakeActive with the OpenGL context it only makes the
context active on the current thread so when you switch threads you may be
using a different OpenGL context. This also means that wined3d cannot
support multiple concurrent devices, unless the application is using one
device per thread, because the OpenGL context isn't being switched when the
device changes.
I've written a little function:
void check_thread(IWineD3DDeviceImpl *This)
{
DWORD tid = GetCurrentThreadId();
if(This-LastTid != tid)
{
WARN( (%p) Current thread has changed! Updating OpenGL context\n,
This);
TRACE( (%p) Old tid=0x%lx, new tid=0x%lx\n, This, This-LastTid,
tid);
/* Find the implicit swapchain and restore the GL context */
if(This-swapchains)
{
if(This-swapchains-swapchain)
{
IWineD3DSwapChainImpl *swapchain = (IWineD3DSwapChainImpl *)
This-swapchains-swapchain;
/* Restore the glX context */
if(glXMakeCurrent(swapchain-display, swapchain-win,
swapchain-glCtx) == FALSE)
{
ERR(Error in setting current context (display %p context
%p drawable %ld)!\n, swapchain-display, swapchain-glCtx, swapchain-win);
}
checkGLcall(glXMakeCurrent);
/* Todo: Restore the viewport */
}
else
{
ERR( (%p) Swapchain list found, but it doesn't contain a
swapchain\n, This);
}
}
else
{
ERR( (%p) No swapchains found - Expect a crash\n, This);
}
This-LastTid = tid;
}
}
It restored the glx context based on the one in the implicit swapchain. I
call
it in WineD3DDeviceImpl_Clear. This solved the GL crash, and I rush into a
blocked Desktop in surface UnlockRect, which can only be solved by killing
wine via acpi hotkeys or ssh. Eighter my solution is incorrect or these
crashes are not related.
/you should really be using the getter function to get the implicite swapchain
and your function
still doesn't make things threadsafe, desktop lockups are usually because
ENTER_GL / LEAVE_GL's
aren't correct. (I've also had some problems with ATI's drivers and buffer
overruns causing X to
lockup)
Stefan
PS: I've a Direct3D 9 test if you are interested.
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
Re: D3D7 - WineD3D, 2nd attempt
To have this method work properly, one would have to somehow make 'glXMakeCurrent(NULL)' run in the context of thread A before doing what you did. Threading fun Will be a long study of man pages and windows threading things I guess. A wild guess: Remove the context after every function using OpenGL and aquire it at the beginning? Really bad performance I'd guess, if it works at all. (Olivier just has sent me a useable guide for thread safety things) Another update before sending: I've used my glXMakeCurrent hack with old ddraw, and guess what: Empire Earth brings the main menu up successfully[1]. It's slow as hell(yes, 2D DIB with those horrible ATI drivers), and it has some little drawing problems. It crashes in msacm when trying to start a game. Well, this shows that its possible - Time to make this work with WineD3D ;-) [1] Screen shots are allways cool - www.doesi.gmxhome.de/ee-shot.png
Re: D3D7 - WineD3D, 2nd attempt
--- Lionel Ulmer [EMAIL PROTECTED] wrote: On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote: Add the OpenGL context to the device structure. Make a per-device critical section. Whenever a call is made enter the critical section Then check that the current active context is the same as the context on the device. If not then make the device context active. How did you plan to solve the 'one needs to release a context before it is free to be used in another thread' problem ? The only 'easy' way out I can see would be to always release the context at the end of each processing so that any subsequent thread could, if needed, get the context. We could do that, or we could signal the other thread an tell it to release the context which should cut down on the context switching, I'm not sure how easy that would be to setup (it doesn't seem possible using even objects because the thread has to be waiting) Another option would be to create a new context that shares resources with the other contexts and copy over the state from the old context to the new one. Either way there's only a slight performance hit for single threaded applications. Oliver. Lionel -- Lionel Ulmer - http://www.bbrox.org/ ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: D3D7 - WineD3D, 2nd attempt
--- Stefan Dösinger [EMAIL PROTECTED] wrote: To have this method work properly, one would have to somehow make 'glXMakeCurrent(NULL)' run in the context of thread A before doing what you did. [1] Screen shots are allways cool - www.doesi.gmxhome.de/ee-shot.png You should be able to get rid of the lines by adjusting the glTranslatef(0.9 / This-stateBlock-viewport.Width, -0.9 / This-stateBlock-viewport.Height, 0); in drawprim.c. The current code isn't quite right, Oliver. ___ Get My Web - a better way to save web pages http://uk.search.yahoo.com/myresults/default
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:13:24PM +0100, Oliver Stieber wrote: We could do that, or we could signal the other thread an tell it to release the context which should cut down on the context switching, I'm not sure how easy that would be to setup (it doesn't seem possible using even objects because the thread has to be waiting) Well, the 'signal' option is (AFAIK) what Transgaming does in Cedega to fix the issue. Another option would be to create a new context that shares resources with the other contexts and copy over the state from the old context to the new one. And this is what I planned to implement when the I have the motivation and the time (discussed about it on IRC with a guy some time ago trying to find the best way to do that). I may try it one of these days for some specific cases (like for Dungeon Siege) and if it works, generalize to all cases. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:59:55PM +0200, Stefan Dösinger wrote: Another update before sending: I've used my glXMakeCurrent hack with old ddraw, and guess what: Empire Earth brings the main menu up successfully[1]. It's slow as hell(yes, 2D DIB with those horrible ATI drivers), and it has some little drawing problems. It crashes in msacm when trying to start a game. Well, seems that your GL drivers do not do all the checks the specification requires them to do... Lucky for you :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
Am Samstag, 15. Oktober 2005 21:13 schrieb Oliver Stieber: --- Lionel Ulmer [EMAIL PROTECTED] wrote: On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote: Add the OpenGL context to the device structure. Make a per-device critical section. Whenever a call is made enter the critical section Then check that the current active context is the same as the context on the device. If not then make the device context active. How did you plan to solve the 'one needs to release a context before it is free to be used in another thread' problem ? The only 'easy' way out I can see would be to always release the context at the end of each processing so that any subsequent thread could, if needed, get the context. How about creating a new thread to to all rendering, and make the calls call this thread and block until the function's finished? Is this possible? Stefan
HL2
Hi, I got wine compiling on x86_64 with some 32bit libs today and tested HL2 again. Steam updates and works just fine, but if I want to start HL2 it always throws a message The latest version of Microsoft DirectX is required to play Half-Life 2 I've updated the DirectX version string to the latest version Version=4.00.09.0904 but this doesn't help. Could someone help me to debug for what else HL2 checks? The console outputs only fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is nonexistent at the moment! Thanks, -- andreas -- http://www.linux-gamers.net - your online gaming resource
Re: D3D7 - WineD3D, 2nd attempt
--- Lionel Ulmer [EMAIL PROTECTED] wrote: On Sat, Oct 15, 2005 at 08:13:24PM +0100, Oliver Stieber wrote: We could do that, or we could signal the other thread an tell it to release the context which should cut down on the context switching, I'm not sure how easy that would be to setup (it doesn't seem possible using even objects because the thread has to be waiting) Well, the 'signal' option is (AFAIK) what Transgaming does in Cedega to fix the issue. Another option would be to create a new context that shares resources with the other contexts and copy over the state from the old context to the new one. And this is what I planned to implement when the I have the motivation and the time (discussed about it on IRC with a guy some time ago trying to find the best way to do that). I may try it one of these days for some specific cases (like for Dungeon Siege) and if it works, generalize to all cases. For wined3d the code in device.c:IWineD3DDeviceImpl_ActiveRender could be improved and used, it creates a new context for a render target and then applies the current state block to update the states. I've got some code that improves updating the states so that only changes are updated but it's a bit work in progress at the moment. It may be easier to do in DirectX 7 because of the way it manages states. Oliver. Lionel -- Lionel Ulmer - http://www.bbrox.org/ ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: D3D7 - WineD3D, 2nd attempt
How about creating a new thread to to all rendering, and make the calls call this thread and block until the function's finished? Is this possible? Yeah, this was another option we discussed (the 'marshalling' option as we called it :-) ). Was deemed too slow as it would reduce performance of games using a single-threaded rendering system (the vast majority of games). The problem with that is either you know beforehand that it will be multi-threaded or it's too late (as once you detect it, you cannot go back as your context is already taken by the other thread). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:44:05PM +0100, Oliver Stieber wrote: It may be easier to do in DirectX 7 because of the way it manages states. Well, I wanted first to handle 'special cases' like applications using the second thread just to do lock / unlock on the buffer or loading textures (which is a good part of the cases). For those, no need to handle states as they are not needed anyway. Applications that are really doing multithreaded 3D rendering are quite rare (and the only case I know is just starting with one thread and then moving to another while not using the previous one again). Lionel -- Lionel Ulmer - http://www.bbrox.org/
16 bit code, breakpoints?
Hi, How do you set breakpoints in 16 bit code, or cant you? I can add in the winedos code a debugbreak at a particular point in time, and I really want to step through some of the code following the return to see why something is happening. If I do, for example, break 0x1257:0x33f3 or *0x1257:0x33f3 it doesn't work. Jason
Wine and Mono
Hi, .exe files are often associated with Wine so that it's easy for users to double click a windows application and have it working like any native application. Wouldn't it be possible for Wine to detect .Net application and run them using mono (mono app.exe) instead of just failing ? If that's not wanted, would it be at least possible to issue a message to tell the user that the application he'is trying to run is a .Net application and that he should try running it using mono ? What are your opinions about the handling of .Net executables ? Thanks. -- Jonathan Ernst [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
