wine-devel September 2006

wine-devel@winehq.org

139 participants
257 discussions

Re: Route WGL font code through gdi32.dll
by Huw Davies 27 Sep '06

27 Sep '06

On Wed, Sep 27, 2006 at 11:34:35PM +0200, Roderick Colenbrander wrote: > Hi, > > This patch routes the WGL font code through gdi32.dll. The patch depends on the other routing patch which routed the WGL context code through gdi32.dll. > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 @@ -396,5 +396,5 @@ @ stdcall wglSwapLayerBuffers(long long) @ stdcall wglUseFontBitmapsA(long long long long) @ stdcall wglUseFontBitmapsW(long long long long) -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You want to forward the wglUseFontBitmaps functions here since that's what the rest of your patch touches ;-) You also forgot to include the changes to gdi32.spec. Huw.

1 0

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp 27 Sep '06

27 Sep '06

> From: Alexandre Julliard <julliard(a)winehq.org> > > If you expect > anything to happen, you'll need to make much more concrete > suggestions, and provide examples to make us understand how > what you are suggesting would work in practice Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I have no idea what your typical workflow looks like. I'm also not restrained by any knowledge of emacs and what can be done in its plugins, macro's, user-defined commands or whatever they're called. But I know I could code the proposal below in e.g Perl or C, so I guess it should be possible in Lisp also. Who's going to code that is a different matter altogether, let's first see if we can think of a solution which would work. Let's assume a patch is submitted to wine-patches. A bot would receive it and store it in a database (Patchwork already seems to do a fine job on this). The bot could do some simple checks, like does it apply cleanly, no C++ comments, whatever automatic checks we can come up with. If one of the checks fails, the status would be set to RFC (Request For Change, I'm using the Patchwork statuses here) and the author would receive an automatic email explaining what's wrong, otherwise the status would be set to New. Note that this should save you some time, weeding out "obviously" wrong patches. On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command. Behind the scenes, this would send a request to the webserver which would reply with a list of queued patches. This list could be sorted by a score. Authors who consistently submit good patches would get a higher score than, well, me. This score could be computed as the number of accepted patches minus the number of rejected patches. A patch already reviewed (and recommended) by a subsystem maintainer could get a real big score boost so it ends up near the top of the list. Patches which have been in the queue for a few days could get extra points. Patches with RFC status wouldn't be shown at all or get a very low score. Anyway, you end up with a list of patches on your screen with the least problematic near the top. This should help ensure that these get through pretty quickly. So you select a patch which is then retrieved from the server. It could be automatically applied, a build started, whatever suits you best. Comments made on it by other developers could be shown to you. After testing is complete, you issue a "decision" command. You can decide to accept the patch, that would send an "accept" message to the webserver and perhaps it could be comitted to your git repo. If the patch needs more work, you'll be prompted for a message. That message will be mailed to the author with a copy to win-devel and it will be sent to the webserver which will change the patch status to RFC. If you think the patch is beyond hope it can be rejected outright (again with a message to author and wine-devel). Or you can decide not to decide on it today and sleep on it for a night. Then the patch will just show up in the list of pending patches again tomorrow, with a little bit higher priority (since it has been in the queue longer). Back to the list of pending patches, repeat. > and how it would be different from what we are doing now. It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Ge van Geldorp.

6 6

re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Dan Kegel 27 Sep '06

27 Sep '06

Alexandre wrote: > How will this test work in non-English locales? How about if it calls SetThreadLocale(LOCALE_INVARIANT)?

3 2

Re: start.exe: Implement /D option, add new wine specific feature allowing to specify the shell operation name (resend)
by James Hawkins 27 Sep '06

27 Sep '06

On 9/26/06, Paul Chitescu <paulc(a)voip.null.ro> wrote: > Changelog: start.exe: Implement /D option, add new wine specific feature > allowing to specify the shell operation name. > > The new /O[peration] command line option allows to specify a shell operation > other than "open". This is very valuable for testing or implementing actions > from shell scripts. > > It is also possible to pass a NULL operation by specifying the empty string > '' (or whatever looks like in your preferred shell). > > Examples: > wine start /d 'c:\' notepad.exe > wine start /o print README.txt > Only submit one fix per patch. Please read the WineHQ patch guidelines: http://winehq.org/site/sending_patches Why are you adding a new switch? This isn't provided by native start.exe, so we shouldn't add it. -- James Hawkins

2 2

Re: localspl: [1/3] Build the Importlib
by Alexandre Julliard 27 Sep '06

27 Sep '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > We need the importlib for the tests It doesn't seem that we should have an importlib, there isn't one in the SDK either. The tests can always use GetProcAddress. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Stefan Dösinger 27 Sep '06

27 Sep '06

Hi, > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. Not so sure about it. I am afraid I do not completely understand the color depth issue, but it appears to me that a patch like that rather hides the problem than fixing it. It is not possible to chance the depth on the fly on X11, so we may want a solution for all color depths.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Dmitry Timoshkov 27 Sep '06

27 Sep '06

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Then it should be changed to 'ULONG' or 'unsigned LONG' for compatibility with Win64. -- Dmitry.

2 2

Re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Alexandre Julliard 27 Sep '06

27 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > +void test_VarWeekdayName(void) > +{ > + WCHAR day_LongFormat[][10] = > + { > + {'S','u','n','d','a','y',0}, > + {'M','o','n','d','a','y',0}, > + {'T','u','e','s','d','a','y',0}, > + {'W','e','d','n','e','s','d','a','y',0}, > + {'T','h','u','r','s','d','a','y',0}, > + {'F','r','i','d','a','y',0}, > + {'S','a','t','u','r','d','a','y',0} > + }; How will this test work in non-English locales? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: clusapi: Implements stub dll for clusapi
by Alexandre Julliard 27 Sep '06

27 Sep '06

"Benjamin Arai" <me(a)benjaminarai.com> writes: > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=6265 > > The application for bug 6265 checks if clusapi.dll exists and attempts > to call clusapi:GetNodeClusterState from it. This patch adds a stub > implementation for the DLL clusapi and GetNodeClusterState. You need to add a DLL_WINE_PREATTACH handler when adding a stub dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wintrust.h: add missing defines
by Paul Vriens 27 Sep '06

27 Sep '06

On Tue, 2006-09-26 at 22:08 -0700, Juan Lang wrote: > #define WTD_UI_ALL 1 > #define WTD_UI_NONE 2 > @@ -115,6 +118,42 @@ > DWORD dwUIContext; > } WINTRUST_DATA, *PWINTRUST_DATA; > > +#define WTD_UI_ALL 1 > +#define WTD_UI_NONE 2 > +#define WTD_UI_NOBAD 3 > +#define WTD_UI_NOGOOD 4 > + > +#define WTD_REVOKE_NONE 0 > +#define WTD_REVOKE_WHOLECHAIN 1 > + > +#define WTD_CHOICE_FILE 1 > +#define WTD_CHOICE_CATALOG 2 > +#define WTD_CHOICE_BLOB 3 > +#define WTD_CHOICE_SIGNER 4 > +#define WTD_CHOICE_CERT 5 Hi Juan, these ones you've added are already in (see also first line in the excerpt from your email). Cheers, Paul.

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2006