Overview

[Mark McIntyre]

Mark McIntyre a écrit :

It is funny how excited you get... It must hurt somewhere isn't it?

Its mainly because arrogant stupid fools annoy me, and I especially
detest the condescending way they insist on treating their betters
like dirt, all the while peddling their misinformation to unsuspecting
newbies and acting like they actually knew what they were talking
about. They presumably get vicarious pleasure out of being so
obnoxious, winding people up and feeding falsehoods to people. I
personally regard such people as contemptible scum, your mileage may
vary of course.



--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

On Mon, 20 Nov 2006 09:38:01 +0100, in comp.lang.c , jacob navia

(the usual mixture of bullshit, incorrect statements and deliberate
attmempts to wind people up).

Who cares? *threadplonk*

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[jacob navia]

But you see, the example I provided _never_ exits. A good compiler
would know that, and have no need to link the library.

Never seen a compiler that would have a different version of the
startup code for each possible API that the generated program
doesn't call!!!

*shrug* This merely proves that VC is a poorly optimising compiler.
I'm sure lcc-win32 can do better.

And note that the function is still never called - including a symbol
name is not the same as calling the function.

This is the mistake. Including that symbol name FORCES the dynamic
loader to link the program to kernel32.dll, even if it is never used.

You must distinguish when speaking about dynamic linking between load
time, and later the run time. At load time the loader will never
know what APIs are called or not. It will never look for that kind of
information. It will just look if a symbol is present in the IMPORTS
table that ALL executable files have and link the dll that exports it.

Now, there are indeed (and there you have a point) demand loading
executables that will not load all DLLs and will load them ONLY if
they are called. Those executables (delay loading executables)
have a greatly reduced memory footprint, since they ONLY link
dynamically with kernel32.dll. THAT one is absolutely essential
since it contains LoadLibrary, the call to the dynamic loader,
and that one CAN'T be delay loaded.

That is why I said that all executables must at least link with
kernel32.dll.

 

[jacob navia]

Its mainly because arrogant stupid fools annoy me, and I especially
detest the condescending way they insist on treating their betters
like dirt, all the while peddling their misinformation to unsuspecting
newbies and acting like they actually knew what they were talking
about. They presumably get vicarious pleasure out of being so
obnoxious, winding people up and feeding falsehoods to people. I
personally regard such people as contemptible scum, your mileage may
vary of course.

WOW What a sentence Mark.

Congratulations, this one I will frame it!!!

 

[Mark McIntyre]

On Mon, 20 Nov 2006 09:48:20 +0100, in comp.lang.c , jacob navia

(bollocks as usual)

You're obviously totally incapable of understanding logic, whenever
where it conflicts with your opinion that you're always right, and
know everything. You're also all too eager to leap to the attack of
any criticism, which is frankly only to be expected given what
evidence I have of your personality.

I've therefore concluded that in future I'll restrict my responses to
your posts to pointing out your errors clearly and unambiguously so
that you don't mislead others. Any responses you may make, other than
to correct your posts, will be ignored.

I live in hope that you will see the error of your ways, but in
several years of posting here I have seen little evidence of common
sense, so I don't hope much.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Keith Thompson said:

No he said

ALL processes under windows must call ExitProcess to finish!!!!!!

A reasonable interpretation of that statement is that calling
ExitProcess is a precondition for any process to finish.

A trivial counter-example can disprove that claim too - simply cut the
power. The process *will* finish, and ExitProcess will *not* be called.

 

[Kenny McCormack]

Keith Thompson said:



A trivial counter-example can disprove that claim too - simply cut the
power. The process *will* finish, and ExitProcess will *not* be called.

Not on my machines.

(Which are all laptops or have GPS; of course, it is trivially true that
*all* programs will eventually finish, GPS or no, when the sun collapses
and everything is reduced to neutrinos)

Gee, are we OT enuf yet?

Alternatively, you could argue that abnormal termination does not count
as finishing. Imagine yourself performing some task, during which time
someone kills you; you would not say that you had finished your task.

 

[CBFalconer]

No he said

ALL processes under windows must call ExitProcess to finish!!!!!!

