January 2005 - Wine-Devel - list.winehq.org

Re: emsabp.idl - virtually identical data structures to mapidefs.h

by Luke Kenneth Casson Leighton

On Mon, Jan 31, 2005 at 11:12:25PM +0000, Luke Kenneth Casson Leighton wrote: > hi, > > here's an IDL file i'm working on for exchange 5.5 server. p.s. when compiled with the FreeDCE dceidl compiler, it results in Nspi* functions that can actually be used to contact a remote exchange 5.5 server and obtain MAPI row information.

Jan. 31, 2005

emsabp.idl - virtually identical data structures to mapidefs.h

by Luke Kenneth Casson Leighton

hi, here's an IDL file i'm working on for exchange 5.5 server. as you can see it's virtually identical, structure-for-structure, to those listed in mapidefs.h. at about struct MAPIERROR, the similarity stops. thoughts, anyone? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Jan. 31, 2005

Re: [d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem

by Jesse Allen

On Mon, 31 Jan 2005 21:47:44 -0000, Ann and Jason Edmeades <us(a)the-edmeades.demon.co.uk> wrote: > Well yes and no. The 'problem' is most of this code isn't implemented yet... > > Try Olivers large patch and see if things are any better, or wait a while > while a whole load of code gets into cvs. Basically d3d9 shouldn't have any > of the code relating to the stencil buffers - that will be in wine3d. I am > pretty certain Olivers patch did that, and he is working on splitting it up > to get cvs in sync with his local tree. > Maybe. I got pirates partially to work. The intro at loading plays, after the Atari logo, it then crashes: fixme:d3d:IDirect3DDevice9Impl_CreateDepthStencilSurface (0x403ac0f0) : stub fixme:d3d:IDirect3DDevice9Impl_CreateDepthStencilSurface (0x403ac0f0) : stub wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x4a1a5b30). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0000 EIP:4a1a5b30 ESP:4068fc40 EBP:4068fd1c EFLAGS:00010202( - 00 - -RI1) EAX:4042c688 EBX:4a1cc32c ECX:403abe40 EDX:00000001 ESI:403ec588 EDI:00000000 Stack dump: 0x4068fc40: 00000001 00007eac 00000002 00000000 0x4068fc50: 7a7d2ba0 0000000c 00000002 00000000 0x4068fc60: 00000000 00000000 00000000 00000000 0x4068fc70: 00000000 00000000 00000000 00000000 0x4068fc80: 00000000 00000000 00000000 00000000 0x4068fc90: 00000000 00000000 00000000 00000000 Backtrace: =>1 0x4a1a5b30 drawPrimitive+0x230(iface=0x403ec588, PrimitiveType=0x6, NumPrimitives=0x2, StartVertexIndex=0x0, StartIdx=0xffffffff, idxSize=0x0, idxData=0x0, minIndex=0x0) [drawprim.c:1582] in wined3d (0x4068fd1c) 2 0x4a19dc57 IWineD3DDeviceImpl_DrawPrimitive+0x47(iface=0x403ec588, PrimitiveType=0x6, StartVertex=0x0, PrimitiveCount=0x2) [/home/jesse/wine-printf/dlls/wined3d/device.c:3504] in wined3d (0x4068fd50) 3 0x4a0244ee IDirect3DDevice9Impl_DrawPrimitive+0x1e(iface=0x403ac0f0, PrimitiveType=0x6, StartVertex=0x0, PrimitiveCount=0x2) [/home/jesse/wine-printf/dlls/d3d9/device.c:579] in d3d9 (0x4068fd68) 4 0x005c1ac0 in pirates! (+0x1c1ac0) (0x00000000) 0x4a1a5b30 drawPrimitive+0x230 [drawprim.c:1582] in wined3d: movl 0x0(%edx),%eax Unable to open file drawprim.c Wine-dbg> Since I had to hack wine to get it to run to this degree, here are the patches I tried out: d3d9_device.diff printf.diff printf_compare_warn.diff wined3d_vb_begin.diff By Oliver: wined3d_guids_01_os.diff wined3d_guids__newfiles_01_os.diff (slight fix to get this to compile) I'm not sure if I need an older patch of his. I also hacked dlls/wined3d/surface.c IWineD3DSurfaceImpl_UnlockRect() here: break; case D3DFMT_A8R8G8B8: case D3DFMT_X8R8G8B8: { The game calls the function with D3DFMT_X8R8G8B8. I think it could work like case D3DFMT_A8R8G8B8 since it's padded the same =) -- just without alpha -- and seemed to thus far. It allowed me to see the intro. Jesse

Jan. 31, 2005

[AppDB] bug on links

by Raphael

Hi, try http://appdb.winehq.org/appview.php?appId=443&versionId=627 select the www.darkageofcamelot.com link .... bug :) Regards, Raphael

Jan. 31, 2005

