|
OK I was just trying to help.. You know I read somewhere on the Internet that there are some data structures out there which are stored and set when DLL's are loaded which has all information about the DLL, such as reference count. Maybe there is a variable which has whether the DLL was loaded by an EXE or DLL. You'll have to find this yourself though as I'm not doing your research.
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
Joe Woodbury wrote: (There may be several executables between the main application and my DLL.
And in this case, GetModuleFileName(NULL, ...) would return the name of the EXE whose address space contains your DLL, regardless of how many other EXEs were loaded first. For example:
A.EXE --> CreateProcess() --> B.EXE --> CreateProcess() --> C.EXE --> implicit/explicit linking --> YOUR.DLL
In this scenario, GetModuleFileName(NULL, ...) would return C.EXE.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Ahhhh, I KNOW THAT, that's the point of my question.
I shake my head and wonder why I bothered posting this question.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I actually understood your question as posted but thought 2 things:
1. I don't think there is any ways of knowing.
2. I can't think of a reason why you would want/need to know.
I thought the best you can do is determine if the dll was loaded via a static binding or a LoadLibrary() call:
http://msdn2.microsoft.com/en-us/library/ms682583.aspx[^]
lpvReserved
If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL for dynamic loads
and non-NULL for static loads.
If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary
has been called or the DLL load failed and non-NULL if the process is terminating.
I can't think of a way off-hand to determine if it was an exe or other dll that was statically bound to your dll. The best i can think of is to look at the list of statically linked dll's for the exe and see if your dll is in the list, if so it was the exe, if not then another dll.
To determine if it was an exe or other dll that called LoadLibrary() to load your dll, i would walk the stack and check the address of the function that called LoadLibrary(), and from that get it's module.
I have two questions:
1. What is the scenario you have where you need to know this.
2. When can we expect an article describing how to do it. 
...cmk
Save the whales - collect the whole set
|
|
|
|
|
cmk wrote: 1. What is the scenario you have where you need to know this.
Security. We have an embedded XP system. We expose a series of APIs to third parties which allow a subset of operations depending on their contract with us. They can't, however, use the underlying DLLs of this API directly. Our concern isn't developers using the low level APIs maliciously, but as a shortcut to meet deadlines. We must keep this as light weight, non-intrusive and automated as possible for many reasons.
(Figuring out ahead of time that a DLL is being loaded statically is easy and we'll do that. It's when they load it dynamically that's more problematic.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Interesting.
I don't think there is a perfect solution for what you want.
e.g.
User writes an exe, the exe first loads your API dll, which then properly loads your low-level dll.
Later in the exe they load a low-level dll directly, at this point i don't think you will get a DllMain(DLL_PROCESS_ATTACH) call in the low-level dll, i just think it's ref count will be increased.
If it is to prevent 'casual' attempts then you may want to export a NONAME init function from the low-level dll that takes some cryptic params. Your API dll would then call this after loading the low-level, but before using any of it's functions. A 3rd party dev would have to hack your API dll to see what is going on. The down-side here is that the low-level functions would have to check some init flag to see if everything is ok - a little extra overhead. I've seen this method used by a number of 3rd party libraries.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
It seems that this must be done programmatically at run-time, rather than design time (which is what I'm used to with VB), but I haven't found any example code.
Does anyone have example code to changing the font color of a Static Text and Edit Control ?
thanks !
|
|
|
|
|
If you respond to the WM_CTLCOLOR message in the control's parent,
you can set the text color and background color on the passed DC.
Are you using Win32 APIs or MFC?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
I am using MFC.
I've added the OnCtlColor() event and it changes the color, but the backgrounds of the edit box and static text box remain grey instead of transparent:
HBRUSH S2000_CP_DLG::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
switch ( pWnd->GetDlgCtrlID() )
{
case IDC_FW_VERSION: //Static Text box
case IDC_MESSAGES: //Edit Control
pDC->SetTextColor(rgbColor_RED);// Set the text color to red
pDC->SetBkMode(TRANSPARENT);// Set the background mode for text to transparent
break;
}
return hbr;
}
I made sure the WINVER is defined to 0x0501 to compile for XP, but still, the background is not see-through.
Is there a fix for the background transparency ?
|
|
|
|
|
You need to return a handle to a brush that you've created/obtained
instead of returning the default brush...
CBrush m_RedBrush;
...
m_RedBrush.CreateSolidBrush(RGB(0xFF,0x00,0x00));
...
HBRUSH S2000_CP_DLG::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
switch ( pWnd->GetDlgCtrlID() )
{
case IDC_FW_VERSION:
case IDC_MESSAGES:
pDC->SetTextColor(rgbColor_RED);
pDC->SetBkMode(TRANSPARENT);
break;
}
return m_RedBrush;
}
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
using the solid red brush makes the static text and edit control backgrounds red.
What I really wanted is have the bitmap on the Dialog visible through the Static Text and Edit Control.
|
|
|
|
|
You could return a NULL brush:
return (LRESULT)::GetStockObject(NULL_BRUSH);
This works on static controls, but I have not got it to work on edit controls.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I just tested - returning a NULL brush works unless XP visual styles are enabled.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yes you need to respond to the WM_CTLCOLOREDIT message. Google for that and look it up on MSDN you should be able to find some code samples.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
Hi,
I am getting cmpilation error "Cannot convert parameter from 'int' to 'HANDLE'" on 64 bit windows for stackwalk64 code. I am porting 32 bit code to 64 bit windows. Could you please any one tell me why compiler is throwing these errors ? MS VS2005 is being used. Down below is code snippet.
stackwalkerTest.h
-----------------
typedef BOOL (__stdcall * STACKWALKPROC)
( DWORD, HANDLE, HANDLE, LPSTACKFRAME, LPVOID,
PREAD_PROCESS_MEMORY_ROUTINE,PFUNCTION_TABLE_ACCESS_ROUTINE,
PGET_MODULE_BASE_ROUTINE, PTRANSLATE_ADDRESS_ROUTINE );
typedef DWORD (__stdcall *SYMSETOPTIONSPROC)(DWORD);
typedef BOOL (__stdcall *SYMGETSYMFROMADDRPROC)
( HANDLE, DWORD, PDWORD, PIMAGEHLP_SYMBOL );
typedef BOOL (__stdcall *SYMGETLINEFROMADDRPROC)
( HANDLE, DWORD, PDWORD, PIMAGEHLP_LINE );
typedef BOOL (__stdcall * SYMINITIALIZEPROC)( HANDLE, LPSTR, BOOL );
typedef BOOL (__stdcall *SYMCLEANUPPROC)( HANDLE );
typedef LPVOID (__stdcall *SYMFUNCTIONTABLEACCESSPROC)( HANDLE, DWORD );
typedef DWORD (__stdcall *SYMGETMODULEBASEPROC)( HANDLE, DWORD );
STACKWALKPROC _StackWalk64;
SYMSETOPTIONSPROC _SymSetOptions;
SYMGETSYMFROMADDRPROC _SymGetSymFromAddr;
SYMGETLINEFROMADDRPROC _SymGetLineFromAddr;
SYMINITIALIZEPROC _SymInitialize;
SYMCLEANUPPROC _SymCleanup;
SYMFUNCTIONTABLEACCESSPROC _SymFunctionTableAccess;
SYMGETMODULEBASEPROC _SymGetModuleBase;
stackwalkerTest.cpp
-------------------
_StackWalk64 = (STACKWALKPROC)::GetProcAddress(m_hImageHlp, "StackWalk64");
if ( ! _StackWalk64( IMAGE_FILE_MACHINE_AMD64,
GetCurrentProcess(),
GetCurrentThread(),
&sf,
pContext,
0,
_SymFunctionTableAccess,
_SymGetModuleBase,
0 ) )
{
....
}
Error 1 error C2664: 'BOOL
(DWORD,HANDLE,HANDLE,LPSTACKFRAME64,LPVOID,PREAD_PROCESS_MEMORY_ROUTINE64,PFUNCTION_TABLE_ACCESS_ROUTINE64,PGET_MODULE_BASE_ROUTINE64,PTRANSLATE_ADDRESS_ROUTINE64)' : cannot convert parameter 2 from 'int' to 'HANDLE' d:\Work\src\Lib\Util\StackWalkerTest.cpp
Error 2 error C2664: 'BOOL
(DWORD,HANDLE,HANDLE,LPSTACKFRAME64,LPVOID,PREAD_PROCESS_MEMORY_ROUTINE64,PFUNCTION_TABLE_ACCESS_ROUTINE64,PGET_MODULE_BASE_ROUTINE64,PTRANSLATE_ADDRESS_ROUTINE64)' : cannot convert parameter 3 from 'int' to 'HANDLE' d:\Work\src\Lib\Util\StackWalkerTest.cpp
Error 3 error C2664: 'BOOL
(DWORD,HANDLE,HANDLE,LPSTACKFRAME64,LPVOID,PREAD_PROCESS_MEMORY_ROUTINE64,PFUNCTION_TABLE_ACCESS_ROUTINE64,PGET_MODULE_BASE_ROUTINE64,PTRANSLATE_ADDRESS_ROUTINE64)' : cannot convert parameter 5 from 'int' to 'LPVOID'
Error 4 error C2664: 'BOOL
(DWORD,HANDLE,HANDLE,LPSTACKFRAME64,LPVOID,PREAD_PROCESS_MEMORY_ROUTINE64,PFUNCTION_TABLE_ACCESS_ROUTINE64,PGET_MODULE_BASE_ROUTINE64,PTRANSLATE_ADDRESS_ROUTINE64)' : cannot convert parameter 7 from 'int' to 'PFUNCTION_TABLE_ACCESS_ROUTINE64'
Error 5 error C2664: 'BOOL
(DWORD,HANDLE,HANDLE,LPSTACKFRAME64,LPVOID,PREAD_PROCESS_MEMORY_ROUTINE64,PFUNCTION_TABLE_ACCESS_ROUTINE64,PGET_MODULE_BASE_ROUTINE64,PTRANSLATE_ADDRESS_ROUTINE64)' : cannot convert parameter 6 from 'int' to 'PREAD_PROCESS_MEMORY_ROUTINE64'
Error 6 error C2664: 'BOOL
(DWORD,HANDLE,HANDLE,LPSTACKFRAME64,LPVOID,PREAD_PROCESS_MEMORY_ROUTINE64,PFUNCTION_TABLE_ACCESS_ROUTINE64,PGET_MODULE_BASE_ROUTINE64,PTRANSLATE_ADDRESS_ROUTINE64)' : cannot convert parameter 4 from 'int' to 'LPSTACKFRAME64'
Any help would be highly appreciated.
Thanks in advance.
John
|
|
|
|
|
John Oliviers wrote: Cannot convert parameter from 'int' to 'HANDLE'" on 64 bit windows for stackwalk64 code
You have to use these types[^] to cast.
Maxwell Chen
|
|
|
|
|
Thanks for your reply.
I have gone through the link, there is no type to cast int to HANDLE(long *). one more thing, both function declaration and parameter are of same type HANDLE, how did the type int came into the picture.
------
typedef BOOL (__stdcall * STACKWALKPROC)
( DWORD, HANDLE, HANDLE, LPSTACKFRAME, LPVOID,
PREAD_PROCESS_MEMORY_ROUTINE,PFUNCTION_TABLE_ACCESS_ROUTINE,
PGET_MODULE_BASE_ROUTINE, PTRANSLATE_ADDRESS_ROUTINE );
--------
_StackWalk64( IMAGE_FILE_MACHINE_AMD64,
GetCurrentProcess(),
GetCurrentThread(),
&sf,
pContext,
0,
_SymFunctionTableAccess,
_SymGetModuleBase,
0 )
Here 2nd parameter GetCurrentProcess() too returns HANDLE type. Then why this error occurs cannot convert parameter 2 from 'int' to 'HANDLE'
Could you please help me ?
Thanks in advance.
Thanks in advance.
John
|
|
|
|
|
Cast int to INT_PTR, then cast INT_PTR to HANDLE.
The principle is:
Under 64-bit environment, int is still 32 bits, but pointers are 64 bits.
There is alignment issue with number values...
-- modified at 14:04 Friday 24th August, 2007
Read this!
Rules for Using Pointers (64-bit Computing, MSDN)[^].
Maxwell Chen
|
|
|
|
|
Modified as HANDLE(INT_PTR(GetCurrentProcess())) but still getting compilation error that cannot convert int to HANDLE.
Thanks in advance.
John
|
|
|
|
|
Hmm... I don't have 64-bit compiler at home, otherwise I could give you a working code snippet...
Maxwell Chen
|
|
|
|
|
Just curious to know that why casting required on return value of GetCurrentProcess()?
GetCurrentProcess return value is HANDLE. I have some knowledge about 64 bit windows that int,long are 32 bit size whereas pointer is of size 64 bit, so casting is required between int,long to pointer and vice versa.
Why do you we need casting on this case ?
I really appreciate your helping tendency and your time.
Thanks in advance.
John
|
|
|
|
|
Yeah... HANDLE should also have been typedefed... 
Maxwell Chen
|
|
|
|
|
Yeah. It has been typedef as long*. But still no need for casting. Right?
Thanks in advance.
John
|
|
|
|
|
Wait...
Could you use [Go to definition], and paste the code snippet for
#ifdef AMD64 // Or x64 something
typedef PVOID HANDLE;
#else // WIN32
#endif
Maxwell Chen
|
|
|
|
|
Hi,
Previously suggestion is also not working. I still got stuck with compilation error.
Any suggestion would be highly appreciated.
Thanks in advance.
Thanks in advance.
John
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
