linker error

[kath.neumann]

Hi,

I just started to get a grip on C++ and and went through the tutorial.
However, not even the standard "hello world" exercise works out :( I
do get a linker error "[Linker Error] Unresolved external 'WinMain'
referenced from C:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\C0W32.OBJ"

my code (Borland C++ builder 5) is as follows:
#include <condefs.h>
#include <iostream.h>
#include <conio.h>
#pragma hdrstop

//---------------------------------------------------------------------------
int main (int argc, char **argv)
{
cout << "Hello World!" << endl;
cout << endl << "press any key to continue...";
getch();
return 0;
}
Any idea?

THANKS!

kath

[Victor Bazarov]

ka**********@web.de wrote:

I just started to get a grip on C++ and and went through the tutorial.
However, not even the standard "hello world" exercise works out :( I
do get a linker error "[Linker Error] Unresolved external 'WinMain'
referenced from C:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\C0W32.OBJ"

my code (Borland C++ builder 5) is as follows:
#include <condefs.h>
#include <iostream.h>
#include <conio.h>
#pragma hdrstop

//---------------------------------------------------------------------------
int main (int argc, char **argv)
{
cout << "Hello World!" << endl;
cout << endl << "press any key to continue...";
getch();
return 0;
}
Any idea?

Unfortunately, yes. You're building this as a Windows application.
If so, then your application doesn't start in 'main', it has to start
in 'WinMain', which you don't have and that's what the linker is
complaining about. MS Windows programming is not the same as just
plain programming. That's why you probably want to set aside the
"Windows" side of things for now and switch to creating what is known
as "Console Applications". See appropriate settings described in the
help system for your compiler. Or ask in the newsgroup dedicated to
your compiler (see the 'borland.public.*' hierarchy).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-07-23 17:40, ka**********@web.de wrote:

Hi,

I just started to get a grip on C++ and and went through the tutorial.
However, not even the standard "hello world" exercise works out :( I
do get a linker error "[Linker Error] Unresolved external 'WinMain'
referenced from C:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\C0W32.OBJ"

my code (Borland C++ builder 5) is as follows:
#include <condefs.h>

Non-standard header, and not used, skip it.

#include <iostream.h>

Old header, nowadays all standard headers are included without the .h
suffix, so it should be just #include <iostream>

#include <conio.h>

Non-standard, it's generally a good idea to stay away from such headers
while learning C++, since it reduces the changes of learning any bad habits.

#pragma hdrstop

Non-standard and I don't know what it does. Keep it if you think it's
useful, but considering the name of the pragma it's probably something
that should be used in header-files.

//---------------------------------------------------------------------------
int main (int argc, char **argv)

Unless you actually parse the command line arguments I would recommend
to use the simpler form: int main().

{
cout << "Hello World!" << endl;

This should give you a compiler error, cout is not defined. Either
include the namespace (std::cout << ...) or put 'using namespace std;'
above the main-function. I prefer the first but that's just me.

cout << endl << "press any key to continue...";

Ditto.

getch();

If used just to prevent the console from closing as soon as the program
is done, I think it's better to use std::cin.get() which will require
you to press enter. If you use this you can get rid of the include for
conio.h also.

return 0;
}
Any idea?

You have probably specified it as a windows GUI program when you created
the project (or whatever Borland calls it), you need to specify it as a
native win32 project.

By the way, it seems to me that Borland C++ Builder 5 is quite old by
now, at least one newer version is out and you might want to consider
upgrading. If cost is an issue there are free alternatives, both Visual
C++ 2005 from MS and DevC++ (which comes with gcc).

--
Erik Wikström

[kath.neumann]

On 23 Jul., 17:55, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:

I just started to get a grip on C++ and and went through the tutorial.
However, not even the standard "hello world" exercise works out :( I
do get a linker error "[Linker Error] Unresolved external 'WinMain'
referenced from C:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\C0W32.OBJ"

my code (Borland C++ builder 5) is as follows:

#include <condefs.h>
#include <iostream.h>
#include <conio.h>
#pragma hdrstop

//---------------------------------------------------------------------------
int main (int argc, char **argv)
{
cout << "Hello World!" << endl;
cout << endl << "press any key to continue...";
getch();
return 0;
}

Any idea?

Unfortunately, yes. You're building this as a Windows application.
If so, then your application doesn't start in 'main', it has to start
in 'WinMain', which you don't have and that's what the linker is
complaining about. MS Windows programming is not the same as just
plain programming. That's why you probably want to set aside the
"Windows" side of things for now and switch to creating what is known
as "Console Applications". See appropriate settings described in the
help system for your compiler. Or ask in the newsgroup dedicated to
your compiler (see the 'borland.public.*' hierarchy).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Hi Victor,
it is running now, thanks for your help!!! I created it as console
application, that was indeed the reason. thanks for this tip :-)
Cheers,
Kathleen

[BobR]

<ka**********@web.dewrote in message...
On 23 Jul., 17:56, Neelesh Bodas <[e-mail]:

>Use some standard-compliant compiler. Typical options are g++(linux),
devc++(windows), but I am sure there are other options too.

>Hi,
thanks, it is running now :)
thanks for your recommendations on compiler, I'll check that soon!
Cheers, Kathleen

FYI: Dev-C++ is not a compiler, it is an IDE. There is an option to download
a Dev-C++ package that contains the GNU GCC(MinGW) compiler.

Dev-C++ IDE: http://www.bloodshed.net/

--
Bob R
POVrookie
- -
MinGW (GNU compiler): http://www.mingw.org/
MinGWStudio http://www.parinyasoft.com/ (GNU/Linux & window$)
wxWidgets URL: http://www.wxwidgets.org
Code::Blocks http://www.codeblocks.org/

[BobR]

Erik Wikström <Er***********@telia.comwrote in message...

>
.... or put 'using namespace std;'
above the main-function.

Why not *in* main()?

--
Bob R
POVrookie

[James Kanze]

On Jul 23, 7:02 pm, "Alf P. Steinbach" <[e-mail]:

* Victor Bazarov:

[...]

g++ supports standard "main" by default,
Visual C++ supports standard "main" when using appropriate switches (by
default Visual C++ is also non-standard-conforming wrt. exceptions, RTTI
and for-loop syntax, so it must be browbeaten into submission).

Aren't they all? You need -std=c++98 -pedantic with g++, and
God knows how many options with Sun CC. Add to that the fact
that pure C++ compliance locks you out of a lot of Posix, and
what's a programmer to do?

which you don't have and that's what the linker is
complaining about. MS Windows programming is not the same
as just plain programming. That's why you probably want to
set aside the "Windows" side of things for now and switch to
creating what is known as "Console Applications".

Good advice.

I know this is off topic, but the issue comes up so often: what
the hell is a "console application"? How does it differ from
any other application, other than, perhaps, it doesn't use
certain libraries? (In which case, of course, you don't need to
click anything. Just don't include the appropriate headers, nor
link against the corresponding library.)

Unless I've misunderstood something greatly, in the end, an
application is an application. If it invokes some system
function which opens a window, and plays around in it, then it
is a GUI (or Windowing) application, but that's a result of the
code the programmer wrote, and nothing else. The applications I
write don't normally do this: are they automatically console
applications (even if they are started by a cronjob, or at
system start-up, with cin, cout and cerr connected to
"/dev/null")?

I'd add: use command line tools for building.

Is there any other way? All the IDE's that I know (admittedly,
NOT Visual Studio) do is generate command lines.

An IDE adds too much "helpful" stuff that just gets in the way.

:-) Boy can I agree with you there.

