WinMain Cannot be Overloaded

Surely that won’t work unless windows.h has been included? That was the whole point of me using the void*s…

Alright, Jules, and TheVinn; I think I got the proper setup for all scenarios on Windows;

//==============================================================================
/*
    To start a JUCE app, use this macro: START_JUCE_APPLICATION (AppSubClass) where
    AppSubClass is the name of a class derived from JUCEApplication.

    See the JUCEApplication class documentation (juce_Application.h) for more details.

*/
#if JUCE_ANDROID
    #define START_JUCE_APPLICATION(AppClass) \
        juce::JUCEApplication* juce_CreateApplication() { return new AppClass(); }

#else
    #if JUCE_WINDOWS
        #if defined(_WINDOWS_) //Windows header include guard. Windows.h was included in user code somewhere...
            #if defined(_UNICODE)
                #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (void*, void*, const wchar_t*, int)
            #elif defined(WINAPI)
                #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (HINSTANCE, HINSTANCE, const LPTSTR, int)
            #else
                #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (HINSTANCE, HINSTANCE, const LPSTR, int)
            #endif
        #else
            #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (void*, void*, const char*, int)
        #endif

        #define  JUCE_MAIN_FUNCTION_ARGS

    #else
        #define  JUCE_MAIN_FUNCTION       int main (int argc, char* argv[])
        #define  JUCE_MAIN_FUNCTION_ARGS  argc, (const char**) argv
    #endif

    #define START_JUCE_APPLICATION(AppClass) \
        static juce::JUCEApplicationBase* juce_CreateApplication() { return new AppClass(); } \
        JUCE_MAIN_FUNCTION \
        { \
            juce::JUCEApplication::createInstance = &juce_CreateApplication; \
            return juce::JUCEApplication::main (JUCE_MAIN_FUNCTION_ARGS); \
        }
#endif

Yeah, that section of code was only for when windows.h was included, as I indicated: “Here’s what I have, which works for me for every case that <windows.h> is included…”

Hmm… Close. How about simplifying it to:

#if JUCE_WINDOWS #if defined (WINAPI) || defined (_WINDOWS_) #define JUCE_MAIN_FUNCTION int __stdcall WinMain (HINSTANCE, HINSTANCE, const LPTSTR, int) #elif defined (_UNICODE) #define JUCE_MAIN_FUNCTION int __stdcall WinMain (void*, void*, const wchar_t*, int) #elif #define JUCE_MAIN_FUNCTION int __stdcall WinMain (void*, void*, const char*, int) #endif

I was going to suggest exactly that

Dohh! Right; yes, that works. Must be time for a coffee…

Oops!

There appears to be a typo in the WinMain fix.

[code] #if JUCE_WINDOWS
#if defined (WINAPI) || defined (WINDOWS)
#define JUCE_MAIN_FUNCTION int __stdcall WinMain (HINSTANCE, HINSTANCE, const LPTSTR, int)
#elif defined (_UNICODE)
#define JUCE_MAIN_FUNCTION int __stdcall WinMain (void*, void*, const wchar_t*, int)

// currently says #elif in the tip
#else

#define JUCE_MAIN_FUNCTION       int __stdcall WinMain (void*, void*, const char*, int)

#endif
#define JUCE_MAIN_FUNCTION_ARGS
#else
#define JUCE_MAIN_FUNCTION int main (int argc, char* argv[])

[/code]

Goldarn it! Thankyou!

How has JUCE been around for almost a decade and this still hasn’t been straightened out???

Ahh damn! This code works fine in my project because of the setup I had where windows.h is included multiple times because of 3rd party libs, once before JuceHeader.h (which makes juce_initialization.h select the proper WinMain), and however many times post-JuceHeader.h (within the 3rd party libs).

Basically, I just figured out that JuceHeader.h (or specifically, juce_Initialization.h) needs a way to know if windows.h is being included after JuceHeader.h… If there was an internal JUCE way of letting users #include <windows.h> if they want, and have such happen before juce_Initialization.h, any JUCE project will be golden (thanks to include guards).

That would be a mess, but how about if Jules gave you access to the three forms of JUCE_START_APPLICATION? Like this:

#define JUCE_START_APPLICATION_LPTSTR ...
#define JUCE_START_APPLICATION_CHAR ...
#define JUCE_START_APPLICATION_WCHAR_T ...

Then instead of using JUCE_START_APPLICATION you could pick one of those three. And juce_Initialisation.h would #define JUCE_START_APPLICATION to one of those three based on preprocessor directives.

That would mean the JUCE user needs to setup a way of selecting the right one when/if necessary… unless there would be something pre-done for that too, in JUCE, which basically comes back to my suggestion.

What I think would be better is a flag/macro for letting a JUCE user include windows.h, and the inclusion would occur if possible, and just before juce_Initialisation.h is setup (perhaps in the internal juce_gui_basics.h, where juce_Initialisation.h is included?). It would be somewhat messy, but it would solve the issue for good, and not leave it up to the user to figure it out.

Can’t you just include Windows.h before any JUCE headers and be done with it?

I guess… but it would just be a preventive measure in case someone happens to include windows.h post a Juce_Header.h include. That’s all…

So…can somebody please summarize the fix please…It’s april 2013, I think I’m using the new juce (just cloned onto xp box) and this issue is nailing me, and after reading/scanning the previous postings I’m still lost…

What combination of multibyte/unicode with or without windows.h in what order - will ERADICATE this problem?

Frustrated…
Thanks,
Kurt

In short, the inclusion order matters;

#include <windows.h>
#include "JuceHeader.h"

If you’re including windows.h in your project’s headers, and intermixing it with JuceHeader.h, you’re bound to run into these problems. I suggest having a custom master include header file, including platform specific headers first, then JUCE.

Thank you, and this is a horrible condition as the instant you include boost system & thread you’re trashed. I had to manually add WinMain, couldn’t use the macro, had to fight headers. yuk.

August 2014 and still the same problem.

Windows, Visual Studio 2013 and Boost (Ogre)


I am implementing some 3D Engine Components and today started with the one for the OgreEngine, which internally uses Boost.

If the <Ogre.h> is only included within my component, compilation fails with the well known error:

1>..\..\Source\Main.cpp(68): error C2733: 'WinMain' : second C linkage of overloaded function not allowed
1>          C:\Program Files (x86)\Windows Kits\8.1\Include\um\winbase.h(905) : see declaration of 'WinMain'

WinMain (
    _In_ HINSTANCE hInstance,
    _In_opt_ HINSTANCE hPrevInstance,
    _In_ LPSTR lpCmdLine,
    _In_ int nShowCmd
    );

If i additionally include it in the main.cpp before the JuceHeader.h:

#include <Ogre.h>
#include <JuceHeader.h>

We instead get the following errors:

(...) jucelibrarycode\modules\juce_core\containers/juce_HashMap.h(452): error C2976: 'std::unordered_map' : too few template arguments (..\..\Source\Main.cpp)

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\unordered_map(79) : see declaration of 'std::unordered_map'

(...) jucelibrarycode\modules\juce_core\containers/juce_HashMap.h(452): fatal error C1903: unable to recover from previous error(s); stopping compilation (..\..\Source\Main.cpp)

Is there any possibility to get a 'clean' fix for this?

Your grumpy title is a bit misplaced because this doesn't look like the same problem to me!

I don't have a Windows build to hand for testing, but is it just because of the const in the juce winmain declaration? - e.g. removing the const like this:

   #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (HINSTANCE, HINSTANCE, LPSTR, int)

..would make it match the other declaration.

God knows what the second problem is - nowhere in juce uses an unordered_map, and line 452 of juce_HashMap.h is the end of the file, so there must be something in the boost/Ogre code that's #defining a symbol which is messing up juce. Not exactly my fault, but I'd be happy to add a workaround if you can track down what they're doing that's causing trouble.

Sry for the grumpy title.

Actually i am quite confused by that preprocessor logic going on there and when i found this thread the errors seemed to be identical for me.

1>..\..\Source\Main.cpp(68): error C2731: 'WinMain' : function cannot be overloaded
1>          ..\..\Source\Main.cpp(68) : see declaration of 'WinMain'
1>..\..\Source\Main.cpp(68): error C2733: 'WinMain' : second C linkage of overloaded function not allowed
1>          C:\Program Files (x86)\Windows Kits\8.1\Include\um\winbase.h(905) : see declaration of 'WinMain'

The bad news is that removing the const did not fix the problem.

To make sure its actually using the correct definition i added some #error directives:

  #if defined (WINAPI) || defined (_WINDOWS_)
   #error "WINAPI || _WINDOWS_"
   #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (HINSTANCE, HINSTANCE, const LPSTR, int)
  #elif defined (_UNICODE)
   #error "_UNICODE"
   #define JUCE_MAIN_FUNCTION       int __stdcall WinMain (void*, void*, const wchar_t*, int)

I noticed that its using the _UNICODE definition for the first half of files compiled and then switches to the WINAPI definition.

If i understand this correctly the relevant output is the following:

Error    30    error C1189: #error :  "_UNICODE" (..\..\Source\Main.cpp)

In the Main.cpp file where the START_JUCE_APPLICATION macro is actually used, it has chosen the wrong path of the juce_Initialization.h, what actually makes sense (???) as the Ogre.h is only included down the hierarchy where it is needed.

The question is... what is the best/cleanest way to cope with this?

EDIT:

Without a clue what these WINAPI and _WINDOWS_ definitions are actually used for i tested what happens when these are added as preprocessor definitions in the compilers command line.

_WINDOWS_ => 1285 errors

WINAPI => works, but some warnings about redeclaration in the juce sources

I am not sure whether this should be considered a 'clean' solution...