#177 WinMain all parameters are NULL

closed-wont-fix
nobody
crt (85)
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

  • Henry N.

    Henry N. - 2010-06-20

    WinMain with MessageBox to view arguments

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

     
  • Nobody/Anonymous

    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.

     
  • Sven Köhler

    Sven Köhler - 2010-07-10

    The reason given for closing this bug is unacceptable. The bug originally was about the fact that WinMain is broken in case of -mconsole. This has nothing to do with whether you like to support main/wmain in case of -mwindows.

     
  • Kai Tietz

    Kai Tietz - 2010-07-10

    As we talked on IRC. It is a bug that a user assumes to have a working WinMain in a console application (what ever mingw.org behaves here).

    So this bug will be closed. As we talked on IRC, too. Please open a feature request for this in our tracker. Additionally it would be nice, if you could test the suggested solution I gave. If it works for in general, I'll apply this patch.

    Kai

    PS: Indeed our startup-code omits for -mconsole to initialize the WinMain arguments variables.

     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • SourceForge Robot

    • status: pending-wont-fix --> closed-wont-fix
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks