profile.c (kernel32): API broken
Just a reminder to everyone involved with profile.c: I have watched the git log of the somewhat recent changes to kernel32/profile.c. The profile API does not work that way. The current situation is even worse than before, when the undocumented empty string section and empty keys were not implemented at all. The current situation leads to consistent INI file corruption when the applications use the undocumented empty string section and empty keys. I tried to explain how the API works under Windows many times. This is another casual attempt at giving you a reality check. If you are interested, you can contact me for further details, or look at the testcases in my last patch (search for profile.c / Claudio Fontana). A good fix in profile.c is difficult because of the unfortunate use of the empty string as sentinel in the implementation. Probably rewriting the module would be a better idea. In short again: empty string section is just another (valid) section under Windows. Depending on the windows version the section is represented in the saved file after []\r\n at the beginning of the INI file or with no header at all. The empty key can be requested and saved in a named section. The empty key in a named section is just another (valid) key under Windows. The empty key value is represented in the saved file after the header of the appropriate section in this way, just as logic would suggest: [header] =value Those empty string sections and empty string keys should be found when querying using the profile API. Currently it does not happen, leading to INI corruption (multiple repeated empty sections' values, none of which are found by the API). Regards, Claudio Fontana
Re: [3/8] WineD3D: Get rid of a version check
2009/8/5 Stefan Dösinger ste...@codeweavers.com:
+void fixup_caps(WINED3DCAPS *pWineCaps)
+{
+/* D3D8 doesn't support SM 2.0 or higher, so clamp to 1.x */
+if(pWineCaps-PixelShaderVersion D3DPS_VERSION(1,4)){
+pWineCaps-PixelShaderVersion = D3DPS_VERSION(1,4);
+}
+if(pWineCaps-VertexShaderVersion D3DVS_VERSION(1,1)){
+pWineCaps-VertexShaderVersion = D3DVS_VERSION(1,1);
+}
+pWineCaps-MaxVertexShaderConst = min(D3D8_MAX_VERTEX_SHADER_CONSTANTF,
pWineCaps-MaxVertexShaderConst);
+
+pWineCaps-StencilCaps = ~WINED3DSTENCILCAPS_TWOSIDED;
+}
Please use proper white space and naming conventions. I could live
with the missing space between the control statement and the brace, if
you really prefer that, but at least put *some* sort of whitespace
between the closing brace and the accolade. And pWineCaps is just
horrible.
Re: [7/8] WineD3D: Catch invalid getDC calls in d3d9
I don't feel very strong about this, but perhaps this should be handled by the format info table (in combination with the create flag).
Re: [4/8] WineD3D: Set the default psizemin in d3d8, avoid the version check
I think the create flags would be more robust here.
Re: profile.c (kernel32): API broken
Claudio Fontana wrote: Just a reminder to everyone involved with profile.c: I have watched the git log of the somewhat recent changes to kernel32/profile.c. The profile API does not work that way. The current situation is even worse than before, when the undocumented empty string section and empty keys were not implemented at all. The current situation leads to consistent INI file corruption when the applications use the undocumented empty string section and empty keys. I tried to explain how the API works under Windows many times. This is another casual attempt at giving you a reality check. If you are interested, you can contact me for further details, or look at the testcases in my last patch (search for profile.c / Claudio Fontana). Found your patch from 2006 and tested on some Windows boxes. The WritePrivateProfileStringA crashes on Windows 2003 for both added tests. Windows 98 doesn't crash btw. Both your fixes to the implementation seem to be for reading the ini file. Could you rewrite the test case so it succeeds on all platforms? So, for example creating the ini file with the empty section/key 'manually' and then trying to read (again on several platforms). -- Cheers, Paul.
Re: [6/8] WineD3D: Return a different success value if D3D is not available
Aside from the fact that you can't know WineDirect3DCreate() failed because of a lack of OpenGL without looking at its implementation, I liked the create flags approach better.
Re: [Bug 19522] Team Fortress 2 (TF2) missing menu fonts
Vitaliy Margolen wine-de...@kievinfo.com writes: --- Comment #3 from Alexandre Julliard julliard at winehq.org 2009-08-04 13:19:16 --- Please don't suggest that people use the --enable-maintainer-mode flag, that's not meant for normal users. Then how can we be sure user have all requirements installed? --verbose doesn't complain about everything which makes it kind of useless. It does complain about everything that is considered important. If there are more things that you think should have complaints, please report them. Maintainer mode adds checks for things like fontforge and icotool that matter only to myself and to people working on fonts or icons; they are irrelevant for end users. Asking users to enable maintainer mode is only going to cause trouble for them. -- Alexandre Julliard julli...@winehq.org
Re: [7/8] WineD3D: Catch invalid getDC calls in d3d9
Am Thursday 06 August 2009 09:35:23 schrieb Henri Verbeet: I don't feel very strong about this, but perhaps this should be handled by the format info table (in combination with the create flag). I don Which format info table? This is d3d9, not wined3d - it only has a d3dformat_from_wined3dformat() and vice versa, not the full wined3d format table. Or do you prefer a behavior flag here as well?
Re: [6/8] WineD3D: Return a different success value if D3D is not available
Am Thursday 06 August 2009 09:35:12 schrieb Henri Verbeet: Aside from the fact that you can't know WineDirect3DCreate() failed because of a lack of OpenGL without looking at its implementation, I liked the create flags approach better. Well, the WINED3DOK_NO3D is intended to say you got your d3d object, but it will only do 2D drawing for you, and then its up to the client to accept this or not(Although I just see I forgot to release the returned object in this case). I don't see the problem. I dislike create flags as much as dxVersion checks, and we should handle as much as possible without them. I feel strongly against using a create flag in patch 4. I just think passing in a flag to call X and call Y's behavior will miraculously change is ugly, although sometimes we can't avoid it. The only places where I think we really need a create flag: * Fixed buffer declarations * D3D7 VB conversion / no conversion * device vs surface palette * and the COM priv data addref or no addref, although maybe there's a way to add a release() in ddraw * the surface pitch alignment That's quite a lot of them already
Re: profile.c (kernel32): API broken
Claudio Fontana wrote: On Thu, Aug 6, 2009 at 9:38 AM, Paul Vrienspaul.vriens.w...@gmail.com wrote: Claudio Fontana wrote: Just a reminder to everyone involved with profile.c: I have watched the git log of the somewhat recent changes to kernel32/profile.c. The profile API does not work that way. The current situation is even worse than before, when the undocumented empty string section and empty keys were not implemented at all. The current situation leads to consistent INI file corruption when the applications use the undocumented empty string section and empty keys. I tried to explain how the API works under Windows many times. This is another casual attempt at giving you a reality check. If you are interested, you can contact me for further details, or look at the testcases in my last patch (search for profile.c / Claudio Fontana). Found your patch from 2006 and tested on some Windows boxes. The testcases are more interesting than the functionality of the patch itself. I did the patch just to bring an application into running, it is not a stable solution. The testcases are the interesting thing. The WritePrivateProfileStringA crashes on Windows 2003 for both added tests. Windows 98 doesn't crash btw. Both your fixes to the implementation seem to be for reading the ini file. The writing is affected too. Could you rewrite the test case so it succeeds on all platforms? I will try as soon as I get some time. However, I have no Windows 2003 to test on. So, for example creating the ini file with the empty section/key 'manually' and then trying to read (again on several platforms). Does Windows 2003 crash on _just_ the testcase? Or did you apply the whole patch? Also, the patch might not be compatible with the latest changes in profile.c. I'll try to make the patch a little bit better, but in the meantime it would be interesting to know if Windows 2003 behaves differently in this situation from the API point of view. Can you try just the testcase on Windows 2003 (with no other changes added besides the new tests)? I only added the test cases (what else for a Windows box?). Both crash on Windows 2003. I will check later (if time permits) with that newer patch you mentioned: http://bugs2.winehq.org/attachment.cgi?id=6495 -- Cheers, Paul.
Re: gdi32: Fix the type of a few return values.
Hello Andrew, Andrew Nguyen wrote: It does not make sense to return a boolean for a pointer type. diff --git a/dlls/gdi32/opengl.c b/dlls/gdi32/opengl.c index 022fc2c..204fc2b 100644 --- a/dlls/gdi32/opengl.c +++ b/dlls/gdi32/opengl.c @@ -168,7 +168,7 @@ static HDC WINAPI wglGetPbufferDCARB(void *pbuffer) TRACE((%p)\n, pbuffer); -if (!dc) return FALSE; +if (!dc) return 0; /* The display driver has to do the rest of the work because * we need access to lowlevel datatypes which we can't access here @@ -338,7 +338,7 @@ PROC WINAPI wglGetProcAddress(LPCSTR func) /* Retrieve the global hDC to get access to the driver. */ dc = OPENGL_GetDefaultDC(); -if (!dc) return FALSE; +if (!dc) return NULL; if (!dc-funcs-pwglGetProcAddress) FIXME( :stub\n); else ret = dc-funcs-pwglGetProcAddress(func); any reason why you use both 0 and NULL to represent a null pointer? For consistency sake just pick one. thanks bye michael
Re: [6/8] WineD3D: Return a different success value if D3D is not available
2009/8/6 Stefan Dösinger ste...@codeweavers.com: Am Thursday 06 August 2009 09:35:12 schrieb Henri Verbeet: Aside from the fact that you can't know WineDirect3DCreate() failed because of a lack of OpenGL without looking at its implementation, I liked the create flags approach better. Well, the WINED3DOK_NO3D is intended to say you got your d3d object, but it will only do 2D drawing for you, and then its up to the client to accept this or not(Although I just see I forgot to release the returned object in this case). I don't see the problem. The problem is that wined3d without 3D capabilities really doesn't make a whole lot of sense for anything except ddraw with the gdi renderer. Arguably that code path shouldn't even depend on wined3d. A wined3d object without 3D capabilities is the exception, and should be handled as such. I dislike create flags as much as dxVersion checks, and we should handle as much as possible without them. I feel strongly against using a create flag in patch 4. I just think passing in a flag to call X and call Y's behavior will miraculously change is ugly, although sometimes we can't avoid it. If done properly, miracles have nothing to do with it... The problem with patch 4 is that you really want the initial value to change, but instead you change it afterwards, and hope you caught all the cases. Fortunately the tests should help a bit there, but I don't think it's a good principle if you can easily avoid it. Another advantage of the flags is that you have a reasonably centralised overview of differences between the different wined3d client libraries.
Re: [7/8] WineD3D: Catch invalid getDC calls in d3d9
2009/8/6 Stefan Dösinger ste...@codeweavers.com: Am Thursday 06 August 2009 09:35:23 schrieb Henri Verbeet: I don't feel very strong about this, but perhaps this should be handled by the format info table (in combination with the create flag). I don Which format info table? This is d3d9, not wined3d - it only has a d3dformat_from_wined3dformat() and vice versa, not the full wined3d format table. Or do you prefer a behavior flag here as well? As mentioned in the bit you quoted.
Re: [6/8] WineD3D: Return a different success value if D3D is not available
Am Thursday 06 August 2009 11:54:58 schrieb Henri Verbeet: If done properly, miracles have nothing to do with it... The problem with patch 4 is that you really want the initial value to change, but instead you change it afterwards, and hope you caught all the cases. Fortunately the tests should help a bit there, but I don't think it's a good principle if you can easily avoid it. The approach doesn't scale though. Luckily we have very few different default values(that are known currently). We'd probably want some other system, like providing a template stateblock, but that seems like an overkill as well. Another advantage of the flags is that you have a reasonably centralised overview of differences between the different wined3d client libraries. Not really, we have a number of cases in ddraw already where the default value is overwritten(e.g. depth test at device creation), and there are many other differences beyond defaults.
Re: [6/8] WineD3D: Return a different success value if D3D is not available
2009/8/6 Stefan Dösinger ste...@codeweavers.com: Am Thursday 06 August 2009 11:54:58 schrieb Henri Verbeet: Another advantage of the flags is that you have a reasonably centralised overview of differences between the different wined3d client libraries. Not really, we have a number of cases in ddraw already where the default value is overwritten(e.g. depth test at device creation), and there are many other differences beyond defaults. I'm not sure we should take ddraw as an example of how we prefer to do things.
Re: mshtml: Implement IHTMLStyle4 get/put textOverflow
Forget this patch, missed the todo_wine
Alistair Leslie-Hughes leslie_alist...@hotmail.com wrote in message
news:4a7aa9a2.9060...@hotmail.com...
Hi,
Changelog:
mshtml: Implement IHTMLStyle4 get/put textOverflow
Best Regards
Alistair Leslie-Hughes
From 4f121dd9918252af3f1a46eeb1c1826a4830d0a8 Mon Sep 17 00:00:00 2001
From: Alistair Leslie-Hughes leslie_alist...@hotmail.com
Date: Wed, 18 Feb 2009 22:43:39 +1100
Subject: [PATCH] Implement IHTMLStyle4 get/put textOverflow
To: wine-patches wine-patc...@winehq.org
---
dlls/mshtml/htmlstyle.c |3 +++
dlls/mshtml/htmlstyle.h |1 +
dlls/mshtml/htmlstyle3.c | 18 ++
dlls/mshtml/tests/dom.c | 30 ++
4 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/dlls/mshtml/htmlstyle.c b/dlls/mshtml/htmlstyle.c
index f036077..82ddf58 100644
--- a/dlls/mshtml/htmlstyle.c
+++ b/dlls/mshtml/htmlstyle.c
@@ -111,6 +111,8 @@ static const WCHAR attrTextAlign[] =
{'t','e','x','t','-','a','l','i','g','n',0};
static const WCHAR attrTextDecoration[] =
{'t','e','x','t','-','d','e','c','o','r','a','t','i','o','n',0};
+static const WCHAR attrTextOverflow[] =
+{'t','e','x','t','-','o','v','e','r','f','l','o','w',0};
static const WCHAR attrTop[] =
{'t','o','p',0};
static const WCHAR attrVerticalAlign[] =
@@ -166,6 +168,7 @@ static const struct{
{attrPosition, DISPID_IHTMLSTYLE2_POSITION},
{attrTextAlign,DISPID_IHTMLSTYLE_TEXTALIGN},
{attrTextDecoration, DISPID_IHTMLSTYLE_TEXTDECORATION},
+{attrTextOverflow, DISPID_IHTMLSTYLE4_TEXTOVERFLOW},
{attrTop, DISPID_IHTMLSTYLE_TOP},
{attrVerticalAlign,DISPID_IHTMLSTYLE_VERTICALALIGN},
{attrVisibility, DISPID_IHTMLSTYLE_VISIBILITY},
diff --git a/dlls/mshtml/htmlstyle.h b/dlls/mshtml/htmlstyle.h
index 307824e..b6bdcab 100644
--- a/dlls/mshtml/htmlstyle.h
+++ b/dlls/mshtml/htmlstyle.h
@@ -73,6 +73,7 @@ typedef enum {
STYLEID_POSITION,
STYLEID_TEXT_ALIGN,
STYLEID_TEXT_DECORATION,
+STYLEID_TEXT_OVERFLOW,
STYLEID_TOP,
STYLEID_VERTICAL_ALIGN,
STYLEID_VISIBILITY,
diff --git a/dlls/mshtml/htmlstyle3.c b/dlls/mshtml/htmlstyle3.c
index 505e91e..84b914b 100644
--- a/dlls/mshtml/htmlstyle3.c
+++ b/dlls/mshtml/htmlstyle3.c
@@ -399,15 +399,25 @@ static HRESULT WINAPI HTMLStyle4_Invoke(IHTMLStyle4
*iface, DISPID dispIdMember,
static HRESULT WINAPI HTMLStyle4_put_textOverflow(IHTMLStyle4 *iface, BSTR
v)
{
HTMLStyle *This = HTMLSTYLE4_THIS(iface);
-FIXME((%p)-(%s)\n, This, debugstr_w(v));
-return E_NOTIMPL;
+static const WCHAR styleEllipsis[] =
{'e','l','l','i','p','s','i','s',0};
+static const WCHAR styleClip[] = {'c','l','i','p',0};
+
+TRACE((%p)-(%s)\n, This, debugstr_w(v));
+
+/* textOverflow can only be one of the following */
+if(!v || strcmpiW(styleEllipsis, v) == 0|| strcmpiW(styleClip, v)
== 0)
+{
+return set_nsstyle_attr(This-nsstyle, STYLEID_TEXT_OVERFLOW, v,
0);
+}
+
+return E_INVALIDARG;
}
static HRESULT WINAPI HTMLStyle4_get_textOverflow(IHTMLStyle4 *iface, BSTR
*p)
{
HTMLStyle *This = HTMLSTYLE4_THIS(iface);
-FIXME((%p)-(%p)\n, This, p);
-return E_NOTIMPL;
+TRACE((%p)-(%p)\n, This, p);
+return get_nsstyle_attr(This-nsstyle, STYLEID_TEXT_OVERFLOW, p);
}
static HRESULT WINAPI HTMLStyle4_put_minHeight(IHTMLStyle4 *iface, VARIANT
v)
diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c
index 4846848..1d283e4 100644
--- a/dlls/mshtml/tests/dom.c
+++ b/dlls/mshtml/tests/dom.c
@@ -2654,6 +2654,8 @@ static void test_style4(IHTMLStyle4 *style4)
HRESULT hres;
VARIANT v;
VARIANT vdefault;
+BSTR sdefault;
+BSTR str;
hres = IHTMLStyle4_get_minHeight(style4, vdefault);
ok(hres == S_OK, get_minHeight failed: %08x\n, hres);
@@ -2672,6 +2674,34 @@ static void test_style4(IHTMLStyle4 *style4)
hres = IHTMLStyle4_put_minHeight(style4, vdefault);
ok(hres == S_OK, put_minHeight failed: %08x\n, hres);
VariantClear(vdefault);
+
+/* textOverflow */
+hres = IHTMLStyle4_get_textOverflow(style4, sdefault);
+ok(hres == S_OK, get_minHeight failed: %08x\n, hres);
+
+str = a2bstr(invalid);
+hres = IHTMLStyle4_put_textOverflow(style4, str);
+ok(hres == E_INVALIDARG, put_textOverflow passed: %08x\n, hres);
+SysFreeString(str);
+
+str = a2bstr(ellipsis);
+hres = IHTMLStyle4_put_textOverflow(style4, str);
+ok(hres == S_OK, put_textOverflow failed: %08x\n, hres);
+SysFreeString(str);
+
+str = a2bstr(clip);
+hres = IHTMLStyle4_put_textOverflow(style4, str);
+ok(hres == S_OK, put_textOverflow failed: %08x\n, hres);
+SysFreeString(str);
+
+hres = IHTMLStyle4_get_textOverflow(style4, str);
+ok(hres == S_OK, get_textOverflow failed: %08x\n, hres);
+todo_wine ok( !strcmp_wa(str,
Re: Latency as of yesterday
Current Ubuntu sound bugs relating to wine OSS 409395. ALSA 407970 -I got this response on the Ubuntu list-- This is probably due to a libasound2-plugins and pulseaudio/rtkit skew; the latest libasound2-plugins needs at least pulseaudio 1:0.9.16~test3 and rtkit 0.3. Karmic has an older version of pulseaudio (1:0.9.15) at the moment. -- After further checking I determined that the current kernel changes are supposed to make the regular kernel capable of running at real-time (right now, for outgoing sound only) by activating a switch on the regular kernel. This functionality, of course, needs pulseaudio. Despite the optimism expressed above, pulseaudio 1:0.9016~test4 and the latest rtkit did not solve my problem. Wine still has no functioning sound. Stay tuned.
Re: [6/8] WineD3D: Return a different success value if D3D is not available
Am Thursday 06 August 2009 12:26:20 schrieb Henri Verbeet: Not really, we have a number of cases in ddraw already where the default value is overwritten(e.g. depth test at device creation), and there are many other differences beyond defaults. I'm not sure we should take ddraw as an example of how we prefer to do things. Maybe, maybe not, but that doesn't change the fact that d3d7 has most of the differences(with just d3d8+d3d9 all we'd have to change is the pointsizemin default value), and it doesn't make behavior flags scale better. (Of course adding a full sized system like a default stateblock for each problem doesn't scale either) That's why I still think we should use behavior flags as a last resort, and use other problem specific ways where possible and reasonable. (an example for what's not reasonable: Clone the entire private data code in ddraw to avoid the AddRef - I clearly prefer a behavior flag for that)
Re: wine.inf: Add the HKCU\Volatile Environment\APPDATA value.
Andrew Nguyen arethus...@gmail.com writes: The VirtuaGirl installer explicitly queries for the APPDATA value under HKCU\Volatile Environment. This most likely needs to be a volatile key created at startup. -- Alexandre Julliard julli...@winehq.org
Re: [3/3] advapi32: Add tests for LsaLookupNames2.
Hans Leidekker h...@codeweavers.com writes: diff --git a/dlls/advapi32/tests/lsa.c b/dlls/advapi32/tests/lsa.c index e69e4e1..991b06b 100644 --- a/dlls/advapi32/tests/lsa.c +++ b/dlls/advapi32/tests/lsa.c It doesn't work here: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so lsa.c touch lsa.ok lsa.c:314: Test failed: expected 0, got 0x00640072 make[2]: *** [lsa.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: [6/8] WineD3D: Return a different success value if D3D is not available
2009/8/6 Stefan Dösinger ste...@codeweavers.com: That's why I still think we should use behavior flags as a last resort, and use other problem specific ways where possible and reasonable. (an example for what's not reasonable: Clone the entire private data code in ddraw to avoid the AddRef - I clearly prefer a behavior flag for that) Actually, if you wanted to avoid create flags, handling that AddRef in ddraw would be less ugly than what patch 4 does. (And no, you don't need to clone resource.c for that, just return the flags from resource_get_private_data() and its callers, and immediately call Release() in the appropriate case in ddraw.)
Re: Begin Wine Development
Alexandros Dermenakis wrote: Hi to everyone, I'm a software developer interested in contributing to wine. Can you guide a bit with the process? How do you become a member and get a account to submit code to the git repository? How do you get tickets with your tasks? Thanks Hey Alexandros, First of all, welcome! We need more people like you, and we especially want to know if we're doing anything to scare you away. I don't think we are, but you can never be sure since most people won't tell you if they gave up when they never really got properly started. I'm keenly interested in cleaning up the WineHQ Developer web pages so they're more newcomer friendly, so if you were at all confused by anything or couldn't find something that's important please give me a poke and I'll fix it ;) Thanks, Scott Ritchie
Re: comctl32: Changed the assembly and manifest file names to mixed-case as in Windows
Paul Chitescu pa...@voip.null.ro writes: Changelog: comctl32: Changed the assembly and manifest file names to mixed-case as in Windows The MSDN says that several tools handle assembly names as case sensitive. Furthermore, trying to open the manifest file with wrong case can fail or take a long time on case sensitive filesystems (pretty much all used with wine). That's OK for the assembly name, but the filenames on Vista are all lowercase too, I'm not sure we want to change that. -- Alexandre Julliard julli...@winehq.org
Re: configure can't find libgsm development files, but they are installed
On Wed, 05 Aug 2009 19:52:15 +0400 Nikolay Sivov bungleh...@gmail.com wrote: Rosanne DiMesio wrote: Since yesterday, configure has been giving me a libgsm development files not found warning even though they are installed on my system. This is on openSUSE 11.1, 32 bit. Is anyone else seeing this, or is something borked on my system? (Any hints as to where I might look would be appreciated.) Hi, Rosanne. Installing libgsm1-dev version 1.0.12-1 from Debian 5.0 repo works for me. config.log snip: --- configure:5894: checking gsm.h usability configure:5911: gcc -c -g -O2 conftest.c 5 configure:5918: $? = 0 configure:5932: result: yes configure:5936: checking gsm.h presence configure:5951: gcc -E conftest.c configure:5958: $? = 0 configure:5972: result: yes configure:6005: checking for gsm.h configure:6014: result: yes --- On my system, gsm.h was installed in /usr/include/gsm, but the log showed configure failed to find it. The location turned out to be the problem; putting a symlink in /usr/include solved it. Is this a Wine bug, or an openSUSE bug? -- Rosanne DiMesio dime...@earthlink.net
Re: configure can't find libgsm development files, but they are installed
Rosanne DiMesio wrote: On Wed, 05 Aug 2009 19:52:15 +0400 Nikolay Sivov bungleh...@gmail.com wrote: Rosanne DiMesio wrote: Since yesterday, configure has been giving me a libgsm development files not found warning even though they are installed on my system. This is on openSUSE 11.1, 32 bit. Is anyone else seeing this, or is something borked on my system? (Any hints as to where I might look would be appreciated.) Hi, Rosanne. Installing libgsm1-dev version 1.0.12-1 from Debian 5.0 repo works for me. config.log snip: --- configure:5894: checking gsm.h usability configure:5911: gcc -c -g -O2 conftest.c 5 configure:5918: $? = 0 configure:5932: result: yes configure:5936: checking gsm.h presence configure:5951: gcc -E conftest.c configure:5958: $? = 0 configure:5972: result: yes configure:6005: checking for gsm.h configure:6014: result: yes --- On my system, gsm.h was installed in /usr/include/gsm, but the log showed configure failed to find it. The location turned out to be the problem; putting a symlink in /usr/include solved it. Is this a Wine bug, or an openSUSE bug? Now it's Wine. I don't know any guidelines about proper place for headers so could be a problem with some packages too. Maarten already sent a patch with additional configure check: http://www.winehq.org/pipermail/wine-patches/2009-August/076705.html
Re: kernel32/nls/winerror: Add Russian translation
Vladimir Pankratov script...@mail.ru wrote: Added Russian translation. Changed files: dlls/kernel32/nls/winerror_rus.mc dlls/kernel32/Makefile.in What's the point in resending the same version of the patch again and again without even answering the questions, or addressing the pointed out problems? Again, this is not a translation. -- Dmitry.
Re: kernel32: Revise SetThreadIdealProcessor to return success.
Andrew Nguyen arethus...@gmail.com writes: The image deblurring tool in bug 19548 tries to use SetThreadIdealProcessor on multi-core systems and checks the result of the call, which causes the application to fail. Simply reporting success in this case allows the application to run, and is perfectly harmless. It breaks the tests. -- Alexandre Julliard julli...@winehq.org
Re: kernel32/nls/winerror: Add Russian translation
2009/8/6 Vladimir Pankratov script...@mail.ru: Hello all. Added Russian translation. Changed files: dlls/kernel32/nls/winerror_rus.mc dlls/kernel32/Makefile.in Thanks. Message id 1221 is missing. File changed/created is winerr_rus.mc, not winerror_rus.mc BTW
Re: kernel32/nls/winerror: Add Russian translation
2009/8/6 Frédéric Delanoy frederic.dela...@gmail.com: 2009/8/6 Vladimir Pankratov script...@mail.ru: Hello all. Added Russian translation. Changed files: dlls/kernel32/nls/winerror_rus.mc dlls/kernel32/Makefile.in Thanks. Message id 1221 is missing. File changed/created is winerr_rus.mc, not winerror_rus.mc BTW Typo: should read 2221 instead
Re: [6/8] WineD3D: Return a different success value if D3D is not available
Am Thursday 06 August 2009 14:08:20 schrieb Henri Verbeet: 2009/8/6 Stefan Dösinger ste...@codeweavers.com: That's why I still think we should use behavior flags as a last resort, and use other problem specific ways where possible and reasonable. (an example for what's not reasonable: Clone the entire private data code in ddraw to avoid the AddRef - I clearly prefer a behavior flag for that) Actually, if you wanted to avoid create flags, handling that AddRef in ddraw would be less ugly than what patch 4 does. (And no, you don't need to clone resource.c for that, just return the flags from resource_get_private_data() and its callers, and immediately call Release() in the appropriate case in ddraw.) True, that sounds like an idea. I still don't see the problem with the SetRenderState(or any other state set call) though. For the app CreateDevice and Reset are atomic calls. We have full control over the wined3d device. If wined3d's setRenderState suddenly gets any new side effects a SetRenderState in CreateDevice is a pretty small concern. WineD3D will not start recording a stateblock after creation(in which case SetRenderState DOES have side effects¹). I don't see in which situation it would matter that the WineD3DDevice initial state is different from the state we return it to the app. All the app bothers about is the D3D8Device's initial state(or reset state), and for that the outcome is the same. Thus I am more worried about the number of create flags getting out of control than a SetRenderState doing something unintended. ¹: This is why I need a create flag for SetRenderTarget: If a stateblock is being recorded, I can neither update the viewport from d3d8/d3d9, nor attempt to restore the old viewport in ddraw - the change would go into the recorded stateblock, not the initial one.
Re: [1/2] shdocvw: Added support for IAdviseSink (resend)
Hi,
Could I get some feedback on this patch please?
Best Regards
Alistair Leslie-Hughes
Alistair Leslie-Hughes wrote:
Hi,
Changelog:
shdocvw: Added support for IAdviseSink
Best Regards
Alistair Leslie-Hughes
From 9925900c771af32a1dfb2567d8354e888949c352 Mon Sep 17 00:00:00 2001
From: Alistair Leslie-Hughes leslie_alist...@hotmail.com
Date: Fri, 31 Jul 2009 20:40:10 +1000
Subject: [PATCH] Partial support for IAdviseSink
To: wine-patches wine-patc...@winehq.org
---
dlls/shdocvw/oleobject.c| 30 +++--
dlls/shdocvw/shdocvw.h |1 +
dlls/shdocvw/tests/webbrowser.c | 92 +++
dlls/shdocvw/webbrowser.c |4 ++
4 files changed, 123 insertions(+), 4 deletions(-)
diff --git a/dlls/shdocvw/oleobject.c b/dlls/shdocvw/oleobject.c
index 017e738..bdffc86 100644
--- a/dlls/shdocvw/oleobject.c
+++ b/dlls/shdocvw/oleobject.c
@@ -501,15 +501,37 @@ static HRESULT WINAPI OleObject_Advise(IOleObject *iface, IAdviseSink *pAdvSink,
DWORD* pdwConnection)
{
WebBrowser *This = OLEOBJ_THIS(iface);
-FIXME((%p)-(%p, %p)\n, This, pAdvSink, pdwConnection);
-return E_NOTIMPL;
+HRESULT hr = E_INVALIDARG;
+
+TRACE((%p)-(%p, %p)\n, This, pAdvSink, pdwConnection);
+
+if(!pdwConnection || !pAdvSink)
+return hr;
+
+if(!This-holder)
+{
+hr = CreateOleAdviseHolder(This-holder);
+if(FAILED(hr))
+ERR(CreateOleAdviseHolder failed\n);
+}
+
+if(hr == S_OK This-holder)
+{
+hr = IOleAdviseHolder_Advise(This-holder, pAdvSink, pdwConnection);
+}
+
+return hr;
}
static HRESULT WINAPI OleObject_Unadvise(IOleObject *iface, DWORD dwConnection)
{
WebBrowser *This = OLEOBJ_THIS(iface);
-FIXME((%p)-(%d)\n, This, dwConnection);
-return E_NOTIMPL;
+TRACE((%p)-(%d)\n, This, dwConnection);
+
+if(!This-holder)
+return OLE_E_NOCONNECTION;
+
+return IOleAdviseHolder_Unadvise(This-holder, dwConnection);
}
static HRESULT WINAPI OleObject_EnumAdvise(IOleObject *iface, IEnumSTATDATA **ppenumAdvise)
diff --git a/dlls/shdocvw/shdocvw.h b/dlls/shdocvw/shdocvw.h
index b148611..ed96882 100644
--- a/dlls/shdocvw/shdocvw.h
+++ b/dlls/shdocvw/shdocvw.h
@@ -128,6 +128,7 @@ struct WebBrowser {
IOleClientSite *client;
IOleContainer *container;
IOleInPlaceSite *inplace;
+IOleAdviseHolder *holder;
/* window context */
diff --git a/dlls/shdocvw/tests/webbrowser.c b/dlls/shdocvw/tests/webbrowser.c
index 131b29c..3485e50 100644
--- a/dlls/shdocvw/tests/webbrowser.c
+++ b/dlls/shdocvw/tests/webbrowser.c
@@ -468,6 +468,68 @@ static HRESULT WINAPI WebBrowserEvents2_QueryInterface(IDispatch *iface, REFIID
return E_NOINTERFACE;
}
+/* IAdviseSink */
+static HRESULT WINAPI WebBrowserAdviseSink_QueryInterface(IAdviseSink *iface, REFIID riid, void **ppv)
+{
+*ppv = NULL;
+
+if(IsEqualGUID(IID_IAdviseSink, riid)) {
+*ppv = iface;
+return S_OK;
+}
+
+ok(0, unexpected riid %s\n, debugstr_guid(riid));
+return E_NOINTERFACE;
+}
+
+static ULONG WINAPI WebBrowserAdviseSink_AddRef(IAdviseSink *iface)
+{
+return 2;
+}
+
+static ULONG WINAPI WebBrowserAdviseSink_Release(IAdviseSink *iface)
+{
+return 1;
+}
+
+static void WINAPI WebBrowserAdviseSink_OnDataChange(IAdviseSink *iface, FORMATETC *pFormatetc, STGMEDIUM *pStgmed)
+{
+ok(0, unexpected OnDataChange\n);
+}
+
+static void WINAPI WebBrowserAdviseSink_OnViewChange(IAdviseSink *iface, DWORD dwAspect, LONG lindex)
+{
+ok(0, unexpected OnViewChange\n);
+}
+
+static void WINAPI WebBrowserAdviseSink_OnRename(IAdviseSink *iface, IMoniker *pmk)
+{
+ok(0, unexpected OnRename\n);
+}
+
+static void WINAPI WebBrowserAdviseSink_OnSave(IAdviseSink *iface)
+{
+ok(0, unexpected OnSave\n);
+}
+
+static void WINAPI WebBrowserAdviseSink_OnClose(IAdviseSink *iface)
+{
+ok(0, unexpected OnClose\n);
+}
+
+static IAdviseSinkVtbl AdviseSinkVtbl = {
+WebBrowserAdviseSink_QueryInterface,
+WebBrowserAdviseSink_AddRef,
+WebBrowserAdviseSink_Release,
+WebBrowserAdviseSink_OnDataChange,
+WebBrowserAdviseSink_OnViewChange,
+WebBrowserAdviseSink_OnRename,
+WebBrowserAdviseSink_OnSave,
+WebBrowserAdviseSink_OnClose
+};
+
+static IAdviseSink AdviseSink = { AdviseSinkVtbl };
+
#define test_invoke_bool(p,s) _test_invoke_bool(__LINE__,p,s)
static void _test_invoke_bool(unsigned line, const DISPPARAMS *params, BOOL strict)
{
@@ -1451,6 +1513,35 @@ static void test_DoVerb(IUnknown *unk)
IOleObject_Release(oleobj);
}
+static void test_IOleObject_Sink(IUnknown *unk)
+{
+IOleObject *oleobj;
+HRESULT hres;
+DWORD sink;
+
+hres = IUnknown_QueryInterface(unk, IID_IOleObject, (void**)oleobj);
+ok(hres == S_OK, QueryInterface(IID_OleObject) failed: %08x\n, hres);
+if(FAILED(hres))
+return;
+
+hres = IOleObject_Advise(oleobj, AdviseSink, NULL);
+ok(hres == E_INVALIDARG,
Re: [1/2] shdocvw: Added support for IAdviseSink (resend)
Hi Alistair,
Alistair Leslie-Hughes wrote:
Hi,
Could I get some feedback on this patch please?
+HRESULT hr = E_INVALIDARG;
+
+TRACE((%p)-(%p, %p)\n, This, pAdvSink, pdwConnection);
+
+if(!pdwConnection || !pAdvSink)
+return hr;
+
+if(!This-holder)
+{
+hr = CreateOleAdviseHolder(This-holder);
+if(FAILED(hr))
+ERR(CreateOleAdviseHolder failed\n);
+}
+
+if(hr == S_OK This-holder)
+{
+hr = IOleAdviseHolder_Advise(This-holder, pAdvSink, pdwConnection);
+}
+
+return hr;
It's a matter of taste, but you complicate things here. You could
achieve the same effect easier:
TRACE((%p)-(%p, %p)\n, This, pAdvSink, pdwConnection);
if(!pdwConnection || !pAdvSink)
return E_INVALIDARG;
if(!This-holder) {
HRESULT hr = CreateOleAdviseHolder(This-holder);
if(FAILED(hr)) {
ERR(CreateOleAdviseHolder failed\n);
return hr;
}
}
return IOleAdviseHolder_Advise(This-holder, pAdvSink, pdwConnection);
Also you don't really add support for IAdviseSink. You only store and
never use it and your test don't document missing functionality. It
would be nice not to call Unadvise just after Advise, but keep it
advised and properly test (with todo_wine for now). It's easy to do by
adding something like
trace(#func \n); \
to CHECK_EXPECT2 and running the test on Windows. Then you can easily
guess when the callback should be called and add corresponding
SET_EXPECT/CHECK_CALLED macros. Note that, although it's not needed for
tests to success, these macros are kept in order of calling as much as
possible for documentation purposes.
If you're not going to extend tests, please leave FIXME messages.
Otherwise you hide the problem with no evidence.
Thanks,
Jacek
Re: DxDiag Demo Patch
On Fri, Mar 27, 2009 at 6:33 AM, Henri Verbeethverb...@gmail.com wrote:
2009/3/25 Allen Hair allen.h...@gmail.com:
Attached is a patch that will add our code to the source tree. This
patch is not meant to be
committed, but should provide a demonstration of the application so
far. Any feedback would be
appreciated, I will try to incorporate any suggestions as I work on
releasing incremental patches
over the next few weeks.
In case anyone's interested, I've cleaned this up a bit:
C++ comments C comments
Consolidated a bunch of files/headers.
Cleaned up formatting to be consistent.
Removed the bastardization of tabs that was everywhere.
Fixed the Makefile, which didn't even compile...
Fixed the headers, which weren't compiling properly (note, the
combined header is still really messy)
Well, it dies on startup in getInputDeviceInfo() in InputInfo.c, line
13. Probably because of IDxDiagContainer_GetChildContainer failed:
DxDiag_DirectInputGameports. Regardless, I have a couple of comments
from quickly looking the patch over.
This is still true.
programs/dxdiag/D3DTest.c | 354 +++
...
It's probably a matter of taste, but please don't use caps in source
filenames.
Fixed here.
+// Is a test instance currently running?
Please don't use C++ style comments in Wine code.
Fixed.
+C_SRCS = \
+»··main.c \
+DxDiagCOM.c \
+System.c \
...
This won't work properly, you need to use tabs in Makefiles.
In general, the code mixes tabs and spaces (and from the looks of it
inconsistent tab width as well). Personally I'd prefer spaces, but the
important thing is consistency. The same goes for other style issues
like the position of braces, whitespace usage, etc.
Fixed.
+void D3DTest_initD3D();
This needs to be void D3DTest_initD3D(void); in C. The same goes for
a couple of other functions.
I received mixed feedback on #winehackers about this. So currently
left as is...is there a CFLAG/gcc switch to detect this, without using
-ansi (which gives a crapton of other warnings).
Note that you can avoid the forward declarations by rearranging the
order of the functions.
Fixed.
+»··if ( !gd3d_pD3D9 ) {
+»··»···fprintf(stderr,Direct3DCreate9() - Failed\n);
+»··»···abort();
+»··»···}
You'll want to handle failure a bit more gracefully than calling abort().
Untouched.
+»··»···pData[i] =
D3DCOLOR_XRGB(buffer[offset+bpp*i],buffer[offset+bpp*i+2],buffer[offset+bpp*i+1]);
+»··»···// Note: bmp file uses RBG instead of RGB!
That's not actually true, the data is typically stored as BGR(A), but
offset looks wrong. You don't want to parse the bitmap yourself
though, you should probably be using LoadBitmap() and GetDIBits().
Added your comment.
+ IDirect3DDevice9_DrawPrimitive(gd3d_pDevice, D3DPT_TRIANGLESTRIP, 0, 2
);
+ IDirect3DDevice9_DrawPrimitive(gd3d_pDevice, D3DPT_TRIANGLESTRIP, 4, 2
);
+ IDirect3DDevice9_DrawPrimitive(gd3d_pDevice, D3DPT_TRIANGLESTRIP, 8, 2
);
+ IDirect3DDevice9_DrawPrimitive(gd3d_pDevice, D3DPT_TRIANGLESTRIP, 12, 2
);
+ IDirect3DDevice9_DrawPrimitive(gd3d_pDevice, D3DPT_TRIANGLESTRIP, 16, 2
);
+ IDirect3DDevice9_DrawPrimitive(gd3d_pDevice, D3DPT_TRIANGLESTRIP, 20, 2
);
This is not the most efficient way to render a cube.
Untouched.
diff --git a/programs/dxdiag/D3DTest.h b/programs/dxdiag/D3DTest.h
new file mode 100644
index 000..f9e8c4d
--- /dev/null
+++ b/programs/dxdiag/D3DTest.h
@@ -0,0 +1,6 @@
+#ifndef D3DTEST_H
+#define D3DTEST_H
+
+void D3DTest_testD3D();
+
+#endif
It's not really worth it to create separate header files if they only
contain a single function declaration. You'll probably want to merge
most of these.
Fixed.
+»·· if (FAILED(DxDiagCOM_GetContainer(pcom-root,
_T(DxDiag_DisplayDevices), displayEnum)))
_T() (or L) won't work properly in Wine because wide strings are
different between Unix and Windows. Typically a wchar_t is 32 bit on
Unix and 16 bit on Windows. -fshort-wchar might help, but I don't
think that's portable. I general I think it's best to just avoid stuff
like TCHAR and make the program explicitly unicode.
Untouched.
I've put it up on http://austinenglish.com/0001-dxdiag.txt and
attached to bug 14118 ( http://bugs.winehq.org/show_bug.cgi?id=14118
).
Allen, I'd really like to see this get into Wine. If you've got some
spare time to fix a few of the bugs y'all left in, I'll help y'all
split it up and get it into Wine. What do you say?
--
-Austin
Request for vista testing
Can someone test this on vista? It tests NtCancelIoFileEx. The goal is
to find out the order of arguments.
Thanks,
Mike.
diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c
index 164c2da..174daa5 100644
--- a/dlls/ntdll/tests/file.c
+++ b/dlls/ntdll/tests/file.c
@@ -54,6 +54,7 @@ static NTSTATUS (WINAPI *pNtWriteFile)(HANDLE hFile, HANDLE hEvent,
PIO_STATUS_BLOCK io_status,
const void* buffer, ULONG length,
PLARGE_INTEGER offset, PULONG key);
+static NTSTATUS (WINAPI *pNtCancelIoFileEx)(HANDLE hFile, PIO_STATUS_BLOCK iosb, PIO_STATUS_BLOCK io_status);
static NTSTATUS (WINAPI *pNtClose)( PHANDLE );
static NTSTATUS (WINAPI *pNtCreateIoCompletion)(PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, ULONG);
@@ -355,6 +356,33 @@ static void read_file_test(void)
ok( apc_count == 1, apc was not called\n );
CloseHandle( read );
+if (pNtCancelIoFileEx)
+{
+IO_STATUS_BLOCK iosb2;
+/* test param order for NtCancelIoFileEx */
+if (!create_pipe( read, write, FILE_FLAG_OVERLAPPED, 4096 )) return;
+apc_count = 0;
+U(iosb).Status = 0xdeadbabe;
+iosb.Information = 0xdeadbeef;
+status = pNtReadFile( read, event, apc, apc_count, iosb, buffer, 2, NULL, NULL );
+ok( status == STATUS_PENDING, wrong status %x\n, status );
+ok( !is_signaled( event ), event is signaled\n );
+ok( U(iosb).Status == 0xdeadbabe, wrong status %x\n, U(iosb).Status );
+ok( iosb.Information == 0xdeadbeef, wrong info %lu\n, iosb.Information );
+ok( !apc_count, apc was called\n );
+status = pNtCancelIoFileEx( read, iosb, iosb2 );
+ok(status == STATUS_SUCCESS, Failed to cancel I/O\n);
+Sleep(1); /* FIXME: needed for wine to run the i/o apc */
+ok( U(iosb).Status == STATUS_CANCELLED, wrong status %x\n, U(iosb).Status );
+ok( iosb.Information == 0, wrong info %lu\n, iosb.Information );
+ok( is_signaled( event ), event is signaled\n );
+ok( !apc_count, apc was called\n );
+SleepEx( 1, TRUE ); /* alertable sleep */
+ok( apc_count == 1, apc was not called\n );
+CloseHandle( read );
+CloseHandle( write );
+}
+
/* now try a real file */
if (!(handle = create_temp_file( FILE_FLAG_OVERLAPPED ))) return;
apc_count = 0;
@@ -712,6 +740,7 @@ START_TEST(file)
pNtDeleteFile = (void *)GetProcAddress(hntdll, NtDeleteFile);
pNtReadFile = (void *)GetProcAddress(hntdll, NtReadFile);
pNtWriteFile= (void *)GetProcAddress(hntdll, NtWriteFile);
+pNtCancelIoFileEx = (void *)GetProcAddress(hntdll, NtCancelIoFileEx);
pNtClose= (void *)GetProcAddress(hntdll, NtClose);
pNtCreateIoCompletion = (void *)GetProcAddress(hntdll, NtCreateIoCompletion);
pNtOpenIoCompletion = (void *)GetProcAddress(hntdll, NtOpenIoCompletion);
Re: kernel32/nls/winerr: Add Russian translation [try 2]
Vladimir Pankratov script...@mail.ru wrote: Thanks for suggestions. Added Russian translation. Changed files: dlls/kernel32/nls/winerr_rus.mc Please stop. This is not a translation. I'd suggest to stop accepting your other translations and patches as well. -- Dmitry.
Re: [3/3] user32/tests: Add tests for SendInput with unicode
Andrew Eikum aei...@codeweavers.com wrote: --- dlls/user32/tests/input.c | 210 + 1 files changed, 210 insertions(+), 0 deletions(-) It would be more natural and would simplify the code to add these tests to msg.c. Also, please try to avoid names like g_keyStatus, lastKeyDown, UnicodeWndProc and similar. key_status, last_key_down, unicode_wnd_proc look much more readable. -- Dmitry.
