RE: Possibility of adding a new patch status

[Hugh McMaster]

On Thursday, 1 August 2013 12:19 AM, Vincent Povirk wrote:
The problem is there are situations where patches are never reviewed and no 
one is told why.

After some thought, it occurred to me that the said patches are being reviewed; 
they just never have their status altered.

So, one possible way to work through this issue is to split the meaning of 
'Pending' into two parts.

'Pending' currently describes two actions for patches:

* The patch is not obviously correct at first glance. Making a more convincing 
argument, preferably in the form of a test case, may help.
* Waiting for feedback from the main developer in that area.

We could have:
* P1: The patch is not obviously correct at first glance. [Revision needed / 
Anything equivalent to go here].
* P2: Waiting for feedback from the main developer in that area.

Changing the patch status would then give an indication of action to be taken 
by the developer.  Of course, while these ideas are likely to provide greater 
clarity, the downside is that there is more work involved for the maintainer.

Wine Gecko 2.24-beta1

[Jacek Caban]

Hi all,

It's time to do another update of Wine Gecko, so I prepared a new beta
build. It's already on Sourceforge [1]. Until server-side support for
auto install of the package is committed [2], its manual installation is
required [3]. I attached a patch to Wine that is required for the new Gecko.

Anything that uses MSHTML is worth testing. All help with testing is
appreciated!

Cheers,
Jacek

[1] https://sourceforge.net/projects/wine/files/Wine%20Gecko/2.24-beta1/
[2] http://source.winehq.org/patches/data/97881
[3] http://wiki.winehq.org/Gecko
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index be6fb6d..c5070dc 100644
--- a/dlls/appwiz.cpl/addons.c
+++ b/dlls/appwiz.cpl/addons.c
@@ -53,14 +53,14 @@
 
 WINE_DEFAULT_DEBUG_CHANNEL(appwizcpl);
 
-#define GECKO_VERSION 2.21
+#define GECKO_VERSION 2.24-beta1
 
 #ifdef __i386__
 #define ARCH_STRING x86
-#define GECKO_SHA a514fc4d53783a586c7880a676c415695fe934a3
+#define GECKO_SHA 659cce1a0e2f4c6768aedf7bcbb4072e8a465c43
 #elif defined(__x86_64__)
 #define ARCH_STRING x86_64
-#define GECKO_SHA c6f249ff2c6eb7dfe423ef246aba54e1a3b26934
+#define GECKO_SHA 31f182f0e2003537aadb27328d3bcd8f3598b722
 #else
 #define ARCH_STRING 
 #define GECKO_SHA ???
