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

Re: kernel32: Correct WideCharToMultiByte and MultiByteToWideChar error codes and conditions

by Nikolay Sivov

On 5/10/2012 00:52, Alex Henrie wrote: > This patch was a lot harder to figure out than I thought it was going to be. > > The MSDN documentation of most of these behaviors can be found at > http://msdn.microsoft.com/en-us/library/windows/desktop/dd319072(v=vs.85).a… Does any application depend on that? > > --- > dlls/kernel32/locale.c | 38 ++++++++++++++--- > dlls/kernel32/tests/locale.c | 94 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 126 insertions(+), 6 deletions(-) This is a wrong file to place tests into. > > diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c > index 3216ef9..9cbb124 100644 > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -3137,6 +3137,99 @@ static void test_IdnToUnicode(void) > } > } > > +static void test_WideCharToMultiByte_error(UINT page, DWORD flags, LPCWSTR src, > + INT srclen, LPSTR dst, INT dstlen, > + LPCSTR defchar, BOOL* used, > + const char* test_description, > + DWORD expected_error) > +{ > + SetLastError(ERROR_SUCCESS); > + WideCharToMultiByte(page, flags, src, srclen, dst, dstlen, defchar, used); > + ok(GetLastError() == expected_error, > + "codepage %i, %s, expected error %i got error %i\n", page, > + test_description, expected_error, GetLastError()); > +} > + > +static void test_MultiByteToWideChar_error(UINT page, DWORD flags, LPCSTR src, > + INT srclen, LPWSTR dst, INT dstlen, > + const char* test_description, > + DWORD expected_error) > +{ > + SetLastError(ERROR_SUCCESS); > + MultiByteToWideChar(page, flags, src, srclen, dst, dstlen); > + ok(GetLastError() == expected_error, > + "codepage %i, %s, expected error %i got error %i\n", page, > + test_description, expected_error, GetLastError()); > +} > + Looks ugly enough, it's better to place some test data in table and loop through it, if you really want to test that.

May 10, 2012

Re: kernel32: Correct WideCharToMultiByte and MultiByteToWideChar error codes and conditions

by Alex Henrie

2012/5/9 Nikolay Sivov <bunglehead(a)gmail.com>: > Does any application depend on that? Probably. Better safe than sorry, and Wine's current behavior definitely doesn't match what MSDN says nor what Windows actually does. >> dlls/kernel32/locale.c | 38 ++++++++++++++--- >> dlls/kernel32/tests/locale.c | 94 >> ++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 126 insertions(+), 6 deletions(-) > > This is a wrong file to place tests into. Which file should I have used? > Looks ugly enough, it's better to place some test data in table and loop > through it, if you really want to test that. A loop is probably overkill, but I will clean it up some more. Thanks for the feedback, -Alex

May 10, 2012

Re: kernel32: Add UTF-7 support

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > 2012/5/8 Alexandre Julliard <julliard(a)winehq.org>: >> That code is hopelessly ugly, and broken in various ways. You are >> probably better off starting from scratch. > > Okay. Could we use the POSIX iconv functions? Why doesn't Wine use > iconv for UTF-8 already? UTF-8 is trivial, using iconv would be more work than doing it by hand. UTF-7 is slightly more complicated but not that hard. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2012

Re: d3drm/tests: Port IDirect3DRMFrame tests to IDirect3DRMFrame3

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > --- > dlls/d3drm/tests/d3drm.c | 323 +++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 320 insertions(+), 3 deletions(-) It doesn't seem necessary to duplicate the whole thing, try to find a better way. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2012

Re: [PATCH] d3drm: Retreive mesh name at loading time. Implement GetName and SetName. (try 5) (resend)

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > Try 5: Use a growing buffer to store name. I don't think a growing buffer makes sense for this. > + if (name) > + { > + *size = min(*size, This->name_size); > + memcpy(name, This->name, *size); > + /* Make sure we have the terminating 0 in case of truncation */ > + name[*size] = 0; Buffer overflow. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2012

Re: kernel32: Add UTF-7 support

by Alex Henrie

2012/5/8 Alexandre Julliard <julliard(a)winehq.org>: > That code is hopelessly ugly, and broken in various ways. You are > probably better off starting from scratch. Okay. Could we use the POSIX iconv functions? Why doesn't Wine use iconv for UTF-8 already? -Alex

May 9, 2012

