|
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.......)?
|
|
|
|
|
hi,I need your help......
|
|
|
|
|
File -> New
New Document
New View
Window -> New
Same Document
New View
|
|
|
|
|
So, here's the issue:
#ifndef ___GLOBALS_H___
#define ___GLOBALS_H___
enum AspectRatio {
Aspect4to3,
Aspect5to3,
Aspect5to4,
AspectOther
};
struct GState
{
bool isDebugMode;
AspectRatio aspectRatio;
unsigned int canary;
};
extern struct SState gState;
#endif
and for the declaration:
#include"globals.h"
SState gState;
Now, the problem: this is being compiled with VC6SP5 (yes, I know, there's nothing I can do for the time being). I manually checked that all files are being compiled with the same flags. In most files, I include globals.h and everything is kosher. In *some* files, the address of aspectRatio is bumped by 3. I can't figure out what this could possibly be except some weird alignment issue.
Solutions: if I uncomment char a,b,c;, then everything works. If I put unnamed (or named) bitfields in, either unsigned int : 0 or unsigned int:24 (the former promises to align everything that follows on an int), it's still broken.
So, for example, in one file,
printf("isDebugMode = %u, address = %X \naspect ratio = %u, address = %X \n"
"canary=%X, add = %X",
gState.isDebugMode, &(gState.isDebugMode),
gState.aspectRatio, &(gState.aspectRatio),
gState.canary, &(gState.canary));
canary is being set to 0x12344321
results in:
file1.cpp:
isDebugMode = 1, address = 5BAE20
aspectRatio = 2, address = 5BAE21
canary = 12344321, address = 5BAE25
file2.cpp:
isDebugMode = 1, address = 5BAE20
aspectRatio = 876814592, address = 5BAE24
canary = 12, address = 5BAE28
file1.cpp is correct; file2.cpp isn't. The address for aspectRatio is being bumped by 3. Can anyone tell me what the hell is going on?
Thanks,
earl
PS: struct member alignment is set to 8 bytes in the compilation flags.
-- modified at 20:27 Monday 3rd July, 2006
|
|
|
|
|
Put a #pragma pack instruction around the struct definition. The compiler option just sets the default packing, some other buggy header may be changing the packing and not resetting it.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
While trying to add a new dialog (for login), after I build the dialog resource and compile the new class, I get errors saying that the IDD_DIALOG1 can't be found, even though it is in the .h file. This is where the error message points back to (the .h file). Anyone know why this is reacting the way it is. This is the first version of Visual C++ 6.0.
Thanks.
John P.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
