March 2007 - Wine-Devel - list.winehq.org

Re: [2/2] imm32: Fix the unwanted root_context string buffer cleanup code.
by Byeong-Sik Jeon March 12, 2007

March 12, 2007

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 composition state before commit, we lost composition > string. > nabi : Korean xim. same 'kinput2' case. > scim : General IM platform. when we input Japanese string, if > we press the "commit key(ENTER)", then we lost the all > composition string. > > This patch fix all above. > --- > dlls/imm32/imm.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-)

1 0

mswsock.dll, Soc & legal questions
by Benoit Pradelle March 12, 2007

March 12, 2007

Hi, I'm pretty interested in implementing mswsock.dll as a SoC this summer : this dll seems to be used by many apps and it's, I think, the sort of job I can do. As I'm not a Wine dev, I was wondering about how should I work for implementing this lib : should I juste use the MSDN description of the functions and make some tests with some apps to validate the behavior ? Or can I take the original dll, execute some apps with it and try to see how the dll is interacting with other libs, what sort of network traffic is generated, etc ? Is this solution possible with the microsoft license ? Thanks, Ben

2 2

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.
by Aric Stewart March 12, 2007

March 12, 2007

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_CONTROL, we use SendMessage, but WM_IME_NOTIFY is not... > > changelog: > Use the PostMessageW for WM_IME_NOTIFY message. > --- > dlls/imm32/imm.c | 25 ++++++++----------------- > 1 files changed, 8 insertions(+), 17 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 02a362e..034d4ea 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -77,8 +77,8 @@ static UINT WM_MSIME_DOCUMENTFEED; > */ > static LRESULT WINAPI IME_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, > LPARAM lParam); > +static LRESULT ImmInternalPostIMEMessage(UINT, WPARAM, LPARAM); > static void UpdateDataInDefaultIMEWindow(HWND hwnd); > -static void ImmInternalPostIMEMessage(UINT, WPARAM, LPARAM); > static void ImmInternalSetOpenStatus(BOOL fOpen); > > static VOID IMM_PostResult(InputContextData *data) > @@ -160,16 +160,7 @@ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpReserved) > } > > /* for posting messages as the IME */ > -static void ImmInternalPostIMEMessage(UINT msg, WPARAM wParam, LPARAM lParam) > -{ > - HWND target = GetFocus(); > - if (!target) > - PostMessageW(root_context->hwnd,msg,wParam,lParam); > - else > - PostMessageW(target, msg, wParam, lParam); > -} > - > -static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > +static LRESULT ImmInternalPostIMEMessage(UINT msg, WPARAM wParam, LPARAM lParam) > { > HWND target; > > @@ -177,7 +168,7 @@ static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > if (!target) target = GetFocus(); > > if (target) > - return SendMessageW(target, WM_IME_NOTIFY, notify, lParam); > + return PostMessageW(target, msg, wParam, lParam); > > return 0; > } > @@ -214,7 +205,7 @@ static void ImmInternalSetOpenStatus(BOOL fOpen) > else > ShowWindow(hwndDefault, SW_SHOWNOACTIVATE); > > - ImmInternalSendIMENotify(IMN_SETOPENSTATUS, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETOPENSTATUS, 0); > } > > > @@ -1243,7 +1234,7 @@ BOOL WINAPI ImmSetCompositionFontA(HIMC hIMC, LPLOGFONTA lplf) > MultiByteToWideChar(CP_ACP, 0, lplf->lfFaceName, -1, data->font.lfFaceName, > LF_FACESIZE); > > - ImmInternalSendIMENotify(IMN_SETCOMPOSITIONFONT, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETCOMPOSITIONFONT, 0); > > if (data->textfont) > { > @@ -1267,7 +1258,7 @@ BOOL WINAPI ImmSetCompositionFontW(HIMC hIMC, LPLOGFONTW lplf) > return FALSE; > > memcpy(&data->font,lplf,sizeof(LOGFONTW)); > - ImmInternalSendIMENotify(IMN_SETCOMPOSITIONFONT, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETCOMPOSITIONFONT, 0); > > if (data->textfont) > { > @@ -1418,7 +1409,7 @@ BOOL WINAPI ImmSetCompositionWindow( > if (reshow) > ShowWindow(hwndDefault,SW_SHOWNOACTIVATE); > > - ImmInternalSendIMENotify(IMN_SETCOMPOSITIONWINDOW, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETCOMPOSITIONWINDOW, 0); > return TRUE; > } > > @@ -1447,7 +1438,7 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > if (hIMC == (HIMC)FROM_IME) > { > ImmInternalSetOpenStatus(fOpen); > - ImmInternalSendIMENotify(IMN_SETOPENSTATUS, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETOPENSTATUS, 0); > return TRUE; > } >

2 3

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.
by Dmitry Timoshkov March 12, 2007

March 12, 2007

"Byeong-Sik Jeon" <wjsqudtlr(a)gmail.com> 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_IME_NOTIFY message. Sounds like it's time to write some message tests or look at the existing ones (which confirm that WM_IME_SETCONTEXT and WM_IME_NOTIFY are sent, not posted). -- Dmitry.

2 3

Re: Add implementation of D3DRMVector* functions
by Dmitry Timoshkov March 12, 2007

March 12, 2007

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> 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 a patch. 2. the patch has inconsistent formatting and very hard to read due to that 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. -- Dmitry.

3 2

Re: Add implementation of D3DRMVector* functions
by H. Verbeet March 12, 2007

March 12, 2007

On 12/03/07, Vijay Kiran Kamuju <infyquest(a)gmail.com> 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 St, Fifth Floor, Boston, MA 02110-1301, USA >+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 0;2110;-130;1, USA I don't think that change should be there. >+ LPD3DVECTOR result=(LPD3DVECTOR)(malloc(sizeof(LPD3DVECTOR))); That and other places in that patch should be using HeapAlloc/HeapFree >+LPD3DVECTOR D3DRMAPI D3DRMVectorRandom(LPD3DVECTOR d) >+{ >+ >+ srand(time(NULL)); >+ d->x=(float)(rand()); >+ d->y=(float)(rand()); >+ d->z=(float)(rand()); >+ TRACE("Random vector=(%f,%f,%f)\n",d->x,d->y,d->z); >+ return d; >+} I'm not sure about this, but I'm thinking it might be better to generate a normalized vector there. - The indentation in D3DRMVectorRotate is a bit of a mess - Writing test cases doesn't hurt, and in this case should be pretty easy

2 1

Re: [try 3] wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
by Stefan Dösinger March 12, 2007

March 12, 2007

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 you just hardcode the formats in the > > normal table? It should not cause any issues otherwise, because the > > function looking for a surface conversion will filter them out anyway. > > This patch includes the requested changes. I did not implement the > conversions for the new pixel formats, as that would not help anything > without also alterting the fragment shaders. Almost perfect :-) + {WINED3DFMT_X8L8V8U8 ,0x0 ,0x0 ,0x0 ,0x0 ,4 ,FALSE ,GL_DSDT8_MAG8_INTENSITY8_NV,GL_DSDT_MAG_INTENSITY_NV,GL_BYTE}, Can you align the } with the other lines? (I'm picky because it is very tricky to fix the formating afterwards)

1 0

Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
by Stefan Dösinger March 12, 2007

March 12, 2007

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 haven't thought of yet. For now, can you just hardcode the formats in the normal table? It should not cause any issues otherwise, because the function looking for a surface conversion will filter them out anyway. It is mostly my own fault; When I created that pixel format table almost a year ago, we only had static formats which were supported by the gl core, or by a max of one extension. Nowadays the table hits the limit with bump map formats, and sRGB textures. I think it is time to think about changing the design. A few ideas by me: * Stop making the table static and keep one table per adapter. Then we can insert the proper formats depending on the supported extensions at initialization time +: One table to search for a format -: No solution for sRGB * Duplicate the tables, create extra tables for sRGB formats and per-extension tables +: Tables stay static -: Multiple tables look nasty. Can get out of control * Put one format into the table, select other per-extension formats in d3dfmt_get_conv. +: One table +: Simmilar to the color keying and palette handling -: No solution for sRGB -: Complicated, final format hard to read from pixel format table * Add extra columns to the table to allow multiple table entries per format: like a flag sRGB, and a supported extension. +: One table, stays static +: Deals with sRGB formats -: Searching for a format gets more complex, will be more expensive than with the many tables approach. * Replace the table with a function with a huge switch statement. +: Can deal with all sorts of parameters dynamically +: Not really more expensive than a lookup table with a linear search +: If done right should be easy to read -: We have had that before, it didn't look nice(ok, it used 3 different functions)

1 0

Re: wined3d: Allow SetCursorProperties on existing cursor
by Erich Hoover March 12, 2007

March 12, 2007

> > Am Samstag 10 März 2007 06:10 schrieb Erich Hoover: > >* Real Name: > *>* Erich Hoover > *>* Description: > *>* The SetCursorProperties call needs to be capable of being performed on > *>* existing cursors. The current behavior removes the cursor handle at the > *>* beginning of any SetCursorProperties call (and on Uninit3D). The removal > *>* of the cursor on SetCursorProperties is counter to the documentation and > *>* causes some applications to lose the cursor when SetCursorProperties is > *>* re-issued (See Bug #7619 <http://bugs.winehq.org/show_bug.cgi?id=7619>). > *>* This patch corrects this issue and permits SetCursorProperties to retrieve > *>* the gl texture of an old cursor. > *>* Changelog: > *>* wined3d: Allow SetCursorProperties on existing cursor > *This is not completely correct: > > The application can Release the d3d surface after setting the cursor. This > would also delete the gl texture used to draw the cursor. Also, the apps can > potentially change the surface and call PreLoad. This would change the cursor > without SetCursorProperties(The cursor texture does not have to be in > D3DPOOL_SCRATCH, so the app can preload it manually). > > But you are right, a non-dirty surface causes issues with the current code. I > think you can fix that by modifying LoadTexture not to release the surface > memory is SFLAG_FORCELOAD is passed. (Or better, fix the SFLAG_DONOTFREE > macro in wined3d_private.h). Then, when SetCursorProperties sets the surface > texture to 0 remove SFLAG_INTEXTURE from the surface flags. > > The API documentation doesn't say anything about an application releasing the d3d surface, but the documentation in the code seems to indicate that the gl texture needs to remain when the surface is deleted - I did nothing to change this. What I did see as requiring a change is the call to "glDeleteTextures(1, &This->cursorTexture);" at the beginning of SetCursorProperties. Maybe I'm not understanding you correctly, but in my mind it is necessary to remove this call so that applications that re-use the same cursor can do so. This change (in combination with the change for non-dirty surfaces) was also experimentally verified to fix the problem I was experiencing (See Bug #7619<http://bugs.winehq.org/show_bug.cgi?id=7619>). I will look into changing/implementing the flags to eliminate the "non-dirty surface" problem. Erich Hoover ehoover(a)mines.edu

4 12

Re: quartz: Check allocation failure and clear memory in DSound Renderer
by Detlef Riekenberg March 12, 2007

March 12, 2007

On Fr, 2007-03-09 at 03:02 -0800, Chris Robinson wrote: > + ZeroMemory(pDSoundRender, sizeof(DSoundRenderImpl)); Since you clear the whole struct, ... > pDSoundRender->lpVtbl = &DSoundRender_Vtbl; > pDSoundRender->IBasicAudio_vtbl = &IBasicAudio_Vtbl; > @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, > LPVOID * ppv) > pDSoundRender->pClock = NULL; > pDSoundRender->init = FALSE; > pDSoundRender->started = FALSE; ... there is no need to clear it again. -- By by ... Detlef

5 8