|
|
|
date: Fri, 11 Jul 2008 19:03:26 -0700,
group: microsoft.public.win32.programmer.ui
back
Re: Control panel applet question
* Sam Hobbs:
> "Dean Earley" wrote in message
> news:eZ2Gvsx5IHA.3420@TK2MSFTNGP05.phx.gbl...
>> Tim Roberts wrote:
>>> Dean Earley wrote:
>>>> Polaris wrote:
>>>>> Hi Experts:
>>>>>
>>>>> I have a control panel applete (testApplet.cpl) which is statically
>>>>> linked to a dll (test.dll). My questions are:
>>>>>
>>>>> 1. Can I put testApplet.cpl at locations other than System32 directory?
>>>>>
>>>>> 2. If I have to put testApplet.cpl in System32 directory, is there a
>>>>> way for me to put test.dll in locations other than System32 directory?
>>>>> For example, I prefer to put test.dll in my application folder under
>>>>> "Program Files".
>>>> If it is statically linked to test.dll, you don't need to put it
>>>> anywhere on the target system.
>>> You can't statically link to a DLL, at least in the way you mean.
>>>
>>> What Polaris meant was statically linking to the export library for
>>> test.dll. It will still be a dynamic link, and test.dll will still be
>>> required at run-time.
>> Ah yes, sorry. I blame lunacy :)
>
> I blame terminology. It is a contradiction in terms to say "statically
> linked to a dll" since a dll is by definition "dynamically linked".
Well there's a difference between statically linking to the DLL, where the
dynamic linking is performed by the OS loader, and dynamically loading the DLL
by calling LoadLibrary or friend.
> I don't
> understand what "statically linked to a dll" means. Perhaps the correct term
> is "implicitly linked".
Statically linked probably means the opposite of dynamically loaded. :-)
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
date: Mon, 28 Jul 2008 21:42:04 +0200
author: Alf P. Steinbach
Re: Control panel applet question
"Alf P. Steinbach" wrote in message
news:YvSdnS53F7ELvRPVnZ2dnUVZ_qPinZ2d@posted.comnet...
>* Sam Hobbs:
>> "Dean Earley" wrote in message
>> news:eZ2Gvsx5IHA.3420@TK2MSFTNGP05.phx.gbl...
>>> Tim Roberts wrote:
>>>> Dean Earley wrote:
>>>>> Polaris wrote:
>>>>>> Hi Experts:
>>>>>>
>>>>>> I have a control panel applete (testApplet.cpl) which is statically
>>>>>> linked to a dll (test.dll). My questions are:
>>>>>>
>>>>>> 1. Can I put testApplet.cpl at locations other than System32
>>>>>> directory?
>>>>>>
>>>>>> 2. If I have to put testApplet.cpl in System32 directory, is there a
>>>>>> way for me to put test.dll in locations other than System32
>>>>>> directory? For example, I prefer to put test.dll in my application
>>>>>> folder under "Program Files".
>>>>> If it is statically linked to test.dll, you don't need to put it
>>>>> anywhere on the target system.
>>>> You can't statically link to a DLL, at least in the way you mean.
>>>>
>>>> What Polaris meant was statically linking to the export library for
>>>> test.dll. It will still be a dynamic link, and test.dll will still be
>>>> required at run-time.
>>> Ah yes, sorry. I blame lunacy :)
>>
>> I blame terminology. It is a contradiction in terms to say "statically
>> linked to a dll" since a dll is by definition "dynamically linked".
>
> Well there's a difference between statically linking to the DLL, where the
> dynamic linking is performed by the OS loader, and dynamically loading the
> DLL by calling LoadLibrary or friend.
Wrong. I avoid saying "wrong" but I don't know how to emphasize the error
here. What you are describing is implicit and explicit linking. Implicit
linking is where the linker uses a lib file and then during execution the
dll is located by Windows without requiring us to specify the dll file in
our code. Explicit linking uses LoadLibrary with the dll file name as a
parameter in our code.
>> I don't understand what "statically linked to a dll" means. Perhaps the
>> correct term is "implicitly linked".
>
> Statically linked probably means the opposite of dynamically loaded. :-)
No, static linking means that the linker puts the code in the exe so that
the code is a permanent part of the exe. Note that it is called static and
dynamic linking, not loading. DLL means "Dynamic Link Library". I am sorry
for saying I don't understand what "statically linked to a dll" means. I was
tring to be nice in my explanation.
Back in the days of DOS, a lib (library) file was only capable of storing
object (obj) files; the equivalent of a static library. An object file is
the output of a compiler. Windows created dynamic link libraries and defined
a format for lib files so the link editor can create an exe that could load
DLLs implicitly. Most operating systems, including Unix, at the time did not
support dynamic linking. The operating systems for the big IBM "mainframes"
did not support dynamic linking but some of thier compilers such as the
COBOL compiler provided dynamic linking in the runtime support.
date: Wed, 30 Jul 2008 14:56:01 -0700
author: Sam Hobbs _change_social_to_socal
Re: Control panel applet question
* Sam Hobbs:
> "Alf P. Steinbach" wrote in message
> news:YvSdnS53F7ELvRPVnZ2dnUVZ_qPinZ2d@posted.comnet...
>> * Sam Hobbs:
>>> "Dean Earley" wrote in message
>>> news:eZ2Gvsx5IHA.3420@TK2MSFTNGP05.phx.gbl...
>>>> Tim Roberts wrote:
>>>>> Dean Earley wrote:
>>>>>> Polaris wrote:
>>>>>>> Hi Experts:
>>>>>>>
>>>>>>> I have a control panel applete (testApplet.cpl) which is statically
>>>>>>> linked to a dll (test.dll). My questions are:
>>>>>>>
>>>>>>> 1. Can I put testApplet.cpl at locations other than System32
>>>>>>> directory?
>>>>>>>
>>>>>>> 2. If I have to put testApplet.cpl in System32 directory, is there a
>>>>>>> way for me to put test.dll in locations other than System32
>>>>>>> directory? For example, I prefer to put test.dll in my application
>>>>>>> folder under "Program Files".
>>>>>> If it is statically linked to test.dll, you don't need to put it
>>>>>> anywhere on the target system.
>>>>> You can't statically link to a DLL, at least in the way you mean.
>>>>>
>>>>> What Polaris meant was statically linking to the export library for
>>>>> test.dll. It will still be a dynamic link, and test.dll will still be
>>>>> required at run-time.
>>>> Ah yes, sorry. I blame lunacy :)
>>> I blame terminology. It is a contradiction in terms to say "statically
>>> linked to a dll" since a dll is by definition "dynamically linked".
>> Well there's a difference between statically linking to the DLL, where the
>> dynamic linking is performed by the OS loader, and dynamically loading the
>> DLL by calling LoadLibrary or friend.
>
> Wrong. I avoid saying "wrong" but I don't know how to emphasize the error
> here. What you are describing is implicit and explicit linking. Implicit
> linking is where the linker uses a lib file and then during execution the
> dll is located by Windows without requiring us to specify the dll file in
> our code. Explicit linking uses LoadLibrary with the dll file name as a
> parameter in our code.
Please note that it's not necessary to use a lib file (import library) to link
to a DLL, except with Microsoft's current tools.
In the old days we used module definition files. GNU tools still don't require
an import library. Import libraries are tool functionality.
I'm sorry if you feel the terminology to be wrong. But it exists. :-) And one
might make a case that using LoadLibrary explicitly is not linking at all; it
isn't usually referred to as linking (except perhaps by Microsoft doc ;-) ).
>>> I don't understand what "statically linked to a dll" means. Perhaps the
>>> correct term is "implicitly linked".
>> Statically linked probably means the opposite of dynamically loaded. :-)
>
> No, static linking means that the linker puts the code in the exe so that
> the code is a permanent part of the exe. Note that it is called static and
> dynamic linking, not loading. DLL means "Dynamic Link Library". I am sorry
> for saying I don't understand what "statically linked to a dll" means. I was
> tring to be nice in my explanation.
>
> Back in the days of DOS, a lib (library) file was only capable of storing
> object (obj) files; the equivalent of a static library. An object file is
> the output of a compiler. Windows created dynamic link libraries and defined
> a format for lib files so the link editor can create an exe that could load
> DLLs implicitly.
Uhm, I'm absolutely not sure that Windows defined the COFF format, if that's
what you're hinting at here. Checking... Nope, the COFF format originated with
Unix (System V).
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
date: Thu, 31 Jul 2008 04:47:55 +0200
author: Alf P. Steinbach
Re: Control panel applet question
"Doug Harrison [MVP]" wrote in message
news:5o42941hlp0sija7qa9h06g1cihlc3lblj@4ax.com...
> On Wed, 30 Jul 2008 19:29:49 -0500, BobF <nothanks@spamfree.world> wrote:
>
>>Igor Tandetnik wrote:
>>> Sam Hobbs <samuel@social.rr.com_change_social_to_socal> wrote:
>>>> Wrong. I avoid saying "wrong" but I don't know how to emphasize the
>>>> error here. What you are describing is implicit and explicit linking.
>>>> Implicit linking is where the linker uses a lib file and then during
>>>> execution the dll is located by Windows
>>>>
>>>> I am sorry for saying I don't understand what "statically
>>>> linked to a dll" means.
>>>
>>> The same thing as "implicit linking to a DLL", as you describe it. The
>>> two terms are often used interchangeably, probably because implicit
>>> linking involves a LIB file (an import library) and thus closely
>>> resembles traditional static linking in how the project is set up.
>>
>>I have *never* heard the phrase "implicit linking to a DLL" until this
>>thread.
>
> MSDN uses the term:
>
> Linking an Executable to a DLL
> http://msdn.microsoft.com/en-us/library/9yd93633%28VS.80%29.aspx
> <q>
> Implicit linking is sometimes referred to as static load or load-time
> dynamic linking. Explicit linking is sometimes referred to as dynamic load
> or run-time dynamic linking.
>
> With implicit linking, the executable using the DLL links to an import
> library (.lib file) provided by the maker of the DLL. The operating system
> loads the DLL when the executable using it is loaded. The client
> executable
> calls the DLL's exported functions just as if the functions were contained
> within the executable.
>
> With explicit linking, the executable using the DLL must make function
> calls to explicitly load and unload the DLL and to access the DLL's
> exported functions. The client executable must call the exported functions
> through a function pointer.
> </q>
>
> --
> Doug Harrison
> Visual C++ MVP
Correct. Since most of what you say is a quote from the documentation I do
of course consider that to be correct.
There is just one more thing worth mentioning. Delay loading is somewhat a
combination of the two. Delay loading uses implicit linking except the DLL
is not loaded until an actual call to the DLL is made. If the DLL is never
called in a specific instance of execution, no error is issued. This is the
behavior that explicit linking is often used for; that is, to not fail if
the DLL is not present and is not needed. I recently researched wdmapi.dll.
It exists only in Vista. Windows applications use it but only if executing
in Vista; if the Windows version is XP, the application does not call
wdmapi.dll. If you use Depends to view the application using XP, Depends
will complain that wdmapi.dll does not exist but the application won't fail
for lack of wdmapi.dll.
date: Fri, 1 Aug 2008 21:27:15 -0700
author: Sam Hobbs _change_social_to_socal
Re: Control panel applet question
* Sam Hobbs:
> "Alf P. Steinbach" wrote in message
> news:Et-dncAwy4vFtQzVnZ2dnUVZ_uydnZ2d@posted.comnet...
>> * Sam Hobbs:
>>> Wrong. I avoid saying "wrong" but I don't know how to emphasize the error
>>> here. What you are describing is implicit and explicit linking. Implicit
>>> linking is where the linker uses a lib file and then during execution the
>>> dll is located by Windows without requiring us to specify the dll file in
>>> our code. Explicit linking uses LoadLibrary with the dll file name as a
>>> parameter in our code.
>> Please note that it's not necessary to use a lib file (import library) to
>> link to a DLL, except with Microsoft's current tools.
>
> Of corse. Microsoft invented DLLs.
If you refer to pure terminology, the term "DLL", then perhaps, but other than
that, AFAIK shared libraries originated with the Multics system.
>> In the old days we used module definition files. GNU tools still don't
>> require an import library. Import libraries are tool functionality.
>
> Module definition files are a compile-time thing and Import libraries are
> used only at link-time. The compiler does not use lib files in any way
> except to pass them on the the linker. The linker never reads def files
> without complaining that it cannor understand them.
I'm sorry, that's not correct in any way; it's just meaningless. However I'm not
going to use time on this by cobbling up examples for you. If you can get hold
of early editions of Petzold's "Programming Windows" it does contain some
examples and discussion.
>> I'm sorry if you feel the terminology to be wrong. But it exists. :-) And
>> one might make a case that using LoadLibrary explicitly is not linking at
>> all; it isn't usually referred to as linking (except perhaps by Microsoft
>> doc ;-) ).
>
> To the extent that a function calls another function, it is linking.
Yes, Microsoft is free to call anything anything they want. :-) But there is a
more forceful argument in the direction it seems you want to go, namely that a
DLL may itself use other DLLs. And in that case loading the DLL involves dynamic
linking, although not relevant at the abstraction level of the loading app.
Please note that terminology is just that, terminology.
As long as one understands the communication, the terms don't matter much;
insisting that only a mostly misleading and seldom used term is "right" is not
very intelligent.
>> Uhm, I'm absolutely not sure that Windows defined the COFF format, if
>> that's what you're hinting at here. Checking... Nope, the COFF format
>> originated with Unix (System V).
>
> DLLs don't have a special format in the manner you describe.
That's incorrect on two counts. First, IIRC I haven't described or discussed the
format of DLLs. Second, they are COFF format (more precisely, PE format).
> Windows
> executable files use the COFF format, whether they are executed directly by
> Windows (an exe file) or linked to dymamically as a DLL. So the fact that
> the COFF format was created in Unix for executable files does not prove that
> dynamic linking existed in Unix prio to the existance in Windows.
That reasoning seems to be valid. However you're arguing against something that
hasn't been stated or implied. Moreover, shared libraries existed before Unix.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
date: Sat, 02 Aug 2008 09:19:32 +0200
author: Alf P. Steinbach
|
|
