unicode and WinMain compiling error

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

unicode and WinMain compiling error

Thomas Steinbach
Hello,

I have a application which compiles with mingw gcc as a non unicode
version and all seems to be fine and working.

But if I try to compile it with the mingw gcc as a unicode version I get the
errror

C:/mingw3/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference
to `WinMain@16'
collect2: ld returned 1 exit status
make: *** [bin/test.exe] Error 1

btw: with VS (cl.exe version 15.x) I can compile as non unicode and
as unicode without any errors. And it's working fine.

What is the problem. I can't figure it out by myself.

The WinMain is implemented as follows:

#ifdef UNIVER
int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPWSTR szCmdLine,
int iCmdShow)
#else
int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR szCmdLine,
int iCmdShow)
#endif
{
    [...]

and if I compile with mingw I use -D "UNIVER" within/from the makefile in
CFLAGS

Does anybody knows this problem or does anybody have a hint and tips how
to solve that?

Thomas


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

JonY-2
On 6/14/2009 03:50, Thomas Steinbach wrote:

> Hello,
>
> I have a application which compiles with mingw gcc as a non unicode
> version and all seems to be fine and working.
>
> But if I try to compile it with the mingw gcc as a unicode version I get the
> errror
>
> C:/mingw3/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference
> to `WinMain@16'
> collect2: ld returned 1 exit status
> make: *** [bin/test.exe] Error 1
>
> btw: with VS (cl.exe version 15.x) I can compile as non unicode and
> as unicode without any errors. And it's working fine.
>
> What is the problem. I can't figure it out by myself.
>
> The WinMain is implemented as follows:
>
> #ifdef UNIVER
> int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPWSTR szCmdLine,
> int iCmdShow)
> #else
> int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR szCmdLine,
> int iCmdShow)
> #endif
> {
>      [...]
>
> and if I compile with mingw I use -D "UNIVER" within/from the makefile in
> CFLAGS
>
> Does anybody knows this problem or does anybody have a hint and tips how
> to solve that?
>
> Thomas
>

Hi,
iirc, mingw.org provided gcc doesn't support wide startup.

I suggest giving mingw-w64 gcc and crt a try. Unicode support has just
been added.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Tor Lillqvist
In reply to this post by Thomas Steinbach
> I have a application which compiles with mingw gcc as a non unicode
> version and all seems to be fine and working.

If WinMain is the only problem you have, you will be glad to know that
you can write a fully working "Unicode" application also with a
main(). Just fetch the command line using the wide character API and
parse it into a wide character string array. I.e.:

wchar_t **wargv = CommandLineToArgvW(GetCommandLineW(), &argc);

But in general the concept that one should build one's application as
separate "non-Unicode" and "Unicode" versions is quite obsolete. (If
you really have to support Win9x, then OK, but I feel sorry for you.)

IMHO, in a newly written (or actively maintained) application, there
is no need to keep using those extremely ugly historical conventions
from the <tchar.h> header. All that TCHAR and TEXT crap deserves to
die. Just use wchar_t strings, wide character literals (L"like this"),
wcs*() functions, and the W version of the Windows API explicitly,
etc, as appropriate, and your application will be a "Unicode" one.

--tml

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Thomas Steinbach
In reply to this post by JonY-2
Hello Jon,

>> [...]
>> Does anybody knows this problem or does anybody have a hint and tips how
>> to solve that?

> Hi,
> iirc, mingw.org provided gcc doesn't support wide startup.
>
> I suggest giving mingw-w64 gcc and crt a try. Unicode support has just
> been added.

Then it's only compiling and working on a 64 bit computer
and I have a 32 bit computer. ;-)

btw: I think the nesseccary of 64 bit computers is made by the marketing
departements of Intel, AMD and other computer manufacturers who
wants to sell new computers/processors, because there is no need
for 64 bit, in no case. It's only overhead and slows down the code.

Thomas


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Thomas Steinbach
In reply to this post by Tor Lillqvist
Hello Tor,

>> [...]
> If WinMain is the only problem you have, you will be glad to know that
> you can write a fully working "Unicode" application also with a
> main(). Just fetch the command line using the wide character API and
> parse it into a wide character string array. I.e.:
>
> wchar_t **wargv = CommandLineToArgvW(GetCommandLineW(), &argc);

