Re: DLL function by ordinal v.s. by name - C / C++ / MFC Discussion Boards

Re: DLL function by ordinal v.s. by name

Rajkumar R8-Feb-08 5:12

8-Feb-08 5:12

in implicit linking, linker generates export library, then it will do in the optimised possible way right? why do you think implicit linking is not using ordinal, it gives a stub which internally uses ordinal values to link. That is why normally if you rebuild DLL, u need to rebuild the application too, if it looks up using name rebuilding is not needed.

George_George wrote:
if we use implicit linking, there is no way to use by ordinal.

DEF files if you need to set ordinals explicitly

see this quote

"Implicit linking looks up based on the ordinal, so ideally a function's ordinal should always stay the same. Unless you specify your own ordinals the linker may generate different ordinals each time you build your application. This in turn means that Applications which have already been built to use your DLL may cease to link correctly."

from
DLL linking[^]

u may get more info if u searched on web.

Re: DLL function by ordinal v.s. by name

George_George8-Feb-08 22:15

George_George

8-Feb-08 22:15

Thanks Rajkumar,

I think it means when using implicit linking, ordinal of DLL exported function is built into EXE. EXE is using the ordinal value to look into related address array of exported function of the DLL to invoke related function, right?

Rajkumar R wrote:
Implicit linking looks up based on the ordinal,

regards,
George

Re: DLL function by ordinal v.s. by name

Rajkumar R8-Feb-08 23:21

Rajkumar R

8-Feb-08 23:21

George_George wrote:
ordinal of DLL exported function is built into EXE.

in a way yes, as the export library stub is linked to exe.

export library is generated through linker switch, it uses DEF files and /or dllexport keywords.
DEF files can be used to override the automatically generated ordinals, and as names can be used in DEF files, i think in that case export library uses names to link. But by default dllexport and export library uses ordinals.

Re: DLL function by ordinal v.s. by name

George_George9-Feb-08 21:01

George_George

9-Feb-08 21:01

Thanks Rajkumar,

When using implicit linking, to use the function exported by DLL, is there any way to use by ordinal other than use by name?

regards,
George

Re: DLL function by ordinal v.s. by name

Rajkumar R10-Feb-08 22:47

Rajkumar R

10-Feb-08 22:47

I think u got confused,

simply using implicit linking by dllexport keyword uses ordinals,

u can use DEF files while using implicit linking to give a constant ordinals inplace of automatically generated ordinals.

Re: DLL function by ordinal v.s. by name

George_George11-Feb-08 22:00

George_George

11-Feb-08 22:00

Thanks Rajkumar,

Rajkumar R wrote:
u can use DEF files while using implicit linking to give a constant ordinals inplace of automatically generated ordinals.

It is for DLL provider. My question is, could DLL comsumer use ordinal to invoke function exported by DLL other than by name, for example providing ordinal as input parameter?

regards,
George

Re: DLL function by ordinal v.s. by name [modified]

Rajkumar R11-Feb-08 22:17

Rajkumar R

11-Feb-08 22:17

I don't want to trace the post that u have posted and CPallini had replied that using GetProcAddress u can pass the ordinals, i think u have no doubts in this,

And in implicit linking, export library take care of linking, u just want to link to the export library. And as we discussed export library uses ordinals, normally automatically generated ordinals, so u don't know the ordinal to call it, and if u still want implicit linking(then calling by GetProcAddress is called explicit linking)and use call by ordinal u need to set ordinals by using DEF files(as u mentioned DLL provider) so that u know the ordinals(linker don't use the generated ordinal)u can call it.

I mentioned DEF files because then only u know the exact ordinal as by default linker generates.

modified on Tuesday, February 12, 2008 4:25 AM

Re: DLL function by ordinal v.s. by name

George_George12-Feb-08 0:12

George_George

12-Feb-08 0:12

Thanks Rajkumar,

I think my question should be answered. Let me summarize your points,

1. To use implicit linking, we can assign ordinal by using .DEF files, but for DLL consumer, it has to invoke DLL exported function by name other than by ordinal;

2. To use dynamic loading, i.e. GetProcAddres, as DLL provider, we can not only assign ordinal by using .DEF files, but also as DLL consumer provide ordinal as input parameter.

My understanding correct?

regards,
George

Re: DLL function by ordinal v.s. by name

Rajkumar R12-Feb-08 5:07

Rajkumar R

12-Feb-08 5:07

I would summarise,

1) implicit linking:
a) dllexport and dllimport - fastest
the compiler automatically generates the indirection code for you through IAT
dll(ex,im)port usage[^]

2) implicit & explicit linking:
a) /EXPORT option
b) DEF files
Export Functions from a DLL By Ordinal Rather Than By Name[^]

DLL optimising[^]

all links are informative, and can conclude urself.

Re: DLL function by ordinal v.s. by name

George_George12-Feb-08 16:40

George_George

12-Feb-08 16:40

Cool, Rajkumar! Great!!

A question about http://msdn2.microsoft.com/en-us/library/aa271769(VS.60).aspx[^],

Seem if we do not use dllimport there will be one more level of indirection and the root cause is we do not know the address of function from IAT if we do not use dllimport, right?

What is the obstacle of blocking the approach (not using dllimport) from knowing the function address in IAT? From the MSDN, I can not see why if we use dllimport, the IAT can be known and if we do not use IAT the address is not known.

