|
Rajkumar_R wrote: please try this on VS2005 and erase "by the looks of things". In VC6 I get EIP as NULL, hence this bahaviour is not because of CPU dependency. Clearly, depends on platform(sw/hw) that I specified explicitly in my first post
But I inspected the generated code from both versions and concluded it wasn't due to code generation differences.
Steve
|
|
|
|
|
I think particularly in a OS based environment generated code doesnot going to be dumbly executed in the CPU. Even, the before calling our main() function, there are CRT based code executed.
I meant May be VS2005 exception handler differs.
|
|
|
|
|
I want to use some memory manipulation while debugging and wish to get into a function which is not normally called by the function. how do I do that.
Any good tutorials on memory dumps debugging I have read one on codeproject but it does not suffice.
|
|
|
|
|
I'm sorry. It is difficulty to understand your question for me.
<br />
wish to get into a function which is not normally called by the function. <br />
Do you mean want to execute the function not normally call?
Or you mean to set breakpoint when the function called?
|
|
|
|
|
I want this one
Do you mean want to execute the function not normally call?
|
|
|
|
|
I think you want to inject or execute code to other process.
if so, try read [ this ] article.
|
|
|
|
|
tom groezer wrote: get into a function which is not normally called by the function
Your question seems strange for me...
While debugging, you can try Next statement, Step into, Set Next statement options to control and analyze the program flow and the contextual values.
You can verify the memory locations by entering the adress or dragging the variables (it's adress) in the Memory Window of Visual Studio.
If you want to check the memory leak in your code,, by defining the macro _CRTDBG_MAP_ALLOC. If this one is defined, CRT will note down each memory allocation and de-allocation. And when we call _CrtDumpMemoryLeaks(), it will dump the leaks to Output window of Visual Studio. In release version it will have no effect. ForIt should be done in release version itself.
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
void Foo()
{
int* pnNumbers = new int[100];
// Dump the leak summery.
_CrtDumpMemoryLeaks();
}
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Any pointers to named pipes, slots and mailboxes for sharing memory?
-- modified at 23:16 Tuesday 12th June, 2007
|
|
|
|
|
I'd suggest changing your subject line, it implied you had a question about pointers.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Do you want handles of all such objects?
|
|
|
|
|
How can I specify that my dlls are called from particular applications only and none other
|
|
|
|
|
|
you can't. You can add password type parameters to stop other programs from using you dll, that's about it.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Yes basically this topic arose during password hacking of a dll by means of a malicious application. How do i prevent that using what u r saying.
|
|
|
|
|
Something like this may interest you:
#pragma optimize( "y", off ) // Make sure we have standard stack frames.
void ExportedFunction()
{
LPCVOID pReturnAddress;
__asm
{
mov eax, [ebp+4]
mov pReturnAddress, eax
}
MEMORY_BASIC_INFORMATION mbi;
DWORD res = VirtualQuery(pReturnAddress, &mbi, sizeof(mbi));
if (res!=sizeof(mbi))
{
return;
}
HMODULE hModCaller = reinterpret_cast<HMODULE>(mbi.AllocationBase);
char ModName[MAX_PATH];
if ( GetModuleFileName(hModCaller, ModName, MAX_PATH) )
{
MessageBox(NULL, ModName, "Calling module's name is", MB_OK);
}
}
#pragma optimize( "", on ) // Reset to default.
Printing the module's name is just an example. This shows how you can identify your caller however.
Steve
|
|
|
|
|
Hi.
Is it possible to ShellExecute Windows Explorer; ie) simply opening and displaying a folders' content, without the explorer tree pane. In this specific case the user does not need to be distracted by the left hand directory tree pane ?.
Regards.
James
|
|
|
|
|
Maybe EXPLORER.EXE drive:\path ?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks for the update.
I already have a fully qualified target path, I would like to be able to open the folder without the anoying left hand tree pane.
James.
|
|
|
|
|
Right
That was the command you could use in CreateProcess()/ShellExecute():
EXPLORER.EXE driveletter:\path
This one also works on XP:
EXPLORER.EXE /n, driveletter:\path
Both open Windows Explorer as a "My Computer"-style window - single pane, no tree.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks very much..
I will try the /n option.
As for the first bit; I am actually running XP and the 'driveletter:\path' does indeed still open explorer with the tree pane, however I will try your second suggestion..thanks for the help.
James.
|
|
|
|
|
Here's another example
::ShellExecute(*this, _T("open"), _T("EXPLORER.EXE"), _T("/n, driveletter:\\path"), NULL, SW_SHOWNORMAL);
although the following is probably better since it's not bound to exporer.exe or specific
command-line arguments:
::ShellExecute(*this, _T("open"), _T("driveletter:\\path"), NULL, NULL, SW_SHOWNORMAL);
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
This did the same thing on XP:
::ShellExecute(hwnd, _T("open"), _T("driveletter:\\path"), NULL, NULL, SW_SHOWNORMAL);
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks Mark.
I Like that one; I will try it .. and get back to you tomorrow..its very late here...
I appreciate your help.
James.
|
|
|
|
|
Mark.
Thanks very much for your help.
It's all sorted now .. many thanks.
James.
|
|
|
|
|
Hi,
I have just installed Vista and of course my old VC++ 6.0 won't work on Vista so I'm finally jumping to Visual Studio 2005.
I can save a few bucks by getting the upgrade version of Visual Studio 2005 but I'm concerned that Vista may want to see VC++ installed on the hard drive. In the past, MS products were satisfied by just seeing the qualifying product CD in the drive but that seems to be changing. This would put me in a pickle since I can't really install VC++ 6.0 (and if I did it may muck up Vista).
Anybody know for sure if the VS 2005 upgrade product will install w/o having my VC++ 6.0 product on the hard drive (ie. just a CD verification)?
Thanks
|
|
|
|