Re: msi/tests: Use BOOL type where appropriate (resend)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2667 Your paranoid android. === wvista (32 bit msi) === Timeout === w2008s64 (32 bit msi) === Timeout Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout
Re: [1/3] xmllite: Use buffer offset instead of pointers
Nikolay Sivov nsi...@codeweavers.com writes: On 10/6/2013 19:06, Nikolay Sivov wrote: It's normal to grow destination buffer, in this case all stored pointers will be trashed. This patch uses offsets from start of a buffer instead. Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get? It's compiler warnings, you have several uninitialized or unused variables. Please review your changes carefully. -- Alexandre Julliard julli...@winehq.org
Re: winemac.drv: add fullscreen mode support for Mac OS X 10.7+
Hi, I finally got around to working on support for Cocoa full-screen mode in the Mac driver, based on the work of Kevin Eaves. I've attached a new patch. This patch can only be applied on top of the other Mac driver patches I just submitted to wine-patches. Some changes from Kevin's original, in no particular oder: * I have not used the user32 hack to increase the max tracking size and let windows grow so their non-frame area covers the screen. Instead, the call to SetWindowPos() that results from a WINDOW_FRAME_CHANGED event uses SWP_NOSENDCHANGING for Cocoa-full-screen windows. That prevents any immediate modification of the new window rect to be within the max tracking size. However, some programs (e.g. Guild Wars) end up moving the window again shortly afterward and then it gets constrained. This results in a window that doesn't quite fill the screen, showing a plain background around the edges. This isn't ideal. As previously discussed, this may require a new driver entry point to allow it to override the size limits. (Although I got slapped down for trying to add a similar entry point for some other work.) * Cocoa understandably refuses to minimize a window that's in full-screen mode. So, if Win32-land tries to programmatically minimize a full-screen window, Cocoa just immediately tells it that it's been unminimized. This shouldn't come up much. (One can access a window's system menu using the keyboard to test.) * We can't distinguish the program trying to make a window Win32 full-screen vs. it merely echoing back the frame set by Cocoa full-screen. So, we never consider a window to be in Win32 full-screen mode if it's in Cocoa full-screen mode. That means that the menu and Dock auto-unhide. Many (most?) apps will modify the window style in addition to just setting the frame such that it becomes incompatible with Cocoa full-screen mode. In that case, the window is first taken out of Cocoa full-screen and then put into Win32 full-screen mode. The menu and Dock are properly hidden, but the window went back to its original space, which may not be what the user wants. * I have added the standard menu item for controlling Cocoa full-screen, Enter Full Screen, to the Window menu. Cocoa automatically renames that to Exit Full Screen and back as the window enters and exits full-screen mode. As with other items in the Mac menus, I don't allow keyboard shortcuts that don't include Option among the modifiers. So, I've used Command-Option-Control-F instead of just Command-Control-F. * The menu item and the window widget are properly disabled when the window is disabled. * The maximum tracking size set by the app for the window is respected in full-screen mode. If the app leaves the default max tracking size alone, then the full-screen size is unconstrained (and so fills the screen) even though the Win32 default is slightly too small to allow that. * If the app programmatically changes the window rect while the window is in Cocoa full-screen mode, that change is honored. This may end up looking a bit odd, but is necessary for correctness. Furthermore, the changed rect is maintained as the window exits full-screen mode, which is not what Cocoa would normally do. (Cocoa restores the window to the size and position it had before entering full-screen.) This is necessary when, for example, a game switches from windowed (in Cocoa full-screen mode) to Win32 full-screen. It will often change the window style in such a way that forces it out of Cocoa full-screen and changes its size to fill the screen. We don't want Cocoa negating that size change as it transitions out of Cocoa full-screen mode. Programmatic changes of the window rect that occur during and shortly after the transition into full-screen are not interpreted as setting the frame that should be restored when exiting full-screen mode. Those are probably just responses from Wine and the app to the changes that Cocoa has initiated. * I set NSWindowCollectionBehaviorFullScreenAuxiliary on any windows which don't get NSWindowCollectionBehaviorFullScreenPrimary. I'm not certain that this is right. That flag is not as clearly documented as I would like. My intent is to allow other Wine windows to share the space with a full-screen-primary window. * WS_EX_TOOLWINDOW windows (utility windows, in Cocoa parlance) are not eligible for Cocoa full-screen. This means that they get NSWindowCollectionBehaviorFullScreenAuxiliary as per the previous point, so they can share a space with a full-screen primary window. * I have left out any attempt to reconcile Cocoa full-screen with changes to the display mode which result in the displays being captured. I don't know of an app which does that while leaving its window eligible for Cocoa full-screen, although I haven't tested many yet. I invite everybody who's interested to test and/or review. Cocoa full-screen was introduced
Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
On 8 October 2013 00:27, Stefan Dösinger ste...@codeweavers.com wrote:
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 52eac16..eb8ca7e 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surface
*surface, DWORD location, c
}
}
-if (location == SFLAG_INSRGBTEX
gl_info-supported[EXT_TEXTURE_SRGB_DECODE])
-location = SFLAG_INTEXTURE;
if (surface-flags location)
{
@@ -5671,12 +5669,6 @@ HRESULT surface_load_location(struct wined3d_surface
*surface, DWORD location, c
surface_evict_sysmem(surface);
}
-if (surface-flags (SFLAG_INTEXTURE | SFLAG_INSRGBTEX)
- gl_info-supported[EXT_TEXTURE_SRGB_DECODE])
-{
-surface-flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX);
-}
-
return WINED3D_OK;
}
This change seems good on its own, as far as I can tell all callers
already handle this correctly. I'm less sure about the other changes,
the texture code seems like the right place to handle
EXT_texture_sRGB_decode.
Re: riched20: Set control content in WM_CREATE message
On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote:
+ if (!(editor-styleFlags ES_MULTILINE))
+ {
+len = 0;
+while(textW[len] != '0' textW[len] != '\r' textW[len] != '\n')
+ len++;
+ }
Although this patch has been committed as
e660bf676c111ce20d9e868280094f1c5bb81c79,
I doubt that it works properly. Did you mean '\0' or 0?
Regards,
Akihiro Sagawa
Re: riched20: Set control content in WM_CREATE message
Hi Akihiro,
On 10/08/13 12:51, Akihiro Sagawa wrote:
On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote:
+ if (!(editor-styleFlags ES_MULTILINE))
+ {
+len = 0;
+while(textW[len] != '0' textW[len] != '\r' textW[len] != '\n')
+ len++;
+ }
Although this patch has been committed as
e660bf676c111ce20d9e868280094f1c5bb81c79,
I doubt that it works properly. Did you mean '\0' or 0?
I meant to check for terminating null-character. I'll fix it.
Thanks,
Piotr
Re: [1/3] xmllite: Use buffer offset instead of pointers
On 10/8/2013 10:56, Alexandre Julliard wrote: Nikolay Sivov nsi...@codeweavers.com writes: On 10/6/2013 19:06, Nikolay Sivov wrote: It's normal to grow destination buffer, in this case all stored pointers will be trashed. This patch uses offsets from start of a buffer instead. Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get? It's compiler warnings, you have several uninitialized or unused variables. Please review your changes carefully. Okay, will do. Strangely I see no warnings here, but that's probably a different gcc version.
Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-08 12:06, schrieb Henri Verbeet:
On 8 October 2013 00:27, Stefan Dösinger ste...@codeweavers.com
wrote:
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++
b/dlls/wined3d/surface.c @@ -5608,8 +5608,6 @@ HRESULT
surface_load_location(struct wined3d_surface *surface, DWORD
location, c } }
-if (location == SFLAG_INSRGBTEX
gl_info-supported[EXT_TEXTURE_SRGB_DECODE]) -location =
SFLAG_INTEXTURE;
if (surface-flags location) { @@ -5671,12 +5669,6 @@ HRESULT
surface_load_location(struct wined3d_surface *surface, DWORD
location, c surface_evict_sysmem(surface); }
-if (surface-flags (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) -
gl_info-supported[EXT_TEXTURE_SRGB_DECODE]) -{ -
surface-flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); -} -
return WINED3D_OK; }
This change seems good on its own, as far as I can tell all
callers already handle this correctly.
Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode
is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If
the application later calls PreLoad manually, texture2d_preload is
called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to
load the srgb copy. It correctly uses the rgb texture structure and
binds the rgb GL texture, but still passes srgb=true to
surface_load(), which results in SFLAG_INSRGBTEX being passed to
surface_load_location, even though we want to load the RGB copy.
I'll see if I can simplify the sRGB_decode handling while still
keeping it in the texture.
Patches 4 and 5 should apply without this one by the way.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSU/AfAAoJEN0/YqbEcdMwIP8P/iJUb9d3dfTQgdDAYNSx0fFc
wp7tJZSZKDNlSLz8oTNx7k2Lmcv7ZSInce+R1oaGxS7QjkhxD7U25CdnvgaXV+Oy
IInOFuauZ7m6zO+FfBbHd9ujM1pC1Mi7BtsE59LNypJT9ym6iqe2MLocLUjDCfbL
koro3I3rzjkMb3XVUQapMevobYBr0jfl3G3q7zirrVuh1fYnL3a1Ge4ckIGsRneL
98ZjmcQyfT8lo9zxtwXPTOR23j1oLnJDNWhn63he1sX6Vg7XQvPZwszXwbN30Jof
CjbrTzBmaKq/yY4jXnffu84tDygvWFr0a9sklX7qtaGd4cNBaiSscR6gBAgvZQdI
1533llMChhOqIUBrS5i8d3t24DLdAzd6PiD4LBCjJXzqfTiqWp3JjChR9FUvq+P1
G5gEldxF+MHPXKhZgpq1MoAy13NDYAFNT/EZSgIH/yRGcm9qVTnI98A6gFZnvel4
DQ3p05mMN4dSvGsQJt/l42k8I5IT1nYqetE1ybZd/45LgHKyjYc80z8lt6f0fhrS
j9KtY3Pu6Ks8hIjsIrnVPX7SSbiaNzytEwTpECXsmnB6T2Co+d5YOYzKmWLIqOqL
ZSTBkStiBzfxi+2KWlnfUHzWmOthaPo98ZRsiwtaux9W+8xvIDMnWD5x51EPlcjt
ca93bMIW9i8aPNOOMeKb
=dp6t
-END PGP SIGNATURE-
Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
On 8 October 2013 13:44, Stefan Dösinger stefandoesin...@gmail.com wrote: Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If the application later calls PreLoad manually, texture2d_preload is called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to load the srgb copy. It correctly uses the rgb texture structure and binds the rgb GL texture, but still passes srgb=true to surface_load(), which results in SFLAG_INSRGBTEX being passed to surface_load_location, even though we want to load the RGB copy. Right. It should be pretty easy to fix that by taking EXT_TEXTURE_SRGB_DECODE into account in texture_srgb_mode() though.
Re: (try 6)[3/5] imm32: use thread data from target HWND
Aric Stewart a...@codeweavers.com writes:
@@ -1597,7 +1612,9 @@ BOOL WINAPI ImmGetConversionStatus(
HWND WINAPI ImmGetDefaultIMEWnd(HWND hWnd)
{
HWND ret;
-IMMThreadData* thread_data = IMM_GetThreadData(0);
+IMMThreadData* thread_data = IMM_GetThreadDataForWindow(hWnd);
+if (!thread_data)
+return NULL;
if (thread_data-hwndDefault == NULL)
thread_data-hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW,
szwIME, NULL, WS_POPUP, 0, 0, 1, 1, 0, 0, 0, 0);
It doesn't seem right to create the default window from a different
thread.
--
Alexandre Julliard
julli...@winehq.org
Wrong status of gdi32
I found this page http://www.nirsoft.net/dll_information/windows8/gdi32_dll.html shows that gdi32 dll has more than 800 functions,but the spec file has only 500 .
Re: gdi32/tests: Skip linked font like SimSun-ExtB in fixed-pitch font selection.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2669 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Timeout Failure running script in VM: network read timed out
RE: binfmt support
From: xantare...@hotmail.com To: hverb...@gmail.com Subject: RE: binfmt support Date: Mon, 7 Oct 2013 11:47:05 + Date: Mon, 7 Oct 2013 12:23:30 +0200 Subject: Re: binfmt support From: hverb...@gmail.com To: xantare...@hotmail.com CC: wine-devel@winehq.org On 7 October 2013 12:06, xantares 09 xantare...@hotmail.com wrote: ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf6b376 What do you think ? Ignoring the discussion if we want this or not for the moment, I'd guess this would break as soon as you pass something other than /usr for --prefix to configure. Yes, It'll only work when prefix=/usr, which is always what happens when building packaging. This is what we want ; we still want to honor the prefix var. x.
Re: Wrong status of gdi32
Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa matyapir...@gmail.com wrote: I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 .
Re: Wrong status of gdi32
On Tue, Oct 8, 2013 at 11:54 AM, C.W. Betts computer...@hotmail.com wrote: Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa matyapir...@gmail.com wrote: I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 . That info is from the windows 8 dll, not wine's. Wine doesn't implement the full win32 API, only what is needed to run applications. If you've got an application that doesn't run because of a missing gdi32 function, please report it to bugzilla: https://bugs.winehq.org -- -Austin
Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.
Hello, this patch is in pending status, is there any way I can improve it? IMO there is no way to 'correctly' implement OpenInputDesktop before implementing SwitchDesktop, as far as SwitchDesktop is a stub, it is safe to assume that OpenInputDesktop will always return either NULL or Winsta0/Default, that is what the patch does and what the tests in [PATCH 3/5] shows.. It is not trivial to implement SwitchDesktop, also I don't know any real world app needing SwitchDesktop except some virtual desktop manager, so I'm not sure it is worth to spend time on implementing SwitchDesktop. However, OpenInputDesktop is needed by multiple apps (TeamViewer, QQ International, Inspect tool from Windows Platform SDK as bug 12067), is it acceptable to submit such a 'better stub' to Wine and leaving SwitchDesktop as a stub? Any comment is great appreciated! On Tue, Oct 8, 2013 at 11:41 AM, Qian Hong qh...@codeweavers.com wrote: Fixed http://bugs.winehq.org/show_bug.cgi?id=12067 , let QQ users happy :) --- dlls/user32/tests/winstation.c | 22 -- dlls/user32/winstation.c | 22 +++--- 2 files changed, 19 insertions(+), 25 deletions(-) -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] d3dx9: Move object initialization into a separate function.
Hi Rico, 2013/10/8 Rico Schüller kgbric...@web.de: Hi, this moves the object initialization into a separate function, so it could be used for strings and resources. It also removes the STATE_TYPE as we could distinguish the types at the object level. 1. When an object has a destination, it points to another shader variable. This was state ST_PARAMETER. 2. If a variable has something in data, it is fxlc, shader (preshader) or a string. This was state ST_CONSTANT and ST_FXLC. 3. If it has both (destination and data), it points to an array of shader variables. The name is in the destination, the index could be calculated with the data. This will be added in a later patch. There's still the issue of distinguishing between ST_CONSTANT and ST_FXLC, checking object_id and type might cover that though. Also saving the destination parameter in the object gains some speed when we need to access the variable as we don't need to run get_parameter_by_name() each time we need the variable ... I'm not sure storing additional info into the objects is the right thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%29.aspx. Notice that GetPassDesc() doesn't return the shader data if the object was created with the flag. What I've been thinking is that it simply can't because the original shader data, stored in an object, were freed after parsing. While nothing forces us to do the same (except probably avoiding to use more memory than strictly necessary) I think it's better not to put additional stuff into the objects or generally assume that the objects are still available after parsing. That means creating the shaders and the strings at parse time or right after that and storing any additional required information (e.g. preshader) in the parameter. So, directly storing the referenced parameter is a good idea but I'd prefer that pointer to be in d3dx_parameter. Cheers Rico --- dlls/d3dx9_36/effect.c | 98 ++ 1 Datei geändert, 34 Zeilen hinzugefügt(+), 64 Zeilen entfernt(-) Cheers, Matteo
Re: ws2_32/tests: Use BOOL type where appropriate
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2674 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (bc): unexpectedly at the OOB mark: 0 sock: unhandled exception c005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (2c8): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:509: Test failed: oob_server (8a4): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (8a4): unexpectedly at the OOB mark: 0 === w864 (32 bit sock) === sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain:
