wWinMain entry point warning
Pages: 12
By Golly!, That Did It George!
From the 'Compiler Options' Property Page of Dev-C++ is a link to all the options....
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
...and at the very bottom next to -mwindows is the -municode. I should have picked up on that. Somehow or other I just never did. Drowned in too much info I guess!
I recall years and years ago I had a major Microsoft eMbeddeded Visual C++ 4.0 project (ran on handheld data collectors running Windows CE) that I converted to a desktop Windows app, and it had quite a few #ifdef conditionals that keyed off of something like a ...
#define GCC
...where I used WinMain() for GCC builds and wWinMain for everything else, i.e., eMbedded C++ 4, MSVC and so on.
Everybody seems to bad mouth mingw for poor wide character support, poor COM support, and so on, but honestly, I've never had many complaints. The only problem I ever had with it was years and years ago when I was teaching myself COM I couldn't seem to manage to build COM components with mingw. It's not a topic many know much about. I asked here as well as on other C++ sites, and couldn't get much help. I eventually gave up on it and just used MS tools to build COM components. But if I had an already built COM component, I could use mingw to utilize it no problem at all. In fact, just the other day I dusted off an ActiveX Grid Control I built from scratch (no ATL) using VC15, and GCC Mingw clients use it no problem - and that's pure wide character and COM.
Only issue seemed to be couldn't use wWinMain entry point, although rest of app used UNICODE. I guess, ultimately, the only UNICODE glitch would be that if one wanted a GUI app that utilized a command line string, one would have to deal with an ansi string coming into an app the rest of which was using wide character strings.
From the 'Compiler Options' Property Page of Dev-C++ is a link to all the options....
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
...and at the very bottom next to -mwindows is the -municode. I should have picked up on that. Somehow or other I just never did. Drowned in too much info I guess!
I recall years and years ago I had a major Microsoft eMbeddeded Visual C++ 4.0 project (ran on handheld data collectors running Windows CE) that I converted to a desktop Windows app, and it had quite a few #ifdef conditionals that keyed off of something like a ...
#define GCC
...where I used WinMain() for GCC builds and wWinMain for everything else, i.e., eMbedded C++ 4, MSVC and so on.
Everybody seems to bad mouth mingw for poor wide character support, poor COM support, and so on, but honestly, I've never had many complaints. The only problem I ever had with it was years and years ago when I was teaching myself COM I couldn't seem to manage to build COM components with mingw. It's not a topic many know much about. I asked here as well as on other C++ sites, and couldn't get much help. I eventually gave up on it and just used MS tools to build COM components. But if I had an already built COM component, I could use mingw to utilize it no problem at all. In fact, just the other day I dusted off an ActiveX Grid Control I built from scratch (no ATL) using VC15, and GCC Mingw clients use it no problem - and that's pure wide character and COM.
Only issue seemed to be couldn't use wWinMain entry point, although rest of app used UNICODE. I guess, ultimately, the only UNICODE glitch would be that if one wanted a GUI app that utilized a command line string, one would have to deal with an ansi string coming into an app the rest of which was using wide character strings.
Add -muincode to a console project in E Dev-C++ and GCC does bomb out when compiling. As expected.
Dev-C++ is a thin GUI interface over a command-line build system, it generates a makefile.
Maybe it is time to get over my disdain for command-line builds and muck around with makefiles and such.
It's similar to my experience with std::sample here: http://www.cplusplus.com/forum/general/281518/#msg1218318
I've looked at <algorithm> countless times, and never really noticed that entry. TMI fer shure!
Dev-C++ is a thin GUI interface over a command-line build system, it generates a makefile.
Maybe it is time to get over my disdain for command-line builds and muck around with makefiles and such.
| freddie1 wrote: |
|---|
| I should have picked up on that. Somehow or other I just never did. Drowned in too much info I guess! |
It's similar to my experience with std::sample here: http://www.cplusplus.com/forum/general/281518/#msg1218318
I've looked at <algorithm> countless times, and never really noticed that entry. TMI fer shure!
About the hardest part of command line building is using the console Change Directory (CD) and PATH commands. What I do to use TDM-GCC-64, is create a project directory somewhere or other where I want to keep my source code, and open a command prompt window, i.e., execute Cmd.exe in C:\Windows\System32. It opens up of course to...
C:\Windows\System32:>
Then I CD back to root...
CD\ [ENTER]
Then change directory to where I put my source code - let's say, for example....
CD C:\Code\Mingw\Hello [ENTER]
Then execute PATH command so gcc 'build chain' can be found from command prompt. The TDM-GCC-64 on this laptop came with an Embarcadero Bloodshed C++ installation, so for me it's here....
C:\Program Files (x86)\Embarcadero\Dev-Cpp\TDM-GCC-64
...and under that in a \bin subdirectory are the various binaries comprising the build chain. So at my console prompt in my code directory I execute this...
Set Path=C:\Program Files (x86)\Embarcadero\Dev-Cpp\TDM-GCC-64\bin
You can just type PATH [ENTER] after doing that to make sure it all 'took'.
If by chance you have a TDM-GCC installation (stand alone not part of IDE install), when the installer runs it asks whether or not you want the build chain added to your PATH environment variables, and if that's the case you don't need to manually set the path as I've described above.
Anyway, here's a Hello World test program and my command line string using g++...
The -s switch strips debug symbols from executable, and -Os optimizes for code size.
C:\Windows\System32:>
Then I CD back to root...
CD\ [ENTER]
Then change directory to where I put my source code - let's say, for example....
CD C:\Code\Mingw\Hello [ENTER]
Then execute PATH command so gcc 'build chain' can be found from command prompt. The TDM-GCC-64 on this laptop came with an Embarcadero Bloodshed C++ installation, so for me it's here....
C:\Program Files (x86)\Embarcadero\Dev-Cpp\TDM-GCC-64
...and under that in a \bin subdirectory are the various binaries comprising the build chain. So at my console prompt in my code directory I execute this...
Set Path=C:\Program Files (x86)\Embarcadero\Dev-Cpp\TDM-GCC-64\bin
You can just type PATH [ENTER] after doing that to make sure it all 'took'.
If by chance you have a TDM-GCC installation (stand alone not part of IDE install), when the installer runs it asks whether or not you want the build chain added to your PATH environment variables, and if that's the case you don't need to manually set the path as I've described above.
Anyway, here's a Hello World test program and my command line string using g++...
|
|
The -s switch strips debug symbols from executable, and -Os optimizes for code size.
It's actually a lot easier with VStudio. Microsoft puts shortcuts on the Visual Studio Start menu that one can execute, and that runs vcvarsall.bat and sets up the paths automagically. Actually, there's a whole pile of shortcuts - some of which are slightly ridiculous, and for first time users might (almost ceratainly are) confusing. For example, there's a shortcut to use the x86 build chain to create x64 binaries. Another to use x64 build chain to create x86 binaries! Then an x86 build chain to create x86 binaries, and an x64 build chain to create x64 binaries. What's missing is a shortcut to use 16 bit build chain to create 32 bit and 64 bit binaries! :)
I installed MSYS2 with the express purpose of doing command-line stuff. So far I've compiled a C++ "Hello World" example and a Fortran one. whee. :|
Doing command-line wouldn't be so hard to do if I spent time actually mucking around with make files, including CMake.
I know I should do this, but keep putting it off for *gasp* real life things.
Doing command-line wouldn't be so hard to do if I spent time actually mucking around with make files, including CMake.
I know I should do this, but keep putting it off for *gasp* real life things.
I don't use make files much. Seems *nix folks are especially big on them. I mostly use g++ from GCC and cl and link from MSVC to build binaries. I do use a make file (nmake.exe is Microsoft's version on Make) for building my TCLib, which is a replacement for the Microsoft C/C++ Runtime.
I generally just keep my command line string remmed out at the top of my main *.cpp source file, and I paste it in the command prompt window when I want to build. That works good for relatively simple apps that don't have long and complicated command line strings, i.e., a lot of *.cpp files, a lot of switches, a lot of libraries needing to be linked, etc. In cases where that isn't the case, that is, major projects with large command line strings that might stretch out for hundreds of characters, I use what seems to be called a 'response file'. So, instead of pasting the command line string at the command prompt, one types in...
cl @ResponseFile.txt
...where Response File is a text file containing the command line build string. What's neat about it is one can use multiple lines to organize all the nasty, evil looking stuff in a more or less intelligible mess. Here's an example response file from a major project from my previous work life for one of my C++ apps. I named it TB.txt....
This works for GCC's g++ too. So one would type this to build TimberBeast.exe
cl @TB.txt
Pretty easy. By the way, for Microsoft's cl, to get a listing of all the switches, just type....
cl /?
...at the prompt. I believe that works for all MS's command line tools, e.g., link.exe, rc.exe, cvtres.exe, midl.exe, etc.
I generally just keep my command line string remmed out at the top of my main *.cpp source file, and I paste it in the command prompt window when I want to build. That works good for relatively simple apps that don't have long and complicated command line strings, i.e., a lot of *.cpp files, a lot of switches, a lot of libraries needing to be linked, etc. In cases where that isn't the case, that is, major projects with large command line strings that might stretch out for hundreds of characters, I use what seems to be called a 'response file'. So, instead of pasting the command line string at the command prompt, one types in...
cl @ResponseFile.txt
...where Response File is a text file containing the command line build string. What's neat about it is one can use multiple lines to organize all the nasty, evil looking stuff in a more or less intelligible mess. Here's an example response file from a major project from my previous work life for one of my C++ apps. I named it TB.txt....
|
|
This works for GCC's g++ too. So one would type this to build TimberBeast.exe
cl @TB.txt
Pretty easy. By the way, for Microsoft's cl, to get a listing of all the switches, just type....
cl /?
...at the prompt. I believe that works for all MS's command line tools, e.g., link.exe, rc.exe, cvtres.exe, midl.exe, etc.
Topic archived. No new replies allowed.
Pages: 12