#177 WinMain all parameters are NULL

closed-wont-fix
nobody
crt (84)
5
2014-08-18
2010-06-19
Henry N.
No

If I build a tiny program with WinMain, all parameters are NULL under 64 bit.
The same source compiled for 32 bit works.

Maybe some gcc flags missed?

Have a small C-example:
>>> Cut cȟeck.c >>>
#include <windows.h>
#include <stdio.h>

int CALLBACK WinMain(IN HINSTANCE hInstance, IN HINSTANCE hPrevInstance, IN LPSTR lpCmdLine, IN int nCmdShow)
{
printf("hInstance: 0x%p\n", hInstance);
printf("hPrevInstance: 0x%p\n", hPrevInstance);
printf("lpCmdLine: 0x%p '%s'\n", lpCmdLine, lpCmdLine);
printf("nCmdShow: 0x%x\n", nCmdShow);
return 0;
}
<<< end cut <<<

Build with mingw-w64-bin_x86_64-linux_20100604_sezero:
x86_64-w64-mingw32-gcc -Wall -o cȟeck64.exe cȟeck.c

Output on Windows 7 64 bit:
C:\&gt;check64.exe test
hInstance: 0x0000000000000000
hPrevInstance: 0x0000000000000000
lpCmdLine: 0x0000000000000000 '(null)'
nCmdShow: 0x0

Build for 32 bit:
i686-pc-mingw32-gcc -Wall -o check32.exe check.c

Output the 32 bit build under Windows 7 64 bit:
C:\&gt;check32.exe test
hInstance: 0x00400000
hPrevInstance: 0x00000000
lpCmdLine: 0x004C29B5 'test'
nCmdShow: 0xa

With or without "CALLBACK" or "IN" does no matter. The used prototype is the default from MSDN.
In assembler have seen, that parameters from WinMain gets from Stack (not from registers). Is this right?

Discussion

1 2 > >> (Page 1 of 2)
  • Henry N.
    Henry N.
    2010-06-20

    WinMain with MessageBox to view arguments

     
    Attachments
  • Henry N.
    Henry N.
    2010-06-20

    In a GUI program with GCC option "-mwindows" the arguments are ok.
    Without "-mwindows" the arguments all are NULL.

    Build the example "HelloWorldBox.c" with and without "-mwindows" to see the difference.

     
  • Doug Semler
    Doug Semler
    2010-06-20

    Yes. This is due to the fact that console applications do not call GetStartupInfo, nor do console applications set up the command line options from the CRT. In mingw-crt this is the biggest difference, aside from telling the linker to set up the executable to be a WinApp and not to create a console.

    Windows Apps == WinMain == no console (no printf).
    Console Apps = main == default == console.

    Maybe we should force a link error for mismatch between -mconsole/-mwindows and main/WinMain? I don't recall offhand the behavior of MSVC.

     
  • Sven Köhler
    Sven Köhler
    2010-07-06

    WinMain parameters are NULL with -mconsole (tested only 32Bit toolchain).

    WinMain should work, even for console programs.
    Using main() is not always acceptable. it's arguments differ from WinMain. Before main() is called, the command line is parsed into chunks which are passed to main as argc and argv[]. In addition, the other 3 parameter of WinMain are not available to main().

    In addition, WinMain works fine using original mingw32.

     
  • Ozkan Sezer
    Ozkan Sezer
    2010-07-06

    Some points I'd like to learn ...

    > WinMain should work, even for console programs.
    > Using main() is not always acceptable.

    Out of curiosity, why? Can you give some examples where
    only WinMain can work correctly and main can not, even
    by additional use of windows functions?

    > it's arguments differ from WinMain.
    > Before main() is called, the command line is parsed
    > into chunks which are passed to main as argc and argv[].
    > In addition, the other 3 parameter of WinMain are
    > not available to main().
    >
    > In addition, WinMain works fine using original mingw32.

    Original mingw does not define windows api, M$ does.
    Is the behavior you are requestion also supported by the
    M$ compiler and/or documented by M$?

     
  • Doug Semler
    Doug Semler
    2010-07-07

    I just verified the behavior of the MS linker:

    /SUBSYSTEM:CONSOLE --- If main/wmain undefined (e.g. using WinMain/wWinMain) a link error occurs.
    /SUBSYSTEM:WINDOWS --- If WinMain/wWinMain undefined (e.g. using main/wmain), a link error occurs
    no /SUBSYSTEM flag --- Linker choses whatever it finds, and sets things appropriately.

    We default to -mconsole, and currently *require* -mwindows in order to set up the command line properly for WinMain *AND* set the executable type properly (IIRC). It may be possible to pass the command line information through to WinMain (via our main that gets linked when no main defined by the user), but I haven't checked (other information such as HINSTANCE and the show parameter should be fine). We are not the MS linker, but are subject to the code/limitations of the GNU linker.

    HOWEVER, I am of the opinion that we should *not* provide default main/wmain functions that call WinMain, and let the linker error out with undefined symbols when main is provided in a -mwindows program and WinMain for an -mconsole program. One of the issues that I believe we have is that the linker (as far as I recall) is unaware of the link type differences --- I am unsure whether ld will set the executable type correctly for the windows subsystem unless the -mwindows flag is passed. (i.e. The linker linking against WinMain doesn't autotmatically set the executable to be /SUBSYSTEM:WINDOWS IIRC).

     
  • Henry N.
    Henry N.
    2010-07-07

    In my opinion linker errors are better as current NULL-pointers in running programs.
    It is ok, that I must set the subsystem correctly. mconsole as default is also welcome.

    M$ says, that WinMain is only for GUI applications. So, it is ok to not work without -mwindows in our gcc.

     
  • I agree, with making the linker fail. But make the behaviour consistent with MS linker, that is:

    - fail if -mconsole and main/wmain undefined
    - fail if -mwindows and WinMain/wWinMain undefined

    Currently, the main works with -mwindows and WinMain works with -mconsole.

     
  • Kai Tietz
    Kai Tietz
    2010-07-10

    • status: open --> pending-wont-fix
     
  • Kai Tietz
    Kai Tietz
    2010-07-10

    As it is common in some open-source project to use even for -mwindows the entry main/wmain, this is an issue to be documented in our Wiki, but shouldn't be fixed.

    Therefore I close this bug.

     
1 2 > >> (Page 1 of 2)