April 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 2/2] winspool.drv: Check the value of pDeviceName.(try 3)
by Marvin April 5, 2013

April 5, 2013

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=24967 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Trying Battle for Wesnoth in Wine.
by Tae Wong April 5, 2013

April 5, 2013

You haven’t tried Battle for Wesnoth latest version in Wine on Ubuntu so you have uploaded the about.cfg file to MediaFire which contains over 1000 lines and some un-terminated quoted strings in many names. Check it here (http://www.mediafire.com/?mbw9y2i834z2k7r) Swear at error message (Quoted string not terminated) whilst you fix the un-terminated quoted strings.

2 1

Trying Battle for Wesnoth in Wine.
by Tae Wong April 5, 2013

April 5, 2013

You haven’t tried Battle for Wesnoth latest version in Wine on Ubuntu so you have uploaded the about.cfg file which contains over 1000 lines and some un-terminated quoted strings in many names.

1 0

[PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
by Pavel Shilovsky April 4, 2013

April 4, 2013

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. So, we have four new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), O_DENYMAND - to switch on/off three flags above. Also, this version of the patchset fixes the problem of data races on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a deny lock by another task. The #1 patch adds flags to fcntl, the #2 patch implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD parts. The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… The future part of open man page patch: ----- O_DENYMAND - used to inforce a mandatory share reservation scheme of the file access. If this flag is passed, the open fails with -ETXTBSY in following cases: 1) if O_DENYREAD flag is specified and there is another open with O_DENYMAND flag and READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with O_DENYMAND flag and WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYMAND and O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYMAND and O_DENYWRITE flags. If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ETXTBSY untill this open is closed. Now this flag is processed by CIFS filesystems only. This mechanism is done through flocks. If O_DENYMAND is specified and flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) O_DENYMAND -> LOCK_MAND 2) !O_DENYREAD -> LOCK_READ 3) !O_DENYWRITE -> LOCK_WRITE ----- Pavel Shilovsky (7): fcntl: Introduce new O_DENY* open flags vfs: Add O_DENYREAD/WRITE flags support for open syscall CIFS: Add O_DENY* open flags support CIFS: Use NT_CREATE_ANDX command for forcemand mounts CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2 NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS fs/cifs/cifsacl.c | 6 +- fs/cifs/cifsglob.h | 12 +++- fs/cifs/cifsproto.h | 9 +-- fs/cifs/cifssmb.c | 47 ++++++++-------- fs/cifs/dir.c | 14 +++-- fs/cifs/file.c | 18 ++++-- fs/cifs/inode.c | 11 ++-- fs/cifs/link.c | 10 ++-- fs/cifs/readdir.c | 2 +- fs/cifs/smb1ops.c | 15 ++--- fs/cifs/smb2file.c | 10 ++-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++-- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 +++-- fs/fcntl.c | 5 +- fs/locks.c | 117 +++++++++++++++++++++++++++++++++++---- fs/namei.c | 44 ++++++++++++++- fs/nfs/nfs4xdr.c | 24 ++++++-- fs/nfsd/nfs4state.c | 46 ++++++++++++++- include/linux/fs.h | 6 ++ include/uapi/asm-generic/fcntl.h | 14 +++++ 23 files changed, 345 insertions(+), 101 deletions(-) -- 1.8.1.2

8 36

Re: wined3d: Properly handle backbuffer_width/_height=0 in wined3d_device_reset.
by Henri Verbeet April 4, 2013

April 4, 2013

Is this really the correct behaviour when windowed is FALSE and the backbuffer width / height is 0? That may just not be allowed at all, but it seems weird to use the window's dimensions in that case, instead of e.g. the current display mode. > if (!swapchain_desc->backbuffer_width || !swapchain_desc->backbuffer_height > || swapchain_desc->backbuffer_width != swapchain->desc.backbuffer_width > || swapchain_desc->backbuffer_height != swapchain->desc.backbuffer_height) Double indent for line continuations, please. > window = swapchain_desc->device_window ? > swapchain_desc->device_window : device->create_parms.focus_window; This is really just the same as "window = swapchain->device_window;". > if(swapchain_desc->backbuffer_width) Space between control statements and '('.

1 0

Re: extrac32: Preprocess command line before passing to CommandLineToArgvW().
by Sergey Guralnik April 4, 2013

April 4, 2013

On 2013-04-04 15:19, Sergey Guralnik wrote: > Playing with one application, that uses extrac32.exe, > I've found that Wine's extrac32 can't process some > command lines, that cause no problem with native one. > ... > There are two ways to solve this promlem: > - write own parser for extrac32, > - perform some translation for command line before > passing to CommandLineToArgvW(). P.S. Replacing wWinMain() with wmain() doesn't solve this problem. -- Sergey

1 0

Wine Gecko 2.20-beta1
by Jacek Caban April 4, 2013

April 4, 2013

Hi all, I've uploaded a new Gecko builds to SourceForge [1]. This one is based on Firefox 20 beta and, other than usual update of Gecko, it should fix some crashes like bug b*ug 32753* <http://bugs.winehq.org/show_bug.cgi?id=32753>. To test them, you need recent Wine Git version with the attached patch. As usually, grab the build from SourceForge, put it in the right place [2] and run patched Wine. All help with testing is appreciated! Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/2.20-beta1/ [2] http://wiki.winehq.org/Gecko

1 1

Re: cmd: Remove a pointless linefeed in an error message.
by Julian Rüger April 4, 2013

April 4, 2013

Sorry for nagging ;) Wasn't the convention to assume an 80-character wide terminal? This line would wrap, then. So the linefeed is not totally pointless here. Please correct me, if I'm mistaken. Best regards, Julian Am Mittwoch, den 03.04.2013, 16:07 +0200 schrieb Francois Gouget: > --- > programs/cmd/cmd.rc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/cmd/cmd.rc b/programs/cmd/cmd.rc > index c3cdb52..d464cab 100644 > --- a/programs/cmd/cmd.rc > +++ b/programs/cmd/cmd.rc > @@ -360,5 +360,5 @@ Enter HELP <command> for further information on any of the above commands.\n" > WCMD_NOOPERAND, "Expected an operand.\n" > WCMD_NOOPERATOR, "Expected an operator.\n" > WCMD_BADPAREN, "Mismatch in parentheses.\n" > - WCMD_BADHEXOCT, "Badly formed number - must be one of decimal (12),\n hexadecimal (0x34) or octal (056).\n" > + WCMD_BADHEXOCT, "Badly formed number - must be one of decimal (12), hexadecimal (0x34) or octal (056).\n" > }

2 1

Re: msvcr110: forward __crtSetUnhandledExceptionFilter to kernel32.SetUnhandledExceptionFilter (try 2)
by Dmitry Timoshkov April 4, 2013

April 4, 2013

Austin English <austinenglish(a)gmail.com> wrote: > Try 2: use cdecl calling convention > -@ stub __crtSetUnhandledExceptionFilter > +@ cdecl __crtSetUnhandledExceptionFilter(ptr) kernel32.SetUnhandledExceptionFilter It's not acceptable to mix calling conventions when forwarding an API with number of arguments != 0. -- Dmitry.

1 0

Re: [PATCH 2/2] winspool.drv: Check the value of pDeviceName.(try 2, resend)
by Marvin April 3, 2013

April 3, 2013

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=24942 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: [PATCH 1/2] winspool.drv/tests: Add DocumentProperties test with empty pDeviceName.
by Marvin April 3, 2013

April 3, 2013

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=24941 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: [PATCH 8/8] configure: Get rid of no longer needed OpenSSL checks.
by Marcus Meissner April 3, 2013

April 3, 2013

Hi, I have one concern ... Licensing. GNUTLS is (L)GPLv3+ these days. Wine will now turn into a LPGLv3+ licensed binary (not the sources, just the binaries will turn into it implicitly by linking against gnutls 3). Ciao, Marcus On Wed, Apr 03, 2013 at 02:06:09PM +0200, Jacek Caban wrote: > --- > configure.ac | 13 ------------- > 1 file changed, 13 deletions(-) > > > diff --git a/configure.ac b/configure.ac > index d8f2e8d..080e961 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -66,8 +66,6 @@ AC_ARG_WITH(openal, AS_HELP_STRING([--without-openal],[do not use OpenAL]), > AC_ARG_WITH(opencl, AS_HELP_STRING([--without-opencl],[do not use OpenCL]), > [if test "x$withval" = "xno"; then ac_cv_header_CL_cl_h=no; ac_cv_header_OpenCL_opencl_h=no; fi]) > AC_ARG_WITH(opengl, AS_HELP_STRING([--without-opengl],[do not use OpenGL])) > -AC_ARG_WITH(openssl, AS_HELP_STRING([--without-openssl],[do not use OpenSSL]), > - [if test "x$withval" = "xno"; then ac_cv_header_openssl_err_h=no; ac_cv_header_openssl_ssl_h=no; fi]) > AC_ARG_WITH(osmesa, AS_HELP_STRING([--without-osmesa],[do not use the OSMesa library])) > AC_ARG_WITH(oss, AS_HELP_STRING([--without-oss],[do not use the OSS sound support])) > AC_ARG_WITH(png, AS_HELP_STRING([--without-png],[do not use PNG]), > @@ -469,8 +467,6 @@ AC_CHECK_HEADERS(\ > netinet/in_systm.h \ > netinet/tcp.h \ > netinet/tcp_fsm.h \ > - openssl/err.h \ > - openssl/ssl.h \ > png.h \ > poll.h \ > port.h \ > @@ -1604,15 +1600,6 @@ fi > WINE_NOTICE_WITH(fontconfig,[test "x$ac_cv_lib_soname_fontconfig" = "x"], > [fontconfig ${notice_platform}development files not found, fontconfig won't be supported.]) > > -dnl **** Check for SSL **** > -if test "$ac_cv_header_openssl_err_h" = "yes" -a "$ac_cv_header_openssl_ssl_h" = "yes" > -then > - WINE_CHECK_SONAME(ssl,SSL_library_init) > - WINE_CHECK_SONAME(crypto,BIO_new_socket) > -fi > -WINE_WARNING_WITH(openssl,[test "x$ac_cv_lib_soname_ssl" = "x" -o "x$ac_cv_lib_soname_crypto" = "x"], > - [OpenSSL ${notice_platform}development files not found, SSL won't be supported.]) > - > dnl **** Check for gsm codec **** > if test "$ac_cv_header_gsm_h" = "yes" -o "$ac_cv_header_gsm_gsm_h" = "yes" > then > >

1 1

Re: [PATCH] winspool.drv: Check the value of pDeviceName.(try 2)
by Nikolay Sivov April 3, 2013

April 3, 2013

On Wed, Apr 3, 2013 at 1:31 PM, Tatyana Fokina <tatyana(a)etersoft.ru> wrote: > Function DocumentPropertiesA calling GDI_CallExtDeviceMode16: If value > pDeviceName is "", from GDI_CallExtDeviceMode16 return -1. > > Is it possible to add a test for that?

2 1

Re: ieframe: Added GoForward tests.
by Marvin April 3, 2013

April 3, 2013

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=24939 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2615: Test failed: expected GetOverridesKeyPath webbrowser.c:2620: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2621: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3065: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Hi Res Icons
by Joel Holdsworth April 3, 2013

April 3, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alexandre (+ Others), I notice you've been working on hi-res icons. I just have a couple of comments to chip in. So 2 years ago when I was doing the wine icon refresh, I decided not to try and tackle the problem of hi-res icons. Just getting the normal sized icons merged had proved to be a gargantuan task that took me over a year to complete - I didn't have the stomach to embark on another round of artwork. We also didn't support PNG icons in those days. As you can see in these hi-res icon patches, scaling icons is never as simple as people think. http://source.winehq.org/git/wine.git/blob/HEAD:/programs/iexplore/iexplore… As you can see here, scaling the iexplore icons really shows the limits of this artwork. The line caps are wrong in several places. The worst being in the highlight of the yellow swoosh at the bottom - you see the highlight doesn't line up with the border. A lot of things don't quite line up correctly. Moreover what were sharp single pixel lines in the 48x48 image have become fat strokes, which look rather play-schoolish to my eye. The solution is to have dedicated artwork specifically for these large sizes. This has been done in the Mango icon project: http://jimmac.musichall.cz/i.php?i=MIME2 http://jimmac.musichall.cz/i.php?i=git3 http://jimmac.musichall.cz/i.php?i=Tango-NG This is the work of Jakub Steiner and Lapo Calamandrei. They did a workshop on how to do this artwork here: https://www.youtube.com/watch?v=2T7833s2MJI Notice the fine detailing and beautiful shading. In the network filter they even used a paper texture for the card of the folder! These guys have done a fantastic job. So I wanted to sound out how much desire there is for this for Wine. I'm probably not going to be able to contribute this myself, due to time constraints. I wondered if there were any other developers cum artists interested in having a go. 2 years ago I asked Jakub if he would be interested in doing this, but he said he was quite busy. It might be worth reaching out to him or Lapo again, to see if they'd like to contribute. Also, I don't know how much this work is being driven by CodeWeavers Mac product, but another approach would be to for CodeWeavers to solicit contract work or a bounty for this. Jakub or Lapo might be more able to make time on those terms - but of course I don't know if that's a deal they or CodeWeavers would be interested in making. Another source of volunteers might be the tango-artists ML, but I don't know how many there are there. Finally, I've rebased my patch for the joy.cpl icon. It doesn't have a 256px icon though. Is this wanted? Best Regards Joel Holdsworth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRW/TtAAoJEIsWlGmq62IgaEcIAJYY9q/B3fA2AZQnR5M41qWn Q84e/5jrc1u2w1skmWAkCNdHNHu/R6AURklQ0Hysbnzxp+5GfftPHTKkRzA59cgs jVmkTSiqdVGGeGDRW2YWAcaFiH25xEOqSb9APzMLT4IRVypLbTwWYWhAsaZCa6+0 1USLRakqs5SF7+lCt5VcSHqiko/HPZZsTtNZYDy7cE4DPoNGbajPR9/0fEUfOEj+ b6xyu62tzPHfUcH4hj7YLa7ukJhq2Hh2ELA6gXnjr6yk+pZfx2uMTtfPZ4joWZzw 1DVcyoTkmeCOnasKJU2Obj7vdWgZxWG+WG4KTneH9a+rkSLo6T6Jojae+BXU4O8= =tNa1 -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/5] wined3d: Make fullscreen windows use HWND_TOPMOST instead of HWND_TOP. (try 3)
by Henri Verbeet April 3, 2013

April 3, 2013

I think this series looks good.

1 0

Fwd: GSoC 2013 Ideas Page
by Austin English April 2, 2013

April 2, 2013

I cleaned this up a couple months ago and removed completed/obsolete projects, but it needs further improvements (mostly new ideas). Please contribute any ideas that you have. Thanks! -Austin ---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Tue, Apr 2, 2013 at 1:41 PM Subject: GSoC 2013 Ideas Page To: Carol Smith <carols(a)google.com> Hi there, You're receiving this email because we've reviewed your application for GSoC 2013. We're currently disappointed with the quality of your Ideas Page and would like to give you an opportunity to improve it and your chances of getting into GSoC this year. Please review the FAQs on Ideas Pages<http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc20…> as well as the Mentor Manual section about creating an ideaspage<http://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/> . You have 24 hours from now to improve your ideas page.We will review it again tomorrow. Please let me know if you have any questions. Cheers, Carol -- -Austin

1 1

Re: d3dx9 [patch1/3, try 2]: Do not use relative error for small numbers
by Matteo Bruni April 2, 2013

April 2, 2013

2013/4/1 Nozomi Kodama <nozomi.kodama(a)yahoo.com> > > Since there are only at most 7 significant digits for a float, we must not be too picky about the expected difference for small numbers > > -#define relative_error(exp, out) ((exp == 0.0f) ? fabs(exp - out) : (fabs(1.0f - (out) / (exp)))) > +#define relative_error(exp, out) (fabs(exp) < 0.01f ? fabs(exp - out) : fabs(1.0f - (out) / (exp))) This doesn't make much sense. Being floating point numbers, they have the same relative precision regardless of the magnitude of the value (as long as you are inside the range of representable values and excluding special values and denormals, but that should be irrelevant to our case here). If using a larger tolerance for the test in patch 2 makes it pass, then I think that's all you have to change. Otherwise you need to figure out why the test result differs so much from the expected value. Slightly unrelated, I think we should use fabsf() instead of fabs() there. We are already using fabsf() in a bunch of places, including d3dx9 tests, so there shouldn't be problems with that.

1 0

Re: uxtheme/tests: Don't test for themed app
by Alexandre Julliard April 2, 2013

April 2, 2013

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -84,18 +84,14 @@ static void test_IsThemed(void) > SetLastError(0xdeadbeef); > bThemeActive = pIsThemeActive(); > trace("Theming is %s\n", (bThemeActive) ? "active" : "inactive"); > + ok( GetLastError() == ERROR_SUCCESS || > + broken(GetLastError() == ERROR_FILE_NOT_FOUND /* Win2k8 */), > + "Expected ERROR_SUCCESS, got 0x%08x\n", > + GetLastError()); Testing last error when there's no failure is not useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

exploring/possibly porting winelib app to support 64bit.
by jordan April 1, 2013

April 1, 2013

Hi list. A friend of mine and myself, have been exploring expanding a (currently, 32bit only) winelib app to support 64bit plugins in wine (64). The app is called FSThost, which is used to host win32 VST instruments and effects (.dll) as a standalone app in Gnu/linux. Webpage: http://sourceforge.net/projects/fsthost/ We currently have a example/test app in the source code, which compile as test64.exe / test.exe.so ... you then use the exeutable 'foo'. ~ in this case 'foo' could be /path/to/your/64bitVSTplugin. Currently, the code fails to load the 64bit dll. We are not sure exactly why it is failing, but suspect a couple of reasons. this is where we at at; 1) LoadLibrary - OK 2) GetProcAddress (get address of VSTPluginMain function from DLL library) - OK 3) Initialize plugin - i.e. call VSTPluginMain function from library - FAIL. Potential reasons: - Vestige mismatch - Wine GetProcAddress on 64 bit platform My friend thought someone more familiar with Wine / WinAPI could take a look on this 64bit DLL and at least confirm that address returned by GetProcAddress is correct. (or give us good tips and/or adive). Since, i am already subbed (to wine-devel), i thought i would see if any one was interested in having a look and/or giving us some pointers, tips, etc. Here's an example (with WINEDEBUG="+relay'), full ouput: http://pastebin.com/5b5srr2a A little snippet: 0042:Call ntdll.RtlEncodePointer(002c4620) ret=18002d9aa 0042:Ret ntdll.RtlEncodePointer() retval=c90b263e5a54eb02 ret=18002d9aa 0042:Ret PE DLL (proc=0x18002f27c,module=0x180000000 L"Automaton.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0042:Ret KERNEL32.LoadLibraryA() retval=180000000 ret=7f77bb394167 0042:Call KERNEL32.GetProcAddress(180000000,7f77bb3950b0 "VSTPluginMain") ret=7f77bb394182 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182 Revive plugin: Automaton 0042:Call KERNEL32.UnhandledExceptionFilter(0023e7f0) ret=7f77bbf1fc1a wine: Unhandled page fault on read access to 0x0000022f at address 0x22f (thread 0042), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:elf_search_auxv can't find symbol in module (goto pastebin for the rest / just scroll to bottom of page) If you want to take a look and/or test the code yourself (you need latest code): svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code the source tree is small (like 2 seconds to download). Makefile64 is used to compile the test app (test.c). (just use 'make -f makefile64' from /src dir). alternatively, on sourceforge you can view the test64 app / source code online / here; http://sourceforge.net/p/fsthost/code/154/ (there are several commits following this one, but i believe this one is the most relevant. then to run it (from source dircetory); './test64.exe /path/to/64bitVSTplugin You can get a 'tester' 64bit VST (.dll) to load into test64.exe from here: http://kunz.corrupt.ch/products/tal-elek7ro anyway, any of your insights, help, tips, comments, etc would be both appreciated and helpful. thanks. Jordan

4 8

Re: includes: avoid confusing the preproccesor
by Alexandre Julliard April 1, 2013

April 1, 2013

Austin English <austinenglish(a)gmail.com> writes: > See http://savannah.nongnu.org/bugs/?38557 > > ==== > > In fact, after some investigation, I found out that it's the correct > behavior as '0xfe+1' is considered as a number token by the > preprocessor. I've learned something today :) This has nothing to do with the preprocessor. It's a compiler bug. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winehtml5.drv: Added new HTML5 driver.
by Ken Thomases April 1, 2013

April 1, 2013

On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote: > There are still some missing features. Most notably, it lacks support > for system tray baloons. I know; that's, like, the hardest thing to do! Great work, though! Actually, since HTML is available everywhere, there's little reason for me to continue with the Mac driver. -Ken

4 3

Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
by Henri Verbeet April 1, 2013

April 1, 2013

On 1 April 2013 02:40, Sam Edwards <cfsworks(a)gmail.com> wrote: > I opted not to write ddraw tests. The existing ddraw window style tests > suggest that DirectDraw doesn't even set WS_VISIBLE when initializing a > (non-visible) window, which is very odd, so any new tests would have been > todo_wine anyway. Nonetheless, my changes to wined3d are minimal and > shouldn't affect ddraw's behavior. > I think it's ok for the tests to be todo_wine, but we do want ddraw coverage for this in the tests. > + ZeroMemory( &d3dpp, sizeof(d3dpp) ); > + d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; > + d3dpp.Windowed = TRUE; > + d3dpp.BackBufferWidth = screen_width / 2; > + d3dpp.BackBufferHeight = screen_height / 2; > + hr = IDirect3DDevice9_Reset(device, &d3dpp); > + ok(hr == D3D_OK, "IDirect3DDevice9_Reset failed with %08x\n", hr); I think you'll want to use reset_device() here. (Although I also just notice 766e732fb changed that to use screen_width x screen_height instead of 640x480, which is perhaps a bit of an unfortunate choice. It's fine to change reset_device() to use screen_width / 2 x screen_height / 2, if needed.)

2 2

Re: [1/4] windowscodecs: Basic tests for tiff encoder options (try3)
by Ludger Sprenker April 1, 2013

April 1, 2013

Is there anything wrong with my patches? The first one is marked as "Pending". Am Dienstag, 26. März 2013, 18:46:23 schrieb Ludger Sprenker: > Try3: > - Removed last named value initialization > - Do not check initial value of properties, if the > precondition/initial-type is not matching > (both pointed out by Vincent) > > Note: This was priviously a set of 5 patches, but the original part one has > already been committed. > > --- > dlls/windowscodecs/tests/converter.c | 145 > ++++++++++++++++++++++++++++++++++ > 1 file changed, 145 insertions(+)

2 1

Re: dpnet: Increase reported buffer size
by Marvin April 1, 2013

April 1, 2013

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=24918 Your paranoid android. === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF

1 0

Problem about declarations of strcoll functions
by Jactry Zeng April 1, 2013

April 1, 2013

Hi folks, I tried to implement a lot of strcoll function these days, and I meet some trouble when I added the declaration into include/msvcrt/*.h. With "grep coll *.spec" in dlls/msvcrt/ we can find there was a lot of strcoll function. Some of them was implemented and some of them not: @ cdecl ___lc_collate_cp_func() @ stub __lc_collate @ extern __lc_collate_cp MSVCRT___lc_collate_cp @ cdecl _mbscoll(str str) @ cdecl _mbscoll_l(str str ptr) @ cdecl _mbsicoll(str str) @ cdecl _mbsicoll_l(str str ptr) @ cdecl _mbsnbcoll(str str long) @ cdecl _mbsnbcoll_l(str str long ptr) @ cdecl _mbsnbicoll(str str long) @ cdecl _mbsnbicoll_l(str str long ptr) @ stub _mbsncoll(str str long) # stub _mbsncoll_l(str str long ptr) @ stub _mbsnicoll(str str long) # stub _mbsnicoll_l(str str long ptr) @ cdecl _strcoll_l(str str ptr) MSVCRT_strcoll_l @ cdecl _stricoll(str str) MSVCRT__stricoll @ cdecl _stricoll_l(str str ptr) MSVCRT__stricoll_l @ cdecl _strncoll(str str long) MSVCRT_strncoll_l @ cdecl _strncoll_l(str str long ptr) MSVCRT_strncoll @ cdecl _strnicoll(str str long) MSVCRT__strnicoll @ cdecl _strnicoll_l(str str long ptr) MSVCRT__strnicoll_l # stub _wcscoll_l(wstr wstr ptr) @ cdecl _wcsicoll(wstr wstr) MSVCRT__wcsicoll # stub _wcsicoll_l(wstr wstr ptr) @ cdecl _wcsncoll(wstr wstr long) MSVCRT__wcsncoll @ cdecl _wcsncoll_l(wstr wstr long ptr) MSVCRT__wcsncoll_l @ cdecl _wcsnicoll(wstr wstr long) MSVCRT__wcsnicoll # stub _wcsnicoll_l(wstr wstr long ptr) @ cdecl strcoll(str str) MSVCRT_strcoll @ cdecl wcscoll(wstr wstr) MSVCRT_wcscoll With "grep coll *.h" in include/msvcrt/ we can find some declarations of some strcoll function: crtdefs.h: unsigned int lc_collate_cp; mbstring.h:int __cdecl _mbscoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsicoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsnbcoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnbicoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsncoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnicoll(const unsigned char*,const unsigned char*,size_t); string.h:int __cdecl _stricoll(const char*,const char*); string.h:int __cdecl strcoll(const char*,const char*); string.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); string.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); string.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); string.h:static inline int stricoll(const char* s1, const char* s2) { return _stricoll(s1, s2); } string.h:static inline int wcsicoll(const wchar_t* str1, const wchar_t* str2) { return _wcsicoll(str1, str2); } wchar.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); wchar.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); wchar.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); As we can see, _strcoll_l and _mbsnbcoll_l were implemented but they were not declared. Should we declare all of them? And whether the sequence was important? Thank you. -- Regards, Jactry Zeng

2 2

Re: mshtml: Fixed builtin getter call with arguments.
by Marvin April 1, 2013

April 1, 2013

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=24910 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH] wined3d: Add a registry key to configure buffer object placement
by Henri Verbeet April 1, 2013

April 1, 2013

On 1 April 2013 10:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.placebo == PLACEBO_VIDMEM) > + { > + TRACE("Placing buffer %p in video memory\n", This); > + glHint(This->buffer_type_hint, GL_FASTEST); > + } > + I'm going to go out on a limb and call April fools on this. The state of GL drivers being what it is though, there's a slight chance such a thing actually exists, in which case please link to the documentation instead. Somewhat related, I do actually have a patch to change the usage hint for static vertex buffers to GL_STATIC_DRAW_ARB in my tree, which should actually make the driver more likely to initially place those in VRAM instead of GTT. (It mostly just helps with initial fps after a VB is just created, most drivers eventually figure out the optimal placement anyway and migrate the buffer to vram.)

1 0