December 2010 - Wine-Devel - list.winehq.org

Re: msctf/tests: Standardize the COM usage in inputprocessor.c.msctf/tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7584 Your paranoid android. === W7PRO (32 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:757: Test failed: Deactivation came unexpectedly === W7PROX64 (32 bit inputprocessor) === inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:515: Test failed: Sink reports wrong previous focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus inputprocessor.c:511: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:513: Test failed: Sink reports wrong focus === W7PROX64 (64 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:757: Test failed: Deactivation came unexpectedly

Dec. 14, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 6 resend)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > +#if defined(HAVE_GETATTRLIST) && defined(ATTR_VOL_CAPABILITIES) && \ > + defined(VOL_CAPABILITIES_FORMAT) && defined(VOL_CAP_FMT_CASE_SENSITIVE) > + char *mntpoint = NULL; > + struct attrlist attr; > + struct vol_caps caps; > + struct get_fsid get_fsid; > + struct fs_cache *entry; > + > + /* First get the FS ID of the volume */ > + attr.bitmapcount = ATTR_BIT_MAP_COUNT; > + attr.reserved = 0; > + attr.commonattr = ATTR_CMN_DEVID|ATTR_CMN_FSID; > + attr.volattr = attr.dirattr = attr.fileattr = attr.forkattr = 0; > + get_fsid.size = 0; > + if (getattrlist( dir, &attr, &get_fsid, sizeof(get_fsid), 0 ) != 0 || > + get_fsid.size != sizeof(get_fsid)) > + return TRUE; > + /* Try to look it up in the cache */ > + entry = look_up_fs_cache( get_fsid.dev ); > + if (entry && !memcmp( &entry->fsid, &get_fsid.fsid, sizeof(fsid_t) )) > + /* Cache lookup succeeded */ > + return entry->case_sensitive; > + /* Cache is stale at this point, we have to update it */ > + > + mntpoint = get_device_mount_point( get_fsid.dev ); > + /* Now look up the case-sensitivity */ > + attr.commonattr = 0; > + attr.volattr = ATTR_VOL_INFO|ATTR_VOL_CAPABILITIES; > + if (getattrlist( mntpoint, &attr, &caps, sizeof(caps), 0 ) == 0) > + { If that can fail then you need to structure this differently, otherwise you'll end up looking up the mount point on every call. Also please put that chunk in a separate function, it's totally different from the statfs code path. > +#elif defined(__linux__) > + /* Only assume CIOPFS is case insensitive. */ > + /* Normally, we'd have to parse the mtab to find out exactly what > + * kind of FUSE FS this is. But, someone on wine-devel suggested > + * a shortcut. We'll stat a special file in the directory. If it's > + * there, we'll assume it's a CIOPFS, else not. > + * This will break if somebody puts a file named ".ciopfs" in a non- > + * CIOPFS directory. > + */ > + cifile = RtlAllocateHeap( GetProcessHeap(), 0, strlen( dir )+sizeof("/.ciopfs") ); > + if (!cifile) return TRUE; > + strcpy( cifile, dir ); > + strcat( cifile, "/.ciopfs" ); > + if (stat( cifile, &st ) == 0) > + { > + RtlFreeHeap( GetProcessHeap(), 0, cifile ); > + return FALSE; > + } You lost the statfs here. > @@ -1872,7 +2097,7 @@ static NTSTATUS find_file_in_dir( char *unix_name, int pos, const WCHAR *name, i > { > ret = ntdll_umbstowcs( 0, de[1].d_name, strlen(de[1].d_name), > buffer, MAX_DIR_ENTRY_LEN ); > - if (ret == length && !memicmpW( buffer, name, length)) > + if (ret == length && !memicmpW( buffer, name, length )) Please avoid gratuitous whitespace changes. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2010

RFC: Pass ReadFile and WriteFile requests on sockets to ws2_32.dll

by Erich Hoover

Attached is a patch to take kernel32/ntdll ReadFile and WriteFile requests on sockets and pass them to WSARecv and WSASend. This patch is part of a series I'm working on for the infamous C&C networking bug (Bug #7929). The functionality added by this patch was requested by a previous RFC response so that ReadFile and WriteFile requests will have all the same filtering as WSARecv and WSASend. Any and all feedback is greatly appreciated. Erich Hoover ehoover(a)mines.edu

Dec. 13, 2010

Re: [2/2] amstream: Be more verbose when whe can't test

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7579 Your paranoid android. === WVISTAADM (32 bit amstream) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 13, 2010

Re: [PATCH 1/2] oleaut32: Convert ITypeInfo implementation to use standard linked list

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > Typelib objects on Windows support both the reading and the creation > interfaces. I find it unlikely that they maintain two different > structures depending on which interface is being used, as Wine > currently (sort of) does. I think the question is whether the > structures should assist reading or creation. Clearly it should be optimized for reading, that happens much more frequently. -- Alexandre Julliard julliard(a)winehq.org

Dec. 13, 2010

Re: [PATCH 1/2] oleaut32: Convert ITypeInfo implementation to use standard linked list

by Andrew Eikum

On 12/13/2010 10:03 AM, Alexandre Julliard wrote: > Andrew Eikum<aeikum(a)codeweavers.com> writes: >> An array would work, especially for the static structures that are >> used now, but these cleanup patches were made with the goal of merging >> the typelib-reading and typelib-creation interfaces in mind. >> Specifically, implementing the typelib-creation interfaces using the >> current data structures in typelib.c. Given the function >> ICreateTypeLib::CreateTypeInfo(), a list seems more appropriate to me. > > If a list is really more appropriate for creation, then they shouldn't > share the structure. The reading API is clearly index-based, a list > isn't appropriate for that. Typelib objects on Windows support both the reading and the creation interfaces. I find it unlikely that they maintain two different structures depending on which interface is being used, as Wine currently (sort of) does. I think the question is whether the structures should assist reading or creation. Would you prefer using arrays in the structures? This would obviously require reallocating space for the arrays and maintaining counts in the implementation of the creation interfaces. This seems more error-prone to me, but you have a valid point about the API being built around indexes.

Dec. 13, 2010

Re: [PATCH 1/2] oleaut32: Convert ITypeInfo implementation to use standard linked list

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > An array would work, especially for the static structures that are > used now, but these cleanup patches were made with the goal of merging > the typelib-reading and typelib-creation interfaces in mind. > Specifically, implementing the typelib-creation interfaces using the > current data structures in typelib.c. Given the function > ICreateTypeLib::CreateTypeInfo(), a list seems more appropriate to me. If a list is really more appropriate for creation, then they shouldn't share the structure. The reading API is clearly index-based, a list isn't appropriate for that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 13, 2010

Re: [PATCH 1/2] oleaut32: Convert ITypeInfo implementation to use standard linked list

by Andrew Eikum

On 12/13/2010 05:34 AM, Alexandre Julliard wrote: > Andrew Eikum<aeikum(a)codeweavers.com> writes: > >> - /* search element n in list */ >> - for(i=0; i< index; i++) >> + i = 0; >> + LIST_FOR_EACH_ENTRY (pTypeInfo,&This->typeinfo_list, ITypeInfoImpl, entry) >> + { >> + if(i>= index) >> + break; >> + ++i; >> + } > > It looks like an array would be more appropriate than a list. > An array would work, especially for the static structures that are used now, but these cleanup patches were made with the goal of merging the typelib-reading and typelib-creation interfaces in mind. Specifically, implementing the typelib-creation interfaces using the current data structures in typelib.c. Given the function ICreateTypeLib::CreateTypeInfo(), a list seems more appropriate to me.

Dec. 13, 2010

REMINDER: Removal of wineaudioio.drv

by Michael Stefaniuc

Just a reminder: If nobody speaks up wine-1.3.9 will be the last version to support audioio. On 12/08/2010 04:11 PM, Michael Stefaniuc wrote: > I have just submitted a patch to remove wineaudioio.drv from Wine. It > was used by Solaris but the Solaris versions 9 and 10 that are > "supported" by Wine do not have it any more. Solaris is using ESD at the > moment and newer version will move to OSS4. > > If anybody has a reason why wineaudioio.drv should stay in please speak > up *now*. This is your chance. Of course if you do speak up you > volunteer to maintain wineaudioio.drv ;) bye michael

Dec. 13, 2010

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 4)

by Henri Verbeet

On 12 December 2010 23:57, Chris Robinson <chris.kcat(a)gmail.com> wrote: > Though I'll defer judgement to others as to what's better. > Avoid macros unless you really need them, IMO.

Dec. 13, 2010

Re: msi: Fix testfailure on some 2k3 machines (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7572 Your paranoid android. === WVISTAADM (32 bit msi) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 13, 2010

Re: [PATCH 1/2] oleaut32: Convert ITypeInfo implementation to use standard linked list

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > - /* search element n in list */ > - for(i=0; i < index; i++) > + i = 0; > + LIST_FOR_EACH_ENTRY (pTypeInfo, &This->typeinfo_list, ITypeInfoImpl, entry) > + { > + if(i >= index) > + break; > + ++i; > + } It looks like an array would be more appropriate than a list. -- Alexandre Julliard julliard(a)winehq.org

Dec. 13, 2010

Re: msi: Fix testfailure on some 2k3 machines

by André Hentschel

Am 13.12.2010 08:42, schrieb Hans Leidekker: > On Sun, 2010-12-12 at 22:44 +0100, André Hentschel wrote: > >> r = MsiOpenProductA(prodcode, &hprod); >> - ok(r == ERROR_INSTALL_PACKAGE_OPEN_FAILED || r == ERROR_SUCCESS, >> - "Expected ERROR_INSTALL_PACKAGE_OPEN_FAILED or ERROR_SUCCESS, got %d\n", r); >> + ok(r == ERROR_INSTALL_PACKAGE_OPEN_FAILED || ERROR_INSTALL_PACKAGE_REJECTED || r == ERROR_SUCCESS, >> + "Expected ERROR_INSTALL_PACKAGE_OPEN_FAILED, ERROR_INSTALL_PACKAGE_REJECTED or ERROR_SUCCESS, got %d\n", r); > > ERROR_INSTALL_PACKAGE_REJECTED means the user has insufficient rights. > Look at how action.c handles this error, for example. > > Ah i see, thx! -- Best Regards, André Hentschel

Dec. 13, 2010

Re: msi: Fix testfailure on some 2k3 machines

by Hans Leidekker

On Sun, 2010-12-12 at 22:44 +0100, André Hentschel wrote: > r = MsiOpenProductA(prodcode, &hprod); > - ok(r == ERROR_INSTALL_PACKAGE_OPEN_FAILED || r == ERROR_SUCCESS, > - "Expected ERROR_INSTALL_PACKAGE_OPEN_FAILED or ERROR_SUCCESS, got %d\n", r); > + ok(r == ERROR_INSTALL_PACKAGE_OPEN_FAILED || ERROR_INSTALL_PACKAGE_REJECTED || r == ERROR_SUCCESS, > + "Expected ERROR_INSTALL_PACKAGE_OPEN_FAILED, ERROR_INSTALL_PACKAGE_REJECTED or ERROR_SUCCESS, got %d\n", r); ERROR_INSTALL_PACKAGE_REJECTED means the user has insufficient rights. Look at how action.c handles this error, for example.

Dec. 13, 2010

Re: [PATCH] cmd: Allow GOTO to a label, which has a following whitespace, with test

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7571 Your paranoid android. === WVISTAADM (32 bit) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 12, 2010

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 4)

