December 2008 - Wine-Devel - list.winehq.org

Re: Wine build failed

by Stefan Leichter

Am Tuesday 23 December 2008 20:48 schrieb Austin English: > On Tue, Dec 23, 2008 at 3:43 AM, Stefan Leichter <sle85276(a)gmx.de> wrote: > > make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/gdi32' > > make[1]: *** [gdi32] Fehler 2 > > make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' > > make: *** [dlls] Fehler 2 > > A fix was committed today, please retest. The build today was successful. -- Stefan

Dec. 27, 2008

RE: Simplify dlls/comctl32/nativefont.c

by ricardo filipe

are you sure windows doesn't call those functions with those parameters? you have to check that before sending patches like these ... ---------------------------------------- > Date: Sat, 27 Dec 2008 08:57:44 +0100 > From: gerald(a)pfeifer.com > To: wine-patches(a)winehq.org > Subject: Simplify dlls/comctl32/nativefont.c > > ChangeLog: > Simplify NATIVEFONT_Create. > > Index: dlls/comctl32/nativefont.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/nativefont.c,v > retrieving revision 1.29 > diff -u -3 -p -r1.29 nativefont.c > --- dlls/comctl32/nativefont.c 24 Oct 2008 13:13:47 -0000 1.29 > +++ dlls/comctl32/nativefont.c 27 Dec 2008 07:57:10 -0000 > @@ -47,7 +47,7 @@ typedef struct > #define NATIVEFONT_GetInfoPtr(hwnd) ((NATIVEFONT_INFO *)GetWindowLongPtrW (hwnd, 0)) > > static LRESULT > -NATIVEFONT_Create (HWND hwnd, WPARAM wParam, LPARAM lParam) > +NATIVEFONT_Create (HWND hwnd) > { > NATIVEFONT_INFO *infoPtr; > > @@ -85,7 +85,7 @@ NATIVEFONT_WindowProc (HWND hwnd, UINT u > switch (uMsg) > { > case WM_CREATE: > - return NATIVEFONT_Create (hwnd, wParam, lParam); > + return NATIVEFONT_Create (hwnd); > > case WM_DESTROY: > return NATIVEFONT_Destroy (infoPtr); > > _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/events.aspx

Dec. 27, 2008

Re: [PATCH 5/6] dinput: Fix usage of HeapReAlloc.

by Alexandre Julliard

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > + if (!have_joydevs) > + joydevs = HeapAlloc(GetProcessHeap(), 0, sizeof(struct JoyDev)); > + else > + joydevs = HeapReAlloc(GetProcessHeap(), 0, joydevs, (1 + have_joydevs) * sizeof(struct JoyDev)); > + > + if (!joydevs) > + { > + close(fd); > + continue; > + } While you are fixing it you should fix it properly by preserving the old pointer on failure. -- Alexandre Julliard julliard(a)winehq.org

Dec. 27, 2008

Re: [2/2] mshtml: Add VT_INT support in IHTMLElementCollection_item

by Jacek Caban

Hi Konstantin, Konstantin Kondratyuk wrote: > Hi, Jacek! > > On Friday 19 December 2008 18:04:45 Jacek Caban wrote: > >> You're duplicating the code that handles VT_I4 case. Please avoid it. >> > > Do you think, this code will be better? And can I truncate "VT_I4" from trace? > Yes, it looks better, but I'd suggest to move this code to separated function. > And about my test for this problem - it's OK? > > Yes, it's OK. There is one improvement that would be nice to have. You could test returned disp better than comparing to NULL. It could look like an attached patch (compile tested only). Also tests must pass after each patch, so you should change order of patches or mark them as todo_wine and remove todo_wine in second patch or send both changes in one patch. I'd suggest sending in one patch in this case. Thanks, Jacek diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c index aa8dbb8..7d821e6 100644 --- a/dlls/mshtml/tests/dom.c +++ b/dlls/mshtml/tests/dom.c @@ -1005,7 +1005,7 @@ static void _test_elem_collection(unsigned line, IUnknown *unk, long len; DWORD i; VARIANT name, index; - IDispatch *disp; + IDispatch *disp, *disp2; HRESULT hres; hres = IUnknown_QueryInterface(unk, &IID_IHTMLElementCollection, (void**)&col); @@ -1021,9 +1021,9 @@ static void _test_elem_collection(unsigned line, IUnknown *unk, len = exlen; V_VT(&index) = VT_EMPTY; - V_VT(&name) = VT_I4; for(i=0; i<len; i++) { + V_VT(&name) = VT_I4; V_I4(&name) = i; disp = (void*)0xdeadbeef; hres = IHTMLElementCollection_item(col, name, index, &disp); @@ -1032,10 +1032,21 @@ static void _test_elem_collection(unsigned line, IUnknown *unk, if(FAILED(hres) || !disp) continue; + if(!i) { + V_VT(&name) = VT_INT; + V_INT(&name) = i; + disp2 = (void*)0xdeadbeef; + hres = IHTMLElementCollection_item(col, name, index, &disp2); + ok_(__FILE__,line) (hres == S_OK, "item(%d) failed: %08x\n", i, hres); + ok_(__FILE__,line) (disp == disp2, "disp != disp2\n"); + IDispatch_Release(disp2); + } + _test_elem_type(line, (IUnknown*)disp, elem_types[i]); IDispatch_Release(disp); } + V_VT(&name) = VT_I4; V_I4(&name) = len; disp = (void*)0xdeadbeef; hres = IHTMLElementCollection_item(col, name, index, &disp);

Dec. 27, 2008

Re: winecfg: Add dll override on return key press in combobox [resend]

by Dmitry Timoshkov