A reasonable interpretation of that statement is that calling
ExitProcess is a precondition for any process to finish. (Another
reasonable interpretation is that all processes must call ExitProcess,
but then the phrase "to finish" would be somewhat redundant.)

He also ignored the many DJGPP programs that run under Wxx and have
absolutely no knowledge of the windows API. Meanwhile they
co-operate with Windoze perfectly well, running off in a further
window as desired, and exit cleanly signalling success or failure.

 

[Alf P. Steinbach]

* Richard Heathfield:

Keith Thompson said:



A trivial counter-example can disprove that claim too - simply cut the
power. The process *will* finish, and ExitProcess will *not* be called.

Actually, in the old days of Windows NT you could just return from the
entry point function (suitably declared), and presumably that's still an
option.

Of course that's off-topic in [comp.lang.c].

But, since the most active [comp.lang.c] OT police are posting OT all
the time, including in this thread, who am I to break with such a fine
tradition?



Follow-ups set to [comp.os.ms-windows.programmer.win32].

 

[Old Wolf]

Like most of your guesses, this is as absurdly wrong as believing the
world to be flat. At a rough guess, *nix and Windows use shared
objects of some sort. Thats two. VMS shared objects are an utterly
different sort of beast. No idea about MVS or other mainframe OSen and
I don't know of a single embedded platform (and there are hundreds)
that is likely to. So we're at between 2% and 4% so far.

I program regularly on two embedded platforms and both of them
have shared libraries with a jump-table.

 

[Andrew Poelstra]

Keith Thompson said:



A trivial counter-example can disprove that claim too - simply cut the
power. The process *will* finish, and ExitProcess will *not* be called.

It will end. It will not finish.

("end" implies termination. "finish" implies completion.)

 

[Richard Heathfield]

Andrew Poelstra said:

It will end. It will not finish.

Wow, that's what I call nitpicking! But okay, fair enough. On to some
more serious counter-examples, then.

I have a whole bunch of programs written in C. All of them work just fine on
Windows XP machines (and indeed some of them ran just fine in the days of
Windows 3.0). All of them, kicked hard enough, will terminate ("finish").
None of them calls ExitProcess. Furthermore, I can generate more such
programs at my leisure.

 

[Chris Dollin]

Keith Thompson said:



A trivial counter-example can disprove that claim too - simply cut the
power. The process *will* finish, and ExitProcess will *not* be called.

Richard, old bean, I think you're losing it. Step back, draw several
deep breaths, have a coffee/tea/chocolate/whatever, and stop ratholing
into the details: in this case, they're a distraction. And they're off-
topic. And in this case, it's making you look like an idiot, and I'd
rather that you didn't -- it doesn't suit you.

 

[jacob navia]

Richard Heathfield wrote:




Richard, old bean, I think you're losing it. Step back, draw several
deep breaths, have a coffee/tea/chocolate/whatever, and stop ratholing
into the details: in this case, they're a distraction. And they're off-
topic. And in this case, it's making you look like an idiot, and I'd
rather that you didn't -- it doesn't suit you.

This is kind of curious.

Let's come back to the original problem:

A user wanted an overview/clarification about dynamic linking.
I gave him a short description. I think it is important, and
since C is a systems related language, this is not
very off topic. Linking (and dynamic linking belongs to the
linking process) is part of the language, even if it is always
system specific.

I mentioned that all programs under windows must use dynamic
linking since essential system functions like ExitProcess
must be called through the kernel32.dll dynamic linking API.

This then, degenerated in a frantic race to prove me
wrong using some kind of funny argument. First, an assembly
interface to the kernel functions of windows was proposed,
then a program with an infinite loop that would NOT call ExitProcess
at exit, then, (and this is the most extreme) just pull the
plug.

OK. I admit that if you pull the plug, the process will NOT
call ExitProcess unless the machine is using an UPS.

I admit also that if you use an assembler interface (not
the C interface) you could avoid having a reference to ExitProcess
in your executable and you would not need dynamic linking
(maybe is that possible, I do not know, and it is really off topic
here since we are discussing C and not assembly). That would
tie your program to a specific version of the ntdll.dll, making
the program unusable with the next service pack. But maybe
this doesn't matter, I do not know.

