RE: Janitorial W->A cleanup objects/metafile.c dlls/gdi/mfdrv/init.c

[Rolf Kalbermatter]

This is a multi-part message in MIME format.
--------------030003030306020205040907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
> This one was required more that a mop and pail. In the end what I had to do is 
> convert MF_CreateMetaHeaderDisk to unicode.
>
> One burning question I have at this point is the relative merits of using 
> RtlCreateUnicodeStringFromAsciiz vs MultiByteToWideChar

Well, when using MultiByteToWideChar you usually format into a buffer allocated
on the stack whereas RtlCreateUnicodeStringFromAsciiz seems to allocate a buffer
on the heap which you later free.

The first is somewhat faster as no memory management calls are caused, but as
Alexandre has pointed out, the current Wine code is at places quite stack intense
which over time could lead to serious problems if Wine is extended with even
more functions allocating much more Unicode buffers on the stack.

So the question is really one about a little performance gain vs. code which has
moderate stack requirements. Personally I think it is ok to allocate once a Unicode
buffer on the stack in the high level API to convert ANSI to Unicode, provided
the code path further down doesn't go back and forth between ANSI and Unicode
conversions. But in general we should probably try in the future to get those
buffers more often allocated dynamically for two reasons:

1) Just as a single buffer on the stack in a high level API once doesn't cause
extreme stack usage, does the same single allocation of a buffer on the heap not
cause a very noticable performance hit.

2) With proper dynamic buffer allocations we can get rid of many buffer length
limitations. A stack buffer is always fixed length and can fail fataly if a
parameter is entered which causes buffer overflow. So the code needs to do extra
checks. Dynamic allocated buffers can be as long as necessary and do not
necessarily have buffer overflow issues.

Rolf Kalbermatter
CIT Engineering Nederland BV    tel: [phone]
Treubstraat 7H                           fax: [phone]
2288 EG Rijswijk	http://www.citengineering.com
Netherlands		mailto:rolf.kalbermatter(a)citeng.com