missing ordinals in avifil32
compsol at ptd.net
Thu Sep 11 16:54:56 CDT 2003
Yes, I used the first method to make this patch. I added a web form to
compare ordinals to the api db. I took the second method into
consideration when I cleaned up glu32. I was going to add ordinals, but
then realized they were alphabetized. I don't think I'm clear on what
to do when there are holes in the ordinals though. It sounds as though
the best route is to first alphabetize the list, like your example
below. Is it true then that the ordinal does not need to be specified
any time n = n+1? This sounds like a rule that will only apply
sometimes. Specifically, in cases where windows seems to assign at
least some ordinals in alphabetical order.
Francois Gouget wrote:
>On Wed, 10 Sep 2003, Alexandre Julliard wrote:
>>Dave Miller <compsol at ptd.net> writes:
>>>The first 59 ordinals seem to match in all windows versions. Add
>>>ordinals to avifil32.spec to match windows.
>>Unless ordinals are actually needed, it's better not to add them. In
>>that case the functions are sorted so it's very likely that Windows is
>>using automatic allocation too.
>Yep, writing a script that detects whether Windows assigns a specific
>ordinal to a function or not is tricky. There are two ways to detect
>that and I think the best results can only be obtained by combining
> * first way is to check whether the ordinal associated to a given
>function changes accross Windows versions. This is the technique Dave
> * the second would be to take all the functions in the dll, sort them
>alphabetically, and check if their ordinals are in the expected order.
>E.g. let's say you have:
> function ordinal
> A 2
> B 4
> C 3
> Obviously at least one of these three functions is exported by
>ordinal otherwise their ordinals would follow the alphabetical order and
>always increment by 1. The tricky part is determining which API is
>exported by ordinal. Here's a possible algorithm:
> A has ordinal n. If B (the next function in alphabetical order) has
>an ordinal different from n+1 then it's exported by ordinal. We then
>consider all functions to be exported by ordinal until we find a
>function with ordinal n+1.
> The problem is that this algo breaks down if the firts function in
>the dll is exported by ordinal and if there are holes in the ordinals.
>In particular we are likely to find holes if some functions are exported
>by ordinal (e.g. all functions 1-49 with ordinals < 100), and others not
>(automatically assigned ordinals >100).
> Maybe a simple enough solution in practice would be to start with the
>last function in alphabetical order...
>Note: I Wine's spec file it's not necessary to sort the functions that
>don't have an ordinal. But it's much cleaner<g>.
More information about the wine-devel