September 2002 - Wine-Devel

wstr vs ptr in spec files
by Andriy Palamarchuk Sept. 12, 2002

Sept. 12, 2002

When should I use wstr and when ptr for wide strings in the spec files functions specification? Looking at existing files I see that LPCWSTR type is usually mapped to wstr, but LPWSTR is sometimes mapped to ptr, sometimes to wstr. Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

RE: Patch - Fix typo
by Patrik Stridvall Sept. 12, 2002

Sept. 12, 2002

> On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > > I noticed this when adapting WINE code for ReactOS > [...] > > > > - * DialogBoxIndirectParam (USER.240) > > > - * DialogBoxIndirectParam16 (USER32.@) > > > + * DialogBoxIndirectParam16 (USER.240) > > > + * DialogBoxIndirectParam (USER32.@) > > > */ > > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > > HANDLE16 dlgTemplate, > > > HWND16 owner16, > > > DLGPROC16 dlgProc, > > > > No this is correct. > > > > The 16 bit function's external name is DialogBoxIndirectParam > > The 32 bit function's external name is DialogBoxIndirectParam16 > Then maybe add a comment instead: > "(yep, 16/32 naming is correct)" Well, it quite common in the core DLLs that the naming is done that way so it would be quite a lot of IMHO unnessary comments. PS. winapi_check automatically finds functions that are wrong so the Wine sourc eis currrently 100% correct (save bugs in winapi_check of course) as far as the issue above in documentation header is concerned.

1 0

Re: Patch - Fix typo
by Andreas Mohr Sept. 12, 2002

Sept. 12, 2002

On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > I noticed this when adapting WINE code for ReactOS [...] > > - * DialogBoxIndirectParam (USER.240) > > - * DialogBoxIndirectParam16 (USER32.@) > > + * DialogBoxIndirectParam16 (USER.240) > > + * DialogBoxIndirectParam (USER32.@) > > */ > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > HANDLE16 dlgTemplate, > > HWND16 owner16, > > DLGPROC16 dlgProc, > > No this is correct. > > The 16 bit function's external name is DialogBoxIndirectParam > The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: "(yep, 16/32 naming is correct)" -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

1 0

Re: Duplicate: Listview update - LVM_GETITEMRECT
by Dimitrie O. Paun Sept. 12, 2002

Sept. 12, 2002

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > Alexandre: Is this format any better. I am worried about line end > characters and line wrapping. I like this format a lot better! But I'm no Alexandre... :) > This is built on top of CVS of yesterday (9/9/02) but will probably > conflict with Dimi's latest patch. Can you please rediff against the current tree? TIA, Dimi.

3 5

RE: Strange CVS problem (help!!!)
by Patrik Stridvall Sept. 12, 2002

Sept. 12, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The orginal reason for winapi_cleanup was to convert the \r\n > > that I got while editing in Micrsoft Developer studio > > to \n. > > > > But I can modify it the so it only does that. > > > > It should probably remove trailing whitespace at lines > > ending in \ though since some compilers choke on that. > > Sure, the idea of a cleanup tool is a good thing, it just should only > do the cleanups that we all agree on. Myself I'm especially interested > in an automatic cleanup of C++ comments... Already on my TODO list. BTW. How do you want multiliners like // XXX // YYY // ZZZ to look like? Like this /* XXX * YYY * ZZZ */ or like this /* * XXX * YYY * ZZZ */ or perhaps in some other way? One liners like // XXX should simply look like /* XXX */ Or would you prefer it some other way?

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall Sept. 11, 2002

