|
The binary file standard is plain C, and the dll uses an ordinal table IIRC. Works pretty well as long as all you want is C. That's why if you examine, eg, GetProcAddress you do lookups with function names, and the returned pointers are untyped.
Problems with other things such as C++ -- hence the need for COM -- come from (1) no standard name mangling, (2)automatic memory management (allocate mem, constructors, destructors, etc) and needing to know the internals of the class structure, (3) the desire for strong versioning and strong interfaces, (4) exceptions handling (compiler specific again), (5) the fact that C++ isn't particularly object oriented at run time -- all sorts of places need to know the exact details of class layout, so it can't ever change. etc.
Grab a book by Don Cox called _Essential COM_
earl
|
|
|
|
|
Thank you earl,
Maybe I have not made myself understood enought. The purpose of my post is not to discuss COM, but to make clear why DLL can be used across linkers (for example, DLL created by VC can be linked in an VB application), while at the same time object file (which is generated by compiler) can not be used across linker (for example, we can not link an obj file generated by VC7 in a VC6 application). Since DLL and obj file are both binary files, why DLL can be used across linker but obj file can not? What is the internal reason?
regards,
George
|
|
|
|
|
DLLs can be used across linkers because everything you need to know is standardized while it isn't in obj files (and isn't in C++, which was the point of the latter bit of my post). You have an ordinal table to find function offsets (run dumpbin /exports on some dll). Combined with the lack of name mangling (at least usually) and the standard calling convention (put in place by __declspec(dllexport), the linker / run time knows what to do.
A dll may or may not have an import library around with automatic thunking code to fix up the lookup table, or you may have to do LoadLibrary / GetProcAddress. Either way, you're mapping function names to addresses.
I'd guess that an obj file is just a bunch of compiled code and the compiler keeps some internal table of function to address mappings (which is what is written to disk and shared via an ordinal table for dlls). In any case, non standard name mangling, various calling conventions, I don't believe (don't really know) that the standard requires any particular code layout, etc, mean they're compiler specific.
Basically, a dll is a bit of stuff added to an obj file to allow it to work across compilers.
HTH, and I'm tired, so it's bedtime.
earl
|
|
|
|
|
Thank you earl!
Let me wish you a good dearm at first. You can continue our discussion tomorrow. 
You always mentioned two terms called "ordinal table" and "calling convention" (I know what means calling convention, but I have never used ordinal table before.), and it seems that the reason why DLL can be used across linkers is because DLL has standard "ordinal table" and "calling convention" in your points. Right? I am interested in this point and I am wondering whether you can give me a sample about what is a standard/non-standard "ordinal table" and "calling convention".
BTW: from your reply, I think there should be some standard way to express function look-up table, function prototype, function calling convention, ... all at binary level, right?
regards,
George
|
|
|
|
|
Here is a dll ordinal table from a random dll from windows\system32
C:\WINDOWS\SYSTEM32>dumpbin /exports oemdspif.dll
Microsoft (R) COFF/PE Dumper Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file oemdspif.dll
File Type: DLL
Section contains the following exports for oemdspif.dll
00000000 characteristics
437413A2 time date stamp Thu Nov 10 21:44:34 2005
0.00 version
1 ordinal base
24 number of functions
24 number of names
ordinal hint RVA name
18 0 00005090 GetCRTCCapabilities
19 1 00005160 GetCRTCConfiguration
2 2 00006090 GetDisplayDeviceCapability
4 3 00003DE0 GetDisplayDeviceMode
3 4 00003CD0 GetDisplayDeviceSwitchCapability
1 5 000036F0 GetDisplayDriverName
21 6 000057C0 GetExtendedDesktopStatus
23 7 00006520 GetLCDI2CBusData
9 8 000047F0 GetLCDRefreshRate
8 9 000046F0 GetLCDRefreshRateCapability
12 A 000061E0 GetPowerState
6 B 000044B0 GetScreenExpansionStatus
16 C 00004EA0 GetStaticPowerState
14 D 00004AC0 GetTVStandard
11 E 000049C0 IsExternalDisplayConnected
20 F 00005300 SetCRTCConfiguration
5 10 00003F40 SetDisplayDeviceMode
22 11 00005850 SetExtendedDesktopStatus
24 12 00006600 SetLCDI2CBusData
10 13 000048E0 SetLCDRefreshRate
13 14 00006360 SetPowerState
7 15 000045D0 SetScreenExpansionStatus
17 16 00004F90 SetStaticPowerState
15 17 00004C70 SetTVStandard
Summary
2000 .data
2000 .rdata
1000 .reloc
1000 .rsrc
C000 .text
C:\WINDOWS\SYSTEM32>
dumpbin comes with most versions of visual studio; it should also be available somewhere online, though VC2005 Express is free. The RVA is probably some sort of relocatable address or some such; there are obviously some complications to "just load code into memory and run it", but they're just details. This is just an ordinal table generated so the linker / runtime can figure out where functions are in the dll.
As for C, this is pretty much the standard way (on win32) to express the lookup table, etc. C++ presents other issues (name mangling, memory management, etc), which is why we have COM, as well as the desire for things like interfaces, etc.
But yeah, this C calling convention is spoken by just about everything on windows -- VB, Python, probably perl, etc.
Hope this helps
earl
|
|
|
|
|
Thank you very much earl!
I think in order for an application to work correctly with a dependent DLL, the application should understand the format of the DLL (calling conventions and ordinal tables), right? But who is responsible for interpreting DLL (interpreting the calling conventions and ordinal tables to deal with each exported functions of the DLL) and inserting related exported function address into executable files -- the linker or?
And when DLL file format is interpreted? During link time (with the help of import library .lib file) or during runtime?
regards,
George
-- modified at 4:31 Wednesday 5th July, 2006
|
|
|
|
|
George,
DLLs can be loaded at compile time -- with an import lib that thunks -- or at runtime -- with LoadLibrary and GetProcAddress.
If the latter, then the application calls LoadLibrary to explicitly open a DLL and GetProcAddress to get a function pointer to each function the app wants to call. Dealing with all the stuff required to use a DLL is split between the app and win32.
If DLLs are loaded at compile time, then code is added to the executable before main/WinMain to load the DLLs and initialize all the function pointers.
In either case, code is added to, I believe, the DLL to deal with loading the code into memory, relocating addresses, etc...
earl
|
|
|
|
|
Thank you earl!
In the situation about implicit linking, I think there should be a standard for the .lib (import library) file, so that when linking an application with an DLL, the linker can understand the exported symbols of the DLL by utilizing the import library .lib. For example, VB linker should be able to interpret the content of a .lib file created by VC in order to utilize the DLL generated by VC. Agree?
So, do you know whether there exists such a standard for .lib file?
regards,
George
|
|
|
|
|
Well, when people start getting to the point of generating libraries to be used across languages, most just use COM. Really, as long as you aren't using a DispID interface (or if you provide dual interfaces) there is virtually no overhead.
Alternatively, there are tlbs -- type libraries -- that some languages can use.
http://windowssdk.msdn.microsoft.com/en-us/library/ms221355.aspx
earl
|
|
|
|
|
Thank you earl!
I think you have answered all my question. Could you give me just one or two sentences to summarize why DLL can be used across linkers while obj files can not please?
regards,
George
|
|
|
|
|
how do i display an image using array method in a dialog box?
|
|
|
|
|
what image, what array, and what dialog?
|
|
|
|
|
Can you be more specific
whitesky
|
|
|
|
|
hello friends,,
I have established serial communication with RABBIT3000 (an 8 bit microcontroller).
When the PC receives packet from the microcontroller, it receives the correct packet for the first time. but when I try sending a different packet (microcontroller updates the packet structure members) to the PC, it still receives only the same packet that it received first and not the updated one.
I clean up the receive buffer on the PC using delete function everytime after the packet is received.
On the microcontrollers end, the changed values is what is sent in the packet. So no bug on the controllers end but the bug is on the Pc side only.
What could be the possibility? any suggestions?
|
|
|
|
|
Are you sure you're sending stuff OK? No problems with a crlf /cr / lf terminator being incorrect on your end?
earl
-- modified at 23:54 Monday 3rd July, 2006
PS: depending on how you're sending this, (just OpenFile on the port?) make sure to flush your buffer so that the packet is guaranteed sent...
|
|
|
|
|
The problem could have hundreds of explanations, since the probable complexity of your hardware and software setup are much higher than the degree of detail you provided.
However, I would sugest you try out the most basic things. One thing that usually happens is cross talk between TX and RX cables resulting in the PC receiving the same bytes it sends. For example, you send a byte and as the bits are sent through the TX the RX cable picks them up (due to cable cross talk) and interprets them as being received from the remote end. All the bits will be valid, including start and stop bits, so the serial port just reads them in at the same time.
Of course, this could also apply to the microcontroller. This could lead to symptoms as you describe if your protocol uses similar bytes to allow confusion between cross talk and repetition.
I hope this helps.
Rilhas
|
|
|
|
|
I have problem on how to use StdAfx & precompiled headers.
Apparently it's an extremely important header and everything I write before
#include "stdafx.h" is ignored.. 
(tooks me awhile to figure that error!)
anyway apparently precompiled header could slow down your compilation a lot (instead of speeding it up) if they are regenerated too often.
the problem is I have no idea when they are regenerated.. 
so here is my question:
1. is it okay to #include "stdafx" in my header (by default its' only included in the .cpp)
2. is it okay to include it after the "guarding define", that is after
#ifndef __SOMCONST___
#define __SOMCONST___
#include "stdafx.h"
....
#endif
3. is it ok to write into include for common system headers + seldom changing projet #define
any other tips wellcome 
|
|
|
|
|
You should include stdafx.h in every .cpp file, not in any header files. If you do that, the header guards will prevent all the stdafx.h contents from being parsed again, but it'll look sloppy.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
thanks.
although I was asking a question on what really happen more than best practice 
|
|
|
|
|
have a look at this article[^].
-Saurabh
|
|
|
|
|
Excellent!
Thanks! 
|
|
|
|
|
Hey Guys,
I got a piece of Unix Code but I have to make it run under Windows. Unfortunately I contains the function mmap (a Unix Function). Fortunately there is this nice DLL called cygwin1.dll which gives you some Unix Functions.
<br />
HINSTANCE hDll = LoadLibrary("cygwin1.dll");<br />
if(hDll)<br />
{<br />
printf("DLL Loaded !\r\n");<br />
FARPROC mmap = GetProcAddress(hDll,"mmap");<br />
if(mmap)<br />
{<br />
printf("Function found !\r\n");<br />
mydata= mmap(mydata, myLength,PROT_READ,MAP_PRIVATE,fd,0);<br />
}<br />
else<br />
{<br />
printf("Function not found!\r\n");<br />
}<br />
}<br />
else<br />
{<br />
printf("Failed to load DLL!\r\n");<br />
}<br />
This is the code I use. But when I then try to call the mmap function my compiler tells me that I'm passing to many arguments to mmap. 
Normally I don't load libraries at runtime. So please help me
|
|
|
|
|
Hey,
You're getting a function pointer back, but GetProcAddress can't possibly know what the function definition of mmap is so you have to tell it.
Assuming that you are using the results from "man mmap"
#include < sys/mman.h >
void* mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
then you would do something like this
#include < windows.h >
typedef void* (CALLBACK* PFNMMAP)(void*, size_t, int, int, int, off_t);
PFNMMAP pmmap;
if( (pmmap = GetProcAddress(dllHandle, "mmap"))) {
}
now pmmap is a function pointer with the right signature -- ie of type PFNMMAP. Oh yes, modify CALLBACK based on the way the dll export table was declared (it should work for __declexport).
Also, there are two types of libs on windows. One, called a .lib, is code made to be statically linked into a file. The other, for your convenience also called a .lib, is code that is statically linked at compile time but just thunks to a dll. The latter is often more convenient as it will handle the LoadLibrary and GetProcAddress stuff for you.
The downside to using import libs is that windows tries to load the dll before your main / WinMain is called. If it can't find the dll you never get control. At least with manual LoadLibrary calls you can be intelligent about telling the user just what you can't find and what he or she ought to do about it.
PS: I don't have a compiler on this computer so I can't promise any of this works.
HTH
earl
|
|
|
|
|
How many parameter in this function mmap and use mmap with correct parameter
whitesky
|
|
|
|
|
what's the difference between file->new and window->newwindow in MDI project(pj name mydoc)?
why use file->new, the newfile name is mydoc1(or mydoc2,mydoc3,mydoc4.......)
but window->new Window, the new doc name is mydoc1:2 (or mydoc1:3, mydoc1:4, mydoc2:2.......)?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