Yes, WinMain is the only problem. And I can't compile it as
a UNICODE version (all other code are coded for UNICODE)
(can successfull build with VC)

Anyway. I even can't compile as a UNICODE version if I just code
the standard _tWinMain entry point

int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR szCmdLine,
int iCmdShow)
I get the error described in my first mail.

main.c:(.text+0x104): undefined reference to `WinMain@16

Is mingw gcc not able to compile a windwos app as unicode?
Or only with L"x" macro and the wcs* functions, but not with the
_T("x") macro and _tcs* functions`? I don't understand that and
it confuses me.

> But in general the concept that one should build one's application as
> separate "non-Unicode" and "Unicode" versions is quite obsolete. (If
> you really have to support Win9x, then OK, but I feel sorry for you.)

No, it's not importent, but if It works it would be fine. :-)

> IMHO, in a newly written (or actively maintained) application, there
> is no need to keep using those extremely ugly historical conventions
> from the <tchar.h> header. All that TCHAR and TEXT crap deserves to
> die. Just use wchar_t strings, wide character literals (L"like this"),
> wcs*() functions, and the W version of the Windows API explicitly,
> etc, as appropriate, and your application will be a "Unicode" one.

ok, but now it is all coded with _T("x"), etc. and should compile as
unicode. Or is this _T(") and _tcs* style not suported by mingw gcc?
Do I _have_ to code with L"string" and with the wcs* or *W functions?
I thought the only problem ist the WinMain entry point...

Do you have a small example windows GUI app which is implemented
with a "normal" main() entry point, what you mentioned above and which
shows this "main()" technic for a windows GUI app?
I can't follow in this way, because I'm not very experienced in programming.

Thomas



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

JonY-2
In reply to this post by Thomas Steinbach
On 6/15/2009 01:35, Thomas Steinbach wrote:

> Hello Jon,
>
>>> [...]
>>> Does anybody knows this problem or does anybody have a hint and tips how
>>> to solve that?
>
>> Hi,
>> iirc, mingw.org provided gcc doesn't support wide startup.
>>
>> I suggest giving mingw-w64 gcc and crt a try. Unicode support has just
>> been added.
>
> Then it's only compiling and working on a 64 bit computer
> and I have a 32 bit computer. ;-)
>
> btw: I think the nesseccary of 64 bit computers is made by the marketing
> departements of Intel, AMD and other computer manufacturers who
> wants to sell new computers/processors, because there is no need
> for 64 bit, in no case. It's only overhead and slows down the code.
>
> Thomas
>

Hi,
I forgot to mention it works on win32 too. They really have to come up
with a better name.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Thomas Steinbach
Hello Jon,

>>>> [...]
>>>> Does anybody knows this problem or does anybody have a hint and tips
>>>> how
>>>> to solve that?
>>
>>> Hi,
>>> iirc, mingw.org provided gcc doesn't support wide startup.

yes, you're right, forget that. But I already have the _tWinMain function,
which
schould also compile to a unicode version if defined, shouldn't it?

>>> [...]
> I forgot to mention it works on win32 too. They really have to come up
> with a better name.

Ah. Ok, I see. Will try that if I have more time

Anyway. Is ther really _NO_ way to compile sourcecode, which is coded
with the _t* functions and the _T('') macro, etc.? I can't believe that.
I'm wondering if mingw can't compile such code...
Why? And why there are such implementations of the _t* functions in mingw?
It should compile as unicode if defined, shouldn't it?


Thomas


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

JonY-2
On 6/20/2009 10:54, Thomas Steinbach wrote:

> Hello Jon,
>
>>>>> [...]
>>>>> Does anybody knows this problem or does anybody have a hint and tips
>>>>> how
>>>>> to solve that?
>>>
>>>> Hi,
>>>> iirc, mingw.org provided gcc doesn't support wide startup.
>
> yes, you're right, forget that. But I already have the _tWinMain function,
> which
> schould also compile to a unicode version if defined, shouldn't it?
>
>>>> [...]
>> I forgot to mention it works on win32 too. They really have to come up
>> with a better name.
>
> Ah. Ok, I see. Will try that if I have more time
>
> Anyway. Is ther really _NO_ way to compile sourcecode, which is coded
> with the _t* functions and the _T('') macro, etc.? I can't believe that.
> I'm wondering if mingw can't compile such code...
> Why? And why there are such implementations of the _t* functions in mingw?
> It should compile as unicode if defined, shouldn't it?
>
>
> Thomas
>
>

