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

[santosh]

dvdsum wrote:

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!

This group tries to confine itself to the standard C language. Posting
is a more specific group like comp.os.ms-windows.programmer etc., will
yield you a better and more accurate response. To answer you just this
once, the *.a files are 'import' files which enable proper compilation
and runtime loading of the corresponding *.dll.

[jacob navia]

dvdsum a écrit :

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

Compiled functions are grouped in files called "libraries". Those files
contain several compiled functions that perform various functions like
drawing a line, opening a file, making coffee, etc.

Libraries are normally called file.lib under windows, or libfile.a under
Unix. Since gcc comes from Unix, it names its libraries .a instead of
..lib.

Libraries can come in two "flavors". Normal "static" libraries, that
contain the code of the functions, and "import" libraries that are
just stubs that tell the dynamic linker/loader where those functions
are actually defined. When you use a dll (or a shared object using Unix
naming conventions) your libraries allows your executable to be
associated to a dynamic library (a .dll under windows a .so under
Unix). In your example libkernel32.a just associates some of
the functions that you use in your program with kernel32.dll.

Under windows you can use the dll directly (without linking to it) by
using the LoadLibrary API. Under Unix you use dlopen() or similar
functions. Note that you must link the dll that contains the
LoadLibrary API STATICALLY, you can't load kernel32.dll dynamically
since it containes the LoadLibrary API. In the same manner
it doesn't make sense to load the library that contains dlopen()
using dlopen() :-)

[Flash Gordon]

jacob navia wrote:

<snip>

associated to a dynamic library (a .dll under windows a .so under
Unix). In your example libkernel32.a just associates some of
the functions that you use in your program with kernel32.dll.

<snip>

Please redirect off topic questions to an appropriate place where your
errors will be corrected. If you want to know what the error is in the
above then *you* will have to ask in an appropriate group, I'll just say
that I know from personal experience that it is wrong in general
although had you been more specific it could have been correct.
--
Flash Gordon

[Kenny McCormack]

In article <9u************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

>jacob navia wrote:

<snip>

>associated to a dynamic library (a .dll under windows a .so under
Unix). In your example libkernel32.a just associates some of
the functions that you use in your program with kernel32.dll.

<snip>

Please redirect off topic questions to an appropriate place where your
errors will be corrected. If you want to know what the error is in the
above then *you* will have to ask in an appropriate group, I'll just say
that I know from personal experience that it is wrong in general
although had you been more specific it could have been correct.

You're the sort who would tell someone that the phrase "The sun rises in
the East" is incorrect/worthless/immoral/fattening because of the
possibility that there might exists planets/worlds in which it doesn't
hold.

Technically right, I suppose, but, obviously, from the POV of any sane
person, utter BS.

[Richard Heathfield]

[Just debunking some trollschildt]

Kenny McCormack said:

<snip>

You're the sort who would tell someone that the phrase "The sun rises in
the East" is incorrect/worthless/immoral/fattening because of the
possibility that there might exists planets/worlds in which it doesn't
hold.

It's incorrect for Venus, for example.

Technically right, I suppose, but, obviously, from the POV of any sane
person, utter BS.

So astronomers are not sane. How interesting.

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

[Flash Gordon]

Richard Heathfield wrote:

[Just debunking some trollschildt]

Kenny McCormack said:

<snip>

>You're the sort who would tell someone that the phrase "The sun rises in
the East" is incorrect/worthless/immoral/fattening because of the
possibility that there might exists planets/worlds in which it doesn't
hold.

It's incorrect for Venus, for example.

Indeed.

As it happens, on my post I had in mind a specific implementation that
comes from a large company and it used for mayor implementations by
other large companies. It happens to be an implementation I develop SW
for so I have had to learn about it. Still, one doesn't expect Kenny to
know about such things, or admit such knowledge if it is inconvenient to
his trolling.

>Technically right, I suppose, but, obviously, from the POV of any sane
person, utter BS.

So astronomers are not sane. How interesting.

They may well be, I have no evidence on the matter, but it does not
prevent them from being correct ;-)
--
Flash Gordon

[Kenny McCormack]

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

>[Just debunking some trollschildt]

Kenny McCormack said:

<snip>

>You're the sort who would tell someone that the phrase "The sun rises in
the East" is incorrect/worthless/immoral/fattening because of the
possibility that there might exists planets/worlds in which it doesn't
hold.

It's incorrect for Venus, for example.

>Technically right, I suppose, but, obviously, from the POV of any sane
person, utter BS.

So astronomers are not sane. How interesting.