Re: [d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem

by Ann and Jason Edmeades

Well yes and no. The 'problem' is most of this code isn't implemented yet... Try Olivers large patch and see if things are any better, or wait a while while a whole load of code gets into cvs. Basically d3d9 shouldn't have any of the code relating to the stencil buffers - that will be in wine3d. I am pretty certain Olivers patch did that, and he is working on splitting it up to get cvs in sync with his local tree. Jason

Jan. 31, 2005

Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...

by Lionel Ulmer

> If it's not too much trouble, it would be nice if you list all the > known loose ends/bugs/optimisations/regressions so that (1) we can > explicitly track them, and (2) we get a sense of where we are and > how things are going. And last, but not least, there is the off chance > that someone might lend a helping hand (yeah, I know, chances are > slim to none, but still ... :)) Basically, the problem with OpenGL is that there is no way (that I know of) in OpenGL to do non-simple clipping (what I mean by 'non-simple' is non-rectangular). Ie if a (non top-level) OpenGL window is obscured by another (non top-level) window, there is no way (that is not a hack) to prevent GL to draw over the obscured window. The best way to fix this would be to have the X server export via a GLX extension its hardware clip-list implementation (which is something that I need to discuss with the FreeDesktop guys as this would be something that could help all the 3D X servers implementations which people are working on as, basically, it's exactly the same issue). The other way is to do indirect rendering for GL contexts not associated to top-level windows: basically, draw in a Pixmap (or a PBuffer) and then use the plain Wine 'DIB' code to blit this back-buffer to the screen (doing then the clipping). This should work easily at the price of some performance (especially on cards / drivers who do not support accelerated off-screen rendering). The additionnal advantage of the latter solution is to solve also the 'multiple windows / different GL attributes' problem. Lionel PS: I think we may have the same issue if we want (one day) to re-introduce Xv acceleration for video playback. -- Lionel Ulmer - http://www.bbrox.org/

Jan. 31, 2005

Re: [game] Running; Dark Reign - The future of war with Wine

by Lionel Ulmer

On Mon, Jan 31, 2005 at 05:45:15PM +0000, Mike Hearn wrote: > On Mon, 31 Jan 2005 16:23:49 +0100, Joachim Schiele wrote: > > My question is where should I start to search for the mouse problem? Was there > > a similar problem with other games in the past? Also note i've already tested > > the DX grab and the DGA settings with no effect. > > Look at DirectInput, a +dinput trace should be OK. Apparently our > DirectInput implementation isn't so hot ... Well, first try to apply Carlos' patch to see if it is the same issue that prevented Fallout to have the mouse working or if it is another one. And then do rather a +event,+dinput trace to see if the problem is in DInput or 'upstream' in Wine's event handler (which can happen if the game has focus problems for example). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 31, 2005

Re: Recruit regression testers?

by Lionel Ulmer

On Mon, Jan 31, 2005 at 10:41:34AM -0800, Scott Ritchie wrote: > I can confirm that this patch fixes things, at least for DInput in > Fallout I promise that one of these days I will look into it and try to understand exactly what the problem is (basically what I tried to do or which application to fix to introduce a more stringent check for correspondance between Wine's and the required data types)... While waiting for this day (i.e. when the snow melts, it's too good for now to miss any possible day out :-) ), this patch can go in. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 31, 2005

Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > If it's not too much trouble, it would be nice if you list all the > known loose ends/bugs/optimisations/regressions so that (1) we can > explicitly track them, and (2) we get a sense of where we are and > how things are going. And last, but not least, there is the off chance > that someone might lend a helping hand (yeah, I know, chances are > slim to none, but still ... :)) It's a bit hard to build a complete list, I mostly make it up as I go... The main optimisation I know about is the repainting on window moves that needs to copy the bits instead of invalidating the whole window. The loose ends are mostly related to dll separation, the exported functions in user32.spec can give you a rough idea of what remains to be done. For OpenGL what we need is to implement proper clipping when drawing to a child window. There are also a number of window management hacks in the Crossover tree that need to be cleaned up and brought over. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2005

Re: SHLWAPI: implement PathIsValidChar{A,W}

by Juan Lang

Hi Hans, > Yes I contemplated that but then you reintroduce a conditional in > the ascii case ( if (c > 0x7e) ), which somewhat defeats the > purpose of using a lookup table. Defeats? I don't think so. A single comparison that covers a large number of cases is different than a cascade of comparisons. Unless the compiler inlines PathIsValidCharAW, adding a comparison to PathIsValidCharA is faster than a function call anyway. > > Also, that means the data type can be unsigned char, not DWORD. > > I don't understand you, char class values are DWORD. You're right, that's my mistake. > > But for values of c greater than 0xff, you do not mask. This may > > be deliberate, I don't know, but it doesn't look correct. > > It's deliberate and correct. PATH_CHAR_CLASS_OTHER_VALID *is* a mask > so I do return the same value in both cases. Also remember that the > return type is a BOOL so we could return TRUE everywhere but I chose > to mimic Windows here and return a masked value. The tests show this > is the case. I'm still not sure it's correct. What if the call is PathIsValidCharW(0x1ff, PATH_CHAR_CLASS_LETTER) ? In this case, you return PATH_CHAR_CLASS_OTHER_VALID, which is 0x00000100. On the other hand, the call PathIsValidCharW('0', PATH_CHAR_CLASS_LETTER) returns 0. Your test cases don't capture the entire behavior, because the caller's mask and the character class are the same. But what if they are different? Test cases will show which is correct, of course. I've never used the function. I was just pointing out that the behavior for characters above 0xff is different than that for characters less than or equal to 0xff. Inconsistency usually means incorrectness. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Jan. 31, 2005