June 2015 - Wine-Devel - list.winehq.org

Re: include: add initial winsta.h

by Austin English

On Tue, May 26, 2015 at 10:21 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin Patch has been pending for several days, is there something I can do to improve it? Nikolay asked in #winehackers where this came from, it's on MSDN: https://msdn.microsoft.com/en-us/library/cc248871.aspx and also in Process Hacker's source: http://processhacker.sourceforge.net/doc/winsta_8h_source.html -- -Austin

June 3, 2015

Re: [PATCH 5/5] d3d8/tests: Port the point size test to D3D8.

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=13782 Your paranoid android. === w8 (32 bit visual) === visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 0, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 1, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 2, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 3, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 4, 7, size 0).

June 2, 2015

Re: [PATCH 4/5] d3d9/tests: Add more tests for point size.

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=13781 Your paranoid android. === w8 (32 bit visual) === visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 0, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 1, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 2, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 3, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x00000000 (case 4, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 5, 7, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x00000000 (case 6, 7, size 0).

June 2, 2015

Re: [2/2] msvcirt/tests: Add initial tests for streambuf (try 2)

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=13771 Your paranoid android. === wvistau64 (64 bit msvcirt) === No test summary line found === w2008s64 (64 bit msvcirt) === No test summary line found

June 2, 2015

Re: [PATCH 1/3] ntdll: Implemenent ObjectTypeInformation class support in NtQueryObject.

by Qian Hong

Hi Nikolay, On Mon, Jun 1, 2015 at 8:01 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Why do you need a separate server call/special case for files? > Thanks again for pointing out this, I just sent a new version which removes special case for files. > Also, do we really need to transfer a string? It seems to be that you can use an index and a static array at ntdll side. Good points. As we discussed in IRC, let's keep the change minimal in this iteration and wait for AJ's opinion. Maybe if there is a change need to done here AJ might prefer to do by himself :) -- Regards, Qian Hong - http://www.winehq.org

June 2, 2015

Re: [1/2] msvcirt: Add initial implementation of streambuf

by Piotr Caban

On 06/02/15 14:52, Iván Matellanes wrote: > + __ASM_VTABLE(streambuf, > + VTABLE_ADD_FUNC(streambuf_vector_dtor)); It would be nice to add all the functions to vtable. Otherwise the application may crash without nice error message.

June 2, 2015

Re: [1/2] msvcirt: Add initial implementation of streambuf

by Iván Matellanes

El 02/06/15 a las 15:38, Piotr Caban escribió: > On 06/02/15 14:52, Iván Matellanes wrote: >> +/* ??0streambuf@@IAE(a)XZ */ >> +/* ??0streambuf@@IEAA(a)XZ */ >> +DEFINE_THISCALL_WRAPPER(streambuf_ctor, 4) >> +streambuf* __thiscall streambuf_ctor(streambuf *this) >> +{ >> + TRACE("(%p)\n", this); >> + this->vtable = &MSVCP_streambuf_vtable; >> + this->allocated = 0; >> + this->unbuffered = 0; >> + this->unknown = -1; >> + this->unknown2 = -1; >> + streambuf_setb(this, NULL, NULL, 0); >> + streambuf_setg(this, NULL, NULL, NULL); >> + streambuf_setp(this, NULL, NULL); >> + InitializeCriticalSection(&this->lock); >> + return this; >> +} > Can't it be simplified to: > streambuf* __thiscall streambuf_ctor(streambuf *this) > { > return streambuf_reserve_ctor(this, NULL, 0); > } > ? > You're right, it can be simplified. The value of this->unbuffered will be different, though. I will resend. Iván.

June 2, 2015

Re: [1/2] msvcirt: Add initial implementation of streambuf

by Piotr Caban

