wine-devel April 2012

wine-devel@winehq.org

76 participants
181 discussions

Re: msvcp90: Add codecvt ctors and dtors
by Piotr Caban 16 Apr '12

16 Apr '12

Hi, On 04/16/12 02:50, William Panlener wrote: > typedef struct { > + locale_facet facet; > + /* FIXME: type definition in standard but var here */ > + enum { ok, partial, error, noconv } result; > +} codecvt_base; This structure has incorrect size. It should not contain result variable. > +typedef struct { > + codecvt_base base; > + /* FIXME: incomplete struct definition */ > +} codecvt_char_char_mbstate; It's better to define whole structure. Also other structures are named differently, it would be probably better to name it codecvt_char. > +typedef struct { > + codecvt_base base; > + /* FIXME: incomplete struct definition */ > +} codecvt_short_char_mbstate; > + > +typedef struct { > + codecvt_base base; > + /* FIXME: incomplete struct definition */ > +} codecvt_wchar_char_mbstate; There's no reason to define separate structures for unsigned short and wchar_t variants of the class. Probably the only difference between this classes is typeinfo structure. > +/* FIXME: Potentially unused */ > +/* ?id@?$codecvt@DDH@std@@2V0locale@2@A */ > +locale_id codecvt_char_char_mbstate_id = {0}; I don't understand this comment. The id fields will be used by locale class. > +/* ??1codecvt_base@std@@UAE@XZ */ > +/* ??1codecvt_base@std@@UEAA@XZ */ > +DEFINE_THISCALL_WRAPPER(codecvt_base_dtor, 4) > +void __thiscall codecvt_base_dtor(codecvt_base *this) > +{ > + FIXME("(%p)\n stub!", this); > + TRACE("(%p)\n", this); > +} There's no need to use both FIXME and TRACE. > +/* ??1?$codecvt@DDH@std@@MAE@XZ */ > +/* ??1?$codecvt@DDH@std@@MEAA@XZ */ > +DEFINE_THISCALL_WRAPPER(codecvt_char_char_mbstate_dtor, 4) > +void __thiscall codecvt_char_char_mbstate_dtor(codecvt_char_char_mbstate *this) > +{ > + /*FIXME stub*/ > + codecvt_base_dtor(&this->base); > + TRACE("(%p)\n", this); > +} It's better to print a fixme message here. > +DEFINE_RTTI_DATA(codecvt_char_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor, NULL, NULL, " ?AV?$codecvt@DDH@std@@"); > +DEFINE_RTTI_DATA(codecvt_short_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor, NULL, NULL, " ?AV?$codecvt@GDH@std@@"); > +DEFINE_RTTI_DATA(codecvt_wchar_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor, NULL, NULL, ".?AV?$codecvt@_WDH@std@@"); The RTTI data for these structures is incorrect. > + __ASM_VTABLE(codecvt_base, ""/*FIXME*/); > + __ASM_VTABLE(codecvt_char_char_mbstate, ""/*FIXME*/); > + __ASM_VTABLE(codecvt_short_char_mbstate, ""/*FIXME*/); > + __ASM_VTABLE(codecvt_wchar_char_mbstate, ""/*FIXME*/); It's better to create correct virtual functions table. This may lead to some strange crashes.

1 0

Re: [PATCH 1/3] browseui: Add IOleWindow to IProgressDialog
by Nikolay Sivov 15 Apr '12

15 Apr '12

On 4/15/2012 23:08, Detlef Riekenberg wrote: > Used by apps to adjust the dialog position > or remove the cancel button before vista > > -- > By by ... Detlef > --- > dlls/browseui/progressdlg.c | 69 ++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 68 insertions(+), 1 deletions(-) > > diff --git a/dlls/browseui/progressdlg.c b/dlls/browseui/progressdlg.c > index 9b970e2..2807622 100644 > --- a/dlls/browseui/progressdlg.c > +++ b/dlls/browseui/progressdlg.c > @@ -60,6 +60,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(browseui); > > typedef struct tagProgressDialog { > IProgressDialog IProgressDialog_iface; > + IOleWindow IOleWindow_iface; > LONG refCount; > CRITICAL_SECTION cs; > HWND hwnd; > @@ -79,6 +80,11 @@ static inline ProgressDialog *impl_from_IProgressDialog(IProgressDialog *iface) > return CONTAINING_RECORD(iface, ProgressDialog, IProgressDialog_iface); > } > > +static inline ProgressDialog *impl_from_IOleWindow(IOleWindow *iface) > +{ > + return CONTAINING_RECORD(iface, ProgressDialog, IOleWindow_iface); > +} > + > static void set_buffer(LPWSTR *buffer, LPCWSTR string) > { > static const WCHAR empty_string[] = {0}; > @@ -270,9 +276,20 @@ static HRESULT WINAPI ProgressDialog_QueryInterface(IProgressDialog *iface, REFI > ProgressDialog *This = impl_from_IProgressDialog(iface); > *ppvOut = NULL; > > - if (IsEqualIID(iid,&IID_IUnknown) || IsEqualIID(iid,&IID_IProgressDialog)) > + if (IsEqualIID(iid,&IID_IUnknown)) > { > *ppvOut = This; > + TRACE("(%p, IID_IUnknown, %p) -> %p\n", This, ppvOut, This); > + } > + else if (IsEqualIID(iid,&IID_IProgressDialog)) > + { > + *ppvOut = This; > + TRACE("(%p, IID_IProgressDialog, %p) -> %p\n", This, ppvOut, This); > + } > + else if (IsEqualIID(iid,&IID_IOleWindow)) > + { > + *ppvOut =&This->IOleWindow_iface; > + TRACE("(%p, IID_IOleWindow, %p) -> %p\n", This, ppvOut, *ppvOut); > } What's a point in different traces? A single one is enough, with printed riid of course. Also please return iface instead of This, like *ppvOut = iface;, or if you prefer instance pointer add a pointer to interface like - &This->... > > if (*ppvOut) > @@ -495,6 +512,55 @@ static const IProgressDialogVtbl ProgressDialogVtbl = > ProgressDialog_Timer > }; > > +static HRESULT WINAPI OleWindow_QueryInterface(IOleWindow *iface, REFIID iid, LPVOID *ppvOut) > +{ > + ProgressDialog *This = impl_from_IOleWindow(iface); > + > + TRACE("(%p, %s, %p)\n", iface, debugstr_guid(iid), ppvOut); > + return ProgressDialog_QueryInterface(&This->IProgressDialog_iface, iid, ppvOut); > +} > + This trace should go to ProgressDialog_QueryInterface(), no need to place it in every interface.

1 0

Re: ddraw/tests: Compare the correct surface pointers.
by Marvin 15 Apr '12

15 Apr '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17873 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(00A70028) === WXPPROSP3 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(00BA0028) === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(00E40028) === WVISTAADM (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(02210028) === W2K8SE (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(02800028) === W7PRO (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(01BF0028) === W7PROX64 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(02740028) === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(00000000) differs from the one returned by Lock(02690028) === W7PROX64 (64 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(0000000000000000) differs from the one returned by Lock(0000000002390040) === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:272: Test failed: lpSurface from GetSurfaceDesc(0000000000000000) differs from the one returned by Lock(0000000002360040)

2 1

Re: [PATCH 1/3] browseui: Add IOleWindow to IProgressDialog
by Michael Stefaniuc 15 Apr '12

15 Apr '12

Hello Detlef, On 04/15/2012 10:08 PM, Detlef Riekenberg wrote: > Used by apps to adjust the dialog position > or remove the cancel button before vista > > -- > By by ... Detlef > --- > dlls/browseui/progressdlg.c | 69 ++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 68 insertions(+), 1 deletions(-) > > diff --git a/dlls/browseui/progressdlg.c b/dlls/browseui/progressdlg.c > index 9b970e2..2807622 100644 > --- a/dlls/browseui/progressdlg.c > +++ b/dlls/browseui/progressdlg.c > @@ -270,9 +276,20 @@ static HRESULT WINAPI ProgressDialog_QueryInterface(IProgressDialog *iface, REFI > ProgressDialog *This = impl_from_IProgressDialog(iface); > *ppvOut = NULL; > > - if (IsEqualIID(iid, &IID_IUnknown) || IsEqualIID(iid, &IID_IProgressDialog)) > + if (IsEqualIID(iid, &IID_IUnknown)) > { > *ppvOut = This; > + TRACE("(%p, IID_IUnknown, %p) -> %p\n", This, ppvOut, This); > + } > + else if (IsEqualIID(iid, &IID_IProgressDialog)) > + { > + *ppvOut = This; this is not correct as ppvOut takes an interface and not an object. While at it please fix the above one too. thanks bye michael

1 0

[GSoC] Reduce dependency on native dlls
by William Panlener 15 Apr '12

15 Apr '12

My name is William Panlener, and I am currently attending the University of Mississippi as a first semester Masters student in Computer Science. This is my first time participating in GSoC. My proposal for GSoC involves choosing an application with high dependence on native dlls and implementing enough stubs so as to eliminate this dependency. I chose the game, League of Legends, and its installer, Pando Media Booster. Most stubs that require implementation are in msvcp90 and wininet. I have two concerns with this proposal: 1) Is it unusual to work towards improving a specific application rather than focusing on a specific component of wine? 2) The scope of the project is difficult to gauge in advance since the next problematic stub cannot be identified until all the previous problematic stubs are taken care of. Is this an issue for a GSoC proposal? I would be more than willing to revise my proposal (if this is allowed) if either of the above points is a problem.

2 1

Re: [1/2] comctl32/tests: Added tests for mouse events handling (try 3)
by Dmitry Timoshkov 15 Apr '12

15 Apr '12

Daniel Jelinski <djelinski1(a)gmail.com> wrote: > Skipping tests on WinNT - older versions of comctl send a different > set of events. Then you need to figure out what is different, and make the tests pass there as well (there is 'optional' flag for that), otherwise you risk breaking applications written for NT. > + /* WM_RBUTTONDOWN does not return until it gets another mouse event. > + Make sure it gets one by posting WM_RBUTTONUP to message queue */ > + PostMessageA(hTree, WM_RBUTTONUP, 0, (LPARAM)0x10001); > + /* this sequence should NOT send WM_CONTEXTMENU */ > + SendMessageA(hTree, WM_RBUTTONDOWN, 2, (LPARAM)0x10001); > + > + /* ditch the first sequence as it processed more messages than we need. Redo */ > + flush_sequences(sequences, NUM_MSG_SEQUENCES); > + > + PostMessageA(hTree, WM_RBUTTONUP, 0, (LPARAM)0x10001); > + SendMessageA(hTree, WM_RBUTTONDOWN, 2, (LPARAM)0x10001); This can't work. If you use PostMessage you need to flush message queue before testing the sequence. Using SendMessage after PostMessage doesn't guarantee that a posted message is handled before a sent one, you may try generating hardware messages instead. > + > + if(sequences[PARENT_SEQ_INDEX]->sequence->message == 0x133) > + { > + win_skip("Comctl32 versions prior to 5.80 send different set of events"); > + return; > + } Please use symbolic names for messages instead of magic numbers. -- Dmitry.

4 5

automate winedbg IDE integration
by Ilya Basin 15 Apr '12

15 Apr '12

Hi developers. There's a manual on this page: http://www.winehq.org/docs/winedev-guide/dbg-others > Start the Wine debugger with a command line like: > winedbg --gdb --no-start <name_of_exe_to_debug.exe> > Start ddd > In ddd, use the 'Open File' or 'Open Program' to point to the Wine executable (which is either wine-pthread or wine-kthread depending on your settings). > In the output of 1/, there's a line like > target remote localhost:32878 > copy that line and paste into ddd command pane (the one with the (gdb) prompt) So many steps. Is there an easier way? Or maybe everyone use plain winedbg without any IDE?

2 5

winedbg-eclipse - winedbg wrapper for Eclipse IDE
by Ilya Basin 14 Apr '12

14 Apr '12

- Get Eclipse 3.7.2 CDT - Import existing code as Makefile (a wine component or a standalone - winelib program) - Check "Automate discovery" in project properties/C/C++ Build/Discovery - Create a standart C/C++ Application debug configuration - Set *.exe.so as application - Set winedbg-eclipse as GDB debugger - fix bugs faster!

1 0

Re: Wine release 1.5.2
by mike＠yurick.ca 13 Apr '12

13 Apr '12

I am no longer using this e-mail. Please contact me for my new e-mail address. Thank you, Mike

1 0

Re: vbscript: Short if statement may have optional 'end if'
by Marvin 13 Apr '12

13 Apr '12

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2012