Because anyone with a lick of common sense (something mostly missing in
the regs of this ng) knows perfectly well that the phrase is meant to
apply to this world (aka, the Earth) - the only planet that has any
human life on it - i.e., anyone to notice or care about the sun rising.

Obviously, the nit-shits of this ng will find a way to pick at that, too.

[Frederick Gotham]

Kenny McCormack:

Because anyone with a lick of common sense (something mostly missing in
the regs of this ng) knows perfectly well that the phrase is meant to
apply to this world (aka, the Earth) - the only planet that has any
human life on it - i.e., anyone to notice or care about the sun rising.

Obviously, the nit-shits of this ng will find a way to pick at that, too.

Yes, and that's because you weren't specific enough.

On comp.lang.c, the topic tends to be _very_ broad, given that we don't
talk about any one implementation in particular. If you want to talk about
machines which have 8-Bit bytes, then you'll had to introduce that as a
precondition to the discussion. If you don't produce that precondition,
then everyone is right to correct your false assumption that CHAR_BIT==8.

In every day speech, like Billy talking to James over a cup of coffee,
there's nothing wrong with saying that the Sun rises in the East, just like
there's nothing wrong with assuming 8-Bit bytes on a Windows programming
newsgroup.

This newsgroup deals with the C programming language in its most basic
form, the form described by the C Standard. The C Standard gives freedom to
implementations, even if these freedoms are only exploited rarely. For
instance, the C Standard gives freedom to the implementation to have any
size bytes (over 7 bits of course), but I think only a very small
proportion of implementations actually depend on this freedom.

If you're in an astronomy newsgroup, I wouldn't suggest saying that the Sun
rises in the East. It's not to bad an idea though if you're in an Earth-
related newsgroup though.

--

Frederick Gotham

[CBFalconer]

Frederick Gotham wrote:

>

.... snip ...

>
If you're in an astronomy newsgroup, I wouldn't suggest saying that
the Sun rises in the East. It's not to bad an idea though if you're
in an Earth- related newsgroup though.

Since East describes the direction from which the sun rizes, I
would expect it to be unambiguous for all worlds orbiting about a
single sun and having a rotation.

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

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Kenny McCormack:

[the usual]

Yes, and that's because you weren't specific enough.

[snip]

I'll probably be flamed for saying this again, but I don't care.

*Please* don't feed the troll.

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

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>Frederick Gotham <fg*******@SPAM.comwrites:

>Kenny McCormack:

[the usual]

>Yes, and that's because you weren't specific enough.

[snip]

I'll probably be flamed for saying this again, but I don't care.

*Please* don't feed the troll.

Since you asked...

If they want to feed me, I think they are well within their rights to do so.

[jacob navia]

Flash Gordon a écrit :

jacob navia wrote:

<snip>

>associated to a dynamic library (a .dll under windows a .so under
Unix). In your example libkernel32.a just associates some of
the functions that you use in your program with kernel32.dll.

<snip>

Please redirect off topic questions to an appropriate place where your
errors will be corrected. If you want to know what the error is in the
above then *you* will have to ask in an appropriate group, I'll just say
that I know from personal experience that it is wrong in general
although had you been more specific it could have been correct.

There is nothing wrong with what I said.
If you call the function in your program

CreateFile (...)

the .a library just tells the linker to link a stub procedure
with the corresponding system dll. When the program loads, the loader
patches that stub with the run time address of that dll, mapped into
your address space.

Nowadays there are other (more sophisticated) methods like delay
loading etc, but basically they are refinements of the basic schema.

And, as you may know, I do not consider this as off topic since it
touches one of the core features of the language: actual runtime
binding to functions.

[Keith Thompson]

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

Flash Gordon a écrit :

>jacob navia wrote:
<snip>

>>associated to a dynamic library (a .dll under windows a .so under
Unix). In your example libkernel32.a just associates some of
the functions that you use in your program with kernel32.dll.

<snip>
Please redirect off topic questions to an appropriate place where
your errors will be corrected. If you want to know what the error is
in the above then *you* will have to ask in an appropriate group,
I'll just say that I know from personal experience that it is wrong
in general although had you been more specific it could have been
correct.

There is nothing wrong with what I said.
If you call the function in your program

CreateFile (...)

the .a library just tells the linker to link a stub procedure
with the corresponding system dll. When the program loads, the loader
patches that stub with the run time address of that dll, mapped into
your address space.

Nowadays there are other (more sophisticated) methods like delay
loading etc, but basically they are refinements of the basic schema.

And, as you may know, I do not consider this as off topic since it
touches one of the core features of the language: actual runtime
binding to functions.

And you are mistaken. This is not a core feature of the language; it
is a core feature of some *implementations* of the language.

