[PATCH2+TEST] RE: user32: Problem using SetClassLongW to subclass built-in control (Edit)
Hello,
Now I have fixed the problem, or corrected to window behaviour. Included is
the Patch, Test and Debug (play with windows). Can anyone please test or
comment ?
Regards
Hongbo Ni
==
# Patch
==
--- wine-1.1.1-orig/dlls/user32/win.c 2008-07-12 01:55:55.0 +1000
+++ wine-1.1.1/dlls/user32/win.c2008-07-14 16:49:21.0 +1000
@@ -173,6 +173,13 @@ static WND *create_window_handle( HWND p
win-owner = full_owner;
win-class = class;
win-winproc= get_class_winproc( class );
+/* This is a window hack - When builtin Edit class has been subclassed by
SetClassLong(Ptr)W */
+/* If creating ansi Edit window the class does not have a ansi proc, use
unicode proc as ansi */
+if(!unicode !IS_INTRESOURCE(name) !strcmpiW( name,
EDIT_builtin_class.name )
+WINPROC_IsUnicode( win-winproc, 0 ) WINPROC_IsUnicode(
win-winproc, 1 ))
+{
+win-winproc = WINPROC_AllocProc((WNDPROC)WINPROC_GetProc(
win-winproc, 1 ), NULL);
+}
win-dwMagic= WND_MAGIC;
win-cbWndExtra = extra_bytes;
if (WINPROC_IsUnicode( win-winproc, unicode )) win-flags |=
WIN_ISUNICODE;
==
# Debug - following debug shows the window hack
#show var: is value show by the MSVC debuger
==
WNDPROC EditWndProcA=NULL, EditClassProcA=NULL;
WNDPROC EditWndProcW=NULL, EditClassProcW=NULL;
HWND hEditWnd1,hEditWnd2;
static const CHAR classNameA[] = Edit;
static const WCHAR classNameW[] = {'E','d','i','t',0};
int i=0;
HWND hEditWnd0 = CreateWindowExA(0,classNameA, NULL,WS_POPUP,0, 0, 1,
1,NULL,NULL,hInst,NULL);
EditClassProcA =(WNDPROC)GetClassLongPtrA(hEditWnd0, GCLP_WNDPROC);
EditClassProcW =(WNDPROC)GetClassLongPtrW(hEditWnd0, GCLP_WNDPROC);
show var: EditClassProcA=0x77246feb EditClassProcW=0x7726f52f
EditWndProcA =(WNDPROC)GetWindowLongPtrA(hEditWnd0, GWLP_WNDPROC);
EditWndProcW =(WNDPROC)GetWindowLongPtrW(hEditWnd0, GWLP_WNDPROC);
show var: EditWndProcA =0x77246feb EditWndProcW=0x0597(handle)
if(IsWindowUnicode(hEditWnd0)) i++;
show var: i = 0 -- not a unciode windows
OldEditWndProcW =(WNDPROC)SetClassLongPtrW(hEditWnd0, GCLP_WNDPROC ,
(DWORD)EditWndProc );
show var: OldEditWndProcW=0x7726f52f
EditClassProcA =(WNDPROC)GetClassLongPtrA(hEditWnd1, GCLP_WNDPROC);
EditClassProcW =(WNDPROC)GetClassLongPtrW(hEditWnd1, GCLP_WNDPROC);
show var: EditClassProcA=0x05bf EditClassProcW=0x00401014
hEditWnd1 = CreateWindowA(classNameA, NULL,WS_POPUP,0, 16, 100,
16,hWnd,NULL,hInst,NULL);
EditWndProcA =(WNDPROC)GetWindowLongPtrA(hEditWnd1, GWLP_WNDPROC);
EditWndProcW =(WNDPROC)GetWindowLongPtrW(hEditWnd1, GWLP_WNDPROC);
show var: EditWndProcA =0x00401014 EditWndProcW=0x0637
if(IsWindowUnicode(hEditWnd1)) i++;
show var: i = 0 -- not a unicode windows
Now you can see EditWndProcA==EditClassProcW and it's not a Unicode Window
I have got a screenshot showing the same debug result on MSVC 6.0
http://www.njstar.com/devimg/SetClassLongW-debug.png
==
# Test - Following tests are added to dlls/user32/tests/class.c
# Latest 4 added tests fails on current wine 1.1.1
==
--- wine-1.1.1-orig/dlls/user32/tests/class.c 2008-07-12 01:55:55.0
+1000
+++ wine-1.1.1/dlls/user32/tests/class.c2008-07-14 16:44:34.0
+1000
@@ -590,6 +590,7 @@ static void test_builtinproc(void)
WCHAR buf[128];
ATOM atom;
HWND hwnd;
+HWND hwnd2;
int i;
pDefWindowProcA = (void *)GetProcAddress(GetModuleHandle(user32.dll),
DefWindowProcA);
@@ -775,6 +776,72 @@ static void test_builtinproc(void)
CallWindowProcA((WNDPROC)GetWindowLongPtrA(hwnd, GWLP_WNDPROC), hwnd,
WM_GETTEXT, 120, (LPARAM)buf);
ok(memcmp(buf, classA, sizeof(classA)) == 0, WM_GETTEXT invalid
return\n);
+/** subclass Edit class using SetClassLongPtrA with ClassTest_WndProc2 **/
+oldproc = (WNDPROC)SetClassLongPtrA( hwnd, GCLP_WNDPROC,
(ULONG_PTR)ClassTest_WndProc2);
+ok(!IS_WNDPROC_HANDLE(GetClassLongPtrA(hwnd, GCLP_WNDPROC)),
+ GetClassLongPtrA expect to return a Ansi wndproc, got %p\n,(void
*)GetClassLongPtrA(hwnd, GCLP_WNDPROC));
+ok(IS_WNDPROC_HANDLE(GetClassLongPtrW(hwnd, GCLP_WNDPROC)),
+ GetClassLongPtrW expect to return a wndproc handle, got %p\n, (void
*)GetClassLongPtrW(hwnd, GCLP_WNDPROC));
+
+/* create a unicode edit window */
+
Re: configure: add ip_icmp.h for getICMPStats on FreeBSD
EA Durbin [EMAIL PROTECTED] writes: diff --git a/configure.ac b/configure.ac index bd764a3..500cae1 100644 --- a/configure.ac +++ b/configure.ac @@ -274,6 +274,7 @@ AC_CHECK_HEADERS(\ mntent.h \ ncurses.h \ netdb.h \ +netinet/ip_icmp.h \ netinet/in.h \ netinet/in_systm.h \ netinet/tcp.h \ ip_icmp.h is already checked for later on, since it depends on some other headers. -- Alexandre Julliard [EMAIL PROTECTED]
Re: iPod patches
On Mon, Jun 9, 2008 at 12:12 PM, Maarten Lankhorst [EMAIL PROTECTED] wrote: Hello Austin, 2008/6/9 Austin English [EMAIL PROTECTED]: Howdy Maarten, I'm trying to do some dogfood testing with iTunes, and am building a wine build with a few hacks to get around the ddraw blacking bug, iPod support, etc. I tried applying your patch for iPod support, but it seems that patch has a lot of conflicts with recent wine versions. I was about to go through and start settling them manually, but thought you may have a version laying around in your git tree that applies (relatively) cleanly to 1.0-rc4. The most recent iteration is at: http://www.winehq.org/pipermail/wine-patches/2008-May/054483.html It should still apply cleanly, since the last patch touches wineserver, you have to run tools/make_requests from the top of the wine tree to update all wineserver related files. I added wine-devel to CC since lots of people asked me about it. The downside is that it still doesn't work 100%, for some reason there is a huge delay every time the ipod is used. How to use it: Set windows version to vista Install iTunes Mount the ipod 'wine net start ipod service' Wait 10 seconds or so start itunes, it should take 3 minutes instead of instantly. (From the delay above) There is a race condition if the ipod service isn't started before itunes is, resulting in the ipod not being found. Might be a wine bug, but I'm not 100% sure. Cheers, Maarten. Cheers, Maarten What's the status of these patches? None of them have made it in yet...
Re: [WineHQ][WWN] WWN 349
On Sun, Jul 13, 2008 at 11:41 PM, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Zachary Goldberg wrote: ... but did not spell check :) Granted, the movie quote is pretty funny, even if isn't spelled right. Ivan What is spelled wrong? -Zach
RE: [PATCH2+TEST] RE: user32: Problem using SetClassLongW to subclass built-in control (Edit)
==
# Patch
==
--- wine-1.1.1-orig/dlls/user32/win.c 2008-07-12 01:55:55.0
+1000 +++ wine-1.1.1/dlls/user32/win.c 2008-07-14 16:49:21.0
+1000 @@ -173,6 +173,13 @@ static WND *create_window_handle( HWND p
win-owner = full_owner; win-class = class; win-winproc =
get_class_winproc( class ); + /* This is a window hack - When builtin
Edit class has been subclassed by SetClassLong(Ptr)W */ + /* If creating
ansi Edit window the class does not have a ansi proc, use unicode proc as
ansi */ + if(!unicode !IS_INTRESOURCE(name) !strcmpiW( name,
EDIT_builtin_class.name ) + WINPROC_IsUnicode( win-winproc, 0 )
WINPROC_IsUnicode( win-winproc, 1 )) + { + win-winproc =
WINPROC_AllocProc((WNDPROC)WINPROC_GetProc( win-winproc, 1 ), NULL); +
} It doesn't seem likely that this behaviour just applies to edit
controls. More likely, it applies to all builtin classes. -- Rob
Shearman
Yes you are right, this behaviour applies to all builtin classes. I can either
1. add more strcmpiW to compare with all the class names,
This can slow down create_window_handle() a little bit.
or
2. prove that there is no need for other builtin classes.
The major difference before Edit and other builtin controls is: the Text in
other builtin control does
not interact with user, the WM_SETTEXT message do A-W conversion,
WM_GETTEXT do a
W-A conversion, it can get same string back. so current wine can handle it.
The Edit control interact with user and input system, W-A conversion of
SendMessageA(WM_GETTEXT)
will not get eact the same string as user entered (eg CJK text). So if we
create a Ansi Edit window, we do
not want W-A conversion. That is why my patch is needed to make Edit window
a Ansi window.
So what do you think we should do?
Regards
Hongbo
_
It's simple! Sell your car for just $40 at CarPoint.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641_t=762955845_r=tig_OCT07_m=EXT
re: Illegal attachment in bug 14461
Vitaliy wrote: Bugzilla admin(s) please remove the illegal attachment from the http://bugs.winehq.org/show_bug.cgi?id=14461 Deleted.
Re: Allow running conformance tests in parallel
On Sun, Jul 13, 2008 at 9:59 PM, Scott Ritchie [EMAIL PROTECTED] wrote: About the same number of tests fail regardless of -j value. About -- shouldn't it be exactly? Yes, but our tests are flaky.
Re: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture
2008/7/14 Tobias Jakobi [EMAIL PROTECTED]: Hi there, this patchset fixes conformance of volumes/volumetextures creation (plus locking) in d3d8 and d3d9. Currently creating volumes/volumetextures always succeeds regardless of the usage and pool type specified. A testcase for both d3d8 and d3d9 is included in the last two patches. The test was verified on Vista and XP systems. Further fixes to volume/volumetexture locking are planned (the behaviour is still not quite correct) and some of the fixes in this patchset could be moved over to wined3d. That's also something that can be done when the hardest work is over. Cheers, Tobias Jakobi As you note in your comment, most of this should go into wined3d. I also think this should for the most part use the same code that is used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would probably be able to help you best there, but he's currently away.
RE: wined3d: universal surface convertor function for unsigned integer color formats
There's a pixelformat table that describes bitmasks and sizes in utils.c, you can access it with a function that is next to it. I think you can infer the shifting information from this table, if not please add it there instead of creating your own table. Also please do not use C++ comments(//), and watch out regarding tabs and spaces Your patch still adds the x8r8g8b8_to_x5r6g5 function, and I think it is a bit ugly to bypass the existing format conversion table entirely and add the convert_unsigned_pixels function. I think it would be better to access this function using the conversion table. One reason is that we could use the table in directx.c in CheckDeviceFormatConversion, so the information is all in one place. -Original Message- From: [EMAIL PROTECTED] [mailto:wine-patches- [EMAIL PROTECTED] On Behalf Of Victor Eremin Sent: Sunday, July 13, 2008 5:52 PM To: [EMAIL PROTECTED] Subject: wined3d: universal surface convertor function for unsigned integer color formats Converter function supports conversion between most of unsigned color argb/xrgb surface formats (like D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, and so on), and between luminosity color formats (D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, D3DFMT_P8 and D3DFMT_A1. Conversion from rgba to luminosity (and vice versa) is not currently implemented. The patch removes Cannot find coverter FIXMEs from Ancient Evil and Stranded 2 games. Patch also fixes water glitches in Stranded 2 game. --- dlls/wined3d/surface_base.c | 215 +- 1 files changed, 209 insertions(+), 6 deletions(-)
RE: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture
As you note in your comment, most of this should go into wined3d. I also think this should for the most part use the same code that is used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would probably be able to help you best there, but he's currently away. I am not sure, ddraw has different pool requirements and behaviors I think. e.g. ddraw can create sysmem render targets it seems. (Of course ddraw doesn't do volume textures, but I think we shouldn't apply different rules to volume and 2D textures)
Re: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture
2008/7/14 Stefan Dösinger [EMAIL PROTECTED]: As you note in your comment, most of this should go into wined3d. I also think this should for the most part use the same code that is used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would probably be able to help you best there, but he's currently away. I am not sure, ddraw has different pool requirements and behaviors I think. e.g. ddraw can create sysmem render targets it seems. (Of course ddraw doesn't do volume textures, but I think we shouldn't apply different rules to volume and 2D textures) I was referring to the usage flags.
Re: wined3d: universal surface convertor function for unsigned integer color formats
On Mon, Jul 14, 2008 at 02:51:42AM +0400, Victor Eremin wrote:
Converter function supports conversion between most of
unsigned color argb/xrgb surface formats (like D3DFMT_A8R8G8B8,
D3DFMT_A8R3G3B2, and so on), and between luminosity color formats
(D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8,
D3DFMT_P8 and D3DFMT_A1.
Conversion from rgba to luminosity (and vice versa) is not currently
implemented.
The patch removes Cannot find coverter FIXMEs from Ancient Evil and
Stranded 2 games.
Patch also fixes water glitches in Stranded 2 game.
I've attached my pixel conversion function which uses the table in
utils.c. Hope you find it useful although I haven't really polished it.
/* Counts the number of leading zeros in a mask, returns 0 if the mask is zero. */
static unsigned int count_zeros(unsigned int mask)
{
unsigned int count;
if (!mask)
return 0;
for (count = 0; !(mask 1); ++count)
{
mask = 1;
}
return count;
}
/* Scales a value masked by one mask to another. */
static DWORD convert_channel(DWORD src, DWORD srcmask, DWORD dstmask)
{
src = src srcmask;
src = count_zeros(srcmask);
src *= (dstmask count_zeros(dstmask)) / (srcmask count_zeros(srcmask));
src = count_zeros(dstmask);
return src;
}
static DWORD get_mask(DWORD value, DWORD mask)
{
return (value mask) count_zeros(mask);
}
static DWORD put_mask(DWORD value, DWORD mask)
{
return (value count_zeros(mask)) mask;
}
/* MSDN states that the default value is 1 for missing channels; and that
* D3DFMT_A8 is the exception where the missing channels are 0.
*
* I assume 1 means 1 in every bit. */
static DWORD convert_pixel(DWORD srcword, const StaticPixelFormatDesc* srcentry, const StaticPixelFormatDesc* dstentry)
{
DWORD pixel = 0;
if (srcentry-alphaMask dstentry-alphaMask)
pixel |= convert_channel(srcword, srcentry-alphaMask, dstentry-alphaMask);
else
pixel |= dstentry-alphaMask;
if (srcentry-redMask dstentry-redMask)
pixel |= convert_channel(srcword, srcentry-redMask, dstentry-redMask);
else
pixel |= dstentry-redMask;
if (srcentry-greenMask dstentry-greenMask)
pixel |= convert_channel(srcword, srcentry-greenMask, dstentry-greenMask);
else
pixel |= dstentry-greenMask;
if (srcentry-blueMask dstentry-blueMask)
pixel |= convert_channel(srcword, srcentry-blueMask, dstentry-blueMask);
else
pixel |= dstentry-blueMask;
return pixel;
}
DWORD convert_pixelformat(DWORD pixel, WINED3DFORMAT srcformat, WINED3DFORMAT dstformat)
{
const StaticPixelFormatDesc* srcentry = getFormatDescEntry(srcformat, NULL, NULL);
const StaticPixelFormatDesc* dstentry = getFormatDescEntry(dstformat, NULL, NULL);
if (!srcentry) {
FIXME(Unsupported pixelformat.\n);
return 0;
}
if (!dstentry) {
FIXME(Unsupported pixelformat.\n);
return 0;
}
return convert_pixel(pixel, srcentry, dstentry);
}
static UINT get_pixel(const LPCVOID data, UINT bpp, const RECT* const rect, UINT pitch, UINT x, UINT y)
{
DWORD pixel = 0;
memcpy(pixel, (char*)data + (rect-top + y) * pitch + (rect-left + x) * bpp, bpp);
return pixel;
}
Re: wined3d: universal surface convertor function for unsigned integer color formats
On Monday 14 July 2008 18:21:19 Stefan Dösinger wrote:
There's a pixelformat table that describes bitmasks and sizes in utils.c,
you can access it with a function that is next to it. I think you can infer
the shifting information from this table, if not please add it there
instead of creating your own table.
I've found this array (StaticPixelFormatDesc formats[]), but I'm not sure if
adding new fields will be a good idea. Reasons:
1) This will contain redundant and unused information (masks-shifts. I
wanted to use masks initially, but decided to use mask_size and shift,
because it's less prone to errors). Redundant means higher chance of errors
and breaking up something somewhere else.
2) Ideally for conversion purposes it should have more channel fields. (at
least L (the only one currently used), but ideally also bitmasks
for W, V, U, D, S channels). But adding more fields will easily
turn formats[] table into monstrosity.
3) StaticFormatDescriptor (and my own SurfFmtDesc) both aren't really what
I'd like to use with conversion routine. Ideally something like that:
---
struct ChannelDesc{
char name; /*channel neame 'a', 'r', 'g', 'd', etc*/
BYTE bits;
BYTE shift;
int defaultBits; /*if 1 then during conversion channel bits in
destination
surface must be set to 1, if such channel doesn't exist in source surface.*/
}
struct FormatDesc{
WINED3DFORMAT fmt;
BYTE size;
BYTE numChannels;
struct ChannelDesc channels[8];
}
---
could be perfect/compact descriptor suitable for converting surfaces. This way
it could be much easier to handle more surface format conversions in simple
fashion. I.e. given two such descriptors I could put all conversion routine
in a loop that would handle almost anything, instead of calling same function
several times for each channel. Such function could be useful in some other
places.
Is it possible to accept patch without merging two tables, until better
(or final) conversion implementation will be written? (like the one which
handles A8R8G8B8-L8 or A8R8G8B8-P8 conversions) Your arguments about C++
comments/spaces, unused x8r8g8b8_to_x5r6g5 are reasonable, but I'm not sure
that merging current table used by convert_unsigned_pixels()
with StaticPixelFormatDesc formats[] from utils.c will be good idea.
Also please do not use C++ comments(//), and watch out regarding tabs and
spaces
Will do.
Your patch still adds the x8r8g8b8_to_x5r6g5 function, and I think it is a
bit ugly to bypass the existing format conversion table entirely and add
the convert_unsigned_pixels function. I think it would be better to access
this function using the conversion table. One reason is that we could use
the table in directx.c in CheckDeviceFormatConversion, so the information
is all in one place.
Currently default conversion (find_convertor) is not bypassed.
It is still used if there is no conversion available via
convert_unsigned_pixels(), which is likely to happen, because
convert_unsigned_pixels() supports only 20 formats. Also, please note that
there is only one entry in convertors table currently (if you don't count
x8r8g8b8_to_x5r6g5).
putting convert_unsigned_pixels in convertors table won't be possible,
because it'll require either writing of 400 wrappers and adding 400 entries
in converter table (unless I don't know some C-technique for avoiding this).
This is extremely ugly.
Also, currently it won't be possible to support all conversions using
convertors table. You won't be able to use current convertors for formats
with palette (someone already have sent me email asking to implement
X8R8G8B8-P8 conversion).
I think instead of using only conversion table it will be better to provide
centrilised functions like is_conversion_supported(WINED3DFORMAT,
WINED3DFORMAT) and convert_pixels. It might make sense to use different
routines/tables for different format conversions.
--
Виктор Ерёмин ([EMAIL PROTECTED])
signature.asc
Description: This is a digitally signed message part.
new valgrind warnings in IWineD3DImpl_CreateDevice, IDirectDrawImpl_CreateSurface
Lots of tests are showing new valgrind warnings involving IWineD3DImpl_CreateDevice, e.g. http://kegel.com/wine/valgrind/logs/2008-07-14-06.13/vg-ddraw_dsurface-diff.txt + Invalid free() / delete / delete[] +at notify_free (heap.c:199) +by RtlFreeHeap (heap.c:1284) +by compile_state_table (state.c:4557) +by IWineD3DImpl_CreateDevice (directx.c:3472) +by DDRAW_Create (main.c:235) +by DirectDrawCreate (main.c:373) +by CreateDirectDraw (dsurface.c:36) +by func_dsurface (dsurface.c:2616) +by run_test (test.h:488) +by main (test.h:537) http://kegel.com/wine/valgrind/logs/2008-07-14-06.13/vg-d3d9_query-diff.txt + Invalid free() / delete / delete[] +at notify_free (heap.c:199) +by RtlFreeHeap (heap.c:1284) +by compile_state_table (state.c:4557) +by IWineD3DImpl_CreateDevice (directx.c:3472) +by IDirect3D9Impl_CreateDevice (directx.c:493) +by test_query_support (query.c:96) +by func_query (query.c:266) +by run_test (test.h:488) +by main (test.h:537) Plus, http://kegel.com/wine/valgrind/logs/2008-07-14-06.13/vg-ddraw_dsurface-diff.txt has the additional new warning: + Conditional jump or move depends on uninitialised value(s) +at IDirectDrawImpl_CreateSurface (ddraw_thunks.c:403) +by MipMapCreationTest (dsurface.c:198) +by func_dsurface (dsurface.c:2618) +by run_test (test.h:488) +by main (test.h:537) + Uninitialised value was created by a stack allocation +at IDirectDrawImpl_CreateSurface (ddraw_thunks.c:384) Stefan, could you have a look? Thanks... - Dan
Re: advpack: Sign-compare warnings fix (Resend)
Andrew Talbot wrote:
Is there anything wrong with this patch, please?
If I might venture a guess it's probably because of the casts. Casts are
evil if not really needed and using casts to get rid of the sign
comparison warnings is debatable at best.
---
Changelog:
advpack: Sign-compare warnings fix.
diff --git a/dlls/advpack/files.c b/dlls/advpack/files.c
index 5e9ce30..43c07ea 100644
--- a/dlls/advpack/files.c
+++ b/dlls/advpack/files.c
@@ -709,7 +709,7 @@ HRESULT WINAPI ExtractFilesA(LPCSTR CabName, LPCSTR
ExpandDir, DWORD Flags,
if (FileList)
{
szConvertedList = convert_file_list(FileList, dwFileCount);
-if (!szConvertedList || dwFileCount == -1)
+if (!szConvertedList || (LONG)dwFileCount == -1)
This one could be replaced by a comparison with either -1u or ~0.
{
res = E_FAIL;
goto done;
diff --git a/dlls/advpack/install.c b/dlls/advpack/install.c
index c5a5df0..05a7232 100644
--- a/dlls/advpack/install.c
+++ b/dlls/advpack/install.c
@@ -41,7 +41,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(advpack);
#define SPAPI_MASK 0xL
#define HRESULT_FROM_SPAPI(x) ((x SPAPI_MASK) | SPAPI_PREFIX)
-#define ADV_HRESULT(x) ((x SPAPI_ERROR) ? HRESULT_FROM_SPAPI(x) :
HRESULT_FROM_WIN32(x))
+#define ADV_HRESULT(x) ((x SPAPI_ERROR) ? HRESULT_FROM_SPAPI(x) :
(DWORD)HRESULT_FROM_WIN32(x))
#define ADV_SUCCESS 0
#define ADV_FAILURE 1
bye
michael
RE: wined3d: Enable filtering for D3DFMT_A4R4G4B4.
Looks ok to me -Original Message- From: [EMAIL PROTECTED] [mailto:wine-patches- [EMAIL PROTECTED] On Behalf Of Philip Nilsson Sent: Monday, July 14, 2008 11:20 AM To: [EMAIL PROTECTED] Subject: wined3d: Enable filtering for D3DFMT_A4R4G4B4. This patch enables texture filtering for textures using the A4R4G4B4 format, I can see no reason why it shouldn't be filtered (especially considering X4R4G4B4 has it). Works for me, in any case. Writing a test case may be hard. Probably solves bug 13256 (I can't think of any other format that would be used instead).
Re: advpack: Sign-compare warnings fix (Resend)
Hi Michael, Michael Stefaniuc wrote: Andrew Talbot wrote: -if (!szConvertedList || dwFileCount == -1) +if (!szConvertedList || (LONG)dwFileCount == -1) This one could be replaced by a comparison with either -1u or ~0. bye michael The first of these would work; the second would not, since it just inverts the bits of decimal zero, which is a signed int. (The reason I say decimal zero is because decimal constants are signed, whereas hexadecimal constants are unsigned[!] Thus, ~0x0 would be a viable alternative.) Thanks and regards, -- Andy.
Re: [WineHQ][WWN] WWN 349
On Mon, Jul 14, 2008 at 7:20 AM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 11:41 PM, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Zachary Goldberg wrote: ... but did not spell check :) Granted, the movie quote is pretty funny, even if isn't spelled right. Ivan What is spelled wrong? -Zach I don't see any spelling errors, but could we get a main goal? Its main goal is to It also serves to inform you... (It looks like the patch doesn't have this mistake, but the website [ http://winehq.org/?issue=348 ] does) Bryan DeGrendel
Re: [WineHQ][WWN] WWN 349
On Mon, Jul 14, 2008 at 5:05 PM, Bryan DeGrendel [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 7:20 AM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 11:41 PM, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Zachary Goldberg wrote: ... but did not spell check :) Granted, the movie quote is pretty funny, even if isn't spelled right. Ivan What is spelled wrong? -Zach I don't see any spelling errors, but could we get a main goal? Its main goal is to It also serves to inform you... (It looks like the patch doesn't have this mistake, but the website [ http://winehq.org/?issue=348 ] does) Bryan DeGrendel This patch was for 349, which has a goal. The linked site was for 348... which should have a goal. I'll send in a patch for that.
Re: advpack: Sign-compare warnings fix (Resend)
Andrew Talbot wrote: (The reason I say decimal zero is because decimal constants are signed, whereas hexadecimal constants are unsigned[!] Thus, ~0x0 would be a viable alternative.) In fact, I have just tried both ~0 and ~0x0 and neither worked. (I can't figure out why the latter fails.) But -1u works, yes. -- Andy.
Re: [PATCH 1/2] user32: Add more tests for SetWindowPos.
On Fri, Jul 11, 2008 at 6:28 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: The fix looks good now, but you should really test the message sequences instead of just counting a single message. We have already all the necessary mechanisms for this. -- Alexandre Julliard [EMAIL PROTECTED] Right, I'll send a patch that tests the entire message sequence. The problem there is that other parts of the sequence are wrong, so I tested for the single message I cared about to show my fix actually does something.
Re: advpack: Sign-compare warnings fix (Resend)
Andrew Talbot wrote: Andrew Talbot wrote: (The reason I say decimal zero is because decimal constants are signed, whereas hexadecimal constants are unsigned[!] Thus, ~0x0 would be a viable alternative.) In fact, I have just tried both ~0 and ~0x0 and neither worked. (I can't figure out why the latter fails.) But -1u works, yes. Sorry for the noise, but just to say I was wrong in claiming that hex constants are unsigned. I have opted for ~0U in try #2. Thanks, -- Andy.
Compile error in wine-1.1.1
Downloaded wine-1.1.1.tar.bz2, and after unzipping, running configure (which included adding some -dev libraries to make it happy) and 'make depend', it ran for several minutes before stopping here: --snip-- make[2]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls/mswsock' make[2]: Entering directory `/home/dunlapg/src/wine-1.1.1/dlls/msxml3' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o attribute.o attribute.c In file included from attribute.c:32: msxml_private.h:94: error: expected ')' before 'xmldoc' make[2]: *** [attribute.o] Error 1 make[2]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls/msxml3' make[1]: *** [msxml3] Error 2 make[1]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls' make: *** [dlls] Error 2 --snip-- I looked at msxml_private.h:94, and it looks perfectly harmless; some previous function prototypes in the same header file use xmlDocPtr in the argument list as well, and don't cause an error. I'm using an Ubuntu 8.04 install. gcc reports version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7). Any ideas? -George
Re: Compile error in wine-1.1.1
Am 15.07.2008 um 01:13 schrieb George Dunlap: Downloaded wine-1.1.1.tar.bz2, and after unzipping, running configure (which included adding some -dev libraries to make it happy) [...] You need really a lot of packages: http://wiki.winehq.org/Recommended_Packages If it still doesn't work, you can seek for the missing bits with: apt-rdepends -b --state-follow=NotInstalled wine ... and install packages until none but the kernel stuff and virtual packages are left in the list given by this command. Unfortunately, an apt-get build-dep wine recommended elsewhere didn't work for me. HTH, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: CUDA wrapper
We have tried to get the trace, many different ways, but to no avail. I've read through everything on running a trace of it and I've tried it with different files and it works fine but when we try it with the folding client we don't get any trace. The cudart.dll.so which is placed in the /usr/local/lib/wine folder is being recognized by wine as we are not longer getting the not implemented error but now it is just a matter of determining what function it isn't liking. I've double check all the functions and they all seem to be fine minus the 4 direct3d functions and 6 functions which contain c++ coding. The 6 functions though involve copying memory, symbol size, and channel format. They don't involve anything that would be needed to start the folding client, they are all things that would cause a fault after the GPU has started calculations, or so I am lead to believe. As always the latest code is available at http://shelnutt.twomurs.com/patches/cuda/ and a 7z of it all at http://shelnutt.twomurs.com/patches/cuda.7z [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] WINEDEBUG=+trace winedbg [EMAIL PROTECTED] WineDbg starting on pid 0016 start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904 0x7b877d02 start_process+0xc2 [/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl %esi,0x0(%esp) Unable to open file '' Wine-dbgn fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x), stub! err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0xf7f80aaf Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling it Process of pid=0016 has terminated Wine-dbgquit [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] WINEDEBUG=+trace wine [EMAIL PROTECTED] fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x32f40c,0x), stub! err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0xf7fddaaf [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/[EMAIL PROTECTED] /[EMAIL PROTECTED] Thanks, Seth Shelnutt On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher [EMAIL PROTECTED] wrote: No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code 0xc005 is a general protection fault. After your program has crashed, the breakpoint wine automatically sets to catch program startup is not valid anymore (there is no program to break anymore), that causes the message you quoted. Whats strange is that the debugger does not catch the exception. While the first-chance event can be disabled, you should get a last-chance exception catch right before the program dies. See http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info about configuring the debugger. Have you tried a relay trace yet? Regards, Michael Karcher
RE: CUDA wrapper
WINEDEBUG=+trace doesn't really do anything. using WINEDEBUG=trace+all (or
just +all) will enable *lots* of debug output.
However, what you want to do is to add something like this to your cuda
wrapper:
At the beginning of the file, after the includes:
WINE_DEFAULT_DEBUG_CHANNEL(cuda);
Then in each function:
void cudaSomething(int a, const char *b) {
TRACE((%d, %s)\n, a, b);
}
Then run your app with WINEDEBUG=+cuda
That will give you some information how far the app gets in talking to your
wrapper and the native lib
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Seth Shelnutt
Sent: Monday, July 14, 2008 9:31 PM
To: Michael Karcher; wine-devel@winehq.org
Subject: Re: CUDA wrapper
We have tried to get the trace, many different ways, but to no avail. I've
read through everything on running a trace of it and I've tried it with
different files and it works fine but when we try it with the folding client
we don't get any trace. The cudart.dll.so which is placed in the
/usr/local/lib/wine folder is being recognized by wine as we are not longer
getting the not implemented error but now it is just a matter of determining
what function it isn't liking. I've double check all the functions and they
all seem to be fine minus the 4 direct3d functions and 6 functions which
contain c++ coding. The 6 functions though involve copying memory, symbol
size, and channel format. They don't involve anything that would be needed
to start the folding client, they are all things that would cause a fault
after the GPU has started calculations, or so I am lead to believe.
As always the latest code is available at
http://shelnutt.twomurs.com/patches/cuda/ and a 7z of it all at
http://shelnutt.twomurs.com/patches/cuda.7z
[EMAIL PROTECTED]:~/.wine/drive_c/Program
Files/[EMAIL PROTECTED]/[EMAIL PROTECTED] WINEDEBUG=+trace winedbg
[EMAIL PROTECTED]
WineDbg starting on pid 0016
start_process () at /media/md0/wine/wine/dlls/kernel32/process.c:904
0x7b877d02 start_process+0xc2
[/media/md0/wine/wine/dlls/kernel32/process.c:904] in kernel32: movl
%esi,0x0(%esp)
Unable to open file ''
Wine-dbgn
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex
samplers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers +
MAX_TEXTURES(=8) combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33f40c,0x), stub!
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0xf7f80aaf
Invalid address (0x7b877d07 start_process+0xc7) for breakpoint 0, disabling
it
Process of pid=0016 has terminated
Wine-dbgquit
[EMAIL PROTECTED]:~/.wine/drive_c/Program
Files/[EMAIL PROTECTED]/[EMAIL PROTECTED] WINEDEBUG=+trace wine [EMAIL
PROTECTED]
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex
samplers and32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers +
MAX_TEXTURES(=8) combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x32f40c,0x), stub!
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0xf7fddaaf
[EMAIL PROTECTED]:~/.wine/drive_c/Program
Files/[EMAIL PROTECTED]/[EMAIL PROTECTED]
Thanks,
Seth Shelnutt
On Sun, Jul 13, 2008 at 5:26 AM, Michael Karcher
[EMAIL PROTECTED] wrote:
No, thats boring. Your program crahsed at address 0xf7fcaaf. IIRC code
0xc005 is a general protection fault. After your program has
crashed, the breakpoint wine automatically sets to catch program startup
is not valid anymore (there is no program to break anymore), that causes
the message you quoted.
Whats strange is that the debugger does not catch the exception. While
the first-chance event can be disabled, you should get a last-chance
exception catch right before the program dies. See
http://www.winehq.org/site/docs/winedev-guide/dbg-config for more info
about configuring the debugger.
Have you tried a relay trace yet?
Regards,
Michael Karcher
RE: [1/8] [d3d8] validate pool type in CreateVolumeTexture
+if ((DWORD)(Pool) = 4) {
+ERR((%p) Called with invalid pool type\n, This);
+return D3DERR_INVALIDCALL;
+}
You could use if(Pool != D3DPOOL_DEFAULT Pool != MANAGED ...) instead
of comparing to the arbitary value 4. The compiler should figure that out and
generate a = 4 for better efficiency, but even if not it doesn't hurt because
Create* isn't performance critical.
RE: Compile error in wine-1.1.1
George Dunlap [mailto:[EMAIL PROTECTED] wrote: Downloaded wine-1.1.1.tar.bz2, and after unzipping, running configure (which included adding some -dev libraries to make it happy) and 'make depend', it ran for several minutes before stopping here: --snip-- make[2]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls/mswsock' make[2]: Entering directory `/home/dunlapg/src/wine-1.1.1/dlls/msxml3' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o attribute.o attribute.c In file included from attribute.c:32: msxml_private.h:94: error: expected ')' before 'xmldoc' make[2]: *** [attribute.o] Error 1 make[2]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls/msxml3' make[1]: *** [msxml3] Error 2 make[1]: Leaving directory `/home/dunlapg/src/wine-1.1.1/dlls' make: *** [dlls] Error 2 --snip-- I looked at msxml_private.h:94, and it looks perfectly harmless; some previous function prototypes in the same header file use xmlDocPtr in the argument list as well, and don't cause an error. I'm using an Ubuntu 8.04 install. gcc reports version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7). Got the same or similar error two days ago after updating my git repository and found in configure a warning about xml2-dev (if I'm not mistaken) being not available. Installed that and the error went away. Guess someone broke the optional dependancy on the xml2-devel package. I think I remember some noise on this mailinglist from someone stating that Wine without xml2 should be considered broken anyhow. Rolf Kalbermatter
RE: CUDA wrapper
Am Montag, den 14.07.2008, 23:18 -0500 schrieb Stefan Dösinger:
WINEDEBUG=+trace doesn't really do anything. using WINEDEBUG=trace+all
(or just +all) will enable *lots* of debug output.
Right.
However, what you want to do is to add something like this to your
cuda wrapper:
At the beginning of the file, after the includes:
WINE_DEFAULT_DEBUG_CHANNEL(cuda);
Then in each function:
void cudaSomething(int a, const char *b) {
TRACE((%d, %s)\n, a, b);
}
This would be the long-term goal, probably, but WINEDEBUG=+relay should
automatically generate thunks in memory that do this printing (but not
only for cuda, of course, except if configured appropriately). In the
short term, this should yield a hint where to start searching more
quickly.
Regards,
Michael Karcher
Re: advpack: Sign-compare warnings fix (Resend)
Am Montag, den 14.07.2008, 23:33 +0100 schrieb Andrew Talbot: (The reason I say decimal zero is because decimal constants are signed, whereas hexadecimal constants are unsigned[!] Thus, ~0x0 would be a viable alternative.) In fact, I have just tried both ~0 and ~0x0 and neither worked. (I can't figure out why the latter fails.) But -1u works, yes. Sorry for the noise, but just to say I was wrong in claiming that hex constants are unsigned. I have opted for ~0U in try #2. Good choice. While I wanted to post that I like -1u much better, as I feel it as the canonical choice for all-bits-set, a grep on the wine source code showed that wine always uses ~0U, and never -1U, so in wine it is ~0U (or ~0UL if dealing with platform longs). Regards, Michael Karcher
