Wine Developer Cheatsheet, v1

Mike Hearn m.hearn at signal.QinetiQ.com
Mon Sep 6 03:54:30 CDT 2004


 > That's is very interesting and useful, but I think there's two things 
that
> can be improved: first the debug delay patch, I wasn't able to find it out
> searching with gmane, maybe if you can add a link to the post on gmane it
> should be better :)

Yeah, it's a bit of a pain keeping track of useful patches that were 
never merged. Maybe we need a list somewhere.

> The second thing is about the coding style. As I said before, I have a patch
> for shlwapi which fixes some MSXML/Borland XML Components problems with the
> builtin one, which wasn't accepted for some problem about the style and the
> placement of the variables. I posted it as a bug at
> http://bugs.winehq.org/show_bug.cgi?id=2385 . If you can add something
> about the coding style I can fix it up and repost it for inclusion.

A few things that jump out at me (not really reviewed the code itself):

- No C++ // style comments, I'm afraid. They aren't portable enough.
- Use HeapAlloc() over malloc(), as it says in the cheatsheet
- Are you sure there is a debugstr_a?? I can't think what it would do,
   ANSI strings can just be printed by regular printf
- You have to declare all the variables at the start of a block. Yes,
   it's a pain. Another C portability rule. So, can't do this:

   LPSTR foo = bar;
   StrCpyA(a, b);
   int i;

   They all have to go at the top.

- Minor stylistic note: you can use strcpy rather than StrCpyA. But I
   doubt this was a problem.
- Usually best to space stuff out, ie rather than this:

   if ( temp_out == temp_out2 ) { temp_in += 3; continue; }

   use this:

   if ( temp_out == temp_out2 )
   {
       temp_in += 3;
       continue;
   }

   ... again I doubt Alexandre would reject the patch because of this.

- //if ( *temp_in == '.' )  ... wine code generally doesn't do this. If
   you find it hard to match up a closing brace with the statement that
   opened it maybe you need ... *fanfare* EMACS! :)

- Is it possible to implement the ANSI version by converting to unicode
   then calling the wide version, rather than duplicate it?

The rest looks fine, I expect it was just the C portability stuff that 
tripped you up. Please do try again!

thanks -mike



More information about the wine-devel mailing list