include

[Dombo]

Op 13-Dec-11 21:10, jacob navia schreef:

Le 13/12/11 20:31, Leigh Johnston a écrit :

Parsing the command line arguments should go into
another TU?

YES!!!!

You have just CONFIRMED THEN the need for main.h

Why would need a main.h? If command line parsing goes in another TU I
would expect something like command_line_parser.h, not main.h. After all
the main() function would call the command line parser, not visa versa.

 

[Goran]

--In this newsgroup, there's no C++ program without main().

This newsgroup is about the C++ lang, not about a function named main.
Its perfectly fine for people to discuss C++ code that doesn't have a main
function.


--So what? It's pretty improbable that OP's main.cpp hasn't got main()
--in it.

The OPs code either does or doesn't contain a main entry point function.
This make the probaility 50/50.

It doesn't. Have a lesson on statistics. (And don't forget your
medication.)

 

[Juha Nieminen]

Nonsense and exe file is loaded into memory by the program loader, it is not
somehow parsed again by a dynamic linker as you seem to be suggesting.

So the wikipedia article above is wrong. Care to quote some actual
technical documentation (eg. from Microsoft) that contradicts the
wikipedia article?

MZ is just an old MS-DOS stub and it's part of the format for that partcular
type of exectuable file.

Ah, so now you finally admit that an exe file contains something else than
pure machine code.

It has nothing to with dynmaic linking, it tells the program loader how to
load the exe into memory.

The "MZ" id just denotes the file type. However, you happily ignored the
fact that it's not the only header data that the exe file contains. It
contains more header data plus relocation data for the dynamic linker.
This data is used by the dynamic linker to modify base addresses and
system function call addresses inside the program binary, before it can
be properly run. If you don't believe me, consult the proper technical
documentation on exe files.

I never said and exe is pure machine code with no headers

Ah, you took a third option that I didn't immediately think of, of the
two I suggested (ie. either check the file format specification for yourself,
or avoid it and pretend that you are right). In other words: Start lying
about what you claimed before. But now that I think about it, it's really
the most natural way of proceeding for you: Pretend that you didn't make
the original mistake you did. Just start repeating "I never said that"
enough times and hope that nobody remembers.