by Chris Robinson

On Sunday, December 12, 2010 2:19:42 pm Louis Lenders wrote: > +#define USER_HZ_TO_TICKSPERSEC(x,y) (ULONGLONG)10000000 * x / y I'd recommend adding proper parenthesis, to avoid potential problems with order-of-operations. #define USER_HZ_TO_TICKSPERSEC(x,y) ((ULONGLONG)10000000 * (x) / (y)) That way it won't break if you do math in the argument for some reason, like with USER_HZ_TO_TICKSPERSEC(val+1, user_hz) or USER_HZ_TO_TICKSPERSEC(val, user_hz*2) > + static long user_hz; > + > + user_hz = sysconf(_SC_CLK_TCK); There's no real point to making it static if you're always going to (re)set the variable. It would be better to just make the call once: static long user_hz; i(user_hz == 0) user_hz = sysconf(_SC_CLK_TCK); You could also make it an inline function to avoid making user_hz a parameter: /* Convert system clock to 100ns tics */ static long user_hz; static inline ULONGLONG ClockToTics(ULONGLONG val) { i(user_hz == 0) user_hz = sysconf(_SC_CLK_TCK); return val * 10000000 / user_hz; } ... sppi->IdleTime.QuadPart = ClockToTics(idle); sppi->KernelTime.QuadPart = ClockToTics(sys); ...etc... Though I'll defer judgement to others as to what's better.

Dec. 12, 2010

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 4)

by Nikolay Sivov

On 12/13/2010 01:19, Louis Lenders wrote: > Change from try 3: improved macro as per Juan's suggestion, and made user_hz a static variable > > /proc/stat measures the times > in units of USER_HZ, whereas Windows uses 100ns ticks. > This should fix http://bugs.winehq.org/show_bug.cgi?id=23847 > @@ -1591,6 +1593,9 @@ NTSTATUS WINAPI NtQuerySystemInformation( > int count; > char name[10]; > char line[255]; > + static long user_hz; > + > + user_hz = sysconf(_SC_CLK_TCK); This change doesn't make any difference, I think the idea was to make it global.

Dec. 12, 2010

Re: wine's configure says "gst/gstpad.h usability... No"

by Detlef Riekenberg

On Sa, 2010-12-11 at 13:09 +0100, Paul Vriens wrote: > On 12/11/2010 08:26 AM, wylda(a)volny.cz wrote: > > Hi guys, > > > > gstreamer-0.10 development files not found, gstreamer support > > disabled > I'm on Fedora 13 and had to install gstreamer-plugins-base-devel. > > So I guess you need libgstreamer-plugins-base0.10-dev. > > Detlef has sent a patch that wasn't applied however: > > http://www.winehq.org/pipermail/wine-patches/2010-November/096133.html > I send an updated patch. http://source.winehq.org/patches/data/69363 -- By by ... Detlef

Dec. 12, 2010

Re: shdocvw: Fix testfailure on some NT4 machines

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7562 Your paranoid android. === WVISTAADM (32 bit shdocvw) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 12, 2010

Re: [PATCH 5/6] mshtml: Added IHTMLWindow2::open test.

by Jacek Caban

Hi Paul, On 12/12/10 12:30 PM, Paul Vriens wrote: > Hi Jacek, > > On 06/14/2010 02:20 AM, Jacek Caban wrote: >> --- >> dlls/mshtml/tests/htmldoc.c | 100 >> ++++++++++++++++++++++++++++++++++++++++++- >> 1 files changed, 98 insertions(+), 2 deletions(-) >> > > Some of these tests fail on IE6 SP1: > > http://test.winehq.org/data/tests/mshtml:htmldoc.html > > What would be the best approach to fix these? We can add a broken() > for the > > 3577 todo_wine > 3578 ok(new_window == NULL, "new_window != NULL\n"); > > but what about the > > 3582 todo_wine > 3583 CHECK_CALLED(EvaluateNewWindow); > > introduce a CHECK_CALLED_BROKEN also in this file? I think that win_skip mechanism will be more appropriate here, as these machines for some reason don't support INewWindowManager. At some point we will go back to implementing it and then we will need more tests that will better be skipped on those IEs. My patch proposal is currently running on winetestbot: https://testbot.winehq.org/JobDetails.pl?Key=7560 Thanks, Jacek

Dec. 12, 2010

Please ban spammer from the forum

by Rosanne DiMesio

Dan or Jeremy-- Please ban user hary from the forum. Right now he's posting spam as fast as I'm deleting it. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Dec. 12, 2010

Re: [PATCH 5/6] mshtml: Added IHTMLWindow2::open test.

by Paul Vriens

Hi Jacek, On 06/14/2010 02:20 AM, Jacek Caban wrote: > --- > dlls/mshtml/tests/htmldoc.c | 100 > ++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 98 insertions(+), 2 deletions(-) > Some of these tests fail on IE6 SP1: http://test.winehq.org/data/tests/mshtml:htmldoc.html What would be the best approach to fix these? We can add a broken() for the 3577 todo_wine 3578 ok(new_window == NULL, "new_window != NULL\n"); but what about the 3582 todo_wine 3583 CHECK_CALLED(EvaluateNewWindow); introduce a CHECK_CALLED_BROKEN also in this file? -- Cheers, Paul.

Dec. 12, 2010

Re: wine's configure says "gst/gstpad.h usability... No"

by wylda＠volny.cz

> > that Debian Squeeze says: > > > > > > gstreamer-0.10 development files not found, gstreamer support > > disabled > > > > > So I guess you need libgstreamer-plugins-base0.10-dev. > > Detlef has sent a patch that wasn't applied however: > > http://www.winehq.org/pipermail/wine-patches/2010-November/096133.html > Thanks Paul and others! "libgstreamer-plugins-base0.10-dev" was exactly that package which fixed the issue. W.

Dec. 11, 2010

Re: Wine: Use GCC's -Wlogical-op if supported.

by Gerald Pfeifer

On Tue, 21 Sep 2010, Alexandre Julliard wrote: >>> I still see a ton of warnings here (gcc 4.4.5), mostly because of the >>> glibc string macros. >> Hmm, I see. Still, this is really useful to have. How about the patch >> below as an alternative? Additional platforms can add this when/if they >> want. > This would have to be a compilation check with the appropriate headers, > not a platform check. Hmm, that's really a bit tricky given my level of autoconf skills; anyone else who might give this a try? Gerald

Dec. 11, 2010

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 3)

by Juan Lang

Hi Louis, +#define USER_HZ_TO_TICKSPERSEC(x) (ULONGLONG)10000000 * x / user_hz It's poor style to assume in a macro that user_hz exists. Pass it as a macro parameter instead. Also, this is a question rather than a suggestion for a fix: + long user_hz = sysconf(_SC_CLK_TCK); Can this value change during the lifetime of a program? I expect not, but I could be mistaken. If not, why not make it static and initialize it only once? --Juan

Dec. 11, 2010

Re: wine's configure says "gst/gstpad.h usability... No"

by Marcus Meissner

On Sat, Dec 11, 2010 at 06:46:25AM -0600, Rosanne DiMesio wrote: > On openSUSE I also had to add gstreamer-0_10-plugins-bad and gstreamer-0_10-plugins-bad-devel packages. On openSUSE I only needed to add gstreamer-0_10-plugins-base-devel Ciao, Marcus

Dec. 11, 2010

Re: wine's configure says "gst/gstpad.h usability... No"

by Rosanne DiMesio

On Sat, 11 Dec 2010 13:09:33 +0100 Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 12/11/2010 08:26 AM, wylda(a)volny.cz wrote: > > Hi guys, > > > > i'm overworked so wanted to relax a bit with wine :-D and noticed > > that Debian Squeeze says: > > > > > > gstreamer-0.10 development files not found, gstreamer support > > disabled > > > > > > but "dpkg -l | grep -i gst": > > > > ii libgstreamer-plugins-base0.10-0 0.10.30-1 > > ii libgstreamer0.10-0 0.10.30-1 > > ii libgstreamer0.10-0-dbg 0.10.30-1 > > ii libgstreamer0.10-dev 0.10.30-1 > > > > > > also "find / -iname gstpad.h": > > > > /usr/include/gstreamer-0.10/gst/gstpad.h > > > > > > Thanks for any tips to enjoy your new release. Adding config.log if > > that helps somehow. > > > > W. > > > > Hi Wylda, > > I'm on Fedora 13 and had to install gstreamer-plugins-base-devel. > > So I guess you need libgstreamer-plugins-base0.10-dev. > > Detlef has sent a patch that wasn't applied however: > > http://www.winehq.org/pipermail/wine-patches/2010-November/096133.html > > -- On openSUSE I also had to add gstreamer-0_10-plugins-bad and gstreamer-0_10-plugins-bad-devel packages. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Dec. 11, 2010

Re: wine's configure says "gst/gstpad.h usability... No"

by Paul Vriens