I have access to a copy of the ISO C standard (the document that
defines the C programming language, which is the topic of this
newsgroup), and I'm quite familiar with most of it. I also own copies
K&R (1st and 2nd editions) and H&S (4th and 5th editions). Those
resources so not give me the ability to judge the accuracy of what
you've written. There is no mention of ".a" libraries or "dll"s. And
in fact, I use systems that do not have anything called "dll"s, though
they may have something that serves a similar purpose. Those systems
do have ".a" files (archives), but I don't believe they're anything
like what you describe (<OT>they're used for static linking</OT>).

If what you're talking about is not mentioned in the C standard, and
if it's something that can vary widely from one implementation to
another, that should be a clue that it's off-topic here.

I don't expect this to get through to you, but I'm prepared to be
pleasantly surprised.

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

[jacob navia]

Keith Thompson a écrit :

>
And you are mistaken. This is not a core feature of the language; it
is a core feature of some *implementations* of the language.

There is nothing else but IMPLEMENTATIONS of the language.

Everything else is just abstract talk, that is good to avoid answering
questions but not much else.

Yes, neither the standard document mention dlls or .so, whatever.
And I do not care, since those documents aren't the BIBLE, but just
documents that present a formal dexription of the language. For a
concrete description (what the original poster was asking) it is
better to use concrete examples.

And since the user mentioned that he used cygwin, where the
libraries are called .a but are in fact import libraries, I followed
that example This made mr "Flash Gordon" start complaining because he
has mistaken .a with Unix probably or whatever.

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 would like to remind all people here about your beloved FAQ, where
MSDOS is discussed in detail.

19.40c: I'm trying to compile a program in which "union REGS" and
int86() are undefined.

A: Those have to do with MS-DOS interrupt programming.

That is very important to be mentioned in the FAQ 2006. But just
a general answer about shared objects is shunned !!!
WHY???

Because everybody was 15 years younger then, and the people here have
retreated into some abstract idea of "C" without caring to look around
and see what is happening elsewhere.

This is welcome by all people that think that C is an obsolete language
and we should start doing C++. Everybody agrees, everybody is happy.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[snip]

This is welcome by all people that think that C is an obsolete language
and we should start doing C++. Everybody agrees, everybody is happy.

Nonsense. You should know better.

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

[Mark McIntyre]

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

>Keith Thompson a écrit :

>>
And you are mistaken. This is not a core feature of the language; it
is a core feature of some *implementations* of the language.

There is nothing else but IMPLEMENTATIONS of the language.

Ignoring the fact that this is plain and utter bollocks, so what?
Since not all implementations include the concept you're discussion,
it cannot be a core feature of the language.

>Everything else is just abstract talk, that is good to avoid answering
questions but not much else.

Mhm, and art is just abstract splattering with paint, and most maths
is worthless babbling and as for science...

>Yes, neither the standard document mention dlls or .so, whatever.
And I do not care,

Yes, thats evident. You an arrogant arse who thinks that standards are
for others. Other people with similar arritudes run red lights,
drink-drive and piss in public. Do you *really* want to align yourself
with them?

>I would like to remind all people here about your beloved FAQ,

Perhaps you ought to reflect on what a FAQ is for.

>where MSDOS is discussed in detail.

In a special section "System Dependencies" whose title and body makes
it abundantly clear that you're outside standard C.

>19.40c: I'm trying to compile a program in which "union REGS" and
int86() are undefined.

A: Those have to do with MS-DOS interrupt programming.

*this* is your definition of detail? I sincerely hope your attention
to detail is better than this in your actual code.

>That is very important to be mentioned in the FAQ 2006. But just
a general answer about shared objects is shunned !!!

WHY???

Because there is no general answer. Still, if you think it ought to be
a FAQ, feel free to prepare one and submit it to Steve.

>This is welcome by all people that think that C is an obsolete language
and we should start doing C++. Everybody agrees, everybody is happy.

Fuckwit.

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

[Flash Gordon]

jacob navia wrote:

<snip>

And since the user mentioned that he used cygwin, where the
libraries are called .a but are in fact import libraries, I followed
that example This made mr "Flash Gordon" start complaining because he

No need to put my chosen handle in quotes, it implies I am hiding my
identity which I am not. You can even use my real name if you want,
anyone who knows anything about who the internet works can find it, so
can anyone who knows how to check posting history.

has mistaken .a with Unix probably or whatever.

Try reading the part of your message I quoted. It was *you* who brought
up Unix.

|jacob navia wrote:
|
|<snip>
|
|associated to a dynamic library (a .dll under windows a .so under
^^^^^^^^^
|Unix). In your example libkernel32.a just associates some of
^^^^
|the functions that you use in your program with kernel32.dll.

If you can't even get straight what you introduce in to the conversation
and what others introduced why should we rely on your memory of other
things?

If anyone wants to know the error all they have to do is ask other than
here.

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've yet to come across *any* implementation where shared libraries are
essential. Just a few example, Cygwin, MSVC++ and gcc under Linux are
all quite capable of producing statically linked programs. That's just a
few of the implementations I've done significant work on.

<snip>

This is welcome by all people that think that C is an obsolete language
and we should start doing C++. Everybody agrees, everybody is happy.

It has been pointed out to you many times that this is not what most
people here think. In fact, the only people I can recall saying such
things as their own opinions are known trolls.

My interpretation of people making serious contributions to this group
would be that they think C is still important and relevant, otherwise
why would they bother? I don't claim that is what others think, just
that it seems to me a more likely interpretation of their participation.
I, at any rate, do not consider it obsolete since I know far too much
about the real world.
--
Flash Gordon

[jacob navia]

Flash Gordon a écrit :

>
I've yet to come across *any* implementation where shared libraries are
essential. Just a few example, Cygwin, MSVC++ and gcc under Linux are
all quite capable of producing statically linked programs. That's just a
few of the implementations I've done significant work on.

Here you show your ignorance. This is completely wrong for Windows. ALL
programs under windows link dynamically with the kernel dlls, and they
at least MUST link dynamically with kernel32.dll.

Note that when I disagree I tell you why, without having your arrogant
position of:

"you are wrong but I will not tell you why" nonsense.

[Kenny McCormack]

In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>Flash Gordon a écrit :

>>
I've yet to come across *any* implementation where shared libraries are
essential. Just a few example, Cygwin, MSVC++ and gcc under Linux are
all quite capable of producing statically linked programs. That's just a
few of the implementations I've done significant work on.

The logic, such as it is, goes something like this:

It is possible to imagine an implementation where shared
libraries are not essential. In fact, such implementations
do actually exist. Since all implementations are "essentially
identical", it follows that shared libraries are not essential
in any implementation.

Have I got that right, Flashy?

>Here you show your ignorance. This is completely wrong for Windows. ALL
programs under windows link dynamically with the kernel dlls, and they
at least MUST link dynamically with kernel32.dll.

Note that when I disagree I tell you why, without having your arrogant
position of:

"you are wrong but I will not tell you why" nonsense.

Very well put. You've got his number. If you Google up my posting
history, you will see a post some time back where I note that rule one
of debating is that you never build up your own position, since all that
does is give your opponent a target. Instead, all you do is pick at
your opponent's position. Thus, it follows that the first person who
advances a position, loses. If neither do, then you have a stalemate.
That this ng is mostly stalemate should, then, come as no surprise.

P.S. And I love how he claims that "Flash Gordon" is his real name,
well, not really his real name, but sort of his real name, and thus
shouldn't be enclosed in scare quotes.

[Mark McIntyre]

On Sun, 19 Nov 2006 10:50:15 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Flash Gordon a écrit :

>>
I've yet to come across *any* implementation where shared libraries are
essential. Just a few example, Cygwin, MSVC++ and gcc under Linux are
all quite capable of producing statically linked programs. That's just a
few of the implementations I've done significant work on.

Here you show your ignorance. This is completely wrong for Windows.

No its not, and by the way your response displays your own arrogance.

>ALL programs under windows link dynamically with the kernel dlls, and they
at least MUST link dynamically with kernel32.dll.

On any system, you need to call hardware routines. Generally this is
done by some system-specific method. If you insist on calling this
"dynamic linkage" then you're axiomatically right. Most people think
of dynamic linkage as specifically calling user-mode software routines
via a runtime load method. By that definition, you're wrong.

>Note that when I disagree I tell you why, without having your arrogant
position of:

You /do/ realise that this statement is initself unsufferably
arrogant?
--
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

[Kenny McCormack]

In article <0u********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
....

>You /do/ realise that this statement is initself unsufferably
arrogant?

You /do/ realise that everybody in this newsgroup thinks of you as a
goon (*), don't you?

(*) In the sense of (would be/wannabee) enforcer.

[CBFalconer]

jacob navia wrote:

Flash Gordon a écrit :

>>
I've yet to come across *any* implementation where shared libraries
are essential. Just a few example, Cygwin, MSVC++ and gcc under
Linux are all quite capable of producing statically linked programs.
That's just a few of the implementations I've done significant work
on.

Here you show your ignorance. This is completely wrong for Windows.
ALL programs under windows link dynamically with the kernel dlls,
and they at least MUST link dynamically with kernel32.dll.

Note that when I disagree I tell you why, without having your
arrogant position of:

"you are wrong but I will not tell you why" nonsense.

Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked. They do not call the
Windows dlls at all. They do call the interrupt 0x21 links. How
these are implemented is another matter, but the results function
without Windoze executing at all.

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

[jacob navia]

CBFalconer a écrit :

jacob navia wrote:

>>Flash Gordon a écrit :

>>>I've yet to come across *any* implementation where shared libraries
are essential. Just a few example, Cygwin, MSVC++ and gcc under
Linux are all quite capable of producing statically linked programs.
That's just a few of the implementations I've done significant work
on.

Here you show your ignorance. This is completely wrong for Windows.
ALL programs under windows link dynamically with the kernel dlls,
and they at least MUST link dynamically with kernel32.dll.

Note that when I disagree I tell you why, without having your
arrogant position of:

"you are wrong but I will not tell you why" nonsense.

Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked. They do not call the
Windows dlls at all. They do call the interrupt 0x21 links. How
these are implemented is another matter, but the results function
without Windoze executing at all.

You are running in a dos extender Chuck, not under
windows. Obviously your dos extender has another interface as
windows programs (using interrupts, not by loading
dynamically OS dlls).

[jacob navia]

Mark McIntyre a écrit :

On Sun, 19 Nov 2006 10:50:15 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>Flash Gordon a écrit :

>>>I've yet to come across *any* implementation where shared libraries are
essential. Just a few example, Cygwin, MSVC++ and gcc under Linux are
all quite capable of producing statically linked programs. That's just a
few of the implementations I've done significant work on.

Here you show your ignorance. This is completely wrong for Windows.

No its not, and by the way your response displays your own arrogance.

>>ALL programs under windows link dynamically with the kernel dlls, and they
at least MUST link dynamically with kernel32.dll.

On any system, you need to call hardware routines. Generally this is
done by some system-specific method. If you insist on calling this
"dynamic linkage" then you're axiomatically right. Most people think
of dynamic linkage as specifically calling user-mode software routines
via a runtime load method. By that definition, you're wrong.

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

Any of those needs a windows system dll, either kernel32, or avdapi32 or
some of those.

Maybe it can be done but that would be an academic exercise.

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"

and that is it. But in my personal opinion that is far from enough.

[Mark McIntyre]

On Sun, 19 Nov 2006 16:22:24 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>CBFalconer a écrit :

>>
Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked.

Obviously your dos extender has another interface as
windows programs (using interrupts, not by loading
dynamically OS dlls).

So you agree that DLLs are *not* necessary after all?
--
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

[Kenny McCormack]

In article <t8********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>On Sun, 19 Nov 2006 16:22:24 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>CBFalconer a écrit :

>>>
Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked.

Obviously your dos extender has another interface as
windows programs (using interrupts, not by loading
dynamically OS dlls).

So you agree that DLLs are *not* necessary after all?

He never claimed that there does not exist an OS/implementation in which
DLLs are not necessary. He claims that under Windows (as we normally
interpret that term - don't go all girly trying to nitpick what that
word means), they are necessary.

Whether or not Chucky was running under Windows is not entirely clear
(his text seems to claim both that he was and that he wasn't), but if
so, he was running at a DOS (aka, console) prompt, so in some sense, it
could be said that he wasn't running Windows.

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.

[santosh]

Kenny McCormack wrote:

In article <t8********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

On Sun, 19 Nov 2006 16:22:24 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>CBFalconer a écrit :

Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked.

Obviously your dos extender has another interface as
windows programs (using interrupts, not by loading
dynamically OS dlls).

So you agree that DLLs are *not* necessary after all?

<snip>

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.

<OT nit:)
_Any_ Win32 program will need to dynamically load atleast NTDLL.DLL.
The only other way is to call the obscure software interrupt directly,
(INT 0x2E).

DJGPP emits 32 bit DPMI programs, and as such, need a DPMI extender on
top of DOS. Under Windows, they run in Intel's V86 mode, (Windows
supplies a DPMI extender). In either case, they have nothing to do with
32 bit parts of Windows like the XXXXX.dll files.
</OT nit>

