"winetricks dotnet40" fails verifier because System.EnterpriseServices.Wrapper.dll missing?
With current git, when I try rm -rf .wine sh winetricks -q dotnet40 sh winetricks -q dotnet_verifier wine netfx_setupverifier.exe the verifier reports failure: ... [07/04/12,21:45:13] ERROR File C:\windows\Microsoft.NET\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll is not installed on the system ... [07/04/12,21:45:15] ERROR Verification failed for product .NET Framework 4 Client That file does seem to be on disc, but somewhere else: c:/windows/Microsoft.NET/Framework/v4.0.30319/System.EnterpriseServices.Wrapper.dll Not sure how serious it is that that's misplaced. Have other folks seen this? - Dan
Policy for the Wiki?
Hello all, I've been working on the wiki recently and noticed that a lot of out-of-date or redundant information is retained. For example, completed tasks on to-do lists are checked off and never removed. Isthere an unofficial policy of not deleting info, even if it may exist elsewhere (in the git repo history, wikipage revision history, etc)? Other instances might be stubs dedicated to features in development years ago, or pages on bugs that have already been fixed or triaged in Bugzilla.I know even page deletions can still be reverted, but I wanted to check first before cleaning things out more aggressively. If there are a few unwritten rules everyone likes the wiki to follow, I could add them somewhere as editing guidelines. While the topic's up, I was also wondering how moinmoin was chosen as the wiki engine. I couldn't really find a discussion on the mailing lists so I figured it was the best option when the wiki was first started. I can appreciate that it doesn't require a database and it's written in python instead of php. Allowing only inline CSS in tables causes some headaches, but mainly it can be really slow sometimes, especially when editing, and unless using wikilinks or going directly to a page, navigation is tricky. Has the possibility of migrating the wiki to a different engine ever come up? Or does the Wine wiki code just need some tweaking and maybe some tools? To be honest, I don't know if there is a better alternative (MediaWiki is designed for a very different use case and has really messy code). It just seems like something is discouraging even basic upkeep on the wiki, which kind of defeats its whole purpose. -Kyle
Re: [PATCH] winepulse.drv: Add PulseAudio driver
Hey Joerg, 2012/6/26 : > Hi, > >>If you don't paste all the mmdevapi tests with the fix in my git tree, it's a >>regression. I don't want to see held_Frames because it's a shadow buffer. >>If winmm and dsound don't work without it, they're wrong, fix those. > > I won't comment on the two individual pulseaudio drivers. Unfortunately, none > of the two authors bothered to point me to a verbose log of the mmdevapi > tests for my scrutiny. > > The tests should pass like they do on native. > > Regarding latency, I'm not aware of a flaw in Wine's winmm. > HOWEVER, Wine's DSound needs a patch. Here the reason. > > To recap, latency is somehow related to the "distance" between what > one hears and the PCM frames sent to the device. GetPosition is the > only API call in that area in both winmm and mmdevapi. > > Buffer size is a completely different thing. I find it useful to have > in mind a cascade of audio filters performing some buffering each. > Then it's obvious that an app only sees the frontmost buffer size and > knows nothing about the others. High latencies imply that there > must be some large buffer space(s), somewhere. > > Period is an artificial entity related to how often the frontmost > buffer is drained to feed the next buffer in the chain, in case that > happens regularly. This is not guaranteed nor necessarily documented. > > You get the idea: regardless of arbitrary (front) buffer sizes and > periods not worth this name, try and send a stable flow of data to > play music without glitches and let explosions be heard ASAP. > > So far the situation, now the issue. It appears easier to write code > that provides (frontmost) buffer space behaviour similar to native than > one that provides similar latency. > > Alas, behaviour observable on MS-Windows differs from what we get with > PulseAudio and some ALSA devices. > > Tests seem to indicate a latency of around 30-70ms from mmdevapi with > MS-Windows. That good enough for games. OTOH if ALSA or PA gives us > 2 seconds on Linux, that's a big cause of trouble. The authors of MS > apps could never test them in an environment with such high latency. > What happens with software not tested? It happens not to work. > > Two solutions: > - Reduce actual latency or > - lie about latency. > > Lying about latency causes apps to loose the ability to sync audio and > video. However, given a choice between loss of lip sync and possible > crashes or other weird behaviour because an app is executed in a > environment that its developers never experienced, I consider the loss > of lip sync to be less worrying. > > We designed the winealsa driver to accomodate an arbitrary latency and > accept a large variation of periods. (Some bug report from Jack users > seem to imply that it should accept even larger periods, e.g. 150ms, > yet still pretend to use 10ms on the mmdevapi side). > > We choose to have the winealsa driver not lie about latency. That > should be left to high level APIs. > > DirectSound is built around the "Direct" HW (lack of) abstraction: a > circular buffer of samples is played by a DAC. The converted signal > is immediately sent to the speaker. Hence: > > 1. GetPosition information in the DSound abstraction translates to >a "playpos" -- well known. > > 2. No provision is made for additional buffering. The playpos must >lie within the circular buffer. The reported free (writable) space >shall never cross the playpos -- with subtle consequences. > > Wine's DSound needs a patch to ensure this second property. Given a > 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 > seconds late! > > I think Wine should try and reduce latency but lie if that does not suffice. > > What's needed? > 1. Have DSound always use a buffer large enough for typical situations >(I believe 100-200ms). > > 2. Clamp the reported position such that it won't leave the (virtual) >primary buffer. As a result, DSound must pretend to play even when >Wine is solely pumping the huge 2s of cascading SW audio buffers. > > 3. Work on reducing the latency of the cascading audio filters. >That device-level work is independent on the DSound one. > > Native's 30-70ms has the benefit that it nicely fits within typical > DSound primary buffer sizes. PulseAudio's 2s does not (yet). > I believe a total 80ms latency would be acceptable with games. > > > Further areas of investigation and effort: > > - Maybe clamp latency in the mmdevapi drivers after all? After all, >huge latencies are known to cause dead-locks in apps and we don't >know what all apps or libraries built atop mmdevapi or winmm expect. >(If yes, to what value? 150% buffer size?) > > - Try and find MS setups with huge latencies. >USB headphones are said to be candidates, but I've yet to see an >excellent and trustworthy report about what happens in that case. > > - Work on reducing the cascades of audio buffers > > - Work on further decoupling m
Re: League of Legends patches
On Tue, Jul 3, 2012 at 3:45 PM, Dan Kegel wrote: > On Tue, Jul 3, 2012 at 1:08 AM, Andrea Canciani wrote: >> I tried to follow the http://wiki.winehq.org/SubmittingPatches >> guidelines, but this is my first submission to wine, so I guess the >> patches might need further improvement. >> Please point out any issues that need fixing. > > On an administrivial note, you should send one patch per > email to wine-patches. Oops, sorry! Will do next time (which might be soon enough, given the regression in ieframe and the missing deadlock test) > > Do you think you could write a test that (semi-)reliably > causes the deadlock you're fixing? Yes, I guess it should be possible. Could you point me to a test which triggers a deadlock (in particular, how should the deadlock be handled?) I tried git-grep'ing for deadlock in the tests, but I only found checks for deadlock-named constants/values. > >> The patches have been tested by Dan Kegel (in CC) and are currently >> being used by many MacOSX and Linux users to run LoL. > > Our emails may have crossed - with these patches applied, > dlls/ieframe/tests/webbrowser.ok seems to crash here: > > Unhandled exception: privileged instruction in 32-bit code (0x02786624). > Backtrace: > =>0 0x02786624 (0x0032fcd8) > 1 0x688e22db func_webbrowser+0x3ca() [dlls/ieframe/tests/webbrowser.c:3382] > Yes, I sent the e-mail just before finding out about this issue. I will probably need to set up a proper wine development environment to find out more about it (I have a ubuntu 12.04 x86 vm, but even wine/master fails the testsuite on it). > Otherwise the tests seem to pass. > > Thanks, > Dan
Re: [1/4] gdiplus: Add a test for font and graphics using different base units. Resend.
Vincent Povirk wrote: > > +todo_wine > > +expectf(102.499985, bounds.Width); > > Please don't hard-code string widths in your tests. It's not likely or > desirable to get them exactly right. That's why I'm using 10% bias for comparisons in 4/4. -- Dmitry.
Re: [1/4] gdiplus: Add a test for font and graphics using different base units. Resend.
> +todo_wine > +expectf(102.499985, bounds.Width); Please don't hard-code string widths in your tests. It's not likely or desirable to get them exactly right.
Re: include: fix mingw64 build
On 07/03/12 20:10, Jacek Caban wrote: > On 06/29/12 03:35, Austin English wrote: >> On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote: >>> 2012/6/29 Austin English : Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 -- -Austin >>> Hi Austin, >>> >>> I already tried to fix it on Wine side, see [1], >>> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >>> as it shouldn't include crtdefs.h by default. >>> >>> BTW, won't that break mingw32 build ? >>> >>> [1] http://source.winehq.org/patches/data/84070 >>> >>> -- >>> Nicolas Le Cam >> Thanks for the info. Have you or anyone else discussed this with >> mingw64? I did a quick search on their bugtracker, but don't see >> anything.. >> http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=artifact&group_id=202880&words=crtdefs > FWIW, here is my proposed patch to mingw-w64: > > http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f > > We will see if they like it. The (extended) fix is in mingw-w64 SVN now. Jacek
New Wine Gecko 1.7-beta1
Hi all,
It's a bit sooner for another Gecko update than usually. This is caused
by the fact, that many existing bugs in our MSHTML are blocked by
another bugs, which require Gecko changes for proper fix. These changes
enable using Gecko's cycle collector to understand our objects. This
solves quite a few problems. The update also contains merged Firefox 14
beta changes. To test it, download Wine Gecko [1] and install it as
usually [2]. You will also need the attached patch. The patch contains
not only Gecko API changes, but also partial (but substantial enough for
test to be meaningful) support for cycle collector in MSHTML. You may
find some bugs already fixed by this patch.
Any help with testing will be appreciated.
Thanks,
Jacek
[1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.7-beta1/
[2] http://wiki.winehq.org/Gecko
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index 8e93dee..f820250 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.6"
+#define GECKO_VERSION "1.7-beta1"
#ifdef __i386__
#define ARCH_STRING "x86"
diff --git a/dlls/mshtml/dispex.c b/dlls/mshtml/dispex.c
index 66dad69..6b9c1d3 100644
--- a/dlls/mshtml/dispex.c
+++ b/dlls/mshtml/dispex.c
@@ -1350,6 +1350,38 @@ BOOL dispex_query_interface(DispatchEx *This, REFIID
riid, void **ppv)
return TRUE;
}
+void dispex_traverse(DispatchEx *This, nsCycleCollectionTraversalCallback *cb)
+{
+dynamic_prop_t *prop;
+
+if(!This->dynamic_data)
+return;
+
+for(prop = This->dynamic_data->props; prop < This->dynamic_data->props +
This->dynamic_data->prop_cnt; prop++) {
+if(V_VT(&prop->var) == VT_DISPATCH)
+note_cc_edge((nsISupports*)V_DISPATCH(&prop->var), "dispex_data",
cb);
+}
+
+/* FIXME: Traverse func_disps */
+}
+
+void dispex_unlink(DispatchEx *This)
+{
+dynamic_prop_t *prop;
+
+if(!This->dynamic_data)
+return;
+
+for(prop = This->dynamic_data->props; prop < This->dynamic_data->props +
This->dynamic_data->prop_cnt; prop++) {
+if(V_VT(&prop->var) == VT_DISPATCH) {
+V_VT(&prop->var) = VT_EMPTY;
+IDispatch_Release(V_DISPATCH(&prop->var));
+}else {
+VariantClear(&prop->var);
+}
+}
+}
+
void release_dispex(DispatchEx *This)
{
dynamic_prop_t *prop;
diff --git a/dlls/mshtml/htmldoc.c b/dlls/mshtml/htmldoc.c
index 53e98c7..32d0567 100644
--- a/dlls/mshtml/htmldoc.c
+++ b/dlls/mshtml/htmldoc.c
@@ -2080,13 +2080,14 @@ static void HTMLDocumentNode_destructor(HTMLDOMNode
*iface)
detach_selection(This);
detach_ranges(This);
-release_nodes(This);
while(!list_empty(&This->plugin_hosts))
detach_plugin_host(LIST_ENTRY(list_head(&This->plugin_hosts),
PluginHost, entry));
-if(This->nsdoc)
+if(This->nsdoc) {
release_document_mutation(This);
+nsIDOMHTMLDocument_Release(This->nsdoc);
+}
heap_free(This->event_vector);
destroy_htmldoc(&This->basedoc);
@@ -2099,10 +2100,44 @@ static HRESULT HTMLDocumentNode_clone(HTMLDOMNode
*iface, nsIDOMNode *nsnode, HT
return E_NOTIMPL;
}
+static void HTMLDocumentNode_traverse(HTMLDOMNode *iface,
nsCycleCollectionTraversalCallback *cb)
+{
+HTMLDocumentNode *This = impl_from_HTMLDOMNode(iface);
+
+if(This->nsdoc)
+note_cc_edge((nsISupports*)This->nsdoc, "This->nsdoc", cb);
+}
+
+static void HTMLDocumentNode_unlink(HTMLDOMNode *iface)
+{
+HTMLDocumentNode *This = impl_from_HTMLDOMNode(iface);
+
+if(This->nsdoc) {
+nsIDOMHTMLDocument *nsdoc = This->nsdoc;
+
+release_document_mutation(This);
+This->nsdoc = NULL;
+nsIDOMHTMLDocument_Release(nsdoc);
+}
+}
+
static const NodeImplVtbl HTMLDocumentNodeImplVtbl = {
HTMLDocumentNode_QI,
HTMLDocumentNode_destructor,
-HTMLDocumentNode_clone
+HTMLDocumentNode_clone,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+HTMLDocumentNode_traverse,
+HTMLDocumentNode_unlink
};
static HRESULT HTMLDocumentFragment_clone(HTMLDOMNode *iface, nsIDOMNode
*nsnode, HTMLDOMNode **ret)
@@ -2237,8 +2272,7 @@ HRESULT create_doc_from_nsdoc(nsIDOMHTMLDocument *nsdoc,
HTMLDocumentObj *doc_ob
HTMLDOMNode_Init(doc, &doc->node, (nsIDOMNode*)nsdoc);
-/* No AddRef, share the reference with nsnode */
-assert((nsIDOMNode*)nsdoc == doc->node.nsnode);
+nsIDOMHTMLDocument_AddRef(nsdoc);
doc->nsdoc = nsdoc;
init_document_mutation(doc);
diff --git a/dlls/mshtml/htmlnode.c b/dlls/mshtml/htmlnode.c
index 3951494..6bdddce 100644
--- a/dlls/mshtml/htmlnode.c
+++ b/dlls/mshtml/htmlnode.c
@@ -17,6 +17,7 @@
*/
#include
+#include
#define COBJMACROS
@@ -312,7 +313,7 @@ static HRESULT WINAPI
HTMLDOMNode_QueryInterface(IHTMLDOMNode *iface,
static ULONG WINAPI HTMLDOM
Re: League of Legends patches
Dan Kegel wrote on Wed, 04 Jul 2012: (https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_blacklist.txt has a list of all the tests that the buildbot failed on while it was running The ones annotated with http://xquartz.macosforge.org/trac/ticket/512 should work with the latest XQuartz, as that bug has been fixed. Jonas
Re: League of Legends patches
On Wed, Jul 4, 2012 at 12:15 AM, Andrea Canciani wrote: >> Do you think you could write a test that (semi-)reliably >> causes the deadlock you're fixing? > > Yes, I guess it should be possible. > Could you point me to a test which triggers a deadlock (in particular, > how should the deadlock be handled?) http://bugs.winehq.org/show_bug.cgi?id=28362 says that the mshtml tests hang occasionally. The testsuite handles them by, well, hanging :-) Scripts that care about this add their own timeout. > Yes, I sent the e-mail just before finding out about this issue. > I will probably need to set up a proper wine development environment > to find out more about it (I have a ubuntu 12.04 x86 vm, but even > wine/master fails the testsuite on it). The testsuite does not, in general, fully pass on any machine but Alexandre's, so just generate a baseline by running the tests several times with "make -k test" without your patch, and saving the logs. Then repeat after applying your patch. (https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_blacklist.txt has a list of all the tests that the buildbot failed on while it was running, and you can run just the known good or known bad tests with https://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests.sh but that's overkill (or underkill) for you, and slightly out of date anyway.) - Dan