On 12/11/2010 08:26 AM, wylda(a)volny.cz wrote: > Hi guys, > > i'm overworked so wanted to relax a bit with wine :-D and noticed > that Debian Squeeze says: > > > gstreamer-0.10 development files not found, gstreamer support > disabled > > > but "dpkg -l | grep -i gst": > > ii libgstreamer-plugins-base0.10-0 0.10.30-1 > ii libgstreamer0.10-0 0.10.30-1 > ii libgstreamer0.10-0-dbg 0.10.30-1 > ii libgstreamer0.10-dev 0.10.30-1 > > > also "find / -iname gstpad.h": > > /usr/include/gstreamer-0.10/gst/gstpad.h > > > Thanks for any tips to enjoy your new release. Adding config.log if > that helps somehow. > > W. > Hi Wylda, I'm on Fedora 13 and had to install gstreamer-plugins-base-devel. So I guess you need libgstreamer-plugins-base0.10-dev. Detlef has sent a patch that wasn't applied however: http://www.winehq.org/pipermail/wine-patches/2010-November/096133.html -- Cheers, Paul.

Dec. 11, 2010

Re: wine-1.3.8 regression for the curses backend to wineconsole

by Eric Pouech

Le 11/12/2010 00:04, Alan W. Irwin a écrit : > > The command > > wineconsole --backend=curses cmd > > hangs with the following error message for 1.3.8: > > err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec "?" wait timed > out in thread 0065, blocked by 0000, retrying (60 sec) > > err:ntdll:RtlpWaitForCriticalSection > section 0x7ee17dec "?" wait timed out in thread 004d, blocked by 0000, > retrying (60 sec) > > There are no such issues for the default wineconsole backend, but I > have always preferred using the curses backend because cut and paste > was available for it. That backend worked fine (according to my > notes) for wine-1.1.41. > no need to open a PR for this it's already fixed in 1.3.9 A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Dec. 11, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Marcus Meissner

On Fri, Dec 10, 2010 at 02:05:08PM -0800, Scott Ritchie wrote: > On 12/10/2010 06:44 AM, Alexandre Julliard wrote: > > Marcus Meissner <meissner(a)suse.de> writes: > > > >> At least map_file will copy the stuff into a new anon mapping and so make > >> it work. quake2 at least runs fully from a "noexec" mounted USB stick. > > > > That should be considered a bug. If you mount it noexec it's because you > > don't trust the code that it may contain... > > > > Should we consider doing this for individual binary files as well? > Stock (non-PPA) Ubuntu already forces this through a front-end script, > but I shudder to think how many existing setups we might break with the > change since apps are not executable by default (unless installed by > Wine, thankfully). I don't think we should. "Download this file, chmod u+x setup.exe ; wine setup.exe" ... Does not really fly. A wrapper like above could ask for the permission I guess. CIao, Marcus

Dec. 11, 2010

wine's configure says "gst/gstpad.h usability... No"

by wylda＠volny.cz

Hi guys, i'm overworked so wanted to relax a bit with wine :-D and noticed that Debian Squeeze says: gstreamer-0.10 development files not found, gstreamer support disabled but "dpkg -l | grep -i gst": ii libgstreamer-plugins-base0.10-0 0.10.30-1 ii libgstreamer0.10-0 0.10.30-1 ii libgstreamer0.10-0-dbg 0.10.30-1 ii libgstreamer0.10-dev 0.10.30-1 also "find / -iname gstpad.h": /usr/include/gstreamer-0.10/gst/gstpad.h Thanks for any tips to enjoy your new release. Adding config.log if that helps somehow. W.

Dec. 11, 2010

Re: msi/tests: Fix some test failures on Wow64.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7542 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Dec. 10, 2010

Re: wine-1.3.8 regression for the curses backend to wineconsole

by Alan W. Irwin

