Should CDLGetLongPathName[AW] be exported by ordinal

[Francois Gouget]

On Windows XP and 2003ES the CDLGetLongPathName[AW] ordinals are 4 and 5 
respectively. On Windows 9x, NT4 and Windows 2000 they are 1 and 2 
respectively.

If Microsoft changed the ordinal of these APIs it means the ordinal does 
not matter so I'm tempted to post the following patch:

Index: dlls/urlmon/urlmon.spec
===================================================================
RCS file: /var/cvs/wine/dlls/urlmon/urlmon.spec,v
retrieving revision 1.31
diff -u -p -r1.31 urlmon.spec
--- dlls/urlmon/urlmon.spec	30 Nov 2004 21:14:21 -0000	1.31
+++ dlls/urlmon/urlmon.spec	23 Feb 2005 10:21:11 -0000
@@ -1,8 +1,8 @@
-1 stub CDLGetLongPathNameA
-2 stub CDLGetLongPathNameW
  @ stub AsyncGetClassBits
  @ stub AsyncInstallDistributionUnit
  @ stub BindAsyncMoniker
+@ stub CDLGetLongPathNameA
+@ stub CDLGetLongPathNameW
  @ stub CoGetClassObjectFromURL
  @ stub CoInstall
  @ stdcall CoInternetCombineUrl(wstr wstr long wstr long ptr long)

Yet in Windows 2000 Microsoft went out of its way to assign these 
ordinals to them so I suspect there is something more to this.

Could it be that old versions of Internet Explorer import these APIs by 
ordinal and that since Windows XP and greater ships with a recent enough 
version of Internet Explorer Microsoft decided it was no longer 
necessary to keep the old ordinals for compatibility?

What should we do if this turns out to be the case? Do we want to keep 
the ordinals anyway? I guess that the minimum would be to document this 
in the spec file.

[Alexandre Julliard]

Francois Gouget  writes:
> What should we do if this turns out to be the case? Do we want to keep
> the ordinals anyway? I guess that the minimum would be to document
> this in the spec file.

Yes we should keep the ordinals, it doesn't hurt anything and
potentially improves compatibility with old apps.