Re: linker error
On Jul 26, 10:55 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1185464835.026416.133...@k79g2000hse.googlegroups.com>,
james.ka...@gmail.com says...
On Jul 25, 6:47 pm, Jerry Coffin <jcof...@taeus.com> wrote:
[ ... ]
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 al=
l.
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:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34