The point I wanted to do is that many systems use dynamic
linking (windows and unix for example) and that an answer to
a specific question about dynamic linking is appropiate in this
Newsgroup.

That is all.

 

[Richard Heathfield]

Chris Dollin said:

Richard, old bean, I think you're losing it.

Chris, my dear chap, I lost it decades ago. But I have hopes...

Step back, draw several
deep breaths, have a coffee/tea/chocolate/whatever, and stop ratholing
into the details: in this case, they're a distraction. And they're off-
topic. And in this case, it's making you look like an idiot, and I'd
rather that you didn't -- it doesn't suit you.

Well, that's as maybe, but I'm still /right/ (on this occasion). Anyway, I
have more serious counter-examples if need be.

 

[Richard Heathfield]

jacob navia said:

The point I wanted to do is that many systems use dynamic
linking (windows and unix for example)

That's certainly true, although not as true as you are claiming. I have at
least three C compilers which will take any strictly conforming C program
as input and produce an executable program that will work just fine under
Windows but which will not have any reference whatsoever to ExitProcess -
no static or dynamic link to it whatsoever.

and that an answer to
a specific question about dynamic linking is appropiate in this
Newsgroup.

Well, that's certainly an opinion, isn't it?

 

[Chris Dollin]

The point I wanted to do is that many systems use dynamic
linking (windows and unix for example)
Indeed.

and that an answer to
a specific question about dynamic linking is appropiate in this
Newsgroup.

Indeed not. Generally (and in this instance), it's off-topic.

That is all.

If that's all, we can stop now and talk about something interesting
and topical.

 

[Kenny McCormack]

If that's all, we can stop now and talk about something interesting
and topical.

You misspelled "boring".

Typical newspeak.

Quite seriously: Can anyone actually give an example of something that
is both topical *and* interesting? There is none, so we (generally)
settle for the former.

 

[Tor Rustad]

jacob navia skrev:

[...]

[...]

I mentioned that all programs under windows must use dynamic
linking since essential system functions like ExitProcess
must be called through the kernel32.dll dynamic linking API.

which was wrong

First, an assembly interface to the kernel functions of windows
was proposed, then a program with an infinite loop that would
NOT call ExitProcess at exit, then, (and this is the most
extreme) just pull the plug.

Some C compilers interface via kernel32.dll, others are set-up
via ntdll.dll, as you have been told, the kernel32.dll is just a
wrapper for ntdll.dll.

FYI, there exist a class of programs that try to avoid being
detected, such programs will typically not call ExitProcess.

I admit also that if you use an assembler interface (not
the C interface) you could avoid having a reference to ExitProcess
in your executable and you would not need dynamic linking
(maybe is that possible, I do not know, and it is really off topic
here since we are discussing C and not assembly). That would

We don't care which language the C compiler is implemented
in. Normally a C compiler is implemented in C, but that doesn't
make sys specific implementation details topical. If your C code
need a recompile due to a minor change of the OS, it's a
compiler QoI issue.

tie your program to a specific version of the ntdll.dll, making
the program unusable with the next service pack. But maybe
this doesn't matter, I do not know.

Really? So each time you install a new service pack, you
have to replace _all_ your device drivers too?! LOL

Of course this is nonsense, Microsoft simply cannot break
this system interface, without breaking a lot of existing
installations.

The point I wanted to do is that many systems use dynamic
linking (windows and unix for example) and that an answer to
a specific question about dynamic linking is appropiate in this
Newsgroup.

The point is:

Dynamic linking is platform specific and off-topic.

 

[Richard Heathfield]

Tor Rustad said:

jacob navia skrev:


Some C compilers interface via kernel32.dll, others are set-up
via ntdll.dll, as you have been told, the kernel32.dll is just a
wrapper for ntdll.dll.

And some don't bother with either of those. I have at least three such
compilers available to me on - er - one or other of the Windows-driven
computers I have lying about the place.

<snip>