Francois Gouget fgouget@free.fr writes:
On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry points for DPA_Create and DPA_Search. So we need to link them dynamically if we want the rest of the tests to run.
What version of comctl32 is that?
On Fri, 16 Jan 2004, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry points for DPA_Create and DPA_Search. So we need to link them dynamically if we want the rest of the tests to run.
What version of comctl32 is that?
That was version 5.00.2919.6304.
But Hans Leidekker and Rolf Kalbermatter were right: the functions are there, it's only that they are exported by ordinal only and/or are missing from the MSVC import libraries. In any case, modifying the test to load them by ordinal using GetProcAddress makes the test work on NT4 and even on Windows 95 (with comctl32 version 4.00.950).
So I'm sending an updated patch.
Francois Gouget fgouget@free.fr writes:
But Hans Leidekker and Rolf Kalbermatter were right: the functions are there, it's only that they are exported by ordinal only and/or are missing from the MSVC import libraries. In any case, modifying the test to load them by ordinal using GetProcAddress makes the test work on NT4 and even on Windows 95 (with comctl32 version 4.00.950).
So I'm sending an updated patch.
I think we should leave it as it is. These are about the only functions exported by ordinal that are available in basically all Windows versions, and that are even documented on MSDN, so this is a very good opportunity to test ordinal imports.
On Sun, 18 Jan 2004, Alexandre Julliard wrote: [...]
I think we should leave it as it is. These are about the only functions exported by ordinal that are available in basically all Windows versions, and that are even documented on MSDN, so this is a very good opportunity to test ordinal imports.
Can't we find another way to test ordinal imports in Winelib?
Because without this patch the comtcl32 tests don't compile with the Windows SDK. As far as I am concerned that means there is no way to generate a Windows executable for the comctl32 tests and thus it is impossible to make sure they are correct. Not just the dpa tests but also the tab tests and certainly more in the future.
Or is there a way to keep the static ordinal import and still have something that compiles with MSVC?
What about MinGW? It sounds like this test does not compile there either...
Francois Gouget fgouget@free.fr writes:
Or is there a way to keep the static ordinal import and still have something that compiles with MSVC?
Yes, you just need an MSVC version that has a correct import lib (or copy the import lib from somewhere).
What about MinGW? It sounds like this test does not compile there either...
That's a MinGW bug, you can work around it by using the Wine-generated import libs.
On Sun, 18 Jan 2004, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
Or is there a way to keep the static ordinal import and still have something that compiles with MSVC?
Yes, you just need an MSVC version that has a correct import lib (or copy the import lib from somewhere).
The link fails with both the Visual C++ 6 import library, and the one from the very latest Microsoft SDK (downloaded this week). So I'm not sure such a 'correct' import lib exists.
But I must be missing something: if the function is exported by ordinal only, how is the linker supposed to know that 328 is DPA_Create?
On Mon, 19 Jan 2004, Francois Gouget wrote: [...]
The link fails with both the Visual C++ 6 import library, and the one from the very latest Microsoft SDK (downloaded this week). So I'm not sure such a 'correct' import lib exists.
I checked in more details and with the import library that comes from the latest Microsoft SDK, it's only DPA_Create which is missing. DPA_Search is there and links fine.
So we could compromise: use GetProcAddress() on DPA_Create and link normally to DPA_Search. This way the test compiles with MSVC and we still get to test the ordinal imports.
I'll submit a patch (tomorrow morning).
Francois Gouget fgouget@free.fr writes:
I checked in more details and with the import library that comes from the latest Microsoft SDK, it's only DPA_Create which is missing. DPA_Search is there and links fine.
Yes, it seems DPA_Create has been removed; it's there in the import lib of MSVC 5 but not in the latest one. This looks like an MS bug since it's declared in the header file.
So we could compromise: use GetProcAddress() on DPA_Create and link normally to DPA_Search. This way the test compiles with MSVC and we still get to test the ordinal imports.
Yes that's a good solution.
On Sunday 18 January 2004 18:02, Francois Gouget wrote:
What about MinGW? It sounds like this test does not compile there either...
Well, it compiles and links, but doesn't link at run-time because MinGW's import lib exports these symbols by name, not ordinal-only.
I submitted a patch to correct this to MinGW but they wouldn't accept it because of some documented-by-Microsoft-only policy.
-Hans
Hans Leidekker wrote:
On Sunday 18 January 2004 18:02, Francois Gouget wrote:
What about MinGW? It sounds like this test does not compile there either...
Well, it compiles and links, but doesn't link at run-time because MinGW's import lib exports these symbols by name, not ordinal-only.
I submitted a patch to correct this to MinGW but they wouldn't accept it because of some documented-by-Microsoft-only policy.
Say again?!
That's not very constructive. Microsoft documentation is not very good.
Where can I start if I want to convert the Mingw minds?
regards, Jakob
On 19.01.2004 18:05:18 Hans Leidekker wrote:
On Sunday 18 January 2004 18:02, Francois Gouget wrote:
What about MinGW? It sounds like this test does not compile there either...
Well, it compiles and links, but doesn't link at run-time because MinGW's import lib exports these symbols by name, not ordinal-only.
I submitted a patch to correct this to MinGW but they wouldn't accept it because of some documented-by-Microsoft-only policy.
You are searching for documentation of DPA_Create() and DPA_Search() ? Herer it is:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
As you may know, Microsoft lost its Anti-Trust process and had to make public some previous API - a lot of shell functions are a part of them. However they did "hide" them in a not very prominent place of MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
Regards,
Martin
On Monday 19 January 2004 20:46, Martin Fuchs wrote:
You are searching for documentation of DPA_Create() and DPA_Search() ? Herer it is:
[MSDN links]
Yes, I know those are documented nowadays. MinGW has prototypes for those functions, no problem with that. It's the bit of information that says that DPA_Create (and previously the other functions) is exported as ordinal 328, and exported ordinal only. That's not documented on MSDN and, they say, can only have been obtained through "reverse engineering".
-Hans
"Hans Leidekker" hans@it.vu.nl wrote:
Yes, I know those are documented nowadays. MinGW has prototypes for those functions, no problem with that. It's the bit of information that says that DPA_Create (and previously the other functions) is exported as ordinal 328, and exported ordinal only. That's not documented on MSDN and, they say, can only have been obtained through "reverse engineering".
Do they consider a "reverse engineering" running 'dumpbin /exports comctl32.dll' ?
On Tuesday 20 January 2004 10:19, Dmitry Timoshkov wrote:
Do they consider a "reverse engineering" running 'dumpbin /exports comctl32.dll' ?
Here's the answer I got from Danny Smith back in October last year:
The only ways you can determine the ordinal alias in absence of documentation is by reverse engineering or by trial and error. How were these determined?
By pushing the limits on "clean room" development of the w32api, we jeopardise not only the mingw project but also other projects - cygwin, Watcom - that seek to provide tools mainly for ordinary developers (who get no value from having DPA_Clone and friends exposed in the import lib).
-Hans
"Hans Leidekker" hans@it.vu.nl wrote:
Do they consider a "reverse engineering" running 'dumpbin /exports comctl32.dll' ?
Here's the answer I got from Danny Smith back in October last year:
The only ways you can determine the ordinal alias in absence of documentation is by reverse engineering or by trial and error. How were these determined?
By pushing the limits on "clean room" development of the w32api, we jeopardise not only the mingw project but also other projects - cygwin, Watcom - that seek to provide tools mainly for ordinary developers (who get no value from having DPA_Clone and friends exposed in the import lib).
Thanks. That's just another proof for ReactOS guys to make use of Wine headers and libraries instead of ones provided by MinGW.
Dmitry Timoshkov wrote:
By pushing the limits on "clean room" development of the w32api, we jeopardise not only the mingw project but also other projects - cygwin, Watcom - that seek to provide tools mainly for ordinary developers (who get no value from having DPA_Clone and friends exposed in the import lib).
Thanks. That's just another proof for ReactOS guys to make use of Wine headers and libraries instead of ones provided by MinGW.
It is all a matter of crosscompiling conformance tests with mingw.
/Jakob
"Jakob Eriksson" jakov@vmlinux.org wrote:
It is all a matter of crosscompiling conformance tests with mingw.
I think that we need to switch to using Wine import libraries for MinGW compiled tests. I sent a patch for that, but it was rejected. Alexandre, taking into account the stance of MinGW maintainers probably it's time to refuse to use (broken) MinGW import libs?
"Dmitry Timoshkov" dmitry@baikal.ru writes:
I think that we need to switch to using Wine import libraries for MinGW compiled tests. I sent a patch for that, but it was rejected. Alexandre, taking into account the stance of MinGW maintainers probably it's time to refuse to use (broken) MinGW import libs?
No, I still think there is value in building the tests with different import libs to spot problems. We'll just need to work around the broken comctl32.
--- Alexandre Julliard julliard@winehq.org wrote:
No, I still think there is value in building the tests with different import libs to spot problems. We'll just need to work around the broken comctl32.
While we are at it can we work around the broken msvcrt problems in mingw?
"../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit'"
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
-
Alexandre Julliard -
Dmitry Timoshkov -
Francois Gouget -
Hans Leidekker -
Jakob Eriksson -
Martin Fuchs -
Steven Edwards