[jacob navia]

Mark McIntyre a écrit :

On Sun, 19 Nov 2006 16:22:24 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>CBFalconer a écrit :

>>>Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked.

Obviously your dos extender has another interface as
windows programs (using interrupts, not by loading
dynamically OS dlls).

So you agree that DLLs are *not* necessary after all?

If you are not running windows it can be that you link
everything statically.

And if you are running in the embedded DSP system
I programmed last year there is no dynamic linker,
nor any linker at all. Just an EPROM and 4K RAM.

And so what?

The original poster was speaking about cygwin...

In workstations OS like Linux/Windows/Mac (that
runs a BSD-like Unix) dynamic linking to the
system shared objects is the rule.

Still, you have failed to point out what is
wrong with my assertions or produce any counter example
or somehow subtatiate your claims...

[jacob navia]

Kenny McCormack a écrit :

In article <t8********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>On Sun, 19 Nov 2006 16:22:24 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>>CBFalconer a écrit :

Once more, you show your lack of knowledge. I use DJGPP regularly,
and their programs are statically linked.

Obviously your dos extender has another interface as
windows programs (using interrupts, not by loading
dynamically OS dlls).

So you agree that DLLs are *not* necessary after all?

He never claimed that there does not exist an OS/implementation in which
DLLs are not necessary. He claims that under Windows (as we normally
interpret that term - don't go all girly trying to nitpick what that
word means), they are necessary.

