Overview

[dvdsum]

Hello, my english is very poor, excuse me. I want that someone explains
several things.
Ok,

Windows, as well as other modern operating systems, gives a set of
functions called API. The programmer can access to the functionalities
of the system by them. Is it right? The functions are grouped, for
example kernel and user. Now, in a compiler as gcc what does
libkernel32.a represent? The dll are written in C and then why do we
use libkernel32.a and not kernel.dll?
What are files lib*.a? Thank you very much!

Bye

dvddum

[jacob navia]

Mark McIntyre a écrit :

On Sun, 19 Nov 2006 17:58:25 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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

[jacob navia]

Andrew Poelstra a écrit :

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
<ja***@jacob.remcomp.frwrote:

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

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!

[jacob navia]

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:

>>Kenny McCormack a écrit :

>>>I would assume that, for the benefit of the nitpickers, it could be said
that in order to invoke the GUI functions under Windows (see previous
disclaimers), you need to dynamically link to a DLL. I think Jacob
would be happy with that.

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

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.

[jacob navia]

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
<ja***@jacob.remcomp.frwrote:

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.

[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.

[jacob navia]

Mark McIntyre a écrit :

On Sun, 19 Nov 2006 17:58:25 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[santosh]

jacob navia wrote:

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
<ja***@jacob.remcomp.frwrote:

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.

[santosh]

jacob navia wrote:

Andrew Poelstra a écrit :

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
<ja***@jacob.remcomp.frwrote:

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.

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!

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().

[jacob navia]

santosh a écrit :

jacob navia wrote:

>>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
><ja***@jacob.remcomp.frwrote:
>
>
>>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?

:-)

[jacob navia]

santosh a écrit :

jacob navia wrote:

>>Andrew Poelstra a écrit :

>>>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
<ja***@jacob.remcomp.frwrote:
>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.

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!

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().

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.

When we compile the above 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

[Richard Heathfield]

jacob navia 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
<ja***@jacob.remcomp.frwrote:
>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.

No, ExitProcess is *not* called, not even by the startup code of the
compiler, because, in the counter-example given, main() never returns.

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

You said "ALL processes under windows must call ExitProcess to
finish!!!!!!", and in the counter-example given, ExitProcess is never
called. Therefore, your statement that it *must* be called is clearly
incorrect.

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

[jacob navia]

Richard Heathfield a écrit :

jacob navia 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
><ja***@jacob.remcomp.frwrote:
>
>>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.

No, ExitProcess is *not* called, not even by the startup code of the
compiler, because, in the counter-example given, main() never returns.

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

You said "ALL processes under windows must call ExitProcess to
finish!!!!!!", and in the counter-example given, ExitProcess is never
called. Therefore, your statement that it *must* be called is clearly
incorrect.

The call is still there, then you must link to kernel32, what needs
dynamic linking, the subject of this thread.

Then, my statement that all process (written in C) use dynamic linking
is correct.

[Richard Heathfield]

jacob navia said:

<snip>

>
The call is still there,

Irrelevant. You didn't claim a call exists in the code. You claimed that
ExitProcess *is called*. If the program never returns from main, and does
not itself call ExitProcess, then ExitProcess is *never* called by the
program.

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

[Kenny McCormack]

In article <B7********************@bt.com>,
Richard Heathfield <in*****@invalid.invalidwrote:
....

>You said "ALL processes under windows must call ExitProcess to
finish!!!!!!", and in the counter-example given, ExitProcess is never
called. Therefore, your statement that it *must* be called is clearly
incorrect.

As I am sure even *you* could see, there is more than one way to
interpret the English sentence: You must do <xin order to <y>.

Take the sentence: You must go to Nepal to climb Mount Everest.
While it is possible to interpret that to mean that everybody must go to
Nepal and climb Mount Everest, I think most of us understand that we
still have a choice in the matter. In fact, I doubt I will ever go to
Nepal, and I think my life will be fine and dandy despite that.

Semantically, I think this is all clear. Whether or not this all accurately
describes Jacob's position is unclear, given some of his later statements.

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.frwrote:

>Kenny McCormack a écrit :

I would assume that, for the benefit of the nitpickers, it could be said
that in order to invoke the GUI functions under Windows (see previous
disclaimers), you need to dynamically link to a DLL. I think Jacob
would be happy with that.

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.

There is NO way I could be wrong.

Yes, just you keep walking into that wall. I'm sure that some day,
you'll be right, and there'll be a door there. In the mean time, though,
doesn't it hurt?

Richard

[Al Balmer]

On Sat, 18 Nov 2006 23:53:09 +0100, jacob navia
<ja***@jacob.remcomp.frwrote:

>In any case I insist that it is NOT off topic to discuss shared
libraries here since it is an essential part of most implementations.

I'm really glad that I'm only a casual contributor to this newsgroup,
and not one of the real gurus who might feel an obligation to expose
the nonsense written by trolls.

It's taken a long time, but I'm in a bad mood this morning because of
Tisdale's return, and now's the time. Jacob, meet Edwin. I'll leave
you two alone, now. Bye.

--
Al Balmer
Sun City, AZ

[jacob navia]

Al Balmer a écrit :

On Sat, 18 Nov 2006 23:53:09 +0100, jacob navia
<ja***@jacob.remcomp.frwrote:

>>In any case I insist that it is NOT off topic to discuss shared
libraries here since it is an essential part of most implementations.

I'm really glad that I'm only a casual contributor to this newsgroup,
and not one of the real gurus who might feel an obligation to expose
the nonsense written by trolls.

It's taken a long time, but I'm in a bad mood this morning because of
Tisdale's return, and now's the time. Jacob, meet Edwin. I'll leave
you two alone, now. Bye.

Glad you are gone

[jacob navia]

Tor Rustad wrote:

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"

You left out the next sentence... I said:

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

You left OUT "to finish".

If you call Exit process using an obscure assembly interface
that is NOT the API (exposing yourself to the risks I described)
you are no longer within the context we were discussing. You
change the context (as you misquoted my words) to satisfy
your need to prove me 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. :-)

Linking is part of the language since it determines
1) The maximum length of identifiers
2) Which identifier will be "pulled in" from a library
determining the meaning of many identifiers.

The original poster asked for a clarification about linking, and my
answer was that: a clarification.

[Frederick Gotham]

jacob navia:

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

So your Windows compiler isn't a conformant C implementation.

Wow, I had come to expect so much from Microsoft, didn't think they'd EVER
slip up. Until they started programming of course.

--

Frederick Gotham

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

jacob navia said:

<snip>

>>
The call is still there,

Irrelevant. You didn't claim a call exists in the code. You claimed that
ExitProcess *is called*. If the program never returns from main, and does
not itself call ExitProcess, then ExitProcess is *never* called by the
program.

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tor Rustad]

jacob navia skrev:

>
You left out the next sentence... I said:

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

You left OUT "to finish".

What is your point?

I addressed that, and proved you WRONG!

If you call Exit process using an obscure assembly interface
that is NOT the API (exposing yourself to the risks I described)
you are no longer within the context we were discussing.

I have already stated that this can be done by calling
NTDLL.DLL... the asm call was there to show what
went on behind the scene.

The main point is that a conforming C implementation
can do it either way, the implementation spesific details
are not relevant for a C programmer... or c.l.c

You change the context (as you misquoted my words)
to satisfy your need to prove me wrong.

LOL.. my initial response had the full quote.

<gd&r>

--
Tor

[Ian Collins]

jacob navia wrote:

>
The proof is obvious:

ALL processes under windows must call

ExitProcess

to finish!!!!!!

That API call is exported in Kernel32.dll.

And people complain when I mention a C++ library object....

--
Ian Collins.

[Mark McIntyre]

On Mon, 20 Nov 2006 00:24:44 GMT, in comp.lang.c , Andrew Poelstra
<ap*******@false.sitewrote:

>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
<ja***@jacob.remcomp.frwrote:

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

I disagree, since he said, as quoted above, that all proceses must
call ExitProcess, and the above doesn't.
--
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 11:56:58 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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

>When we compile the above program with visual studio we get
following imports from kernel32.dll:
ExitProcess <---- see this one?

*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.
--
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:35:44 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>>On Sun, 19 Nov 2006 17:58:25 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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

But you said, quite clearly, that all processes must _call_
ExitProcess to finish. You've proved yourself incorrect by this
analysis.
--
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]

Tor Rustad wrote:

jacob navia skrev:

>>You left out the next sentence... I said:

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

You left OUT "to finish".

What is your point?

I addressed that, and proved you WRONG!

No, you presented a main() that doe'sn't return and doesn't
call ExitProcess. The call however is still there in the startup code
so dynamic linking is needed at program startup to resolve it anyway,
even if your program doesn't call it.

>

>>If you call Exit process using an obscure assembly interface
that is NOT the API (exposing yourself to the risks I described)
you are no longer within the context we were discussing.

I have already stated that this can be done by calling
NTDLL.DLL... the asm call was there to show what
went on behind the scene.

You can't call it using the documented C interface. If you use
assembly or "undocumented windows" stuff, this is no longer
a C interface and we can discuss assembly language or whatever.

The main point is that a conforming C implementation
can do it either way, the implementation spesific details
are not relevant for a C programmer... or c.l.c

No, a conforming compiler will not compile a program that will
stop working when a minor change to the OS is done.

Practically of course.

In your hypothetical world, you would call directly
ntdll.dll, tying the generated program to a specific
version of the OS... What a nonsense!

[Mark McIntyre]

On Mon, 20 Nov 2006 09:32:02 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

When? The programme doesn't return to the startup routine.

>Please study how main is called and what happens
after main returns.

Newsflash: It doesn't return.

>This will be described in your compiler's documentation.

Humorous. I assume you document this in the lcc-win32 documentation.

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

Coming from someone whose messages are 80% ignorance and 20%
invective, thats quite amusing.
--
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:33:58 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>
There is NO way I could be wrong.

And therein lies the basic problem you have - total faith in your own
infallibility. What is it that pride cometh before?
--
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]

Mark McIntyre wrote:

On Mon, 20 Nov 2006 09:35:44 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>>>On Sun, 19 Nov 2006 17:58:25 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>ALL processes under windows must call ExitProcess to finish!!!!!!

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

But you said, quite clearly, that all processes must _call_
ExitProcess to finish. You've proved yourself incorrect by this
analysis.

I was presented with an infinite loop in main() The argument was:

Since main() never returns, it doesn't call ExitProcess, so the call
to ExitProcess is not needed.

I answered:

The call is still there even if it is not used. At program startup,
the dynamic linker must resolve it, even if there will
never be an actual call to that API.

This means, that all processes (written in C) have quite a lot of
APIs in there, at least the ExitProcess call.

Other APIs that are always called are GetCommandLineArgs(), to get
the arguments argv[] from the system, to pass them to the main()
function.

[Mark McIntyre]

On Mon, 20 Nov 2006 09:38:01 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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
<ja***@jacob.remcomp.frwrote:

(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]

Mark McIntyre wrote:

On Mon, 20 Nov 2006 11:56:58 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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

>

>>When we compile the above program with visual studio we get
following imports from kernel32.dll:
ExitProcess <---- see this one?

*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]

Mark McIntyre wrote:

On Mon, 20 Nov 2006 09:38:01 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

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

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
<ja***@jacob.remcomp.frwrote:

(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:

<snip>

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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Kenny McCormack]

In article <bt******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Keith Thompson said:

<snip>

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

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.

[Alf P. Steinbach]

* Richard Heathfield:

Keith Thompson said:

<snip>

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

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].

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Old Wolf]

Mark McIntyre wrote:

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.

[CBFalconer]

Keith Thompson wrote:

Richard Heathfield <in*****@invalid.invalidwrites:

>jacob navia said:

<snip>

>>>
The call is still there,

Irrelevant. You didn't claim a call exists in the code. You claimed
that ExitProcess *is called*. If the program never returns from
main, and does not itself call ExitProcess, then ExitProcess is
*never* called by the program.

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Andrew Poelstra]

On Tue, 2006-21-11 at 00:26 +0000, Richard Heathfield wrote:

Keith Thompson said:

<snip>

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.

It will end. It will not finish.

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

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use [first_name].[last]@gmail.com
"You're only smart on the outside." -anon.

[Richard Heathfield]

Andrew Poelstra said:

On Tue, 2006-21-11 at 00:26 +0000, Richard Heathfield wrote:

>Keith Thompson said:

<snip>

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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Dollin]

Richard Heathfield wrote:

Keith Thompson said:

<snip>

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

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.

--
Chris "VOOM? What means this VOOM?" Dollin
"The path to the web becomes deeper and wider" - October Project

[jacob navia]

Chris Dollin wrote:

Richard Heathfield wrote:

>>Keith Thompson said:

<snip>

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

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 Heathfield wrote:

>Keith Thompson said:

<snip>

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

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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

jacob navia said:

<snip>

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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Dollin]

jacob navia wrote:

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.

--
Chris "VOOM? What means this VOOM?" Dollin
Scoring, bah. If I want scoring I'll go play /Age of Steam/.

[Kenny McCormack]

In article <ej**********@murdoch.hpl.hp.com>,
Chris Dollin <ch**********@hp.comwrote:
....

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

[...]

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

[...]

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.

--
Tor

[Richard Heathfield]

Tor Rustad said:

jacob navia skrev:

<snip>

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

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>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.