On 06/02/15 14:52, Iván Matellanes wrote: > +/* ??0streambuf@@IAE(a)XZ */ > +/* ??0streambuf@@IEAA(a)XZ */ > +DEFINE_THISCALL_WRAPPER(streambuf_ctor, 4) > +streambuf* __thiscall streambuf_ctor(streambuf *this) > +{ > + TRACE("(%p)\n", this); > + this->vtable = &MSVCP_streambuf_vtable; > + this->allocated = 0; > + this->unbuffered = 0; > + this->unknown = -1; > + this->unknown2 = -1; > + streambuf_setb(this, NULL, NULL, 0); > + streambuf_setg(this, NULL, NULL, NULL); > + streambuf_setp(this, NULL, NULL); > + InitializeCriticalSection(&this->lock); > + return this; > +} Can't it be simplified to: streambuf* __thiscall streambuf_ctor(streambuf *this) { return streambuf_reserve_ctor(this, NULL, 0); } ?

June 2, 2015

mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.

by Joerg-Cyril.Hoehle＠t-systems.com

Akihiro, >However, recent Windows systems don't allow to call MCI commands from another thread. Could you please elaborate? I understand the Co/UnCo issue, but what about other commands? Wouldn't the thread invoking Co/UnCo remain strictly internal to winmm? At the MCI string command level, all you see are "device" numbers and aliases, so why shouldn't an app be allowed to send "status x position" from any thread in the app's address space? >Do you know the application which relies on this feature? I rarely analyzed app's requirements. I usually proceed as follows: read available documentation, perform many tests, then turn a meaningful subset of these into wine test format and write driver code that makes Wine nearly undistinguishable from native. As native behavior varies, I prefer to target the version that was in use at the time when the driver was mostly used (by commercial apps/games). For the MCI, this means MS-Windows 3.x + 9X/ME and early 2k/XP. When you wade through forums, you'll notice that some VB programmers still use the MCI nowadays, but I saw no complex use cases there. Yet I'm biased, as I hardly investigated mciqtz usage and mostly cared about mciwave+midi+cda so far. >> E.g. there may be a need to dispatch REFRESH and PAINT messages? >I didn't check Windows behavior at that point. >IMHO, MCI code doesn't assume the Window message queue and shouldn't touch them. Pumping message queue is pure hypothesis on my side, but it would be valuable to know for sure. I'm not familiar with MS-Windows messaging at all. When I raised the question in wine-devel 2013, IIRC I got no response. I'm unsure there could be no interaction with the message queue in mciavi and mciqtz. After all, there are MCI_*_HWND command options. Some other area in need of investigation is timing. When or how fast does a function return? For instance, there are entries in bugzilla related to the time it takes to close and reopen winmm. https://bugs.winehq.org/show_bug.cgi?id=28413 On a related side, at what time are callbacks invoked (or quartz pins)? Fortunately, the MCI knows no callbacks (lesson learned), but they may raise their ugly head again via the MCI-Quartz bridge. As many (old?) apps are single-threaded, so I was told, the duration of function calls matters, allowing the app to return to its message queue fast. The order of calls through pins matters too, alas. For instance, I've wondered whether it would be valuable to send PLAY, PAUSE and STOP asynchronously, so as to return to the caller fast. The driver could still have internal logic that would let it accept the next command only after the current one is processed, so it's still strictly serial. IOW there's a pipe of length 1 in between. The difference is that the caller app is free to do other things for as long as it doesn't issue commands to fast in a row. I've observed evidence of some async. behavior with at least one of the MCI drivers (mcicda perhaps, or mcimidi, not sure any more): not all errors that PLAY would meet were returned immediately upon command invocation (IIRC there were a few corner cases along PLAY FROM 100 to 100). >From an implementation POV, this requires some processing (error checking, e.g. refuse PLAY FROM 100 TO 50) before sending the async. message, and checking the rest in the async. driver. That's quite different from your current "forward immediately" patch. But that's just an idea. Regards, Jörg Höhle

June 2, 2015

Re: msvcirt/tests: Add initial tests for streambuf

by Piotr Caban

On 06/02/15 13:25, Iván Matellanes wrote: > I have already implemented those methods. Is it OK if I skip the stubs and send the implementation directly? Probably it's OK, if the patches are to hard to review you'll be asked to split them. The idea is to keep patches small so it's easier to review them.

June 2, 2015