signal(SIGCHLD,SIG_DFL) before exec()
Hi list. I suffer from this bug: http://bugs.winehq.org/show_bug.cgi?id=27014
In wine sources there're not so many places where exec(3) family is
used. In some places SIGCHLD and SIGPIPE are restored to default
before calling exec(), in others they aren't. What's the difference?
Can anyone explain me the why SIGCHLD not restored to default
before calling execvp() here:
http://source.winehq.org/source/libs/port/spawn.c?v=wine-1.3.19#L42
int spawnvp(int mode, const char *cmdname, const char *const argv[])
{
...
if (mode == _P_OVERLAY)
{
execvp(cmdname, (char **)argv);
/* if we get here it failed */
#ifdef ENOTSUP
if (errno != ENOTSUP) /* exec fails on MacOS if the process has
multiple threads */
#endif
return -1;
}
Because it's not forked and if execvp() fails, we end up with the
default handler?
Re: FAQ translation possible?
On Wed, May 4, 2011 at 07:24, Ove Kåven o...@arcticnet.no wrote: Den 04. mai 2011 00:49, skrev Frédéric Delanoy: But in any case, the language to use should preferably be autoselected from WineHQ's lang cookie IMHO. The way I understand moinmoin, you need to create a new wiki page with the translated content. This is typically done by also translating the page name itself, i.e. if you have an English MyProject, then you have a MeinProjekt page in German. Anyway, the version of moinmoin used here is dated and doesn't support on-page-change notification, which makes translation (but especially further maintainance) tricky. I tried to find the wiki/web server responsible, but without success. Who's responsible for the server? J. Newman? Once the translation exist, you can update moinmoin's dictionary page (the GermanDict page in this case), so that it knows that MeinProjekt is a German translation of MyProject. With that done, if a German user accesses MyProject, there will be a toolbar entry to take them to the German version. MoinMoin can do even better for the front page, because if the user accesses the wiki without requesting a specific page, then moinmoin can itself choose which front page to return. It's chosen based on the preferred language of the user's browser, and it will search its dictionary to find what the name of that language's front page is. So German people would automatically get StartSeite instead of FrontPage. Then, of course, that front page would contain links to the pages of the language it is written in. So German users would automatically be served the German frontpage, and all German pages (like StartSeite) would link to MeinProjekt where the English pages (like FrontPage) would link to MyProject. This scheme, of course, works best if the people putting content into the wiki are careful not to use acronyms like FAQ as page names. Thanks for the info. Frédéric
Re: FAQ translation possible?
I tried to find the wiki/web server responsible, but without success. Who's responsible for the server? J. Newman? In this case, it's Dimi O'Paun. --Juan
Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().
On 05/03/2011 05:30 PM, Nikolay Sivov wrote: I'm worried about VT_UI1 being interpreted as ASCII stream or just a byte stream that could be in any encoding. If it's a case you can't assume it's encoded as utf8, when you do utf8 - utf16 (for BSTR). For this particular case you might want direct doparse() call for VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array over a WCHAR buffer with UTF16 xml data and try to ::load() from it. If encoding is detected then you need direct doparse() call, to do completely clear case don't include encoding= attribute in this xml data. I glad you mentioned this, I thought about that too. I did some testing and it seems that only UTF8 (or maybe just ASCII) is supported. The SAFEARRAY does seem to be treated more like a file than a string, eg if there is a '\0' at the end of the array it causes a parse error (I don't think we need to duplicate that behavior though). I'm not sure if multi-dimensional arrays are supported, it will take some further testing, but if so that can be a separate patch; for now I'll just add a FIXME if the array is not a vector. I remember another place where it would have been useful to be able to call domdoc_loadXML() with a UTF8 string to avoid converting to BSTR and back, I think in the schema stuff. It would be nice to have an internal function to do that, then domdoc_loadXML() can just wrap it, but I think that can be a separate patch. Anyway if you need a interface call to implement some other method use already defined macro instead of internal static implementation function. Internal method implementations better not depend on each other. Ye, you're right, I will add that as part of this set.
Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections
Jacek Caban ja...@codeweavers.com writes: try2: Using GetTickCount64() for timestamps --- dlls/urlmon/tests/protocol.c |2 +- dlls/urlmon/tests/url.c | 20 +- dlls/wininet/http.c | 567 -- dlls/wininet/internet.c |2 +- dlls/wininet/internet.h | 42 +++- dlls/wininet/netconnection.c | 138 --- dlls/wininet/tests/http.c| 32 +-- 7 files changed, 427 insertions(+), 376 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c touch http.ok http.c:2621: Test failed: expected 1 retrievals, got 0 http.c:2628: Test failed: count was wrong http.c:2629: Test failed: http data wrong http.c:2649: Test succeeded inside todo block: expected 1 retrievals make: *** [http.ok] Error 4 -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections
On 05/04/11 16:07, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: try2: Using GetTickCount64() for timestamps --- dlls/urlmon/tests/protocol.c |2 +- dlls/urlmon/tests/url.c | 20 +- dlls/wininet/http.c | 567 -- dlls/wininet/internet.c |2 +- dlls/wininet/internet.h | 42 +++- dlls/wininet/netconnection.c | 138 --- dlls/wininet/tests/http.c| 32 +-- 7 files changed, 427 insertions(+), 376 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c touch http.ok http.c:2621: Test failed: expected 1 retrievals, got 0 http.c:2628: Test failed: count was wrong http.c:2629: Test failed: http data wrong http.c:2649: Test succeeded inside todo block: expected 1 retrievals make: *** [http.ok] Error 4 That's an already existing race in tests. It fails on Windows as well: http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_fg-win2003es-sp2/wininet:http.html I've seen it here and my patch seems to make is more likely to fail. I plan fixing it, but, as it's not new, so I think it shouldn't block committing my patch. Jacek
Re: winscard/tests: Add test base functions of winscard.dll
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 http://testbot.winehq.org/JobDetails.pl?Key=10722 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections
Jacek Caban ja...@codeweavers.com writes: That's an already existing race in tests. It fails on Windows as well: http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_fg-win2003es-sp2/wininet:http.html I've seen it here and my patch seems to make is more likely to fail. I plan fixing it, but, as it's not new, so I think it shouldn't block committing my patch. Maybe it's not new, but it's much worse. That failure used to happen maybe at most once a week here, but now it's failing 9 times out of 10. I really don't want to have to always run make test in a loop until it works. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections
On 5/4/11 8:05 PM, Alexandre Julliard wrote: Jacek Cabanja...@codeweavers.com writes: That's an already existing race in tests. It fails on Windows as well: http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_fg-win2003es-sp2/wininet:http.html I've seen it here and my patch seems to make is more likely to fail. I plan fixing it, but, as it's not new, so I think it shouldn't block committing my patch. Maybe it's not new, but it's much worse. That failure used to happen maybe at most once a week here, but now it's failing 9 times out of 10. I really don't want to have to always run make test in a loop until it works. Oh, didn't expect it to be that bad, it fails about 1 out of 5 times here. I will fix the test first then. Jacek
Re: Support for D3DQUERY_TIMESTAMP* queries...
OK, I think I addressed those issues, let me know how these look.
From 4648e7395800ae2a1ad55166493cae9183dc2c62 Mon Sep 17 00:00:00 2001
From: Adam Martinson amartin...@codeweavers.com
Date: Wed, 4 May 2011 11:05:25 -0500
Subject: [PATCH 03/12] wined3d: Add support for GL_ARB_timer_query.
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/wined3d/directx.c|1 +
dlls/wined3d/wined3d_gl.h | 19 +++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 1b593ce..e1fc833 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -86,6 +86,7 @@ static const struct {
{GL_ARB_texture_non_power_of_two, ARB_TEXTURE_NON_POWER_OF_TWO, MAKEDWORD_VERSION(2, 0) },
{GL_ARB_texture_rectangle,ARB_TEXTURE_RECTANGLE, 0 },
{GL_ARB_texture_rg, ARB_TEXTURE_RG, 0 },
+{GL_ARB_timer_query, ARB_TIMER_QUERY,0 },
{GL_ARB_vertex_array_bgra,ARB_VERTEX_ARRAY_BGRA, 0 },
{GL_ARB_vertex_blend, ARB_VERTEX_BLEND, 0 },
{GL_ARB_vertex_buffer_object, ARB_VERTEX_BUFFER_OBJECT, 0 },
diff --git a/dlls/wined3d/wined3d_gl.h b/dlls/wined3d/wined3d_gl.h
index be50b2f..9038fcc 100644
--- a/dlls/wined3d/wined3d_gl.h
+++ b/dlls/wined3d/wined3d_gl.h
@@ -1769,6 +1769,7 @@ typedef enum wined3d_gl_extension
ARB_TEXTURE_NON_POWER_OF_TWO,
ARB_TEXTURE_RECTANGLE,
ARB_TEXTURE_RG,
+ARB_TIMER_QUERY,
ARB_VERTEX_ARRAY_BGRA,
ARB_VERTEX_BLEND,
ARB_VERTEX_BUFFER_OBJECT,
@@ -2458,6 +2459,17 @@ typedef GLvoid (WINE_GLAPI *PGLFNGETSYNCIVPROC)(GLsync sync, GLenum pname, GLsiz
#define GL_RG32UI 0x823c
#endif
+/* GL_ARB_timer_query */
+#ifndef GL_ARB_timer_query
+#define GL_ARB_timer_query 1
+#define GL_TIME_ELAPSED_ARB 0x88BF
+#define GL_TIMESTAMP_ARB0x8E28
+#endif
+
+typedef void (WINE_GLAPI *PGLFNGLQUERYCOUNTERPROC)(GLuint id, GLenum target);
+typedef void (WINE_GLAPI *PGLFNGLGETQUERYOBJECTI64VPROC)(GLuint id, GLenum pname, GLint64 *params);
+typedef void (WINE_GLAPI *PGLFNGLGETQUERYOBJECTUI64VPROC)(GLuint id, GLenum pname, GLuint64 *params);
+
/* GL_ARB_vertex_blend */
#ifndef GL_ARB_vertex_blend
#define GL_ARB_vertex_blend 1
@@ -4002,6 +4014,13 @@ typedef BOOL (WINAPI *WINED3D_PFNWGLSWAPINTERVALEXTPROC)(int interval);
glCompressedTexSubImage3DARB, ARB_TEXTURE_COMPRESSION,NULL) \
USE_GL_FUNC(PGLFNGETCOMPRESSEDTEXIMAGEPROC, \
glGetCompressedTexImageARB, ARB_TEXTURE_COMPRESSION,NULL) \
+/* GL_ARB_timer_query */ \
+USE_GL_FUNC(PGLFNGLQUERYCOUNTERPROC, \
+glQueryCounter, ARB_TIMER_QUERY,NULL) \
+USE_GL_FUNC(PGLFNGLGETQUERYOBJECTI64VPROC, \
+glGetQueryObjecti64v, ARB_TIMER_QUERY,NULL) \
+USE_GL_FUNC(PGLFNGLGETQUERYOBJECTUI64VPROC, \
+glGetQueryObjectui64v, ARB_TIMER_QUERY,NULL) \
/* GL_ARB_vertex_blend */ \
USE_GL_FUNC(PGLFNGLWEIGHTPOINTERARB, \
glWeightPointerARB, ARB_VERTEX_BLEND, NULL) \
--
1.7.1
From 8e1a7181077bf35ca545984bd6985ed23d842fe4 Mon Sep 17 00:00:00 2001
From: Adam Martinson amartin...@codeweavers.com
Date: Wed, 4 May 2011 11:12:28 -0500
Subject: [PATCH 04/12] d3d9/query: Use D3DQUERYTYPE instead of HRESULT in IDirect3DQuery9Impl_GetType().
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/d3d9/query.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/d3d9/query.c b/dlls/d3d9/query.c
index 5e1bf12..4accc6a 100644
--- a/dlls/d3d9/query.c
+++ b/dlls/d3d9/query.c
@@ -95,15 +95,15 @@ static HRESULT WINAPI IDirect3DQuery9Impl_GetDevice(IDirect3DQuery9 *iface,
static D3DQUERYTYPE WINAPI IDirect3DQuery9Impl_GetType(IDirect3DQuery9 *iface)
{
IDirect3DQuery9Impl *This = impl_from_IDirect3DQuery9(iface);
-HRESULT hr;
+D3DQUERYTYPE type;
TRACE(iface %p.\n, iface);
wined3d_mutex_lock();
-hr = wined3d_query_get_type(This-wineD3DQuery);
+type = wined3d_query_get_type(This-wineD3DQuery);
wined3d_mutex_unlock();
-return hr;
+return type;
}
static DWORD WINAPI IDirect3DQuery9Impl_GetDataSize(IDirect3DQuery9 *iface)
--
1.7.1
From 988c4aa4d12251dcc5320a1c3d178de7770e4ef7 Mon Sep 17 00:00:00 2001
From: Adam Martinson amartin...@codeweavers.com
Date: Wed, 4 May 2011 11:25:45 -0500
Subject: [PATCH 05/12]
Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().
On 5/4/2011 19:30, Adam Martinson wrote: On 05/03/2011 05:30 PM, Nikolay Sivov wrote: I'm worried about VT_UI1 being interpreted as ASCII stream or just a byte stream that could be in any encoding. If it's a case you can't assume it's encoded as utf8, when you do utf8 - utf16 (for BSTR). For this particular case you might want direct doparse() call for VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array over a WCHAR buffer with UTF16 xml data and try to ::load() from it. If encoding is detected then you need direct doparse() call, to do completely clear case don't include encoding= attribute in this xml data. I glad you mentioned this, I thought about that too. I did some testing and it seems that only UTF8 (or maybe just ASCII) is supported. The SAFEARRAY does seem to be treated more like a file than a string, eg if there is a '\0' at the end of the array it causes a parse error (I don't think we need to duplicate that behavior though). Yeah, I don't see a reason to implement this particular case for now. I'm not sure if multi-dimensional arrays are supported, it will take some further testing, but if so that can be a separate patch; for now I'll just add a FIXME if the array is not a vector. I don't expect it's supported, it sounds a bit insane for me to load from multidimensional arrays. I think after this case (VT_UI1 array) implemented we need a WARN for any other variant type. And some tests for sure.
Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.
On 5/5/2011 00:38, Adam Martinson wrote: --- dlls/msxml3/domdoc.c | 85 + 1 files changed, 50 insertions(+), 35 deletions(-) You don't need a separate helper for that. doparse() should do fine with UTF-8 encoding parameter to force encoding. Also will it preserve existing document or will really create empty one on error is a question.
Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)
On 5/5/2011 00:38, Adam Martinson wrote:
Fixes bugs 14864 + 16453.
---
dlls/msxml3/domdoc.c | 27 +
dlls/msxml3/tests/domdoc.c | 94
+++-
2 files changed, 120 insertions(+), 1 deletions(-)
+case VT_ARRAY|VT_UI1:
+{
+SAFEARRAY *psa = V_ARRAY(source);
+xmlChar *str;
+LONG len;
+UINT dim = SafeArrayGetDim(psa);
+
+switch (dim)
+{
+case 0:
+ERR(SAFEARRAY == NULL\n);
+hr = E_INVALIDARG;
+break;
+case 1:
+/* Only takes UTF8 strings.
+ * NOT NULL-terminated. */
+SafeArrayAccessData(psa, (void**)str);
+SafeArrayGetUBound(psa, 1,len);
+hr = load_utf8(This, str, ++len, isSuccessful);
+SafeArrayUnaccessData(psa);
+break;
+default:
+FIXME(unhandled SAFEARRAY dim: %d\n, dim);
+hr = E_NOTIMPL;
+}
+}
This could be simplified. SafeArrayGetUBound will fail for case 0 for
example, and unhandled dimension should be WARN, IMO.
