const cleanup round 1(commentary on what I found)

Some of this was included in the patch submission. Some of it I had questions about. spawn.c : warnings may or may not be harmless depending on if esecvp attempts to modify the results. Specs indicate it doesn't, but the function typing doesn't indicate so(the difference is 'const char * const

Want to be a Wine mentor for Google Summer of Code 2007?

I'm looking for active Wine developers to act as mentors for Google Summer of Code 2007. If you're interested, please let me know quickly; the list has to be finalized in the next half-day or so. (Sorry for the late notice; I wasn't paying attention, and the deadline snuck up on me...) - Dan

re: Add d3drmdef.h header - try 2

Vijay wrote: Add minimalistic d3drmdef.h But why? None of the code in wine currently needs it. Maybe you should submit it together with the first bit of code that needs it. -- Wine for Windows ISVs: http://kegel.com/wine/isv

Re: Add d3drmdef.h header

Hi, I have sent the fix for the problematic file, which I used a base. There a bug in bugzilla 7386 (http://bugs.winehq.org/show_bug.cgi?id=7386) , which needs implementation of D3DRM's vector functions. These are pure math functions. I am improving the fix given in bugzilla 7442 (http://bugs.win

Re: Add d3drmdef.h header

"Vijay Kiran Kamuju" <[EMAIL PROTECTED]> wrote: > +#ifndef __D3DRMDEFS_H__ > +#define __D3DRMDEFS_H__ I saw d3dtypes.h and other d3d header files, its defined like this only, no wine prefix has been added. No, it's not defined like this. That's exactly how microsoft does it, this is not ho

Re: Add d3drmdef.h header

Hi On 3/12/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: "Vijay Kiran Kamuju" <[EMAIL PROTECTED]> wrote: > I thought for completeness, we provide the entire header. > I did write all that with the help DirectX SDK. (Phew It took me 3 hrs > to type it) If it ends up as an almost exact copy of

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On Tue, March 13, 2007 00:41, James Hawkins wrote: > The list on my site has the problem, but every list I've seen has the > same problem. Maybe it's browser dependent. I use Firefox in Linux. > > http://wiki.winehq.org/JamesHawkins It looks like MoinMoin is doing something strange here, this r

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On Tue, March 13, 2007 01:02, Dan Kegel wrote: > Looks good, thanks. (It's a *nearly* thankless task, isn't it? :-) We're happy we can help ;) I also get really annoyed when things don't work, and believe me, we'd like to provide 99.9% uptime, but it's a lot harder than it looks :) We are (s

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On Tue, March 13, 2007 00:45, Vitaliy Margolen wrote: > Also the problem with misaligned table cells still not fixed: > http://wiki.winehq.org/KnownIssues While the generated HTML is not perfect for the table, it should render just find as AFACT. In fact, it does render OK in IE, but not in Firef

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On 3/12/07, Dimi Paun <[EMAIL PROTECTED]> wrote: > We had a problem on the server last night, and we had > to restore from backup. I'm still working on restoring > the Wine Wiki, hopefully I'll be able to restore it all. Things should be back to where they were. Please take a look and let me kno

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

Dimi Paun wrote: > On Mon, March 12, 2007 23:58, James Hawkins wrote: >> While we're talking about it, there's a strange issue with bulleted >> lists that has popped up recently, though I don't know exactly when it >> started. Some items have a larger font than other items in the list, >> which lo

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On 3/12/07, Dimi Paun <[EMAIL PROTECTED]> wrote: On Mon, March 12, 2007 23:58, James Hawkins wrote: > While we're talking about it, there's a strange issue with bulleted > lists that has popped up recently, though I don't know exactly when it > started. Some items have a larger font than other

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On Mon, March 12, 2007 23:58, James Hawkins wrote: > While we're talking about it, there's a strange issue with bulleted > lists that has popped up recently, though I don't know exactly when it > started. Some items have a larger font than other items in the list, > which looks rather silly. Any

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On Mon, March 12, 2007 22:06, Dimi Paun wrote: > We had a problem on the server last night, and we had > to restore from backup. I'm still working on restoring > the Wine Wiki, hopefully I'll be able to restore it all. OK, Things should be back to where they were. Please take a look and let me k

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On 3/12/07, Dimi Paun <[EMAIL PROTECTED]> wrote: On Mon, March 12, 2007 21:13, Dan Kegel wrote: > This, and all my other recent wiki changes, seem to > have vanished in a puff of greasy black smoke. > What's up? We had a problem on the server last night, and we had to restore from backup. I'm s

Re: Add d3drmdef.h header

"Vijay Kiran Kamuju" <[EMAIL PROTECTED]> wrote: I thought for completeness, we provide the entire header. I did write all that with the help DirectX SDK. (Phew It took me 3 hrs to type it) If it ends up as an almost exact copy of a microsoft header it's not worth an effort. +#ifndef __D3DRM

Re: Add casts to tools/makedep.c

"Gerald Pfeifer" <[EMAIL PROTECTED]> wrote: I accidently ended up building Wine using a C++ compiler the other day, and came across the following. -char *p = xmalloc (size); +char *p = (char*) xmalloc (size); That's a problem of C++ not Wine if it can't cope with casting voi

Re: CreateScalableFontResource - a few questions

"Chris Howe" <[EMAIL PROTECTED]> wrote: 2) NE binaries, including FOT files, contain as part of the header a DOS stub-executable that typically spits out a message of some sort. I reasoned that being in itself a compiled binary we can't legally use the blob of binary that would appear in a real-

Re: Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On Mon, March 12, 2007 21:13, Dan Kegel wrote: > This, and all my other recent wiki changes, seem to > have vanished in a puff of greasy black smoke. > What's up? We had a problem on the server last night, and we had to restore from backup. I'm still working on restoring the Wine Wiki, hopefully

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS fix

"Robert Shearman" <[EMAIL PROTECTED]> wrote: Andrew O. Shadoura wrote: break; } +if (flags & MB_USEGLYPHCHARS) { +for (i=0; i!=dstlen; i++) +if (dst[i]<0x20) dst[i]=glyph_xlat[dst[i]]; +} + I think you need to take into account the codepage when d

Re: DirectX 10 start as a SoC project?

On 3/11/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Regaring Vista, the nice thing is that Students get Educational licenses cheap. But the license should be checked carefully. I for example may use it only for educational purposes. As I am working for CodeWeavers my hacking on wine isn't pure

DirectX 10 start as a SoC project?

Hi, I think, that start working on Dx10 is a great opportunity to learn about wined3d, and Microsoft's new platform. I would like to apply, because i want to contribute to open source projects, and i'm really interested in wine, especially in wined3d. I have some patches in the tree, and I rea

Re: Set D3DCAPS2_DYNAMICTEXTURES flag

Shouldn't we use WINED3DCAPS2_DYNAMICTEXTURES rather than D3DCAPS2_DYNAMICTEXTURES ? Mirek Slugen Kovács András napsal(a): Hi, Set D3DCAPS2_DYNAMICTEXTURES flag. This makes Call of Duty 2 to run. Stefan told me, this function is supported, but we don't advertise it currently.

Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)

