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@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 them:
- first way is to check whether the ordinal associated to a given
function changes accross Windows versions. This is the technique Dave used.
- 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>.