At least for production code. I can imagine that when learning,
"one thing at a time" is not a bad policy, and if you could find
an IDE which actually worked correctly and usefully, it would be
nice. But professionally, never.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 23, 5:56 pm, Neelesh Bodas <[e-mail]:

On Jul 23, 8:40 pm, [e-mail] wrote:

Use some standard-compliant compiler. Typical options are g++(linux),
devc++(windows), but I am sure there are other options too.

Watch it. I have no idea what devc++ is, but g++ is not
standards compliant, by a long shot. "g++ -std=c++98 -pedantic"
tries to be, up to a certain point, but even it ignores some
major features of C++ (like export).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Victor Bazarov]

James Kanze wrote:

[..] If I look at my
Windows system, I don't see any difference between applications;
they're all .exe files, regardless of what they do. As far as I
can tell, all of the facilities of the OS are there for all
programs to use, if they want.

If I look at my Windows desktop, they all look like tiny pictures.
As far as I can tell, there are no .exe files.

[..off topic snipped..]

MSDN is your friend (if you really want to know about Windows,
that is). It looks like you were at least curious. Well, don't
you know that there are newsgroups for those discussions? And
here is a link (courtesy of MSDN) answering at least one question
(how to distinguish between a console app and non-console app):
http://support.microsoft.com/kb/90493

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Jul 25, 2:36 pm, "Victor Bazarov" <[e-mail]:

James Kanze wrote:

[..] If I look at my
Windows system, I don't see any difference between applications;
they're all .exe files, regardless of what they do. As far as I
can tell, all of the facilities of the OS are there for all
programs to use, if they want.

If I look at my Windows desktop, they all look like tiny pictures.
As far as I can tell, there are no .exe files.

Come now. How did those icons get there? Even I know that you
can open a properties dialog, and specify the command for the
program, and I rarely use Windows.

[..off topic snipped..]

MSDN is your friend (if you really want to know about Windows,
that is). It looks like you were at least curious.

All I really wanted was a definition of a term that I'd seen
often enough here, and for which I couldn't figure out any
reasonable meaning. Alf's article filled the bill (and then
some, since I now not only know what was meant, but what I'll
have to do if I ever have to develop applications under
Windows.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[BobR]

James Kanze <ja*********@gmail.comwrote in message...

...., and I rarely use Windows.

Ah, so you are the guy that dropped B. Gates to number 2 in the 'worlds
richest' list!! <G>
Good job, friend!

--
Bob R
POVrookie

[Jerry Coffin]

In article <11**********************@k79g2000hse.googlegroups .com>,
ja*********@gmail.com says...

On Jul 25, 6:47 pm, Jerry Coffin <[e-mail]:

[ ... ]

What's a PE file? And what do you mean by "optional header"?
I'm sure that .exe file have a specific format, just as a.out
files do under Unix; do you mean a header section in this
format?

Sorry -- PE is "Portable Executable" format, which is a variation on
COFF, and yes, it's the current format for Windows executables. COFF
defines a couple of fields for what it calls an optional header -- but
to be a PE file, that optional header has to be included in a specific
format.

[ ... ]

That means portable code that uses 'main' will become a console
subsystem program unless you specify otherwise.

But I can specify otherwise. Why not?

