August 2012 - Wine-devel - list.winehq.org

Re: msxml3: Implement xmldecl-version property for a reader
by Marvin 27 Aug '12

27 Aug '12

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=21252 Your paranoid android. === W2KPROSP4 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === WXPPROSP3 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W2K3R2SESP2 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === WVISTAADM (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W2K8SE (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W7PRO (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W7PROX64 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === TEST64_W7SP1 (32 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 saxreader: unhandled exception c0000005 at 00443BC3 === W7PROX64 (64 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 Timeout === TEST64_W7SP1 (64 bit saxreader) === saxreader.c:2365: Test failed: got 0x80040154, expected 0x00000000 Timeout

1 0

re: msvcr100: Add wmemmove_s and wmemcpy_s
by Dan Kegel 26 Aug '12

26 Aug '12

I asked Alexandre what http://source.winehq.org/patches/data/88732 needed before it could be reviewed. He said it needed to adapt to the recent parameter checking changes. I see that when he took my patch http://www.winehq.org/pipermail/wine-patches/attachments/20120728/bea2581d/… and committed it as http://source.winehq.org/git/wine.git/patch/49560458426cf25b6a36bbf9bad35aa… he could remove a few assignments to *MSVCRT__errno() because MSVCRT_CHECK_PMT now does that for you. But msvcr100's wmemmove_s/wmemcpy_s are different; they do not change errno. Tests in my patch confirm this. So changing msvcr100's CHECK_PMT macro to assign to errno doesn't seem appropriate. So, is there still anything that needs changing?

2 2

Re: About WineHQ Wiki
by Kyle Auble 26 Aug '12

26 Aug '12

Sorry if my replies come in large batches, I'm subscribed to the mailing list digest. Sun, 26 Aug 2012 10:08, Cheer Xiao wrote: > Hi all, > I'm a MoinMoin contributor, one of MoinMoin's participating students > in this year's Summer of Code. > 2012/8/26 Kyle Auble <randomidman48(a)yahoo.com>: >> Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: >>> When I edited pages in the WineHQ Wiki, I notised, its markup lankuage >>> isn`t so good as MediaWiki`s one. How do you think about moving the Wiki >>> into MediaWiki engine? Besides, moving each language section of the Wiki >>> into separated subdomain (like in Wikipedia) would be a good idea too. >> There are some pluggable parsers for Moinmoin, and there may be one >> that allows MediaWiki syntax. After going through and checking, >> categorizing, and editing so many pages, I definitely agree with your >> suggestion that each language be given a domain, instead of one flat >> namespace. Then maybe just add a single common "translation" menu to >> the side toolbar? > Indeed there is a MediaWiki parser[1]. > Also, take a look at MoinMoin 2.0[2]. It has multiple markups support > out of the box (including mediawiki of course). You can even mix them > in a single wiki instance - this is not necessarily a good idea, but > it helps when you have to migrate some content from another wiki by > hand. ... > Feature requests are welcome, but be noted that MoinMoin 2.0 is the > current development version (it's not a development "branch" since the > codebase is almost a total rewrite) and quite likely the feature you > want is already there (or a TODO). :) Hello, I'm glad to hear there's already a line of communication. Allowing people to use MediaWiki syntax will probably be a big plus. There have been performance problems, but I noticed both the Ubuntu and Moinmoin wikis are pretty snappy so I'm thinking it's due to a strained server and using an old version of Moinmoin (although the SystemInfo macro seems to be disabled, I ran across version info somewhere, and I think Wine Wiki is running Moinmoin 1.5 or 1.6). I'm not sure if other problems I've noticed have been fixed in v1.8 or 1.9 so I would have to try out those versions before checking against v2.0. One thing I have done is written up some python code to help convert HTML tables to Moinmoin ones. I checked in Moinmoin's script market, but could only find full-blown page converters, and their output was kind of messy. I probably got carried away, but I'll attach it to http://wiki.winehq.org/WineStatus because I'm using it to move WineHQ's static status pages to the wiki. I guess that would make it LGPL so if you want to salvage a few parts from it or have me submit it to your utility marketplace, just let me know. Sun, 26 Aug 2012 16:07, Andre Hentschel wrote: > Further it seems a bit more complicated with Wine, the moinmoin wiki is sponsored by http://lattica.com/ (whatever > sponsored means, didn't find further information) and the code > is not accessable via a wine git repo (maybe it should be in tools.git, website.git or its own). This also leads to the > fact that we still have no new wiki theme years after the > theme change on the website. > Now that we upgraded the Forum engine we (we as in laxdragon xD) could maybe do something about the wiki, it > needs love. > It seems Kyle is doing a good job at the content, but the content is not everything. Thank you for the compliment. I am actually planning on doing more coding soon, but besides ramping up, I though cleaning up the wiki some first would let me see where the different parts of the project are. Applying the theme from the rest of the WineHQ is on both the WikiToDo and my own list (no guarantees about how long I would take though). Sun, 26 Aug 2012 22:46, Cheer Xiao wrote: > And yes, as I noted in a previous post moin2 is *not* production-ready > yet and I don't suggest you jump ship now. :) > What I do strongly suggest, however, is that you upgrade to moin1.9 > first, since 1) there has been many security fixes[1] which are not > backported to old versions, and 2) upgrade to moin2 will only be > supported from moin1.9. Helping to upgrade the wiki is on my list somewhere between finishing a first round of polishing content and trying a couple of patches to Wine itself. Although the maintainer would actually have to deploy it, I could test and work some of the kinks out of the upgrade using a local install. Dimi Paun put a lot of work into setting up the wiki in the first place and is the maintainer at lattica. From the git logs and mail list, it seems like he has been really busy with other things for a while. At times, Jeremy Newman has raised the possibility of moving the wiki to WineHQ: http://www.winehq.org/pipermail/wine-devel/2006-June/048712.html I remember stumbling across another email too, but I can't find it right now. If it's still a possibilty, I think the first step would be somehow setting up datadumps so we could start on the upgrade. If there is already a feature for admins to do that, maybe Dimi could start putting a daily/weekly tarball on WineHQ's FTP site. If it requires a custom patch though, I could look into doing that too. -Kyle

1 0

Re: po: Update German translation
by Julian Rüger 26 Aug '12

26 Aug '12

Hi André, war ich zu langsam? ;) Das Komma ist an der Stelle grammatikalisch falsch, glaube ich. "Die verbundenen Controller" sollten auch Plural bleiben. Mein Vorschlag wäre irgendwie so etwas: "Nach dem De-/Aktivieren eines Gerätes wird die Liste der verbundenen Controller bis zum Neustart dieses Applets nicht [mehr] aktualisiert." Viele Grüsse, Julian Am Samstag, den 25.08.2012, 13:40 +0200 schrieb André Hentschel: > "After disabling or enabling a device, the connected joysticks won't be " > "updated here until you restart this applet." >-msgstr "" >+msgstr "Nach dem deaktivieren oder aktivieren eines Gerätes, wird der " >+"verbundene Controller hier bis zum Neustart des Applets nicht mehr " >+"aktualisiert."

1 1

Re: winhttp: disable TLSv1.1/1.2 by default
by Marcus Meissner 26 Aug '12

26 Aug '12

On Sun, Aug 26, 2012 at 11:50:15AM +0900, Hiroshi Miura wrote: > > Windows 7 disables TLSv1.1/1.2 by default. > This patch intend to behave same as Windows. Please do not... The newer TLSv1.x fix some shortcomings of the older TLS versions. Is there a specific problem you see? Otherwise, I object. Ciao, MArcus > Signed-off-by: Hiroshi Miura <miurahr(a)linux.com> > --- > dlls/winhttp/net.c | 74 > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 74 insertions(+) > > > > diff --git a/dlls/winhttp/net.c b/dlls/winhttp/net.c > index 5ec4e1a..03cf9b7 100644 > --- a/dlls/winhttp/net.c > +++ b/dlls/winhttp/net.c > @@ -52,6 +52,7 @@ > #include "winbase.h" > #include "winhttp.h" > #include "wincrypt.h" > +#include "winreg.h" > > #include "winhttp_private.h" > > @@ -109,8 +110,10 @@ MAKE_FUNCPTR( SSL_load_error_strings ); > MAKE_FUNCPTR( SSLv23_method ); > MAKE_FUNCPTR( SSL_CTX_free ); > MAKE_FUNCPTR( SSL_CTX_new ); > +MAKE_FUNCPTR( SSL_CTX_ctrl ); > MAKE_FUNCPTR( SSL_new ); > MAKE_FUNCPTR( SSL_free ); > +MAKE_FUNCPTR( SSL_ctrl ); > MAKE_FUNCPTR( SSL_set_fd ); > MAKE_FUNCPTR( SSL_connect ); > MAKE_FUNCPTR( SSL_shutdown ); > @@ -408,12 +411,66 @@ static int netconn_secure_verify( int preverify_ok, X509_STORE_CTX *ctx ) > } > return ret; > } > + > +static long get_tls_option(void) { > + long tls_option; > + DWORD type, val, size; > + HKEY hkey,tls12_client,tls11_client; > + LONG res; > + const WCHAR Schannel_Prot[] = { /* SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCANNEL\\Protocols */ > + 'S','Y','S','T','E','M','\\', > + 'C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\', > + 'C','o','n','t','r','o','l','\\', > + 'S','e','c','u','r','i','t','y','P','r','o','v','i','d','e','r','s','\\', > + 'S','C','H','A','N','N','E','L','\\', > + 'P','r','o','t','o','c','o','l','s',0 }; > + const WCHAR TLS12_Client[] = {'T','L','S',' ','1','.','2','\\','C','l','i','e','n','t',0}; > + const WCHAR TLS11_Client[] = {'T','L','S',' ','1','.','1','\\','C','l','i','e','n','t',0}; > + const WCHAR DisabledByDefault[] = {'D','i','s','a','b','l','e','d','B','y','D','e','f','a','u','l','t',0}; > + > + tls_option = SSL_OP_NO_SSLv2; /* disable SSLv2 for security reason, and secur32/Schannel(GnuTLS) don't support it */ > + res = RegOpenKeyExW(HKEY_LOCAL_MACHINE, > + Schannel_Prot, > + 0, KEY_READ, &hkey); > + if (res != ERROR_SUCCESS) { > + tls_option |= SSL_OP_NO_TLSv1_2; > + tls_option |= SSL_OP_NO_TLSv1_1; > + goto end; > + } > + if (RegOpenKeyExW(hkey, TLS12_Client, 0, KEY_READ, &tls12_client) == ERROR_SUCCESS) { > + size = sizeof(DWORD); > + if (RegQueryValueExW(tls12_client, DisabledByDefault, NULL, &type, (LPBYTE) &val, &size) || type != REG_DWORD) { > + tls_option |= SSL_OP_NO_TLSv1_2; > + } else { > + tls_option |= val?SSL_OP_NO_TLSv1_2:0; > + } > + RegCloseKey(tls12_client); > + } else { > + tls_option |= SSL_OP_NO_TLSv1_2; > + } > + if (RegOpenKeyExW(hkey, TLS11_Client, 0, KEY_READ, &tls11_client) == ERROR_SUCCESS) { > + size = sizeof(DWORD); > + if (RegQueryValueExW(tls11_client, DisabledByDefault, NULL, &type, (LPBYTE) &val, &size) || type != REG_DWORD) { > + tls_option |= SSL_OP_NO_TLSv1_1; > + } else { > + tls_option |= val?SSL_OP_NO_TLSv1_1:0; > + } > + RegCloseKey(tls11_client); > + } else { > + tls_option |= SSL_OP_NO_TLSv1_1; > + } > + RegCloseKey(hkey); > + > +end: > + return tls_option; > +} > #endif > > BOOL netconn_init( netconn_t *conn, BOOL secure ) > { > #if defined(SONAME_LIBSSL) && defined(SONAME_LIBCRYPTO) > int i; > + long tls_option; > #endif > > conn->socket = -1; > @@ -453,8 +510,10 @@ BOOL netconn_init( netconn_t *conn, BOOL secure ) > LOAD_FUNCPTR( SSLv23_method ); > LOAD_FUNCPTR( SSL_CTX_free ); > LOAD_FUNCPTR( SSL_CTX_new ); > + LOAD_FUNCPTR (SSL_CTX_ctrl); > LOAD_FUNCPTR( SSL_new ); > LOAD_FUNCPTR( SSL_free ); > + LOAD_FUNCPTR( SSL_ctrl ); > LOAD_FUNCPTR( SSL_set_fd ); > LOAD_FUNCPTR( SSL_connect ); > LOAD_FUNCPTR( SSL_shutdown ); > @@ -494,11 +553,20 @@ BOOL netconn_init( netconn_t *conn, BOOL secure ) > LOAD_FUNCPTR( sk_num ); > #undef LOAD_FUNCPTR > > +#define pSSL_CTX_set_options(ctx,op) \ > + pSSL_CTX_ctrl((ctx),SSL_CTRL_OPTIONS,(op),NULL) > +#define pSSL_set_options(ssl,op) \ > + pSSL_ctrl((ssl),SSL_CTRL_OPTIONS,(op),NULL) > + > pSSL_library_init(); > pSSL_load_error_strings(); > > method = pSSLv23_method(); > ctx = pSSL_CTX_new( method ); > + > + tls_option = get_tls_option(); > + pSSL_CTX_set_options(ctx, tls_option); > + > if (!pSSL_CTX_set_default_verify_paths( ctx )) > { > ERR("SSL_CTX_set_default_verify_paths failed: %s\n", pERR_error_string( pERR_get_error(), 0 )); > @@ -676,12 +744,18 @@ BOOL netconn_connect( netconn_t *conn, const struct sockaddr *sockaddr, unsigned > BOOL netconn_secure_connect( netconn_t *conn, WCHAR *hostname ) > { > #ifdef SONAME_LIBSSL > + long tls_option; > + > if (!(conn->ssl_conn = pSSL_new( ctx ))) > { > ERR("SSL_new failed: %s\n", pERR_error_string( pERR_get_error(), 0 )); > set_last_error( ERROR_OUTOFMEMORY ); > goto fail; > } > + > + tls_option = get_tls_option(); > + pSSL_set_options(conn->ssl_conn, tls_option); > + > if (!pSSL_set_ex_data( conn->ssl_conn, hostname_idx, hostname )) > { > ERR("SSL_set_ex_data failed: %s\n", pERR_error_string( pERR_get_error(), 0 )); > > >

1 0

Question about some Linux integration
by Oleg Yarigin 25 Aug '12

25 Aug '12

Hi! I have an idea to move some Wine parts into Linux subsystems. For instance, Wine apps windows and window content can be drawn with Desktop Manager via USER32.DLL opposite of using Wine Server. Similar thing can be with clipboard. I understand, it`s a big work, what is must to be started with an EXE loader. So I have a few questions before I can start: 1. Does Wine loader have any mechanism for loading .so files. 2. May I move all loader stuff from NTDLL to the loader. Is it rational? I asked, becouse there are a lot of stuff, that can be unloaded after program loading. And an off-top question: where is wine_server_call realisation defined? --- Oleg

2 2

About WineHQ Wiki
by Oleg Yarigin 25 Aug '12

25 Aug '12

Hi to all! When I edited pages in the WineHQ Wiki, I notised, its markup lankuage isn`t so good as MediaWiki`s one. How do you think about moving the Wiki into MediaWiki engine? Besides, moving each language section of the Wiki into separated subdomain (like in Wikipedia) would be a good idea too. --- Oleg

1 0

Re: [1/16] po: Update Russian translation
by Dmitry Timoshkov 24 Aug '12

24 Aug '12

These new translations look at least questionable to say the least. -- Dmitry.

2 1

Re: advapi32/tests: Skip a couple of registry tests on NT4 to avoid crashing it.
by Alexandre Julliard 24 Aug '12

24 Aug '12

Francois Gouget <fgouget(a)free.fr> writes: > I know it's bad form to test for the Windows version but I'm not sure > what other check would be relevant here. I think we can safely ignore such old versions at this point. -- Alexandre Julliard julliard(a)winehq.org

1 0

configure --with-osmesa fails to link
by Peter Urbanec 24 Aug '12

24 Aug '12

I just turned on --with-osmesa and configure fails for me: > checking for -lOSMesa... not found > configure: error: libOSMesa development files not found (or too old), > OpenGL rendering in bitmaps won't be supported. > This is an error since --with-osmesa was requested config.log output would suggest that perhaps the test is being treated as C code, but libOSMesa needs to link with C++ libs. > configure:9067: checking for -lOSMesa > configure:9092: gcc -o conftest -g3 -feliminate-unused-debug-symbols > -O0 -mtune=core2 conftest.c -lOSMesa -lSM -lICE -lXext -lX11 > -lm >&5 > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator delete[](void*)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator new(unsigned long)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_get_proc_address' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator delete(void*)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_get_dispatch_table_size' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `operator new[](unsigned long)' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `__cxa_pure_virtual' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `__gxx_personality_v0' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_get_context' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `vtable for __cxxabiv1::__class_type_info' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_add_dispatch' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_check_multithread' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_tls_Context' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_set_context' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `vtable for __cxxabiv1::__si_class_type_info' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_set_dispatch' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: > undefined reference to `_glapi_tls_Dispatch' > collect2: ld returned 1 exit status This is on Gentoo x64 with: media-libs/mesa-8.1_rc1_pre20120814 (classic egl g3dvl gallium llvm nptl osmesa shared-glapi vdpau xvmc -bindist -d3d -debug -gbm -gles1 -gles2 -kernel_FreeBSD -openvg -pax_kernel -pic -r600-llvm-compiler -selinux -video_cards_i915 -video_cards_i965 -video_cards_intel -video_cards_nouveau -video_cards_r100 -video_cards_r200 -video_cards_r300 -video_cards_r600 -video_cards_radeon -video_cards_radeonsi -video_cards_vmware -wayland -xa -xorg) sys-devel/gcc-4.6.3 (cxx fortran graphite mudflap multilib nls nptl openmp -altivec -bootstrap -build -doc -fixed-point -gcj -go -gtk -hardened -libssp -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla) Any suggestions as to how this could be fixed? My autoconf skills are no match for this problem :-( Thanks.

3 3