Re: [PATCH] kernel32: add condition variables prototypes and tests
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=21331 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH] kernel32: add condition variables prototypes and tests
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=21332 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)
Marcus Meissner meiss...@suse.de wrote:
+if (!pInitializeConditionVariable) {
+skip(no condition variable support.\n);
+return;
+}
Probably this should be a win_slip().
+/* fprintf(stderr,produced %d, c1 %d, c2 %d\n, totalproduced, cnt1,
cnt2); */
+
+/* The sleeps of the producer or consumer should not go above 1,
otherwise
+ * the implementation does not sleep correctly. */
+
+/* fprintf(stderr,producer sleep %d, consumer sleep %d\n,
condvar_producer_sleepcnt, condvar_consumer_sleepcnt); */
There is trace() for debug output, it's shorter and more convenient IMHO.
--
Dmitry.
Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)
On Sun, Sep 02, 2012 at 11:40:52PM +0900, Dmitry Timoshkov wrote:
Marcus Meissner meiss...@suse.de wrote:
+if (!pInitializeConditionVariable) {
+skip(no condition variable support.\n);
+return;
+}
Probably this should be a win_slip().
The function exists only since Windows 7/Vista (not XP) and is not yet
in Wine (and might take a while, as my time is limited currently
and my knowledge of this specific function same).
So I think skip is currently the right thing ;)
+/* fprintf(stderr,produced %d, c1 %d, c2 %d\n, totalproduced, cnt1,
cnt2); */
+
+/* The sleeps of the producer or consumer should not go above 1,
otherwise
+ * the implementation does not sleep correctly. */
+
+/* fprintf(stderr,producer sleep %d, consumer sleep %d\n,
condvar_producer_sleepcnt, condvar_consumer_sleepcnt); */
There is trace() for debug output, it's shorter and more convenient IMHO.
True, I could do that, but its not relevant for the test as-is.
Ciao, Marcus
Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)
Probably this should be a win_slip(). The function exists only since Windows 7/Vista (not XP) and is not yet in Wine (and might take a while, as my time is limited currently and my knowledge of this specific function same). So I think skip is currently the right thing ;) I think a todo_wine win_skip is appropriate for cases where Wine should have an implementation but doesn't yet.
Wine Gecko 1.8-beta1
Hi all,
It's time for another Gecko update. I've uploaded to SourceForge [1] new
Gecko builds. These are based on Firefox 16 beta. Other than tons of
changes inherited from Firefox and usual fixes to keep it working well
for us, it brings a few visible fixes:
- Proper noscript tag handling
- Synchronous ActiveX loading
- Possibility to properly call APIs requiring JSContext
- Possibility to implement HTMLStyleElement::styleSheet property
As usually, to test it you need the attached patch and Gecko build
placed in the right place [2]. Any help with testing is appreciated!
On related note, I seriously consider dropping debug builds and replace
them by unstripped release build or even just a separated package
containing only debug symbols for the release build. Here are my
thoughts about reasoning (in random order):
- People use debug build mostly to retrieve better backtraces.
Unstripped builds also give that ability.
- If someone really needs debug build, it's easy enough to build it
himself (and that's usually a good idea anyway)
- Debug builds are seriously different than release build, so it
occasionally exposes different set of problems, leading to invalid
assumptions. This is really something for developers rather than users.
- It costs my time spent builds and tests. And I consider it a serious
matter. Amount of work needed to keep Gecko relevant is constantly
growing. I try to mitigate it by doing long-term improvements upstream,
automating the process and improving my hardware, but that has its
limits. And the time spent on Gecko maintenance (as in pure maintenance,
not real improvements) costs Wine in terms of improvements I could make
in this time.
If someone has a reason to keep debug builds, let me know. Any comments
are welcomed.
Thanks,
Jacek
[1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/
[2] http://wiki.winehq.org/Gecko
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index 82a6797..b569705 100644
--- a/dlls/appwiz.cpl/addons.c
+++ b/dlls/appwiz.cpl/addons.c
@@ -51,7 +51,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(appwizcpl);
-#define GECKO_VERSION 1.7
+#define GECKO_VERSION 1.8-beta1
#ifdef __i386__
#define ARCH_STRING x86
diff --git a/dlls/mshtml/htmldoc.c b/dlls/mshtml/htmldoc.c
index 86615df..5ac8e4e 100644
--- a/dlls/mshtml/htmldoc.c
+++ b/dlls/mshtml/htmldoc.c
@@ -1022,24 +1022,12 @@ static HRESULT WINAPI
HTMLDocument_createElement(IHTMLDocument2 *iface, BSTR eTa
IHTMLElement **newElem)
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
-HTMLDocumentNode *doc_node;
-nsIDOMHTMLElement *nselem;
HTMLElement *elem;
HRESULT hres;
TRACE((%p)-(%s %p)\n, This, debugstr_w(eTag), newElem);
-/* Use owner doc if called on document fragment */
-doc_node = This-doc_node;
-if(!doc_node-nsdoc)
-doc_node = doc_node-node.doc;
-
-hres = create_nselem(doc_node, eTag, nselem);
-if(FAILED(hres))
-return hres;
-
-hres = HTMLElement_Create(doc_node, (nsIDOMNode*)nselem, TRUE, elem);
-nsIDOMHTMLElement_Release(nselem);
+hres = create_element(This-doc_node, eTag, elem);
if(FAILED(hres))
return hres;
@@ -1443,11 +1431,55 @@ static HRESULT WINAPI
HTMLDocument_createStyleSheet(IHTMLDocument2 *iface, BSTR
LONG lIndex, IHTMLStyleSheet
**ppnewStyleSheet)
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
+nsIDOMHTMLHeadElement *head_elem;
+IHTMLStyleElement *style_elem;
+HTMLElement *elem;
+nsresult nsres;
+HRESULT hres;
-FIXME((%p)-(%s %d %p) semi-stub\n, This, debugstr_w(bstrHref), lIndex,
ppnewStyleSheet);
+static const WCHAR styleW[] = {'s','t','y','l','e',0};
-*ppnewStyleSheet = HTMLStyleSheet_Create(NULL);
-return S_OK;
+TRACE((%p)-(%s %d %p)\n, This, debugstr_w(bstrHref), lIndex,
ppnewStyleSheet);
+
+if(!This-doc_node-nsdoc) {
+FIXME(not a real doc object\n);
+return E_NOTIMPL;
+}
+
+if(lIndex != -1)
+FIXME(Unsupported lIndex %d\n, lIndex);
+
+if(bstrHref) {
+FIXME(semi-stub for href %s\n, debugstr_w(bstrHref));
+*ppnewStyleSheet = HTMLStyleSheet_Create(NULL);
+return S_OK;
+}
+
+hres = create_element(This-doc_node, styleW, elem);
+if(FAILED(hres))
+return hres;
+
+nsres = nsIDOMHTMLDocument_GetHead(This-doc_node-nsdoc, head_elem);
+if(NS_SUCCEEDED(nsres)) {
+nsIDOMNode *tmp_node;
+
+nsres = nsIDOMHTMLHeadElement_AppendChild(head_elem,
(nsIDOMNode*)elem-nselem, tmp_node);
+nsIDOMHTMLHeadElement_Release(head_elem);
+if(NS_SUCCEEDED(nsres) tmp_node)
+nsIDOMNode_Release(tmp_node);
+}
+if(NS_FAILED(nsres)) {
+IHTMLElement_Release(elem-IHTMLElement_iface);
+return E_FAIL;
+}
+
+hres = IHTMLElement_QueryInterface(elem-IHTMLElement_iface,
Wine Gecko 1.8-beta1
Hi all,
It's time for another Gecko update. I've uploaded to SourceForge [1] new
Gecko builds. These are based on Firefox 16 beta. Other than tons of
changes inherited from Firefox and usual fixes to keep it working well
for us, it brings a few visible fixes:
- Proper noscript tag handling
- Synchronous ActiveX loading
- Possibility to properly call APIs requiring JSContext
- Possibility to implement HTMLStyleElement::styleSheet property
As usually, to test it you need the attached patch and Gecko build
placed in the right place [2]. Any help with testing is appreciated!
On related note, I seriously consider dropping debug builds and replace
them by unstripped release build or even just a separated package
containing only debug symbols for the release build. Here are my
thoughts about reasoning (in random order):
- People use debug build mostly to retrieve better backtraces.
Unstripped builds also give that ability.
- If someone really needs debug build, it's easy enough to build it
himself (and that's usually a good idea anyway)
- Debug builds are seriously different than release build, so it
occasionally exposes different set of problems, leading to invalid
assumptions. This is really something for developers rather than users.
- It costs my time spent builds and tests. And I consider it a serious
matter. Amount of work needed to keep Gecko relevant is constantly
growing. I try to mitigate it by doing long-term improvements upstream,
automating the process and improving my hardware, but that has its
limits. And the time spent on Gecko maintenance (as in pure maintenance,
not real improvements) costs Wine in terms of improvements I could make
in this time.
If someone has a reason to keep debug builds, let me know. Any comments
are welcomed.
Thanks,
Jacek
[1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/
[2] http://wiki.winehq.org/Gecko
PS: This is a second resend. For some reason this mail didn't make to
wine-devel yesterday.
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index 82a6797..b569705 100644
--- a/dlls/appwiz.cpl/addons.c
+++ b/dlls/appwiz.cpl/addons.c
@@ -51,7 +51,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(appwizcpl);
-#define GECKO_VERSION 1.7
+#define GECKO_VERSION 1.8-beta1
#ifdef __i386__
#define ARCH_STRING x86
diff --git a/dlls/mshtml/htmldoc.c b/dlls/mshtml/htmldoc.c
index 86615df..5ac8e4e 100644
--- a/dlls/mshtml/htmldoc.c
+++ b/dlls/mshtml/htmldoc.c
@@ -1022,24 +1022,12 @@ static HRESULT WINAPI
HTMLDocument_createElement(IHTMLDocument2 *iface, BSTR eTa
IHTMLElement **newElem)
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
-HTMLDocumentNode *doc_node;
-nsIDOMHTMLElement *nselem;
HTMLElement *elem;
HRESULT hres;
TRACE((%p)-(%s %p)\n, This, debugstr_w(eTag), newElem);
-/* Use owner doc if called on document fragment */
-doc_node = This-doc_node;
-if(!doc_node-nsdoc)
-doc_node = doc_node-node.doc;
-
-hres = create_nselem(doc_node, eTag, nselem);
-if(FAILED(hres))
-return hres;
-
-hres = HTMLElement_Create(doc_node, (nsIDOMNode*)nselem, TRUE, elem);
-nsIDOMHTMLElement_Release(nselem);
+hres = create_element(This-doc_node, eTag, elem);
if(FAILED(hres))
return hres;
@@ -1443,11 +1431,55 @@ static HRESULT WINAPI
HTMLDocument_createStyleSheet(IHTMLDocument2 *iface, BSTR
LONG lIndex, IHTMLStyleSheet
**ppnewStyleSheet)
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
+nsIDOMHTMLHeadElement *head_elem;
+IHTMLStyleElement *style_elem;
+HTMLElement *elem;
+nsresult nsres;
+HRESULT hres;
-FIXME((%p)-(%s %d %p) semi-stub\n, This, debugstr_w(bstrHref), lIndex,
ppnewStyleSheet);
+static const WCHAR styleW[] = {'s','t','y','l','e',0};
-*ppnewStyleSheet = HTMLStyleSheet_Create(NULL);
-return S_OK;
+TRACE((%p)-(%s %d %p)\n, This, debugstr_w(bstrHref), lIndex,
ppnewStyleSheet);
+
+if(!This-doc_node-nsdoc) {
+FIXME(not a real doc object\n);
+return E_NOTIMPL;
+}
+
+if(lIndex != -1)
+FIXME(Unsupported lIndex %d\n, lIndex);
+
+if(bstrHref) {
+FIXME(semi-stub for href %s\n, debugstr_w(bstrHref));
+*ppnewStyleSheet = HTMLStyleSheet_Create(NULL);
+return S_OK;
+}
+
+hres = create_element(This-doc_node, styleW, elem);
+if(FAILED(hres))
+return hres;
+
+nsres = nsIDOMHTMLDocument_GetHead(This-doc_node-nsdoc, head_elem);
+if(NS_SUCCEEDED(nsres)) {
+nsIDOMNode *tmp_node;
+
+nsres = nsIDOMHTMLHeadElement_AppendChild(head_elem,
(nsIDOMNode*)elem-nselem, tmp_node);
+nsIDOMHTMLHeadElement_Release(head_elem);
+if(NS_SUCCEEDED(nsres) tmp_node)
+nsIDOMNode_Release(tmp_node);
+}
+if(NS_FAILED(nsres)) {
+IHTMLElement_Release(elem-IHTMLElement_iface);
+return
Re: Wine Gecko 1.8-beta1
On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. No one has complained about the debugging symbols in Wine Mono yet. They are included mostly because I don't know how to get rid of them, and it seems silly to put effort into that given the debug symbols have proven useful so far.
Re: vcomp.dll, vcomp90.dll missing on testbot?
On Wed, Aug 8, 2012 at 7:27 AM, Dan Kegel d...@kegel.com wrote: Testing vcomp100 does work, but I shouldn't need to do that until there's some vcomp100-specific code. msvcr90/tests just adds a manifest, and that works. Heh. It does add a manifest, but I don't think it works. See http://bugs.winehq.org/show_bug.cgi?id=31603 - Dan
Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).
On Sep 2, 2012, at 11:23 AM, Erich E. Hoover wrote: This patch adds the final feature to make the embedded help work properly, allowing Elster to resize the HTML Help window whenever the application window is resized. Without this feature the HTML Help window would always remain at the same size as when the window was first created. Er, uh, what patch? Chip
Re: [PATCH] secur32/schannel: diabled TLS1.1/1.2 by Default
On 2 September 2012 10:58, Hiroshi Miura miur...@linux.com wrote: -Set TLS1.1/1.2 disabled by Default that is same as Windows 7 default. Aside from whether disabling TLS1.1+ is appropriate or not, or if this is the right implementation, this patch also add %COMPAT to the priority string, which wasn't there before.
Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).
On Sun, Sep 2, 2012 at 2:18 PM, Charles Davis cdavi...@gmail.com wrote: ... Er, uh, what patch? Bah, usually Google warns me when I do that! Thanks! Erich
Re: winhttp: disable TLSv1.1/1.2 by default
On 26 August 2012 18:56, André Hentschel n...@dawncrow.de wrote: It's for http://bugs.winehq.org/show_bug.cgi?id=30598 So it has its reason So assuming I don't feel like reading through various bug trackers to figure this out, what is the specific issue this patch is supposed to address?
Re: d3dx9_36: Implement D3DXSHRotate
On 02.09.2012 22:28, Nozomi Kodama wrote: +for (order = 0; order 10; order++) Is there a reason why we'd want to test til 9? D3DXSH_MAXORDER is 6, so 7 Should be enough? I know the other test do this, but technically I see no reason for that. Specifically the if (.. order D3DXSH_MAXORDER) says exactly that, so no need to further than 7, since the parameters or did I miss something? I guess you'd also out of bounds? table[36 * j + i]; (for j=3 and i=99 = 207) since the table only has 4*36 = 144 elements. Cheers Rico
Re: wined3d: Use backup swapchain DC for devices created with desktop window.
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=21350 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PRO (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a.
Building winetest-latest.exe?
Hi folks, how does one build the native version of winetest.exe? I looked around a bit, and didn't see any obvious instructions. http://www.winehq.org/pipermail/wine-devel/2011-July/091144.html touches on it, but doesn't say much. I ask because I'm interested in tracking down why testbot doesn't think vcomp.dll is installed. ( cf. http://www.winehq.org/pipermail/wine-devel/2012-August/096642.html ) - Dan
Re: Building winetest-latest.exe?
As I understand it, you need to set up a mingw build as in http://wiki.winehq.org/CompilingDLLsUsingMingw