"Andre Wisplinghoff" <andre.wisplinghoff(a)gmail.com> wrote: >>> +INT_PTR CALLBACK >>> +comboedit_wndproc (HWND hEdit, UINT uMsg, WPARAM wParam, LPARAM lParam) >> >> INT_PTR is wrong return value type for a window proc. > > so it should be HRESULT? No. > INT_PTR is used for other window procs in > programs/winecfg/libraries.c, too. INT_PTR is used for dialog procs. >>> + /* subclass dllcombo's edit to allow return keypress handling */ >>> + GetComboBoxInfo(GetDlgItem(dialog, IDC_DLLCOMBO), &cbinfo); >>> + edit = cbinfo.hwndItem; /* retrieve edit box handle */ >>> + oldWndProc = (LONG_PTR)SetWindowLong(edit, GWL_WNDPROC, >>> + (DWORD) comboedit_wndproc); >>> + SetWindowLong(edit, GWL_USERDATA, (DWORD)oldWndProc); >> >> The code is above is not 64-bit safe. > > I'm not used to 64-bit programming but willing to learn. Is using > SetWindowLongPtr enough to make it 64-bit safe?: > > oldWndProc = SetWindowLongPtr(edit, GWL_WNDPROC, > (LONG_PTR) comboedit_wndproc); > SetWindowLongPtr(edit, GWL_USERDATA, (LONG_PTR) oldWndProc); Yes, along with GWLP_WNDPROC. -- Dmitry.

Dec. 27, 2008

Re: winecfg: Add dll override on return key press in combobox [resend]

by Reece Dunn

2008/12/27 Andre Wisplinghoff <andre.wisplinghoff(a)gmail.com>: > 2008/12/27 Dmitry Timoshkov <dmitry(a)codeweavers.com>: >> "Andre Wisplinghoff" <andre.wisplinghoff(a)gmail.com> wrote: >> >>> +INT_PTR CALLBACK >>> +comboedit_wndproc (HWND hEdit, UINT uMsg, WPARAM wParam, LPARAM lParam) >> >> INT_PTR is wrong return value type for a window proc. > > so it should be HRESULT? INT_PTR is used for other window procs in > programs/winecfg/libraries.c, too. LRESULT is the return type for WndProc functions. HRESULT is used by COM. The signatures for the other WndProc functions should be fixed too, but in a different patch. >>> + /* subclass dllcombo's edit to allow return keypress handling */ >>> + GetComboBoxInfo(GetDlgItem(dialog, IDC_DLLCOMBO), &cbinfo); >>> + edit = cbinfo.hwndItem; /* retrieve edit box handle */ >>> + oldWndProc = (LONG_PTR)SetWindowLong(edit, GWL_WNDPROC, >>> + (DWORD) comboedit_wndproc); >>> + SetWindowLong(edit, GWL_USERDATA, (DWORD)oldWndProc); >> >> The code is above is not 64-bit safe. > > I'm not used to 64-bit programming but willing to learn. Is using > SetWindowLongPtr enough to make it 64-bit safe?: > > oldWndProc = SetWindowLongPtr(edit, GWL_WNDPROC, > (LONG_PTR) comboedit_wndproc); > SetWindowLongPtr(edit, GWL_USERDATA, (LONG_PTR) oldWndProc); Should be. However, you should use GWLP_WNDPROC and GWLP_USERDATA instead (http://msdn.microsoft.com/en-us/library/ms644898(VS.85).aspx) - Reece

Dec. 27, 2008

Re: winecfg: Add dll override on return key press in combobox [resend]

by Andre Wisplinghoff

2008/12/27 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Andre Wisplinghoff" <andre.wisplinghoff(a)gmail.com> wrote: > >> +INT_PTR CALLBACK >> +comboedit_wndproc (HWND hEdit, UINT uMsg, WPARAM wParam, LPARAM lParam) > > INT_PTR is wrong return value type for a window proc. so it should be HRESULT? INT_PTR is used for other window procs in programs/winecfg/libraries.c, too. >> + /* subclass dllcombo's edit to allow return keypress handling */ >> + GetComboBoxInfo(GetDlgItem(dialog, IDC_DLLCOMBO), &cbinfo); >> + edit = cbinfo.hwndItem; /* retrieve edit box handle */ >> + oldWndProc = (LONG_PTR)SetWindowLong(edit, GWL_WNDPROC, >> + (DWORD) comboedit_wndproc); >> + SetWindowLong(edit, GWL_USERDATA, (DWORD)oldWndProc); > > The code is above is not 64-bit safe. I'm not used to 64-bit programming but willing to learn. Is using SetWindowLongPtr enough to make it 64-bit safe?: oldWndProc = SetWindowLongPtr(edit, GWL_WNDPROC, (LONG_PTR) comboedit_wndproc); SetWindowLongPtr(edit, GWL_USERDATA, (LONG_PTR) oldWndProc); -- Andre Wisplinghoff

Dec. 27, 2008

Re: Are OpenBSD bugs worth filing?

by Kai Blin

