August 2006 - Wine-Devel - list.winehq.org

Re: widl [3/6]: Represent typedefs with easier to use structures

by Dan Kegel

On 8/29/06, Dan Hipschman <dsh(a)linux.ucla.edu> wrote: > I need to generate names for tagless structs, etc., because my patch changes > the way typedefs are output in the header file. Currently, > > typedef struct { int x; } foo, bar; > > will be output exactly as is in the header (disregarding whitespace changes). > However, this patch splits the typedefs up like this: > > typedef struct { int x; } foo; > typedef struct ??? bar; > > This is why we need the generated names. I think we might need them anyway; standard C++ is very picky, and requires tags in more circumstances than one would like.

Aug. 29, 2006

Re: widl: Remove use of type_t "ref" field for base types

by Dan Hipschman

On Tue, Aug 29, 2006 at 01:46:52PM +0100, Robert Shearman wrote: > >@@ -207,6 +207,7 @@ struct _type_t { > > func_t *funcs; /* interfaces and modules */ > > var_t *fields; /* interfaces, structures and > > enumerations */ > > ifref_t *ifaces; /* coclasses */ > >+ type_t *orig; /* dup'd types */ > > int ignore, is_const, sign; > > int defined, written, user_types_registered; > > int typelib_idx; > > You add a new field to type_t, yet no code uses it. Will it have some > future purpose? It takes the place of ref for typedefs. I.e., it refers to the typedef'd type. It's used in write_typedef, check_for_user_types, encode_type, and add_typedef_typeinfo in the third patch of my last series. It's true no code used it in this earlier patch (except duptype, which only initialized it).

Aug. 29, 2006

Re: widl [3/6]: Represent typedefs with easier to use structures

by Dan Hipschman

On Tue, Aug 29, 2006 at 01:45:41PM +0100, Robert Shearman wrote: > > if (n) fprintf(h, "%s", n); > >+ else if (t->kind == TKIND_ALIAS) fprintf(h, "%s", t->name); > > I'm not really sure we should be depending on a typelib thing for a > fundamental concept such as this. In fact, I think the kind field of the > type_t structure could probably be removed and generated as needed in > the typelib generation code. The kind field is useful outside of the typelib, though. In fact, as you say, it's not really even that useful inside the typelib code. It's *more* useful in the parser and header code. If you don't like me using it this way, maybe we could just rename the field and constants to remove the connotation of being associated only with typelibs. Without using the "type == 0 && ref != NULL" combo to designate typedefs, we need some way to separate typedefs from regular types, and this was the most obvious choice for me. > >void init_types(void) > >{ > >+ decl_builtin("void", 0); > > decl_builtin("byte", RPC_FC_BYTE); > > This would seem as though it would make widl incorrectly accept "int > func(void a);" as a valid statement. I think you need to try to fix this > case. This patch doesn't change the grammar or semantic phase at all. It only removes a special case in write_type so we can print void types by their name field. The point was to allow this chunk of patch: - } - } - else { - if (t->ref) { - write_type(h, t->ref, NULL, t->name); - } - else fprintf(h, "void"); Actually, the "int f(void a)" declaration is already accepted, even without this patch. This patch doesn't fix that; it wasn't intended to change the language semantics at all. Now that you bring it up, however, I, or somebody else, can submit a patch that will fix the problem fairly easily, I think. > >-static type_t *reg_types(type_t *type, var_t *names, int t) > >+static type_t *reg_typedefs(type_t *type, var_t *names, attr_t *attrs) > >{ > > type_t *ptr = type; > > int ptrc = 0; > > > >+ /* We must generate names for tagless enum, struct or union. > >+ Typedef-ing a tagless enum, struct or union means we want the typedef > >+ to be included in a library whether it has other attributes or not, > >+ hence the public attribute. */ > >+ if ((type->kind == TKIND_ENUM || type->kind == TKIND_RECORD > >+ || type->kind == TKIND_UNION) && ! type->name && ! parse_only) > >+ { > >+ if (! is_attr(attrs, ATTR_PUBLIC)) > >+ { > >+ attr_t *new_attrs = make_attr(ATTR_PUBLIC); > >+ LINK(new_attrs, attrs); > >+ attrs = new_attrs; > >+ } > > I'm not sure it is necessary to include this change with the rest of the > patch. I'm also not sure what you are trying to accomplish here (as we > always add the type to a typelib, no matter whether the type has the > public attribute). I need to generate names for tagless structs, etc., because my patch changes the way typedefs are output in the header file. Currently, typedef struct { int x; } foo, bar; will be output exactly as is in the header (disregarding whitespace changes). However, this patch splits the typedefs up like this: typedef struct { int x; } foo; typedef struct ??? bar; This is why we need the generated names. As for adding the public attribute, we don't (and MIDL doesn't) add typedefs to the typelib if they don't have any attributes (since reg_types was only used for typedefs, I renamed it to reg_typedefs to make the use clearer). By observing MIDL, I found that it will add the public attributes to typdefs on tagless structs, etc., so they are included in the typelib. Thanks for your comments. I'm trying my best to improve widl, so if you see something that looks questionable, I don't mind the criticism.

Aug. 29, 2006

Re: [wintrust] Add some documentation

by James Hawkins

On 8/29/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > On Tue, 2006-08-29 at 09:38 -0700, James Hawkins wrote: > > On 8/29/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > > > Hi, > > > > > > I thought I'd start with some documentation. The tests are already > > > there so what's missing is the implementation :-). > > > > > > > > > /*********************************************************************** > > > * WintrustAddActionID (WINTRUST.@) > > > + * > > > + * Add a Trust provider. Or actually the functions it performs. > > > + * > > > > Can you rewrite this sentence? It's not grammatically correct, and I > > don't understand what you're saying. > > > Hi, > > something like this: > > * Add a Trust provider. Part of the Trust provider is the definition of > * the actions it can perform. WintrustAddActionID add these definitions > * to the registry. > I wouldn't describe the Trust provider concept in an API documentation, we only need to document what action the function performs. Something along these lines would work: "Add a Trust provider and the definition of the actions it can perform to the registry." I'm not familiar enough with wintrust to make this clear, but you get the idea. -- James Hawkins

Aug. 29, 2006

Re: [wintrust] Add some documentation

by Paul Vriens

On Tue, 2006-08-29 at 09:38 -0700, James Hawkins wrote: > On 8/29/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > > Hi, > > > > I thought I'd start with some documentation. The tests are already > > there so what's missing is the implementation :-). > > > > > > /*********************************************************************** > > * WintrustAddActionID (WINTRUST.@) > > + * > > + * Add a Trust provider. Or actually the functions it performs. > > + * > > Can you rewrite this sentence? It's not grammatically correct, and I > don't understand what you're saying. > Hi, something like this: * Add a Trust provider. Part of the Trust provider is the definition of * the actions it can perform. WintrustAddActionID add these definitions * to the registry. Paul.

Aug. 29, 2006

Re: [wintrust] Add some documentation

by James Hawkins

On 8/29/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > I thought I'd start with some documentation. The tests are already > there so what's missing is the implementation :-). > > > /*********************************************************************** > * WintrustAddActionID (WINTRUST.@) > + * > + * Add a Trust provider. Or actually the functions it performs. > + * Can you rewrite this sentence? It's not grammatically correct, and I don't understand what you're saying. -- James Hawkins

Aug. 29, 2006

Re: Keyboard freeze - Max Payne

by Jeremy Newman

Alexandre has yet to apply them. I assume he does not like them? Trying to keep this issue open until it is fixed. ;-) On Wed, 2006-08-23 at 19:05 -0600, Viitaliy Margolen wrote: > Jeremy Newman wrote: > > http://bugs.winehq.org/show_bug.cgi?id=5712 > > > > We have a bug on this I see. Still no fix as of yet. Consider this a > > bump. > > > > On Wed, 2006-08-23 at 13:50 -0500, Jeremy Newman wrote: > >> Just going through my list of issues I'd like resolved, and discovered > >> this bug/regression. > >> > >> In Max Payne 1 / Max Payne 2 it seems the game freezes up for a few > >> seconds when you hold down any key in the game. For example using 'W' to > >> move forward, hold it down you take like 1 step and it freezes up. > >> Letting go and waiting a few seconds gets the game back to normal. As > >> you can imagine, this makes it unplayable. > >> > >> Before I go and enter this as a bug, I was wondering if anyone knows > >> about this and/or has a fix. > >> > See my patch(es). They address the problem. > > Vitaliy > >

Aug. 29, 2006

Re: X11Drv: import glx context code

by Alexandre Julliard

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > +@ cdecl WGL_CreateContext(long) X11DRV_WGL_CreateContext > +@ cdecl WGL_DeleteContext(long) X11DRV_WGL_DeleteContext > +@ cdecl WGL_GetCurrentContext() X11DRV_WGL_GetCurrentContext > +@ cdecl WGL_GetCurrentDC() X11DRV_WGL_GetCurrentDC > +@ cdecl WGL_GetCurrentReadDCARB() X11DRV_WGL_GetCurrentReadDCARB > +@ cdecl WGL_glGetIntegerv(long ptr) X11DRV_WGL_glGetIntegerv You should export the functions under their official name, like we do for the GDI functions, so something like: @ cdecl wglCreateContext(long) X11DRV_wglCreateContext etc. -- Alexandre Julliard julliard(a)winehq.org

Aug. 29, 2006

Re: widl [2/6]: Handle more pointer types in write_type

by Robert Shearman

Dan Hipschman wrote: >So write_type can handle more than just full pointers. > Hi Dan, I see from a couple of patches back that you intend to move the representation of pointers out of the var_t type. How do you intend to represent "char **" for example? type: FC_RP, ref: { type: FC_RP, ref: { type: FC_CHAR } } or: type: FC_CHAR, ptr_level: 2 It seems to me you're going down the first route (and there's nothing wrong with that as far as I can see). I'm just interested to know which approach you are taking. -- Rob Shearman

Aug. 29, 2006

Re: widl: Remove use of type_t "ref" field for base types

by Robert Shearman

Dan Hipschman wrote: >diff --git a/tools/widl/widltypes.h b/tools/widl/widltypes.h >index d39def3..cf0f246 100644 >--- a/tools/widl/widltypes.h >+++ b/tools/widl/widltypes.h >@@ -207,6 +207,7 @@ struct _type_t { > func_t *funcs; /* interfaces and modules */ > var_t *fields; /* interfaces, structures and enumerations */ > ifref_t *ifaces; /* coclasses */ >+ type_t *orig; /* dup'd types */ > int ignore, is_const, sign; > int defined, written, user_types_registered; > int typelib_idx; > You add a new field to type_t, yet no code uses it. Will it have some future purpose? -- Rob Shearman

Aug. 29, 2006