Re: I'm not sure why it was rejected
On Wed, Oct 02, 2013 at 12:26:51PM -0300, Bruno Jesus wrote: On Wed, Oct 2, 2013 at 12:17 PM, Akira Nakagawa matyapir...@gmail.com wrote: I cannnot make sure my patch 99266 was rejected. I can't really tell why it was rejected but I can tell there are mixed space/tabs in the SetLastError lines. I guess if you SetLastError to not implemented you cannot return S_OK too Try comparing your patch with other patches that added new dlls. It looks like you're missing the changes in configure and Makefile.in. http://source.winehq.org/git/wine.git/?a=searchh=HEADst=commits=new+dll no, he is not as they are autogenerated. Last open issue was the incorrect licenses. Ciao, Marcus
Re: add ualapi directory (try 11)
On Sat, Sep 28, 2013 at 11:58:33AM +0900, Akira Nakagawa wrote: From 2ecc71fdb3406d3cf79ebcbd7f6d0c711b68d699 Mon Sep 17 00:00:00 2001 Message-Id: 2ecc71fdb3406d3cf79ebcbd7f6d0c711b68d699.1379923234.git.matyapir...@gmail.com From: Akira Nakagawa matyapir...@gmail.com Date: Mon, 23 Sep 2013 17:00:04 +0900 Subject: [PATCH] add ual directory (try9) --- configure | 2 + Not needed to be submitted configure.ac| 2 + also not actually needed as these parts are autogenerated. dlls/ualapi/Makefile.in | 6 +++ dlls/ualapi/main.c | 86 + dlls/ualapi/tests/Makefile.in | 8 dlls/ualapi/tests/ualapi_test.c | 38 ++ You have no working tests yet, so leave these two files out. Add them with the patch with the first tests. dlls/ualapi/ualapi.spec | 4 ++ include/Makefile.in | 1 + include/Makefile.in is also autoadjusted. include/ual.h | 48 +++ 9 files changed, 195 insertions(+) rest looks ok, but you really only should submit: dlls/ualapi/Makefile.in dlls/ualapi/main.c dlls/ualapi/ualapi.spec include/ual.h as the rest are autogenerated. Ciao, Marcus
Re: my patch was wrong at dlls/kernel32/computernames.c
On Thu, Aug 29, 2013 at 11:31:06PM +0900, matyapiro31 wrote: From if ( isalnumW ( wc ) ) return wc; for ( i = 0; i 17; i++ ) To if ( isalnumW ( wc ) ) return wc; for ( i = 0; i 16; i++ ) and the original version was wrong,too. It counts the NULL of the end. Thats why you should use sizeof() or strlen() ... and not hardcoded magic values. CIao, Marcus
Re: Process for reporting security bugs?
Hi, On Sat, Aug 10, 2013 at 01:12:24PM +0900, Andrew Church wrote: [Please cc: me on any replies since I'm not subscribed to the list.] Hi, Is there a specific process for reporting security-related bugs in Wine? I've looked through winehq.org but haven't found any mention of such; I just wanted to make sure I haven't overlooked anything before posting the bug in a publicly visible manner. There is no such process set up for Wine yet. If you want to report a thing privately, you could mail our chief in command, Alexandre Julliard julli...@winehq.org privately and perhaps CC me as I am a security guy at SUSE ;) If it is not a high severe issue you can also just mail this mailinglist here (wine-devel). Ciao, Marcus
Re: Process for reporting security bugs?
On Mon, Aug 12, 2013 at 10:40:48PM +0900, Andrew Church wrote: Hi Marcus, If it is not a high severe issue you can also just mail this mailinglist here (wine-devel). Thanks for the info. As it turns out, it's an already-known issue (unixfs allows full host filesystem access through Windows APIs even if there's no equivalent dosdevices link -- reported as http://bugs.winehq.org/show_bug.cgi?id=22450) so I just added a comment onto the bug. Depending on what attack scenario you envision, disabling unixfs is not enough. If you want to avoid actually executed malware from accessing the UNIX fs directly, you are out of luck as the malware could just do systemcalls itself (int 0x80 on x86 for instance). Remember Wine is made to execute Win32 code. ;) If you think indirectly executed unixfs shellfolder accesses, this might be blocked by that, yes. Ciao, Marcus
Re: [PATCH] oleaut32: ERR on 32bit typelibs on 64bit
On Fri, Aug 02, 2013 at 04:29:07PM +0200, Alexandre Julliard wrote: Marcus Meissner meiss...@suse.de writes: Triggered by the Novell Groupwise installer currently, from the ISBE64W.exe Installshield Helper program. The typelib is contained directly in ISBE64W.exe itself :/ Basically if we encounter this case the program will crash anyway (but with random backtrace), so output an ERR(). That looks like it's just hiding the problem. Well, more like a finger pointing at the problem until its fixed. But yes. CIao, Marcus
Re: NtCreateFile fails
On Mon, Jul 29, 2013 at 04:02:03PM +0200, Mislav Blazevic wrote:
First of all, pardon my ignorance, I am new to wine and winapi.
I am trying to implement apphelp.dll and I ran into issues with
NtCreateFile: It always returns 0xc103, STATUS_NOT_A_DIRECTORY, and I
am not sure what that means. Here is code:
/* This function is not in API, but written for internal use */
HANDLE WINAPI SdbOpenFile( LPCWSTR path, PATH_TYPE type )
{
/* SNIP */
if (type == DOS_PATH)
if (!RtlDosPathNameToNtPathName_U(path, str, NULL, NULL))
return NULL;
InitializeObjectAttributes(attr, str, OBJ_CASE_INSENSITIVE, NULL, NULL);
status = NtCreateFile(file, GENERIC_READ | SYNCHRONIZE |
FILE_READ_ATTRIBUTES,
attr, io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ,
FILE_OPEN, FILE_DIRECTORY_FILE, NULL, 0);
/* SNIP */
return file;
}
Function is called like this:
WCHAR szFileName[1024] = {0};
ExpandEnvironmentStringsW(L%SystemRoot%\\sample.sdb, szFileName, 1024);
// for testing purposes
SdbOpenFile(szFileName, DOS_PATH);
Compiled with winegcc.
I am sure that C:\windows\sample.sdb exists. What am I doing wrong?
Try printing out the expanded string. It will probably just print C
Lstring does not work to specify WCHAR*, as the Linux L strings are
differently sized than the Windows L strings.
Ciao, Marcus
Coverity Status
Hi, For Wine 1.6 we have the following Coverity stats: - 3,648,322 Lines of Code scanned - Defect Density 0.51 - 8321 total defects - 1852 outstanding (unresolved) defects - 1964 dismissed defects - 4505 fixed defects git shortlog wine-1.4..wine-1.6|grep -i Coverity|wc -l 225 Thanks to AmineKhaldi uploading the builds and everyone reviewing and fixing coverity issues :) Ciao, Marcus
Re: Another major milestone
On Thu, Jul 18, 2013 at 04:55:42PM -0500, Jeremy White wrote: Alright folks, I have to confess that the 1.6 release came and I didn't immediately get up and dance. In fact, a new Wine release was almost...boring. I think we have to consider that a major milestone in of itself. New, useful releases are just a matter of course for us now. Woohoo! Now I'm dancing grin. I keep hearing Considering that it took you 15 years for 1.0 you are grinding them out really fast now ;) Ciao, Marcus
Re: Another major milestone
On Fri, Jul 19, 2013 at 09:00:30AM -0500, Rosanne DiMesio wrote: On Thu, 18 Jul 2013 16:55:42 -0500 Jeremy White jwh...@codeweavers.com wrote: Alright folks, I have to confess that the 1.6 release came and I didn't immediately get up and dance. In fact, a new Wine release was almost...boring. What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. Either we are good :) Or we should have reminded and called for this kind of tagging and bug squashing work. Ciao, Marcus
Re: Another major milestone
On Fri, Jul 19, 2013 at 06:32:32PM +0100, Ken Sharp wrote: On 19/07/13 15:00, Rosanne DiMesio wrote: On Thu, 18 Jul 2013 16:55:42 -0500 Jeremy White jwh...@codeweavers.com wrote: Alright folks, I have to confess that the 1.6 release came and I didn't immediately get up and dance. In fact, a new Wine release was almost...boring. What was most striking to me about this release was the fact that not a single bug was targeted to be fixed for 1.6. The practice of nominating bugs for specific milestones seems to have been abandoned. I can't help but wonder why. http://bugs.winehq.org/show_bug.cgi?id=24611 was added two days ago. *shrugs* We noticed too late. ;) But thats software management life, you always have bugs left over when you release. More for 1.6.1 or 1.7.x :) Ciao, Marcus
Re: Need help with debugging a directx9 game crashing
On Fri, Jul 19, 2013 at 04:06:56PM +0200, Henri Verbeet wrote: On 19 July 2013 15:34, Qian Hong fract...@gmail.com wrote: Further tests show that the simplest hack to avoid crashing is replacing line 71 to: FIXME(anything %x\n, 0xdeadbeef); I have no idea what the real fix is, any suggestion what is the next step to debug? Well, it sounds a bit like some form of memory corruption. Sometimes WINEDEBUG=warn+heap helps with tracking those down. Also, I don't suppose the d3d9 object was already destroyed earlier? Or timing ... Also can you print out refcount there to see if the refcounting is good? Ciao, Marcus
Re: [PATCH] ole32: LeaveCriticalSection in one exit case (Coverity)
On Sun, Jun 23, 2013 at 08:43:18PM +0900, Dmitry Timoshkov wrote:
Marcus Meissner mar...@jet.franken.de wrote:
--- a/dlls/ole32/ifs.c
+++ b/dlls/ole32/ifs.c
@@ -217,6 +217,8 @@ static LPVOID WINAPI IMalloc_fnRealloc(LPMALLOC
iface,LPVOID pv,DWORD cb) {
IMallocSpy_Release(Malloc32.pSpy);
Malloc32.SpyReleasePending = FALSE;
Malloc32.pSpy = NULL;
+ /* cb == 0 case will release it some lines below. */
+ if (cb) LeaveCriticalSection(IMalloc32_SpyCS);
}
if (0==cb) {
Why not unconditionally release the lock before the '0==cb' check?
That would cause LeaveCriticalSection be called twice with a race window
inbetween.
Of course you'd need to remove a redundant LeaveCriticalSection under
'if (0==cb)' case, and I don't see a race there.
I resubmitted a slightly improved fix, but I do not think it can be made as
simple as you think it can.
Ciao, Marcus
Re: [PATCH] ole32: LeaveCriticalSection in one exit case (Coverity)
On Sun, Jun 23, 2013 at 07:15:43PM +0900, Dmitry Timoshkov wrote:
Marcus Meissner mar...@jet.franken.de wrote:
--- a/dlls/ole32/ifs.c
+++ b/dlls/ole32/ifs.c
@@ -217,6 +217,8 @@ static LPVOID WINAPI IMalloc_fnRealloc(LPMALLOC
iface,LPVOID pv,DWORD cb) {
IMallocSpy_Release(Malloc32.pSpy);
Malloc32.SpyReleasePending = FALSE;
Malloc32.pSpy = NULL;
+ /* cb == 0 case will release it some lines below. */
+ if (cb) LeaveCriticalSection(IMalloc32_SpyCS);
}
if (0==cb) {
Why not unconditionally release the lock before the '0==cb' check?
That would cause LeaveCriticalSection be called twice with a race window
inbetween.
CIao, Marcus
Re: [PATCH] ole32: fixed 3 handle leaks (Coverity)
On Mon, Jun 10, 2013 at 10:43:58AM +0900, Dmitry Timoshkov wrote: Marcus Meissner mar...@jet.franken.de wrote: 1030106 Resource leak 1030105 Resource leak 1030104 Resource leak These cases are of the kind 'freeing resources at process exit is not useful'. Well, it is code that is run within a library. The usage pattern is unclear and might cover repeated calls. Ciao, Marcus
Re: [PATCH] ole32: fixed 3 handle leaks (Coverity)
On Mon, Jun 10, 2013 at 08:25:42AM +0200, Marcus Meissner wrote: On Mon, Jun 10, 2013 at 10:43:58AM +0900, Dmitry Timoshkov wrote: Marcus Meissner mar...@jet.franken.de wrote: 1030106 Resource leak 1030105 Resource leak 1030104 Resource leak These cases are of the kind 'freeing resources at process exit is not useful'. Well, it is code that is run within a library. The usage pattern is unclear and might cover repeated calls. ah, that was ole_server.c ... of course this is not a library. But please ... good practice? :( Ciao, Marcus
Re: msvcrt: remove hack
On Wed, May 29, 2013 at 10:23:29PM -0700, Austin English wrote: This was added 12 years ago in 1db20bfd33f9c1486a1a662c2f78f45d00caf24b but clang doesn't like it: clang -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_MT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -o process.o process.c process.c:363:10: warning: explicitly assigning a variable of type 'int' to itself [-Wself-assign] action = action; /* Remove warning */ ~~ ^ ~~ 1 warning generated. and no modern gcc/other compiler that I can find cares. It was probably added because of a tool that warned of the unused parameter ... So it all goes in circles. ;) Ciao, Marcus
Re: wine-patches
On Thu, May 02, 2013 at 08:12:53AM +0200, Daniel Jeliński wrote: Hello, I sent a ~200KB patch to wine-patches last night and it disappeared without a trace. I'm wondering if it got lost or just went to moderation. Regards, Daniel PS.I just resent it, still no luck. If you are subscribed, the list size trigger will probably have happened and it is waiting for moderation. What is in the 200KB patch? If its sourcecode, it is too large even without looking at it. :) Ciao, Marcus
Re: Fun with GCC 4.8
On Mon, Apr 15, 2013 at 02:37:27PM -0600, James Eder wrote: As many of you no doubt know, GCC recently released 4.8.0. This new version introduces a new optimization level enabled by -Og with the following description (from the man page): Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. Of course I had to try it out. I found that building Wine lead to GCC dieing with ... dlls/kernel32/console.c:1691:1: internal compiler error: Segmentation fault I also found ... dlls/kernel32/computername.c:701:1: internal compiler error: Segmentation fault I eventually stumbled my way into the enclosed patch which lets GCC build Wine with -Og. I'm not sure if this change (or something similar) makes sense for Wine. I'm fairly certain some changes make sense for GCC (I suspect that GCC should not segfault). I haven't submitted a bug for GCC because I suspect they'll want me to provide something simpler to compile than the Wine source tree. I certainly won't be upset if someone beats me too it. I'm not sure how much time in the near future I'll spend on it. Eventually is probably the word that fits. At any rate, I wanted to at least share my experiences in case anyone is interested in heading down the same path. You copy and paste the failing commandline and add --save-temps, like e.g.: gcc -c -I/home/marcus/projects/wine/dlls/kernel32 -I. -I/home/marcus/projects/wine/include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_NORMALIZE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -gdwarf-2 -gstrict-dwarf -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -Wall -g -fstack-protector -o console.o /home/marcus/projects/wine/dlls/kernel32/console.c -Og --save-temps it will generate a console.i file in the currenct directory. The console.i file and above commandline are a start for the gcc bug. Ciao, Marcus
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hi, Well, your testcase had a trivial mistake which i now see. This line: typedef struct AEffect * (*main_entry_t)(audioMasterCallback); must read: typedef struct WINAPI AEffect * (*main_entry_t)(audioMasterCallback); WINAPI is critical here, as it changes the call from the SysV AMD64 calling convention to the Microsoft x64 one which is entirely different. (That it works for 32bit is probably just luck.) If you fix it in fst.h: fst.h:typedef struct AEffect * (*main_entry_t)(audioMasterCallback); It will probably also work better. Ciao, Marcus On Sat, Apr 06, 2013 at 06:41:42PM -0400, jordan wrote: Hey Marcus, Can you add a printf(plugin %p\n, plugin); after above line? I would suspect things like: - checks for processor features and returns 0x if not found. I added this line to the sources / compiled and tested - here is output: http://pastebin.com/QMtWttRZ I'n not sure what to make of it. I've been trying to nail down what the problem might be on my system (to no avail). It's really strange... I've tried different kernels, different versions of wine, using a binary version of the test app (not compiled on my machine). but nothing seems to work. Jordan
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
On Thu, Apr 04, 2013 at 07:39:16PM -0400, jordan wrote: Hey List, A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86). the original post is here (for those interested, but not entirely relevant to this post): http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to-support-64bit-td5750102.html moving on. So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails. - Successful on Intel: xj@xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close So intel computers tested (2 that i know of) work just fine. - Failure on AMD: http://pastebin.com/x64pig3s and a little snippet: ./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0x at address 0x (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module Works for me on my AMD Phenom(tm) II X4 945 Processor. It looks like the struct AEffect* plugin = main_entry((audioMasterCallback) simple_master_callback); returns 0x, which is probably a failure indication. Can you add a printf(plugin %p\n, plugin); after above line? I would suspect things like: - checks for processor features and returns 0x if not found. CIao, Marcus
Re: [PATCH 8/8] configure: Get rid of no longer needed OpenSSL checks.
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
Re: [PATCH 8/8] configure: Get rid of no longer needed OpenSSL checks.
On Wed, Apr 03, 2013 at 02:33:06PM +0200, Marcus Meissner wrote: 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). After talking to my legal council ... it is only a problem for GPLv2 - GPLv3 http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility So please ignore me. Ciao, Marcus
Re: Crash confuses me
On Thu, Mar 07, 2013 at 07:53:57PM +, Graham wrote: I use a LD_PRELOAD before running wine so that i can debug my application. The library which is preloaded is able to replace system dlsym and from that, other consequence library call. There is no problem until, i put some Detour code(hot patching) into the kernel32.dll.so address space. But the very funny things is this **THE PROGRAM CRASHES BEFORE MY HOTPATCH IS APPLIED ** so it seems somehow the order of cause and effect is extremely weird and frightening to me. How can a piece of code which is not excecuted be teh cause for errors PRIOR/BEFORE to its execution. And this is surely happening because when i uncomment the Hotpatch/detour lines the problem goes away. here are some lines from the crashs ... err:module:attach_process_dlls user32.dll failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for LC:\\windows\\system32\\winemenubuilder.exe failed, status c005 wine: Unhandled page fault on execute access to 0x7c9e4cd7 at address 0x7c9e4cd7 (thread 000b), starting debugger... err:module:DelayLoadFailureHook failed to delay load user32.dll.BroadcastSystemMessageW wine: Call from 0x7b83ba92 to unimplemented function user32.dll.BroadcastSystemMessageW, aborting wine: Unimplemented function user32.dll.BroadcastSystemMessageW called at address 0x7b83ba92 (thread 001d), starting debugger... Another thing to notice is that this was tested using wine1.4.1 However it DOES work with wine1.5.10 ... to get something to work for me is not the challenge, its to understand the logic behind why something does not. THanks a lot and I am grateful for any who contributes his knowledge to this problem i am a real NOVICE real NOVICE and using LD_PRELOAD or hotpatching does not fit together for me...? - wine uses it own elfloader, which might cause issues. - during loading/linking it might also interact already. what should the LD_PRELOAD thing achieve? Can perhaps a wine internal debug mechanism be used already? Ciao, Marcus
Re: Crash confuses me
On Sat, Mar 09, 2013 at 01:40:00AM +, Graham wrote: On 08/03/13 22:40, Francois Gouget wrote: On Fri, 8 Mar 2013, Marcus Meissner wrote: [...] real NOVICE and using LD_PRELOAD or hotpatching does not fit together for me...? - wine uses it own elfloader, which might cause issues. Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here. the functions i detoured in kernel32.dll.so were LoadLibrary and FreeLibrary, the question still remains how its even possible, this should be a fairly straight-forward thing to answer for you developers, i would had thought. If its too much to understand , please say :/ i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so , but the code only runs at a later certain time after program execution ... ( trigger is actually a certain library loaded, i detect it in dlsym ) ... But in wine 1.4.1 the program crashes at a time earlier than the triggered detour, understand?? This don't seem physically possible, any explanation? In loader/preloader.c is our own pre-elf-loader, which handles the specific address space layouts we use. All the library loading is very magic even to me and I have to understand it anew every time ;) Why not just patch the Wine source itself and build a specific Wine version for your problem? This makes it easier and avoids need of preloading tricks. You probably also want to patch LdrLoadDll in ntdll. Ciao, Marcus
Re: [PATCH] cryptui: use add_oid_to_usage correctly (Coverity)
On Fri, Feb 01, 2013 at 03:48:27PM -0800, Juan Lang wrote: On Fri, Feb 1, 2013 at 3:45 PM, Juan Lang juan.l...@gmail.com wrote: Hi Marcus, -add_oid_to_usage(usage, ptr); +usage = add_oid_to_usage(usage, ptr); This looks fine, but would you mind making the same change on line 337? Actually, perhaps I hit sent too early. If this memory allocation fails, which is the only situation under which add_oid_to_usage doesn't just return its first parameter, it'll immediately crash on the next invocation with a NULL pointer dereference. I'm not sure it's worth all the trouble in an out of memory situation. Perhaps just remove the return value and let the caller crash. Actually the loop around checks that as a condition and would lead to return NULL: for (ptr = usageStr, comma = strchr(ptr, ','); usage ptr *ptr; For the second one the loop around does not catch it. I think the add_oid_to_usage() should not even do it this way and not touch usage at all, but instead return a memory allocation error and let the caller handle it:/ Or just let it crash. Ciao, Marcus
Re: [PATCH 2/2] jscript: Fixed a leak in regexp_match function
On Fri, Jan 25, 2013 at 04:26:59PM +0100, Piotr Caban wrote:
---
dlls/jscript/regexp.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/dlls/jscript/regexp.c b/dlls/jscript/regexp.c
index 0d66551..fa2668c 100644
--- a/dlls/jscript/regexp.c
+++ b/dlls/jscript/regexp.c
@@ -3466,10 +3466,15 @@ static HRESULT regexp_match(script_ctx_t *ctx,
jsdisp_t *dispex, jsstr_t *str, B
break;
if(ret_size == i) {
-if(ret)
-ret = heap_realloc(ret, (ret_size = 1) *
sizeof(match_result_t));
-else
+if(ret) {
+match_result_t *old_ret = ret;
+
+ret = heap_realloc(old_ret, (ret_size = 1) *
sizeof(match_result_t));
+if(!ret)
+heap_free(old_ret);
Should be probably if (ret) heap_free(old_ret); here.
+}else {
ret = heap_alloc((ret_size=4) * sizeof(match_result_t));
+}
if(!ret) {
hres = E_OUTOFMEMORY;
break;
Re: Reload a DLL and _getptd returns zero
On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote: Hi list, Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd? At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time. Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash. The sequence is: 1. [main] start a thread 2. [main] load a library 3. [thread] call std::cout from the library 4. [main] free the library 5. [main] reload the library 6. [thread] call std::cout from the library - crash! It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash. The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero. Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded? Any hints, thoughts? clues? Thanks! Is this statically linked msvcrt from Wine or Windows? And why free/reload a statically linked library? Ciao, Marcus
Re: Patchsets that need review by experienced Wine Developers
On Thu, Jan 03, 2013 at 05:22:14PM -0500, jordan wrote: Hi, I have been experimenting with some patchsets for Wine - based on an implementation of Wine originally developed By Muse Research. It has improved support for a bunch of stuff, fixes (most) bottlenecks for Linux proaudio folks making use of Wine + Jack, and also contains some bug fixes for wine (that may or may not be acceptable to wine-devs.) I have a project that now lives on SF.net, but has been running for months now, on my machine(s), locally. It's called L-ProAudio, and the version of wine (L_pa-Wine) is geared towards proaudio users. We also have support in 1 linux application ~ which now properly handles the new method of mapping win/prio - linux/prio. Some of the patchset fixes synchronization issues (with jack), disk geomtery-io-syscl, fixes rendering bugs in VSTs (probably other apps too) and a bunch of other improvements (geared for proaudio users). L_ProAudio SF.net Page: https://sourceforge.net/projects/l-proaudio/ - Wine-L_Proaudio_Arch_n_patches.tar.gz contains a pkgbuild for Archlinux (like gentoo' ebuild) + all patches (and probably one or two others, not used in my builds). But please note: this is NOT a fork of Wine. It is necessary for me to be able to run the applications that i want with Wine. I am just carrying patchwork and re-basing it, as time passes. But i decided to release it - since it benefits the larger community who uses this stuff (greatly). note 2: I am posting, in order to shed light on any improvements/bug fixes that _might_ be suitable for upstream. ~ If so, once a given stable release of Wine is issued, I would then be able to remove them from my patchset, minimizing duplicate efforts, among other things. The original patches/sources (that i have based my version on, are found here: http://www.museresearch.com/support/receptor-faq.php ...at the bottom of the page / last link: http://www.museresearch.com/support/receptor-faq.php these patches fix Wine problems (in most areas) for people using linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes for wine. It's Gpl'd (obviously), so it would be worthwhile to have a look anyway. - didn't include every patch (some of them aren't of interest to me, outdated, etc). I looked over them briefly. 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch Not sure why this is needed? 0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch a user32.EnableWindow 2008 patch ... is it still needed for you, as quite some enhancements have happened... Would need review (likely from julliard or other user32 guru) and testcases. 0012-ntdll-Use-pipes-for-synchronization-objects.patch 0050-pipe-check-and-thread-safe-read.patch A new synchronization method using UNIX pipe(2)s. This is definitely not going in as is... It would be interesting to know what deficit in regular Wine is fixed by it. wineserver overhead? 0023-improve-IoRegisterDeviceInterface.patch Remove the MUSE specific fixmes and use the same FIXME() style for stub parameters as in the other FIXME()s. Then its ready for wine-patches I would say. 0025-Add-stub-for-IoSetDeviceInterfaceState.patch Use same FIXME() style as used for other stub functions, then ready for submission. 0027-Add-stub-for-PoSetPowerState.patch Good for submission as-is. 0033-overridable-default-filesystem-type.patch Not submittable as-is ... It would be good to know the reason and/or what MUSE expects. 0044-get-windows-label-from-registry.patch Smells like the wrong place to do it. Perhaps mountmgr.sys, but perhaps different. Also unclear if Alexandre likes it. 0052-NI-drag-and-drop.patch Looks already good for submission to me. 0054-set-realtime-priority-without-wineserver.patch wine-rt-101107.patch Needs design and discussion... So far a RT solution was not accepted for Wine yet. 0061-fix-broken-cross-compiled-winegcc.patch 0063-disable-winedbg-auto-crash-dialog.patch local hacks 0062-disable-crashing-alpha-bitmaps-for-gdb.patch Seems like a mistaken patch that was needed as we had the old DIB sections. gdb would have accepted continue here. Should not be necessary anymore these days with the DIBENGINE. add-implementation-setProcessWorkingSetSize.patch Might be submittable as-is. Might need autoconf checks for non-Linux. Fix-disk-geometry-ioctl.patch Alexandre usually does not like override files like this unless necessary. What is actually expected? you mentioned rendering issues? fix-obscured-windows.patch Hmm, needs user32 windowing guru review. menu-border-color.patch If this is not just a hack, could be submitted as-is.
Re: [PATCH 2/2] kernel32: conditional variable support
On Sun, Dec 30, 2012 at 12:02:34AM +0400, Nikolay Sivov wrote:
On 12/29/2012 23:04, Marcus Meissner wrote:
From: Marcus Meissner marcus@jet.(none)
Modeled pretty much after the implementation described
in glibc/nptl/DESIGN-condvar.txt with its futex usage
sofar replaced by regular Win32 Semaphores.
An additional futex implementation is possible.
I *think* I have the semantics correct, there is 1 small
place where it might have unnecessary CPU usage though.
Ciao, Marcus
+/**
+ * InitializeConditionVariable (KERNEL32.@)
+ */
+VOID WINAPI InitializeConditionVariable(PCONDITION_VARIABLE variable)
+{
+struct _condition_var_intern *var;
+variable-Ptr =
HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,sizeof(struct
_condition_var_intern));
+var = variable-Ptr;
+if (!var) return;
+InitializeCriticalSection (var-crit);
+var-crit.DebugInfo-Spare[0] = (DWORD_PTR)(__FILE__ :
ConditionVariable.cs);
+}
I don't think it allocates anything at all, what makes me believe
that is that stuff like CONDITION_VARIABLE_INIT exists.
After googling a bit for it I see that gallium from mesa has some
platform dependent stuff in code that uses this API like that:
---
+#define pipe_static_condvar(cond) \
+ /*static*/ pipe_condvar cond = CONDITION_VARIABLE_INIT
---
So this structure has nothing more than a single pointer value,
value 0 of it means it's initialized. I think you could just add
some tests to see if it's really reset to 0 from initial value.
I am not fully sure. The SDK only has PVOID Ptr and that alone
is not enough space to implement conditional variables.
CONDITION_VARIABLE_INIT is only there to init it to NULL.
(if you look at the SDK CONDITION_VARIABLE_INIT seems to be {0} )
So I suspect some private data structure is hidden into it.
I however do not know if windows allocates it from heap
or from where exactly.
Also regarding tests I don't think randomizing timeouts is a good
idea cause it adds some unpredictable behaviour and it's not really
clear if we could rely on such tests results.
I have to think about those some more :/
I testing Adobe Lightroom 4 with the patch I encountered more conditions
I should probably also test for.
Ciao, Marcus
Re: Small patch to make Adobe Lightroom 4.x work with wine 1.5.17
Hi, Sorry for not answering sooner, I was distracted by work and a broken workstation at home :/ On Sun, Dec 02, 2012 at 04:19:24PM +0100, Roland Baudin wrote: Hi, here is a small patch that allows me to make Adobe Photoshop Lightroom 4.x work very well with wine 1.5.17. First let me recall that Adobe Photoshop Lightroom is *the* catalog and raw development application for professional photographers and hobbyists. The patch has two parts. The first part essentially modifies the file sync.c from the kernel32 dll and implements some functions related to Condition Variables. I found an original patch by Marcus Meissner and I fixed it because it led to a 100% CPU load. I tried to contact Marcus to discuss my changes with him, but he didn't answer and so I submit my changes to this list, otherwise my work would be lost... So generally, my patch is basically just a hack to get it work. While it does work mostly, it is not the best and correct implementation, and Alexandre wants a correct implementation of Condition Variables. I don't have the time to do it right currently. :/ The second part modifies the file menu.c from the user32 dll. It allows the menu bar to appear in Lightroom when the windows version is set to winxp. I'm not the author of this patch but if I remember well, I found it several monthes ago somewhere in the wine patch list. This might be easier to get in as above, but it should be seperated out and likely needs a testcase. Perhaps the other gurus can take it ;) With the patch applied, I was able to run Lightroom 4.2 flawessly, and it's very stable. I (and other users) have found only minor bugs (like a limitation of the number of shown thumbnails to 455 per folder on a 22 inches display) but the patch is a huge step forward for Lightroom. Here is a link where I explain the whole installation procedure (message #34) : http://www.pentaxforums.com/forums/digital-processing-software-printing/159894-lightroom-3-4-linux-its-alive-working-pretty-well-3.html I apologize because I don't have the skills to write a test for the functions of this patch... No worries, even feedback and hacky patches help to show where Wine can go :) Ciao, Marcus
Re: [PATCH 20/25] mciseq: Check stop condition after sleeping. (Try 5)
On Wed, Oct 17, 2012 at 10:36:44AM +0200, joerg-cyril.hoe...@t-systems.com wrote: Please note that the patch queue failed to detect some superseded patches: 90588: I should not have named that 17/25 in the first place. 90672 + 90674: the original 20-21/25 were never marked superseded by later patches. 90841+ 90482: try 3 was superseded by try 4, now superseded by this try 5. I would suggest to resubmit your queue in smaller batches (like eg. 5 pieces per day) and wait for it to get applied. In the current state testbot will not be run on the sequence I think. Ciao, Marcus
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
On Tue, Oct 16, 2012 at 12:38:51PM +0200, Jacek Caban wrote:
---
dlls/ntdll/string.c | 12 +++-
dlls/ntdll/tests/string.c | 33 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
index 716dbdf..288e910 100644
--- a/dlls/ntdll/string.c
+++ b/dlls/ntdll/string.c
@@ -254,7 +254,17 @@ int __cdecl _stricmp( LPCSTR str1, LPCSTR str2 )
*/
int __cdecl _strnicmp( LPCSTR str1, LPCSTR str2, size_t n )
{
-return strncasecmp( str1, str2, n );
+int ret = 0;
+
+/* 32-bit Windows return only -1,0,1 values */
+while(n--) {
+if(!*str1)
+return sizeof(void*) == 4 ? (*str2 ? -1 : 0) : -(unsigned
char)*str2;
+if((ret = tolower(*str1++) - tolower(*str2++)))
+return sizeof(void*) == 4 ? (ret 0 ? 1 : -1) : ret;
+}
Errm. Why not
int ret = strncasecmp( str1, str2, n );
if (ret 0 ) return -1;
if (ret 0 ) return 1;
return 0;
Ciao, Marcus
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
On Tue, Oct 16, 2012 at 01:12:50PM +0200, Jacek Caban wrote:
On 10/16/12 13:08, Marcus Meissner wrote:
On Tue, Oct 16, 2012 at 12:38:51PM +0200, Jacek Caban wrote:
---
dlls/ntdll/string.c | 12 +++-
dlls/ntdll/tests/string.c | 33 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
index 716dbdf..288e910 100644
--- a/dlls/ntdll/string.c
+++ b/dlls/ntdll/string.c
@@ -254,7 +254,17 @@ int __cdecl _stricmp( LPCSTR str1, LPCSTR str2 )
*/
int __cdecl _strnicmp( LPCSTR str1, LPCSTR str2, size_t n )
{
-return strncasecmp( str1, str2, n );
+int ret = 0;
+
+/* 32-bit Windows return only -1,0,1 values */
+while(n--) {
+if(!*str1)
+return sizeof(void*) == 4 ? (*str2 ? -1 : 0) : -(unsigned
char)*str2;
+if((ret = tolower(*str1++) - tolower(*str2++)))
+return sizeof(void*) == 4 ? (ret 0 ? 1 : -1) : ret;
+}
Errm. Why not
int ret = strncasecmp( str1, str2, n );
if (ret 0 ) return -1;
if (ret 0 ) return 1;
return 0;
That wasn't the original reason for writing this patch. It seems like
some distros (well, at least some Gentoo installations) have broken
strncasecmp.
How exactly? Do you know more details / urls?
Does it return -n ... +n values? Like the memcmp optimization that caused mysql
security issue?
In that case my patch should work.
Ciao, Marcus
Re: [PATCH] rpcrt4: wait_async_request: return error if we received an error
On Tue, Oct 02, 2012 at 01:19:37PM +0200, Jacek Caban wrote:
Hi Marcus,
On 10/01/12 23:00, Marcus Meissner wrote:
Hi,
Various coverity issues complain about user-after-free scenarios,
all involving this code path.
I strongly think if call_ret signals error, we also need to return
an error condition to avoid the callers from proceeding as if nothing
happened.
Second reiteration with Jaceks comment applied
Sorry for not catching this later, I was concentrated on your comment
instead of the code, but the important thing is that true call_ret means
success (and wininet doing request asynchronously is signalled as an
error). It means that in this case we want to return RPC_S_OK. What is
the exact problem?
Ok, my fix was likely bad.
Coverity is spotting use-after-free scenarios.
CID 715805
rpcrt4_http_prepare_in_pipe()
/* prepare in pipe */
status = send_echo_request(in_request, async_data, cancel_event);
if (status != RPC_S_OK) return status;
... here it thinks async_data might be returned freed in the non-async case ...
memset(buffers_in, 0, sizeof(buffers_in));
buffers_in.dwStructSize = sizeof(buffers_in);
/* FIXME: get this from the registry */
buffers_in.dwBufferTotal = 1024 * 1024 * 1024; /* 1Gb */
prepare_async_request(async_data);
... but it is again referenced here ...
ret = HttpSendRequestExW(in_request, buffers_in, NULL, 0, 0);
status = wait_async_request(async_data, ret, cancel_event);
if (status != RPC_S_OK) return status;
send_echo_request() looks like:
static RPC_STATUS send_echo_request(HINTERNET req, RpcHttpAsyncData
*async_data, HANDLE cancel_event)
{
DWORD bytes_read;
BYTE buf[20];
BOOL ret;
RPC_STATUS status;
prepare_async_request(async_data);
ret = HttpSendRequestW(req, NULL, 0, NULL, 0);
status = wait_async_request(async_data, ret, cancel_event);
if (status != RPC_S_OK) return status;
status = rpcrt4_http_check_response(req);
if (status != RPC_S_OK) return status;
InternetReadFile(req, buf, sizeof(buf), bytes_read);
/* FIXME: do something with retrieved data */
return RPC_S_OK;
}
so with the bumped reference count via prepare_async_request I think it might
be safe here.
(and so is a coverity misdetection I think now)
Ciao, Marcus
Re: [PATCH] secur32/schannel: diabled TLS1.1/1.2 by Default
On Mon, Sep 10, 2012 at 12:14:51AM +0900, Hiroshi Miura wrote: -Set TLS1.1/1.2 disabled by Default that is same as Windows 7 default. See registry entry for schannel and control enable/disable tls versions. It also see grbitEnabledProtocols defined in credentials that take precedence over registry. I think the regression issue with TLS 1.1/1.2 is the empty fragments sending, right? Perhaps we can just disable that and not all of TLS 1.1/1.2? Ciao, Marcus
Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)
On Sun, Sep 02, 2012 at 11:40:52PM +0900, Dmitry Timoshkov wrote:
Marcus Meissner meiss...@suse.de wrote:
+if (!pInitializeConditionVariable) {
+skip(no condition variable support.\n);
+return;
+}
Probably this should be a win_slip().
The function exists only since Windows 7/Vista (not XP) and is not yet
in Wine (and might take a while, as my time is limited currently
and my knowledge of this specific function same).
So I think skip is currently the right thing ;)
+/* fprintf(stderr,produced %d, c1 %d, c2 %d\n, totalproduced, cnt1,
cnt2); */
+
+/* The sleeps of the producer or consumer should not go above 1,
otherwise
+ * the implementation does not sleep correctly. */
+
+/* fprintf(stderr,producer sleep %d, consumer sleep %d\n,
condvar_producer_sleepcnt, condvar_consumer_sleepcnt); */
There is trace() for debug output, it's shorter and more convenient IMHO.
True, I could do that, but its not relevant for the test as-is.
Ciao, Marcus
Re: winhttp: disable TLSv1.1/1.2 by default
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 miur...@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 @@
Re: wine/server: removed obsolete one-iteration loop from request forming macro (try 2)
On Thu, Aug 23, 2012 at 11:14:23AM +0400, Oleg Yarigin wrote:
An original message was sent with wrong author`s name by mistake, so
I resend this patch with hope it was the only reason to reject it.
It was not the only reason.
A single loop is a common pattern in C to allow safe encapsulation
and handling of blocks, or doing break;/continue; style things.
One thing that it allows here in Wine is that the variable definitions
are at the begin of a { } block and not in the middle of the code
to allow old C standard builds to work still.
There is no break; usage, although I spotted 1 goto done; which
could be just a break; ;)
The compiler will optimize everything of those loops away, so this change
also brings no performance improvement.
Ciao, Marcus
---
include/wine/server.h | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/include/wine/server.h b/include/wine/server.h
index d573d1f..dcbc7fa 100644
--- a/include/wine/server.h
+++ b/include/wine/server.h
@@ -124,19 +124,15 @@ static inline void *wine_server_get_ptr( client_ptr_t
ptr )
/* macros for server requests */
#define SERVER_START_REQ(type) \
-do { \
-struct __server_request_info __req; \
-struct type##_request * const req = __req.u.req.type##_request; \
-const struct type##_reply * const reply =
__req.u.reply.type##_reply; \
-memset( __req.u.req, 0, sizeof(__req.u.req) ); \
-__req.u.req.request_header.req = REQ_##type; \
-__req.data_count = 0; \
-(void)reply; \
-do
-
-#define SERVER_END_REQ \
-while(0); \
-} while(0)
+struct __server_request_info __req; \
+struct type##_request * const req = __req.u.req.type##_request; \
+const struct type##_reply * const reply = __req.u.reply.type##_reply; \
+memset( __req.u.req, 0, sizeof(__req.u.req) ); \
+__req.u.req.request_header.req = REQ_##type; \
+__req.data_count = 0; \
+(void)reply;
+
+#define SERVER_END_REQ
#endif /* __WINE_WINE_SERVER_H */
-- 1.7.9.5
--
Open Linux Security Engineer Position at SUSE: http://bit.ly/Li4RbS
Re: GSoC mentor summit 2012
On Fri, Jul 27, 2012 at 01:20:20PM +0200, Stefan Dösinger wrote: Am Donnerstag, 26. Juli 2012, 16:07:52 schrieb Owen Rudge: It looks like the GSoC mentor summit for 2012 has been announced. Are any of the mentors this year interested in attending? It's happening on the 20th/21st October in Mountain View. Sure, why not :-) That said, I've been there before, so if two other mentors who haven't been to the summit yet want to go I am happy to yield the spot. I dont want to travel to the US just for this, so count me out ;) Ciao, Marcus
Re: Have there been any problems with Wine on GCC 4.7?
On Mon, Jul 23, 2012 at 07:06:21PM -0700, Scott Ritchie wrote: Wine is the last remaining package still depending on GCC 4.5 in the current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port Wine, however 4.6 is known to not work too well. But now we have 4.7 -- have there been any bugs attributed to its usage? For what its worth, openSUSE 12.2 (in RC Phase) has gcc 4.7 and builds with Wine with it, so far I have no bug reports. Ciao, Marcus
Re: Query MediaType of SD-Cards using IOCTL_GET_DISK_DRIVE_GEOMETRY
On Mon, Jul 16, 2012 at 07:12:59AM +0200, Eduard Hasenleithner wrote: Am 2012-07-15 22:04, schrieb GOUJON Alexandre: On 07/14/2012 09:14 PM, Eduard Hasenleithner wrote: [...] This means that the drive letter assigned for the sd card will not be returned in GetLogicalDrives(). When the symlink to the mountpoint is added manually, following output is produced: Does http://source.winehq.org/patches/data/88280 solve your GetLogicalDrives issue ? Well yes, with the patch all the drive letters are reported by GetLogicalDrives (although there are quite a lot due to the multi-slot card reader). This means that the drive letters are also visible in explorer.exe. But in explorer I still cannot have a look at the drive contents because there is no symlink in dosdevices which points to the mount point. Perhaps an issue here is that by default the card/drive is not mounted in the current udisks/udisks2 setups The mount process need to be initiated by the desktop client (either KDE, GNOME or perhaps Wine) on demand. Ciao, marcus
Re: Debugging wine/windows applications
On Sat, Jul 07, 2012 at 12:17:00AM +0300, John Yani wrote: I tried to run wine under gdb and failed. Using multiprocess gdb I endup with weird trace: 0xf7ffd430 0x7bc846f9 0x7bc8480f 0x7bc84855 0x7bc42a94 0x7bc433b1 0x7b8772f7 0x7ebab89b 0x7bc80014 0x7bc8005d Where 0x7** addresses are not connected to any module. And 0xf** addresses are from /lib/ld-linux.so.2, debug symbols for which I can't find. Can somebody explain what's hapenning? Running wine with winedbg under gdb fails with message err:module:LdrInitializeThunk Main exe initialization for LC:\\windows\\system32\\notepad.exe failed, status c022 Is there any tutorial on how to run wine with applications under gdb? winedbg can hook gdb into itself, which will make this work better I think. winedbg --gdb notepad.exe Ciao, Marcus
Re: Debugging wine/windows applications
On Sat, Jul 07, 2012 at 01:11:42PM +0300, John Yani wrote: Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg binary. This would be the same. There usually is a winedbg wrapper installed that does the same, but for all purposes its the same thing. Ciao, Marcus
Re: Debugging wine/windows applications
On Sat, Jul 07, 2012 at 01:25:12PM +0300, John Yani wrote: I tried WINELOADER=./wine winedbg --gdb notepad And its output is the same as ./wine winedbg --gdb notepad Well, i have a installed wine... but doing this there: wine winedbg.exe --gdb notepad.exe 0042:0043: create process 'C:\Windows\System\notepad.exe'/0x1106f8 @0x7ee012b0 (00) fixme:dbghelp_dwarf:dwarf2_parse_line_numbers Unsupported extended opcode 0 fixme:dbghelp_dwarf:dwarf2_parse_line_numbers Unsupported extended opcode 0 fixme:dbghelp_dwarf:dwarf2_parse_line_numbers Unsupported extended opcode 0 fixme:dbghelp_dwarf:compute_location Only supporting one breg (edi/24 - esi/23) 0042:0043: create thread I @0x7ee012b0 GNU gdb (GDB) SUSE (7.2-3.3) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. 0042:0043: loads DLL C:\Windows\System\KERNEL32.dll @0x7b81 (00) 0042:0043: loads DLL C:\Windows\System\ntdll.dll @0x7bc1 (00) 0042:0043: loads DLL C:\Windows\System\advapi32.dll @0x7e7e (00) 0042:0043: loads DLL C:\Windows\System\gdi32.dll @0x7e85 (00) start_process (peb=0x7ffdf000) at /home/marcus/projects/wine/dlls/kernel32/process.c:1083 1083return call_process_entry( peb, entry ); trace: 98 = 80 Wine-gdb bt #0 start_process (peb=0x7ffdf000) at /home/marcus/projects/wine/dlls/kernel32/process.c:1083 #1 0x7bc75670 in call_thread_func_wrapper () from /home/marcus/projects/32wine/dlls/ntdll/ntdll.dll.so #2 0x7bc7794d in call_thread_func (entry=0x7b85e1c0 start_process, arg=0x7ffdf000, frame=0x33ffc8) at /home/marcus/projects/wine/dlls/ntdll/signal_i386.c:2522 #3 0x7bc7564e in call_thread_entry_point () from /home/marcus/projects/32wine/dlls/ntdll/ntdll.dll.so #4 0x7bc4d7de in start_process (kernel_start=0x7b85e1c0) at /home/marcus/projects/wine/dlls/ntdll/loader.c:2653 #5 0xf75c4bad in wine_call_on_stack () from /home/marcus/projects/32wine/libs/wine/libwine.so.1 #6 0xf75c4c6b in wine_switch_to_stack (func=0x7bc4d7c0 start_process, arg=0x7b85e1c0, stack=0x34) at /home/marcus/projects/wine/libs/wine/port.c:59 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Wine-gdb c Continuing. ^C Program received signal SIGTRAP, Trace/breakpoint trap. 0xe423 in ?? () Wine-gdb bt #0 0xe423 in ?? () #1 0x7bcb6ff4 in ?? () from /home/marcus/projects/32wine/dlls/ntdll/ntdll.dll.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) Wine-gdb Its not having the correct symbols there, but basically works. Or I also tried: $ wine notepad.exe ... wait until window shows ... $ ps auxw|grep notepad marcus 26694 0.4 0.1 1785696 10084 pts/6 t12:27 0:00 notepad.exe $ gdb /usr/bin/wine (gdb) attach 26694 0xe425 in __kernel_vsyscall () (gdb) bt #0 0xe425 in __kernel_vsyscall () #1 0xf764e0e3 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x7bc796c8 in wait_reply (cookie=0x32f3bc) at /home/marcus/projects/wine/dlls/ntdll/sync.c:807 #3 0x7bc7bb03 in NTDLL_wait_for_multiple_objects (count=1, handles=0x32f438, flags=4, timeout=0x0, signal_object=value optimized out) at /home/marcus/projects/wine/dlls/ntdll/sync.c:1122 #4 0x7bc7bbf5 in NtWaitForMultipleObjects (count=1, handles=0x32f438, wait_all=0 '\000', alertable=0 '\000', timeout=0x0) at /home/marcus/projects/wine/dlls/ntdll/sync.c:1160 #5 0x7b86fe3f in WaitForMultipleObjectsEx (count=1, handles=0x32f61c, wait_all=0, timeout=4294967295, alertable=0) at /home/marcus/projects/wine/dlls/kernel32/sync.c:190 #6 0x7e4c3bc5 in WaitForMultipleObjectsEx_ichk (count=1, handles=0x32f61c, timeout=4294967295, mask=1279, flags=0) at /home/marcus/projects/wine/include/winbase.h:2600 #7 X11DRV_MsgWaitForMultipleObjectsEx (count=1, handles=0x32f61c, timeout=4294967295, mask=1279, flags=0) at /home/marcus/projects/wine/dlls/winex11.drv/event.c:472 ... Ciao, Marcus
Re: Building WoW64 packages
On Mon, Jun 25, 2012 at 11:21:33PM +0200, Hilko Bengen wrote: Hi, after the effort on the Debian wine packages has progressed to a point where it's likely that we'll release wheezy with a stable wine version that is not completely out of date, I'd like to take things a step further. I recently spent some time looking at ways how we could build Debian packages for a shared WoW64 setup similar to what is described in http://wiki.winehq.org/Wine64. We will have to use separate build environments because having 32-bit and 64-bit -dev packages installed at the same time is not possible. Installing a 64-bit package that contains the build tools into a 32-bit environment should be possible, though. This is not necessary. From looking at the build system, things happen in a different way when I run configure for the 32-bit components with --wine64=...: 1. Manpages are not installed (WOW64_DISABLE) 2. --disable-fonts is implied 3. --disable-server is implied, so wineserver is not built. (The 64-bit wineserver is used instead, right?) Correct. 4. --disable-tools is implied because the existing build tools are being used. Did I miss anything? Leaving parts out is easy to understand, but how do the build tools that have been built for the x86_64 architecture affect the 32-bit components that are being built with them? Are different paths encoded into libwine? Not really ... you can create 32bit and 64bit built Wine packages without having cross dependencies. You just need to pack less files for the 32bit one if you use it with a 64 prefix. So for 32bit, do not use --with-wine64, just package the relevant things for the -32bit build. What is needed from the 32bit build in a WoW context is: /usr/bin/wine /usr/bin/wine-preloader /usr/lib/wine/fakedlls/* /usr/lib/libwine*.so* /usr/lib/wine/*.so* and for development additionally: /usr/lib/wine/*.def Ciao, Marcus
Re: DllMain() seems unused in ntoskrnl.exe
On Wed, Jun 13, 2012 at 07:46:47PM +0200, Francois Gouget wrote: The DllMain() function in ntoskrnl.exe appears to be unused: making it static causes a compiler warning to that effect and removing it entirely does not cause a compilation failure. Should it be removed or is there a build issue with ntoskrnl.exe? I added a FIXME() at the beginning, then typed notepad and it showed fixme:ntoskrnl:DllMain called So it is called. Not exactly sure, but I guess somehow via the loader magic. Ciao, Marcus
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
On Wed, Jun 06, 2012 at 11:31:52AM +0200, Jacek Caban wrote: Hi Marcus, On 06/06/12 10:17, Marcus Meissner wrote: Hi, wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. The list is just not setup yet as we fail... Ciao, Marcus --- dlls/shell32/control.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c index cb080d5..b3eddb6 100644 --- a/dlls/shell32/control.c +++ b/dlls/shell32/control.c @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) } if (applet-proc) applet-proc(applet-hWnd, CPL_EXIT, 0L, 0L); FreeLibrary(applet-hModule); -list_remove( applet-entry ); +if (applet-entry.next) list_remove( applet-entry ); HeapFree(GetProcessHeap(), 0, applet-cmd); HeapFree(GetProcessHeap(), 0, applet); } The way Wine standard list implementation works, it should not be NULL here. It seems that list_init call is missing where the CPlApplet is allocated. The error handling that calls this leaves the Control_LoadApplet function before it is attached to the list head. list_add_head( panel-applets, applet-entry ); is not called before leaving the function. No other list_ functions are used by Control_LoadApplet. Not sure if this is right, or if there should be a entry init? Ciao, Marcus
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
On Wed, Jun 06, 2012 at 11:56:06AM +0200, Jacek Caban wrote: On 06/06/12 11:52, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). There's no reason to call list_init on list entries, it should only be called on the actual list. Oh, right, sorry for misleading. I made wrong assumptions looking at the patch. So, Alexandre, is my patch right or wrong? And if wrong, can you quickly fix it:) Ciao, Marcus
size of wine packages
Hi, As we have crossed the 100MB installed size (stripped) for the Wine RPM packages (stripped), this makes a Wow64 capable installation taking around 200MB these days. Can we reduce this size? eg. kernel32.dll.so has 1.6MB of static data inside itself, which is puzzling me a bit. (winerror.res is 1.3MB, winerror.mc is 0.068 MB ... Huh? Translations blowing this up?) Out of 100MB /usr/lib/wine/, e.g. I have here 67 MB of .text (73MB on x86_64) 11 MB of .data (static data) Ciao, Marcus
Re: running 16bit code
On Tue, May 08, 2012 at 12:06:23PM +0100, David Laight wrote: On Tue, May 08, 2012 at 12:03:52PM +0200, Damjan Jovanovic wrote: On Tue, May 8, 2012 at 11:40 AM, David Laight da...@l8s.co.uk wrote: Does wine support running of 16bit windows apps? If so does it rely on the underlying OS having support for 'virtual 8086 emulation'? I'm thinking of removing the VM86 support from NetBSD, and wine is about the only likely user. ? ? ? ?David -- David Laight: da...@l8s.co.uk 16 bit Windows applications are written and compiled to either use real mode or 16 bit protected mode. Those that use real mode (mostly MS-DOS and Windows 1 and 2 applications) need virtual 8086 mode. Those that use protected mode (mostly Windows = 3.0 applications) don't need virtual 8086 mode. Ok, so wine users would be very unlikely to be affected. Since most of the 16bit apps post-date windows 3. Correct. You'd break DOSBOX a lot more than Wine. Possibly, although some emulators are probably better bets for DOS. But why do you want to remove this from NetBSD? I thought compatibility with other operating systems was one of its major features? Mainly because it isn't used much, and may well contain security holes. There are two separate kernel options VM86 (usually enabled) and KVM86 (usually disabled). Both change some low level code is obscure ways. for what it is worth... 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 ;) Ciao, Marcus
Re: Patch 85420
On Tue, Apr 17, 2012 at 09:10:45PM +0200, Christian Costa wrote: Hi, Patch http://source.winehq.org/patches/data/85420 is marked as pending. I've taken a look but I still don't understand what's wrong. Is there anything I've missed ? I stopped reading at this line: +*frame = (LPDIRECT3DRMFRAME)(impl_from_IDirect3DRMFrame3(This-parent)-IDirect3DRMFrame2_iface); You are doing something very wrong if you need to cast this way. It probably also needs explicit sign-off drom the d3d folks as it handles funny refcounting. Ciao, Marcus
Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)
On Mon, Apr 16, 2012 at 11:53:00AM -0500, Andrew Eikum wrote: On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote: Also initialize a may be uninitialized value the compiler sees. Not sure what this means. *num is initialized at the beginning of alsa_enum_devices, which is always called from GetEndpointIDs. Seems like a Coverity oversight. I'd either leave it as-is, or also remove the *num=0 from alsa_enum_devices. It cannot handle two variables that track the same logic easily. So it cannot see counter and content variables that belong together. I marked it as FALSE now. Ciao, Marcus
Re: Regression testing
On Thu, Apr 12, 2012 at 10:23:07AM +0200, Daniel Jeliński wrote: Hello all, I am trying to get Microsoft SQL Server Management Studio to work flawlessly under Wine. For the most part I create and triage related bug reports, but recently I also started tinkering with code, specifically with comctl library, which I am most familiar with. Back on subject. I thought I found a regression - on Wine 1.4 package downloaded from launchpad the New query button works fine, while on my compiled Wine it produces an error. So I did: git reset --hard wine-1.4 make and, surprisingly, I still had the problem with the compiled version. However after some combination of deleting leftover files, running make clean, make depend and make the button started working, so I started bisecting, hoping for the best. At some point I started getting bad versions, and every subsequent compile was bad - even after I ended bisecting and returned to wine-1.4, the button still did not work (and it still works under packaged Wine - I use the same install for all tests). This time make clean make depend make did not help. I am comparing what I did to [1], and the only difference I see is that I did not run configure before make. I'll try doing that later, but I think this shouldn't affect the outcome. Any other ideas? Also [1] suggests to set CC=ccache gcc -m32 on amd64 machines. I did that and when doing make I noticed that many lines start with: ccache gcc -m32 -m32 I guess that CC=ccache gcc would be enough - but I didn't test that yet. Also I noticed that running parallel make (make -j) is never mentioned on [1]. Is there any reason I shouldn't use it? Did you make clean in between the bisect steps? Especially going backwards during bisecting might be problematic. Also if there is some specific in the created wineprefix it might be necessary to recreate the wineprefix during every test :/ Ciao, Marcus
Re: 'Pending' patches state
On Tue, Apr 10, 2012 at 04:52:42PM +0900, Dmitry Timoshkov wrote: Jeff Latimer l...@yless4u.com.au wrote: I agree a lot of developers would benefit from feedback, however that does not appear to be the Wine way of doing business. Maybe a halfway measure would be to automatically notify the developer that their patch has been marked as pending and then the developer can ask. Something like Your patch is pending, you have to ask to get an answer why.? But the answer known, and it is * The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help. * Waiting for feedback from the main developer in that area. And how is that better than current situation when in order to get a feedback a developer have to ask? Q: What's wrong with my patch xxx? A: The patch is not obviously correct at first glance... Q: What can I do? A: Making a more convincing argument, preferably in the form of a test case, may help. ... or may not help. http://wiki.winehq.org/SubmittingPatches suggests If your patch disappears from http://source.winehq.org/patches/ without being committed, improve it (perhaps by adding more tests) and resend. The patch disappears from the patch tracker in a month. You have plenty time for 11 resends in an year, don't you? Also Alexandre to some parts comments on bad patches these days. :) Ciao, Marcus
Re: Wine and Window Management
On Sat, Mar 24, 2012 at 07:12:14PM -0700, Roger Cruz wrote: Could someone tell me if Wine has a built-in Window Manager of its own or does it count on the host's window manager for such things as window hierarchy (parent-child relationships), clipping, move, resize, iconify, etc? I want to run Wine on an environment which lacks X and I have been told conflicting information on whether I need to write my own window manager. It has always been my impression that Wine does all the window management so it must have a Windows window manager built-in. In Desktop Mode Wine does its own window management. You can test it by setting desktop mode in winecfg. ;) I'm interested in knowing that if I remove the X11 driver from Wine, whether I will have to also provide my own window manager or whether what is in Wine is sufficient. If there is a window manager in Wine, what type of functionality does it require from whatever I chose to replace X11 with? Then you will need to write your own display engine first, which will be a bit harder than the window manager part. (Not sure how much additional work you will need to get the desktop managed mode in.) ciao, Marcus
Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168
On Tue, Mar 20, 2012 at 06:40:37PM -0700, Joey Yandle wrote: Hi everybody, As originally discovered by Carsten Juttner, Star Wars: The Old Republic uses the time values in KUSER_SHARED_DATA to trigger network send buffers. wine does not currently update these values, so TOR does not make it past an initial server handshake. I'm attaching my current patch which fixes this. It updates the values every 1560 nanoseconds as does Windows 7, and presumably all Windows versions. The words of the timers are written in the correct order for applications to detect clock tick. It uses a separate thread which does nothing else; a previous attempt at an NtTimer based solution did not work, presumably due to irregularity in the exact callback times. Attempts at setting thread priority were also abandoned after many people were unable to run the code. The patch does not check the return code of nanosleep; I could add code to nanosleep again for the remaining time in the case of an interrupt, but didn't think it was necessary. I could also change it to use clock_nanosleep, which would allow for more absolute timing. Please let me know what you think. - pthread_create() is pretty much a no-go. Use Win32 apis instead (CreateThread() and WaitFor*) - The shared data structure should be modified with atomic accesses only. (Or use a criticalsection if possible.) However, I do not know if we can have additional threads at all in a Win32 process without confusing the win32 processes, or if this needs to be solved differently (APC?). Ciao, Marcus
Re: NtDelayExecution: reduce multiple stack allocation
On Sat, Mar 10, 2012 at 04:20:20PM +0100, Ferdinand Nölscher wrote: In ntdll/sync.c, line 1232 the struct timeval is being allocated in a for-loop. Would'nt it be faster if tv was created before entering the loop? I have not tested doing so but I think that it would increase performance a tiny bit. Do not worry, the space for it is not allocated per loop. All compilers from the last 20 years allocate the stackspace on function entry once. Ciao, Marcus
Re: [PATCH] README: updated Linux and FreeBSD kernels
On Wed, Feb 22, 2012 at 10:44:31AM +0100, Francois Gouget wrote: On Wed, 22 Feb 2012, Marcus Meissner wrote: --- README | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/README b/README index baa6ab3..0cbb047 100644 --- a/README +++ b/README @@ -29,7 +29,7 @@ especially the wealth of information found at http://www.winehq.org. To compile and run Wine, you must have one of the following: Linux version 2.0.36 or above - FreeBSD 6.3 or later + FreeBSD 8.0 or later [...] FreeBSD info: - Wine will generally not work properly on versions before FreeBSD - 6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See - http://wiki.freebsd.org/Wine for more information. + Wine will generally not work properly on versions before FreeBSD 8.0. + See http://wiki.freebsd.org/Wine for more information. Is there a reason why Wine won't work right on FreeBSD 7.0? Winetest seems mostly ok. http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_BSD.html I followed the note on http://wiki.freebsd.org/Wine who does not mention older versions than 8.0. I have no other information. Ciuao, Marcus
Re: msxml3: Fix varargs handling in libxml2 error callback implementation
On Thu, Feb 16, 2012 at 01:55:44AM +0300, Nikolay Sivov wrote:
The problem is that vsnprintf() was called multiple times with same
va_list. Ti fix that it was necessary to get rid of some tracing
bits like macro-defined callback calls and a single function for all
kinds of error types.
As far as I understand this problem it leads to a stack corruption
when va_list is used multiple time without va_start/va_end around
it, so it's critical to fix.
If I remember correctly, you can even process a va_list only once
on some platforms.
If you need to process it multiple times, you need to create a copy
with va_copy() first.
Ciao, Marcus
From d75433c8ff34e125c7db1fb665bdb9271991b9f5 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov nsi...@codeweavers.com
Date: Thu, 16 Feb 2012 01:06:16 +0300
Subject: [PATCH 1/1] Fix varargs handling in libxml2 error callback
implementation
---
dlls/msxml3/domdoc.c| 50 +---
dlls/msxml3/main.c | 49 +---
dlls/msxml3/msxml_private.h | 18 ++---
dlls/msxml3/schema.c| 90
++-
dlls/msxml3/selection.c |4 +-
5 files changed, 80 insertions(+), 131 deletions(-)
diff --git a/dlls/msxml3/domdoc.c b/dlls/msxml3/domdoc.c
index 64122ce..9bcecdd 100644
--- a/dlls/msxml3/domdoc.c
+++ b/dlls/msxml3/domdoc.c
@@ -425,23 +425,7 @@ static void sax_characters(void *ctx, const xmlChar *ch,
int len)
xmlSAX2Characters(ctxt, ch, len);
}
-static void LIBXML2_LOG_CALLBACK sax_error(void* ctx, char const* msg, ...)
-{
-va_list ap;
-va_start(ap, msg);
-LIBXML2_CALLBACK_ERR(doparse, msg, ap);
-va_end(ap);
-}
-
-static void LIBXML2_LOG_CALLBACK sax_warning(void* ctx, char const* msg, ...)
-{
-va_list ap;
-va_start(ap, msg);
-LIBXML2_CALLBACK_WARN(doparse, msg, ap);
-va_end(ap);
-}
-
-static void sax_serror(void* ctx, xmlErrorPtr err)
+static void libxml2_sax_structerror(void* ctx, xmlErrorPtr err)
{
LIBXML2_CALLBACK_SERROR(doparse, err);
}
@@ -472,9 +456,9 @@ static xmlDocPtr doparse(domdoc* This, char const* ptr,
int len, xmlCharEncoding
sax_characters, /* ignorableWhitespace */
xmlSAX2ProcessingInstruction, /* processingInstruction */
xmlSAX2Comment, /* comment */
-sax_warning,/* warning */
-sax_error, /* error */
-sax_error, /* fatalError */
+libxml2_warn_callback, /* warning */
+libxml2_error_callback, /* error */
+libxml2_error_callback, /* fatalError */
xmlSAX2GetParameterEntity, /* getParameterEntity */
xmlSAX2CDataBlock, /* cdataBlock */
xmlSAX2ExternalSubset, /* externalSubset */
@@ -482,10 +466,12 @@ static xmlDocPtr doparse(domdoc* This, char const* ptr,
int len, xmlCharEncoding
NULL, /* _private */
xmlSAX2StartElementNs, /* startElementNs */
xmlSAX2EndElementNs,/* endElementNs */
-sax_serror /* serror */
+libxml2_sax_structerror /* serror */
};
xmlInitParser();
+TRACE((%p)-(%p %d %d)\n, This, ptr, len, encoding);
+
pctx = xmlCreateMemoryParserCtxt(ptr, len);
if (!pctx)
{
@@ -2634,22 +2620,6 @@ static inline BOOL is_wellformed(xmlDocPtr doc)
#endif
}
-static void LIBXML2_LOG_CALLBACK validate_error(void* ctx, char const* msg,
...)
-{
-va_list ap;
-va_start(ap, msg);
-LIBXML2_CALLBACK_ERR(domdoc_validateNode, msg, ap);
-va_end(ap);
-}
-
-static void LIBXML2_LOG_CALLBACK validate_warning(void* ctx, char const*
msg, ...)
-{
-va_list ap;
-va_start(ap, msg);
-LIBXML2_CALLBACK_WARN(domdoc_validateNode, msg, ap);
-va_end(ap);
-}
-
static HRESULT WINAPI domdoc_validateNode(
IXMLDOMDocument3* iface,
IXMLDOMNode* node,
@@ -2695,11 +2665,11 @@ static HRESULT WINAPI domdoc_validateNode(
if (get_doc(This)-intSubset || get_doc(This)-extSubset)
{
xmlValidCtxtPtr vctx = xmlNewValidCtxt();
-vctx-error = validate_error;
-vctx-warning = validate_warning;
+vctx-error = libxml2_error_callback;
+vctx-warning = libxml2_warn_callback;
++validated;
-if (!((node == (IXMLDOMNode*)iface)?
+if (!((node == (IXMLDOMNode*)iface) ?
xmlValidateDocument(vctx, get_doc(This)) :
xmlValidateElement(vctx, get_doc(This),
get_node_obj(node)-node)))
{
diff --git a/dlls/msxml3/main.c b/dlls/msxml3/main.c
index 464ef90..4f9b020 100644
--- a/dlls/msxml3/main.c
+++ b/dlls/msxml3/main.c
@@ -60,28 +60,47 @@ HINSTANCE MSXML_hInstance = NULL;
#ifdef HAVE_LIBXML2
-void
Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27
On Sat, Feb 11, 2012 at 03:56:43PM +, Jerome Leclanche wrote: On Sat, Feb 11, 2012 at 2:50 PM, Maarten Lankhorst m.b.lankho...@gmail.comwrote: Hey Jeremy, Op 10-02-12 20:23, Jeremy White schreef: Hi Folks, It's that time of year again - summer of code is going to start up soon. Maarten, you've been coordinating things for us for a while now - are you still game? Would you like help? Anyone else willing to volunteer to help admin the process? I'll apply wine again this year, but I want to ask everyone to help update our summer of code project wiki page. http://wiki.winehq.org/**SummerOfCodehttp://wiki.winehq.org/SummerOfCode I feel like we're not getting enough accessible projects that also have the correct length. I'm looking for something that's non-trivial but can still be done incrementally, having huge delta's to winehq has proven to not lead to meaningful contributions, and some of the projects on that list are too small, too complicated or might not be integrated into wine because it would be above a student's level get it done right. I have my doubts about these for example: - Message mode pipes - if AJ doesn't know how to do it, how can a student do it right? - Sandboxing, what's to prevent an app from simply doing syscalls in assembly, a real sandbox is not going to work - Richedit windowless mode - There's no way this can be a student project until someone does the thiscall that works both ways, this has been the biggest stumbling block to implementing it. - TestSuite - All previous attempts have failed, I believe that compiling testsuites for other projects would be a good project instead, fixing all problems that show up and don't show up on windows. Improving winetestbot to something more standardized and maintained would be nice too, but hardly a summer of code project, since it's too short. But that's just my opinion, feel free to add your own projects to that list. :-) ~Maarten The problem with GSOC projects, in my opinion, is that too many people see them as projects; the kind that needs to be finished by a deadline and have visible changes, new gui or this sort of thing. While there are interesting bits that could be done that way, having looked at a lot of bugs and their lifetime it feels to me there are areas of wine that could just use generic improvements, which are the kind that help wine the most: gradually implemented, tends to have a visible impact on bugs, many different areas to pick from, etc. The uniscribe/bidi improvements over the past few releases are a good example of a project that could have been picked up by someone familiar with/willing to familiarise themselves with the area. A GSoC really needs to be measurable somehow... Partially as psychological aspect for both student and project (to see that somehting was achieved), but also for fairness and proof if anyone would ever ask. Helping developing parts is not well measurable :/ Ciao, Marcus
Re: libgcrypt thread safety
On Wed, Feb 08, 2012 at 02:48:06PM -0600, Adam Martinson wrote: I've been looking into bug 27036 http://bugs.winehq.org/show_bug.cgi?id=27036 , and it's due to the lack of thread safety by default in libgcrypt (in this case via libgnutls in secur32.dll). To be thread safe, libgcrypt requires a call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt initialization is done. However, libgcrypt is used by a lot of different libs, one of which is being used by some other dll that's loading before secur32.dll. My question is, is it acceptable to do the gcry_control() call in ntdll's DllMain()? The alternative seems to be tracking down every lib used by wine that uses libgcrypt and doing it in each of those dlls. What's the best way to handle this? No, this would break abstraction. Why is libgcrypt needed here? It does not seem to be linked directly by any Wine component, also it seems strange that gnutls pulls it in... Can you call it on DllMain() on secur32.dll? Ciao, Marcus
Re: ntdll: Remove dead code
On Sun, Feb 05, 2012 at 03:59:44PM +0100, André Hentschel wrote:
---
dlls/ntdll/signal_x86_64.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c
index 0fc53c7..e9cefb8 100644
--- a/dlls/ntdll/signal_x86_64.c
+++ b/dlls/ntdll/signal_x86_64.c
@@ -2629,10 +2629,6 @@ static BOOL is_inside_epilog( BYTE *pc )
for (;;)
{
-BYTE rex = 0;
-
-if ((*pc 0xf0) == 0x40) rex = *pc++ 0x0f; /* rex prefix */
-
This is not OK I think.
The pc++ side effect is removed ... and is not handled in the switch() below.
Ciao, Marcus
Re: Rethinking WineConf
On Tue, Jan 17, 2012 at 04:21:47PM -0600, Vincent Povirk wrote: Well, sure. I was replying to a suggestion that we tack wineconf onto the side of, say, http://monospace.us/ by saying that I didn't think they'd be interested. Do you think they would be? Well, most of them are not very interested in Wine, but they're not hostile to it either. So it's not impossible. No harm in asking the organizers. one conference of two sets of groups that are not that interested in each others work might share the organisation burden ... but its not that useful i guess to attract more people to wineconf :/ Ciao, Marcus
Re: What other conferences do Wine people attend?
On Tue, Jan 10, 2012 at 02:55:33PM -0800, Dan Kegel wrote: In the wineconf thread, the question came up: What other conferences people do wine developers/users attend, if any? If you send me the names of the conference(s) you attended in the last two years, I'll summarize for the list. not much I go voluntary to. LinuxTag Berlin FOSDEM Brussels perhaps was at LinuxCon prague by chance only this year. Ciao, Marcus
Re: Rethinking WineConf
On Mon, Jan 09, 2012 at 12:31:11PM -0600, Jeremy White wrote: Hi All, This past Wine conference, while great fun as always, was not as well attended as Wine conferences in the past. So I would like to stir up trouble by suggesting we rethink WineConf. For those that have not attended, the Wine conference has been a mostly annual affair since 2002. It is open to all, but is advertised as being aimed at Wine developers. About 35 people attend each year. It's been in Minnesota about every 3rd year, and is otherwise 'normally' somewhere in Europe. I see the primary goal as creating human bonds between otherwise anonymous people (aka going to the pub). It's a bonus if it also spurs resolution to tricky issues, or motivates people to get more done. So I'd like to ask folks to brain storm with me. How could Wineconf be different? If you've never been, what would encourage you to come? If you've been to a technical conference recently that you thought was well done, what did they do well? Anything we could emulate? Any other ideas, or suggestions? - Users ... as this was brought up Reality check: Wine users will not travel 100s of kms to a standalone conference. This would make sense only if we attach wineconf to another general conference - Attaching to other conferences? We do not really share much with other projects (please do not bring up Samba: we don't), but perhaps attaching to general conferences... General conferences like FOSDEM (where other projects run Developer Rooms)... or LinuxCon with their specific tracks. This might be workable... but I do not think it will bring more people. - Changing the style... A talk / discussion only wineconf is not really flying anymore... we don't have that much talks. The workshop elements we introduced in the last years are however more the direction to go. So something of a workshop is my best bet at keeping interest. Question is whether we can find workshop style things besides fixing the testsuite that attract all developers? I think that will be hard. - Perhaps a shrinking audience is unavoidable. This is a bit of a fact that some projects I have been in found hard to cope with... That after the interest peak it might go down. Ciao, Marcus
Re: DIB crash with gdb
On Fri, Dec 23, 2011 at 11:56:35PM -0600, Ken Thomases wrote: On Dec 23, 2011, at 3:10 PM, Michael Ost wrote: This all makes sense, and pulls the code together for me. Thanks! You're welcome. I assume this is a recent development, because I was successfully using gdb with our last wine version - 1.1.7. Nope. This is how it has worked for a long, long time. Don't know what else has changed. Maybe some of the other work on the DIB engine has changed whether/when the DIB accesses cause access violations that you're seeing. Yes, the DIB engine should no longer let this happen with the last 1.3. releases since around September or so. Otherwise, in gdb you can type pass to pass the signal on to the program. Ciao, Marcus
Re: Regression testing breakthrough
On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote: On 19/10/11 13:43, Frédéric Delanoy wrote: On Wed, Oct 19, 2011 at 14:08, Joel Holdsworthj...@airwebreathe.org.uk wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? tar.xz would compress better tar.lzma? Having tars of all builds would be way larger I guess. GIT compresses and shares objects that are the same. Ciao, Marcus
Re: Regression testing breakthrough
On Wed, Oct 19, 2011 at 04:18:50PM +0200, Frédéric Delanoy wrote: On Wed, Oct 19, 2011 at 15:50, Marcus Meissner meiss...@suse.de wrote: On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote: On 19/10/11 13:43, Frédéric Delanoy wrote: On Wed, Oct 19, 2011 at 14:08, Joel Holdsworthj...@airwebreathe.org.uk wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? tar.xz would compress better tar.lzma? Having tars of all builds would be way larger I guess. GIT compresses and shares objects that are the same. Ciao, Marcus You're talking about using a git tree just to store binaries for each committed patch, I suppose? But then you would have to download the whole repository (which can be quite big) to get compression benefits, right? True, yes. Ciao, Marcus
Re: [Wine] WineHQ database compromise
On Thu, Oct 13, 2011 at 10:23:58AM +0200, Maarten Lankhorst wrote:
Hey,
On 10/12/2011 12:46 AM, Josh Juran wrote:
On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran j...@iswifter.net wrote:
Since bugzilla passwords were sent in cleartext anyway, I sincerely hope
none of them were otherwise valuable. (Remember FireSheep?)
Wait, what? Bugzilla sends passwords in cleartext? That isn't very
smart... Is there no way to replace this with some sort of client based
hashing or something?
To clarify, your browser sends your password to bugzilla in cleartext,
since HTTPS isn't an option.
Firesheep was a lesson that even once passwords are secure, session
credentials are still vulnerable to sniffing. Some sites went to HTTPS-only
sessions after that.
If I go to any https://*.winehq.org website I get the certificate for
test.winehq.org , otherwise you could use the firefox https anywhere to force
https on.
Or better yet, force automatic redirect to https, with
Strict-Transport-Security:
https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/
If winehq can't get more ips for every subdomain (ssl sucks), would the
solution be moving it to https://winehq.org/{bugs,appdb,test,source} ?
Or a wildcard SSL cert for *.winehq.org.
Ciao, Marcus
Re: [PATCH] ntdll: deal with images which override the section table during mapping
On Mon, Oct 10, 2011 at 11:36:33AM +0200, Bernhard Loos wrote:
---
dlls/ntdll/virtual.c | 38 ++
1 files changed, 34 insertions(+), 4 deletions(-)
I think this needs tests, the algorithms are very fragile.
Ciao, Marcus
diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c
index 5e69eb9..7841d9c 100644
--- a/dlls/ntdll/virtual.c
+++ b/dlls/ntdll/virtual.c
@@ -1114,6 +1114,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
IMAGE_DOS_HEADER *dos;
IMAGE_NT_HEADERS *nt;
IMAGE_SECTION_HEADER *sec;
+IMAGE_SECTION_HEADER *section_table = NULL;
IMAGE_DATA_DIRECTORY *imports;
NTSTATUS status = STATUS_CONFLICTING_ADDRESSES;
int i;
@@ -1123,6 +1124,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
struct file_view *view = NULL;
char *ptr, *header_end;
INT_PTR delta = 0;
+DWORD SizeOfHeaders;
/* zero-map the whole range */
@@ -1158,8 +1160,11 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
header_end = ptr + ROUND_SIZE( 0, header_size );
memset( ptr + header_size, 0, header_end - (ptr + header_size) );
if ((char *)(nt + 1) header_end) goto error;
-sec =
(IMAGE_SECTION_HEADER*)((char*)nt-OptionalHeader+nt-FileHeader.SizeOfOptionalHeader);
-if ((char *)(sec + nt-FileHeader.NumberOfSections) header_end) goto
error;
+section_table =
(IMAGE_SECTION_HEADER*)((char*)nt-OptionalHeader+nt-FileHeader.SizeOfOptionalHeader);
+/* make sure we mapped enough memory */
+if ((char *)(section_table + nt-FileHeader.NumberOfSections)
header_end) goto error;
+/* windows is only interested in the size as given by
OptionalHeader.SizeOfHeaders */
+SizeOfHeaders = ROUND_SIZE( 0, nt-OptionalHeader.SizeOfHeaders );
imports = nt-OptionalHeader.DataDirectory +
IMAGE_DIRECTORY_ENTRY_IMPORT;
if (!imports-Size || !imports-VirtualAddress) imports = NULL;
@@ -1180,7 +1185,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
if (nt-OptionalHeader.FileAlignment !=
nt-OptionalHeader.SectionAlignment) goto error;
for (i = 0; i nt-FileHeader.NumberOfSections; i++)
{
-if (sec[i].VirtualAddress != sec[i].PointerToRawData)
+if (section_table[i].VirtualAddress !=
section_table[i].PointerToRawData)
goto error; /* Windows refuses to load in that case too */
}
@@ -1192,6 +1197,24 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
goto done;
}
+if ((char *)(section_table + nt-FileHeader.NumberOfSections) ptr +
SizeOfHeaders)
+{
+/* part of the section table is outside of SizeOfHeaders
+ * at this point, it's likely that a section will get mapped over
+ * the section table (Borderlands does this)
+ * Not sure how it works on Windows, but we make a copy of the
+ * table at this point */
+ sec = RtlAllocateHeap( virtual_heap, 0, sizeof(*sec) *
nt-FileHeader.NumberOfSections);
+ if (!sec)
+ {
+ status = STATUS_NO_MEMORY;
+ goto error;
+ }
+ memcpy( sec, section_table, sizeof(*sec) *
nt-FileHeader.NumberOfSections);
+ section_table = sec;
+ }
+ else
+sec = section_table;
/* map all the sections */
@@ -1200,6 +1223,9 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
static const SIZE_T sector_align = 0x1ff;
SIZE_T map_size, file_start, file_size, end;
+if (sec-VirtualAddress SizeOfHeaders)
+goto error;
+
if (!sec-Misc.VirtualSize)
map_size = ROUND_SIZE( 0, sec-SizeOfRawData );
else
@@ -1329,7 +1355,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
VIRTUAL_SetProt( view, ptr, ROUND_SIZE( 0, header_size ),
VPROT_COMMITTED | VPROT_READ );
-sec = (IMAGE_SECTION_HEADER*)((char
*)nt-OptionalHeader+nt-FileHeader.SizeOfOptionalHeader);
+sec = section_table;
for (i = 0; i nt-FileHeader.NumberOfSections; i++, sec++)
{
SIZE_T size;
@@ -1361,6 +1387,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
}
done:
+if (section_table (char *)section_table != (char
*)nt-OptionalHeader+nt-FileHeader.SizeOfOptionalHeader)
+RtlFreeHeap( virtual_heap, 0, section_table );
view-mapping = dup_mapping;
server_leave_uninterrupted_section( csVirtual, sigset );
@@ -1373,6 +1401,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd,
char *base, SIZE_T total_siz
error:
if (view) delete_view( view );
+if (section_table (char
Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)
On Fri, Oct 07, 2011 at 11:44:24AM +0900, Dmitry Timoshkov wrote: Bernhard Loos bernhardl...@googlemail.com wrote: +int debug_childs:1; /* also debug all child processes */ 'debug_children' would be a better name. also unsigned intfoo:1; please. (int foo:1 works, but is semidefined only ;) Ciao, Marcus
Re: Problems with drawing text in 1.3.29
On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. To get a backtrace and be able to dump some datastructures, run with WINEDEBUG=+synchronous wine foo.exe This will bring it into the debugger once the condition happens. CIao, MArcus
Re: ws2_32: Patch to selectively bind to interfaces while still allowing broadcast packets (try 2)
On Tue, Oct 04, 2011 at 10:51:26AM -0600, Erich Hoover wrote:
Real Name:
Erich Hoover
Description:
I know it's been quite a while, but I'm back with another solution
for Bug #7929. This patch uses SO_BINDTODEVICE in order to bind a
socket to a specific interface while still allowing broadcast packets
(a Linux-only feature). While this feature normally requires root
privileges, it can also be enabled by giving wine-preloader the
CAP_NET_RAW capability. Should insufficient permissions be available,
the patch outputs an appropriate error message notifying the user that
broadcast packets will not function properly.
Frankly, no sane distributor will ever do this.
Ciao, Marcus
Changelog:
ws2_32: Patch to selectively bind to interfaces while still
allowing broadcast packets.
From f4c904b9b21da7664eff33be918da71795db01af Mon Sep 17 00:00:00 2001
From: Erich Hoover ehoo...@mines.edu
Date: Tue, 4 Oct 2011 10:43:06 -0600
Subject: ws2_32: Selectively bind UDP sockets to interfaces while still
allowing broadcast packets.
---
dlls/ws2_32/socket.c | 94
++
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c
index f0313fc..174ec15 100644
--- a/dlls/ws2_32/socket.c
+++ b/dlls/ws2_32/socket.c
@@ -2101,6 +2101,94 @@ static int WINAPI WS2_WSARecvMsg( SOCKET s, LPWSAMSG
msg, LPDWORD lpNumberOfByte
}
/***
+ * interface_bind (INTERNAL)
+ *
+ * Bind the given socket exclusively to a specific interface.
+ */
+static int interface_bind( int fd, struct sockaddr *addr )
+{
+struct sockaddr_in *in_sock = (struct sockaddr_in *) addr;
+PIP_ADAPTER_INFO adapters = NULL, adapter;
+unsigned int sock_type = 0, optlen;
+int ret = FALSE;
+DWORD adap_size;
+
+if (in_sock-sin_addr.s_addr == htonl(WS_INADDR_ANY))
+{
+/* Not binding to specific interface, use default route */
+goto cleanup;
+}
+optlen = sizeof(sock_type);
+if (getsockopt(fd, SOL_SOCKET, SO_TYPE, sock_type, optlen) == -1
+|| sock_type != SOCK_DGRAM)
+{
+/* Not a UDP socket, interface-specific bind is irrelevant. */
+goto cleanup;
+}
+/* Obtain the size of the IPv4 adapter list and allocate structure
memory */
+if (GetAdaptersInfo(NULL, adap_size) != ERROR_BUFFER_OVERFLOW)
+{
+ERR(Failed to get the size of the adapter list,
+bound broadcast packets will not work on this socket.\n);
+goto cleanup;
+}
+adapters = HeapAlloc(GetProcessHeap(), 0, adap_size);
+if (adapters == NULL)
+{
+ERR(Failed to allocate the adapter list,
+bound broadcast packets will not work on this socket.\n);
+goto cleanup;
+}
+/* Obtain the IPv4 adapter list */
+if (GetAdaptersInfo(adapters, adap_size) != NO_ERROR)
+{
+ERR(Failed to obtain the adapter list,
+bound broadcast packets will not work on this socket.\n);
+goto cleanup;
+}
+/* Search the IPv4 adapter list for the appropriate binding IP */
+for (adapter = adapters; adapter != NULL; adapter = adapter-Next)
+{
+char *ip = adapter-IpAddressList.IpAddress.String;
+in_addr_t adapter_addr = (in_addr_t) inet_addr(ip);
+
+if (in_sock-sin_addr.s_addr == adapter_addr)
+{
+#ifdef SO_BINDTODEVICE
+struct ifreq ifr;
+
+memset(ifr, 0, sizeof(ifr));
+lstrcpynA(ifr.ifr_name, adapter-AdapterName,
sizeof(ifr.ifr_name));
+if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, (void*)ifr,
sizeof(ifr)) == 0)
+{
+/* Success! All packets sent on this socket will go through
the
+ * specified interface. */
+TRACE(Bound to interface '%s' (corresponds to local address
%s).\n,
+ adapter-AdapterName, inet_ntoa(in_sock-sin_addr));
+ret = TRUE;
+break;
+}
+
+/* If we are unable to bind to a specific interface then notify
the
+ * user that broadcast packets will not work for this socket. The
+ * user can correct this by giving CAP_NET_RAW access to the
+ * wine-preloader binary. */
+ERR(SO_BINDTODEVICE failed (requires CAP_NET_RAW),
+broadcast packets will not work on this socket.\n);
+#else /* SO_BINDTODEVICE */
+WARN(SO_BINDTODEVICE is unsupported on this platform,
+broadcast packets will not work on this socket.\n);
+#endif /* SO_BINDTODEVICE */
+break;
+}
+}
+
+cleanup:
+HeapFree(GetProcessHeap(), 0, adapters);
+return ret;
+}
+
Re: Alexandre's keynote
On Sat, Oct 01, 2011 at 05:10:31PM -0500, Jeremy White wrote: Thanks to Jon Parshall's hard work, we have Alexandre's keynote available here: http://www.youtube.com/watch?v=2rdDvMonTnQ Remember to have your libation at hand so you can play the game... grin Thanks for doing that :) Interesting new regression by git commit overview and fortunately I just have 1 yet. ;) Ciao, Marcus
Re: winscard
On Fri, Sep 30, 2011 at 11:42:26AM +0200, Vincent Hardy wrote: Hi all, Here are four patches that are a partial but functional implementation of winscard. I installed Belgian Electronic Identity Card MiddleWare (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) I tested winscard by starting beid35gui.exe and I can see my identity card data. Moreover, this should help to solve this bug http://bugs.winehq.org/show_bug.cgi?id=26978. Are these 4 patches good enough to be sent to wine-patch ? Patch looks largely good to me. 1 comment I have on quick review below. It is probably hard to write testcases that work without hardware, but if you can think of any, they would be welcome. +State = pStates[i].dwEventState (~SCARD_STATE_CHANGED); +rgReaderStates[i].cbAtr = pStates[i].cbAtr; +memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); The MAX_ATR_SIZE size looks wrong. Should it be perhaps pStates[i].cbAtr which seems to be the bytecount? With that clarified you could already send them to wine-patches as-is. Ciao, Marcus
Re: Ole16 to Ole32 mapping
On Mon, Sep 19, 2011 at 10:00:48AM -0300, Bruno Jesus wrote: Hi, I would like some advice about Ole function redirection. The winsock16 dll maps some operations to ws2_32 dll, I thought I could do the same with Ole16disp to Oleaut32. For example the function SAFEARRAYALLOCDESCRIPTOR in Ole16disp have a similar counterpart named SafeArrayAllocDescriptor in Oleaut32. There are dozens of functions like this if you look in the spec files of these dlls. I added oleaut32 to the imports and started mapping by making one line functions, for example SAFEARRAYALLOCDESCRIPTOR simply return calling SafeArrayAllocDescriptor from Ole32. Is it ok to do it like this? I implemented SafeArrayAlloc[Descriptor/Data] and SafeArrayDestroy[Descriptor/Data] and they seem to be working, then I started implementing some of the others and testing with the application winverbs from bug #28113. Is there any msdn documentation like to these old functions? I would like to compare the function parameters in some cases. You will quite soon stumble upon the need for implementing COM interfaces in 16bit. Let me just say that this will not be pretty. Ciao, Marcus
Re: [PATCH] oleaut32: OLEPictureImpl_Load uses Seek(STREAM_SEEK_END) to find the stream length
On Thu, Sep 15, 2011 at 02:09:56PM +0200, Bernhard Loos wrote:
---
dlls/oleaut32/olepicture.c | 148
+-
dlls/oleaut32/tests/olepicture.c | 16 ++---
2 files changed, 54 insertions(+), 110 deletions(-)
Did make check work for you even? Marvin does not like it at least.
This will break NonStatable streams, also seekability of streams can
not be assumed.
Ciao, Marcus
diff --git a/dlls/oleaut32/olepicture.c b/dlls/oleaut32/olepicture.c
index 8081785..725207f 100644
--- a/dlls/oleaut32/olepicture.c
+++ b/dlls/oleaut32/olepicture.c
@@ -1324,15 +1324,13 @@ static HRESULT OLEPictureImpl_LoadAPM(OLEPictureImpl
*This,
*/
static HRESULT WINAPI OLEPictureImpl_Load(IPersistStream* iface, IStream
*pStm) {
HRESULThr;
- BOOL headerisdata;
- BOOL statfailed = FALSE;
- ULONG xread, toread;
- ULONG headerread;
+ ULONG xread, toread = 0;
BYTE *xbuf;
DWORD header[2];
WORD magic;
- STATSTG statstg;
OLEPictureImpl *This = impl_from_IPersistStream(iface);
+ ULARGE_INTEGER end, start;
+ LARGE_INTEGER offset;
TRACE((%p,%p)\n,This,pStm);
@@ -1348,104 +1346,56 @@ static HRESULT WINAPI
OLEPictureImpl_Load(IPersistStream* iface, IStream *pStm)
* At least in Visual Basic 6, resource streams, valid headers are
*header[0] == lt\0\0,
*header[1] == length_of_stream.
- *
- * Also handle streams where we do not have a working Stat method by
- * reading all data until the end of the stream.
*/
- hr = IStream_Stat(pStm,statstg,STATFLAG_NONAME);
- if (hr != S_OK) {
- TRACE(stat failed with hres %x, proceeding to read all data.\n,hr);
- statfailed = TRUE;
- /* we will read at least 8 byte ... just right below */
- statstg.cbSize.QuadPart = 8;
- }
+ offset.QuadPart = 0;
- toread = 0;
- headerread = 0;
- headerisdata = FALSE;
do {
- hr = IStream_Read(pStm, header, 8, xread);
- if (hr != S_OK || xread!=8) {
- ERR(Failure while reading picture header (hr is %x, nread is
%d).\n,hr,xread);
- return (hr?hr:E_FAIL);
- }
- headerread += xread;
- xread = 0;
-
- if (!memcmp((header[0]),lt\0\0, 4) (statfailed || (header[1] +
headerread = statstg.cbSize.QuadPart))) {
- if (toread != 0 toread != header[1])
- FIXME(varying lengths of image data (prev=%u curr=%u), only
last one will be used\n,
- toread, header[1]);
- toread = header[1];
- if (toread == 0) break;
- } else {
- if (!memcmp((header[0]), GIF8, 4) || /* GIF header */
- !memcmp((header[0]), BM, 2) || /* BMP header */
- !memcmp((header[0]), \xff\xd8, 2) || /* JPEG header */
- (header[0] == EMR_HEADER)|| /* EMF header */
- (header[1] statstg.cbSize.QuadPart)|| /* invalid size */
- (header[1]==0)
- ) {/* Found start of bitmap data */
- headerisdata = TRUE;
- if (toread == 0)
- toread = statstg.cbSize.QuadPart-8;
- else toread -= 8;
- xread = 8;
- } else {
- FIXME(Unknown stream header magic: %08x\n, header[0]);
- toread = header[1];
- }
- }
- } while (!headerisdata);
-
- if (statfailed) { /* we don't know the size ... read all we get */
- int sizeinc = 4096;
- int origsize = sizeinc;
- ULONG nread = 42;
-
- TRACE(Reading all data from stream.\n);
- xbuf = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, origsize);
- if (headerisdata)
- memcpy (xbuf, header, 8);
- while (1) {
- while (xread origsize) {
- hr = IStream_Read(pStm,xbuf+xread,origsize-xread,nread);
- xread += nread;
- if (hr != S_OK || !nread)
- break;
- }
- if (!nread || hr != S_OK) /* done, or error */
- break;
- if (xread == origsize) {
- origsize += sizeinc;
- sizeinc = 2*sizeinc; /* exponential increase */
- xbuf = HeapReAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, xbuf,
origsize);
- }
- }
- if (hr != S_OK)
- TRACE(hr in no-stat loader case is %08x\n, hr);
- TRACE(loaded %d bytes.\n, xread);
- This-datalen = xread;
- This-data= xbuf;
- } else {
- This-datalen = toread+(headerisdata?8:0);
- xbuf = This-data = HeapAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY,
This-datalen);
- if (!xbuf)
- return E_OUTOFMEMORY;
-
- if (headerisdata)
- memcpy (xbuf, header, 8);
-
- while (xread This-datalen) {
- ULONG nread;
-
Re: [3/7] dinput: Added enumerated devices to ConfigureDevices dialog
On Tue, Aug 30, 2011 at 09:11:33PM -0300, Lucas Zawacki wrote: It doesn't make sense to pass the info as WM_INITDIALG parameter if it's going to be stored in global variables anyway. A better way would be to store this in the window info. Any pointers on what's the set of winapi functions used to store and retrieve data in windows? I've searched MSDN for almost 30 minutes and no luck. SetPropA/W Also offset 0 of the window longs are usually used, like e.g. in comctl32/tooltips.c: SetWindowLongPtrW (hwnd, 0, (LONG_PTR)infoPtr); Ciao, Marcus
Re: [4/5] shlwapi/tests: Test for an unchanged buffer when cchMax=0 in StrFromTimeInterval
On Sat, Aug 06, 2011 at 06:54:48AM -0700, Scott Ritchie wrote: --- dlls/shlwapi/tests/string.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/dlls/shlwapi/tests/string.c b/dlls/shlwapi/tests/string.c index 68028d7..ecc58cc 100644 --- a/dlls/shlwapi/tests/string.c +++ b/dlls/shlwapi/tests/string.c @@ -615,6 +615,14 @@ static void test_StrFromTimeIntervalW(void) result-return_value, ret); ok(!strcmp(result-time_interval, szBuff), Formatted %d %d wrong\n, result-ms, result-digits); + +/* Test with 0 parameter, this should not change the buffer */ +MultiByteToWideChar(0,0,dontchange,-1,szBuffW,sizeof(szBuffW)); /sizeof(szBuffW[0]) missing. Ciao, Marcus
GSoC: dinput8 Action Mapping - dialog testing
On Tue, Aug 02, 2011 at 06:25:49PM -0300, Lucas Zawacki wrote: Hello. I need some help here. Before commiting the ConfigureDevices patches tried to add a couple simple tests for the function, the problem is that I now have to test a dialog. What is the best way to do it? I'm thinking of creating another thread and sending the desired messages to the dialog, is that a good option? I'm open to suggestions. This is over my head... There are some dlls that test dialogs, like dlls/comdlg32/tests but it does not seem obvious how they do it. (I unthreaded this e-mail so more people can read it ... Perhaps post new stuff in new e-mail threads for more comments.) Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Fri, Jul 29, 2011 at 05:48:43PM -0300, Lucas Zawacki wrote:
Hello!
Here's a lot of patches with a ConfigureDevices implementation. These
patches can be tested with this app I built that uses ConfigureDevices
to set up a joystick action mapping
(https://github.com/downloads/lfzawacki/dinput-samples/dolphin-plugin.exe)
. I also tested it with the Rally Trophy and Star Sonata games.
Any advice on the dialog code is appreciated, it's the first time I've
coded something like this and may have missed some things.
This implementation still lacks some things:
* Implement username property for devices
* Tracking down a bug with Rally Trophy that makes the mouse disappear
while inside the ConfigureDevices dialog.
* Implement the Sort Assigned checkbox
* Some fixes to the code
I'll let the code resting here while I keep working on this stuff.
If this is to some degree functional it can also be included already :)
One thing in 0001:
+/* Copy action names */
+for (i=0; i diafW.dwNumActions; i++)
+{
+const char* from =
lpdiCDParams-lprgFormats-rgoAction[i].u.lptszActionName;
+WCHAR *to = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*MAX_PATH);
+MultiByteToWideChar(CP_ACP, 0, from , -1, to , MAX_PATH);
+diafW.rgoAction[i].u.lptszActionName = to;
+}
The pattern to do this is usually by querying MBtoWC for the result length and
then
allocating and doing it for real (untested):
const char* from =
lpdiCDParams-lprgFormats-rgoAction[i].u.lptszActionName;
WCHAR *to;
DWORD len;
len = MultiByteToWideChar(CP_ACP, 0, from , -1, NULL , 0);
to = HeapAlloc(GetProcessHeap(),0,len*sizeof(WCHAR));
MultiByteToWideChar(CP_ACP, 0, from , -1, to, len);
diafW.rgoAction[i].u.lptszActionName = to;
+hr = IDirectInput8WImpl_ConfigureDevices(This-IDirectInput8W_iface,
lpdiCallback, diCDParamsW, dwFlags, pvRefData);
Should the action format be copied back on error?
+/* Copy back configuration */
+_copy_diactionformatWtoA(lpdiCDParams-lprgFormats, diafW);
+
+/* Free memory */
+for (i=0; i diafW.dwNumActions; i++)
+HeapFree(GetProcessHeap(), 0, (LPVOID)
diafW.rgoAction[i].u.lptszActionName);
+
+HeapFree(GetProcessHeap(), 0, diafW.rgoAction);
- FIXME((this=%p,%p,%p,%04x,%p): stub\n, This, lpdiCallback,
lpdiCDParams,
-dwFlags, pvRefData);
- return 0;
+return hr;
I also read over the dialog stuff ... I did not see anything problematic,
looked to
my untrained eyes :)
Ciao, Marcus
Re: comctl32: Remove dead increments (clang)
On Tue, Jul 26, 2011 at 09:15:57PM +0200, André Hentschel wrote:
---
dlls/comctl32/propsheet.c |1 -
dlls/comctl32/rebar.c |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/dlls/comctl32/propsheet.c b/dlls/comctl32/propsheet.c
index f711399..3dd0713 100644
--- a/dlls/comctl32/propsheet.c
+++ b/dlls/comctl32/propsheet.c
@@ -543,7 +543,6 @@ static BOOL PROPSHEET_CollectPageInfo(LPCPROPSHEETPAGEW
lppsp,
/* Extract the caption */
psInfo-proppage[index].pszText = p;
TRACE(Tab %d %s\n,index,debugstr_w( p ));
- p += lstrlenW( p ) + 1;
if (dwFlags PSP_USETITLE)
{
diff --git a/dlls/comctl32/rebar.c b/dlls/comctl32/rebar.c
index 99bde77..8d4e6f3 100644
--- a/dlls/comctl32/rebar.c
+++ b/dlls/comctl32/rebar.c
@@ -1576,8 +1576,6 @@ REBAR_SizeToHeight(REBAR_INFO *infoPtr, int height)
iRow++;
}
}
-else
-extra -= REBAR_SizeChildrenToHeight(infoPtr, first_visible(infoPtr),
infoPtr-uNumBands, extra / infoPtr-uNumRows, fChanged);
if (fChanged)
REBAR_Layout(infoPtr);
REBAR_SizeChildrenToHeight might set fChanged here, or?
Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Tue, Jul 19, 2011 at 09:40:37PM -0300, Lucas Zawacki wrote:
Hey, I've got a couple patches implementing build and setactionmap for
joysticks and I'd like you guys to give them a look.
The patches look good to my eyes.
This part:
+if ((lpdiaf-rgoAction[i].dwSemantic genre) == genre)
still looks strange (as the first genre should be a some kind
of bitmask instead of genre?), but will likely work as-is for now.
These implementations are very generic and I think I could use them
for the keyboard and the mouse too. If everything's alright with these
patches that'll be my next step.
The mapping can be tested this small app I built:
https://github.com/downloads/lfzawacki/dinput-samples/dolphin.exe
provided that you have one joystick attached (it will chose the first
one if there are more).
Works with my Joystick here at least.
Not sure what it should output, A and X button works, the
ranges go to 10/-10 expect for Down just going to -5 (might be a issue with
the joystick).
Ciao, Marcus
2011/7/5 Lucas Zawacki lfzawa...@gmail.com:
Hi guys.
Now that all the initial patches are in I have several smaller tasks
to work on as listed here
http://lfzawacki.heroku.com/wine/published/Road+Map and hopefully
they're more straightforward. I've already started working on getting
EnumDevicesBySemantics correct with joysticks and the passed flags
and, after that, BuildActionMap for the joysticks will follow. Maybe
now it's time to discuss how to implement EnumDevicesBySemantics as a
crosscall, but I really don't know how to do it (or if it's worth it)
and everywhere I look in dinput I see similar cases of this
duplication pattern.
Another thing that I've been thinking is that I might as well end up
rolling a version of ConfigureDevices
(http://msdn.microsoft.com/en-us/library/microsoft.directx_sdk.idirectinput8.idirectinput8.configuredevices%28v=VS.85%29.aspx)
because so far I've seen two of the games affected by bug 8754 use it
to configure controls. I've not had time to find and test all of them,
but if someone on the list knows about other games that use it I'd
like to be informed.
Last but not least, thanks for Wylda for testing NFSU and keeping bug
8754 informed. I actually can't run the game properly, most likely
because of the crappy intel graphics card in my laptop.
Anyway, feedback on the tasks is welcome.
---
lfz
From b492c54d5ca7179e0905f63cec183d0920555e1d Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki lfzawa...@gmail.com
Date: Tue, 19 Jul 2011 17:52:12 -0300
Subject: [PATCH 1/4] dinput: EnumDevicesBySemantics enumerating joysticks
with priority flags
Added an utility function that checks the priority of a device for a given
mapping. This can be modified later to return priority 2 mappings, if
necessary.
---
dlls/dinput/dinput_main.c | 50
1 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c
index b653307..1d59cdc 100644
--- a/dlls/dinput/dinput_main.c
+++ b/dlls/dinput/dinput_main.c
@@ -317,6 +317,38 @@ void _copy_diactionformatWtoA(LPDIACTIONFORMATA to,
LPDIACTIONFORMATW from)
}
}
+/* _diactionformat_priorityA
+ *
+ * Given a DIACTIONFORMAT structure and a DI genre, returns the enumeration
+ * priority. Joysticks should pass the game genre, and mouse or keyboard
their
+ * respective DI*_MASK
+ */
+static DWORD _diactionformat_priorityA(LPDIACTIONFORMATA lpdiaf, DWORD genre)
+{
+int i;
+DWORD priorityFlags = 0;
+
+/* If there's at least one action for the device it's priority 1 */
+for(i=0; i lpdiaf-dwActionSize; i++)
+if ((lpdiaf-rgoAction[i].dwSemantic genre) == genre)
+priorityFlags |= DIEDBS_MAPPEDPRI1;
+
+return priorityFlags;
+}
+
+static DWORD _diactionformat_priorityW(LPDIACTIONFORMATW lpdiaf, DWORD genre)
+{
+int i;
+DWORD priorityFlags = 0;
+
+/* If there's at least one action for the device it's priority 1 */
+for(i=0; i lpdiaf-dwActionSize; i++)
+if ((lpdiaf-rgoAction[i].dwSemantic genre) == genre)
+priorityFlags |= DIEDBS_MAPPEDPRI1;
+
+return priorityFlags;
+}
+
/**
* IDirectInputA_EnumDevices
*/
@@ -877,7 +909,7 @@ static HRESULT WINAPI
IDirectInput8AImpl_EnumDevicesBySemantics(
{
TRACE( - checking device %u ('%s')\n, i,
dinput_devices[i]-name);
-callbackFlags = 0;
+callbackFlags = _diactionformat_priorityA(lpdiActionFormat,
lpdiActionFormat-dwGenre);
/* Default behavior is to enumerate attached game controllers */
enumSuccess =
dinput_devices[i]-enum_deviceA(DI8DEVCLASS_GAMECTRL, DIEDFL_ATTACHEDONLY |
dwFlags, didevi, This-dwVersion, j);
if
build error in dlls/d3dx9_36/tests/math.c
Hi, I get on dlls/d3dx9_36/tests/math.c: (Code added in a6b40624dbc457ba7b0b4b307b1eb88617c67197 by Misha Koshelev misha...@gmail.com) gcc -c -I. -I. -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-stateme nt -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -DLDAP_DEPRECATED=1 -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-prot ector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o mesh.o mesh.c math.c: In function 'test_D3DXFloat_Array': math.c:2251: error: 'INFINITY' undeclared (first use in this function) math.c:2251: error: (Each undeclared identifier is reported only once math.c:2251: error: for each function it appears in.) math.c:2253: error: 'NAN' undeclared (first use in this function) make[1]: *** [math.o] Error 1 NAN and INFINITY variables are ISO C 99 features and would need #define _ISOC99_SOURCE at the beginning of the source. Would such a patch be accepted? Or perhaps add 0.0/0.0 1.0/0.0 or similar constructs? Ciao, Marcus
Re: ws2_32: Remove dead assignment (Clang)
On Wed, Jul 06, 2011 at 10:34:45AM +0200, Frédéric Delanoy wrote:
---
dlls/ws2_32/socket.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c
index 4fc65ab..91aab01 100644
--- a/dlls/ws2_32/socket.c
+++ b/dlls/ws2_32/socket.c
@@ -5874,7 +5874,7 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr
*addr, LPINT addrlen,
{
case CF_ACCEPT:
if (addr addrlen)
- addr = memcpy(addr, src_addr, (*addrlen
size) ? size : *addrlen );
+ memcpy(addr, src_addr, (*addrlen size) ? size
: *addrlen );
This is wrong. Keep the addrlen check.
Ciao, Marcus
Re: ws2_32: Remove dead assignment (Clang)
On Wed, Jul 06, 2011 at 10:57:12AM +0200, Marcus Meissner wrote:
On Wed, Jul 06, 2011 at 10:34:45AM +0200, Frédéric Delanoy wrote:
---
dlls/ws2_32/socket.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c
index 4fc65ab..91aab01 100644
--- a/dlls/ws2_32/socket.c
+++ b/dlls/ws2_32/socket.c
@@ -5874,7 +5874,7 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr
*addr, LPINT addrlen,
{
case CF_ACCEPT:
if (addr addrlen)
- addr = memcpy(addr, src_addr, (*addrlen
size) ? size : *addrlen );
+ memcpy(addr, src_addr, (*addrlen size) ?
size : *addrlen );
This is wrong. Keep the addrlen check.
Sorry, was mistaken... I thought you removed the if().
Ciao, Marcus
Re: [PATCH] advapi32: Set *lpSize properly in GetUserNameA (try2)
On Sat, Jul 02, 2011 at 11:49:44AM +0300, Alex Stanev wrote: --- dlls/advapi32/advapi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/advapi32/advapi.c b/dlls/advapi32/advapi.c index e135fa5..7025a21 100644 --- a/dlls/advapi32/advapi.c +++ b/dlls/advapi32/advapi.c @@ -65,7 +65,7 @@ GetUserNameA( LPSTR lpszName, LPDWORD lpSize ) ret = GetUserNameW( buffer, sizeW ); if (ret) -WideCharToMultiByte( CP_ACP, 0, buffer, -1, lpszName, *lpSize, NULL, NULL ); +*lpSize = WideCharToMultiByte( CP_ACP, 0, buffer, -1, lpszName, *lpSize, NULL, NULL ); else *lpSize = sizeW; For completeness, the else part also needs to convert the wide character cound in sizeW to the A character cound in *lpSize. Not sure how though. Ciao, Marcus
Re: Random crashes while running (cmd) test runner
On Sat, Jul 02, 2011 at 09:31:52PM +0200, Frédéric Delanoy wrote: Hi folks, I'm in the process of writing a couple of cmd tests (on top of master, not of my currently pending patches), and I at times have problems where none of the tests is actually performed, but the test suite still returns without any error indication, e.g. batch.c:306: running TEST_BUILTINS.CMD test... batch: 7 tests executed (0 marked as todo, 0 failures), 0 skipped. which many more tests should be performed After checking with winedbg --gdb it gets a SIGSEGV I tried to reproduce with a mimimal output file and expected file, and get weird results. Say you have the following files: test_builtins.cmd @echo off echo should fail empty line and test_builtins.cmd.exp dir empty line When I run make testclean make test in programs/cmd/tests, I get the following (first line of .exp file executed somehow...) batch.c:215: Test failed: unexpected char 0x73 position 0 in line 1 (got 'should fail', wanted 'dir') batch.c:227: Test failed: too long output, got additional Volume Serial Number is - Directory of Z:\path\to\wine\programs\cmd\tests 2/07/2011 20:56 DIR . 2/07/2011 14:34 DIR .. 2/07/2011 2:3411,074 batch.c ... batch: 14 tests executed (0 marked as todo, 2 failures), 0 skipped. If I run /wine winedbg --gdb programs/cmd/tests/cmd.exe_test.exe.so and run (c)ont, I get a SIGSEGV: Program received signal SIGSEGV, Segmentation fault. 0x7bc481f2 in HEAP_MakeInUseBlockFree (subheap=0x110014, pArena=0x1106a8) at heap.c:640 640 size += (pFree-size ARENA_SIZE_MASK) + sizeof(ARENA_FREE); If you could run this with export WINEDEBUG=+heap This should show the heap corruption way earlier, but gets a lot of debugoutput. Redirect to a file, and look for the first instancnes of corruption. Add more debugging to WINEDEBUG to see where it does fail... Ciao, Marcus
Re: Random crashes while running (cmd) test runner
On Mon, Jul 04, 2011 at 12:32:47PM +0200, Frédéric Delanoy wrote: 2011/7/4 Stefan Dösinger stefandoesin...@gmx.at: Am 04.07.2011 um 10:28 schrieb Marcus Meissner: export WINEDEBUG=+heap WINEDEBUG=warn+heap adds the corruption checking but not the debug output I get the following: batch.c:306: running TEST_BUILTINS.CMD test... batch.c:215: Test failed: unexpected char 0x73 position 0 in line 1 (got 'should fail', wanted 'dir') batch.c:227: Test failed: too long output, got additional Volume Serial Number is - (dir output) err:heap:HEAP_ValidateInUseArena Heap 0x11: block 0x11c8a0 tail overwritten at 0x11c8bc (byte 0/12 == 0x64) batch: 14 tests executed (0 marked as todo, 2 failures), 0 skipped. See http://pastebin.com/T4E63M5S for full log and heap dump The first error appears around line 328: trace:heap:RtlAllocateHeap (0x11,7062,001c): returning 0x11c898 err:heap:HEAP_ValidateInUseArena Heap 0x11: block 0x11c898 tail overwritten at 0x11c8b4 (byte 0/12 == 0x64) Heap: 0x11 Next: 0x11 Sub-heaps: 0x110014 Free lists: Block Stat SizeId It would be interesting to know what happened there in the testsuite. You could e.g. add +relay or similar. Ciao, Marcus
Re: Random crashes while running (cmd) test runner
On Mon, Jul 04, 2011 at 02:01:31PM +0200, Frédéric Delanoy wrote: On Mon, Jul 4, 2011 at 13:37, Marcus Meissner meiss...@suse.de wrote: On Mon, Jul 04, 2011 at 12:32:47PM +0200, Frédéric Delanoy wrote: 2011/7/4 Stefan Dösinger stefandoesin...@gmx.at: Am 04.07.2011 um 10:28 schrieb Marcus Meissner: export WINEDEBUG=+heap WINEDEBUG=warn+heap adds the corruption checking but not the debug output I get the following: batch.c:306: running TEST_BUILTINS.CMD test... batch.c:215: Test failed: unexpected char 0x73 position 0 in line 1 (got 'should fail', wanted 'dir') batch.c:227: Test failed: too long output, got additional Volume Serial Number is - (dir output) err:heap:HEAP_ValidateInUseArena Heap 0x11: block 0x11c8a0 tail overwritten at 0x11c8bc (byte 0/12 == 0x64) batch: 14 tests executed (0 marked as todo, 2 failures), 0 skipped. See http://pastebin.com/T4E63M5S for full log and heap dump The first error appears around line 328: trace:heap:RtlAllocateHeap (0x11,7062,001c): returning 0x11c898 err:heap:HEAP_ValidateInUseArena Heap 0x11: block 0x11c898 tail overwritten at 0x11c8b4 (byte 0/12 == 0x64) Heap: 0x11 Next: 0x11 Sub-heaps: 0x110014 Free lists: Block Stat Size Id It would be interesting to know what happened there in the testsuite. You could e.g. add +relay or similar. http://pastebin.com/6bV5BGQc 003c:Call ntdll.RtlAllocateHeap(0011,,001c) ret=7effad94 trace:heap:RtlAllocateHeap (0x11,7062,001c): returning 0x1213d8 003c:Ret ntdll.RtlAllocateHeap() retval=001213d8 ret=7effad94 003c:Call KERNEL32.TlsGetValue() ret=7effc041 003c:Ret KERNEL32.TlsGetValue() retval=00120b28 ret=7effc041 003c:Call KERNEL32.TlsGetValue() ret=7effc041 003c:Ret KERNEL32.TlsGetValue() retval=00120b28 ret=7effc041 003c:Call KERNEL32.CreateFileA(7effd262 test.cmd,4000,,,0002,0080,) ret=7effaf5a err:heap:HEAP_ValidateInUseArena Heap 0x11: block 0x1213d8 tail overwritten at 0x1213f4 (byte 0/12 == 0x64) Heap: 0x11 Next: 0x11 Sub-heaps: 0x110014 As it happens right before the test.cmd creation, it is very likely the function static const char* replace_escaped_spaces(const char *data, DWORD size, DWORD *new_size) At least the final \0 seems not to be counted during the HeapAlloc() in this function, perhaps just adding +1 in the HeapAlloc() will help. Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Thu, Jun 30, 2011 at 02:56:08AM -0300, Lucas Zawacki wrote:
Hey guys, how are you doing? I've got some patches for you.
The first is a refactoring of the BuildActionMap implementations for
keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is
pretty much correct for keyboard and mouse and it's being done the
right way.
The second patch is much like one I sent some time ago, it's
SetActionMap for keyboard and mouse, this time (hopefully) with the
dataformat stuff done right too. I've split it up in a third patch,
which implements the action mapping per se.
Anyway, tomorrow I'll code some mouse tests to be sure that this is working.
Cheers
From 37e5a1e6d51778ee0d5c0f3081dad8ca1431968f Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki lfzawa...@gmail.com
Date: Fri, 10 Jun 2011 21:43:53 -0300
Subject: dinput: Keyboard and mouse implementation of BuildActionMap (try 4)
+DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic)
+{
...
+if (!found) return 0;
So 0 is the not found case...
+DWORD obj_id = semantic_to_obj_id(This-base,
lpdiaf-rgoAction[i].dwSemantic);
+if (obj_id != -1)
But here you check for -1.
+DWORD obj_id = semantic_to_obj_id(This-base,
lpdiaf-rgoAction[i].dwSemantic);
+if (obj_id != -1)
and here. (both mouse and keyboard code)
should probably check for 0 there, also as DWORD is unsigned ;)
Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Fri, Jun 24, 2011 at 01:37:41PM -0300, Lucas Zawacki wrote: Is there any problem with the latest patches I sent? They're sitting there with the 'New' status but I have no feedback (good or bad) about them. I think there are still in the backlog. If there are not in Mondays commit round, resend them on Tuesday or so :) Ciao, Marcus
Disablin xinput2 for now?
Hi, There seem to be regressions in xinput2 support, http://bugs.winehq.org/show_bug.cgi?id=27028 As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Mon, Jun 13, 2011 at 07:17:04PM -0300, Lucas Zawacki wrote:
OK, so here is my second try at some patches. These mostly implement
keyboard action mapping and there's plenty of tests to go together
with it. I believe the keyboard part is pretty much done, as is
SetActionMap. Of course I'm ignoring the username strings and all the
device ownership part, I'll leave that for later.
As before I'll leave the patches here to get some feedback before I
try to commit.
Looks good to me. I spotted one small flaw in binary logic:
+/* This is used for the action mapping of constants such as DIKEYBOARD_SPACE
*/
+static DWORD keyboard_semantic_to_obj_id(DWORD dwSemantic)
+{
+/* dwSemantic=810004df is dwObjID=0xdf04 */
+return 0x ( (dwSemantic 8) | (dwSemantic 8) );
+}
The 8 shift will drag in bits 16-23 from dwSemantic, which is probably not
intended.
(think dwSemantic = 0x4242df04 , it will roate in the 0x42)
dwSemantic = 0x;
before the operation will help.
If no negative comments appear, please post them as 1 patch per email to
wine-patches ;)
Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Tue, Jun 14, 2011 at 02:07:32PM -0300, Lucas Zawacki wrote: Also please implement unicode method and call it from ascii. (IDirectInput8AImpl_EnumDevicesBySemantics - IDirectInput8WImpl_EnumDevicesBySemantics) Sorry if that's a stupid question, but what should I do with the string parameters? Is it ok to call a W function with the A parameters? No, it would need to converted back and forth. I think for the first committed patches having them seperate is fine, it could be factored out later, as W-A conversion for the callback handler will be tricky. Ciao, Marfcus
Re: GSoC: dinput8 Action Mapping
On Sun, Jun 12, 2011 at 10:45:38PM -0300, Lucas Zawacki wrote: I'm having some issues with test that inject input. For instance this code ( http://pastebin.com/gan0Niqj ) works as expected under wine and wine with dinput8.dll , but fails in every windows version... I tried a version with SendInput and had the same results... Anyone has some insight on this? What does keybd_event() do? I suspect that Windows might not hooking the keyboard for DirectInput usage, but attaches to some lower layer in the input stack. Ciao, Marcus
Re: cmd: ensure create_full_path returns FALSE for all errors
On Sat, Jun 04, 2011 at 04:37:05PM +0200, Frédéric Delanoy wrote:
This resolves the issue from bug #27383
---
programs/cmd/builtins.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c
index 0352e59..18e16fe 100644
--- a/programs/cmd/builtins.c
+++ b/programs/cmd/builtins.c
@@ -496,6 +496,7 @@ static BOOL create_full_path(WCHAR* path)
WCHAR *slash;
DWORD last_error = GetLastError();
if (last_error == ERROR_ALREADY_EXISTS)
+ret = FALSE;
break;
You at least miss { } here.
Ciao, Marcus
Re: GSoC: dinput8 Action Mapping
On Sun, May 29, 2011 at 07:18:03PM -0300, Lucas Zawacki wrote:
Hey guys. So last week I finally got a good understanding of dinput as
a whole and nailed some trivial cases of action mapping, the ones with
the keyboard. I'm sending a series of patches so everyone can take a
look before I try commiting them. Please note that these contain a
partial implementation of EnumDevicesBySemantics, BuildActionMap and
SetActionMap, and also they're only the A versions. There are some
tests for EnumDevicesBySemantics. I'm not too sure of how to code the
tests that require user input...
I hope it's not a nuisance to read the code split in 7 files, if you
guys want I can merge it in one big diff.
Its ok.
In general changes should be in small patches, and should
ensure for every patch in the sequence (in sequence):
- wine builds
- make test still runs
I looked over your patches and as much as I can make out, they look fine :)
Ciao, Marcus
On a bright note, this patchset results in the input working for these
two games:
* http://appdb.winehq.org/objectManager.php?sClass=applicationiId=3678
* http://appdb.winehq.org/objectManager.php?sClass=applicationiId=7919
Cheers :)
From 551a2f3bea643add493d50a5580f7c2a3c2f7566 Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki lfzawa...@gmail.com
Date: Sat, 28 May 2011 14:56:28 -0300
Subject: dinput8/tests: Organized it a little and added a test for the
EnumDevicesBySemantics callback.
---
dlls/dinput8/tests/device.c | 37 +
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/dlls/dinput8/tests/device.c b/dlls/dinput8/tests/device.c
index c18a83a..eca22a9 100644
--- a/dlls/dinput8/tests/device.c
+++ b/dlls/dinput8/tests/device.c
@@ -27,6 +27,23 @@
#include initguid.h
#include dinput.h
+/* Dummy GUID */
+static const GUID ACTION_MAPPING_GUID = { 0x1, 0x2, 0x3, { 0x4, 0x5, 0x6,
0x7, 0x8, 0x9, 0xa, 0xb } };
+
+static DIACTION actionMapping[]=
+{
+ /* axis */
+ { 0, 0x01008A01 /* DIAXIS_DRIVINGR_STEER */ , 0, { Steer } },
+ /* button */
+ { 1, 0x01000C01 /* DIBUTTON_DRIVINGR_SHIFTUP */ , 0, { Upshift } },
+ /* keyboard mapping */
+ { 2, DIKEYBOARD_SPACE , 0, { Missiles } }
+};
+
+
+/* This will set the number of devices, incrementing it
+ each time a new one is enumerated
+*/
static BOOL CALLBACK enum_by_semantics(
LPCDIDEVICEINSTANCE lpddi,
LPDIRECTINPUTDEVICE8 lpdid,
@@ -34,6 +51,10 @@ static BOOL CALLBACK enum_by_semantics(
DWORD dwRemaining,
LPVOID pvRef)
{
+
+int *ndevices = pvRef;
+if (ndevices != NULL) *ndevices += 1;
+
return DIENUM_CONTINUE;
}
@@ -44,17 +65,7 @@ static void test_action_mapping(void)
HINSTANCE hinst = GetModuleHandle(NULL);
LPDIRECTINPUT8 pDI = NULL;
DIACTIONFORMAT af;
-/* Dummy GUID */
-const GUID ACTION_MAPPING_GUID = { 0x1, 0x2, 0x3, { 0x4, 0x5, 0x6, 0x7,
0x8, 0x9, 0xa, 0xb } };
-
-DIACTION actionMapping[]=
-{
- /* axis */
- { 0, 0x01008A01 /* DIAXIS_DRIVINGR_STEER */ , 0, { Steer } },
-
- /* button */
- { 1, 0x01000C01 /* DIBUTTON_DRIVINGR_SHIFTUP */ , 0, { Upshift } }
-};
+int ndevices = 0;
hr = CoCreateInstance(CLSID_DirectInput8, 0, 1, IID_IDirectInput8A,
(LPVOID*)pDI);
if (hr == DIERR_OLDDIRECTINPUTVERSION ||
@@ -86,9 +97,10 @@ static void test_action_mapping(void)
af.dwGenre = 0x0100; /* DIVIRTUAL_DRIVING_RACE */
hr = IDirectInput8_EnumDevicesBySemantics(pDI,0, af,
-enum_by_semantics, 0, 0);
+enum_by_semantics, ndevices, 0);
ok(SUCCEEDED(hr), EnumDevicesBySemantics failed: hr=%08x\n,hr);
+todo_wine ok (ndevices 0, EnumDevicesBySemantics did not call the
callback. hr=%08x ndevices=%d\n, hr, ndevices);
/* The call fails with a zeroed GUID */
memset(af.guidActionMap, 0, sizeof(GUID));
@@ -107,3 +119,4 @@ START_TEST(device)
CoUninitialize();
}
+
--
1.7.0.4
From 1829925b178b3c2eb45fe4ea1956a226e6f91628 Mon Sep 17 00:00:00 2001
From: Lucas Fialho Zawacki lfzawa...@gmail.com
Date: Sun, 29 May 2011 16:49:45 -0300
Subject: dinput: Implement a simple version of EnumDevicesBySemanticsA which
enumerates only the keyboard.
---
dlls/dinput/dinput_main.c | 46 ++--
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c
index d3727bc..2d572bf 100644
--- a/dlls/dinput/dinput_main.c
+++ b/dlls/dinput/dinput_main.c
@@ -120,7 +120,7 @@ static struct list direct_input_list = LIST_INIT(
direct_input_list );
*/
HRESULT WINAPI DirectInputCreateEx(
HINSTANCE hinst, DWORD dwVersion, REFIID riid, LPVOID *ppDI,
- LPUNKNOWN punkOuter)
+ LPUNKNOWN punkOuter)
{
IDirectInputImpl* This;
@@ -282,7 +282,7 @@ static HRESULT WINAPI IDirectInputAImpl_EnumDevices(
Re: NTDLL doesn't compile under Clang
On Sun, May 29, 2011 at 12:43:35PM -0600, Charles Davis wrote: On 5/29/11 12:41 PM, C.W. Betts wrote: When compiling the NTDLL component of Wine, I get the following error: ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of instruction mnemonic without a size suffix __asm__(div %4,%%eax ^ inline asm:1:2: note: instantiated into assembly here div 12(%esp),%eax ^ I'm using Clang 2.0 from Xcode 4.0 That's a Clang bug that's already been fixed. Sadly, it didn't make it into Xcode 4.0. Try this patch? Ciao, Marcus Subject: [PATCH] ntdll: specify div to be divl Hi, avoids a clang build issue. Ciao, Marcus --- dlls/ntdll/large_int.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/ntdll/large_int.c b/dlls/ntdll/large_int.c index cb98bae..54ce6b0 100644 --- a/dlls/ntdll/large_int.c +++ b/dlls/ntdll/large_int.c @@ -264,7 +264,7 @@ UINT WINAPI RtlEnlargedUnsignedDivide( ULONGLONG a, UINT b, UINT *remptr ) p1 = a 32; p2 = a 0xLL; -__asm__(div %4,%%eax +__asm__(divl %4,%%eax : =a (ret), =d (rem) : 0 (p2), 1 (p1), g (b) ); if (remptr) *remptr = rem; -- 1.7.3.4