I'm not sure I follow. Why not what? If you mean, why wouldn't you do
that, the main reason would be that you plan to use the console streams,
so you want them set up by default, which will happen if it's marked for
the console subsystem, but not if it's marked for the windows subsystem
(at least the startup code supplied by the compilers I've looked at
didn't do include that by default...)

[ ... ]

That's what I'd always thought. (On the other hand, there are
significant differences between the way Windows handles .dll's,
and Unix handles .so's. My impression, in fact, is that they
are much like the differences between how the systems handle the
way you start a program. Under Windows, the decisions are
handled upstream, by the person who provides the program/DLL;
under Unix, they're made by the user, when he uses it.)

I'm not sure I understand exactly what differences you're talking about
here...

[ ... ]

As far as sophistication goes, I suspect it's a much a matter of
viewpoint as anything else -- when I run Unix (or Linux, BSD, etc.) I
get the feeling of having just stepped back 10 or 15 years as well...

With regards to what? I don't have the applications that I have
under Windows, or they don't look as sleek, but at the system
level, I've got a lot more functionality: multiple desktops,
windows on many different machines, etc.

Well, to continue one of your examples, Windows does support multiple
desktops -- but I haven't been able to find X/Unix functionality similar
to the multiple window stations supported by Windows. Under Windows,
each desktop lives in a window station. Most "global" objects like the
clipboard are only really shared among the desktops in a window station.
Under X, the clipboard is managed by a process of its own, but I haven't
seen a capability to designate (for example) that these three desktops
share one clipboard, while those two share a different one.

[ ... ]

This _is_ somewhat different: Windows only provides on way to start a
program, but it does NOT map to much of anything. The real entry point
for a program always has the signature 'unsigned int entryPoint(void)'.
It's (always) up to some code in the program itself to do things like
retrieving and parsing its command line, if it chooses to do so at all.

All of which is transparent to the C++ programmer, of course:-).

Yes -- unless he chooses to get involved, of course.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 26, 10:55 pm, Jerry Coffin <[e-mail]:

In article <[e-mail] .com>,
[e-mail] says...

On Jul 25, 6:47 pm, Jerry Coffin <[e-mail]:

[ ... ]

That means portable code that uses 'main' will become a console
subsystem program unless you specify otherwise.

But I can specify otherwise. Why not?

I'm not sure I follow. Why not what?

Just "why not?" Why not do it like Microsoft does? It's no
worse (nor any better) than some other solutions.

[ ... ]

That's what I'd always thought. (On the other hand, there are
significant differences between the way Windows handles .dll's,
and Unix handles .so's. My impression, in fact, is that they
are much like the differences between how the systems handle the
way you start a program. Under Windows, the decisions are
handled upstream, by the person who provides the program/DLL;
under Unix, they're made by the user, when he uses it.)

I'm not sure I understand exactly what differences you're talking about
here...

The fact that with Windows DLL's, you specify which symbols are
exported in the source file, using language extension (or in a
second file, which will be read by the linker), where as with
Unix, you specify whether other so's can see the symbols in your
so by means of an option to dlopen, when you load the object.
Under Windows, the author of the dynamically linked object
chooses what will and what will not be visible; under Unix, the
user chooses when loading the object. (But that's a radical
simplification, of course.)

[ ... ]

As far as sophistication goes, I suspect it's a much a matter of
viewpoint as anything else -- when I run Unix (or Linux, BSD, etc.) I
get the feeling of having just stepped back 10 or 15 years as well...

With regards to what? I don't have the applications that I have
under Windows, or they don't look as sleek, but at the system
level, I've got a lot more functionality: multiple desktops,
windows on many different machines, etc.

Well, to continue one of your examples, Windows does support multiple
desktops -- but I haven't been able to find X/Unix functionality similar
to the multiple window stations supported by Windows. Under Windows,
each desktop lives in a window station. Most "global" objects like the
clipboard are only really shared among the desktops in a window station.
Under X, the clipboard is managed by a process of its own, but I haven't
seen a capability to designate (for example) that these three desktops
share one clipboard, while those two share a different one.

I'm not sure what the difference is under Windows, but it sounds
like you've basically got two different terminals under X. (A
terminal under X can have more than one screen.)

[ ... ]

This _is_ somewhat different: Windows only provides on way to start a
program, but it does NOT map to much of anything. The real entry point
for a program always has the signature 'unsigned int entryPoint(void)'.
It's (always) up to some code in the program itself to do things like
retrieving and parsing its command line, if it chooses to do so at all.

All of which is transparent to the C++ programmer, of course:-).

Yes -- unless he chooses to get involved, of course.

Agreed. (IMHO: Not having access to the actual command line
is a flaw in the Unix design. There are cases where you want to
differ e.g. filename expansion; under MS-DOS, I had a library
which broke up the command line something like the way Unix
does, including expansion of things like *.c. And one of my
"standard" options was -R, which means recurse on the current
directory, expanding the filenames in all of its subdirectories
as well. And a -o option which would accept such names as well,
mapping each input filename to a corresponding output filename.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]