Overview

M

Mark McIntyre

Let's see. You name a program that doesn't do any input or output,
that doesn't touch any hardware, nor the screen nor the timers...

God, you are such a tedious idiot.
Any of those needs a windows system dll, either kernel32, or avdapi32 or
some of those.

Bollocks. There's no other word for it.
This discussion is doomed since you refuse (or can't) name
a program or show some example of your position. You just
limit to say

"Jacob is wrong"

You lie, badly, but still, you lie.
and that is it. But in my personal opinion that is far from enough.

Luckily I actually backed up my points.
--
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
 
M

Mark McIntyre

If you are not running windows it can be that you link
everything statically.
....
The original poster was speaking about cygwin...

And so what? You claimed that DLLS were a universal feature. You have
admitted yourself you lied. End of discussion I believe.
Still, you have failed to point out what is
wrong with my assertions or produce any counter example
or somehow subtatiate your claims...

Actually, I already did (even though its hideously offtopic here), but
as expected you chose to ignore it and snip it from all replies.

Here's a thought: the only reason you are not in my killfile is
_specifically_ so that I can read your posts and point out any errors
you make. Doesn't that give you pause for thought that someone feels
it specifically necessary to monitor you?
--
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
 
M

Mark McIntyre

ALL processes under windows must call

ExitProcess

to finish!!!!!!

counter example

int main(void){for(;;) }
That API call is exported in Kernel32.dll.

Mhm, but we never call it.
--
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
 
M

Mark McIntyre

Tor Rustad a écrit :

This is stupid. All those numbers change from version to version.

So what? It proves you to be
a) wrong and
b) too proud to admit it.
Dynamic linking is NOT platform specific and is used in MANY different
platforms.

You talk utter dreck. Words fail me for how stupidly, arrogantly,
fatuously cretinously wrong you are. Dynamic linking is probably one
of the most platform-specific things you can get, precisely _because_
it is used on many platforms.
Most of them I would guess.

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.


--
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
 
M

Mark McIntyre

Flash Gordon a écrit :

Thanks Mr Gordon...

I noticed that while thanking him, you snipped all the context.
Dissembling to the last.

--
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
 
T

Tor Rustad

jacob navia skrev:

[...]
If a C compiler would do this, the generated programs would
run ONLY with the EXACT copy of the API, what it means that
the next service pack that adds an API call would make that the
programs instead of calling Exitprocess would call ANOTHER,
different API!!!

So what?

How all C compilers does this, is simply not under your control,
and your statement:

"ALL processes under windows must call ExitProcess"

has been proven wrong.

Dynamic linking is NOT platform specific and is used in
MANY different platforms. Most of them I would guess.

I currently develop C code on 2 different embedded
systems, where there is no dynamic linking.

Linking is platform specific and OFF-TOPIC. :)
 
A

Andrew Poelstra

counter example

int main(void){for(;;) }


Mhm, but we never call it.

Ah, but we never finish, so this doesn't actually debunk Jacob's
point.

Your other comments elsethread all appear correct, however, although
harsher than I might have put them. :)
 
R

Richard Bos

jacob navia said:
Kenny McCormack a écrit :

The proof is obvious:

ALL processes under windows must call

ExitProcess

to finish!!!!!!

Boy, when you find yourself having to use multiple exclamation marks to
get your point across it's high time to start considering that you just
might be wrong. As, in this case, you patently are.

Richard
 
R

Richard Heathfield

[Context: How many platforms use dynamic linking?]

Mark McIntyre said:
On Mon, 20 Nov 2006 00:17:17 +0100, in comp.lang.c , jacob navia


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.

Just a data point, really - MVS has been using DLLs since forever (well, a
very long time, anyway), and quite possibly even before Bill Gates was a
sparkle in his mum's eye.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
 
R

Richard Heathfield

[Text reflowed, and one tiny, non-harmful edit (I added a colon).]

Andrew Poelstra said:
Ah, but we never finish, so this doesn't actually debunk Jacob's
point.

Yes, it does. Mr Navia incorrectly assumed that ALL processes under Windows
must terminate, which is clearly not the case. The counter-example exposes
the assumption and disproves the point at the same time.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
 
J

jacob navia

Mark McIntyre a écrit :
counter example

int main(void){for(;;) }




Mhm, but we never call it.

THAT code never calls it, but the startup code of
the program does.

Please study how main is called and what happens
after main returns. This will be described in your
compiler's documentation.

For someone whose messages are 80% insults you show
such a TOTAL ignorance...
 
J

jacob navia

Andrew Poelstra a écrit :
Ah, but we never finish, so this doesn't actually debunk Jacob's
point.

Your other comments elsethread all appear correct, however, although
harsher than I might have put them. :)

The startup code calls ExitProcess, not the code itself!!!!

Please consult your compiler's documentation or disassemble
the compiler's startup code!
 
J

jacob navia

Richard Bos a écrit :
Boy, when you find yourself having to use multiple exclamation marks to
get your point across it's high time to start considering that you just
might be wrong. As, in this case, you patently are.

Richard

There is NO way I could be wrong. The startup code
of the compiler calls ExitProcess AFTER main() has finished,
it is NOT main() that calls it.
 
J

jacob navia

Richard Heathfield a écrit :
[Text reflowed, and one tiny, non-harmful edit (I added a colon).]

Andrew Poelstra said:

Ah, but we never finish, so this doesn't actually debunk Jacob's
point.


Yes, it does. Mr Navia incorrectly assumed that ALL processes under Windows
must terminate, which is clearly not the case. The counter-example exposes
the assumption and disproves the point at the same time.
No. The call to ExitProcess is done in the startup code of the
compiler and will be called after main() returns.

If main() never returns the call to ExitProcess is STILL THERE
even if it is not used.
 
J

jacob navia

Mark McIntyre a écrit :
You talk utter dreck. Words fail me for how stupidly, arrogantly,
fatuously cretinously wrong you are.

It is funny how excited you get... It must hurt somewhere isn't it?
:)
Dynamic linking is probably one
of the most platform-specific things you can get, precisely _because_
it is used on many platforms.

The details are system specific. The principles are very
similar everywhere.
 
J

jacob navia

Mark McIntyre a écrit :
counter example

int main(void){for(;;) }




Mhm, but we never call it.

That API will be called from the code that calls main()
and cleans up after main exits!!!! The code that implements
atexit, and calls ExitProcess.

Such an elementary mistake is incredible from someone that
has programmed since such a long time heathfield.

When we compile that program with visual studio we get
following imports from kernel32.dll:
GetCommandLineA
HeapFree
GetVersionExA
HeapAlloc
GetProcessHeap
GetProcAddress
GetModuleHandleA
ExitProcess <---- see this one?
WriteFile
GetStdHandle
GetModuleFileNameA
RtlUnwindExt
UnhandledExceptionFilter
FreeEnvironmentStringsA
GetEnvironmentStrings
FreeEnvironmentStringsW
WideCharToMultiBytes
GetLastError
GetEnvironmentStringsW
SetHandleCount
GetFileType
GetStartupInfoA
DeleteCriticalSection
FlsGetValue
FlsSetValue
TlsFree
FlsFree
SetLastError
GetCurrentThreadId
FlsAlloc
HeapSetInformation
HeapCreate
QueryPerformanceCounter
GetTickCount
GetCurrentProcessId
GetSystemTimeAsFileTime
LeaveCriticalSection
EnterCriticalSection
TerminateProcess
GetCurrentProcess
SetUnhandledExceptionFilter
IsDebuggerPresent
CaptureContext
LoadLibraryA
InitializeCriticalSection
Sleep
GetCPInfo
GetACP
GetOEMCP
HeapSize
MultiByteToWideChar
GetLocaleInfoA
HeapReAlloc
MapStringA
MapStringW
GetStringTypeA
GetStringTypeW
RtlVirtualUnwind
RtlLookupFunctionEntry
 
K

Keith Thompson

jacob navia said:
Mark McIntyre a écrit : [...]
Dynamic linking is probably one
of the most platform-specific things you can get, precisely _because_
it is used on many platforms.

The details are system specific. The principles are very
similar everywhere.

But neither the principles nor the details are relevant to the C
programming language.
 
S

santosh

jacob said:
Richard Heathfield a écrit :
[Text reflowed, and one tiny, non-harmful edit (I added a colon).]

Andrew Poelstra said:

On Sun, 2006-19-11 at 23:41 +0000, Mark McIntyre wrote:

On Sun, 19 Nov 2006 17:58:25 +0100, in comp.lang.c , jacob navia

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

counter example: int main(void){for(;;) }


That API call is exported in Kernel32.dll.

Mhm, but we never call it.

Ah, but we never finish, so this doesn't actually debunk Jacob's
point.


Yes, it does. Mr Navia incorrectly assumed that ALL processes under Windows
must terminate, which is clearly not the case. The counter-example exposes
the assumption and disproves the point at the same time.
No. The call to ExitProcess is done in the startup code of the
compiler and will be called after main() returns.

If main() never returns the call to ExitProcess is STILL THERE
even if it is not used.

You can't assume that _all_ processes in Windows are implemented in C,
so the existence of main() is irrelevant to whether a process calls the
Win32 API functions, (or atleast ExitProcess()).

As I pointed out earlier, you can bypass dynamic loading of *.dll by
invoking the INT 0x2E interface. It's not sensible, but it _is_
possible.

Also, when you say _all_ processes, we'll have to also include system
tasks implemented as a driver, which need not use the Win32 API but
rather, call other kernel functions, as given in DDK.
 
S

santosh

jacob said:
Andrew Poelstra a écrit :

The startup code calls ExitProcess, not the code itself!!!!

Please consult your compiler's documentation or disassemble
the compiler's startup code!

For a compiler writer, you're making mistakes rather abundantly.

In a C program, ExitProcess() is automatically called _only_ when you
link with the standard C library. If you're writing a C program that
uses Win32 APIs but _not_ any standard C functions, then you'll have to
code an explicit ExitProcess() at the end of main().
 
J

jacob navia

santosh a écrit :
jacob said:
Richard Heathfield a écrit :
[Text reflowed, and one tiny, non-harmful edit (I added a colon).]

Andrew Poelstra said:



On Sun, 2006-19-11 at 23:41 +0000, Mark McIntyre wrote:


On Sun, 19 Nov 2006 17:58:25 +0100, in comp.lang.c , jacob navia


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

counter example: int main(void){for(;;) }



That API call is exported in Kernel32.dll.

Mhm, but we never call it.

Ah, but we never finish, so this doesn't actually debunk Jacob's
point.


Yes, it does. Mr Navia incorrectly assumed that ALL processes under Windows
must terminate, which is clearly not the case. The counter-example exposes
the assumption and disproves the point at the same time.

No. The call to ExitProcess is done in the startup code of the
compiler and will be called after main() returns.

If main() never returns the call to ExitProcess is STILL THERE
even if it is not used.


You can't assume that _all_ processes in Windows are implemented in C,
so the existence of main() is irrelevant to whether a process calls the
Win32 API functions, (or atleast ExitProcess()).

So, we agree (at last) that for all processes written in C you will
end up linking with the startup code and having a call to ExitProcess
anyway, whether main() returns or not!
As I pointed out earlier, you can bypass dynamic loading of *.dll by
invoking the INT 0x2E interface. It's not sensible, but it _is_
possible.

Yes, it is not sensible, and now you are writing in plain assembly, not
C.
Also, when you say _all_ processes, we'll have to also include system
tasks implemented as a driver, which need not use the Win32 API but
rather, call other kernel functions, as given in DDK.

Granted. I was speaking about programs written in C. Other
programs/languages I think are off topic in this newsgroup,
wouldn't you agree?

:)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top