September 2009 - Wine-Devel

Re: dlls/user32/edit.c -- remove superflous check
by Austin English Sept. 24, 2009

Sept. 24, 2009

On Thu, Sep 24, 2009 at 3:15 PM, todd baker <kkiddrrock707(a)yahoo.com> wrote: You forgot the patch. -- -Austin

1 0

Re: richedit: Silence fixme for WM_STYLECHANGING & WM_STYLECHANGED.
by James Mckenzie Sept. 24, 2009

Sept. 24, 2009

>From: Dylan Smith <dylan.ah.smith(a)gmail.com> >Sent: Sep 24, 2009 6:02 AM >To: wine-patches <wine-patches(a)winehq.org> >Subject: richedit: Silence fixme for WM_STYLECHANGING & WM_STYLECHANGED. > >I have tried changing the different styles, and have noticed that they >don't have any effect. The initial styles are the ones actually used, >which is why they are stored internally for the editor. Is this in Wine or in Windows? If it is in Wine, then we still need to implement the code to make the styles in the editor change. This may involve alot of work to get them completely functional as styles change at least one item. James McKenzie

2 1

Re: shell32: stub ShellHookProc for the Aion launcher
by Chris Robinson Sept. 24, 2009

Sept. 24, 2009

On Thursday 24 September 2009 11:54:33 am Aric Stewart wrote: > +@ stdcall ShellHookProc(long long long) ... > +LRESULT CALLBACK ShellHookProc(DWORD a, DWORD b, DWORD c) Doesn't CALLBACK signify cdecl, not stdcall?

2 1

Re: comctl32: initial theming tests
by Nikolay Sivov Sept. 24, 2009

Sept. 24, 2009

André Hentschel wrote: > tests class redirection and "load"-order atm > --- > dlls/comctl32/tests/Makefile.in | 1 + > dlls/comctl32/tests/theming.c | 301 +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 302 insertions(+), 0 deletions(-) > create mode 100644 dlls/comctl32/tests/theming.c > Why not reuse this +static const CHAR manifest[] = from v6util.h. Also it's better to introduce new create/delete manifest helpers in this header and use them. It's better to use already defined classnames here: --- + struct classlist {WCHAR class[24]; BOOL todo;} listW[] = {like --- STATUSCLASSNAMEW for example. If the purpose of that --- static void test_redirection(HINSTANCE hInstance, LPCWSTR clsname, BOOL todo) --- is to show that message procedure moves to comctl32 after enabling themes than testing for comctl32 classes is useless - winproc is already in this module. I don't think it's a good choice: --- + pIsThemeActive = (void*)GetProcAddress(hUxtheme, "IsThemeActive"); + if (!pIsThemeActive || !pIsThemeActive()) --- I mean what if I don't use theming on XP but classic decorations will it return TRUE? Not sure but maybe this class reregistration occurs anyway when v6 module is loaded (manifest specified). Skipping like that will drop tests on native boxes that have theming disable what isn't good. BTW. Do you plan to reregister all user32 classes on comctl32 load? How could this be done at user32 side - testing for something like IsThemeActive() while loading user32?

3 2

Re: Fix for Bug 19851 (try 4) - Interlocked instruction support for ARM
by André Hentschel Sept. 24, 2009

Sept. 24, 2009

On Thu, Sep 24, 2009 at 12:19 PM, Colin Fowler <elethiomel(a)gmail.com> wrote: > Removed trailing white-spaces. I think this is good to go now :) every "else" still has trailing white-spaces and the first comment line("\* "). BTW i like that someone works on the ARM port. thats great! -- Best Regards, André Hentschel

1 0

Re: [kernel32/tests] Fix some test failures on WinMe
by Alexandre Julliard Sept. 24, 2009

Sept. 24, 2009

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > @@ -1894,10 +1895,18 @@ static void test_FindFirstFileExA(void) > ok(FindNextFile(handle, &search_results), "Fetching third file failed\n"); > ok(CHECK_NAME(search_results.cFileName), "Invalid third entry - %s\n", search_results.cFileName); > > - ok(FindNextFile(handle, &search_results), "Fetching fourth file failed\n"); > + SetLastError(0xdeadbeef); > + ret = FindNextFile(handle, &search_results); > + ok( ret || > + broken(!ret && GetLastError() == ERROR_NO_MORE_FILES), /* WinMe */ > + "Fetching fourth file failed\n"); It sounds like it's actually respecting the FindExSearchLimitToDirectories flag, so I'm not sure this qualifies as broken. Maybe testing without that flag too would be a better test. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Fix for Bug 19851 (try 4) - Interlocked instruction support for ARM
by Austin English Sept. 24, 2009

Sept. 24, 2009

On Thu, Sep 24, 2009 at 12:19 PM, Colin Fowler <elethiomel(a)gmail.com> wrote: > Removed trailing white-spaces. I think this is good to go now :) Close ;-). > +#elif defined(__arm__) Like AJ said, if it's generic enough to be used on most archs, it should be the fall back. So instead of '+#elif defined(__arm__)', use '#else', and remove the ' #else', '# error You must implement the interlocked* functions for your CPU'. -- -Austin

1 0

Re: Fix for Bug 19851 (try 3) - Interlocked instruction support for ARM
by André Hentschel Sept. 24, 2009

Sept. 24, 2009

You have some trailing whitespaces in your patch. As far as i had a look it is mostly the intendation from an empty line. -- Best Regards, André Hentschel

1 0

newbie question
by Dmitry Konnov Sept. 24, 2009

Sept. 24, 2009

Hello All, can somebody tell weather it is possible to run NT service on Wine, especially written in Delphi VCL(TService) tx. dima

1 0

Re: Fix for Bug 19851 (try 3) - Interlocked instruction support for ARM
by Alexandre Julliard Sept. 24, 2009

Sept. 24, 2009

Colin Fowler <elethiomel(a)gmail.com> writes: > @@ -396,6 +396,88 @@ > "beq $1,L0xchg_add\n\t" > "mb") > > + > +#elif defined(__arm__) > + > +/* > + * Similar to the Sparc, many ARM CPUs lack the necessary > + * atomic instructions. Fall back in a similar way, but instead > + * use pthreads. This solution is generic enough to work on > + * pretty much any CPU, but is still very fast thanks to > + * Linux's NPTLS. > + */ Actually since it's generic there's no reason to put it in an __arm__ ifdef, it could simply be the default fallback. -- Alexandre Julliard julliard(a)winehq.org

2 1