Stupid stupid question :/

Stupid stupid question :/

[Chris Wall]

I know this has probably been hashed over several times on the list and
elsewhere, but I'm stuck...

I'm having problems compiling Win95 gui apps with 17.1. In the faq they
mention using the -ssubsystem windows option to gcc OR ld, but when I do
so I get an "invalid option" and "no such file or directory: windows"
error. There was another part of the mailing list archives/faq (don't
remember which) that mentioned using a -mwindows switch - which didn't
work for me either.

The compiler goes on its merry way, and comes to a few functions that
it's totally confused by, but I am hoping that this is because of the
lib/target problem I'm having - the program isn't my source, it's a
cheezy example program with (unfortunately) a MSVC mak file. 

Anyhow, any help would be greatly appreciated!

Christopher Wall
vergil@midusa.net

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

Re: Stupid stupid question :/

[A. Phillip Smith]

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

Re: Stupid stupid question :/

[A. Phillip Smith]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

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.

Phil

> 
> >Linking applications with  --Wl,subsystem,windows is easy, but
> >with the fork-exec problems, how do you spawn a child process ?
> >The system command works, but it triggers the pop-up window, I assume
> >there would have to be a windows version of bash built, since those
> >commands are run from a shell ...
> 
> Well, actualy I´m not trying to solve those caveats.I use gnu-win32 to develop
> Windows applications, and by itself its very dificult. In my humble opinion, in
> the
> state-of-the-art of the projet, you can develop UNIX-like programs or
> WIN32 programs, but convining both...
> 
> Ismael Jurado <ismaelj@hotmail.com>
> 
> ---------------------------------------------------------
> Get Your *Web-Based* Free Email at http://www.hotmail.com
> ---------------------------------------------------------
> 

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

Re: Stupid stupid question :/

[Ismael Jurado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

>Linking applications with  --Wl,subsystem,windows is easy, but
>with the fork-exec problems, how do you spawn a child process ?
>The system command works, but it triggers the pop-up window, I assume
>there would have to be a windows version of bash built, since those
>commands are run from a shell ...

Well, actualy I´m not trying to solve those caveats.I use gnu-win32 to develop
Windows applications, and by itself its very dificult. In my humble opinion, in
the
state-of-the-art of the projet, you can develop UNIX-like programs or
WIN32 programs, but convining both...

Ismael Jurado <ismaelj@hotmail.com>

---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Stupid stupid question :/

[Geoffrey Noer]

[...]
> b)If you don't want (and who would?) a console window to appear whit your
> windows program you have to include the option --subsystem windows (not
> --ssubsystem windows).
[...]

Thanks.  I fixed the FAQ in development sources and the WWW site.

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

Re: Stupid stupid question :/

[A. Phillip Smith]

Linking applications with  --Wl,subsystem,windows is easy, but
with the fork-exec problems, how do you spawn a child process ?
The system command works, but it triggers the pop-up window, I assume
there would have to be a windows version of bash built, since those
commands are run from a shell ...

CreateProcess does not seem to work from within a gnu-win32 application.
It compiles/links, but the program dies silently on execution. Any other
ideas ?

Phil Smith

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

Re: Stupid stupid question :/

[Ismael Jurado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

>I'm having problems compiling Win95 gui apps with 17.1. In the faq they
>mention using the -ssubsystem windows option to gcc OR ld, but when I do
>so I get an "invalid option" and "no such file or directory: windows"

To compile a program for the windows subsystem, you have to do only two things:

a) include the libraries you will use in the command line. The common windows
stuff is included in KERNEL32.DLL, USER32.DLL and GDI32.DLL, wich are
automaticaly included with the -mwindows option Other libraries, such advapi or
tapi must be in the command line explicitely.

b)If you don't want (and who would?) a console window to appear whit your
windows program you have to include the option --subsystem windows (not
--ssubsystem windows).

and that´s all.

ismaelj@hotmail.com


---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Stupid stupid question :/

[Colin Peters]

Chris Wall[SMTP:vergil@midusa.net] wrote:
>I'm having problems compiling Win95 gui apps with 17.1. In the faq they
>mention using the -ssubsystem windows option to gcc OR ld, but when I do
>so I get an "invalid option" and "no such file or directory: windows"
>error. There was another part of the mailing list archives/faq (don't
>remember which) that mentioned using a -mwindows switch - which didn't
>work for me either.
>
>The compiler goes on its merry way, and comes to a few functions that
>it's totally confused by, but I am hoping that this is because of the
>lib/target problem I'm having - the program isn't my source, it's a
>cheezy example program with (unfortunately) a MSVC mak file. 

I think (confirmations anyone?) that the "-ssubsystem windows" bit in
the readme is a typo. It should be "--subsystem windows". An easy way
to do this (and not have to fool around too much) is to use gcc to
do your link step with a command line like this:

  gcc -o myexe.exe myexe.o foo.o bar.o -luser32 -Wl,--subsystem,windows

The last bit is the important part.

NOTE: You will, I think, get a "Cannot find entry point _WinMainCRTStartup"
warning or something similar. This should be harmless.

-- Colin Peters - colin@bird.fu.is.saga-u.ac.jp
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

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