|
Hiya everyone,
I was searching for some way to find the memory address of a function such as TerminateProcess. Is there a way to do this? I've read something about the VirtualQuery function, but I don't exactly understand how that can be applied. Could anyone give me a few pointers? (and maybe somewhere I can learn some more about windows memory management.)
Thanks. 
EDIT: this is what I'm reading right now.
modified on Thursday, September 24, 2009 2:23 PM
|
|
|
|
|
hxhl95 wrote: I was searching for some way to find the memory address of a function such as TerminateProcess.
Something like:
HMODULE hModule = LoadLibrary(_T("kernel32.dll"));
typedef BOOL (*PROC)(HANDLE, UINT);
PROC proc = (PROC) GetProcAddress(hModule, "TerminateProcess");is much less succinct than Stuart's answer.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
modified on Thursday, September 24, 2009 4:58 PM
|
|
|
|
|
If you have (for example) TerminateProcess's definition pulled in via a header, then &TerminateProcess is sufficient...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks (to both you and DavidCrow, but I can't reply to two threads with a single reply...), I'll try that. Can't believe I didn't think of that... 
EDIT: Okay. So now if I hook TerminateProcess with my own dll, shouldn't the value of &TerminateProcess differ from the address of TerminateProcess in the kernel32.dll? I don't see any difference in the two addresses right now..
modified on Thursday, September 24, 2009 6:08 PM
|
|
|
|
|
hxhl95 wrote: but I can't reply to two threads with a single reply..
You can make a reply pointing to the other one's address... (sorry for the bad pun)
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
[My articles]
|
|
|
|
|
hxhl95 wrote: I was searching for some way to find the memory address of a function
hxhl95 wrote: Could anyone give me a few pointers?
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
[My articles]
|
|
|
|
|
I knew someone was gonna say that sooner or later. 
|
|
|
|
|
Hi All vc++ Masters,
I am migrating my vs-2003 code to vs-2008(on vista machine)...I have the compilation successfully.But i am getting the compilation errors in the debug mode...
I think It should be issue of multiple string datatypes in my project like: MFC Cstring, DblString datatype, char *. It might be mismatch of MFC/ATL Cstring datatype in old and new MFC library....The error is like this...
fwpipd.lib(fwstsrv.obj) : error LNK2019: unresolved external symbol "public: int __thiscall
DomIssuerInfo::HasSurIFeeBillableDebt(class DblDateTime const &,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > const & )
My related function is like this in the code:
BOOL DomIssuerInfo::HasSurvFeeBillableDebt(const DblDateTime& dtReference, const CString& csRatgQualCd )
Can anyone suggest to resolve this error,please....
Thanks in Advance.....
|
|
|
|
|
Vetukuri Raju wrote: Can anyone suggest to resolve this error,please....
Compare the project's Release vs. Debug settings.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hi Thanks for the reply..
I have compared,but not fixed.
Can you please further suggest me......?
|
|
|
|
|
Could someone with experience on this subject point me to sample code or article describing how to communicate between splitter panes in the same frame?
I did few searches and cannot find this subject covered in any useful detail.
I have posted message in left pane and can process it using WindowProc ( in same class).
I am using Spy and do not see how the WM_USER message got there.
I could just keep at it until I find the message-processing path by trial and error.
Any constructive help would be appreciated to speed up this process.
|
|
|
|
|
If you're using SDI or MDI, this sort of communication is already setup for you using the MVC or observer pattern.
From one view you call CDocument::UpdateAllViews[^]. This function will call each view's OnUpdate[^] member function to notify of the changes.
The documentation explains more about it.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I have been using UpdateAllViews (with parameters) to add new view to doc / view, no problem here.
However, I run into assertion problem when trying to RemoveView using UpdateAllViews for now obvious reason ( after few frustrating hours of “coding”) - MFC is trying to update deleted view(s). Now I am using RemoveView in CSplitterWnd and after I figure out how to repaint the splitter pane after views removals I’ll be OK.
There is small catch here - the RemoveView literary removes the whole pane - including the background ( no surprise here) therefore one must CreateView immediately.
Thanks for your help.
|
|
|
|
|
If you're making a change to something both views will see, then you should be making that change in the document, and use UpdateAllViews to "tell" the views that something has changed and they should do something about it.
If you're adding / removing views, then neither the view(s) or the document are the right place to do that. I'd suggest the frame holding the views, either the CChildFrame or CMainFrame (for SDI) would be the right place to handle any "add a new view", "kill a view", "change a view" message.
UpdateAllViews is *not* the place to be murdering Views in their sleep.
I hope that helps,
Iain.
I have now moved to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), or need cotract work done, give me a job! http://cv.imcsoft.co.uk/[ ^]
|
|
|
|
|
Hi,
I need to filter the list of files in a CBCGPListCtrl by extension.The problem is like this :
I have a CBCGPShellTree and CBCGPListCtrl, I'm succeed to display the list of files related to item selected in the tree .But i want to display only files which has a specific extension i.e udl.
So can you help me please.
Thank you
modified on Friday, September 25, 2009 4:11 AM
|
|
|
|
|
|
Hi
a quick question
if I allocate a cdialog derived object via
the new operator
just so I can save data in the object
that won't associate with windows resource
until I do the create specfing the dialog item
from the resource file
after the create. The framework should call
my ::initdialog overideable
sounds right ??
Btw in the create is where I would specify
the dialog item resource
|
|
|
|
|
ForNow wrote: if I allocate a cdialog derived object via
the new operator
just so I can save data in the object
Just for the sake of saving data, why would you want to do this?
ForNow wrote: that won't associate with windows resource
until I do the create specfing the dialog item
from the resource file
after the create. The framework should call
my ::initdialog overideable
Wouldn't it be easier to just code it up and see (when OnInitDialog() is called)?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I have two threads providing information
for the dialog
which ever finishes first I'll save that info
in a Cstring member of the CDialog derived
object
When the second thread finishes and I'am
ready to display the Cdialog I'll do the
Create to get things going
Thank
|
|
|
|
|
Ok, but why use a heap-based CDialog object?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Since I need this storage while the Cdialog
exists it seems like a good place to save the
Data
|
|
|
|
|
Saving the data in the dialog object is fine. I'm just curious why you think it needs to be heap-based. Are you creating it in one place and then doing the thread-related code elsewhere?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I just if I Created it on the I guess stack
e.g. Cdialog mydialog then
1) I would have to pass the Cdialog constructed
paramters such as the dialog resource item
to initialize the windows object
2) the CDialog objects would be lost between
the windows/framwork messages
waiting for the second thread to complete
with the rest of the data
thankx
|
|
|
|
|
ForNow wrote: 1) I would have to pass the Cdialog constructed
paramters such as the dialog resource item
to initialize the windows object
2) the CDialog objects would be lost between
the windows/framwork messages
What does this mean?
Consider these two statements:
CMyDialog dlg;
dlg.DoModal(); The dialog window itself and any controls on it do not exist until DoModal() is called, so you can access non-UI member variables of the dialog object until the object goes out of scope.
I'm not saying you have to do it this way, I was just questioning why you thought you had to do it the other way. Either way works, one just unnecessarily involves the memory manager.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I am using a modeless dialog box
so Create I guess attaches the MFC
object to to the Windows Dialog
I also need the storage of the CDialog
saved between Windows messages
If I save the address of dlg in a CDialog *
would be around (the storage area of dlg)
between Windows messages????
Thankx again
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