On Friday 26 December 2008 21:16:58 David Gerard wrote: > Some of us on wine-users are trying to get Wine to install on OpenBSD. > First, of course, we need to get it to compile on OpenBSD ... > > Are bugs on this platform considered valid reportable bugs? I couldn't > find any OpenBSD bugs on a quick search in Bugzilla. They are considered valid bugs, but be prepared to go through a lot of iterations if developers aren't able to test on their own machines. (At least I don't have a spare just for toying with OpenBSD) Basically, the best way to get a new, uncommon POSIX OS supported in Wine is to get somebody familiar with (programming on) the OS to work on Wine, or at least closely with the Wine developers. That's how FreeBSD was fixed to better support Wine's needs some time ago. This required a couple of patches to the FreeBSD kernel, IIRC, so if the OpenBSD kernel lacks a feature Wine needs, you might have to spend time talking to the OpenBSD team to get features added. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 27, 2008

Re: winecfg: Add dll override on return key press in combobox [resend]

by Dmitry Timoshkov

"Andre Wisplinghoff" <andre.wisplinghoff(a)gmail.com> wrote: > +INT_PTR CALLBACK > +comboedit_wndproc (HWND hEdit, UINT uMsg, WPARAM wParam, LPARAM lParam) INT_PTR is wrong return value type for a window proc. > + /* subclass dllcombo's edit to allow return keypress handling */ > + GetComboBoxInfo(GetDlgItem(dialog, IDC_DLLCOMBO), &cbinfo); > + edit = cbinfo.hwndItem; /* retrieve edit box handle */ > + oldWndProc = (LONG_PTR)SetWindowLong(edit, GWL_WNDPROC, > + (DWORD) comboedit_wndproc); > + SetWindowLong(edit, GWL_USERDATA, (DWORD)oldWndProc); The code is above is not 64-bit safe. -- Dmitry.

Dec. 26, 2008

Fwd: Wine on OpenBSD

by David Gerard

2008/12/27 Austin English <austinenglish(a)gmail.com>: > Would you mind starting a wiki page on this? > http://wiki.winehq.org/OpenBSD is empty at the moment. I've done ones > for OpenSolaris/PC-BSD, see: http://wiki.winehq.org/PC-BSD and > http://wiki.winehq.org/OpenSolaris > The wiki page would make it easier to track progress. http://wiki.winehq.org/OpenBSD - this incorporates most of the discussion from the thread on wine-users. Marcel, please add to it and file Wine on OpenBSD bugs as well. I've also done a page for VirtualBox (basically: VirtualBox is quite buggy, so bugs found in Wine running in a VirtualBox are as likely as not to be bugs in VirtualBox), which should probably become a more general page on why VMs aren't good to report bugs from. - d.

Dec. 26, 2008

Re: Are OpenBSD bugs worth filing?

by David Gerard

2008/12/27 James McKenzie <jjmckenzie51(a)earthlink.net>: > David: > File a bug when you think it is Wine related as it pertains to the ability > to build on that platform. > Austin: > OpenBSD does not like virualization of any kind. VMWare does not support > it, from what I remember. Yep. In the present case, I'll hold off filing any bugs (e.g. the ENOTSUP compile error - if you try compiling Wine on OpenBSD you *will* get this) until I've done them on a real physical PC. Though QEMU on my laptop is good enough for my present pottering about. - d.

Dec. 26, 2008

Re: Wine bugs e-mails/spoofing warnings

by Austin English

On Fri, Dec 26, 2008 at 6:28 PM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > On Sat, Dec 27, 2008 at 8:40 AM, Austin English <austinenglish(a)gmail.com> wrote: >> Anyone else on gmail seeing this? It doesn't happen on all e-mails, >> only once every couple days (I've got digest mode enabled): >> >> "Due to a filter you created, this message was not sent to Spam. Edit Filters >> Warning: This message may not be from whom it claims to be. Beware of >> following any links in it or of providing the sender with any personal >> information. Learn more" >> >> -- >> -Austin >> > > I get the warning message for any mail with a link to an executable > from wine-bugs and it ends up in Spam. > > -Jeff > That's the missing common denominator...thanks for pointing that out. Filter gets around it, fwiw, but disables all urls. -- -Austin

Dec. 26, 2008

Re: Are OpenBSD bugs worth filing?

by James McKenzie

Austin English wrote: > On Fri, Dec 26, 2008 at 2:16 PM, David Gerard <dgerard(a)gmail.com> wrote: > >> Some of us on wine-users are trying to get Wine to install on OpenBSD. >> First, of course, we need to get it to compile on OpenBSD ... >> >> Are bugs on this platform considered valid reportable bugs? I couldn't >> find any OpenBSD bugs on a quick search in Bugzilla. >> >> State of things: it doesn't compile cleanly yet, and ./configure seems >> to fail to recognise a lot of libs that are in fact present. >> >> >> (I realise that running Windows on OpenBSD may cause a >> matter-antimatter explosion as the two security models meet ... But it >> has *hack value*!) >> >> >> - d. >> >> >> >> > > File bugs on compiling issues, if you're sure they're bugs in wine and > not bugs in OpenBSD. > > FWIW, I'm working on trying this, but installing it in VirtualBox > gives segfaults galore. I'm going to try putting it on a spare HDD on > bare metal and see if that works better. > > David: File a bug when you think it is Wine related as it pertains to the ability to build on that platform. Austin: OpenBSD does not like virualization of any kind. VMWare does not support it, from what I remember. James McKenzie

Dec. 26, 2008

Re: Wine bugs e-mails/spoofing warnings

by Jeff Zaroyko

On Sat, Dec 27, 2008 at 8:40 AM, Austin English <austinenglish(a)gmail.com> wrote: > Anyone else on gmail seeing this? It doesn't happen on all e-mails, > only once every couple days (I've got digest mode enabled): > > "Due to a filter you created, this message was not sent to Spam. Edit Filters > Warning: This message may not be from whom it claims to be. Beware of > following any links in it or of providing the sender with any personal > information. Learn more" > > -- > -Austin > I get the warning message for any mail with a link to an executable from wine-bugs and it ends up in Spam. -Jeff

Dec. 26, 2008

Re: Are OpenBSD bugs worth filing?

by David Gerard

