Overview

[Mark McIntyre]

Flash Gordon a écrit :

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]

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]

Flash Gordon a écrit :

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.

 

[jacob navia]

CBFalconer a écrit :

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 :

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




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]

CBFalconer a écrit :

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]

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]

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>

 

[Flash Gordon]

Flash Gordon a écrit :

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]

Kenny McCormack wrote:

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!

 

[jacob navia]

Mark McIntyre a écrit :

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 :

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]

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.

 

[Flash Gordon]

jacob navia wrote:

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.

 

[jacob navia]

Keith Thompson a écrit :

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/developerworks/linux/library/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]

Flash Gordon a écrit :

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]

Keith Thompson a écrit :

http://www-128.ibm.com/developerworks/linux/library/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.

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.

 

[Tor Rustad]

jacob navia skrev:

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

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

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.

 

[jacob navia]

Tor Rustad a écrit :

jacob navia skrev:

Keith Thompson a écrit :

[...]


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

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.