[PATCH 2/2] wininet: Add a new common module information struct

Morten Rønne morten.roenne at tdcadsl.dk
Wed Apr 18 14:46:30 CDT 2012


Den 18-04-2012 17:42, Piotr Caban skrev:
> On 04/16/12 22:03, Morten Rønne wrote:
>> Add a new common module information struct for urlcache and functions to
>> do initialization of the struct. This is intended to be a new way to
>> more easily create Ansi and Unicode version of the functions, by doing a
>> Ansi/Unicode preamble code that calls a common worker function that do
>> the real work.
> Is there any reason not to call Ansi function inside Unicode function?
>
> (This is the other way then it is done in most parts of wine, the
> reason for this is that urlcache stores ansi strings internally.
> Unicode urls should probably be converted using punycode encoding
> (IdnToAscii?)).
>
> This patch is also introducing lots of unneeded Ansi/Unicode
> conversions. I'm not sure if storing all url entry related information
> inside a structure makes anything easier/more readable. Especially when
> you need to make sure that a field is initialized before accessing it.
>
Hi

By creating a common internal function for the Ansi and Unicode function 
you can use return to exit "early" in the function.
Together with the common struct, this makes cleanup easy regardless of 
how little or how much work was done.
All "tracking" of allocation is done in that one struct.

This means that most top level functions can be written:
   if (AcquireIndex)
      do work
   ReleaseIndex

Also from a TRACE point of view you only get one trace entry per call, 
with clear information whether an ansi or unicode function was called.
Also by having a common function it is possible to reuse functions, e.g. 
RetrieveUrlCacheEntryStream can use RetrieveUrlCacheEntry common 
function in its implementation. This can be done because the 
locking/release is done once in the top level entry function.

Doing a general rule of Unicode calls Ansi function, you will end up 
with even more round trip conversions, because Unicode function would 
convert to ansi, and the ansi function would convert back to unicode in 
some cases, at least as the code is now.
If you are to avoid this, you have to rewrite all the internal functions 
to use ansi only in its processing (see comment about prefix below).

Regarding Ansi/Unicode conversions.
If you read the current code, you will find that certain functions will 
do a round trip conversion between Ansi/Unicode already.
My code will only do one conversion ever, once it is fully implemented.

The current implementation requires both the unicode version and the 
ansi version (at least of the url), because the url prefix in the 
container struct, used to find the container is in unicode and the 
internal value used inside the cache is ansi.
The same is true about all file processing which is done in unicode.

Regarding the actual conversion of ansi/unicode I have simply done what 
is already being done in the module. If there is another way, feel free 
to send the exact code that I should use or send a patch after.

Creating a few common functions will ensure that all variables needed 
are initialized properly, so there is no need for testing whether or not 
a value is filled or not.

I believe that what I propose here will make the implementation of 
functions simpler and safer.

Best Regards
Morten Rønne



More information about the wine-devel mailing list