Wine Developer Cheatsheet, v1

[Mike Hearn]

Hi guys,

Back in February at WineConf one of the issues (I) raised was that
there's a lot of stuff you just have to know in order to hack Wine, and
that raises the barrier to entry.

So, I wrote this. If anybody has stuff they think should be added, let
me know. If the community likes it, I'll submit it as a patch against
the website:

http://navi.cx/~mike/wine/developer-cheatsheet.html

thanks -mike

[James Hawkins]

I like this Mike.  It's even convenient if you aren't so new.


On Sat, 04 Sep 2004 13:31:52 +0100, Mike Hearn <mike(a)navi.cx> wrote:
> Hi guys,
>
> Back in February at WineConf one of the issues (I) raised was that
> there's a lot of stuff you just have to know in order to hack Wine, and
> that raises the barrier to entry.
>
> So, I wrote this. If anybody has stuff they think should be added, let
> me know. If the community likes it, I'll submit it as a patch against
> the website:
>
> http://navi.cx/~mike/wine/developer-cheatsheet.html
>
> thanks -mike

-- 
James Hawkins

[Diego 'Flameeyes' Pettenò]

Mike Hearn wrote:
> Back in February at WineConf one of the issues (I) raised was that
> there's a lot of stuff you just have to know in order to hack Wine, and
> that raises the barrier to entry.
> 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 :)

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.

-- 
Diego "Flameeyes" Pettenò
dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

[Francois Gouget]

About handling Unicode strinsg you say:
> when allocating buffers for unicode strings use
> sizeof(string)*sizeof(WCHAR).

It's not very clear and most of the type the sizeof will not give the
expected result. I think it would be better to say to use
(strlen(ansi_string)+1)*sizeof(WCHAR). But really, these days to convert
an ANSI string to Unicode the recommended way is:

    lenW = MultiByteToWideChar(CP_ACP, 0, strA, -1, NULL, 0);
    strW = HeapAlloc(GetProcessHeap(), 0, lenW * sizeof(WCHAR));
    MultiByteToWideChar(CP_ACP, 0, strA, -1, strW, lenW );


Now I'm just nitpicking, a bit later you say:
> Any function which expects a null terminated string requires a wide
> equivalent, as it's legal for wide strings to have null bytes in them.

I would rather say that wide strings *have* nul bytes in them. At least
> 99% of the time, and >95% of the time they have more than 50% nul
> bytes!

Also:
> Speaking of which, the contents of ntdll are undocumented

Some of it is documented though it may notb ethe most useful parts. But
for instance, an MSDN search on RtlInitializeBitMap returns a man page
with a bunch of other ntdll functions.

More generally while it's a good idea to say not to rely on MSDN too
much, it should still be pointed out as a useful resource especially if
you don't know what the API is supposed to do, whether it returns 0 or 1
on success, etc. For this reason I created a parameterized Mozilla
shortcut. Now I just type stuff like 'msdn CreateProcess' as the URL...

http://search.microsoft.com/search/results.aspx?View=msdn&qu=%s


-- 
Francois Gouget         fgouget(a)free.fr        http://fgouget.free.fr/
    Indifference will certainly be the downfall of mankind, but who cares?