I think the IAT is contained in the import library file (.lib file), and whether or not we are using dllimport, it is input to linker, right (so it is always known)?

regards,
George

Re: DLL function by ordinal v.s. by name

Rajkumar R8-Feb-08 6:32

Rajkumar R

8-Feb-08 6:32

yes, see this [^]

Re: DLL function by ordinal v.s. by name

George_George8-Feb-08 22:13

George_George

8-Feb-08 22:13

Thanks Rajkumar!

regards,
George

Re: DLL function by ordinal v.s. by name

Stephen Hewitt7-Feb-08 12:39

Stephen Hewitt

7-Feb-08 12:39

Importing by ordinal is faster as it simply uses the ordinal as an index into an array of function pointers (well RVAs actually) instead of performing a binary search on function names. That said, I doubt that importing by name is a problem for many applications.

Steve

Re: DLL function by ordinal v.s. by name

George_George7-Feb-08 20:38

George_George

7-Feb-08 20:38

Thanks Steve,

My question is answered.

regards,
George

COM CreateInstance method

George_George6-Feb-08 19:19

George_George

6-Feb-08 19:19

Hello everyone,

I think there is only one COM CreateInstance method, which belongs to IClassFactory interface.

Is there another CreateInstance method, which does not belongs to any class/interface and belongs to the COM global library function (like CoCreateInstance)?

thanks in advance,
George

Re: COM CreateInstance method

CPallini6-Feb-08 20:54

CPallini

6-Feb-08 20:54

Sorry?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

[my articles]

Re: COM CreateInstance method

George_George7-Feb-08 3:25

George_George

7-Feb-08 3:25

Sorry for what? I have not made myself understood, CPallini?

regards,
George

Re: COM CreateInstance method

CPallini7-Feb-08 3:52

CPallini

7-Feb-08 3:52

George_George wrote:
I have not made myself understood, CPallini?

Yes. At least I cannot undersatnd what you're asking for.

As you already know CoCreateInstance is simply a shortcut for the sequence

CoGetClassObject(rclsid, dwClsContext, NULL, IID_IClassFactory, &pCF); 
hresult = pCF->CreateInstance(pUnkOuter, riid, ppvObj) 
pCF->Release();

That, in turn, shows CoGetClassObject, another function of the COM library.
Bottom line, COM library provide a set of standard functions (such as CoInitialize, CoCreateInstance, ...). Does that make you wonder?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

Re: COM CreateInstance method

George_George7-Feb-08 4:06

George_George

7-Feb-08 4:06

Thanks CPallini,

My question is, for COM defined functions (including the functions in COM defined interface and class) -- which are not used defined functions, beyond the CreateInstance function in IClassFactory, are there another function which has exact the same name of CreateInstance?

Let me know if I have not made myself understood.

regards,
George

Problem in execution

mosali satish6-Feb-08 18:33

mosali satish

6-Feb-08 18:33

hi
iam working with some dialog applications in VC++.iam facing a problem in one of the application i have developed a dialog application and it was running fine then i want to exetend the funcationality so i have added few more controls to it and added member variables to those controls then i have executed the application and it was not running.when i removed those member variables it was running.what may be the problem? please can anyone solve this probelm.

sathish

Re: Problem in execution

Cedric Moonen6-Feb-08 20:14

Cedric Moonen

6-Feb-08 20:14

Which kind of controls did you add ?

Cédric Moonen
Software developer

Charting control [v1.2]

Re: Problem in execution

Iain Clarke, Warrior Programmer6-Feb-08 23:12

Iain Clarke, Warrior Programmer

6-Feb-08 23:12

In addition to Cedric's answer...

Have you tried adding them one by one?

Is the dialog able to create, or is it failing? If it fails in debug mode, then single step through and see where it fails.

If it fails on dialog creation, then you can set a no-fail-create style for the dialog in the dialog editor. That may help you narrow down the fault.

Are you using custom classes for the control's you're adding, and have you registered that class before you create the dialog?

For all we know, you've got a bug in the code handling those controls - the only way to find out is to debug your application.

Iain.

Iain Clarke appearing in spite of being begged not to by ^CPallini.

Re: Problem in execution

David Crow7-Feb-08 2:50

David Crow

7-Feb-08 2:50

If you add the DS_NOFAILCREATE style to the dialog, does it display then?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

SetScrollSizes

Still learning how to code6-Feb-08 12:09

Still learning how to code

6-Feb-08 12:09

As I am using CScrollView in my application, I have called SetScrollSizes() in my override of OnInitialUpdate(). However, I get an assertion when I check the mapping mode. The code is as below:-

SetScrollSizes(MM_LOMETRIC,TotalSize);

CDC* pDC;
pDC = GetDC();

int iMapMode;
iMapMode = pDC->GetMapMode();
ASSERT(iMapMode == MM_LOMETRIC);

I'm sure that there is a simple answer to this !!! Confused | :confused:

Doug

Re: SetScrollSizes

Mark Salsbery6-Feb-08 12:50

Mark Salsbery

6-Feb-08 12:50

Probably because iMapMode != MM_LOMETRIC for your freshly obtained client DC.

There's no reason iMapMode == MM_LOMETRIC unless you set
the mapping mode to MM_LOMETRIC for the DC. This will be done for you
in the CPaintDC that is passed to the OnDraw() method of the view class,
so there your assert should succeed.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.