2008/12/26 Austin English <austinenglish(a)gmail.com>: > On Fri, Dec 26, 2008 at 2:16 PM, David Gerard <dgerard(a)gmail.com> wrote: >> Some of us on wine-users are trying to get Wine to install on OpenBSD. >> First, of course, we need to get it to compile on OpenBSD ... >> Are bugs on this platform considered valid reportable bugs? I couldn't >> find any OpenBSD bugs on a quick search in Bugzilla. >> State of things: it doesn't compile cleanly yet, and ./configure seems >> to fail to recognise a lot of libs that are in fact present. > File bugs on compiling issues, if you're sure they're bugs in wine and > not bugs in OpenBSD. When OpenBSD refuses to put up with a dodgy virtual machine, they regard that as a feature rather than a bug ;-) OpenBSD basically doesn't work properly in a lot of VMs because it is serious about not letting programs misbehave in ways that could cause insecurities. So stuff you can get away with on Windows and even Linux breaks it. > FWIW, I'm working on trying this, but installing it in VirtualBox > gives segfaults galore. I'm going to try putting it on a spare HDD on > bare metal and see if that works better. In the case of VirtualBox, OpenBSD not working has been acknowledged by the VirtualBox developers as "known bug, our emulation's imperfect, no paying customers affected, go away." So don't expect it to work in the foreseeable future unless you have a large Sun contract and they ask why you went with VMware. I'm currently playing with it in QEMU - don't try this with kqemu, that's known to break OpenBSD too! - and reliably geting the ENOTSUP compile-time error (which I'm about to file a bug on). I'll be getting a spare dual AMD64 next week to try it on OpenBSD under 32-bit and 64-bit. I looked in Bugzilla again and saw a few filed bugs ... I'll see if I can reproduce the "abandoned" ones on current Wine tarballs. More to come! %-D - d.

Dec. 26, 2008

Re: Are OpenBSD bugs worth filing?

by Austin English

On Fri, Dec 26, 2008 at 2:16 PM, David Gerard <dgerard(a)gmail.com> wrote: > Some of us on wine-users are trying to get Wine to install on OpenBSD. > First, of course, we need to get it to compile on OpenBSD ... > > Are bugs on this platform considered valid reportable bugs? I couldn't > find any OpenBSD bugs on a quick search in Bugzilla. > > State of things: it doesn't compile cleanly yet, and ./configure seems > to fail to recognise a lot of libs that are in fact present. > > > (I realise that running Windows on OpenBSD may cause a > matter-antimatter explosion as the two security models meet ... But it > has *hack value*!) > > > - d. > > > File bugs on compiling issues, if you're sure they're bugs in wine and not bugs in OpenBSD. FWIW, I'm working on trying this, but installing it in VirtualBox gives segfaults galore. I'm going to try putting it on a spare HDD on bare metal and see if that works better. -- -Austin

Dec. 26, 2008

Re: Bugzilla - CVS/GIT tag

by Austin English

On Fri, Dec 26, 2008 at 5:07 PM, Francois Gouget <fgouget(a)free.fr> wrote: > On Thu, 25 Dec 2008, Austin English wrote: > [...] >> I was attempting to avoid more bugzilla e-mails to set the version, >> and considering that most people won't know the version that they were >> using that long ago, it's at most a futile effort. > > The email should ask them to retest with the current Wine and fill in > the field with that version, rather than try to remember what they were > using at the time.That would be useful and likely eliminate a lot of > bugs (either because it'sfixed or due to lack of response). > > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > I've started with closed bugs at the moment, but I'll do that for the open ones. -- -Austin

Dec. 26, 2008

Re: Wine bugs e-mails/spoofing warnings

by Lei Zhang

On Fri, Dec 26, 2008 at 1:40 PM, Austin English <austinenglish(a)gmail.com> wrote: > Anyone else on gmail seeing this? It doesn't happen on all e-mails, > only once every couple days (I've got digest mode enabled): > > "Due to a filter you created, this message was not sent to Spam. Edit Filters > Warning: This message may not be from whom it claims to be. Beware of > following any links in it or of providing the sender with any personal > information. Learn more" > Gmail can be over-zealous when it sees emails that have http urls pointing to .exe files.

Dec. 26, 2008

Re: Bugzilla - CVS/GIT tag

by Francois Gouget

On Thu, 25 Dec 2008, Austin English wrote: [...] > I was attempting to avoid more bugzilla e-mails to set the version, > and considering that most people won't know the version that they were > using that long ago, it's at most a futile effort. The email should ask them to retest with the current Wine and fill in the field with that version, rather than try to remember what they were using at the time.That would be useful and likely eliminate a lot of bugs (either because it'sfixed or due to lack of response). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Dec. 26, 2008

Re: Wine bugs e-mails/spoofing warnings

by Vincent Pelletier

Le Friday 26 December 2008 22:40:28 Austin English, vous avez écrit : > Anyone else on gmail seeing this? It doesn't happen on all e-mails, > only once every couple days (I've got digest mode enabled): I don't have this message, probably because I didn't set any filter. But I don't receive any message I send to the list, although the option is enabled in my subscription, and although I (obviously) do receive messages of others. -- Vincent Pelletier

Dec. 26, 2008

Wine bugs e-mails/spoofing warnings

by Austin English

Anyone else on gmail seeing this? It doesn't happen on all e-mails, only once every couple days (I've got digest mode enabled): "Due to a filter you created, this message was not sent to Spam. Edit Filters Warning: This message may not be from whom it claims to be. Beware of following any links in it or of providing the sender with any personal information. Learn more" -- -Austin

Dec. 26, 2008

Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size

by Vincent Pelletier

