Re: [PATCH 2/8] urlmon/tests: CoInternetCreateZoneManager not present on W95B
On 04/16/2010 12:20 AM, Detlef Riekenberg wrote: --- dlls/urlmon/tests/sec_mgr.c | 29 + 1 files changed, 21 insertions(+), 8 deletions(-) Hi Detlef, After this patch none of the tests are actually run on W95B and we have loads of win_skip's. Wouldn't it be better to just check for one (or all) and bail out with a (only one) win_skip()? I guess if one is not present, none are? -- Cheers, Paul.
Re: loader: Fix French translation of wine manpage (resent)
Hi. Could someone please tell me why this patch was silently discarded ? Is there some something awfully wrong in the changes in tools/Makefile.in ? Or some other trivial mistake ? Frédéric
Re: [PATCH] RFC: C99: rewrote some extern inline to static inline
On Thu, 15 Apr 2010 11:56:32 +0200, Yann Droneaud wrote: > In order to build with CLANG with default arguments, extern inline > declaration > must be changed. > > By default CLANG uses C99's "extern inline" semantic which is like > gcc's "inline", and not the expected gcc's "extern inline" behavor. > > Additionnaly LLVM/CLANG don't support multiple function definitions with > different linkage in the same module (source file) : so it's not > possible to have a static inline definition in a header included in a > source file with a externally visible function of the same name. > C99's inline differs from GNU C's in that it will never cause a function definition to be emitted, so you should be able to replace GNU C's "extern inline" with plain inline. This has an advantage over static inline if you need to define an externally visible function, since you can avoid the copying the definition from the header to a source file by making sure the translation unit declares the function as C99 extern inline before including the inline definition. > This patch convert extern inline to static inline, so > embedded functions are not globally visible. > > This could be a problem if those symbols are needed. But currently, > I'm not able to give you any status: i was only able to run "cmd.exe", > before going further with LLVM/CLANG. I'm fighting with LLVM/CLANG bug > instead. > > If they are so symbols needed or if the binaries size grow to much, > the "extern inline" attribute will have to be converted to a macro, > expanded to "extern inline" with gcc in default behavor, and "inline" with > a C99 compatible compiler. > With C99 static inline, there should be no function definitions emitted so the size should not be much different. > See for example how this work in GMP: > http://gmplib.org:8000/gmp/file/da5903b6e386/gmp-h.in#l414 > Thanks for helping Wine get closer to C standards conformance! -Albert
Re: winex11: add support for 32-bit DDBs
On Thu, Apr 15, 2010 at 7:04 AM, Erich Hoover wrote:
> On Thu, Apr 15, 2010 at 2:22 AM, Roderick Colenbrander <
> thunderbir...@gmail.com> wrote:
>
>> I can't see the screenshot well but that's notepad? What display
>> drivers are you using?
>>
>> Roderick
>>
>> On Thu, Apr 15, 2010 at 3:36 AM, Erich Hoover wrote:
>> > I noticed a problem with the icons in Wine when alt+tabbing today.
>> After
>> > doing a regression test it appears that commit
>> > c29cf0591976f96c3adb30c3c3b6db59f4983251 results in pixmaps that do not
>> > always display properly when alt+tabbing (see attached screenshot).
>> >
>>
>
> That's the notepad window in the compiz alt+tab dialog (everything except
> the window icon gets scaled). The key feature is that in the bottom right
> corner the icon for the window is really messed up (black with a few dots of
> color). It's also worth noting that the window icon does not display in the
> gnome taskbar at all after this patch, just a generic "this program has no
> icon" icon. I'm using the nVidia driver version 185.18.36.
>
I looked into this a little and it appears like it's necessary to use the
extended window manager hint _NET_WM_ICON to use 32-bit window icons. I've
whipped up a small patch (attached) that does this and it fixes the problem
I'm seeing (both with alt+tab and in the gnome taskbar), does this solution
appear acceptable?
Erich Hoover
ehoo...@mines.edu
From 279f193db8424110463d8077920435b9186af1dc Mon Sep 17 00:00:00 2001
From: Erich Hoover
Date: Thu, 15 Apr 2010 10:02:06 -0600
Subject: winex11.drv: Set the _NET_WM_ICON for 32-bit window icons.
---
dlls/winex11.drv/window.c | 21 +
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/x11drv_main.c |1 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c
index a9a3769..f42f537 100644
--- a/dlls/winex11.drv/window.c
+++ b/dlls/winex11.drv/window.c
@@ -833,6 +833,7 @@ static void set_icon_hints( Display *display, struct x11drv_win_data *data, HICO
}
else
{
+DIBSECTION bmpXor;
HBITMAP hbmOrig;
RECT rcMask;
BITMAP bmMask;
@@ -861,6 +862,26 @@ static void set_icon_hints( Display *display, struct x11drv_win_data *data, HICO
hints->icon_mask = X11DRV_get_pixmap(data->hWMIconMask);
destroy_icon_window( display, data );
hints->flags = (hints->flags & ~IconWindowHint) | IconPixmapHint | IconMaskHint;
+
+GetObjectW( ii.hbmColor, sizeof(bmpXor), &bmpXor );
+/* Icons with an alpha channel need to be handled using the _NET_WM_ICON property */
+if (bmpXor.dsBm.bmBitsPixel == 32)
+{
+int xorLength, wm_icon_size;
+char *xor_bits;
+
+wm_icon_size = 2 + bmpXor.dsBm.bmWidth * bmpXor.dsBm.bmHeight;
+xorLength = bmpXor.dsBm.bmWidth * bmpXor.dsBm.bmHeight * 4;
+xor_bits = (char *) HeapAlloc( GetProcessHeap(), 0, wm_icon_size * 4 );
+memcpy(&xor_bits[0*4], &bmpXor.dsBm.bmWidth, 4);
+memcpy(&xor_bits[1*4], &bmpXor.dsBm.bmHeight, 4);
+GetBitmapBits( ii.hbmColor, xorLength, &xor_bits[2*4] );
+wine_tsx11_lock();
+XChangeProperty( display, data->whole_window, x11drv_atom(_NET_WM_ICON), XA_CARDINAL, 32,
+ PropModeReplace, (unsigned char *) xor_bits, wm_icon_size);
+wine_tsx11_unlock();
+HeapFree( GetProcessHeap(), 0, xor_bits );
+}
}
}
diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h
index b4ccff3..cd96700 100644
--- a/dlls/winex11.drv/x11drv.h
+++ b/dlls/winex11.drv/x11drv.h
@@ -635,6 +635,7 @@ enum x11drv_atoms
XATOM__NET_WM_NAME,
XATOM__NET_WM_PID,
XATOM__NET_WM_PING,
+XATOM__NET_WM_ICON,
XATOM__NET_WM_STATE,
XATOM__NET_WM_STATE_ABOVE,
XATOM__NET_WM_STATE_FULLSCREEN,
diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c
index a7f7ae0..56e64f4 100644
--- a/dlls/winex11.drv/x11drv_main.c
+++ b/dlls/winex11.drv/x11drv_main.c
@@ -142,6 +142,7 @@ static const char * const atom_names[NB_XATOMS - FIRST_XATOM] =
"_NET_WM_NAME",
"_NET_WM_PID",
"_NET_WM_PING",
+"_NET_WM_ICON",
"_NET_WM_STATE",
"_NET_WM_STATE_ABOVE",
"_NET_WM_STATE_FULLSCREEN",
--
1.6.3.3
Re: [1/1] wcmd/tests: Attrib tests (resend)
Eleazar Galano writes: >> Dan Kegel is helping me get started with Wine development. To prepare >> for modifications to the ATTRIB function of CMD.EXE, I have added test >> cases for the current functionality of ATTRIB. It seems to me this should go in programs/attrib. Also it should test that the attributes actually changed. -- Alexandre Julliard julli...@winehq.org
Re: ddraw: Do not restore the display mode from inside SetCooperativeLevel (resend)
Johan Gill writes: > dlls/ddraw/ddraw.c|3 --- > dlls/ddraw/tests/ddrawmodes.c | 25 + > 2 files changed, 25 insertions(+), 3 deletions(-) This causes the test to not restore the display mode properly on exit. -- Alexandre Julliard julli...@winehq.org
Re: HLSL Compiler and d3dcompiler_xx.dll
On Thu, Apr 15, 2010 at 11:23 AM, Stefan Dösinger wrote: > > Am 14.04.2010 um 20:45 schrieb Jason Green: >> FYI, we encountered a game a while back which used a few shaders that >> depended on being compiled with a particular version for d3dx9_##.dll. >> There was a compiler bug which the game engine knew about and accounted for. >> If you tried to use the compiled shader from a newer d3dx9_##.dll, then the >> rendering wouldn't look quite right on certain objects. >> >> So, there's one argument for identical bytecode compatibility, but it's >> likely that very few apps will exhibit behavior like this. > I think it's only an argument that we may need some specific tests that check > for identical bytecode. And by your description it sounds like the compiler > bug can be detected by looking at the rendering output. I still think that > having the majority of tests check the generated bytecode is a bad idea: > > * It will be hard to implement the same compiler result As long as it is possible, I think we should do. > * It will make our own optimizations impossible(the MS compiler is very good > optimization wise, so that point is mostly moot) > * It will be hard to maintain the tests when we're moving them to a newer MS > compiler version Tests should fail if a newer version of MS compiler is used and different code is produced. Or, if you prefer, win_skip if version is newer than what the tests expect. > * There are things that can be translated into different bytecodes, and all > are equally valid and optimal, like constants ordering. > Same as your first concern.
Re: winex11: add support for 32-bit DDBs
On Thu, Apr 15, 2010 at 2:22 AM, Roderick Colenbrander < thunderbir...@gmail.com> wrote: > I can't see the screenshot well but that's notepad? What display > drivers are you using? > > Roderick > > On Thu, Apr 15, 2010 at 3:36 AM, Erich Hoover wrote: > > I noticed a problem with the icons in Wine when alt+tabbing today. After > > doing a regression test it appears that commit > > c29cf0591976f96c3adb30c3c3b6db59f4983251 results in pixmaps that do not > > always display properly when alt+tabbing (see attached screenshot). > > > That's the notepad window in the compiz alt+tab dialog (everything except the window icon gets scaled). The key feature is that in the bottom right corner the icon for the window is really messed up (black with a few dots of color). It's also worth noting that the window icon does not display in the gnome taskbar at all after this patch, just a generic "this program has no icon" icon. I'm using the nVidia driver version 185.18.36. Erich Hoover ehoo...@mines.edu
Re: mciseq: Prevent busy-wait while paused.
Hi Joerg, 2010/4/15 : > Hi, > > any comment on that patch? It's currently the bottommost in > source.winehq.org/patches hence may fall into the bitbucket anytime. > > I had noticed that the MCI MIDI player would busy loop while paused > because of a while(xyz) ; statement therein. > > Test it using these MCI commands > open c:\data\foo.mid alias m > play m > pause m > > So I simply added a Sleep() and wrote: >>7 ms is arbitrary. It allows to sleep well yet be responsive enough >>so the app doesn't wait too long should the next command be MCI_Stop. >>For the ear, an even larger sleep would be good enough. It would be better to signal an event object to wake up from sleep. Cheers, Maarten
mciseq: Prevent busy-wait while paused.
Hi, any comment on that patch? It's currently the bottommost in source.winehq.org/patches hence may fall into the bitbucket anytime. I had noticed that the MCI MIDI player would busy loop while paused because of a while(xyz) ; statement therein. Test it using these MCI commands open c:\data\foo.mid alias m play m pause m So I simply added a Sleep() and wrote: >7 ms is arbitrary. It allows to sleep well yet be responsive enough >so the app doesn't wait too long should the next command be MCI_Stop. >For the ear, an even larger sleep would be good enough. Sleep is a sort of stop gap until someone invents a notification/setEvent/Resume patch or whatever would be TRT. Regards, Jörg Höhle
Re: oleaut32: be more explicit with locale dependent parsing of dates (try 2)
On 4/14/2010 23:56, André Hentschel wrote:
Nikolay Sivov schrieb:
On 4/14/2010 22:51, André Hentschel wrote:
case 0x3: /* TTT TTTDD TTTDDD */
- if (iDate&& dp.dwCount == 3)
+ if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8))
case 0x1B: /* localized DDDTTT */
- if (!iDate)
+ if (strncmp(ShortDate,"dd.MM.yy",8))
{
hRet = DISP_E_TYPEMISMATCH;
break;
This looks like a workaround. I don't think you should hard code it this
way, what's so special with this format?
And what is a initial problem with that?
The date and time parsing is locale dependent of course, but the code is mainly
written for english.
There was a bug so i fixed it and introduced a regression and bug 22287 came up.
Yes, but that doesn't mean it should be hard coded this way. Am I right
it should use localized format and try to fit input in it?
If so, this should be fixed in a general way.
Re: HLSL Compiler and d3dcompiler_xx.dll
Am 14.04.2010 um 20:45 schrieb Jason Green: > FYI, we encountered a game a while back which used a few shaders that > depended on being compiled with a particular version for d3dx9_##.dll. There > was a compiler bug which the game engine knew about and accounted for. If > you tried to use the compiled shader from a newer d3dx9_##.dll, then the > rendering wouldn't look quite right on certain objects. > > So, there's one argument for identical bytecode compatibility, but it's > likely that very few apps will exhibit behavior like this. I think it's only an argument that we may need some specific tests that check for identical bytecode. And by your description it sounds like the compiler bug can be detected by looking at the rendering output. I still think that having the majority of tests check the generated bytecode is a bad idea: * It will be hard to implement the same compiler result * It will make our own optimizations impossible(the MS compiler is very good optimization wise, so that point is mostly moot) * It will be hard to maintain the tests when we're moving them to a newer MS compiler version * There are things that can be translated into different bytecodes, and all are equally valid and optimal, like constants ordering.
Packaging Wine 64bit
Hello guys! Wine 64bit (the one able to run 64bit Windows application) is nearly feature complete. As of wine-1.1.42 Wine supports shared 32/64-bit setups; though we do not recommend it yet for general consumption. This is more of a "heads up" info as the next stable Wine release aka 1.2 is "imminent" (about one month until code freeze and then an additional month for the stabilization period). Proper Wine 64bit support poses some challenges for packaging as it requires *both* 64bit as well as 32bit libraries and binaries. This makes Wine 64bit packaging different from the normal other 64bit packages. To ease the pain we have created a wiki page with information pertinent to packagers/distributions: http://wiki.winehq.org/Wine64ForPackagers Do not hesitate to contact us either by email to wine-devel or on irc on Freenode in #winehackers if you have any questions or suggestions. The above page actually evolved from discussions on irc. If you do know about Wine packagers on other Linux distributions please forward them this info; we are pretty sure that we missed a few. We didn't forget about the non-Linux OSes but Wine 64bit is at the moment a Linux only feature; patches to change that are of course welcome ;) bye michael
Re: winex11: add support for 32-bit DDBs
I can't see the screenshot well but that's notepad? What display drivers are you using? Roderick On Thu, Apr 15, 2010 at 3:36 AM, Erich Hoover wrote: > I noticed a problem with the icons in Wine when alt+tabbing today. After > doing a regression test it appears that commit > c29cf0591976f96c3adb30c3c3b6db59f4983251 results in pixmaps that do not > always display properly when alt+tabbing (see attached screenshot). > > Erich Hoover > ehoo...@mines.edu >