Whether or not Chucky was running under Windows is not entirely clear
(his text seems to claim both that he was and that he wasn't), but if
so, he was running at a DOS (aka, console) prompt, so in some sense, it
could be said that he wasn't running Windows.

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

That API call is exported in Kernel32.dll.

[Keith Thompson]

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

ALL processes under windows must call

ExitProcess

to finish!!!!!!

That API call is exported in Kernel32.dll.

I can't judge the accuracy of those statements, but surely they're
equally applicable to Windows programs written in *any* language, and
entirely inapplicable to C programs running under operating systems
other than Windows. This should tell you that this is off-topic here.

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

[Flash Gordon]

jacob navia wrote:

Flash Gordon a écrit :

>>
I've yet to come across *any* implementation where shared libraries
are essential. Just a few example, Cygwin, MSVC++ and gcc under Linux
are all quite capable of producing statically linked programs. That's
just a few of the implementations I've done significant work on.

Here you show your ignorance. This is completely wrong for Windows. ALL
programs under windows link dynamically with the kernel dlls, and they
at least MUST link dynamically with kernel32.dll.

I did not specify which version of Windows... Windows 1.0 anyone? ;-)
By the way, the MS documentation on MSDN specifically refers to
statically linking to DLLs, although they don't mean quite what most
people mean when they talk about static linking, so even Windows XP it
is possible to build something that MS would call statically linked even
though it does use kernel32.dll and other DLLs. So although you are
possibly right about linking to kernel32.dll (although others here say
it is not required), you are wrong according to the MS documentation
about *dynamically* linking to it!