Re: Ubuntu 12.04 (version#2, drop previous mail)

by Scott Ritchie

On 5/1/12 2:32 AM, Eric Pouech wrote: > >> This is the downside people in this thread are complaining about: >> compiling 32-bit programs on a 64-bit Ubuntu install is now slightly >> more difficult. However, Wine is currently the _only_ piece of >> software I've encountered that needs to be built for both arches on >> the same machine in order to be usable. We are beautiful special >> snowflakes here: Wine developers who aren't using the build daemons is >> about the extent of the current use case. > <snip> >> >> I'm beginning to have memories of what happened when we removed gcc >> from the default install. Setting up a 32-bit chroot for building Wine >> should not be complicated -- I'll present a script to make it even >> easier soon. You can build in a single command and even use things >> like ccache and the like to speed it up. >> > to summarize: > ubuntu doesn't do anything to support developers > as it implies using ubuntu build daemons, not developers' machine (and > all the relevant environment) > as it implies to use chroot even on a multi lib arch => multi arch is > then for users, not developers > > bye bye ubuntu then If this is a blocker for you then I can't blame you then. For reference the only successful way to build Wine I'm aware of is http://wiki.winehq.org/Wine64ForPackagers under the "Alternatives" section (ie, manually configuring and building 32 and 64 separately and copying files from one into the other.) You may be able to do that without a chroot (or something similar like pbuilder), > > for the sake of record (I won't even dare to send it to wine-patches) a > workaround ubuntu recvmsg breakage in order to get ptrace API to be > usable on 12.04 > > diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c > index 8a01d22..6c8e759 100644 > --- a/dlls/ntdll/server.c > +++ b/dlls/ntdll/server.c > @@ -1016,6 +1016,37 @@ void server_init_process(void) > send_server_task_port(); > #endif > #if defined(__linux__) && defined(HAVE_PRCTL) > + /* work around Ubuntu's recvmsg breakage */ > + if (!server_pid) > + { > + int zfd; > + struct flock fl; > + char tmp[4096]; > + strcpy(tmp, wine_get_server_dir()); > + strcat(tmp, "/"); > + strcat(tmp, LOCKNAME); > + > + if ((zfd = open( tmp, O_RDONLY )) == -1) > + fatal_error( "no lock present %s.\n", tmp ); > + > + fl.l_type = F_WRLCK; > + fl.l_whence = SEEK_SET; > + fl.l_start = 0; > + fl.l_len = 1; > + if (fcntl( zfd, F_GETLK, &fl ) != -1) > + { > + if (fl.l_type == F_WRLCK) > + { > + /* the file is locked */ > + fprintf(stderr, "getting server_pid from lock %d\n", fl.l_pid); > + server_pid = fl.l_pid; > + } > + fatal_error( "cannot get pid from lock (lock isn't locked)\n"); > + } > + else > + fatal_error( "cannot get pid from lock\n"); > + close(zfd); > + } > /* work around Ubuntu's ptrace breakage */ > if (server_pid != -1) prctl( 0x59616d61 /* PR_SET_PTRACER */, server_pid ); > #endif > I showed this to the developer who originally wrote the kernel ptrace stuff, and indeed this seems like an upstream kernel bug, albeit in recvmsg rather than ptrace (also note that the ptrace stuff is now in the mainline kernel as well, not just Ubuntu, so you may have found a problem that was just exposed in Ubuntu first). Anyway, I'll follow up on it. In the meantime I'm pushing your patch in a stable release update for Wine (once I test another thing), so thank you very much for it. Thanks, Scott Ritchie

May 9, 2012

Re: [2/5] gdi32: Set tmDigitizedAspectX/Y to 96 instead of 300 for consistency.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -6677,8 +6677,8 @@ static BOOL get_outline_text_metrics(GdiFont *font) > TM.tmWeight = pOS2->usWeightClass; > } > TM.tmOverhang = 0; > - TM.tmDigitizedAspectX = 300; > - TM.tmDigitizedAspectY = 300; > + TM.tmDigitizedAspectX = 96; /* FIXME */ > + TM.tmDigitizedAspectY = 96; /* FIXME */ A couple of comments to the patch: 1. the values should be set to the resolution of the target device, and 96 looks more natural since most of the time the device is a display. 2. the change is for consystency with get_bitmap_text_metrics() which sets these values to 96. 3. even if this pacth is rejected, other patches in the sequence should not be affected by it. -- Dmitry.

May 8, 2012

Re: running 16bit code

by Stefan Dösinger

Am Dienstag, 8. Mai 2012, 13:31:00 schrieb Marcus Meissner: > DOSBOX and DOSEMU can fall back to full emulation today, so vm86 not > strictly required anymore these days. Speed is probably no longer an > issue ;) No, speed is still an issue. DOSBOX is too slow to run Settlers 2 and Screamer 2(aka Bleifuß 2) on my Core 2 Duo CPU. Dosemu works for Settlers 2(I estimate that it is about 20 times faster), and Screamer 2 works with some 3DFX hacks that move the graphics calculations into the GPU. Ok, I realize that this is borderline off-topic, and both games aren't real mode apps strictly speaking, but 32 bit protected mode DOS/4G programs. They still need 16 bit real mode to launch though.

May 8, 2012

Re: [PATCH 4/4] dmsynth: Add stubbed IKsControl interface to DirectMusicSynthSink object.

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > --- > dlls/dmsynth/dmsynth_private.h | 1 + > dlls/dmsynth/synthsink.c | 67 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 68 insertions(+), 0 deletions(-) It fails here: ../../../tools/runtest -q -P wine -M dmsynth.dll -T ../../.. -p dmsynth_test.exe.so dmsynth.c && touch dmsynth.ok dmsynth.c:56: Test succeeded inside todo block: IDirectMusicSynthSink_QueryInterface returned: 0 make: *** [dmsynth.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 8, 2012