Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Jim Balter <jqb at netcom dot com>]

Colin Peters wrote:
> 
> A. Phillip Smith[SMTP:asmith@www.aeinc.com] wrote:
> [snip]
> >of fact that the mere INCLUSION of a particular Win32 call caused the
> >GUI portion of a program to apparently fail (silent death). Note that
> >the code was NEVER invoked, as I stated, so usage errors are not at
> >issue.
> >
> >This is further complicted on Windows NT by the fact that unless you strip
> >the executable, the binary will not run. Hence you have no VCC++ debugging OR
> >gdb debugging capability. Here's another simple program in it's entirety.
> >Compile it per the gcc line. It works fine. Now uncomment the statement
> >containing the GetFullPathName call, and rebuild. If you get something
> >other than the "silent death" behaviour, please share it. This seems like
> >a bug to me, unless there's some other link options of which I'm unaware...
> [snip - Code example]
> 
> It doesn't seem to be a code generation problem, or at least not an easy
> one to reproduce. I must point out that I compiled with Mingw32 and not
> the normal Cygnus libraries, so there is some chance (small though it may
> be) that the Mingw32 environment removes or influences this bug in some
> strange way. Another possibility is that it is an NT thing, since I did
> the compile on 95 (where you don't have to strip to get a working exec
> either, so debugging is possible with GDB). Anyway the point is that it
> works, both ways, no problem. (The compile line under Mingw32 is slightly
> different, but essentially comes down to the same arguments for cc1 and
> ld).
> 
> Are you using a completely vanilla version of GNU-Win32 or have you made
> changes to things (like the startup code for example)? Could you send me
> a copy of your silently failing binary?
> 
> Colin (If it is a compiler bug lets find it and fix it) Peters.
> 
> PS. Any confirmations on that statement about NT from other readers?
>     Does stripping an executable make it work? Do you *have* to strip
>     on NT? Is there a difference between the -s link option and using
>     strip after linking?

Under NT 4.0, the program dies just by virtue of *referencing*
GetFullPathName, without calling it (as APS said).  The following
is enough to cause the access violation:

  #include <windows.h>

  void (*xxx)() = GetFullPathName;

  int STDCALL
  WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
  {
        return 0;
  }

I've tracked this down, and have determined that it dies with a SIGSEGV
which doesn't get printed anywhere because cygwin.dll prints it to
STD_ERROR_HANDLE, which isn't valid.  Clearly it should do better,
at the very least writing it to the strace output if that is a file, and
a
MessageBox would be nice.  A useful option would be to not set the
exception handler, so that the windows debugger would get it.
APS' complaint that silent exit is a bug is quite valid, but it isn't
something to be surprised about from alpha software like cygwin.dll.

The point at which it dies is the at the very beggining of main()
from libcmain.cc, when it calls GetModuleHandle.  That call goes to a
jump instruction that goes
through an indirect pointer that appears to contain the wrong
address, since it is the address of some code.  The jump uses the
content of that code as the "location" to go to, and so it
dies.  Perhaps to someone who knows about Windows dll's and jump tables,
the problem here might be obvious, but I know nothing of those things.
But it sure looks like a serious screwup by ld.

If someone wants to pursue this who can run the MS debugger under NT
4.0,
the easiest way is to build a version of cygwin.dll with the
init_exceptions call in dcrt0.cc commented out (or ignored based
upon an environment variable, so you can control it dynamically).


A word about the comments from drs@inxpress.net:

>>... I merely stated a point
>> of fact that the mere INCLUSION of a particular Win32 call caused the
>> GUI portion of a program to apparently fail (silent death). Note that
>> the code was NEVER invoked, as I stated, so usage errors are not at
>> issue.
>
> I would have to see this to believe it.

He gave an example.  His WinMain never gets called,
let alone the GetFullPathName call that triggers the problem.

>> Compile it per the gcc line. It works fine. Now uncomment the statement
>> containing the GetFullPathName call, and rebuild. If you get something
>> other than the "silent death" behaviour, please share it. This seems like
>> a bug to me, unless there's some other link options of which I'm unaware...
>
> The code you posted failed to work as expected, Phillip, because you 
> are not using it correctly. What you posted works exactly as advertized
> by the SDK. The API puts the path and the file-name together. That's it.
> It does not verify the presence of the file name. It is not a "search" 
> api at all. Granted, this is a pretty stupid behaviour, but then I'm not 
> an MS apologist. The API in question works correctly and compiles
> correctly
> under gnu-win32. You simply don't know how to use it.

Your arrogance is unwarranted and unearned.
His usage was perfectly reasonable, even if his comment that refers to
"search" is misleading.  In any case, his use or misuse is irrelevant
when the complaint was that the code died silently.  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.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".