Well, at least now you admit that an .exe file is not pure machine code,
which is something. (Of course you still can't admit having made a mistake.)

, it was you who
introduced this PE format into the discussion.

The .exe files used in Windows *are* in the PE format. And even the
old DOS .exe files, which were simpler, were not pure machine code either.

You claimed that .exe files can be run directly without any modification,
and that they are "machine code" (which you yourself defined as "containing
only machine code"). In your definition object files are not "machine code"
because they contain something else than machine code as well.

Well, big surprise: There isn't that much difference between an object
file and an exe file: Both contain machine code *and* ancillary data,
mostly related to rebasing/relocating the code and setting function call
addresses.

 

[Goran]

--It doesn't. Have a lesson on statistics. (And don't forget your
--medication.)

You don't know anything about probaility and chance. You are just a dumb ass
**** who aint really worth replying to again.

Still didn't take that medication? Mummy will be upset!

 

[Goran]

Well you remain wrong then. A C++ compiler outputs object code, not machine
code or C code.

You know who's wrong? People who don't take their medication. Remember
that guy from Norway some months ago? Well, that's what often happens
when you forget your medication.

 

[Fred Zwarts \(KVI\)]

"(e-mail address removed)>" wrote in message

Object files contain object code. It is incorrect to say that an object
file is machine code just because the text segment contains opcodes.

It is incorrect to say that an executable file is machine code just because
some segments contain opcodes. Just like object files, executable files
contain different segments, not all of them are executable.

You can, in the correct context, say that object files contain machine
code as the text section notrmally does contain machine specific opcodes.
It is incorrect however to suggest this file format is the same as an
exectuable.

You can, in the correct context, say that an executable file contains
machine code
as the executable section normally does contain machine specific opcodes.
It is incorrect however, to assume that these opcodes can be executed
unmodified,
except in very rare cases that are nowadays no longer used, like the ..COM
files in DOS.
Further, the exe files contain other sections, like data sections, which are
not opcodes and
cannot be executed by a processor. Even the old fashioned .COM files
contained data that
were not opcodes.
So, there is a difference between object files and executable files, but the
difference is not
that only one format consists only of opcodes that can be used unmodified by
the processor.

 

[gwowen]

You know who's wrong? People who don't take their medication. Remember
that guy from Norway some months ago? Well, that's what often happens
when you forget your medication.

Battle not with monsters, lest you become a monster... Seriously, the
correct response to an internet kook is *not* continual attempts to
engage in rational discourse, but its not abuse either.

 

[Juha Nieminen]

If the wiki article is saying that PE is loaded with a dynamic loader then
its probably talking about a DLL. It is certialy not the case that all exe's
are loaded with a dynamic linker.

I happen to know for a fact that .exe files are loaded with a dynamic
linker which performs relocation and rebasing operations as needed (using
the data in the .exe file for that exact purpose). The wikipedia article
also clearly tells you this.

An .exe file (or any executable in any modern OS for that matter) is
as much "machine code" as an object file: Both contain compiled machine
code plus ancillary data used to set up jump and subfunction call
addresses appropriately. In some systems (such as in Windows) both
actually use the same file format (in Windows' case the PE format),
thus making them even less different.

I don't really need to post a link to prove you wrong

Translation: "I can't post a link to any official documentation because
there isn't one that would confirm my assertions."

It amuses me that I have given actual references, you have given
absolutely none, and only try to defend yourself with laughably weak
"I don't have to give you any references because everybody knows you
are wrong" pretenses.

 

[Goran]

I know one thing for sure. Horrible people like you are certainly wrong and
you will die one die. This makes me happy

See what happens when you don't take your medication? Tsk, tsk, tsk...

 

[Goran]

Battle not with monsters, lest you become a monster... Seriously, the
correct response to an internet kook is *not* continual attempts to
engage in rational discourse, but its not abuse either.

True, but it's not human to always abstain, either ;-)

Goran.

 

[Juha Nieminen]

Are you blind? Dyslexic? Memory problems? Drug addict with brain
damage? Can you not read responses properly? I never called object
files "as a whole" machine code.

I really think that you are being misled by his squiggling and attempts
to muddle the issue. What actually happened is pretty simple:

When you originally said that "the compiler generates machine code",
he misunderstood you and thought that you were saying "the compiler
creates an executable file". What he then loudly *tried* to say is
"no, a compiler does not create an executable file, it creates object
files; it's the linker which creates an executable file from those
object files."

However, since he got confused with the terminology (ie. confusing
"machine code" with "executable file") and because of his pathological
personality disorder (either he amuses himself with trolling, or he is
completely unable to admit his own mistakes) he started defending his
mistaken *terminology* (rather than what he was trying to really say
originally).

Thus, rather than simply saying "ah, sorry, I misread; I thought you
said that a compiler creates an executable file directly", he instead has
now gone to ridiculous extents to try to make his own personal definition
of what "machine code" really means.

What I'm trying to say is that it doesn't really matter whether you
originally said "an object file contains only machine code" (which
obviously isn't what you said, of course). He is just trying to cover
up his simple mistake by fighting over terminology.

(Of course by doing this he made yet another mistake: He originally
believed that an executable file contains nothing else than machine
code and whatever data the program itself uses. He did not know that
executable files actually contain non-machine code, namely headers and
relocation/rebasing data, which are used by a dynamic linker to modify
the machine code before it can be run. After he finally realized *this*
mistake of his, now he is trying to deny what he originally claimed,
yet still somehow maintain his personal definition of "machine code".)

 

[Goran]

I know one thing for sure. Horrible people like you are certainly wrong and
you will die one die. This makes me happy

Actually, it's the medicine that makes you happy. But you need to take
it to realize you have been unhappy before.

 

[gwowen]

  However, since he got confused with the terminology (ie. confusing
"machine code" with "executable file") and because of his pathological
personality disorder (either he amuses himself with trolling, or he is
completely unable to admit his own mistakes) he started defending his
mistaken *terminology* (rather than what he was trying to really say
originally).

i.e. He did *exactly* what he always does when corrected - a mixture
of weaseling-through-redefinition and outright abuse. The only way
this will stop is if *you stop engaging with him*. How much evidence
do you require that he's *not* engaging in good faith discussion?

[ObXKCD elided]

 

[John Bokma]

You know who's wrong? People who don't take their medication. Remember
that guy from Norway some months ago? Well, that's what often happens
when you forget your medication.

Goran,

I really would appreciate it if you leave the "medication" out of future
discussions. Not all meds are effective for everybody (e.g. SSRIs seem
only to be effective in 50% of the cases, and is by some considered not
more effictive than therapy). Medication is certainly not a cure all,
and the "did you forget to take your pills" line is not funny to people
who either have to take meds to stay somewhat sane, and certainly
not funny to people for whom there are no effective meds, yet they have
heard this line countless times by "well-meaning" laymen (and so-called
"professionals"). One of the most stupid lines I've ever heard was "not
cooperating with medication" while the prescription was being followed
to the letter. I have no idea what the person was trying to tell, but
the meds were not effective, and that couldn't be the meds, right?

Paul seems to be in it for drawing out discussions, and you seem to be
too eager to assist him. Maybe it's you who needs to control yourself?
I am following this group for a week or so, and the majority of posts
seems to consist of Paul's post and replies to him. One can't just argue
with a troll. And while one could argue that some replies are
educational, it's all quite basic stuff (what I've seen) and not worth
the effort of following the whole thread or threads, it seem to infect
others very rapidly...

 

[John Bokma]

Actually, it's the medicine that makes you happy.

Actually, there are no (legal) medications that make people happy. I
guess to are referring here to SSRIs and similar meds. What those do in
some people -- SSRIs, for example, are not that effective although they
are considered the magic solution for almost everything -- is to make it
possible to be able to "feel" things again, to actually enjoy things
again, to remove the numbness. And yes, that can allow for (more)
moments of happiness.

 

[88888 Dihedral]

I really think that you are being misled by his squiggling and attempts
to muddle the issue. What actually happened is pretty simple:

When you originally said that "the compiler generates machine code",
he misunderstood you and thought that you were saying "the compiler
creates an executable file". What he then loudly *tried* to say is
"no, a compiler does not create an executable file, it creates object
files; it's the linker which creates an executable file from those
object files."

However, since he got confused with the terminology (ie. confusing
"machine code" with "executable file") and because of his pathological
personality disorder (either he amuses himself with trolling, or he is
completely unable to admit his own mistakes) he started defending his
mistaken *terminology* (rather than what he was trying to really say
originally).

Thus, rather than simply saying "ah, sorry, I misread; I thought you
said that a compiler creates an executable file directly", he instead has
now gone to ridiculous extents to try to make his own personal definition
of what "machine code" really means.

What I'm trying to say is that it doesn't really matter whether you
originally said "an object file contains only machine code" (which
obviously isn't what you said, of course). He is just trying to cover
up his simple mistake by fighting over terminology.

(Of course by doing this he made yet another mistake: He originally
believed that an executable file contains nothing else than machine
code and whatever data the program itself uses. He did not know that
executable files actually contain non-machine code, namely headers and
relocation/rebasing data, which are used by a dynamic linker to modify
the machine code before it can be run. After he finally realized *this*
mistake of his, now he is trying to deny what he originally claimed,
yet still somehow maintain his personal definition of "machine code".)

It is kind of boring for you two arguing machines for a fixed job
that does need an OS at all and machines that has to run with an OS to load a program to run.

The address translation is needed in the OS.

 

[Tobias Müller]

You know who's wrong? People who don't take their medication. Remember
that guy from Norway some months ago? Well, that's what often happens
when you forget your medication.

Your posts are by far the most disgusting ones on this thread. You don't
contribute anything interesting at all and none of your posts are on topic
(not even considering that this whole discussion is actually off topic).

Tobi

 

[Juha Nieminen]

Nonsense , an executable file is loaded into memory as is.

Then it should be easy to prove it, shouldn't it? Just give us some
official documentation that say so.

Of course you won't do that. You'll just call us names and say that
you don't have to prove anything.

 

[Juha Nieminen]

Absolute rubbish.

http://en.wikipedia.org/wiki/Loader_(computing)

Please note the subsection on dynamic linkers:
"Dynamic linking loaders are another type of loader that load and link
shared libraries (like .dll files) to already loaded running programs."

Isn't it amusing that you see only what you want to see? You happily
skipped the section that talks about relocating (which goes totally against
your claim that executables are run as-is, without modification).

Executable files in most modern operating systems contain relocation and
rebasing data, and they always depend on shared libraries, and they are
always loaded with a dynamic linker that performs the relocations and
linking with the shared libraries (by changing function call addresses).

All Windows executables are in the PE format, which contains header and
reallocation data. The same is true for all unix executables in both the
COFF and ELF formats. They all require dynamic linking to run.

You didn't even bother to read the article about the PE format, did you?
It says, among other things:

"A PE file consists of a number of headers and sections that tell the
dynamic linker how to map the file into memory. An executable image
consists of several different regions, each of which require different
memory protection; so the start of each section must be aligned to a
page boundary. For instance, typically the .text section (which holds
program code) is mapped as execute/readonly, and the .data section
(holding global variables) is mapped as no-execute/readwrite. However,
to avoid wasting space, the different sections are not page aligned on
disk. Part of the job of the dynamic linker is to map each section to
memory individually and assign the correct permissions to the
resulting regions, according to the instructions found in the
headers."

You are still claiming that an exe file can be loaded and run as-is,
without any modification. No, they can't.

 

[Juha Nieminen]

The section you have pointed out here clearly says :

"Some computers need relocating loaders, which adjust addresses (pointers)
in the executable to compensate for variations in the address at which
loading starts."

These programs are not the norm and they are certainly not your standard
windows PE executables , which is what you have been spouting on about.

I still find it amusing how you fail to read the articles I refer.

"PE files do not contain position-independent code. Instead they are
compiled to a preferred base address, and all addresses emitted by the
compiler/linker are fixed ahead of time. If a PE file cannot be loaded
at its preferred address (because it's already taken by something
else), the operating system will rebase it. This involves
recalculating every absolute address and modifying the code to use the
new values."

PE files are, thus, *exactly* the type of executables you are yourself
quoting above.

So no, Windows executables cannot be run as-is, without modification.
Of course you will never admit this. (Or alternatively, you will start
lying that you never claimed so.)

This is absolute nonsense.

Then it should be easy for you to prove me wrong, shouldn't it? Please
go ahead. I'll wait.