Hi,

Both mingw.org and mingw-w64 support the _t* names, take a look at
"tchar.h" header.

Now that you mention it, in mingw.org tchar.h, they have:

#if 0  /* no  wide startup module */
#define _tmain      wmain
#define _tWinMain   wWinMain
#define _tenviron   _wenviron
#define __targv     __wargv
#endif

Even if you did change it to wWinMain, the code still can't properly
link due to the missing startup code in the mingw.org crt. The other _t*
functions like _tprintf should work as expected.

mingw-w64 on the other hand already includes the Unicode startup codes,
but the toolchain is a bit harder to set up, compared to the easy point
and click mingw.org installer.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Thomas Steinbach
Hello Jon,

>>> [...]
>> Anyway. Is ther really _NO_ way to compile sourcecode, which is coded
>> with the _t* functions and the _T('') macro, etc.? I can't believe that.
>> I'm wondering if mingw can't compile such code...
>> Why? And why there are such implementations of the _t* functions in
>> mingw?
>> It should compile as unicode if defined, shouldn't it?

> Both mingw.org and mingw-w64 support the _t* names, take a look at
> "tchar.h" header.

But this doesn't make any sense. In noc case.
Why are these header implemented, if I CAN'T compile and link
a windows GUI application as a unicode application???

Can you or anybody explain me that crazy and mad thing?

> Now that you mention it, in mingw.org tchar.h, they have:
>
> #if 0  /* no  wide startup module */
> #define _tmain      wmain
> #define _tWinMain   wWinMain
> #define _tenviron   _wenviron
> #define __targv     __wargv
> #endif
>
> Even if you did change it to wWinMain, the code still can't properly
> link due to the missing startup code in the mingw.org crt. The other _t*
> functions like _tprintf should work as expected.

These _t* funcitons doesn't make any sense, if mingw gcc, can't compile
and link to get a full unicode progamm ???

I don't understand that. Please tell me why?
That is really mad and I'm verryt disappointed about that :-(

So it looks like I should recommend every new user to use
Visual C or any other compiler which is abel to compile
unicode programs...

Thomas


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

JonY-2
On 6/21/2009 07:34, Thomas Steinbach wrote:

> Hello Jon,
>
>>>> [...]
>>> Anyway. Is ther really _NO_ way to compile sourcecode, which is coded
>>> with the _t* functions and the _T('') macro, etc.? I can't believe that.
>>> I'm wondering if mingw can't compile such code...
>>> Why? And why there are such implementations of the _t* functions in
>>> mingw?
>>> It should compile as unicode if defined, shouldn't it?
>
>> Both mingw.org and mingw-w64 support the _t* names, take a look at
>> "tchar.h" header.
>
> But this doesn't make any sense. In noc case.
> Why are these header implemented, if I CAN'T compile and link
> a windows GUI application as a unicode application???
>
> Can you or anybody explain me that crazy and mad thing?
>
>> Now that you mention it, in mingw.org tchar.h, they have:
>>
>> #if 0  /* no  wide startup module */
>> #define _tmain      wmain
>> #define _tWinMain   wWinMain
>> #define _tenviron   _wenviron
>> #define __targv     __wargv
>> #endif
>>
>> Even if you did change it to wWinMain, the code still can't properly
>> link due to the missing startup code in the mingw.org crt. The other _t*
>> functions like _tprintf should work as expected.
>
> These _t* funcitons doesn't make any sense, if mingw gcc, can't compile
> and link to get a full unicode progamm ???
>

I meant to say that using _tmain or _tWinMain won't work, but _tprintf
would work as expected. You cannot use wWinMain() or wmain() as the
entry point for your programs because of the missing startup code.

> I don't understand that. Please tell me why?
> That is really mad and I'm verryt disappointed about that :-(
>
> So it looks like I should recommend every new user to use
> Visual C or any other compiler which is abel to compile
> unicode programs...
>