diff --git a/dlls/mshtml/htmlelem.c b/dlls/mshtml/htmlelem.c
index db4b8e7..73e8f55 100644
--- a/dlls/mshtml/htmlelem.c
+++ b/dlls/mshtml/htmlelem.c
@@ -1728,8 +1728,8 @@ static HRESULT HTMLElement_invoke(DispatchEx *dispex, 
DISPID id, LCID lcid,
 static HRESULT HTMLElement_populate_props(DispatchEx *dispex)
 {
 HTMLElement *This = impl_from_DispatchEx(dispex);
-nsIDOMNamedNodeMap *attrs;
-nsIDOMNode *node;
+nsIDOMMozNamedAttrMap *attrs;
+nsIDOMAttr *attr;
 nsAString nsstr;
 const PRUnichar *str;
 BSTR name;
@@ -1747,40 +1747,40 @@ static HRESULT HTMLElement_populate_props(DispatchEx 
*dispex)
 if(NS_FAILED(nsres))
 return E_FAIL;
 
-nsres = nsIDOMNamedNodeMap_GetLength(attrs, len);
+nsres = nsIDOMMozNamedAttrMap_GetLength(attrs, len);
 if(NS_FAILED(nsres)) {
-nsIDOMNamedNodeMap_Release(attrs);
+nsIDOMMozNamedAttrMap_Release(attrs);
 return E_FAIL;
 }
 
 nsAString_Init(nsstr, NULL);
 for(i=0; ilen; i++) {
-nsres = nsIDOMNamedNodeMap_Item(attrs, i, node);
+nsres = nsIDOMMozNamedAttrMap_Item(attrs, i, attr);
 if(NS_FAILED(nsres))
 continue;
 
-nsres = nsIDOMNode_GetNodeName(node, nsstr);
+nsres = nsIDOMAttr_GetNodeName(attr, nsstr);
 if(NS_FAILED(nsres)) {
-nsIDOMNode_Release(node);
+nsIDOMAttr_Release(attr);
 continue;
 }
 
 nsAString_GetData(nsstr, str);
 name = SysAllocString(str);
 if(!name) {
-nsIDOMNode_Release(node);
+nsIDOMAttr_Release(attr);
 continue;
 }
 
 hres = IDispatchEx_GetDispID(dispex-IDispatchEx_iface, name, 
fdexNameCaseInsensitive, id);
 if(hres != DISP_E_UNKNOWNNAME) {
-nsIDOMNode_Release(node);
+nsIDOMAttr_Release(attr);
 SysFreeString(name);
 continue;
 }
 
-nsres = nsIDOMNode_GetNodeValue(node, nsstr);
-nsIDOMNode_Release(node);
+nsres = nsIDOMAttr_GetNodeValue(attr, nsstr);
+nsIDOMAttr_Release(attr);
 if(NS_FAILED(nsres)) {
 SysFreeString(name);
 continue;
@@ -1803,7 +1803,7 @@ static HRESULT HTMLElement_populate_props(DispatchEx 
*dispex)
 }
 nsAString_Finish(nsstr);
 
-nsIDOMNamedNodeMap_Release(attrs);
+nsIDOMMozNamedAttrMap_Release(attrs);
 return S_OK;
 }
 
diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c
index 5c40f41..65161fd 100644
--- a/dlls/mshtml/htmlwindow.c
+++ b/dlls/mshtml/htmlwindow.c
@@ -38,6 +38,7 @@
 #include mshtml_private.h
 #include htmlevent.h
 #include htmlscript.h
+#include pluginhost.h
 #include binding.h
 #include resource.h
 
@@ -114,8 +115,12 @@ static void detach_inner_window(HTMLInnerWindow *window)
 if(outer_window  outer_window-doc_obj  outer_window == 
outer_window-doc_obj-basedoc.window)
 window-doc-basedoc.cp_container.forward_container = NULL;
 
-if(window-doc)
+if(window-doc) {
 detach_events(window-doc);
+while(!list_empty(window-doc-plugin_hosts))
+
detach_plugin_host(LIST_ENTRY(list_head(window-doc-plugin_hosts), 
PluginHost, entry));
+}
+
 abort_window_bindings(window);
 remove_target_tasks(window-task_magic);
 release_script_hosts(window);
diff --git a/dlls/mshtml/nsembed.c b/dlls/mshtml/nsembed.c
index 4e72464..7fa13e5 100644
--- a/dlls/mshtml/nsembed.c
+++ b/dlls/mshtml/nsembed.c
@@ -486,7 +486,7 @@ static BOOL load_xul(const PRUnichar *gre_path)
 }
 
 #define NS_DLSYM(func) \
-func = (void *)GetProcAddress(xul_handle, #func _P); \
+func = (void *)GetProcAddress(xul_handle, #func); \
 if(!func) \
 ERR(Could not 

Re: mscoree: Redirect .NET 1.0 to .NET 2.0

[Vincent Povirk]

Looks good, thanks.

Re: mscoree: Attempt to load the assembly from the application directory

[Vincent Povirk]

This seems suspicious to me. You appear to be taking the namespace of
the class and assuming it's an assembly name.

Is there really no other information in the registry that could be
used to identify the assembly?

Re: msvcrt: add support for _chsize_s

[Ken Sharp]

On 14/08/13 20:08, morphiend wrote:

-@ stub _chsize_s
+@ cdecl _chsize_s(long int64) msvcrt._chsize
+#@ stub _chsize_s


Oops..

Re: mscoree: Attempt to load the assembly from the application directory

[Daniel Jeliński]

Hi Vincent,
there's no more info in the registry. At this point we have the assembly
name and we know that it is not in GAC, so either it is in current
directory or it's absent.

That being said, I think this is the wrong place for this change. Method
get_file_from_strongname [1] is better suited for that purpose IMO.
Also MSDN states that assembly name is not equivalent to file name. I
suppose that code to resolve assembly name into file name exists somewhere
in fusion.dll, but I have never seen it. Hans may know more.

Regards,
Daniel

[1] http://source.winehq.org/source/dlls/mscoree/metahost.c#L1213


2013/8/14 Vincent Povirk madewokh...@gmail.com

 This seems suspicious to me. You appear to be taking the namespace of
 the class and assuming it's an assembly name.

 Is there really no other information in the registry that could be
 used to identify the assembly?

Re: mscoree: Attempt to load the assembly from the application directory

[Vincent Povirk]

If we have the assembly name, then we should be using that to decide
on the filename to try in the application directory, not the
namespace.

Re: mscoree: Attempt to load the assembly from the application directory

[Vincent Povirk]

On Wed, Aug 14, 2013 at 4:04 PM, Daniel Jeliński djelins...@gmail.com wrote:
 That being said, I think this is the wrong place for this change. Method
 get_file_from_strongname [1] is better suited for that purpose IMO.

Doing it that way is probably more correct, but it's also more
dangerous because it would affect all assembly lookups. We'd then want
to check the precedence of dll's in the application directory vs. the
GAC, what happens when the filename matches but the strongname does
not, and whether other directories in the dll search path should be
considered.