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]

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:

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.

 

[Kenny McCormack]

jacob navia wrote:



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

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]

[Just debunking some trollschildt]

Kenny McCormack said:

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.

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

 

[Kenny McCormack]

[Just debunking some trollschildt]

Kenny McCormack said:

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.

 

[CBFalconer]

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

 

[Keith Thompson]

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.

 

[Kenny McCormack]

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>

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]

Flash Gordon a écrit :

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.

 

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

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.

 

[Mark McIntyre]

Keith Thompson a écrit :

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:

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.

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.

 

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

Flash Gordon a écrit :

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.