Woops, re-sending to list this time... On Wed, Dec 24, 2008 at 4:01 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I think henri sent a reply. He recommended to clamp the new pointsize > instead of leaving the old one set. Found it. Wasn't subscribed here at that time (only to -patches). New version of previous patch is attached. > Of course a test would be interesting too, to see how windows behaves here. I'm not sure where to add it. I've added some line in d3d9/tests/visual.c:pointsize_test (attached too). As I wrote that test to succeed on wine and did not run it on any windows version, I would be happy if someone could try it. Note that this patch also contains a change from fix explained below (I'm not used to git enough yet to split patches...). Also, runing that test I had an unrelated failure in autogen_mipmap_test because texture creation failed in IWineD3DDeviceImpl_CreateTexture due to SFLAG_OVERSIZE being set at D3DCB_CreateSurface return. As I guess IWineD3DDeviceImpl_CreateTexture should then return a failure code, I patched it and made the test give up if texture allocation failed. (patch attached) I'm not sure if I chose the right error code. From MSDN, it can return: D3DERR_INVALIDCALL, D3DERR_OUTOFVIDEOMEMORY, E_OUTOFMEMORY If this change is OK, I will submit it separately from pointsize clamping. -- Vincent Pelletier

Dec. 26, 2008

Are OpenBSD bugs worth filing?

by David Gerard

Some of us on wine-users are trying to get Wine to install on OpenBSD. First, of course, we need to get it to compile on OpenBSD ... Are bugs on this platform considered valid reportable bugs? I couldn't find any OpenBSD bugs on a quick search in Bugzilla. State of things: it doesn't compile cleanly yet, and ./configure seems to fail to recognise a lot of libs that are in fact present. (I realise that running Windows on OpenBSD may cause a matter-antimatter explosion as the two security models meet ... But it has *hack value*!) - d.

Dec. 26, 2008

Re: feedback? wined3d: Implement r5g6b5 to x8r8g8b8 function

by paulo lesgaz

In the same idea, what's wrong with the patch: wined3d: Convert between A8R8G8B8 and X8R8G8B8http://www.winehq.org/pipermail/wine-patches/attachments/20080928/a… It fixes une FIXME in medieval total wars (Henri asked what is fixed by this patch ;) ) David --- En date de : Ven 26.12.08, Henri Verbeet <hverbeet(a)gmail.com> a écrit : De: Henri Verbeet <hverbeet(a)gmail.com> Objet: Re: feedback? wined3d: Implement r5g6b5 to x8r8g8b8 function À: "Stefan Dösinger" <stefandoesinger(a)gmx.at> Cc: jeremielapuree(a)yahoo.fr, "wine" <wine-devel(a)winehq.org> Date: Vendredi 26 Décembre 2008, 15h27 2008/12/27 Stefan Dösinger <stefandoesinger(a)gmx.at>: >>anything wrong with the patch >>wined3d: Implement r5g6b5 to x8r8g8b8 function >>David > Probably alexandre wanted an ok from me. Can you resend the patch? > No, the patch was flawed. The author knows about this, and posted an improved patch to bugzilla (bug 18011). The improved patch is mostly ok, but doesn't round correctly, and could be made a bit faster by using a lookup table instead of recalculating everything all the time.

Dec. 26, 2008

website: interviews / XML error: Mismatched tag

by Andre Wisplinghoff

Hi, for example at http://www.winehq.org/interview/14 you get 'XML error: Mismatched tag at line 9'. I'm sending a proposed patch here because last time I sent a website patch to wine-patches it wasn't applied and there was no reaction. wwn/en/interviews/interview_11.xml | 2 +- wwn/en/interviews/interview_12.xml | 2 +- wwn/en/interviews/interview_14.xml | 2 +- wwn/en/interviews/interview_15.xml | 2 +- wwn/en/interviews/interview_6.xml | 2 +- wwn/en/interviews/interview_9.xml | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) -- Andre Wisplinghoff

Dec. 26, 2008

Re: Marshalling of remotable handles

by Michael Karcher

Am Freitag, den 26.12.2008, 17:20 +0000 schrieb Rob Shearman: > 2008/12/21 Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de>: > > This makes widl generate null pointer checks for HWND parameters, as > > HXXX is a void pointer without the unique attribute. My question is: > > Should widl really add this check? As the type is marshalled as > > wireHXXX, the null value is no problem for marshalling, so it could be > > safely left out. > Yes, that's a widl bug - it shouldn't output NULL ref pointer checks > for user-marshaled types. OK, thanks for your info. I will try to send a patch. Best regards, Michael Karcher

Dec. 26, 2008

Re: Marshalling of remotable handles

by Rob Shearman

2008/12/21 Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de>: > Hello Wine developers, > > while trying to add proxy/stub code for shell32, I stumbled across the > definition of remotable handles in IDL. > > We have > > - a RemotableHandle union. > - the IDL typedefs for the wire representation of handles: > | typedef [unique] RemotableHandle *wireHXXX; > - the IDL declaration for the handle types itself: > | typedef [wire_marshal(wireHXXX)] void*HXXX; > > This makes widl generate null pointer checks for HWND parameters, as > HXXX is a void pointer without the unique attribute. My question is: > Should widl really add this check? As the type is marshalled as > wireHXXX, the null value is no problem for marshalling, so it could be > safely left out. Yes, that's a widl bug - it shouldn't output NULL ref pointer checks for user-marshaled types. > What I did in my repository was adding the [unique] attribute to the IDL > typedef of the handle type: > | typedef [unique, wire_marshal(wireHXXX)] void*HXXX; > Is this the right approach to generally get rid of the NULL pointer > checks for handles, or is widl to be fixed instead? widl should be fixed, since MIDL correctly doesn't output NULL ref pointer checks when using the same source IDL files. -- Rob Shearman

Dec. 26, 2008

Re: feedback? wined3d: Implement r5g6b5 to x8r8g8b8 function

by Henri Verbeet