On 2010-12-10 15:14-0800 Juan Lang wrote: > Hi Alan, > you should open a bug for this rather than ask here. (Also, I just > tried on Ubuntu 10.04 with Wine 1.3.9 here, and I can't confirm.) Thanks, Juan, for your reply which inspired me to build wine-1.3.9, and indeed the issue has been fixed for that version. I should have built wine-1.3.9 before saying anything here, but I thought I was safe because it's not been very long since 1.3.8 was released. Sorry for that noise. This is obviously a case where discussion here has saved a "noise" bug report on the bugtracker. Some open-source projects that I am aware of do encourage discussion of issues on the mailing lists before bug reporting to reduce bugtracker noise at the expense of some more list noise. I assumed because of the bot reports I have noticed on this list, wine also had that same culture. However, at this point, I don't know whether the above remark about not discussing bugs here is one person's opinion or the consensus culture here. I am willing to go along with whatever that consensus is. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Dec. 10, 2010

Re: [wine-devel] wine-1.3.8 regression for the curses backend to wineconsole

by Alan W. Irwin

On 2010-12-10 15:04-0800 Alan W. Irwin wrote: I should have added that the configure step for my wine-1.3.8 build used no options other than --prefix. That means I built the 32-bit version of wine-1.3.8 on my 64-bit (amd64) Intel box as confirmed by software(a)raven> file ~/wine/install/bin/wine /home/software/wine/install/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Dec. 10, 2010

Re: wine-1.3.8 regression for the curses backend to wineconsole

by Juan Lang

Hi Alan, you should open a bug for this rather than ask here. (Also, I just tried on Ubuntu 10.04 with Wine 1.3.9 here, and I can't confirm.) --Juan

Dec. 10, 2010

wine-1.3.8 regression for the curses backend to wineconsole

by Alan W. Irwin

The command wineconsole --backend=curses cmd hangs with the following error message for 1.3.8: err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec "?" wait timed out in thread 0065, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec "?" wait timed out in thread 004d, blocked by 0000, retrying (60 sec) There are no such issues for the default wineconsole backend, but I have always preferred using the curses backend because cut and paste was available for it. That backend worked fine (according to my notes) for wine-1.1.41. I built wine-1.3.8 on my Debian testing box a week ago, but saved the output of all build steps. The configure stage had the following curses-related messages: software(a)raven> grep curses configure.out checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for -lncurses... libncurses.so.5 These seem fine, and all curses-related output of the "make depend", "make", and "make install" steps seem fine as well. I am generally pretty happy with wine-1.3.8 except for this one curses backend regression. Can others confirm this issue? Is there some workaround such as using a different version of ncurses? Here are the curses-related packages I have installed at the moment on Debian testing: irwin(a)raven> dpkg --list |grep curse ii lib32ncurses5 5.7+20100313-4 shared libraries for terminal handling (32-bit) ii lib32ncurses5-dev 5.7+20100313-4 developer's libraries for ncurses (32-bit) ii libncurses5 5.7+20100313-4 shared libraries for terminal handling ii libncurses5-dev 5.7+20100313-4 developer's libraries and docs for ncurses ii libncursesw5 5.7+20100313-4 shared libraries for terminal handling (wide character support) ii ncurses-base 5.7+20100313-4 basic terminal type definitions ii ncurses-bin 5.7+20100313-4 terminal-related programs and man pages Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Dec. 10, 2010

Re: [PATCH 07/10] mshtml: Added QueryService(SID_SBindHost) implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7538 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Dec. 10, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Scott Ritchie

On 12/10/2010 06:44 AM, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > >> At least map_file will copy the stuff into a new anon mapping and so make >> it work. quake2 at least runs fully from a "noexec" mounted USB stick. > > That should be considered a bug. If you mount it noexec it's because you > don't trust the code that it may contain... > Should we consider doing this for individual binary files as well? Stock (non-PPA) Ubuntu already forces this through a front-end script, but I shudder to think how many existing setups we might break with the change since apps are not executable by default (unless installed by Wine, thankfully). Thanks, Scott Ritchie

Dec. 10, 2010

Re: winedbg --gdb shows multiple segfaults during any app startup

by Paul Chitescu

On Friday 10 December 2010 08:57:15 pm Ilya Basin wrote: > In both 1.3.8 and git winedbg --gdb or plain gdb catches several > segfaults, but if I ignore them, the program works. > > $ CC="ccache gcc" ./configure CFLAGS="-g -O0" > make > ./wine winedbg.exe --gdb notepad > > Wine-gdb> cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x7e942cf4 in create_alpha_bitmap (color=0x33c, mask=0x338, > src_info=0x1319a8, color_bits=0x7ebf411c) at cursoricon.c:664 664 > ptr[0] = ptr[0] * alpha / 255; > Wine-gdb> > Continuing. > ... > Program exited normally. > Wine-gdb> quit These faults are normal, they are part of how wine more-or-less transparently switches access to GDI bitmaps data.

Dec. 10, 2010

winedbg --gdb shows multiple segfaults during any app startup

by Ilya Basin

In both 1.3.8 and git winedbg --gdb or plain gdb catches several segfaults, but if I ignore them, the program works. $ CC="ccache gcc" ./configure CFLAGS="-g -O0" make ./wine winedbg.exe --gdb notepad Wine-gdb> cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x7e942cf4 in create_alpha_bitmap (color=0x33c, mask=0x338, src_info=0x1319a8, color_bits=0x7ebf411c) at cursoricon.c:664 664 ptr[0] = ptr[0] * alpha / 255; Wine-gdb> Continuing. ... Program exited normally. Wine-gdb> quit

Dec. 10, 2010

None

by paulo lesgaz

http://webpage.lv/page.php

Dec. 10, 2010

Re: ntdll: Change NtQuerySystemInformation to return 100ns ticks for SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION info class (try 2)

by Alexandre Julliard

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c > index 7ad56e4..d9f0398 100644 > --- a/dlls/ntdll/nt.c > +++ b/dlls/ntdll/nt.c > @@ -64,6 +64,8 @@ > #include <mach/vm_map.h> > #endif > > +#define USER_HZ_TO_TICKSPERSEC(x) (ULONGLONG)10000000 * x / sysconf(_SC_CLK_TCK) Don't hide sysconf in a macro, call it just once where needed. -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2010

Re: Cross-DLL toolbar bitmaps

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > On Fri, Dec 10, 2010 at 3:28 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Erich Hoover <ehoover(a)mines.edu> writes: >> > ... So, my thought was that it might be desirable to split apart the >> > individual icons, move them all to one centralized location, and then >> > institute a makefile rule for chaining the icons together into toolbar >> > bitmaps. Any other thoughts? Does this sound reasonable and worth >> > pursuing? >> >> Probably not. It would be fairly complex and create dependencies on >> external tools. What you can do though is load the bitmaps from >> comctl32 at run-time for things that would be duplicated. > > Wine already requires all the build tools you would need to do this in > order to build icons. It would essentially be the same procedure > except that you'd want to have a "source" toolbar bitmap file > describing the size to use and the list of icons to pull. I don't think it's worth the trouble. Copying a few bitmaps is not a big deal. -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2010

Re: Cross-DLL toolbar bitmaps

by Erich Hoover

On Fri, Dec 10, 2010 at 3:28 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Erich Hoover <ehoover(a)mines.edu> writes: > > ... So, my thought was that it might be desirable to split apart the > > individual icons, move them all to one centralized location, and then > > institute a makefile rule for chaining the icons together into toolbar > > bitmaps. Any other thoughts? Does this sound reasonable and worth > > pursuing? > > Probably not. It would be fairly complex and create dependencies on > external tools. What you can do though is load the bitmaps from > comctl32 at run-time for things that would be duplicated. Wine already requires all the build tools you would need to do this in order to build icons. It would essentially be the same procedure except that you'd want to have a "source" toolbar bitmap file describing the size to use and the list of icons to pull. Once you pull out the correct size from each icon then you just feed that list to ImageMagick: http://www.imagemagick.org/Usage/layers/#append I'm aware that some of these bitmaps are available through comctl32, but hhctrl.ocx shares a bunch of icons with IE (home, stop, refresh, etc.). I imagine you would not approve of adding custom image lists to comctl32 for handling the icons that overlap between IE and hhctrl.ocx. Erich Hoover ehoover(a)mines.edu

Dec. 10, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > At least map_file will copy the stuff into a new anon mapping and so make > it work. quake2 at least runs fully from a "noexec" mounted USB stick. That should be considered a bug. If you mount it noexec it's because you don't trust the code that it may contain... > Anyway, what kind of warning would you suggest? A FIXME? No it's not a FIXME, there's nothing to fix. Just an ERR, we already have one for this. -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Marcus Meissner

On Fri, Dec 10, 2010 at 03:08:26PM +0100, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > The issue is that it worked before my last patch and still works. > > > > Or should we take care of not executing stuff from "noexec" filesystems > > as kind of policy rule? > > Yes. On systems that enforce this correctly, if you ignore the error at > that point you'll then get a mysterious crash when the app actually > tries to execute code. I guess my x86_64 system does ... At least map_file will copy the stuff into a new anon mapping and so make it work. quake2 at least runs fully from a "noexec" mounted USB stick. Anyway, what kind of warning would you suggest? A FIXME? Ciao, Marcus

Dec. 10, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > The issue is that it worked before my last patch and still works. > > Or should we take care of not executing stuff from "noexec" filesystems > as kind of policy rule? Yes. On systems that enforce this correctly, if you ignore the error at that point you'll then get a mysterious crash when the app actually tries to execute code. -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Marcus Meissner

On Fri, Dec 10, 2010 at 02:01:18PM +0100, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > Hi, > > > > regression from my previous patch, which forced EXEC permissions on > > some mappings, which in turn gets EPERM when the filesystem is > > "noexec" mounted. > > I don't think that's a good idea. If the filesystem is no exec we should > report it and fail. The issue is that it worked before my last patch and still works. Or should we take care of not executing stuff from "noexec" filesystems as kind of policy rule? Ciao, Marcus

Dec. 10, 2010

Re: [PATCH] ntdll: Handle executable file mappings from noexec filesystems

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > Hi, > > regression from my previous patch, which forced EXEC permissions on > some mappings, which in turn gets EPERM when the filesystem is > "noexec" mounted. I don't think that's a good idea. If the filesystem is no exec we should report it and fail. -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2010

Re: Cross-DLL toolbar bitmaps

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > I was looking into adding better bitmaps for the toolbar controls in > hhctrl.ocx (now that we have fancy alpha transparency support) and I wanted > to make sure that the bitmaps used matched everywhere else in Wine. Looking > into how this works currently, I noticed that keeping all the toolbar > bitmaps in sync is currently done manually. For example, > dlls/shell32/idb_tb_large.bmp uses older icons for backward and forward > where dlls/shdocvw/ietoolbar.bmp and dlls/comctl32/idb_std_large.bmp use the > new icons. So, my thought was that it might be desirable to split apart the > individual icons, move them all to one centralized location, and then > institute a makefile rule for chaining the icons together into toolbar > bitmaps. Any other thoughts? Does this sound reasonable and worth > pursuing? Probably not. It would be fairly complex and create dependencies on external tools. What you can do though is load the bitmaps from comctl32 at run-time for things that would be duplicated. -- Alexandre Julliard julliard(a)winehq.org

Dec. 10, 2010

Re: 64-bit down to 11 failures !!

by Austin English

On Thu, Dec 9, 2010 at 10:25 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 12/10/2010 05:11, Austin English wrote: >> >> msxml:domdoc - >> http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_a… > > I see a crash in eglibc in another log. Is it a same failure for you? ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c && touch domdoc.ok fixme:urlmon:InternetBindInfo_GetBindString not supported string type 12 fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! err:msxml:doparse Document is empty wine: Unhandled page fault on read access to 0x00000a64 at address 0x2b15a742a7aa (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000a64 in 64-bit code (0x00002b15a742a7aa). Register dump: rip:00002b15a742a7aa rsp:00002b15a98beb60 rbp:00002b15a98bf1f0 eflags:00010286 ( R- -- I S - -P- ) rax:0000000000000000 rbx:00002b15a98bf200 rcx:ffffffffffffffff rdx:0000000000000020 rsi:00002b15adf918c7 rdi:0000000000000a64 r8:0000000000000000 r9:0000000000000a64 r10:0000000000000000 r11:0000000000000000 r12:0000000000000000 r13:00002b15a98bf3d8 r14:00002b15adf918c8 r15:ffffffffffffffa8 Stack dump: 0x00002b15a98beb60: 0000000000000000 00002b15adf918c9 0x00002b15a98beb70: 00002b15adf918c9 a98befe800000000 0x00002b15a98beb80: 0000000000000000 00002b15a71d1b99 0x00002b15a98beb90: 00002b15a98bf0e0 00002b15a79ea8f5 0x00002b15a98beba0: 00002b15a98bf188 00002b15a98bf168 0x00002b15a98bebb0: 00002b15adf918c7 00002b15a98bf14c 0x00002b15a98bebc0: 0000000000000000 0000000000000000 0x00002b15a98bebd0: 0000000000000000 00002b1500000000 0x00002b15a98bebe0: 00002b15a98becd0 00002b1500000016 0x00002b15a98bebf0: 00002b15a98bf0b8 0000000b00000000 0x00002b15a98bec00: 00002b15a98bf140 000006ce00000000 0x00002b15a98bec10: 0000000000000000 ffffffffffffffff Backtrace: 0x00002b15a742a7aa: repne scasb (%rsi) Modules: Module Address Debug info Name (75 modules) ELF 7b800000- 7bbb0000 Deferred kernel32<elf> \-PE 7b820000- 7bbb0000 \ kernel32 ELF 7be00000- 7c102000 Deferred <wine-loader> ELF 2b15a6c4a000- 2b15a6e6d000 Deferred ld-linux-x86-64.so.2 ELF 2b15a6e6d000- 2b15a719d000 Deferred libwine.so.1 ELF 2b15a71c3000- 2b15a73e0000 Deferred libpthread.so.0 ELF 2b15a7764000- 2b15a7968000 Deferred libdl.so.2 ELF 2b15a796a000- 2b15a7c55000 Deferred ntdll<elf> \-PE 2b15a7980000- 2b15a7c55000 \ ntdll ELF 2b15a7c7b000- 2b15a7efe000 Deferred libm.so.6 ELF 2b15a7efe000- 2b15a8114000 Deferred libgcc_s.so.1 ELF 2b15a8542000- 2b15a874b000 Deferred libnss_compat.so.2 ELF 2b15a874b000- 2b15a8965000 Deferred libnsl.so.1 ELF 2b15a8965000- 2b15a8b70000 Deferred libnss_nis.so.2 ELF 2b15a8b70000- 2b15a8d7d000 Deferred libnss_files.so.2 ELF 2b15a9554000- 2b15a97bd000 Deferred msxml3_test<elf> \-PE 2b15a9560000- 2b15a97bd000 \ msxml3_test ELF 2b15a98c0000- 2b15a9c01000 Deferred oleaut32<elf> \-PE 2b15a98e0000- 2b15a9c01000 \ oleaut32 ELF 2b15a9c01000- 2b15a9f7a000 Deferred ole32<elf> \-PE 2b15a9c30000- 2b15a9f7a000 \ ole32 ELF 2b15a9f7a000- 2b15aa1f4000 Deferred advapi32<elf> \-PE 2b15a9f90000- 2b15aa1f4000 \ advapi32 ELF 2b15aa1f4000- 2b15aa586000 Deferred user32<elf> \-PE 2b15aa210000- 2b15aa586000 \ user32 ELF 2b15aa586000- 2b15aa84a000 Deferred gdi32<elf> \-PE 2b15aa5a0000- 2b15aa84a000 \ gdi32 ELF 2b15aa84a000- 2b15aaa63000 Deferred version<elf> \-PE 2b15aa850000- 2b15aaa63000 \ version ELF 2b15aaa63000- 2b15aacf4000 Deferred rpcrt4<elf> \-PE 2b15aaa70000- 2b15aacf4000 \ rpcrt4 ELF 2b15aad1a000- 2b15aafa1000 Deferred libfreetype.so.6 ELF 2b15aafa1000- 2b15ab1b9000 Deferred libz.so.1 ELF 2b15ab1df000- 2b15ab414000 Deferred libfontconfig.so.1 ELF 2b15ab414000- 2b15ab63d000 Deferred libexpat.so.1 ELF 2b15ab6ce000- 2b15ab990000 Deferred winex11<elf> \-PE 2b15ab6e0000- 2b15ab990000 \ winex11 ELF 2b15ab9b6000- 2b15abbbf000 Deferred libsm.so.6 ELF 2b15abbbf000- 2b15abdda000 Deferred libice.so.6 ELF 2b15abdda000- 2b15abfec000 Deferred libxext.so.6 ELF 2b15abfec000- 2b15ac322000 Deferred libx11.so.6 ELF 2b15ac322000- 2b15ac527000 Deferred libuuid.so.1 ELF 2b15ac527000- 2b15ac744000 Deferred libxcb.so.1 ELF 2b15ac744000- 2b15ac947000 Deferred libxau.so.6 ELF 2b15ac947000- 2b15acb4d000 Deferred libxdmcp.so.6 ELF 2b15acb4d000- 2b15acd73000 Deferred imm32<elf> \-PE 2b15acb50000- 2b15acd73000 \ imm32 ELF 2b15acd73000- 2b15acf76000 Deferred libxinerama.so.1 ELF 2b15acf76000- 2b15ad17c000 Deferred libxxf86vm.so.1 ELF 2b15ad17c000- 2b15ad386000 Deferred libxrender.so.1 ELF 2b15ad386000- 2b15ad58f000 Deferred libxrandr.so.2 ELF 2b15ad58f000- 2b15ad792000 Deferred libxcomposite.so.1 ELF 2b15ad792000- 2b15ad998000 Deferred libxfixes.so.3 ELF 2b15ad998000- 2b15adba2000 Deferred libxcursor.so.1 ELF 2b15adba2000- 2b15ade56000 Deferred msxml3<elf> \-PE 2b15adbb0000- 2b15ade56000 \ msxml3 ELF 2b15ade7c000- 2b15ae1ca000 Deferred libxml2.so.2 ELF 2b15ae1ca000- 2b15ae45f000 Deferred urlmon<elf> \-PE 2b15ae1e0000- 2b15ae45f000 \ urlmon ELF 2b15ae45f000- 2b15ae892000 Deferred shell32<elf> \-PE 2b15ae480000- 2b15ae892000 \ shell32 ELF 2b15ae892000- 2b15aeb1f000 Deferred shlwapi<elf> \-PE 2b15ae8a0000- 2b15aeb1f000 \ shlwapi ELF 2b15aeb1f000- 2b15aee19000 Deferred comctl32<elf> \-PE 2b15aeb30000- 2b15aee19000 \ comctl32 ELF 2b15aee19000- 2b15af089000 Deferred wininet<elf> \-PE 2b15aee30000- 2b15af089000 \ wininet ELF 2b15af089000- 2b15af2b2000 Deferred mpr<elf> \-PE 2b15af090000- 2b15af2b2000 \ mpr ELF 2b15af2b2000- 2b15af4eb000 Deferred uxtheme<elf> \-PE 2b15af2c0000- 2b15af4eb000 \ uxtheme ELF 2b15af5ce000- 2b15af808000 Deferred libxslt.so.1 ELF 2b15af936000- 2b15afb39000 Deferred libnss_mdns4_minimal.so.2 ELF 2b15afb39000- 2b15afd3f000 Deferred libnss_dns.so.2 ELF 2b15afd3f000- 2b15aff58000 Deferred libresolv.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\home\austin\64-wine-git\dlls\msxml3\tests\msxml3_test.exe 0000001c 0 0000001b 0 00000009 0 <== 0000000e services.exe 00000017 0 00000015 0 00000014 0 00000010 0 0000000f 0 00000011 winedevice.exe 00000018 0 00000016 0 00000013 0 00000012 0 00000019 explorer.exe 0000001a 0 Backtrace: err:seh:call_stack_handlers invalid frame 2b15a98c10c0 (0x2b15a97c2000-0x2b15a98c0000) err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception. wine client error:9: write: Bad file descriptor err:seh:call_stack_handlers invalid frame 2b15a98c10c0 (0x2b15a97c2000-0x2b15a98c0000) err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception. wine client error:9: write: Bad file descriptor make: *** [domdoc.ok] Error 1 -- -Austin

Dec. 10, 2010

Re: 64-bit down to 11 failures !!

by Nikolay Sivov

On 12/10/2010 05:11, Austin English wrote: > msxml:domdoc - http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_a… I see a crash in eglibc in another log. Is it a same failure for you?

Dec. 10, 2010

64-bit down to 11 failures !!

by Austin English

Dec. 9, 2010

Re: riched20/tests: Mark behaviour at 120 dpi as broken

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7522 Your paranoid android. === W7PROX64 (32 bit editor) === editor.c:4702: Test failed: test paste: strcmp = 1, text='testing paste editor.c:4720: Test failed: test paste: strcmp = 1 editor.c:4732: Test failed: test paste: strcmp = -1 editor.c:4762: Test failed: test paste: strcmp = -1, actual = 'Ts' editor.c:5977: Test failed: Cursor is at 0 instead of 4 editor.c:5983: Test failed: Cursor is at 0 instead of 9 editor.c:5989: Test failed: Cursor is at 0 instead of 4 editor.c:6003: Test failed: Cursor is at 8 instead of 9 editor.c:6011: Test failed: Cursor is at 11 instead of 9 editor.c:6022: Test failed: Cursor is at 0 instead of 8 editor.c:6047: Test failed: Cursor is at 0 instead of 8 === W7PROX64 (64 bit editor) === editor.c:4702: Test failed: test paste: strcmp = 1, text='testing paste editor.c:4720: Test failed: test paste: strcmp = 1 editor.c:4732: Test failed: test paste: strcmp = -1 editor.c:4762: Test failed: test paste: strcmp = -1, actual = 'Ts' editor.c:5977: Test failed: Cursor is at 0 instead of 4 editor.c:5983: Test failed: Cursor is at 0 instead of 9 editor.c:5989: Test failed: Cursor is at 0 instead of 4 editor.c:6003: Test failed: Cursor is at 8 instead of 9 editor.c:6011: Test failed: Cursor is at 11 instead of 9 editor.c:6022: Test failed: Cursor is at 0 instead of 8 editor.c:6047: Test failed: Cursor is at 0 instead of 8

Dec. 9, 2010

Cross-DLL toolbar bitmaps

by Erich Hoover

I was looking into adding better bitmaps for the toolbar controls in hhctrl.ocx (now that we have fancy alpha transparency support) and I wanted to make sure that the bitmaps used matched everywhere else in Wine. Looking into how this works currently, I noticed that keeping all the toolbar bitmaps in sync is currently done manually. For example, dlls/shell32/idb_tb_large.bmp uses older icons for backward and forward where dlls/shdocvw/ietoolbar.bmp and dlls/comctl32/idb_std_large.bmp use the new icons. So, my thought was that it might be desirable to split apart the individual icons, move them all to one centralized location, and then institute a makefile rule for chaining the icons together into toolbar bitmaps. Any other thoughts? Does this sound reasonable and worth pursuing? Erich Hoover ehoover(a)mines.edu

Dec. 9, 2010

Re: riched20/tests: Mark behaviour at 120 dpi as broken

by James Mckenzie

Andre: My computer is set up for 125 dpi (Large Fonts on WindowsXP). Should we be testing for this as well? This should give different results than what is stated here. Maybe there is a better way to test this than using a fixed value of 39 in the ok comparision. James McKenzie -----Original Message----- >From: André Hentschel <nerv(a)dawncrow.de> >Sent: Dec 9, 2010 11:38 AM >To: wine-patches <wine-patches(a)winehq.org> >Subject: riched20/tests: Mark behaviour at 120 dpi as broken > >comparison to 96 dpi can be found at http://test.winehq.org/data/23906816d87795c363f0199f33ff70f2732c6ab5/index_… >--- > dlls/riched20/tests/editor.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > >diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c >index efd2023..5321d07 100644 >--- a/dlls/riched20/tests/editor.c >+++ b/dlls/riched20/tests/editor.c >@@ -6082,7 +6082,9 @@ static void test_EM_CHARFROMPOS(void) > point.x = 1000; > point.y = 40; > result = SendMessage(hwnd, EM_CHARFROMPOS, 0, (LPARAM)&point); >- todo_wine ok(result == 39, "expected character index of 39 but got %d\n", result); >+ todo_wine ok(result == 39, >+ broken(result == 34) /* 120 dpi */, >+ "expected character index of 39 but got %d\n", result); > > point.x = 1000; > point.y = -1; >-- > >Best Regards, André Hentschel > >

Dec. 9, 2010

Re: Trace/breakpoint trap using VS2008 remote debugger

by Joe Dluzen

The remote debugger is on Mint 9 32 under WINE1.2 in a virtual machine. VS2008 is on the host PC, Win7 64. The only command line output is that "Trace/breakpoint trap" line, and then the program exits. I've filed a bug here: http://bugs.winehq.org/show_bug.cgi?id=25462 and a HowTo here: http://wiki.winehq.org/VisualStudioDebugging 2010/12/9 André Hentschel <nerv(a)dawncrow.de>: > Am 07.12.2010 22:23, schrieb Joe Dluzen: >> Hi all, >> >> I've got the Visual Studio Remote Debugger working with breakpoints, >> but not with forcing the process to pause. It immediately exits with >> "Trace/breakpoint trap." I've tried looking up the error, but it seems >> that no one has this specific set of circumstances. Any ideas? >> >> Thanks, >> Joe >> >> > > I guess you get no response because people don't know what you are talking about. > Maybe you are on the wrong Mailinglist? > In which direction do you use the remote debugger, from inside Wine to some windowsmachine? > Any commandline output? > > -- > > Best Regards, André Hentschel

Dec. 9, 2010

Re: Trace/breakpoint trap using VS2008 remote debugger

by André Hentschel

Am 07.12.2010 22:23, schrieb Joe Dluzen: > Hi all, > > I've got the Visual Studio Remote Debugger working with breakpoints, > but not with forcing the process to pause. It immediately exits with > "Trace/breakpoint trap." I've tried looking up the error, but it seems > that no one has this specific set of circumstances. Any ideas? > > Thanks, > Joe > > I guess you get no response because people don't know what you are talking about. Maybe you are on the wrong Mailinglist? In which direction do you use the remote debugger, from inside Wine to some windowsmachine? Any commandline output? -- Best Regards, André Hentschel

Dec. 9, 2010

Re: [1/2] msi: Don't try to install or remove ODBC drivers if the component is disabled.

by Hans Leidekker

On Thu, 2010-12-09 at 07:52 -0800, Joris Huizer wrote: > I noticed in this patch, exactly the same lines are added in all the > functions; wouldn't it be better to add a(n) (inline) function > isComponentEnabled(rec,package) to reduce the repetition? I'm not opposed to consolidating the check in a function, but note that there's a trace in there that reveals the action being run (through the function name), and this information should not get lost.

Dec. 9, 2010

Re: [1/2] winetest: Add a trace in the log when skipping a subtest.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > I'm not happy with the situation when we skip a whole test executable. > One issue is that in such a case we don't even extract the executable > right now, thus making it impossible to print the subtest name. So we'd > need a different skip line format for that case. Or we could decide to > extract all the files and query their subtest names anyway and only > disable actually running the tests. The problem with this is that one of the reasons for skipping a test is that loading the test binary crashes the system, so loading it to get the subtest names wouldn't help. -- Alexandre Julliard julliard(a)winehq.org

Dec. 9, 2010

Re: [1/2] msi: Don't try to install or remove ODBC drivers if the component is disabled.

by Joris Huizer

Hello, I noticed in this patch, exactly the same lines are added in all the functions; wouldn't it be better to add a(n) (inline) function isComponentEnabled(rec,package) to reduce the repetition? HTH, Joris

Dec. 9, 2010

Re: [PATCH 5/5] mshtml: Added GUID_CUSTOM_CONFIRMOBJECTSAFETY with CONFIRMSAFETYACTION_LOADOBJECT flag tests

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7515 Your paranoid android. === WXPPROSP3 (32 bit script) === script.c:1462: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1393: Test failed: policy = 0, expected 3 script.c:1407: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1407: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1407: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1586: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1587: Test failed: policy = 0, expected 3 === WVISTAADM (32 bit script) === script.c:1462: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1393: Test failed: policy = 0, expected 3 script.c:1407: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1407: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1407: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1586: Test failed: expected AXSetInterfaceSafetyOptions_IDispatch_data script.c:1587: Test failed: policy = 0, expected 3

Dec. 9, 2010

Re: [2/2] ntdll: Implement missing 64 bit shifts (try 2)

by Alexandre Julliard

Mike Gibson <mike.gibson(a)storagecraft.com> writes: > @@ -144,8 +144,23 @@ LONGLONG WINAPI RtlLargeIntegerShiftRight( LONGLONG a, INT count ) > */ > LONGLONG WINAPI RtlLargeIntegerArithmeticShift( LONGLONG a, INT count ) > { > - /* FIXME: gcc does arithmetic shift here, but it may not be true on all platforms */ > - return a >> count; > +#ifdef HAVE_SIMPLE_ARITHMETIC_RIGHT_SHIFT > + return a >> count; > +#else > + /* create mask to extend the sign bit */ > + LONGLONG mask; > + mask = ( LONGLONG ) 1 << 63; > + mask &= a; > + mask >>= count; That's an arithmetic shift, you are only moving the problem. Also your calling convention for the _allsh* functions isn't correct, as a simple test case demonstrates. Do you really have an app that uses this? -- Alexandre Julliard julliard(a)winehq.org

Dec. 9, 2010

Re: dsound: Standardize the COM usage in duplex.c.

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > --- > dlls/dsound/duplex.c | 86 ++++++++++++++++++++++++++++++------------------- > 1 files changed, 53 insertions(+), 33 deletions(-) > > diff --git a/dlls/dsound/duplex.c b/dlls/dsound/duplex.c > index 4a1fbd2..2fcf64c 100644 > --- a/dlls/dsound/duplex.c > +++ b/dlls/dsound/duplex.c > @@ -44,7 +44,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(dsound); > typedef struct IDirectSoundFullDuplexImpl > { > /* IUnknown fields */ > - const IDirectSoundFullDuplexVtbl *lpVtbl; > + IDirectSoundFullDuplex IDirectSoundFullDuplex_iface; > LONG ref; > > /* IDirectSoundFullDuplexImpl fields */ > @@ -57,23 +57,43 @@ typedef struct IDirectSoundFullDuplexImpl > } IDirectSoundFullDuplexImpl; > > typedef struct IDirectSoundFullDuplex_IUnknown { > - const IUnknownVtbl *lpVtbl; > + IUnknown IUnknown_iface; > LONG ref; > IDirectSoundFullDuplexImpl *pdsfd; > } IDirectSoundFullDuplex_IUnknown; > > typedef struct IDirectSoundFullDuplex_IDirectSound8 { > - const IDirectSound8Vtbl *lpVtbl; > + IDirectSound8 IDirectSound8_iface; > LONG ref; > IDirectSoundFullDuplexImpl *pdsfd; > } IDirectSoundFullDuplex_IDirectSound8; > > typedef struct IDirectSoundFullDuplex_IDirectSoundCapture { > - const IDirectSoundCaptureVtbl *lpVtbl; > + IDirectSoundCapture IDirectSoundCapture_iface; > LONG ref; > IDirectSoundFullDuplexImpl *pdsfd; > } IDirectSoundFullDuplex_IDirectSoundCapture; All these objects are redundant, they should be merged. -- Alexandre Julliard julliard(a)winehq.org

Dec. 9, 2010

Re: Outlook-friendly stub for CreatePrivateObjectSecurity

by James Mckenzie

Nick Sukharev <nicksukharev(a)gmail.com> wrote: > >Tab characters fixed. You need to resubmit as [Try 2] if you make a correction in the future in a new message, please. James McKenzie

Dec. 8, 2010

Removal of wineaudioio.drv

by Michael Stefaniuc

Hello guys, I have just submitted a patch to remove wineaudioio.drv from Wine. It was used by Solaris but the Solaris versions 9 and 10 that are "supported" by Wine do not have it any more. Solaris is using ESD at the moment and newer version will move to OSS4. If anybody has a reason why wineaudioio.drv should stay in please speak up *now*. This is your chance. Of course if you do speak up you volunteer to maintain wineaudioio.drv ;) bye michael

Dec. 8, 2010

Re: Outlook-friendly stub for CreatePrivateObjectSecurity

by Dmitry Timoshkov

Nick Sukharev <nicksukharev(a)gmail.com> wrote: > + if (!InitializeSecurityDescriptor(*NewDescriptor, SECURITY_DESCRIPTOR_REVISION)) { > + HeapFree(GetProcessHeap(), 0, *NewDescriptor); > + return FALSE; > + } You are mixing tabs and spaces. -- Dmitry.

Dec. 8, 2010

CreatePrivateObjectSecurity implementation

by Nick Sukharev

I found that stub implementation for CreatePrivateObjectSecurity / DestroyPrivateObjectSecurity prevents Microsoft Exchange client from working properly. After changing these stubs to return an empty security descriptor and destroy it Exchange works much better. It can now read mail and calendar. I'm looking for suggestions what minimal implementation for these functions would be acceptable as a patch. Thank you PS. Sorry for double-post. It looks like I shouldn't be using nabble to post to wine-devel

Dec. 7, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by James McKenzie

On 12/6/10 1:41 PM, Juan Lang wrote: >> Hey ! I said I didn't want to be rude and that's still true >> >> RTFM is a kind of philosophy > It's very hard to make RTFM not seem rude. Anything with the F word > in it is, in my opinion, best left off this list. +1, Juan. Spell it out, Read the Fine Manual is what was intended, but could be misunderstood as a really rude comment. I prefer directing folks to the document, be it a web page (Google is your Friend), manual or a manpage... James McKenzie

Dec. 7, 2010

Re: ntdll: Implement missing 64 bit shifts

by Erich Hoover

On Tue, Dec 7, 2010 at 10:51 AM, Mike Gibson <mike.gibson(a)storagecraft.com> wrote: > ... > The vast majority of platforms seem to do arithmetic right shift. It would be better to have a #define that indicates what the right shifting behavior is. Only on those platforms where right shift isn't arithmetic would the slower code be used. > > AFAIK, this sort of thing is determined in the configure step. I can write a test for it, but I have a suspicion someone may have already done this. Anyone know? If not, I would appreciate some pointers (or links) on how to go about adding such a test. You should be able to test this behavior with AC_COMPILE_IFELSE: ---- dnl **** Check for arithmetic right shifting **** AC_CACHE_CHECK([whether the right shift operator is an arithmetic right shift], wine_cv_arithmetic_right_shift, AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#if ((-4 >> 1) != -2) #error "No simple arithmetic right shift" #endif]], [[]])], [wine_cv_arithmetic_right_shift=yes], [wine_cv_arithmetic_right_shift=no])) if test "$wine_cv_arithmetic_right_shift" = "yes" then AC_DEFINE(HAVE_SIMPLE_ARITHMETIC_RIGHT_SHIFT,1,[Define if the right shift operator is an arithmetic shift]) fi ---- Throw the above in configure.ac and test with "autoconf && autoheader && ./configure". Erich Hoover ehoover(a)mines.edu

Dec. 7, 2010

winetricks dotnet30 install seems to be working again

by Dan Kegel

For me, with today's winetricks from svn and wine from git, winetricks dotnet30 seems to work well. It appears to hang at the end because of http://bugs.winehq.org/show_bug.cgi?id=25059 but that's cosmetic; if you look for the icon hiding on the taskbar, you'll see the installer completed. Don't know if the resulting package works, but at least it installed for me just now once. Ship it! :-)

Dec. 7, 2010

Trace/breakpoint trap using VS2008 remote debugger

by Joe Dluzen

Hi all, I've got the Visual Studio Remote Debugger working with breakpoints, but not with forcing the process to pause. It immediately exits with "Trace/breakpoint trap." I've tried looking up the error, but it seems that no one has this specific set of circumstances. Any ideas? Thanks, Joe

Dec. 7, 2010

Re: winemenubuilder: Include icons in .url menus

by Andrew Bogott

On 12/7/10 3:09 PM, Paul Vriens wrote: > On 12/07/2010 06:45 PM, Andrew Bogott wrote: >> >> This should supersede the previous version of this patch. This one plugs >> a memory leak present in the last version. >> > > Hi Andrew, > > The previous patch has already been committed. Yep -- Alexandre did his push after I sent the revision but before it posted. I'll send a different smaller patch to fix the leak. -Andrew

Dec. 7, 2010

Re: winemenubuilder: Include icons in .url menus

by Paul Vriens

On 12/07/2010 06:45 PM, Andrew Bogott wrote: > > This should supersede the previous version of this patch. This one plugs > a memory leak present in the last version. > Hi Andrew, The previous patch has already been committed. -- Cheers, Paul.

Dec. 7, 2010

RE: ntdll: Implement missing 64 bit shifts

by Mike Gibson

Alexandre Julliard [julliard(a)winehq.org] writes: > Mike Gibson <mike.gibson(a)storagecraft.com> writes: > > > +/****************************************************************************** > > + * _allshr (NTDLL.@) > > + * > > + * Right arithmetic shift a 64 bit integer > > + * > > + * PARAMS > > + * a [I] Initial number. > > + * count [I] Number of bits to shift by. > > + * > > + * RETURNS > > + * The value of a following the shift. > > + */ > > +LONGLONG WINAPI _allshr( LONGLONG a, INT count ) > > +{ > > + return a >> count; > > +} > > There's no guarantee that this would be an arithmetic shift, it's > compiler-dependent. RtlLargeIntegerArithmeticShift doesn't handle this case either, but of course, that's not the point. Once we determine a solution, I'll fix it up as well. The following code would work regardless or right shift behavior. Of course, it's a bit slower. /* create mask to extend the sign bit */ LONGLONG mask; mask = ( LONGLONG ) 1 << 63; mask &= a; mask >>= count; /* do the shift */ a >>= count; /* add the mask */ a |= mask; return a; The vast majority of platforms seem to do arithmetic right shift. It would be better to have a #define that indicates what the right shifting behavior is. Only on those platforms where right shift isn't arithmetic would the slower code be used. AFAIK, this sort of thing is determined in the configure step. I can write a test for it, but I have a suspicion someone may have already done this. Anyone know? If not, I would appreciate some pointers (or links) on how to go about adding such a test. Mike Gibson

Dec. 7, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > Yes, we considered that. It means we need to be able to create a > cabinet file, which needs to be done with open source tools if we want > distributions to include the packages. Wine itself seems to be about > the only option there, but we don't support compression. If we already need Wine to create the msi file then it shouldn't be an issue to use it to create the cabinet. Compression shouldn't be hard to add. -- Alexandre Julliard julliard(a)winehq.org

Dec. 7, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Hans Leidekker

On Mon, 2010-12-06 at 23:14 +0100, Alexandre Julliard wrote: > > where 7zS.sfx is the self-extractor and wine_gecko-1.1.0.cfg looks > > like this: > > > > ;!@Install@!UTF-8! > > Title="Wine Gecko 1.1.0" > > BeginPrompt="Do you want to install Wine Gecko 1.1.0?" > > ExecuteFile="wine_gecko-1.1.0.msi" > > ;!@InstallEnd@! > > Of course it would be even nicer to pack everything inside the msi > file, then we wouldn't need a self-extractor at all... Yes, we considered that. It means we need to be able to create a cabinet file, which needs to be done with open source tools if we want distributions to include the packages. Wine itself seems to be about the only option there, but we don't support compression.

Dec. 7, 2010

re: [SOLVED] Cannot install Python on wine

by Alan W. Irwin

On 2010-12-06 18:49-0800 Dan Kegel wrote: > Does > winetricks python26 > work for you? The answer to your question (for wine-1.3.8, at least) is yes it does, and that lead to a complete solution! I am CCing to the list as well because others will be interested in that solution to my original question. The command above essentially downloads python-2.6.2.msi then executes wine msiexec /i python-2.6.2.msi ALLUSERS=1 which worked and is very similar to what I tried independently with python-2.7.1, i.e., wine msiexec /i python-2.7.1.amd64.msi which returned with no GUI and error message at all. I then realized from that name this was likely a 64-bit issue. I then downloaded the 32-bit MSI version, (from http://www.python.org/download/releases/2.7.1/) After that download wine msiexec /i python-2.7.1.msi worked like a charm! (I don't understand the significance of ALLUSERS=1 so I left it off.) So problem solved for python-2.7.1. Thanks for your helpful winetricks suggestion which gave me an excellent start on the road to finding the solution for the latest python2. One issue is you will likely want to incorporate the latest version of python2 in winetricks as well as python3 from http://www.python.org/download/releases/3.1.3/. The remaining issue is the complete lack of any error messages when executing the 64-bit MSI file. Shall I file a msiexec bug report about that? There is also no mention of 64-bit versus 32-bit MSI files at http://wiki.jswindle.com/index.php/Wine_MSI. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Dec. 7, 2010

Re: How to deal with variables where the size differs for 32 and 64bit

by Austin English

On Sun, Dec 5, 2010 at 12:05 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Just found the fix for the oledb32:convert tests on 64bit. We need to adjust > our oledb.idl (see patch attached). > > How should I deal with the ok() messages where we currently specify the > 32bit variant? I mean this will of course introduce warnings on the 64bit > side. > > Do I need to create a wrapper for the ok() messages, with a _WIN64 check > somewhere? Or use a different printf format identifier? > > The same is also true for the TRACE() messages in our implementation. Why not use an #ifdef there as well? A few other tests do it, for example: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/mshtml/tests/dom.c#l37… http://source.winehq.org/git/wine.git/?a=blob;f=dlls/kernel32/tests/process… -- -Austin

Dec. 7, 2010

Re: Cannot install Python on wine

by Austin English

On Mon, Dec 6, 2010 at 1:19 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > Here is what I have tried to install Python under wine so far > following what is recommended in > http://wiki.jswindle.com/index.php/Wine_MSI. This was done using > wine-1.3.8 with WINEDEBUG set to nothing (i.e., "WINEDEBUG=") so > that all warning/error messages would be output. > > wine(a)raven> wine msiexec /i python-2.7.1.amd64.msi Try the 32-bit version instead. Though wine-devel is for development communications, not general help. Use wine-users for assistance. -- -Austin

Dec. 7, 2010

CreatePrivateObjectSecurity implementation

by nicksukharev

I found that stub implementation for CreatePrivateObjectSecurity / DestroyPrivateObjectSecurity prevents Microsoft Exchange client from working properly. After changing these stubs to return an empty security descriptor and destroy it Exchange works much better. It can now read mail and calendar. I'm looking for suggestions what minimal implementation for these functions would be acceptable as a patch. -- View this message in context: http://wine.1045685.n5.nabble.com/CreatePrivateObjectSecurity-implementatio… Sent from the Wine - Devel mailing list archive at Nabble.com.

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > On Mon, 2010-12-06 at 20:21 +0100, Jacek Caban wrote: > >> > What improvements are needed for 7zip? It seems to work fine here, I can >> > use both the Windows and the Linux version to create self-extracting >> > archives for Windows. >> >> That's exactly the problem of creating Windows self-extracting archives >> on Linux. How do you do that? > > $ rm -f wine_gecko-1.1.0.7z > $ 7z a wine_gecko-1.1.0.7z wine_gecko-1.1.0.msi gecko/ > $ cat 7zS.sfx wine_gecko-1.1.0.cfg wine_gecko-1.1.0.7z > > wine_gecko-1.1.0.exe > > where 7zS.sfx is the self-extractor and wine_gecko-1.1.0.cfg looks > like this: > > ;!@Install@!UTF-8! > Title="Wine Gecko 1.1.0" > BeginPrompt="Do you want to install Wine Gecko 1.1.0?" > ExecuteFile="wine_gecko-1.1.0.msi" > ;!@InstallEnd@! Of course it would be even nicer to pack everything inside the msi file, then we wouldn't need a self-extractor at all... -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2010

Cannot install Python on wine

by Alan W. Irwin

Here is what I have tried to install Python under wine so far following what is recommended in http://wiki.jswindle.com/index.php/Wine_MSI. This was done using wine-1.3.8 with WINEDEBUG set to nothing (i.e., "WINEDEBUG=") so that all warning/error messages would be output. wine(a)raven> wine msiexec /i python-2.7.1.amd64.msi fixme:storage:create_storagefile Storage share mode not implemented. fixme:advapi:LookupAccountNameW (null) L"wine" (nil) 0x32f130 (nil) 0x32f134 0x32f128 - stub fixme:advapi:LookupAccountNameW (null) L"wine" 0x179f10 0x32f130 0x176bf8 0x32f134 0x32f128 - stub The lack of err: messages is encouraging. In particular notice these results have no err:msi:call_script Could not find CLSID for Windows Script which seemed to be an issue for another wine user that has attempted this with prior wine versions. So I had some hope that the above command actually worked, but it returned very quickly with no other response than above, and "find -name python.exe found nothing created by it in the whole wine account area I have set up to deal with wine matters. Thus, I don't think it worked. Is there some clue in the above fixme messages that indicates something fatal happened with msiexec? Is there anything else I should be doing? Another thread about a prior unsuccessful attempt to install Python under wine had this quote: "I have downloaded http://www.dll-files.com/dllindex/dll-files.shtml?msvcirt and placed it in the .wine/drive_c/windows/system directory." I don't have a clue about the significance of that step since I have no Windows experience and little wine experience. Is that step important or is it no longer necessary with wine-1.3.8? Anyhow, my test above was without that step since I didn't understand its necessity/significance. To give you some background about my use case, my development environment has been exclusively Linux since 1996, and I have no Microsoft Windows experience at all. Nevertheless, I help with developing the PLplot package which works on all of Linux, Mac OS X, and Windows so I try to help out the PLplot Windows developers by attempting to build PLplot under wine to follow/confirm what they do and any errors they find. As part of that work, I would like to test the optional PLplot Python bindings under wine which motivates my interest in installing the Windows version of Python under wine. Any help with the proper procedure for installing Python under wine would be much appreciated. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Juan Lang

> Hey ! I said I didn't want to be rude and that's still true > > RTFM is a kind of philosophy It's very hard to make RTFM not seem rude. Anything with the F word in it is, in my opinion, best left off this list. --Juan

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by André Hentschel

Am 06.12.2010 21:28, schrieb GOUJON Alexandre: > On 12/06/2010 09:15 PM, André Hentschel wrote: >> So that will simply create a linux executable with an ".exe" extention. >> You should consider being more friendly, especially when you dont know >> what you are talking about > Hey ! I said I didn't want to be rude and that's still true > > RTFM is a kind of philosophy > My teacher was always saying that and now, I'm proud of finding how > something works just by reading the manual > > Quoting the manual is relevant. > If not, the manual should be improved. > > That being said, > Have a nice .. day/night guys (depends) Sry, still was reading it in a rude way, had a long day. so sry. -- Best Regards, André Hentschel

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by GOUJON Alexandre

On 12/06/2010 09:15 PM, André Hentschel wrote: > So that will simply create a linux executable with an ".exe" extention. > You should consider being more friendly, especially when you dont know what you are talking about Hey ! I said I didn't want to be rude and that's still true RTFM is a kind of philosophy My teacher was always saying that and now, I'm proud of finding how something works just by reading the manual Quoting the manual is relevant. If not, the manual should be improved. That being said, Have a nice .. day/night guys (depends)

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by André Hentschel

Am 06.12.2010 21:07, schrieb Hans Leidekker: > On Mon, 2010-12-06 at 20:49 +0100, André Hentschel wrote: > >> So the only problem is to have the Windows sfx file in your Linux environment? > > Yeah, it would be nice to have a Linux package for it. The source > appears to be in the public domain. > > One plan was to send patches to p7zip to compile the sfx part twice(one time gcc, one time with mingw(-w64)) at buildtime, so that it is upstream. I am working on it, but i am also busy with other things. -- Best Regards, André Hentschel

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by André Hentschel

Am 06.12.2010 21:02, schrieb GOUJON Alexandre: > On 12/06/2010 08:21 PM, Jacek Caban wrote: >> That's exactly the problem of creating Windows self-extracting >> archives on Linux. How do you do that? > (I don't want to be rude but ...) > RTFM > > quoting `man 7z` from Ubuntu 10.04 : >> EXAMPLE 2 >> 7z a -sfx archive.exe dir1 >> add all files from directory "dir1" to SFX archive >> archive.exe >> (Remark : SFX archive MUST end with ".exe") > > > So that will simply create a linux executable with an ".exe" extention. You should consider being more friendly, especially when you dont know what you are talking about. -- Best Regards, André Hentschel

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Hans Leidekker

On Mon, 2010-12-06 at 20:49 +0100, André Hentschel wrote: > So the only problem is to have the Windows sfx file in your Linux environment? Yeah, it would be nice to have a Linux package for it. The source appears to be in the public domain.

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by GOUJON Alexandre

On 12/06/2010 08:21 PM, Jacek Caban wrote: > That's exactly the problem of creating Windows self-extracting > archives on Linux. How do you do that? (I don't want to be rude but ...) RTFM quoting `man 7z` from Ubuntu 10.04 : > EXAMPLE 2 > 7z a -sfx archive.exe dir1 > add all files from directory "dir1" to SFX archive > archive.exe > (Remark : SFX archive MUST end with ".exe")

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by André Hentschel

Am 06.12.2010 20:44, schrieb Hans Leidekker: > On Mon, 2010-12-06 at 20:21 +0100, Jacek Caban wrote: > >>> What improvements are needed for 7zip? It seems to work fine here, I can >>> use both the Windows and the Linux version to create self-extracting >>> archives for Windows. >> >> That's exactly the problem of creating Windows self-extracting archives >> on Linux. How do you do that? > > $ rm -f wine_gecko-1.1.0.7z > $ 7z a wine_gecko-1.1.0.7z wine_gecko-1.1.0.msi gecko/ > $ cat 7zS.sfx wine_gecko-1.1.0.cfg wine_gecko-1.1.0.7z > > wine_gecko-1.1.0.exe > > where 7zS.sfx is the self-extractor and wine_gecko-1.1.0.cfg looks > like this: > > ;!@Install@!UTF-8! > Title="Wine Gecko 1.1.0" > BeginPrompt="Do you want to install Wine Gecko 1.1.0?" > ExecuteFile="wine_gecko-1.1.0.msi" > ;!@InstallEnd@! > > > > So the only problem is to have the Windows sfx file in your Linux environment? -- Best Regards, André Hentschel

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Hans Leidekker

On Mon, 2010-12-06 at 20:21 +0100, Jacek Caban wrote: > > What improvements are needed for 7zip? It seems to work fine here, I can > > use both the Windows and the Linux version to create self-extracting > > archives for Windows. > > That's exactly the problem of creating Windows self-extracting archives > on Linux. How do you do that? $ rm -f wine_gecko-1.1.0.7z $ 7z a wine_gecko-1.1.0.7z wine_gecko-1.1.0.msi gecko/ $ cat 7zS.sfx wine_gecko-1.1.0.cfg wine_gecko-1.1.0.7z > wine_gecko-1.1.0.exe where 7zS.sfx is the self-extractor and wine_gecko-1.1.0.cfg looks like this: ;!@Install@!UTF-8! Title="Wine Gecko 1.1.0" BeginPrompt="Do you want to install Wine Gecko 1.1.0?" ExecuteFile="wine_gecko-1.1.0.msi" ;!@InstallEnd@!

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Wolfram Sang

>> What improvements are needed for 7zip? It seems to work fine here, I can >> use both the Windows and the Linux version to create self-extracting >> archives for Windows. > > That's exactly the problem of creating Windows self-extracting archives > on Linux. How do you do that? Check http://www.bugaco.com/7zip/MANUAL/switches/sfx.htm SFX-header + config.txt + archive.7z = win.exe I created such sfx-files on Linux to make the testbot run a bit more than the standard test-executables. Regards, Wolfram

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Jacek Caban

On 12/6/10 8:13 PM, Hans Leidekker wrote: > On Mon, 2010-12-06 at 19:15 +0100, Jacek Caban wrote: > >> Let's make it clear, what's the plan: >> The first step is moving the code to the right place (I will send >> patches moving it to appwiz.cpl). On the next Gecko release, we will >> change it to use MSI file and all goodies of more standard installation. >> Meantime we need some improvements. I know that André is looking at >> required 7zip improvements and Hans has looked at MSI file creation. I'm > I wrote a simple tool that allows you to build an installer database > from .idt files. Sounds great, thanks. > Note that it's a winelib program, so using it will make > Wine a build dependency of your project. That's fine with me. I believe that distros will be able to cope with it as well. > What improvements are needed for 7zip? It seems to work fine here, I can > use both the Windows and the Linux version to create self-extracting > archives for Windows. That's exactly the problem of creating Windows self-extracting archives on Linux. How do you do that? Jacek

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Hans Leidekker

On Mon, 2010-12-06 at 19:15 +0100, Jacek Caban wrote: > Let's make it clear, what's the plan: > The first step is moving the code to the right place (I will send > patches moving it to appwiz.cpl). On the next Gecko release, we will > change it to use MSI file and all goodies of more standard installation. > Meantime we need some improvements. I know that André is looking at > required 7zip improvements and Hans has looked at MSI file creation. I'm I wrote a simple tool that allows you to build an installer database from .idt files. Note that it's a winelib program, so using it will make Wine a build dependency of your project. What improvements are needed for 7zip? It seems to work fine here, I can use both the Windows and the Linux version to create self-extracting archives for Windows.

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Owen Rudge

On 06/12/2010 12:15, Jacek Caban wrote: > I must have misunderstood your plan then. Now I understand that we will > have MSI file with self extracting archive for both Gecko and Mono that > can be downloaded and/or installed by control panel applet. I agree that > appwiz.cpl looks like a better place than a new applet for that. Adding in an "optional components" tab to appwiz.cpl would seem to be the most sensible thing there, similar to that used in Windows. While you could have an entry in the Installed Programs list when they're installed, it would seem slightly perverse to include them in that list when they're not actually installed. To me, a separate tab would seem better. -- Owen Rudge http://www.owenrudge.net/

Dec. 6, 2010

Re: ntdll: Implement missing 64 bit shifts

by Alexandre Julliard

Mike Gibson <mike.gibson(a)storagecraft.com> writes: > +/****************************************************************************** > + * _allshr (NTDLL.@) > + * > + * Right arithmetic shift a 64 bit integer > + * > + * PARAMS > + * a [I] Initial number. > + * count [I] Number of bits to shift by. > + * > + * RETURNS > + * The value of a following the shift. > + */ > +LONGLONG WINAPI _allshr( LONGLONG a, INT count ) > +{ > + return a >> count; > +} There's no guarantee that this would be an arithmetic shift, it's compiler-dependent. -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2010

Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.

by Jacek Caban

On 12/6/10 1:15 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> The following series of patches is a first step towards Wine Add-ons >> tool. These patches move Gecko installation to wineaddon.cpl. They do >> nothing about making install code generic nor provide any new GUI yet. >> They only place the code in the right place so that it can be improved >> further. > Is a separate control panel really the right place? It seems to me that > it would be preferable if add-ons were treated more like normal > packages, and in particular registered in the installed packages > list. This would make it possible to manage them from the appwiz control > panel, and from other tools that use install information like > uninstaller. I must have misunderstood your plan then. Now I understand that we will have MSI file with self extracting archive for both Gecko and Mono that can be downloaded and/or installed by control panel applet. I agree that appwiz.cpl looks like a better place than a new applet for that. Let's make it clear, what's the plan: The first step is moving the code to the right place (I will send patches moving it to appwiz.cpl). On the next Gecko release, we will change it to use MSI file and all goodies of more standard installation. Meantime we need some improvements. I know that André is looking at required 7zip improvements and Hans has looked at MSI file creation. I'm planning to add checksum checking and fix installation without z: drive mapping. Also some GUI changes and making the code more generic for Mono will be needed. It's up to Vincent when he's planning to add Mono package. Jacek

Dec. 6, 2010

Re: How to deal with variables where the size differs for 32 and 64bit

by Reece Dunn

On 5 December 2010 20:05, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Just found the fix for the oledb32:convert tests on 64bit. We need to adjust > our oledb.idl (see patch attached). Nice find. Shouldn't these be using the _PTR types instead (ULONG_PTR, LONG_PTR and friends?) -- then you don't need the 32/64-bit switch. > How should I deal with the ok() messages where we currently specify the > 32bit variant? I mean this will of course introduce warnings on the 64bit > side. > > Do I need to create a wrapper for the ok() messages, with a _WIN64 check > somewhere? Or use a different printf format identifier? Does "%p" (pointer) work? Are there any other tests that handle 32/64-bit types? - Reece

Dec. 6, 2010

Re: How to deal with variables where the size differs for 32 and 64bit

by André Hentschel

Am 05.12.2010 21:05, schrieb Paul Vriens: > Hi, > > Just found the fix for the oledb32:convert tests on 64bit. We need to > adjust our oledb.idl (see patch attached). wow, good job!!! > How should I deal with the ok() messages where we currently specify the > 32bit variant? I mean this will of course introduce warnings on the > 64bit side. sry, actually i don't know, just wanted to thank you. -- Best Regards, André Hentschel

Dec. 6, 2010