Mail Archives: cygwin/1997/03/26/22:35:16
Jim Balter wrote:
> Under NT 4.0, the program dies just by virtue of *referencing*
> GetFullPathName, without calling it (as APS said).
Huh. Must be a bug in the linker. (Not.)
The following code compiles and works correctly under win95. I suggest
it may work on your system, too.
// g++ -o test.exe test.cpp
#include <windows.h>
#include <iostream.h>
LPTSTR lpFilePart;
main()
{
DWORD (*api)( LPCTSTR file, DWORD length,
LPTSTR buf, LPTSTR *lpFile);
api = GetFullPathName;
char* lpFileName = "test.exe";
char* buffer = new char[256];
(*api)(lpFileName, 256, buffer, &lpFilePart);
cout << "buffer: " << buffer << endl;
cout << "filename: " << lpFilePart << endl;
delete [] buffer;
return 0;
}
So even though you and Phil claim to have found a linker bug, I have
yet to be able to reproduce it. The function works correctly
either referenced as a pointer, or simply on it's own. I don't know
why you are trying to reference the function name (it has nothing to
do with calling the api) but you brought it up. I can find no trace
of the problems you guys describe. All of the API's mentioned work
fine for me. So *maybe* it's an NT thing.
Maybe not.
> The following is enough to cause the access violation:
>
> #include <windows.h>
>
> void (*xxx)() = GetFullPathName;
>
The correct prototype for GetFullPathName looks like this, Jim:
DWORD (*api)( LPCTSTR file, DWORD length, LPTSTR buf, LPTSTR
*lpFilePart);
[...]
> Your arrogance is unwarranted and unearned.
Perhaps. But my code seems to work, while yours and Phil's doesn't. ;)
>There is nothing
> in any SDK that would indicate that MessageBoxes should never show up,
> with not even a Dr. Watson popup. The fact that the code works as
> advertised on *your* system is irrelevant when the behavior of the code
> on *APS's* system was described ("silent death") and is incorrect.
I hate to disagree. I can only mention many hours of frustration in the
old win16 days, trying to figure out why an app silently failed.
If my code sample fails on your system (or Phils) then I will be happy
to
agree--something is wrong with the linker or perhaps the NT version of
the function. On the other hand, if it works under NT, then I hope
and expect you to acknowledge as much. Everyone makes mistakes
in their code, but not all of us immediately blame the toolset for
our problems.
Regards as always.
--DRS
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -