Overview

[jacob navia]

santosh a écrit :

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:

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.

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

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:

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]

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 <x> in 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]

Richard Bos a écrit :

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]

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.

 

[jacob navia]

Al Balmer a écrit :

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]

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.

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.

 

[Keith Thompson]

jacob navia said:



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

 

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

 

[Ian Collins]

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

 

[Mark McIntyre]

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]

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]

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]

jacob navia skrev:



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.

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]

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]

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]

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.