Re: Possible Code to make Visual Studio compile easier

[Tor Lillqvist <tml iki fi>]

Didn't I tell you to use the mailing list, and not send me private
mail?

> for one this magic thing your talking about is not 100% true. i do
> know about that one bit in the header of the exe that make windows
> consider a exe a console app or a gui app.

> but there is still a difference in what is passed to the main function.

Umm, is there? Have you, like, verified this empirically?

Take this very trivial program, m.c:

#include <windows.h>
int main (int argc, char **argv)
{
  MessageBox (NULL, argv[1], argv[0], MB_OK);
  return 0;
}

Compile it, producing a console app m.exe:

C:\src>cl -MD m.c user32.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

m.c
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:m.exe
m.obj
user32.lib

Verify that it is a console ("CUI") app:

C:\src>dumpbin -headers m.exe |findstr subsystem
            4.00 subsystem version
               3 subsystem (Windows CUI)

Run it from the command line, with some command-line parameter(s). The
MessageBox shows the argv[0] as title and argv[1] as the message.

Now turn it into a windowing ("GUI") app:

C:\src>editbin -subsystem:windows m.exe
Microsoft (R) COFF/PE Editor Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

Verify this:

C:\src>dumpbin -headers m.exe |findstr subsystem
            4.00 subsystem version
               2 subsystem (Windows GUI)

Again, run it with some command-line parameter(s). Notice any
difference in behaviour? Does it still display the same argv[0] and
argv[1] in the message box?

You can also create a shortcut in Explorer to m.exe, and add
command-line parameters there. They too get passed to main() in the
same way regardless whether m.exe is marked as a console or windowing
executable.

> yes that stupid trigger dictates what is getting sent to entry function

When you say "entry function", do you mean the C level entry function
(main() or WinMain()), or the real entry function where the executable
actually begins its execution? I hope you aren't confusing the two
concepts. The real entry function of an exectuable written in C (or
C++) on Windows is a routine statically linked in from the C library,
which then calls the programmer-written main() or WinMain().

If you are setting the executable's entry function in the Visual
Studio IDE (which eventually ends up being passed to the linker as
/ENTRY) to main or WinMain, you lose badly. Then the C library will
not be initialized properly. Don't touch that unless you know exactly
what you are doing.

> but it does not dictate how local memory allocation for the entry
> fucntion is allocated when the program starts.  since at the ASM
> level any pointer or anything that is 4byte big that needs to be
> passed is a dword you could just change that gui trigger to console
> and it would not cause a stack problem.

> but if you where to change a console app to a gui app via that trigger
> you could have stack problems.

I do not understand what you talk about here.

> and no do you think anything that microsoft sends to anyone or any books
> that are not about Reverse engineering would cover something like that.

"to anyone"? No, but perhaps their customers who buy their products
get some kind of documentation. Not physical books, but on the CD?
Lots of documentation is also online.

> also there is the problem with the gnu compiler where is does not handle
> dll entry points correctly so that is the main reson why i wont use it
> for this type of project im using.

Please tell me more. I have used the GNU compiler successfully for a
long time on Windows. I have built DLLs with DllMain() functions
without problem with it.

> so i figured after looking around and seeing that people had some
> questions on how to do it and i figured a way out to just add a cpp file
> along with the sample projects along with others that make it compile
> correctly that it might be of interest but i guess not.

> oh and yes the code is 100% compatible with the visual studios compiler
> even when compiled as c++.

--tml