On 3/11/07, Dan Kegel <[EMAIL PROTECTED]> wrote: I'm putting a list together at http://wiki.winehq.org/DesktopMigrationProjects This, and all my other recent wiki changes, seem to have vanished in a puff of greasy black smoke. What's up? This isn't doing much for my trust in wikis... - Dan

Re: CreateScalableFontResource - a few questions

Hi Chris, > For my first foray into contributing to Wine Welcome! > would it be better to write something like a NE_SaveModule that takes > an in-memory NE module and saves it to disk, and call that from my > .FOT saving code? Only if it makes your code more readable. In general Wine doesn't s

Re: wined3d: Set wrapmode for cubemags to clamp regardeless of the sampler state

On 12/03/07, H. Verbeet <[EMAIL PROTECTED]> wrote: I've written a test for this, I'll send it tomorrow together with some other patches. Since this patch doesn't appear to have been applied yet, I can't submit my test yet. I've attached it to this mail instead. --- dlls/d3d9/tests/visual.c |

Re: LockRect Problem

On 3/12/07, H. Verbeet <[EMAIL PROTECTED]> wrote: On 12/03/07, Erich Hoover <[EMAIL PROTECTED]> wrote: > I think that the allocated memory should be the size of the resource > multiplied by 4 (instead of adding 4). What makes you think that? Just that (pLockedRect->Pitch * pRect->top) with pR

WineHQ maintenance

I will be performing some maintenance to WineHQ today at 14:30 CST. The recent outages on WineHQ were attributed to a faulty drive in the RAID. I will be taking the server offline to replace that drive. The server should only be offline for about 20 minutes. -newman

Re: Add d3drmdef.h header

Hi, I thought for completeness, we provide the entire header. I did write all that with the help DirectX SDK. (Phew It took me 3 hrs to type it) Thanks, VJ On 3/12/07, Dan Kegel <[EMAIL PROTECTED]> wrote: vijay wrote: > [complete d3drmdef.h] It seems premature to check that in without any cod

re: Add d3drmdef.h header

vijay wrote: [complete d3drmdef.h] It seems premature to check that in without any code that uses it. Also, did you really write all that yourself? - Dan

Re: DirectX 10 start as a SoC project?

Am Montag 12 März 2007 17:38 schrieb Jesse Allen: > On 3/11/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > I do not think d3d10 hardware is required yet, the reference rasterizer > > should work for the start. It is a long way to get any actual rendering > > going. > > Well if I am able to use

Re: DirectX 10 start as a SoC project?

On 12/03/07, Jesse Allen <[EMAIL PROTECTED]> wrote: On 3/11/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > I do not think d3d10 hardware is required yet, the reference rasterizer should > work for the start. It is a long way to get any actual rendering going. Well if I am able to use my laptop

Re: LockRect Problem

On 12/03/07, Erich Hoover <[EMAIL PROTECTED]> wrote: your explanation in bugzilla makes sense. Will you be taking care of this, or should I write up a patch with the divide by 4 and a bounds check? If you're willing to write a patch for this, sure. The patch should apply to DXT2-DXT5, and the

Re: DirectX 10 start as a SoC project?

On 3/11/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: I do not think d3d10 hardware is required yet, the reference rasterizer should work for the start. It is a long way to get any actual rendering going. Well if I am able to use my laptop, it has the ATI XPress 200M. DX9 compatible chip. Bu

Re: DirectX 10 start as a SoC project?

On 3/11/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Sonntag 11 März 2007 19:40 schrieb Jesse Allen: > > The concept is nice, and I'd like to learn 3D graphic APIs better. But > when I consider DX10, I don't have any DX10 apps, nor do I have Vista. > I'd also be concerned if it is even prope

Re: LockRect Problem

Am Montag 12 März 2007 06:04 schrieb Erich Hoover: > I'm looking into a problem that causes Supreme Commander to segfault (Bug > #7643 ) and I believe I may > have run into a problem with IWineD3DSurfaceImpl_LockRect. I believe the > > problem is a typo

Re: LockRect Problem

On 12/03/07, Erich Hoover <[EMAIL PROTECTED]> wrote: I think that the allocated memory should be the size of the resource multiplied by 4 (instead of adding 4). What makes you think that? IIRC the +4 there is for dodgy applications reading just past the end of the surface, but that line could d

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS fix