See, I'll even admit the possibility of being wrong (but not the
certainty). You, on the other hand, conveniently ignore that you accused
me of bringing Unix in to the discussion when it was you that made
claims about Unix originally.

Things may have changed on Windows since I last looked, but gcc under
Linux and under Unix distributions I use do not require dynamic linking.
Some applications are even deliberately built as "standard" to be
entirely statically linked so you can use them to recover your system
after completely trashing your shared libraries.

Note that when I disagree I tell you why, without having your arrogant
position of:

"you are wrong but I will not tell you why" nonsense.

I didn't say I would not tell you, I said I would not tell you here
since it is not topical.

I will not discus this further here because it is not topical. As I said
earlier, if you want to find out about specifically what you got wrong
in the text I quoted ask else where.
--
Flash Gordon

[Flash Gordon]

Kenny McCormack wrote:

<snip>

P.S. And I love how he claims that "Flash Gordon" is his real name,
well, not really his real name, but sort of his real name, and thus
shouldn't be enclosed in scare quotes.

I have never claimed it to be my name, merely the handle I use on
Usenet, and that it does not need to be enclosed in quotes implying I am
hiding my identity. Anyone could easily find my real name and with a bit
of research the town I live in. Hell, you could find out the town I grew
up in, where I've been on holiday and some photos of me if you wanted!
--
Flash Gordon

[jacob navia]

Keith Thompson a écrit :

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

>>ALL processes under windows must call

ExitProcess

to finish!!!!!!

That API call is exported in Kernel32.dll.

I can't judge the accuracy of those statements, but surely they're
equally applicable to Windows programs written in *any* language, and
entirely inapplicable to C programs running under operating systems
other than Windows. This should tell you that this is off-topic here.

http://www-128.ibm.com/developerwork.../l-shlibs.html
< quote >
Shared libraries are a fundamental component for the efficient use of
space and resources on a modern UNIX® system. The C library on a SUSE
9.1 system is made up of about 1.3 MB. A copy of that library for every
program in /usr/bin (and I have 2,569!) would take up a couple of
gigabytes of space.

