Re: mscoree: Implement ICorDebug SetManagedHandler (try 2)
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=14737 Your paranoid android. === WVISTAADM (32 bit debugging) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Vista/w2k8/w7 users, please test mmdevapi base render test
Hi thank you for your results. Please test again using https://testbot.winehq.org/JobDetails.pl?Key=14738 + The crash in session tests should be gone, while render.c:887: Test failed: Initialize failed: 8889000f is left in until we gather more knowledge about sessions. + the exclusive mode should be handled correctly now, except - 5:1 IsSupported vs Initialize unchanged until we know more about 5:1 cards. - volume failure unchanged, I don't know those tests. (Saulius, a quick test is enough if there's no more issue) And how does the test handle multiple soundcards? Not at all. The tests uses solely the default multimedia rendering device. I'm not aware of another test (devenum would be the candidate) that enumerates devices for us to check whether Wine did a good job, like the winmm:wave and midi test do. BSD and other Wine users may also be interested in the tests, e.g. Francois' BSD81 system crashed http://test.winehq.org/data/e5ba60174ef931d299894bc1e8961c822f4809c4/bsd_fg-freebsd81-vm/mmdevapi:render.html and there's now better protection against failures (not in all places though). Regards, Jörg Höhle
Re: [1/4] winscard: implementation
2011/10/3 André Hentschel n...@dawncrow.de: Am 03.10.2011 09:31, schrieb Vincent Hardy: First submitted on wine-devel and modified following comments from Marcus Meissner (MAX_ATR_SIZE / bytecount). OK, some notes: winscard: implementation is a very bad name for a patch, especially for 4. Splitting the patches is a good idea, but you need to split it different (you are adding dead code). In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches Hi to all, I would like to help Vincent to get this patches in. But we need more objective help. The comments in this email and in previous Vincent email differ. One says send small patch the other says send full functionality patch series. I would like to restart this thread because otherwise it will be forgotten together with the patches. This is a whole new feature, in my short period into wine developing this is the first time I see a completely new thing being introduced. The first Vincent patch seems ok to me, it adds the pcsclite to configure system and loads the library. I think this first patch should be commited after the next release cycle tomorrow so we will have two weeks to implement the rest of the functions, I talked to Vincent and he agreed with me that we can send one patch per function filled with tests that probably only he and me will be able to test since we have supported readers. Is this reasonable? In the order there would be patches for ScardEstablishContext, SCardListReaders, SCardGetStatus, SCardConnect, SCardTransmit. All of them with a series os tests and skips if the reader is not available or if the card is not available avoiding failures to other users. Non-users of smart cards may think this feature is not useful but I say it's a very important step and worth a line in the news when it gets implemented. Please, help us. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...
Re: [1/4] winscard: implementation
On Thu, Oct 6, 2011 at 8:07 AM, Bruno Jesus 00cp...@gmail.com wrote: ... This is a whole new feature, in my short period into wine developing this is the first time I see a completely new thing being introduced. I'd take a look at usbd.sys, as it was introduced relatively recently. Generally for the first patch everything is just stubs: http://www.winehq.org/pipermail/wine-cvs/2010-March/065163.html I'm not sure about your other questions, but I figured that commit would at least help you get started. Erich Hoover ehoo...@mines.edu
Re: mscoree: Implement ICorDebug SetManagedHandler (try 2)
Still not sure there should be only one ICorDebug per runtime host. It seems like you might want to create multiple interfaces and use them independently.
Re: Vista/w2k8/w7 users, please test mmdevapi base render test
On Thu, 6 Oct 2011, joerg-cyril.hoe...@t-systems.com wrote: Hi thank you for your results. Please test again using https://testbot.winehq.org/JobDetails.pl?Key=14738 Hi Jörg, I think your tests are actually correct, though could use a tiny bit more crash-proofing. On closer look, my capture setup seems to be broken on the E-MU 0202 USB - due to driver trouble. I get a later crash in your test this time though. render.c:167: Returned periods: 10. ms 3. ms render.c:179: pwfx: 00961AA0 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:251: Initialize(duration=0) GetBufferSize is 1440 render.c:315: Returned latency: 10. ms render.c:388: IsSupported(exclus., 44100x16x2) render.c:388: IsSupported(exclus., 48000x16x2) render.c:388: IsSupported(shared , 48000x 8x2) render.c:388: IsSupported(shared , 48000x16x2) render.c:897: Test failed: Initialize failed for capture in rendering session: 8889000f render.c:906: Tests skipped: No capture session: 8889000f; skipping capture device in render session tests render.c:1482: Test failed: Initialize failed: 8889000f render.c:1486: Test failed: GetService failed: 88890001 render.c:1486: this is the last test seen before the exception render: unhandled exception c005 at 76EC8DA9 When I disable my known-broken microphone device on the 0202, I get no failures. render.c:167: Returned periods: 10. ms 3. ms render.c:179: pwfx: 00921AA0 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:251: Initialize(duration=0) GetBufferSize is 1440 render.c:315: Returned latency: 10. ms render.c:388: IsSupported(exclus., 44100x16x2) render.c:388: IsSupported(exclus., 48000x16x2) render.c:388: IsSupported(shared , 48000x 8x2) render.c:388: IsSupported(shared , 48000x16x2) render.c:906: Tests skipped: No capture session: 80070490; skipping capture device in render session tests render: 668 tests executed (0 marked as todo, 0 failures), 1 skipped. And on the cheapo USB headset, I still only get the GetVolume failures. -- -erik http://useofwords.blogspot.com/
Re: [1/4] winscard: implementation
Am Donnerstag 06 Oktober 2011, 16:07:29 schrieb Bruno Jesus: 2011/10/3 André Hentschel n...@dawncrow.de: Am 03.10.2011 09:31, schrieb Vincent Hardy: First submitted on wine-devel and modified following comments from Marcus Meissner (MAX_ATR_SIZE / bytecount). OK, some notes: winscard: implementation is a very bad name for a patch, especially for 4. Splitting the patches is a good idea, but you need to split it different (you are adding dead code). In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches Hi to all, I would like to help Vincent to get this patches in. But we need more objective help. The comments in this email and in previous Vincent email differ. One says send small patch the other says send full functionality patch series. I would like to restart this thread because otherwise it will be forgotten together with the patches. This is a whole new feature, in my short period into wine developing this is the first time I see a completely new thing being introduced. Hi, have a look at http://www.winehq.org/pipermail/wine-devel/2007-May/057057.html . There you find the reason why the patches did not go in the first time. Bye Stefan
WINMM_OpenDevice Activate failed
Hi Andrew, I saw you modified the Audio tab of winecfg to let the user choose a device. You're really doing a great job considering the mess behind it (audio architecture drivers). I tested the latest wine and noticed that when you click the Test Sound button, there is no error but if you do it again (or several times), there is a err:winmm:WINMM_OpenDevice Activate failed: 80004005 on the console. Harmless but probably worth fixing.
Re: [patch] Fake display interface
Hello, I have updated this to support multiple resolutions( frequencies) and also made it use only one registry key. If the registry key is empty, or does not exist, or WINE_FAKEDISP environment variable is not defined it won't be used at all. Syntax is the same, expect you can separate multiple resolutions with semicolon(;) I've been using it for a while now, and find it really useful for applications that might change resolution. Also keeping both monitors alive (Game on other monitor for example, while doing stuff on other). And it can also make games use resolution that is normally unsupported. Here is screen of Ys Origins running 1440x900 where it normally does not: http://ompldr.org/vYW91NA/YsOrigins.png Just let you know, if anyone else found the patch useful. Cheers. 2011/9/6 Jari Vetoniemi mailro...@gmail.com: Well, I did the patch mostly for personal use and dropped here as some might find it useful. If wine ever needs something like this, let's say for testing or for some people wanting to fake display information, or do not want to use XRandR or others for some reason, then it would at least need to support multiple resolutions I guess. ATM it only supports one, also it would be good to get rid of the useless registry keys and just provide one with same syntax as the environment variable one. Both should be easy to implement, I don't know where wine gets/sends the color depth information, so it could be faked too, but I'm not sure if it's worth it. But the patch should do the faking clean way, I guess. It's just another interface like the XRandR selector and such. As for, do we need it? I don't know. I need it :) Correct way to add it? See above, but I highly suspect this ever getting into mainline. It's not correct behavior and is quite niche patch. Does the patch look good? See above, registry keys could be cleaned and multiple resolutions separated with eg ';' letter would be nice. Also I'm not sure what is the take on defining environment variables. 2011/9/6 GOUJON Alexandre ale.gou...@gmail.com: On 09/06/2011 02:25 PM, Jari Vetoniemi wrote: I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp. IMO, there is a need and your patch is a solution (among other). Is there a relevant developer able to answer these questions ? - Do we need this feature ? - If so, what is the correct/clean way to add it into mainline ? - Does the patch look good or what is wrong ? I know there is no [RFC] in the subject of this thread but you're definitely requesting comments.
Re: [patch] Fake display interface
Bleh, Forgot to include the updated patch. There we go! 2011/10/6 Jari Vetoniemi mailro...@gmail.com: Hello, I have updated this to support multiple resolutions( frequencies) and also made it use only one registry key. If the registry key is empty, or does not exist, or WINE_FAKEDISP environment variable is not defined it won't be used at all. Syntax is the same, expect you can separate multiple resolutions with semicolon(;) I've been using it for a while now, and find it really useful for applications that might change resolution. Also keeping both monitors alive (Game on other monitor for example, while doing stuff on other). And it can also make games use resolution that is normally unsupported. Here is screen of Ys Origins running 1440x900 where it normally does not: http://ompldr.org/vYW91NA/YsOrigins.png Just let you know, if anyone else found the patch useful. Cheers. 2011/9/6 Jari Vetoniemi mailro...@gmail.com: Well, I did the patch mostly for personal use and dropped here as some might find it useful. If wine ever needs something like this, let's say for testing or for some people wanting to fake display information, or do not want to use XRandR or others for some reason, then it would at least need to support multiple resolutions I guess. ATM it only supports one, also it would be good to get rid of the useless registry keys and just provide one with same syntax as the environment variable one. Both should be easy to implement, I don't know where wine gets/sends the color depth information, so it could be faked too, but I'm not sure if it's worth it. But the patch should do the faking clean way, I guess. It's just another interface like the XRandR selector and such. As for, do we need it? I don't know. I need it :) Correct way to add it? See above, but I highly suspect this ever getting into mainline. It's not correct behavior and is quite niche patch. Does the patch look good? See above, registry keys could be cleaned and multiple resolutions separated with eg ';' letter would be nice. Also I'm not sure what is the take on defining environment variables. 2011/9/6 GOUJON Alexandre ale.gou...@gmail.com: On 09/06/2011 02:25 PM, Jari Vetoniemi wrote: I have them both disabled, however then some applications won't work because they don't get any resolution information. I only use FakeDisp. IMO, there is a need and your patch is a solution (among other). Is there a relevant developer able to answer these questions ? - Do we need this feature ? - If so, what is the correct/clean way to add it into mainline ? - Does the patch look good or what is wrong ? I know there is no [RFC] in the subject of this thread but you're definitely requesting comments. fakedisp_interface.patch Description: Binary data
Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
Hi Folks, I try to send out a periodic message to the wine-devel mailing list outlining the 'corporate' structure of Wine and how some decisions are made. We work with the Software Freedom Conservancy. They manage the pieces of Wine that benefit from a formal organization, such as managing money, holding Trademarks, and so on. The primary activity we have conducted with them over the past several years is managing money - about $3,000 each year. They manage all funds donated to Wine - the donate button goes into a bank account they manage and any larger private donations go there as well. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, we have a decision group and we require a majority of members to approve any spending. Alexandre and I are the current members of that group. We also claim the right to appoint anyone else to replace or augment the decision group. We CC all decisions to an auditor. We have recently asked Michael Stefanuic to replace Zachary Goldberg in that role. A critical requirement, we feel, is that a non CodeWeavers staff member be fully aware of all decisions made. We choose this strategy rather than a fully public process so that we can apply discretion and protect privacy of people that ask for help with travel funding. The SFC will recognize a 'revolt' by the Wine project. That is, the designated decision group can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has primarily been to help defray travel costs for Wine contributors to come to Wineconf. Wine's income has been around $3,000 / year for the past few years; we tend to spend down much of the balance each year for Wineconf. Cheers, Jeremy p.s. One note - the SFC also manages the GSOC payments, although I believe that they ostensibly manage that on behalf of Google, not really Wine. That is generally coordinated by Wine's GSOC coordinator, and Alexandre and I have nothing to do with it.
Wine Gecko 1.4-beta1
Hi all,
I've just uploaded new Gecko builds [1]. To use it, you need the
attached patch and the build installed to the right place [2]. As
usually, everything that uses MSHTML is worth testing. All testing and
feedback will be appreciated.
Thanks,
Jacek
[1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.4-beta1/
[2] http://wiki.winehq.org/Gecko
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index 95e4fe8..868e9d9 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.3
+#define GECKO_VERSION 1.4-beta1
#ifdef __i386__
#define ARCH_STRING x86
diff --git a/dlls/mshtml/editor.c b/dlls/mshtml/editor.c
index 3a8b654..ae5954a 100644
--- a/dlls/mshtml/editor.c
+++ b/dlls/mshtml/editor.c
@@ -182,7 +182,6 @@ static void set_ns_align(HTMLDocument *This, const char
*align_str)
static DWORD query_align_status(HTMLDocument *This, const WCHAR *align)
{
DWORD ret = OLECMDF_SUPPORTED | OLECMDF_ENABLED;
-nsIDOMNSHTMLDocument *nsdoc;
nsAString justify_str;
PRBool b;
nsresult nsres;
@@ -190,21 +189,12 @@ static DWORD query_align_status(HTMLDocument *This, const
WCHAR *align)
if(This-doc_obj-usermode != EDITMODE || This-window-readystate
READYSTATE_INTERACTIVE)
return OLECMDF_SUPPORTED;
-
-nsres = nsIDOMHTMLDocument_QueryInterface(This-doc_node-nsdoc,
IID_nsIDOMNSHTMLDocument,
-(void**)nsdoc);
-if(NS_FAILED(nsres)) {
-ERR(Could not get nsIDOMNSHTMLDocument iface: %08x\n, nsres);
-return 0;
-}
-
nsAString_Init(justify_str, align);
-nsres = nsIDOMNSHTMLDocument_QueryCommandState(nsdoc, justify_str, b);
+nsres = nsIDOMHTMLDocument_QueryCommandState(This-doc_node-nsdoc,
justify_str, b);
nsAString_Finish(justify_str);
if(NS_SUCCEEDED(nsres) b)
ret |= OLECMDF_LATCHED;
-nsIDOMNSHTMLDocument_Release(nsdoc);
return ret;
}
diff --git a/dlls/mshtml/htmldoc.c b/dlls/mshtml/htmldoc.c
index 0636a04..1db608d 100644
--- a/dlls/mshtml/htmldoc.c
+++ b/dlls/mshtml/htmldoc.c
@@ -813,9 +813,9 @@ static HRESULT document_write(HTMLDocument *This, SAFEARRAY
*psarray, BOOL ln)
if(V_VT(var+i) == VT_BSTR) {
nsAString_SetData(nsstr, V_BSTR(var+i));
if(!ln || i != argc-1)
-nsres = nsIDOMHTMLDocument_Write(This-doc_node-nsdoc,
nsstr);
+nsres = nsIDOMHTMLDocument_Write(This-doc_node-nsdoc,
nsstr, NULL /* FIXME! */);
else
-nsres = nsIDOMHTMLDocument_Writeln(This-doc_node-nsdoc,
nsstr);
+nsres = nsIDOMHTMLDocument_Writeln(This-doc_node-nsdoc,
nsstr, NULL /* FIXME! */);
if(NS_FAILED(nsres))
ERR(Write failed: %08x\n, nsres);
}else {
@@ -851,6 +851,7 @@ static HRESULT WINAPI HTMLDocument_open(IHTMLDocument2
*iface, BSTR url, VARIANT
VARIANT features, VARIANT replace, IDispatch
**pomWindowResult)
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
+nsISupports *tmp;
nsresult nsres;
static const WCHAR text_htmlW[] = {'t','e','x','t','/','h','t','m','l',0};
@@ -867,12 +868,15 @@ static HRESULT WINAPI HTMLDocument_open(IHTMLDocument2
*iface, BSTR url, VARIANT
|| V_VT(features) != VT_ERROR || V_VT(replace) != VT_ERROR)
FIXME(unsupported args\n);
-nsres = nsIDOMHTMLDocument_Open(This-doc_node-nsdoc);
+nsres = nsIDOMHTMLDocument_Open(This-doc_node-nsdoc, NULL, NULL, NULL,
NULL, 0, tmp);
if(NS_FAILED(nsres)) {
ERR(Open failed: %08x\n, nsres);
return E_FAIL;
}
+if(tmp)
+nsISupports_Release(tmp);
+
*pomWindowResult = (IDispatch*)This-window-IHTMLWindow2_iface;
IHTMLWindow2_AddRef(This-window-IHTMLWindow2_iface);
return S_OK;
@@ -902,19 +906,11 @@ static HRESULT WINAPI HTMLDocument_close(IHTMLDocument2
*iface)
static HRESULT WINAPI HTMLDocument_clear(IHTMLDocument2 *iface)
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
-nsIDOMNSHTMLDocument *nsdoc;
nsresult nsres;
TRACE((%p)\n, This);
-nsres = nsIDOMHTMLDocument_QueryInterface(This-doc_node-nsdoc,
IID_nsIDOMNSHTMLDocument, (void**)nsdoc);
-if(NS_FAILED(nsres)) {
-ERR(Could not get nsIDOMNSHTMLDocument iface: %08x\n, nsres);
-return E_FAIL;
-}
-
-nsres = nsIDOMNSHTMLDocument_Clear(nsdoc);
-nsIDOMNSHTMLDocument_Release(nsdoc);
+nsres = nsIDOMHTMLDocument_Clear(This-doc_node-nsdoc);
if(NS_FAILED(nsres)) {
ERR(Clear failed: %08x\n, nsres);
return E_FAIL;
@@ -1317,7 +1313,6 @@ static HRESULT WINAPI
HTMLDocument_get_styleSheets(IHTMLDocument2 *iface,
{
HTMLDocument *This = impl_from_IHTMLDocument2(iface);
nsIDOMStyleSheetList *nsstylelist;
-nsIDOMDocumentStyle *nsdocstyle;
nsresult nsres;
TRACE((%p)-(%p)\n, This, p);
@@ -1329,16 +1324,14
Re: [PATCH] winecoreaudio.drv: Reimplement IAudioClock::GetPosition()
Andrew Eikum aei...@codeweavers.com writes: --- dlls/winecoreaudio.drv/mmdevdrv.c | 27 +-- 1 files changed, 9 insertions(+), 18 deletions(-) This fails for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c touch wave.ok wave.c:498: Test failed: waveOutGetPosition(0): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(0): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(0): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(0): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(0): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(0): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(WAVE_MAPPER): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(WAVE_MAPPER): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(WAVE_MAPPER): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(WAVE_MAPPER): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(WAVE_MAPPER): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(WAVE_MAPPER): TICKS test failed make: *** [wave.ok] Error 24 -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)
Bernhard Loos bernhardl...@googlemail.com wrote: +int debug_childs:1; /* also debug all child processes */ 'debug_children' would be a better name. -- Dmitry.