Andrew O. Shadoura wrote: break; } +if (flags & MB_USEGLYPHCHARS) { +for (i=0; i!=dstlen; i++) +if (dst[i]<0x20) dst[i]=glyph_xlat[dst[i]]; +} + I think you need to take into account the codepage when doing this translation. -- Rob Shearman

Re: wined3d: Allow SetCursorProperties on existing cursor

Please examine the attached corrections. Erich Hoover [EMAIL PROTECTED] On 3/11/07, H. Verbeet <[EMAIL PROTECTED]> wrote: On 11/03/07, Erich Hoover <[EMAIL PROTECTED]> wrote: > Is the attached what you mean? > > Erich Hoover > [EMAIL PROTECTED] > >+if (IWineD3DSurface_LockRect(pCursor

Re: wined3d: Allow SetCursorProperties on existing cursor

Is the attached what you mean? Erich Hoover [EMAIL PROTECTED] On 3/11/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Sonntag 11 März 2007 21:08 schrieb Erich Hoover: > Yeah, that would make more sense wouldn't it :) Please see attached patch. If you do it that way, you can remove the PreLo

LockRect Problem

I'm looking into a problem that causes Supreme Commander to segfault (Bug #7643 ) and I believe I may have run into a problem with IWineD3DSurfaceImpl_LockRect. I believe the problem is a typo in the line: This->resource.allocatedMemory = HeapAlloc(G

Re: winedbg: Support longer thread names

I am not very familiar with the winedbg code and do not see any easy (ie, non-hackish) way to get the length of the string in order to properly allocate the name size. I could read back a "large buffer" and use the string resulting from that to determine how large of a name to allocate, but that

Re: wined3d: Allow SetCursorProperties on existing cursor

Yeah, that would make more sense wouldn't it :) Please see attached patch. Erich Hoover [EMAIL PROTECTED] On 3/11/07, H. Verbeet <[EMAIL PROTECTED]> wrote: On 11/03/07, Erich Hoover <[EMAIL PROTECTED]> wrote: > So, which change exactly are you concerned about? Changes are: > 1) The removal of

Re: fog with pixel shaders < 3.0

On 12/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: With the precalculated No-Fog fog I pass values from [255,0] in the vertex attribs. GL fogstart = 255, end = 0, but that is bypassed with pixel shaders. Otherwise the Z value is used, which can be in any range. So yes, I think the fixed fun

Re: fog with pixel shaders < 3.0

> I think that if fog is disabled, we should be getting corresponding > values from vertex processing. Also, at least for the vertex shader > case we already clamp fog values in the vertex shader, so unless fixed > function can pass us values outside [0,1] we probably can get away > with not clampi

Re: fog with pixel shaders < 3.0

> As I see it, the No-Fog fog is a vertex fog where the fog weighting > parameter for every vertex is calculated by the application on the cpu > rather than by geometry pipeline. Yup. And it is also used if vertex fog is enabled but the app draws already transformed vertices. > Anyhow from MSDN:

Re: fog with pixel shaders < 3.0

I investigated the issue a bit further. Henri was right, the solution is much simpler than I initially thought. :) On Monday 12 March 2007 12:56, you wrote: > Am Montag 12 März 2007 10:35 schrieb Fabian Bieler: > > With pixel Shaders < SM 3.0, the fixed function fog calculation is still > perform

Re: [2/2] imm32: Fix the unwanted root_context string buffer cleanup code.

I'm sorry. This patch don't fix kinput2 case. kinput2 case may be wanted situation. but this patch fix the 'nabi' and 'scim' case. Hmm, I'll stop the my poor patch series. Thank you. Byeong-Sik Jeon worte: > kinput2: Japanese xim. when we press japanese/english toggle key > at the compos

Re: mswsock.dll, Soc & legal questions

be aware that the easy parts have been started in last year SoC, but weren't applied to the git tree yet, and the other parts are pretty much hard to implement (will require wine server requests changes, and those elements won't be done until some other changes on asynchronous requests are do

Re: fog with pixel shaders < 3.0

On 12/03/07, Fabian Bieler <[EMAIL PROTECTED]> wrote: This is what we have to do, imo: Take the value from the oFog register, and store it in gl_FogFragCoord (which is currently already done). At the end of the fragment shader, we have to clamp gl_FogFragCoord to [0,1] and used it to mix the frag

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

Thank you. Aric Stewart wrote: > Hello, > >yes, I think that is a good change. > >I use kinput2 for testing Japanese on linux. > > -aric >

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

Hello, yes, I think that is a good change. I use kinput2 for testing Japanese on linux. -aric Byeong-Sik Jeon wrote: Thank you. I understand. In my previous persnal mail for you([2/3] patch), how do you think about attached patch? and what is your xim program? I can't input Japanese str

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

Thank you. I understand. In my previous persnal mail for you([2/3] patch), how do you think about attached patch? and what is your xim program? I can't input Japanese string with scim( my xim program ). Aric Stewart wrote: > I am pretty sure that these are done via SendMessage when I checked wi

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

Thanks you. Dmitry Timoshkov wrote: > "Byeong-Sik Jeon" <[EMAIL PROTECTED]> wrote: > > > I think we have to use "PostMessage" to send WM_IME_SETCONTEXT too. > > Using the "SendMessage" change the real WM_IME_* message ordering. It > > caused misunderstooding when I tested for my IME message test

Re: Add implementation of D3DRMVector* functions

Hi, Currently I dont have a wine repository, so that I could not apply and test it. No time to change it :( Next will check properly. Thanks, VJ On 3/12/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: "Vijay Kiran Kamuju" <[EMAIL PROTECTED]> wrote: > This is a patch by David Adams, implementi

Re: Add implementation of D3DRMVector* functions

Hi, Can you update these comments to this bugzilla entry, #7442? Thanks, VJ On 3/12/07, H. Verbeet <[EMAIL PROTECTED]> wrote: On 12/03/07, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote: > Hi, > > This is a patch by David Adams, implementing D3DRMVector* functions in d3drm.dll > I am sending th

Re: fog with pixel shaders < 3.0

Am Montag 12 März 2007 13:16 schrieb H. Verbeet: > No, but the hash table functions in utils.c should be generic enough > to help at least a little bit with keeping track of the different > states. I am thinking more about completely removing a compiled shader rather than having 2 or more gl shad

CreateScalableFontResource - a few questions

Hi all, For my first foray into contributing to Wine (a blast, so far :) ) I am implementing CreateScalableFontResource which is currently present in stub form, but when fully implemented should create .FOT files from .TTF files for (amongst other things) temporarily installing fonts by a success

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

Hi, I think we have to use "PostMessage" to send WM_IME_SETCONTEXT too. Using the "SendMessage" change the real WM_IME_* message ordering. It caused misunderstooding when I tested for my IME message test program. But, at currently wine IME implementation, it is a minor problem. I'll consider this

Re: Add implementation of D3DRMVector* functions

On 12/03/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: 3. the patch is extremely buggy in memory allocations: instead of allocating the space for an object it allocates the space only for a pointer. I'd suggest to allocate all the objects on the stack instead. Hmm, I looked over that.

Re: Add implementation of D3DRMVector* functions

On 12/03/07, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote: Hi, This is a patch by David Adams, implementing D3DRMVector* functions in d3drm.dll I am sending the patch to this mailing list as this was posted on bugzilla and awaiting review. A few comments: - * Foundation, Inc., 51 Franklin S

Re: fog with pixel shaders < 3.0

On 12/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: With per fragment fog we have linear, exp and exp2. With glsl we can make it a parameter, but for arb shaders we have to hardwire it in the shader. I don't think we really want to use branching for that anyway. What we need for the start

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

I am pretty sure that these are done via SendMessage when I checked with Spy++. Additional a number of the applications I am working with hang when the WM_IME_NOTIFY is sent out of order. -aric Byeong-Sik Jeon wrote: We have to call PostMessage to send WM_IME_NOTIFY message. To send WM_IME_C

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

"Byeong-Sik Jeon" <[EMAIL PROTECTED]> wrote: I think we have to use "PostMessage" to send WM_IME_SETCONTEXT too. Using the "SendMessage" change the real WM_IME_* message ordering. It caused misunderstooding when I tested for my IME message test program. But, at currently wine IME implementation,

Re: fog with pixel shaders < 3.0

Am Montag 12 März 2007 10:35 schrieb Fabian Bieler: Ok, I am not so much into the whole fog + shader thing, so I am not sure if I understand the problem correcty. The vertex shader writes out fog values, which go into the fog equation. With just a vertex shader only it works, see the dolphin sd

Re: Add implementation of D3DRMVector* functions

"Vijay Kiran Kamuju" <[EMAIL PROTECTED]> wrote: This is a patch by David Adams, implementing D3DRMVector* functions in d3drm.dll I am sending the patch to this mailing list as this was posted on bugzilla and awaiting review. 1. it's not really nice to send something with name attachment.cgi as

Re: [try 3] wined3d: Implented signed texture formats via NV_TEXTURE_SHADER

Am Montag 12 März 2007 11:54 schrieb Fabian Bieler: > On Monday 12 March 2007 10:39, Stefan Dösinger wrote: > > You seem to add a 2nd table for GL_NV_texture_shader3 formats and try > > this table first. It is another solution for the static table problem I > > haven't thought of yet. For now, can

Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER

Am Montag 12 März 2007 00:30 schrieb Fabian Bieler: > The same patch as before, but with GL_DSDT_NV instead of GL_HILO8_NV as > suggested by Frank Richter. You seem to add a 2nd table for GL_NV_texture_shader3 formats and try this table first. It is another solution for the static table problem I

Re: wined3d: Allow SetCursorProperties on existing cursor

On 12/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Sonntag 11 März 2007 23:58 schrieb Erich Hoover: You can remove the SFLAG_FORCELOAD definition from wined3d_private.h now. You'll need to remove that from surface.c as well then.

fog with pixel shaders < 3.0

Hello! I'd like to get fog working in conjunction with pixel shaders 2.0 or earlier. The problem is that said shaders don't replace the fog stage in Direct3D. Adding the necessary fog calculations to a GLSL fragment shader is trivial, however, this results in a dependency of the shader on the cu

Re: quartz: Check allocation failure and clearmemoryinDSound Renderer

"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > If (void*)0 doesn't guarantee to actually set all bits to 0, then > HEAP_ZERO_MEMORY doesn't guarantee it either. Yes, that's the point. In theory you have to initialize things with an explicit assignment, instead of a memset or HEAP_ZERO_MEMORY. I

Re: wined3d: Allow SetCursorProperties on existing cursor

Am Sonntag 11 März 2007 23:58 schrieb Erich Hoover: > Is the attached what you mean? Yes, that looks better. A few minor things: You can remove the SFLAG_FORCELOAD definition from wined3d_private.h now. Also, if I remember right, the cursor must be A8R8G8B8, so instead of reading the description

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.

"Byeong-Sik Jeon" <[EMAIL PROTECTED]> wrote: We have to call PostMessage to send WM_IME_NOTIFY message. To send WM_IME_CONTROL, we use SendMessage, but WM_IME_NOTIFY is not... changelog: Use the PostMessageW for WM_IME_NOTIFY message. Aric just changed the code to use SendMessage for WM_IM

Re: wined3d: Allow SetCursorProperties on existing cursor

On 12/03/07, Erich Hoover <[EMAIL PROTECTED]> wrote: Please examine the attached corrections. Erich Hoover [EMAIL PROTECTED] Looks ok to me.