October 2013 - Wine-devel - list.winehq.org

Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling
by Marvin 07 Oct '13

07 Oct '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2649 Your paranoid android. === wxppro (32 bit cpp) === cpp.c:1326: Test failed: 124: Got name "[thunk]: __thiscall CView::`vcall'{392,{flat}}' " cpp.c:1329: Test failed: 124: Expected "[thunk]: __thiscall CView::`vcall'{392,{flat}}' }'"

1 0

Re: msvcrt: add support for _chsize_s (try #2)
by Piotr Caban 07 Oct '13

07 Oct '13

Hi, On 10/06/13 00:45, morphiend wrote: > + * _chsize_s (MSVCRT.@) > + */ > +int CDECL MSVCRT__chsize_s(int fd, __int64 size) > +{ > + LARGE_INTEGER cur, pos; > + LARGE_INTEGER temp = { 0 }; This causes compilation warnings. There's also a trailing space in this line. > + TRACE("(fd=%d, size=%lld)\n", fd, size); You can't print 64-bit numbers this way, it's not portable. You can use wine_dbgstr_longlong function. > + handle = msvcrt_fdtoh(fd); > + if (!MSVCRT_CHECK_PMT_ERR(handle == INVALID_HANDLE_VALUE, MSVCRT_EBADF) || > + !MSVCRT_CHECK_PMT_ERR(size < 0, MSVCRT_EINVAL)) You're validating parameters incorrectly. Did you test this patch? > + { > + ret = SetEndOfFile(handle); > + if (!ret) > + { > + msvcrt_set_errno(GetLastError()); > + ret = *MSVCRT__errno(); > + } This causes the _chsize_s function to return TRUE in case of success. > + /* restore the file pointer */ > + MSVCRT__lseek(fd, cur.QuadPart, SEEK_SET); MSVCRT__lseek takes LONG as second argument. Cheers, Piotr

1 0

binfmt support
by xantares 09 07 Oct '13

07 Oct '13

Hello, I made a patch to add a configuration file to be picked up by binfmt to allow to associate windows executables to wine. As binfmt is now a part of systemd in most linux disttributions: http://www.freedesktop.org/software/systemd/man/systemd-binfmt.service.html ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf… What do you think ? x.

2 1

Re: msvcrt: add support for _chsize_s (try #2)
by Frédéric Delanoy 06 Oct '13

06 Oct '13

On Sun, Oct 6, 2013 at 12:45 AM, morphiend <morphiend(a)gmail.com> wrote: > This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. > This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without > the implementation of _chsize_s(), certain binaries caused an internal crash > of IDA. This patch fixed that crash. > You need to use your real name when sending patches. -- Frédéric Delanoy

2 1

Re: mshtml/tests: Fix compilation on systems that don't support nameless unions.
by Marvin 05 Oct '13

05 Oct '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2637 Your paranoid android. === wxppro (32 bit htmldoc) === htmldoc.c:2898: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:7601: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:5978: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:2898: Test failed: mon(002ADFE8) != exmon(00265FE8) htmldoc.c:7601: Test failed: mon(002ADFE8) != exmon(00265FE8) htmldoc.c:5978: Test failed: mon(002ADFE8) != exmon(00265FE8) === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found

1 0

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions.
by Marvin 05 Oct '13

05 Oct '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2634 Your paranoid android. === w7pro64 (64 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:883: Test failed: WaitCommEvent error 0 comm.c:885: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:889: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:891: Test failed: WaitCommEvent used 1014 ms for waiting

1 0

BiDi, Unicode 6.3 and Wine.
by Aric Stewart 04 Oct '13

04 Oct '13

Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric

3 2

Re: [3/3] ntdll: Add support for FILE_APPEND_DATA to NtWriteFile. Take 2.
by Alexandre Julliard 04 Oct '13

04 Oct '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -979,6 +986,12 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent, > goto done; > } > > + if (append_write) > + { > + offset_eof.QuadPart = (LONGLONG)-1; /* FILE_WRITE_TO_END_OF_FILE */ > + offset = &offset_eof; > + } > + Please add a test for the file position after the write, to show that this is the correct behavior. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
by Henri Verbeet 04 Oct '13

04 Oct '13

On 4 October 2013 15:02, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Client storage only applies to GL textures, which won't be created for sysmem surfaces. > I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them.

2 4

Re: [PATCH 5/5] wininet: Added InternetLockRequestFile tests.
by Marvin 04 Oct '13

04 Oct '13

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://newtestbot.winehq.org/JobDetails.pl?Key=2625 Your paranoid android. === w2008s64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0 === w7pro64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0

1 0