2008/12/27 Stefan Dösinger <stefandoesinger(a)gmx.at>: >>anything wrong with the patch >>wined3d: Implement r5g6b5 to x8r8g8b8 function >>David > Probably alexandre wanted an ok from me. Can you resend the patch? > No, the patch was flawed. The author knows about this, and posted an improved patch to bugzilla (bug 18011). The improved patch is mostly ok, but doesn't round correctly, and could be made a bit faster by using a lookup table instead of recalculating everything all the time.

Dec. 26, 2008

AW: feedback? wined3d: Implement r5g6b5 to x8r8g8b8 function

by Stefan D�singer

>anything wrong with the patch >wined3d: Implement r5g6b5 to x8r8g8b8 function >David Probably alexandre wanted an ok from me. Can you resend the patch?

Dec. 26, 2008

AW: [PATCH] Fix ddraw surface version setting (redux) (now withattachment)

by Stefan D�singer

Looks ok

Dec. 26, 2008

feedback? wined3d: Implement r5g6b5 to x8r8g8b8 function

by paulo lesgaz

Hello, anything wrong with the patch wined3d: Implement r5g6b5 to x8r8g8b8 function David

Dec. 26, 2008

Re: Combining Fuse and Wine - What's the best way?

by Richard Stitz

Tried adding in those other options and the only difference it makes is that I get an additional error message when I try to execute the program as a normal user. Instead of getting: fusermount: failed to open /etc/fuse.conf: Permission denied fusermount: waitpid: No child processes ...I now get: fixme:ntoskrnl:KeInitializeSpinLock 0x4577a4 fusermount: failed to open /etc/fuse.conf: Permission denied fusermount: waitpid: No child processes Running the program as root behaves identically to before. On Thu, Dec 25, 2008 at 10:05 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Have you actually looked at the winegcc command in that forum thread? I > guess not. > You didn't compile your binary properly.

Dec. 25, 2008

Re: Bugzilla - CVS/GIT tag

by Austin English

On Thu, Dec 25, 2008 at 10:39 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Austin English" <austinenglish(a)gmail.com> wrote: > >> On Wed, Dec 24, 2008 at 8:50 PM, Vitaliy Margolen >> <wine-devel(a)kievinfo.com> wrote: >>> >>> Austin English wrote: >>>> >>>> In an effort to remove the CVS/GIT tag, I was going to go through and >>>> start changing the versions based on when the bug was filed. I.e., >>>> look at when 1.1.10 was out, and any bugs filed in those dates with >>>> CVS/GIT tag get moved to 1.1.10. I'm thinking of starting with 0.9, as >>>> anything before that is _really_ old and not worth the effort... >>> >>> Agreed. Non need to generate huge volume of spam changing all the old >>> versions. Especially for closed bugs. >> >> Well, they all have to be moved so we can delete that version. I meant >> that anything that was before 0.9 will be labeled as 0.9. > > I'd suggest to replace CVS/GIT tag in existing bugs buy "unknown" and > ask the reporter to fix it (as I initially suggested when I proposed > to get rid CVS/GIT tag). > > -- > Dmitry. > I was attempting to avoid more bugzilla e-mails to set the version, and considering that most people won't know the version that they were using that long ago, it's at most a futile effort. Either way's fine with me, I'd just like to eliminate the version tag so we can quit getting 'CVS/GIT is deprecated e-mails'. -- -Austin

Dec. 25, 2008

Re: Bugzilla's down

by Tomasz Sałaciński

It seems WINE is gaining popularity, more and more users are connecting to the bugzilla's database:) Max_user_connection reached! Happy holidays to everyone! Dnia 2008-12-25, czw o godzinie 14:13 -0600, Austin English pisze: > Newman/whomever else, if you're not busy with family etc., mind taking a look? > > Happy holidays everyone! >

Dec. 25, 2008

Bugzilla's down

by Austin English

Newman/whomever else, if you're not busy with family etc., mind taking a look? Happy holidays everyone! -- -Austin

Dec. 25, 2008

Re: Combining Fuse and Wine - What's the best way?

by Vitaliy Margolen

Bottom post here! Richard Stitz wrote: > > On Wed, Dec 24, 2008 at 6:54 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >> Just using "winegcc" is not enough. You have to run it with Wine: >> http://forum.winehq.org/viewtopic.php?t=3177 > I thought that the "main" executable being produced by winegcc was > just a script that called wine with "main.exe.so"? This seems to be No. It does much more then that. > the case, as attempting to run "wine main" fails (Module not found), > and running "wine main.exe.so" produces exactly the same results as > running "./main" did. Have you actually looked at the winegcc command in that forum thread? I guess not. You didn't compile your binary properly. Vitaliy

Dec. 25, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Nikolay Sivov

Vitaly Lipatov wrote: > В сообщении от 25 декабря 2008 Вы написали: > ... > >> You could start with testing for some special cases (such as NULL input >> parameters). >> > If I will add test case for NULL input and returned values, my commit will be > accepted? > I don't know actually. That's first I think about when my patch isn't accepted. >> For me your comment looks suspicious: >> ----- >> >> + * TODO >> + * Check if OLE object has no verbs >> > > > >> ----- >> >> + hr = IOleObject_EnumVerbs(lpOleObj, &pEnumVerbs); >> + if (hr == S_OK) { >> ---- >> Will this hr be OLEOBJ_E_NOVERBS when no verbs present? >> If it's so you're actually checking for this. >> This one needs a testcase for example. >> > Please understand me. I did a part of work. Possible my implementation is > incomplete. But I wish to share result of my work with the world, winehq > community. I agree with test case argument with I fix already existing > function. But I do a new realization and have no enough time and knowledge > to write ideal code. Also I can improve code only from winehq repository. > ... > All of this is perfectly clear, and I don't argue with you and I'm not calling your patch bad. I'm only point on some obvious things for me. Treat this only like an advice and my opinion. >> Does native crash on it or not? I'm not sure. >> >> The same about SetLastError on failure - this should be checked by testing >> it directly. >> > I will try to add this tests. >