Sept. 11, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > Of course having an imperfect parser also means we cannot > use it for > > > the export info, because unlike relay debugging it needs > to be 100% > > > correct. So we either need compiler declspec support, > > > > That will leave us dependent on compilers that support it. > > Well, the idea would be not to depend on compiler support for the > __declspec keyword itself, but more to have some clever macro > replacements that output stuff in a special ELF section or something > like that. This could then hopefully be made to work on most > compilers. But I'm not sure if there's a good way to do that at all. It might work, but then it might not. > > This isn't happend soon either. It might not be THAT difficult, > > however the code need not just work it needs be well structured > > and organized as well if any reasonable guarantees of correctness > > can be made. > > I think most of all it needs to be simple. My idea is to run through > the preprocessor, This will be VERY slow. > find the __declspec, and locate the corresponding > function name, or die if there's anything it cannot parse. This should > be reasonably foolproof. A naive idea would be search for __declspec while keeping track of the nesting level (that is how many (, [, { that have not been closed). If the nesting level goes from 1 to 0 before finding the __declspec set a mark. When __declspec is found search backward to mark until you find ; at nesting level 0 or the mark then skip forward any white space. This is extremely likely to be the beginning of a function. Then search forward until { or ; is found when nesting level is 0. Then skip any whitespace backwards. You now know where a __declspec function begins and ends. This reduces the problem to the parsing of a function declaration. The rest is left as an exersize to the reader. :-) The problem is that this might work or it might not. You have no real guarante that it will. > And IMO it shouldn't be in Perl, it should be > part of winebuild. That will not make things easier.

3 2

Strange CVS problem (help!!!)
by Dimitrie O. Paun Sept. 11, 2002

Sept. 11, 2002

Folks, Up until a few days ago, I was able to do this: # vim some/wine/file.c # cvs diff some/wine/file.c > file.diff # mail wine-patches(a)winehq.com < file.diff # sleep <until Alexandre commited the patch> # cvs up At this point, CVS would figure out that the changes in file.c in my tree are the same as the ones on the server, will give a message to that effect, and update the file. As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different? -- Dimi.

7 20

RE: Strange CVS problem (help!!!)
by Patrik Stridvall Sept. 11, 2002

Sept. 11, 2002

> Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > I (personally) like to keep it the way it is. > > If the submitter is worried about the spaces he can > > run the whitespaces cleaning tool himself before > > submitting the patch (hint, hint ;-) > > Well, no, if not everybody does it you can't do it either, otherwise > it will create huge differences. I don't want to receive a patch that > is 10% code and 90% whitespace changes just because the guy who edited > the file before you didn't cleanup the spaces. Well, either you remove trailing whitespaces from patches or you don't. If you do than "the guy who edited the file before you didn't cleanup the spaces" case can't happend, can it?

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall Sept. 11, 2002

Sept. 11, 2002

> > You have the case: > > void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) > > __attribute__((noreturn)) { } > > > > Sure you can have an exception if the name seems to be > __attribute__ but > > then where might be other exceptions. > > Yes, but a few preprocessor defines can get rid of that. Well. You want to read the __attribute__ to know if the function should be stdcall or cdecl don't you? The there might be cases I haven't though of. > > > The only problem is if you want to find > > > the number of args for stdcall decoration, but we should > be able to do > > > without it. > > > > That is not a problem. If you find the opening ( before the > function name, > > it would be the number of , at nesting level 1 plus one > with the special > > case of void between the parantesis which means 0. > > Except for 64-bit data types... And data structures. Forgot about that. > > Perhaps. You will easily reach 99% correctness. However > beyond that it > > is hard without a real C parser. > > Well it's clear you can't get 100%, the thing is to make sure it fails > in a reasonable way, not just silently breaks. Agreed. > I think it is feasible; Maybe. > whether it is worth the effort is an entirely different question... It is MANY hours of work. Work I'm not going to be able to motivate myself to do especially not if you want it in C. The last time years ago I did parsing and string handling in C was a horrible experience one I'm not eager to experience again, especially since other tools (read: Perl) exists. PS. I do agree it should be done in C though.

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall Sept. 11, 2002

Sept. 11, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > This will be VERY slow. > > I don't think it will be really different than duplicating all the > work the preprocessor is doing inside the parser itself. Of course you > want to use the Wine preprocessor, not fork+exec gcc for each file. OK. I was mainly refering to fork+exec gcc. > But yes parsing all the files is of course slower than having all the > info in the .spec, there's no way around that. Of course. > > You now know where a __declspec function begins and ends. > > This reduces the problem to the parsing of a function declaration. > > The rest is left as an exersize to the reader. :-) > > All you really need is the function name, which should be the last > token before the opening '('. Yes, but which opening? There might be several at nesting level 0. And searching backward to find the matching ( from the last ) might not be always correct either. You have the case: void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) __attribute__((noreturn)) { } Sure you can have an exception if the name seems to be __attribute__ but then where might be other exceptions. > The only problem is if you want to find > the number of args for stdcall decoration, but we should be able to do > without it. That is not a problem. If you find the opening ( before the function name, it would be the number of , at nesting level 1 plus one with the special case of void between the parantesis which means 0. > > The problem is that this might work or it might not. You > have no real > > guarante that it will. > > Well the thing is if you find a declspec you output what you think is > the function name. If you get it wrong and output 'WINAPI' or 'char*' > instead you'll notice it at build time. Perhaps. You will easily reach 99% correctness. However beyond that it is hard without a real C parser. It easy to do that for reasonable functions but for ALL function is much harder. For example you have the special case of a function that returns a function pointer. Not even all C compilers gets that one right, so it normally done with a helping typedef...

2 1