Re: Stupid stupid question :/

["A. Phillip Smith" <asmith at www dot aeinc dot com>]

> 
> A. Phillip Smith wrote:
> > 
> > Actually, ignoring the spawn/CreateProcess problems, the
> > use of gnu-win32 to build even vanilla Win32 programs is
> > limited. I was unable to get windows subsystem programs to
> > execute by just adding a simple call to 'WritePrivateProfileSection'
> > in a callback function to update a .CFG file.
> > 
> > Removing that simple statement allows the GUI program to execute,
> > while adding it causes it to die silently. Note that the problem has
> > to do with code generation or environment, since it is invoked in
> > the callback, it should only cause runtime troubles when it is
> > actually executed. As things stand, the application window is
> > never generated when that 1 line is added.
> 
> I would like to vigorously rebut this view. A) I was able to call the
> function
> in question successfully on the first try. Probably you failed to read
> the 
> documentation, which specifies double null termination on the data
> parameter.
> 
> B) I have also successfully called API's not supported by the
> distribution's 
> library, by simply linking dynamically. This technique requires a bit
> more effort,(creating function pointer and then binding it with
> GetProcAddress) 
> but it works. In this way I was able to access WinMM (the 32 bit wrapper 
> on MMSYSTEM) and play midi files. In theory *any* windows API can be
> called in
> this way; thus, the distribution has no effective limit in terms of API
> access.
> But reading the MS Documentation will help ;)
> 
> C) Anyone with much Windows programming experience can attest to the
> relative 
> difficulty in debugging Windows programs. You say "the 
> program died silently" and suggest this is somehow a statement about the
> compiler; but this is simply wrong. With more experience you will see
> how
> many times your Windows code will fail in exactly this way. The bane of
> the 
> Windows Programmer is not the GPF (which can actually be a useful
> signal) 
> but the hidden silent failure, which you can't seem to trace.
> 
> D) The importance of Windows as a GUI environment (as opposed to a
> 32-bit
>  multi-tasking one) is in my view highly over-rated.
> 
> Regards,
> D. Smith
> 

I'm not sure which "view" you're rebutting... 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. 

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...

	Phil Smith


#include <windows.h>

/*
gcc -o mytest.exe mytest.c -lkernel32 -luser32 -Wl,--subsystem,windows
*/

int STDCALL
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
{
        HWND    hWnd;
        LPTSTR  lpPart;
        char    Path[255];
        char    *cwd;

        hWnd = GetTopWindow( NULL );

        // Build path from current directory
        cwd = (char *) getcwd(NULL, 256);
        sprintf(Path,"Path is %s/test.exe",cwd);

        // Use Win32 search API to get the path
        //if ( ! GetFullPathName("test.exe", 256, Path, &lpPart) ) {
        //MessageBox (NULL, "Not Found", "Full Path", MB_OK|MB_ICONEXCLAMATION);
        //}

        // Show the constructed path
        MessageBox (NULL, Path, "Full Path", MB_OK|MB_ICONINFORMATION);

        return 0;
}

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