Dec. 25, 2008

Re: Bugzilla - CVS/GIT tag

by Dmitry Timoshkov

"Austin English" <austinenglish(a)gmail.com> wrote: > On Wed, Dec 24, 2008 at 8:50 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >> Austin English wrote: >>> In an effort to remove the CVS/GIT tag, I was going to go through and >>> start changing the versions based on when the bug was filed. I.e., >>> look at when 1.1.10 was out, and any bugs filed in those dates with >>> CVS/GIT tag get moved to 1.1.10. I'm thinking of starting with 0.9, as >>> anything before that is _really_ old and not worth the effort... >> Agreed. Non need to generate huge volume of spam changing all the old >> versions. Especially for closed bugs. > > Well, they all have to be moved so we can delete that version. I meant > that anything that was before 0.9 will be labeled as 0.9. I'd suggest to replace CVS/GIT tag in existing bugs buy "unknown" and ask the reporter to fix it (as I initially suggested when I proposed to get rid CVS/GIT tag). -- Dmitry.

Dec. 25, 2008

Re: [PATCH] Fix ddraw surface version setting (redux)

by Austin English

On Wed, Dec 24, 2008 at 8:48 PM, Nick Burns <adger44(a)hotmail.com> wrote: > > Resubmitting patch with correct email address and against tot wine > > > This fixes the d3d6 rendering problem reported by Ben Slackin against Wine 1.1.3 > http://appdb.winehq.org/objectManager.php?sClass=version&iId=8524 > http://img216.imageshack.us/img216/2764/shogoiz3.png > > > SHOGO got MAD when it was not able to find the mipmaps (due to incorrect version) > > > With this fix the game looks correct (well if you apply my other menu blt patch) > > > Changelog > Fix surface version setting > Mipmaps need to be properly versioned after creation > > > - Nick > > > You forgot the patch. -- -Austin

Dec. 25, 2008

Re: [PATCH] Fix ddraw surface version setting (redux)

by Vincent Povirk

No attachment? Vincent Povirk

Dec. 25, 2008

Re: Bugzilla - CVS/GIT tag

by Austin English

On Wed, Dec 24, 2008 at 8:50 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Austin English wrote: >> In an effort to remove the CVS/GIT tag, I was going to go through and >> start changing the versions based on when the bug was filed. I.e., >> look at when 1.1.10 was out, and any bugs filed in those dates with >> CVS/GIT tag get moved to 1.1.10. I'm thinking of starting with 0.9, as >> anything before that is _really_ old and not worth the effort... > Agreed. Non need to generate huge volume of spam changing all the old > versions. Especially for closed bugs. Well, they all have to be moved so we can delete that version. I meant that anything that was before 0.9 will be labeled as 0.9. -- -Austin

Dec. 25, 2008

Re: gdi32: Correct order of matrix elements in World transform

by Dmitry Timoshkov