Of course this number is inflated -- statically linked programs would
incorporate only those parts of the library that they use. Nonetheless,
the amount of space tied up by all those duplicate copies of printf()
would give the system a very bloated feel.

Shared libraries can save memory, not just disk space. The kernel can
keep a single copy of a shared library in memory, sharing it among
multiple applications. So, not only do we only have one copy of printf()
on the disk, we only have one in memory. That has a pretty noticeable
effect on performance.
< / end quote>

Please read the rest of the article in that URL to know
more about shared libraries under Unix systems Keith.

OS/390???

Please download the red book:

http://www.redbooks.ibm.com/redbooks/pdfs/sg245992.pdf

In section 4.3.1 you will learn more about DLLs (yes, they are called
like that!) under System/390.

Dynamic linking is a BASIC COMPONENT of any modern OS Keith.
And since C is almost everywhere the basic interface to the OS
the C library is almost always in the form of a dynamicly loaded
object.

I insist this is on-topic here, and by the way, as on topic as
the FAQ about MSDOS registers structure...

Why stop with MSDOS?

C is a systems programming language and as such dynamic linking
touches C, even if not described in the standard. This is NOT
comp.std.c

jacob

[jacob navia]

Flash Gordon a écrit :

See, I'll even admit the possibility of being wrong (but not the
certainty).

Thanks Mr Gordon...

What is important for me is to come back to that open mind that is
documented in the FAQ. I find GOOD that the FAQ (when it was written
back in the good old MSDOS days) spoke about TSRs, MSDOS stuff like the
"registers" structure, etc.

Because then, people were less "static", i.e. they would accept looking
beyond the standard, beyond the rigid schemas that have grown so
suffocating.

I just replied to a user that was asking for minformation. I tried to be
genaral and not limit my answer to windows, even if the question
of the original poster was about windows.

THAT'S WHY I spoke about UNIX.

jacob

[Flash Gordon]

jacob navia wrote:

<snip>

In workstations OS like Linux/Windows/Mac (that
runs a BSD-like Unix) dynamic linking to the
system shared objects is the rule.

The norm, not the rule. There are *extremely* good reasons why some
programs are *not* dynamically linked.

Still, you have failed to point out what is
wrong with my assertions or produce any counter example
or somehow subtatiate your claims...

OK, I'm bored, I'll give you a counter example. sash.
home tmp # which sash
/bin/sash
home tmp # ldd /bin/sash
not a dynamic executable
home tmp # /bin/sash
Stand-alone shell (version 3.7)
$ exit
home tmp #

See, a pretty much standard Linux program that is not dynamically linked
to *anything*. Since you including Linux in your list above, this is a
valid counter example to your current claim.

Now stop claiming to know what goes on in the Linux and Unix worlds as
there is obviously a vast quantity that you do *not* know about such
systems however much you might know about Windows.
--
Flash Gordon

[Flash Gordon]

jacob navia wrote:

Flash Gordon a écrit :

>See, I'll even admit the possibility of being wrong (but not the
certainty).

<snip>

Because then, people were less "static", i.e. they would accept looking
beyond the standard, beyond the rigid schemas that have grown so
suffocating.

You fail to recognise that we *regularly* go beyond the standard, just
not here. People regularly get told they should use things not covered
in the standard and often get told the correct places to ask about such
things.

I just replied to a user that was asking for minformation. I tried to be
genaral and not limit my answer to windows, even if the question
of the original poster was about windows.

THAT'S WHY I spoke about UNIX.

The problem is you do not know as much as you think you do about Unix as
you regularly demonstrate when you assert something about it and you
fail to redirect people to the proper places for discussing such things.
--
Flash Gordon

[Flash Gordon]

jacob navia wrote:

Keith Thompson a écrit :

>jacob navia <ja***@jacob.remcomp.frwrites:
[...]

>>ALL processes under windows must call

ExitProcess

to finish!!!!!!

That API call is exported in Kernel32.dll.

I can't judge the accuracy of those statements, but surely they're
equally applicable to Windows programs written in *any* language, and
entirely inapplicable to C programs running under operating systems
other than Windows. This should tell you that this is off-topic here.

http://www-128.ibm.com/developerwork.../l-shlibs.html
< quote >
Shared libraries are a fundamental component for the efficient use of

^^^^^^^^^^^^^^^^^^^^^

That is not all use and certainly does not mean people need to know
about shared objects to write C on Unix or Linux.

<snip>

Dynamic linking is a BASIC COMPONENT of any modern OS Keith.
And since C is almost everywhere the basic interface to the OS
the C library is almost always in the form of a dynamicly loaded
object.

No, it is normally provided in both static and dynamic forms and you
choose the most appropriate one for what you are doing.

I insist this is on-topic here, and by the way, as on topic as
the FAQ about MSDOS registers structure...

Why stop with MSDOS?

C is a systems programming language and as such dynamic linking
touches C, even if not described in the standard. This is NOT
comp.std.c

No it isn't, it is comp.lang.c, so it is about the C language, and
dynamic linking is not part of the C language. You know perfectly well
that comp.std.c is about the standard as a document rather than
programming in standard C since it has been pointed out often enough, so
stop pretending you don't.

Dynamic linking is not even required on Unix which you so like talking
about. Even on AIX which is the IBM version of Unix, since you brought
IBM up, I know for a fact (as I use it and develop for it) that you can
easily produce entirely statically linked programs and, indeed, the
dynamic version of the maths library is not even installed by default so
many applications link statically to that!

Actually, it was not that long ago that I change one of our applications
which is used by *big* companies in the UK to use dynamic linking, up
until then it had always been statically linked on Linux, SCO, AIX,
HP-UX and Solaris.

So it is not required that you use it, a lot of the time when it is used
you don't need to know anything about it, and only when you are doing
something non-portable do you actually need to know about it, and then
there are other groups to discus it on. Sound like a lot of good reasons
to discus it on the platform specific groups rather than the group not
dedicated to specific platforms.
--
Flash Gordon

[Tor Rustad]

jacob navia skrev:

Keith Thompson a écrit :

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

>ALL processes under windows must call

ExitProcess

to finish!!!!!!

That API call is exported in Kernel32.dll.

Sorry, but you are wrong..... a C compiler don't
*need to* go via KERNEL32.DLL, the implementation
don't even need to invoke systems services via
NTDLL.DLL.

The KERNEL32.DLL is just a wrapper for NTDLL.DLL,
where transfere of control from Ring 3 (user) to
Ring 0 (kernel) on Intel 80x86 processors is done
via interrupt 0x2e:

MOV EAX, func_number
LEA EDX, func_arg_addr
INT 2E
RET ret_code
which invoke _KiSystemService in NTOSKRNL.EXE.

http://www.microsoft.com/msj/1097/hood1097.aspx

<g>

C is a systems programming language and as such dynamic linking
touches C, even if not described in the standard. This is NOT
comp.std.c

This is NOT on-topic in comp.lang.c... in this news group
we discuss C language as defined in the C90 and C99
standards. This is really simple:

Platform specific topics are on-topic elsewhere.

--
Tor

[jacob navia]

Tor Rustad a écrit :

jacob navia skrev:

>>Keith Thompson a écrit :

>>>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
ALL processes under windows must call

ExitProcess

to finish!!!!!!

That API call is exported in Kernel32.dll.

Sorry, but you are wrong..... a C compiler don't
*need to* go via KERNEL32.DLL, the implementation
don't even need to invoke systems services via
NTDLL.DLL.

The KERNEL32.DLL is just a wrapper for NTDLL.DLL,
where transfere of control from Ring 3 (user) to
Ring 0 (kernel) on Intel 80x86 processors is done
via interrupt 0x2e:

MOV EAX, func_number
LEA EDX, func_arg_addr
INT 2E
RET ret_code
which invoke _KiSystemService in NTOSKRNL.EXE.

http://www.microsoft.com/msj/1097/hood1097.aspx

<g>

This is stupid. All those numbers change from version to version.
If you do this hack, your program will not run with the next
service pack... not to mention in the next version of
windows. Using the API shields programs from this calling
of direct numbers!

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

>>C is a systems programming language and as such dynamic linking
touches C, even if not described in the standard. This is NOT
comp.std.c

This is NOT on-topic in comp.lang.c... in this news group
we discuss C language as defined in the C90 and C99
standards. This is really simple:

Platform specific topics are on-topic elsewhere.

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

[Mark McIntyre]

On Sun, 19 Nov 2006 16:26:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>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

[Mark McIntyre]

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

>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

[Mark McIntyre]

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

>Tor Rustad a écrit :

>Sorry, but you are wrong..... a C compiler don't
*need to* go via KERNEL32.DLL, the implementation
don't even need to invoke systems services via
NTDLL.DLL.

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

[Mark McIntyre]

On Sun, 19 Nov 2006 18:52:00 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Flash Gordon a écrit :

>See, I'll even admit the possibility of being wrong (but not the
certainty).

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

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

Platform specific topics are on-topic elsewhere.

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

--
Tor

[Andrew Poelstra]

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

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

[Richard Bos]

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

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

<snip>

>

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

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.

[Richard Heathfield]

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

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