March 2012 - Wine-Devel - list.winehq.org

Re: po: Update Korean translation
by Frédéric Delanoy March 14, 2012

March 14, 2012

On Wed, Mar 14, 2012 at 13:31, Hwang YunSong(황윤성) <hys545(a)dreamwiz.com>wrote: > fuzzy sections translated > You may also remove the "#| msgid ..." lines: these only indicate the former msgid, so you can see the difference quickly. Frédéric

1 0

Re: po: Spanish translation update (this patch supersedes previous patches fixing fuzzies)
by Frédéric Delanoy March 14, 2012

March 14, 2012

On Wed, Mar 14, 2012 at 22:57, Eduardo García <eduardo.garcia(a)gmx.com> wrote: > This patch fixes fuzzies and remove obsolete comments. > > With regards. > > Eduardo You may also remove the "#| msgid ..." lines: these only indicate the former msgid, so you can see the difference quickly. Also, add "(try N)" suffix when you submit a new version of a patch (that's a bit more concise than your "this patch... fuzzies") Frédéric

1 0

Re: My Idea for GSOC
by Stefan Dösinger March 14, 2012

March 14, 2012

Am Samstag, 10. März 2012, 17:22:51 schrieb Daniel Oom: > Hi, > > Writing tests, or implementing the command line tools seems like > something I could do. I'm kinda leaning towards the command line > tools, since it would offer a chance to thoroughly learn the shading > languages. For learning purposes writing tests and fixing bugs uncovered by them will be better. The command line tools are mostly about parsing parameters and forwarding them to d3dx9 functions(*). If you want to look a little bit in either proposal(we recommend that in general): For the test stuff, take a look at IDirect3DDeviceImpl_2_DrawPrimitive in dlls/ddraw/device.c. It thunks IDirect3DDevice2::DrawPrimitive to IDirect3DDevice7::DrawPrimitive. The main difference is the VertexType parameter. It is a D3DVERTEXTYPE in the IDirect3DDevice2 method, and a DWORD with D3DFVF_* flags in Device7. Our thunk simply converts between these two, but a deeper difference a user noticed is that D3DVT_LVERTEX in Device2 disables lighting calculations, whereas the equivalent D3DFVF flag collection in Device3 and Device7 does not. Device3 and newer have D3DRENDERSTATE_LIGHTING to enable / disable lighting, but this render state does not exist in Device2. Fixing this is fairly straightforward, just call SetRenderState(LIGHTING, ...) in the thunk, but it needs some tests to answer / show the following: * Show that D3DVT_LVERTEX indeed disables lighting, and D3DVT_VERTEX enables it * Show that D3DFVF_LVERTEX does not influence lighting in Device2 and Device7(D3DFVF_TLVERTEX disables all vertex processing in all d3d versions, this is already tested and implemented) * Test what happens when you call SetRenderState and GetRenderState in Device2. * Probably others There are numerous things like that that need testing and probably fixes. This is just one example that happens to be on my todo list. ddraw tests go to dlls/ddraw/tests/ddraw*.c. The other files should be moved to the tests/ddraw*.c files and extended to cover all ddraw versions. For the command line tools, download an older version of the directx sdk that still has vsa.exe and psa.exe(I think 2007 ones were the last ones) and compare their command line parameters to d3dx9.D3DXAssembleShaderFromFile and friends. The tests are certainly the more useful task. vsa.exe and psa.exe would mainly serve developer convenience when writing d3d8 and d3d9 tests since we wouldn't need an ancient dx sdk to assemble our own test shaders. d3d tests and fixes fix actual games. Enjoy, Stefan (*) Actually, that's not how native vsa/psa work. They seem to have their own copy-pasted version of the compiler and assembler, or they link statically. We should probably do it by calling d3dx9 though, especially for tools that mainly serve developer convenience.

3 2

Re: [PATCH 2/8] d3drm: Specify when a method is forwarded to another interface. (resend)
by Alexandre Julliard March 14, 2012

March 14, 2012

Christian Costa <titan.costa(a)gmail.com> writes: > @@ -438,7 +438,7 @@ static HRESULT WINAPI IDirect3DRMMeshBuilder2Impl_Load(IDirect3DRMMeshBuilder2* > { > IDirect3DRMMeshBuilderImpl *This = impl_from_IDirect3DRMMeshBuilder2(iface); > > - TRACE("(%p)->(%p,%p,%x,%p,%p): partial stub\n", This, filename, name, loadflags, cb, arg); > + TRACE("(%p)->(%p,%p,%x,%p,%p): forwarding to IDirect3DRMMeshBuilder3\n", This, filename, name, loadflags, cb, arg); > > return IDirect3DRMMeshBuilder3_Load(&This->IDirect3DRMMeshBuilder3_iface, filename, name, > loadflags, (D3DRMLOADTEXTURE3CALLBACK)cb, arg); I don't think that's an improvement. "Partial stub" makes a lot more sense for someone not deeply familiar with the code. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [1/2] advapi32: Fix failures in the security tests compiled with PSDK headers.
by Alexandre Julliard March 14, 2012

March 14, 2012

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -22,6 +22,9 @@ > #include <stdarg.h> > #include <stdio.h> > > +/* 0x0600 makes PROCESS_ALL_ACCESS not compatible with pre-Vista versions */ > +#define _WIN32_WINNT 0x0500 This will break once the Wine headers are updated. If the definition is not reliable the test should avoid it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: po: Update Lithuanian translation (resend)
by Alexandre Julliard March 14, 2012

March 14, 2012

Aurimas Fišeras <aurimas(a)gmail.com> writes: > @@ -2190,16 +2190,14 @@ msgstr "" > "atšauktų liudijimų sąrašą ar patikintų liudijimų sąrašą:" > > #: cryptui.rc:296 > -#, fuzzy > #| msgid "Cryptographic Message Syntax Standard/PKCS #7 Messages (.p7b)" > msgid "Cryptographic Message Syntax Standard/PKCS #7 Messages (*.p7b)" > -msgstr "Kriptografinio pranešimo sintaksės standarto/PKCS #7 pranešimai (.p7b)" > +msgstr "Kriptografinio pranešimo sintaksės standarto/PKCS #7 pranešimai (*.p7b)" You should also remove the previous string comment when updating fuzzy entries. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: jscript: Add VT_I2 support
by Jacek Caban March 14, 2012

March 14, 2012

Hi Alistair, On 03/14/12 10:00, Alistair Leslie-Hughes wrote: > --- a/dlls/jscript/jsutils.c > +++ b/dlls/jscript/jsutils.c > @@ -187,11 +187,14 @@ HRESULT to_primitive(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, VARIANT *ret > case VT_EMPTY: > case VT_NULL: > case VT_BOOL: > - case VT_I2: First of all, this is not a patch against current Git. You're changing core parts of jscript and I'd really like an evidence that it's done in the right direction. There are many parts of code that assume given types are returned as result, so I'm really picky about getting this right. In your previous test you had getVT that was hiding the difference between VT_I4 and VT_I2. I've asked you about better test and now you've removed tests that were using getVT at all and took my guesses as assumptions for implementation. Please add proper tests that really show your implementing things really the right way. Hint: it may be easier to concentrate one one aspect, say to_number which is easy to test, first. That patch may be well split. Cheers, Jacek

1 0

Re: kernel32/tests: Verify the stability of CreateTimerQueue.
by Austin English March 14, 2012

March 14, 2012

On Wed, Mar 14, 2012 at 05:32, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > this should have been labeled [PATCH 3/3] because tests will fail without my 2 ntdll patches. > > First a note unrelated to my patches: if you run the tests in git in a loop, > sometimes one DeleteTimerQueueTimer(INVALID_HANDLE_VALUE) > fails (presumably with IO_PENDING) because a callback was executing concurrently. > Did Dan or anybody else running tests repeatedly observe this? > Surprisingly, test.winehq shows next to nothing like this: > http://test.winehq.org/data/tests/kernel32:sync.html > but one failure comes close (not sure if it's the same): > http://test.winehq.org/data/e79644e6a96eae419082ec78ce8ff3294888d05d/2000_f… > sync.c:867: Test failed: DeleteTimerQueueTimer The list of tests that are skipped by buildbot is at: http://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_blac… kernel32/sync is not on the list (nor do I see any emails from buildbot for it failing). -- -Austin

1 0

Having problems with building a deb package of the sources
by Rahul Ghose March 14, 2012

March 14, 2012

I am using the 1.4-rc6 source code to build the deb package. The source compiles smoothly but debuild -us -uc fails with this message: (last few lines, I hope which are more relevant) ../../../tools/runtest -q -P wine -M atl.dll -T ../../.. -p atl_test.exe.soatl_ax.c && touch atl_ax.ok Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:systray:initialize_systray Could not create tray window Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. fixme:atl:OleClientSite_ShowObject (0x170ed0) - stub fixme:atl:OleClientSite_ShowObject (0x178cb0) - stub fixme:atl:OleClientSite_ShowObject (0x178cf8) - stub atl_ax.c:110: Test failed: Expected AtlAxAttachControl to return S_OK, got 0x00000001 make[2]: *** [atl_ax.ok] Error 1 make[2]: Leaving directory `/home/rahul/Programming/Projects/Downloaded/Wine/wine-1.4-rc6/dlls/atl/tests' make[1]: *** [dlls/atl/tests/__test__] Error 2 make[1]: Leaving directory `/home/rahul/Programming/Projects/Downloaded/Wine/wine-1.4-rc6' dh_auto_test: make -j1 test returned exit code 2 make: *** [build] Error 29 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed Any help regarding this? (I am not sure if this is the best mailing list to send this query to, but I got no help from the wine-users mailing list) Thanks in advance.

3 2

Re: gdiplus: Use StretchBlt instead of GdiAlphaBlend if device doesn't support alpha blending.
by Vincent Povirk March 14, 2012

March 14, 2012

Uh, in many cases this will be worse than a failed draw.

2 7

Preprocessing asm shaders
by Józef Kucia March 13, 2012

March 13, 2012

Hi, I'm writing because I found a bug in asm shader preprocessor in Wine and I'm not sure what's the best way to fix it. The D3DPreprocess function is an universal shader preprocess for HLSL and asm shaders. In fact, it's C-like language preprocessor and it doesn't understand assembler style comments (comments from ';' to the end of line). The fact that it doesn't understand these comments is a root of whole problem. Valid asm shaders can contain single or double quotation characters in assembler style comments, and these quotation characters will be treated as a beginning of quoted string constants while preprocessing. The Wine's implementation of D3DPreprocess behaves differently than Windows implementation in respect to strings passing the end of line. Generally, strings passing the end of line are an error in C, but they can result in a correct asm shader when contained in a assembler style comment. D3DPreprocess on Windows works fine for shaders which contains single or double quotation marks. It only issues an error in case of unmatched double quotation mark, but returns D3D_OK anyway. In Wine situation is different, wpp tries to find a matching quotation mark to the end of file, while shader preprocessor on Windows gives up on parsing a string when it gets a first newline character. The result of wpp's behavior is a truncated output and an error returned from D3DPreprocess. I wonder if it's fine to change wpp behavior for strings passing the end of line to mimic the behavior observed on Windows. Perhaps, strings passing the end of line could be treated as an error by default. Whereas D3DCompiler would activate an option to treat such strings as a warning. Thanks, Józef Kucia

3 5

Re: msvcp90/tests: Don't redefine __thiscall (resend).
by Alexandre Julliard March 13, 2012

March 13, 2012

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > @@ -60,11 +60,13 @@ static char* (__cdecl *p_Copy_s)(char*, size_t, const char*, size_t); > static unsigned short (__cdecl *p_wctype)(const char*); > static MSVCP__Ctypevec (__cdecl *p__Getctype)(void); > > +#ifndef __thiscall > #ifdef __i386__ > #define __thiscall __stdcall > #else > #define __thiscall __cdecl > #endif > +#endif That seems dangerous, we don't know what it has been defined to. -- Alexandre Julliard julliard(a)winehq.org

2 1

use assert etc. in Wine dlls? What is better?
by Joerg-Cyril.Hoehle＠t-systems.com March 13, 2012

March 13, 2012

Hi, Maarten's wine-pulse contains several instances of assert() I've been thinking about adding a bit of protection against inconcsistencies within mmdevapi code too. There are two variants that could be applicable depending on the situation: /* this should not happen, but if we detect it early, we can work-around the situation */ if (a > limit) { ERR("%d > %d\n", a, limit); a = limit; } or assert(a <= limit, "whatever %d", a); I'm not too fond of assert. An assert in DSound was one of my first bug fixes in Wine, years ago. It was not obvious why the app should not continue running -- perhaps without sound. OTOH, if an assert is violated, as a programmer, I'd like to hear about it. I found little on that topic in Wine. In 2002, Alexandre Julliard wrote: http://www.winehq.org/pipermail/wine-devel/2002-October/009766.html >A better approach would be to leave assert() alone, and raise an >exception on the SIGABRT signal. What is current opinion on this topic? Thank you, Jörg Höhle

4 3

What happens upon mmdevapi capture overrun on native?
by Joerg-Cyril.Hoehle＠t-systems.com March 13, 2012

March 13, 2012

Hi, Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9: >- Reworked capture logic to always capture, since that seems to be the case on windows, > when stopped we simply drop whole packets, but keep firing the event. Does anybody know what precisely happens upon overrun during capture? A. mmdevapi fills the whole buffer once. It keeps firing events and sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer. This is like mciwave's "record from 0 to 5000" command. The client can read the oldest recorded samples. B. mmdevapi continuously overwrites the circular buffer. It keeps firing events and sets the DISCONTINUITY flag too. The client gets to see the newest recorded samples. It's like your TV recorder's time shift function that can only travel back by as much as the buffer holds. C. Other, e.g. mixing newest with older packets (current winealsa). In other words, what data does the dlls/mmdevapi/capture test see in: http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc… I think A makes sense but really I don't know. The tests show a position jump by one period worth of frames when reading the next packet after an overrun. That's not what I'd expect from behaviour A. But from behaviour B I'd expect a much larger position jump, as large as elapsed time. We really need somebody with a microphone and Vista/w2k8/w7 to tell us what happens. Does anybody know what DSound does in such a case? (not that it matters...) Thank you, Jörg Höhle

2 3

Re: jscript: Add VT_I2 support
by Jacek Caban March 13, 2012

March 13, 2012

Hi Alistair, On 03/13/12 10:36, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > jscript: Add VT_I2 support static inline BOOL is_num_vt(enum VARENUM vt) { - return vt == VT_I4 || vt == VT_R8; + return vt == VT_I4 || vt == VT_I2 ||vt == VT_R8; } I'm not sure we want this handled this way. I'd much rather make sure VT_I2 (which is not internal jscript type, so it may come only from external/host objects) is never supposed to return TRUE here. If it's unavoidable, it requires convincing tests. static inline DOUBLE num_val(const VARIANT *v) { - return V_VT(v) == VT_I4 ? V_I4(v) : V_R8(v); + switch(V_VT(v)) + { + case VT_I2: + return V_I2(v); + case VT_I4: + return V_I4(v); + case VT_R8: + return V_R8(v); + } + + return 0; } It's similar here, I don't think we want to allow num_val calls on VT_I2. @@ -187,6 +187,7 @@ HRESULT to_primitive(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, VARIANT *ret case VT_EMPTY: case VT_NULL: case VT_BOOL: + case VT_I2: That seems like a likely place for VT_I2->VT_I4 conversion. @@ -569,6 +574,9 @@ HRESULT to_string(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, BSTR *str) case VT_NULL: *str = SysAllocString(nullW); break; + case VT_I2: + *str = int_to_bstr(V_I2(v)); + break; I'd like to see it covered by tests. @@ -76,7 +76,9 @@ static HRESULT Number_toString(script_ctx_t *ctx, vdisp_t *jsthis, WORD flags, D return throw_type_error(ctx, ei, JS_E_INVALIDARG, NULL); } - if(V_VT(&number->num) == VT_I4) + if(V_VT(&number->num) == VT_I2) + val = V_I2(&number->num); + else if(V_VT(&number->num) == VT_I4) I'd much rather keep the assumption that Number stores only VT_I4 or VT_R8. +objI2 = createVT_I2(); +ok(getVT(objI2) === "VT_I4", "getVT(obj) = " + getVT(objI2)); Hmm, this together with this: @@ -603,6 +608,7 @@ static HRESULT WINAPI Global_InvokeEx(IDispatchEx *iface, DISPID id, LCID lcid, case VT_NULL: V_BSTR(pvarRes) = a2bstr("VT_NULL"); break; + case VT_I2: case VT_I4: V_BSTR(pvarRes) = a2bstr("VT_I4"); break; loses the point of this test. +ok(objI2.toString() === "2", "obj = " + objI2.toString()); +function funcLoopI2() +{ + var i = 0; + /* Tests: to_primitive, to_number */ + for(; i < objI2; i++) + ; + ok(i == objI2, "i(" + i + ") != 1"); +} + +funcLoopI2(); These tests don't really show much about how VT_I2 is handled. Please try to make them striker and closer to implementation details. Also objI2 is not really a nice name for something that's not an object. + if(!strcmp_wa(bstrName, "createVT_I2")) { + *pid = DISPID_GLOBAL_CREATE_I2; + return S_OK; + } A better name would be nice. Cheers, Jacek

1 0

Re: mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in, GetRequestedRuntimeInfo (try 4)
by Marvin March 13, 2012

March 13, 2012

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=17320 Your paranoid android. === WVISTAADM (32 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322" === W2K8SE (32 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322" === W7PRO (32 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322" === W7PROX64 (32 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322" === TEST64_W7SP1 (32 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322" === W7PROX64 (64 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322" === TEST64_W7SP1 (64 bit mscoree) === mscoree.c:154: Test failed: version is L"v2.0.50727" , expected L"v1.1.4322"

1 0

Re: mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in, GetRequestedRuntimeInfo (try 3)
by Vincent Povirk March 13, 2012

March 13, 2012

- FIXME("Unrecognized version %s\n", debugstr_w(pwzVersion)); + WARN("Unrecognized version %s\n", debugstr_w(pwzVersion)); I'm not so sure about this. I think GetRuntime is still incomplete, so I'd still like to know when it fails. You will get a useless FIXME in the case where RUNTIME_INFO_UPGRADE_VERSION is specified, but I think a program that makes that specifies a version number and that flag is doing it wrong. Anyway, we shouldn't be spammed with fixme's, right?

2 1

Re: kernel32: Make CreateFile called with creation == 0 work when opening a vxd in win9x mode.
by Saulius Krasuckas March 12, 2012

March 12, 2012

* On Sun, 11 Mar 2012, Dmitry Timoshkov wrote: > > A widely used approach to open/load device drivers under win9x is > > /* Check if already loaded in system.ini */ > hvxd = CreateFile("\\\\.\\mydevice", 0, 0, 0, 0, 0, 0); > if (hvxd == INVALID_HANDLE_VALUE) > /* Load dynamically from PATH */ > hvxd = CreateFile("\\\\.\\path\\to\\mydevice.vxd", 0, 0, 0, CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE, 0); > > First call never succeeds under Wine, and some device drivers refuse to > load more than once. Are there any proof one can see? What application does behave like this? Where has this source excerpt come from? S.

1 0

GSoC 2011 - introduction
by Józef Kucia March 12, 2012

March 12, 2012

Hi, My name is Józef Kucia. I'm a Masters student in Computer Science at Wrocław University of Technology in Poland. I would like to apply for Google Summer of Code this year. I have a good knowledge of C and OpenGL. I also have limited experience with Direct3D and win32 programming. With regard to the Wine project, I'm familiar with the project from user perspective. I used to run some applications in Wine on my Gentoo Linux box, mostly games to be exact. Unfortunately, I haven't made any previous contributions to the Wine project, except submitting two small patches recently. I have read your project ideas for GSoC, and I am primarily interested in projects related to Direct3D. Nevertheless, I'm open to other projects. I would appreciate any suggestions or comments. Thanks, Józef Kucia

3 2

Re: [PATCH 4/5] msxml3: Added partial XMLView IPersistMoniker_Load implementation
by Alexandre Julliard March 12, 2012

March 12, 2012

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msxml3/xmlview.c | 908 > ++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 904 insertions(+), 4 deletions(-) This doesn't build without libxml (missing domdoc functions). -- Alexandre Julliard julliard(a)winehq.org

2 1

Instructions for using JACK with with Wine's ALSA output on wiki: reverted twice
by Alex Bradbury March 12, 2012

March 12, 2012

Recently user 'falktx' posted instructions on the Sound wiki page on how to set up an ALSA to JACK bridge that would work with Wine. He did this at the suggestion of aeikum: 14:45 <@aeikum> okay. so it is possible to get this working correctly. that's good to know 14:46 < falktx> I can make a small package with my setup scripts 14:47 <@aeikum> that might be handy to put up on the sound wiki page http://wiki.winehq.org/Sound If you look at the page edit history, you'll see the content has been reverted twice by Vitaliy without comment: http://wiki.winehq.org/Sound?action=info Please can you (wine developers) clarify your position on this. It seems to be useful content for the wiki that will benefit a number of users and I can see no justification for deleting it. It could be argued it clutters up the Sound wiki page, in which case it should be moved to a separate page linked to from there. Thank you, Alex

3 4

Re: advapi32: Correct tests under WOW64 (try 2)
by Vitaliy Margolen March 12, 2012

March 12, 2012

On 03/10/2012 12:36 AM, Alistair Leslie-Hughes wrote: > Hi, > Marked test as broken if it returns true. > > + /* WoW64 return TRUE with the LastError set */ > + ok((!ret && GetLastError() == ERROR_INSUFFICIENT_BUFFER) || broken(ret), > "%d with error %d\n", ret, GetLastError()); This is incorrect. You can check or report result of GetLastError(). But not both at the same time. You have to store the result in additional variable. Then compare and report it. Vitaliy

3 4

Re: mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in, GetRequestedRuntimeInfo (try 2)
by Vincent Povirk March 12, 2012

March 12, 2012

I suspect that RUNTIME_INFO_UPGRADE_VERSION will actually use the newest non-4.0 version when it doesn't find an exact match, which is why I asked you to add that test. I'm not sure whether Marvin's results prove that or not. If that's the case, get_runtime_info should probably be checking the result of CLRMetaHost_GetRuntime, and proceeding to the RUNTIME_INFO_UPGRADE_VERSION check if it fails.

1 0

Re: mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in, GetRequestedRuntimeInfo (try 2)
by Marvin March 12, 2012

March 12, 2012

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=17280 Your paranoid android. === WVISTAADM (32 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727" === W2K8SE (32 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727" === W7PRO (32 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727" === W7PROX64 (32 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727" === TEST64_W7SP1 (32 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727" === W7PROX64 (64 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727" === TEST64_W7SP1 (64 bit mscoree) === mscoree.c:157: Test failed: version is L"v2.0.50727" , expected L"v2.0.50727"

1 0

Re: Are we the reason Apple isn't helping us?
by Ralph Little March 11, 2012

March 11, 2012

Hi, Well, I'm a general lurker and small contributer in my own way. I'm looking at one bug and have requested help from wine-devel in the past. So, in a nutshell, I consider myself an outsider of the general crew. Therefore, I'm going to be a bit more forthright about my response to this post. The Wine developers know nothing about me and my experience. I have attempted to demonstrate that, although I lack much time, I am prepared to put some effort into helping where I can in my small way. There are many like me. In have tried to be cordial and respectful on wine-devel. In return I have had nothing but courtesy, helpful assistance and general goodwill in answer. There is a right way of entering into these things and a wrong way. The Wine crew, as far as I know, know nothing of this supposed Apple developer. He has not demonstrated his experience or trustworthyness or knowledge of the Wine product to any level. Jeremy expects that as a stranger the Wine team should take his word at face value that he submitted a needed fix and that it sufficiently corrected the problem without doing even the *minimum* of effort to convince them. I have read the bug issue in question, and from the outset, he was disrespectful and downright combative and dismissive of all of the Wine teams procedures. Despite that, the responses on the bug tracker from the Wine team where measured and non-escalatory. A slightly different approach would have yielded a substantially different result. A humble request for assistance in knowing the proper channel and aid in getting the change properly submitted would, I feel, have had a far greater acceptance of what he was after. I agree that sometimes the responses on the bug tracker can be curt to the point of rudeness, but mostly that is down to the impersonal nature of the medium. Jeremy obviously thought that the change was important enough that he should take the time to submit it in the first place. A little bit of natural humility and expressing a more willing sentiment would have gone a long way to helping his cause. Cheers, Ralph

1 0