I have told you already that the Unicode startups are missing in the
mingw.org crt and suggested you used the mingw-w64 toolchain as a
replacement.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Keith Marshall
In reply to this post by Thomas Steinbach
On Sunday 21 June 2009 00:34:45 Thomas Steinbach wrote:
> These _t* funcitons doesn't make any sense,

No, they don't -- completely non-standard, non-portable...

> if mingw gcc, can't compile and link to get a full unicode
> progamm ???

Who says MinGW GCC can't compile a full Unicode program?  How do you
think we build libiconv, and the utility programs which both depend
on it, and support it?  Are you suggesting that iconv is not a fully
Unicode aware application? [*]

> So it looks like I should recommend every new user to use
> Visual C ...

For those who share your unhealthy fixation with Microsoft's TCHAR
API, that may indeed be the best advice, but only if you share
Microsoft's blinkered and FUD ridden view that Unicode means only
UTF-16LE; how will your so-called full Unicode program cope when
faced with UTF-8, UTF-16BE or (perhaps less important) UTF-32?  I
may be wrong, but I don't believe TCHAR is equipped to handle them.

> or any other compiler which is abel to compile unicode programs...

Any ANSI-C compiler is perfectly capable of compiling fully Unicode
aware programs, provided you write them appropriately.  Your problem
appears to be your fixation with this Microsoft specific API.  If
you had been paying attention, earlier in the thread, you would have
learned that this antiquated, non-standard and non-portable API
deserved to die, long ago.

[*] FTR, iconv is probably actually more "fully Unicode aware" than
anything you will ever produce, if you limit yourself to Microsoft's
"lock-in" API; it is already fully equipped to interpret UTF-8,
UTF-16, UTF-16LE, UTF-16BE, (which IIRC is the "true" UTF-16 default
encoding), and UTF-32, together with myriad other non-Unicode
encodings, yet it is written without a single reference to TCHAR.

--

Regards,
Keith.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

Tor Lillqvist
In reply to this post by Thomas Steinbach
> Anyway. Is ther really _NO_ way to compile sourcecode, which is coded
> with the _t* functions and the _T('') macro, etc.? I can't believe that.

But why on Earth would you want to write code that uses these obsolete
and ugly conventions? If you really do want that, I fear you might be
so "brainwashed" by "Microsoft style" C (or even "C/C++"...) that
mingw isn't really for you anyway.

If you are compiling code written by others that uses that silly TCHAR
etc mechanism, then I think chances are large that the code uses other
things (MFC?) that won't work in mingw anyway, so better stick to
Microsoft's compilers. (There are "free" (no-cost) editions of them.)

If you are writing code from scratch, then, as I already tried to
suggest, just write your code to be "always Unicode" without any TCHAR
etc ugliness. Just use wchar_t strings, wide string literals, and
explicit wide character Windows and Microsoft C library APIs as
appropriate. Your code won't run on Windows 9x, but do you care?

--tml

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: unicode and WinMain compiling error

80063r
This post has NOT been accepted by the mailing list yet.
In reply to this post by Thomas Steinbach

Thomas Steinbach wrote
Hello,

I have a application which compiles with mingw gcc as a non unicode
version and all seems to be fine and working.

But if I try to compile it with the mingw gcc as a unicode version I get the
errror

C:/mingw3/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference
to `WinMain@16'
collect2: ld returned 1 exit status
make: *** [bin/test.exe] Error 1
I learned more about this subject from this thread than anywhere else.  But only because I first figured out that this will compile with mingw:


#define UNICODE
#define _UNICODE
#include <windows.h>
#include <tchar.h>

/* Real WinMain Prototype */

int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int);

/* It seems MinGW doesn't like _tWinMain when _UNICODE is defined and generates an undefined reference to WinMain
   So we provide a stub to keep it quiet */

#if !defined(_MSC_VER) && defined(_UNICODE) /* Only compile it when necessary */

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hNull, LPSTR lpCmdLine, int nCmdShow)
{
    return _tWinMain(hInst, NULL, GetCommandLine(), nCmdShow);
}

#endif

int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
    LPTSTR lpCmdLine, int nCmdShow)
{
        return MessageBox(HWND_DESKTOP,lpCmdLine,_T(""),MB_OK);
}


I'm still just learning about portability and unicode so feel free to correct me in any way.