Re: Are OpenBSD bugs worth filing?
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 developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: winecfg: Add dll override on return key press in combobox [resend]
2008/12/27 Dmitry Timoshkov dmi...@codeweavers.com: Andre Wisplinghoff andre.wisplingh...@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
Re: winecfg: Add dll override on return key press in combobox [resend]
2008/12/27 Andre Wisplinghoff andre.wisplingh...@gmail.com: 2008/12/27 Dmitry Timoshkov dmi...@codeweavers.com: Andre Wisplinghoff andre.wisplingh...@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
Re: winecfg: Add dll override on return key press in combobox [resend]
Andre Wisplinghoff andre.wisplingh...@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.
Re: [2/2] mshtml: Add VT_INT support in IHTMLElementCollection_item
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; ilen; 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);
Re: [PATCH 5/6] dinput: Fix usage of HeapReAlloc.
Vitaliy Margolen wine-patc...@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
julli...@winehq.org
RE: Simplify dlls/comctl32/nativefont.c
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: ger...@pfeifer.com
To: wine-patc...@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 - 1.29
+++ dlls/comctl32/nativefont.c 27 Dec 2008 07:57:10 -
@@ -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
Re: Wine build failed
Am Tuesday 23 December 2008 20:48 schrieb Austin English: On Tue, Dec 23, 2008 at 3:43 AM, Stefan Leichter sle85...@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
Re: Simplify dlls/comctl32/nativefont.c
ricardo filipe wrote:
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: ger...@pfeifer.com
To: wine-patc...@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 - 1.29
+++ dlls/comctl32/nativefont.c 27 Dec 2008 07:57:10 -
@@ -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
It isn't exported.
Minimal patches to try win64?
Out of curiosity, I finally bit the bullet, installed 64 bit Ubuntu 8.10, updated http://wiki.winehq.org/Wine64 to show how to build gcc, and built wine with win64 support enabled. It built successfully on the first try, but starting any conformance test or win64 app fails with wineserver: request.c:744: open_master_socket: Assertion `sizeof(union generic_request) == sizeof(struct request_max_size)' failed. I tried grabbing the patch that seems to fix that, http://repo.or.cz/w/wine/wine64.git?a=commitdiff_plain;h=6e77a4879d5e62a97775e5c1c225915e659d5dbf but then I got other errors. What's the minimal set of patches needed to start trying win64? I'd rather not pull Maarten's whole repo, I have no idea how closely that tracks winehq... - Dan
Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size
Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit :
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)
Updated to test previous return code, instead of accessing a list behin
potentially NULL pointer.
--
Vincent Pelletier
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 36fbcba..e87af6f 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -871,6 +871,8 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateTexture(IWineD3DDevice *iface, U
hr = D3DCB_CreateSurface(This-parent, parent, tmpW, tmpH, Format, Usage, Pool, i, WINED3DCUBEMAP_FACE_POSITIVE_X, object-surfaces[i],NULL);
if (hr!= WINED3D_OK || ( (IWineD3DSurfaceImpl *) object-surfaces[i])-Flags SFLAG_OVERSIZE) {
FIXME(Failed to create surface %p\n, object);
+if (hr == WINED3D_OK)
+hr = WINED3DERR_OUTOFVIDEOMEMORY;
/* clean up */
object-surfaces[i] = NULL;
IWineD3DTexture_Release((IWineD3DTexture *)object);
260 tests passing on win64!
I updated http://wiki.winehq.org/Wine64 with easy instructions (thanks, Maarten!) for how to build wine's 64 bit support and try 64 bit pacman (which works!). And then I ran make -k test. Surprisingly, I got 260 passing tests according to find . -name '*.ok' | wc and only 128 failed tests according to grep ok.*Error test.log | wc -l Ladies and gentlemen, I believe it's time for a 64 bit winetest.exe to be added to the daily build, and for 64 bit test data to start showing up at http://test.winehq.org. That would let us tamp down errors in the test suite on 64 bits. (Yeah, I know, gcc with win64 ABI isn't released yet, and there are problems with exception handling still, but it still seems worth it...) - Dan
RE: Simplify dlls/comctl32/nativefont.c
On Sat, 27 Dec 2008, ricardo filipe wrote: are you sure windows doesn't call those functions with those parameters? you have to check that before sending patches like these ... Yes, I am. Looking at the patch... static LRESULT -NATIVEFONT_Create (HWND hwnd, WPARAM wParam, LPARAM lParam) +NATIVEFONT_Create (HWND hwnd) ...you'll notice that this function is static and thus cannot be invoked by any external caller. I have explicitly excluded functions with external linkage or callback functions from such simplifications. Gerald -- Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/
Status of dxdiagn?
Hi Markus, what's the status of dxdiagn these days? I see a number of games that say they need a native copy: http://www.google.com/search?q=dxdiagn+site%3Aappdb.winehq.org Do you know what needs doing before we can get native dxdiag working, http://bugs.winehq.org/show_bug.cgi?id=1429 ? Also, how about your dxdiagn conformance test? http://www.winehq.org/pipermail/wine-patches/2008-May/055355.html I know it didn't do much, maybe you could have it check a few required properties? I ask because I'm looking around for a student project, and implementing dxdiag.exe came to mind; looking around a bit, I saw dxdiagn, and figured it might be nice to tie up some loose ends there, too. - Dan
Re: Combining Fuse and Wine - What's the best way?
So would the best way to do this be to have a separate process for the Wine program that loads the DLL, and then have the Fuse process communicate over pipes or some other IPC method?
Implementing dxdiag as student project?
Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program? This seems like it might be a fun student project. - Dan