"Konstantin Kondratyuk" <kondratyuk(a)etersoft.ru> wrote: > Oops, this patch is not full. > > I think, there is code with bad index also: > > /* Extra transformation specified by caller */ > if (lpmat && !is_identity_MAT2(lpmat)) > { > FT_Matrix extraMat; > extraMat.xx = FT_FixedFromFIXED(lpmat->eM11); > extraMat.xy = FT_FixedFromFIXED(lpmat->eM21); // <<<<<<< > extraMat.yx = FT_FixedFromFIXED(lpmat->eM12); // <<<<<<< > extraMat.yy = FT_FixedFromFIXED(lpmat->eM22); > pFT_Matrix_Multiply(&extraMat, &transMat); > pFT_Matrix_Multiply(&extraMat, &transMatUnrotated); > needsTransform = TRUE; > } > > What can I do? Send second fix? Or send "full" patch for both transformations? Have you tested your patch? In my tests gdi and freetype differ in matrix usage. -- Dmitry.

Dec. 25, 2008

Feedback needed

by Andre Wisplinghoff

Hi all, i need some feedback for my submitted patch (winecfg: Add a dll override instead of closing the dialog on pressing return in the combobox at 'libraries' tab): http://www.winehq.org/pipermail/wine-patches/2008-December/066619.html Thank you and Happy Holidays!! -- Andre Wisplinghoff

Dec. 25, 2008

Re: oledlg: Implement OleUIAddVerbMenuA/W functions [resend]

by Vitaly Lipatov

В сообщении от 25 декабря 2008 Вы написали: ... > You could start with testing for some special cases (such as NULL input > parameters). If I will add test case for NULL input and returned values, my commit will be accepted? > For me your comment looks suspicious: > ----- > > + * TODO > + * Check if OLE object has no verbs > > ----- > > + hr = IOleObject_EnumVerbs(lpOleObj, &pEnumVerbs); > + if (hr == S_OK) { > ---- > Will this hr be OLEOBJ_E_NOVERBS when no verbs present? > If it's so you're actually checking for this. > This one needs a testcase for example. Please understand me. I did a part of work. Possible my implementation is incomplete. But I wish to share result of my work with the world, winehq community. I agree with test case argument with I fix already existing function. But I do a new realization and have no enough time and knowledge to write ideal code. Also I can improve code only from winehq repository. ... > Does native crash on it or not? I'm not sure. > > The same about SetLastError on failure - this should be checked by testing > it directly. I will try to add this tests. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 25, 2008

Re: gdi32: Correct order of matrix elements in World transform

by Konstantin Kondratyuk

Oops, this patch is not full. I think, there is code with bad index also: /* Extra transformation specified by caller */ if (lpmat && !is_identity_MAT2(lpmat)) { FT_Matrix extraMat; extraMat.xx = FT_FixedFromFIXED(lpmat->eM11); extraMat.xy = FT_FixedFromFIXED(lpmat->eM21); // <<<<<<< extraMat.yx = FT_FixedFromFIXED(lpmat->eM12); // <<<<<<< extraMat.yy = FT_FixedFromFIXED(lpmat->eM22); pFT_Matrix_Multiply(&extraMat, &transMat); pFT_Matrix_Multiply(&extraMat, &transMatUnrotated); needsTransform = TRUE; } What can I do? Send second fix? Or send "full" patch for both transformations? -- Best regards, Konstantin Kondratyuk.

Dec. 25, 2008

Re: wine-1.2 release criteria? (USB device support)

by Vitaly Lipatov

В сообщении от 25 декабря 2008 Pavel Troller написал(a): ... > > We (Etersoft) are realized USB support in wine via libusb and do many ... > Is your work accessible as a patch to the current wine tree, or as a git > branch somewhere ? Please check http://git.etersoft.ru/people/lav/packages/wine.git branch eterhack > I would like to test it with some of my apps (Nokia software, programmers > etc...) and give you a feedback, whether it works. > Do you know, why Alexandre is not accepting your improvements ? Some summarize is available on http://wiki.winehq.org/USB -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 25, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (re-redux)

by Stefan Dösinger

Your wined3d_gl.h patch was applied, the others weren't Sometimes too much discussion makes AJ wait on a patch too, to see how the discussion turns out. If you resend your patches I'll just reply with an "patch is ok" mail to avoid further confusion > -----Original Message----- > From: Nick Burns [mailto:adger44(a)hotmail.com] > Sent: Thursday, December 25, 2008 1:06 AM > To: stefan(a)codeweavers.com; wine-devel(a)winehq.org > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer > (re-redux) > > > Thanks for the explanation -- I will email asking why soon -- and > perhaps resubmit the other patch > I have been looking at http://winehq.org/pipermail/wine-cvs to see what > has been applied > > But source.winehq.org/git shows the diffs much nicer > > > > - Nick > > ---------------------------------------- > > From: stefan(a)codeweavers.com > > To: adger44(a)hotmail.com; wine-devel(a)winehq.org > > Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer > (re-redux) > > Date: Wed, 24 Dec 2008 15:48:24 +0100 > > > >> Thanks for reviewing my patch (it sure makes the SHOGO menu much > nicer) > >> BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] > Fix > >> ddraw surface version setting)? > > Yes, I recommend to do that. It is likely that it was lost or didn't > apply > > any longer after the 3 days it waited in moderation. > > > > You can see on source.winehq.org/git or with 'git log origin' if your > patch > > was applied. If it wasn't, it is best to send a mail to wine-devel > asking > > why, or ask Alexandre(nick 'julliard') on #winehackers. Quite often > > Alexandre sends a reply if he doesn't like the patch(or someone else > does), > > but not always. > > > > Alexandre usually wants a confirmation from someone who knows the > area(in > > the case of d3d Heri, Roderick or me) if a new contributor sends a > patch, > > hence my "the patch is ok" mails. > > > > I don't know if Alexandre will apply patches over the holidays, so if > the > > patch is silently ignored it is best to resend it in a few days.

Dec. 25, 2008

RE: Combining Fuse and Wine - What's the best way?

by Stefan Dösinger

> $ winegcc -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=22 -lfuse -o main > main.c > $ mkdir test > $ ./main test > fusermount: failed to open /etc/fuse.conf: Permission denied > fusermount: waitpid: No child processes > $ sudo umount test Sorry, I've no idea. Probably fuse uses some sort of framework that expects you to use it in a specific way like Wine does too, and collides with Wine. I recommend you to ask this question on the Fuse mailing list too, probably they can help out. There's at least one potential problem if Fuse creates a process or thread behind the application's back. In that case there is no Win32 process in Wine for that process(because Wine has no idea about it). No problem if it just runs Fuse's or your code, but if the Windows DLL code is called and it calls GetCurrentProcess() or something similar you have a problem.

Dec. 25, 2008

Re: wine-1.2 release criteria?

by Pavel Troller

> ? ????????? ?? 15 ??????? 2008 Pavel Troller ???????(a): > ... > > All these things have a common denominator: proprietary USB drivers. It's > > fine that wine can use USB scanners/cameras/printers etc, which can be > > interfaced though native Linux drivers/libraries, but these are almost > > always usable directly from Linux, while those proprietary devices aren't. > > Is there any chance that wine will progress in this area ? I'm ready to > > supply a bounty for a volunteer making some progress here. > We (Etersoft) are realized USB support in wine via libusb and do many fixes in > ntoskrnl.exe to load and run proprietary drivers for protection keys (like > HASP). > AS I know, this improvements is not acceptable by Alexandre. > If anyone is interested to consult us to do our code more acceptable, you are > welcome. > Hi! It sounds really very interesting! Is your work accessible as a patch to the current wine tree, or as a git branch somewhere ? I would like to test it with some of my apps (Nokia software, programmers etc...) and give you a feedback, whether it works. Do you know, why Alexandre is not accepting your improvements ? With regards, Pavel Troller

Dec. 25, 2008

Re: Combining Fuse and Wine - What's the best way?

by Richard Stitz

I thought that the "main" executable being produced by winegcc was just a script that called wine with "main.exe.so"? This seems to be the case, as attempting to run "wine main" fails (Module not found), and running "wine main.exe.so" produces exactly the same results as running "./main" did. On Wed, Dec 24, 2008 at 6:54 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Just using "winegcc" is not enough. You have to run it with Wine: > http://forum.winehq.org/viewtopic.php?t=3177

Dec. 24, 2008