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\C BUILDER5\LIB\C0 W32.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

[BobR]

James Kanze <ja*********@gm ail.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************ **********@k79g 2000hse.googleg roups.com>,
ja*********@gma il.com says...

On Jul 25, 6:47 pm, Jerry Coffin <jcof...@taeus. comwrote:

[ ... ]

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 <jcof...@taeus. comwrote:

In article <1185464835.026 416.133...@k79g 2000hse.googleg roups.com>,
james.ka...@gma il.com says...

On Jul 25, 6:47 pm, Jerry Coffin <jcof...@taeus. comwrote:

[ ... ]

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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]