|
Quit spamming the board. You've already asked your question. Do you think people are going to be more inclined to answer now?
L u n a t i c F r i n g e
|
|
|
|
|
Using VC++(MFC) in Visual Studio 2008 is called unmanaged. Built on .Net framework is called managed. They are totally different.
I think it is a good timing for you to switch to C# now.
|
|
|
|
|
Hello,
Can any body give me the idea how to extract information from win 32 dll's.
e.g
class name
all methods which dll exports.
name of methods, parameter types(in,out) & return type of that method.
all variables (private,public,protected).
all data structures listed
we can do the same job from tlb file which's generated from idl which stores all COM exposed interfaces,co-classes,records,enums and etc..
MS provided TypeLib for this purpose. but from DLl perspective can we do the same job as we can do from tlb using ITypeLib of MS.
Regards
Muhammad Usman Khalil
|
|
|
|
|
If a DLL expose all the information you want, where is abstraction in it?
Then whats the difference of providing a code and DLL?
As far a i think,
you can get the exports and imports of a DLL by parsing the PE file programmatic ([^])
well dependency walker avail with Visual studio is finished product that will be useful for the purpose to get information about the methods.
But regarding the parameters, variables, cannot be extracted from the DLL without the code.
Well whats the use for you, to do so? 
Величие не Бога может быть недооценена.
modified on Friday, January 15, 2010 7:43 AM
|
|
|
|
|
What OLEView do with TLB files : parse them, extract every single info(e.g methods,parameter names,their nature in/out, all interfaces types dispinterfaces or simple interfaces, modules and records etc..)
Same information want to extract from win32 dll's. But as win dlls always not generate tlb file or idl file, so how does the way to go..?
Regards
|
|
|
|
|
The TLB 'equivalent' of a standard DLL is its header file.
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]
|
|
|
|
|
As pallini suggested, you need header file .
Величие не Бога может быть недооценена.
|
|
|
|
|
bascially I am writing a QTP (Software used for test automation---executing test cases repeatedly written in a script format, not exact idea how it workds.. ) like tool.
which test my com servers(can be achieved via parsing TLB file generated via idl ..and I've DONE), my all Win32 DLL's(need to parse and have to extract all info seperately like methods,their parameters,imports and exports..???) and fianlly i need to test all my js files(similarly all functions with their params probably i need to write few regex's (Regular Expressions) which will do this job) ..
that's it..
Points u given i have got..Any suggestions and recommendations still...?
Regards
Muhammad Usman Khalil
|
|
|
|
|
I have worked with 2 automation projects. Where i have to test the API's, whether they are working correctly based on the input and check the output.
In that case, we wrote a COM DLL as the interface between the COM EXE and the test data.
where our input is passed from the VB scripts.
In another one, we used INI file to configure the input and the exe read the input from the INI file and pass it to the DLL that is to be tested, which holds some library.
Now tell me whether your case match any of these?
Величие не Бога может быть недооценена.
|
|
|
|
|
matched with none..
actually COM server testing not an issue..World has given some standards to extract information from COM environments like TLB's(we can extract every info methods,params and their types and nature, structures, modules, co classes) easily. As these are standards which 3rd party can use to extract info from this e.g ITypeLib .....All Correct!! and I have done this.
I have stored all TLB parsed info as INI or XML and its ready for input for other frameworks.
I have BIG PROBLEM about Win 32 DLL's. MS or others have not given any standards for Win32 dll's from every aspect(like how many functions contained by DLL, how many parameters as input for every function, how many structs ,modules,interfaces,imports & exports a dll have) ..So how can we parse these DLL's and can extract information (statted above) from DLL's.
e.g KERNEL32.dll (its Win32 DLL) contains how many functions, return types of these functions, input parameters and output parameters,types of these params, modules and structs it contain.
One way is PE Parsing..With this way we unable to get parameter types,names and return type of function(but we get fully decorated name of method..with some HEX stuff)
Finally header file remains(as suggested others), but dont know how much difficulties can produce in this way.
Moral is DLl's have no standards contrast with COM which have defined standards.
|
|
|
|
|
DLL are hard to reenginner.
You need either the header or a documentation for it.
Else trail and error with some freaky methods
Величие не Бога может быть недооценена.
|
|
|
|
|
If your DLL has debug information then you can use DIA (Debug Interface Access) SDK, which will extract information from the pdb files.
Величие не Бога может быть недооценена.
|
|
|
|
|
OK..!!
As we know that we can extract information like imported/exported functions after parsing PE file programatically.
But we can only take the names (function names imported/exported) of methods. We cannot look up their parameters(in/out)names with their types and return type of method.(as these parts encoded as HEX)
Is there any way out to extract these as well..?
Regards
Muhammad Usman Khalil
|
|
|
|
|
You may also have a look at the article : An In-Depth Look into the Win32 Portable Executable File Format.
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]
|
|
|
|
|
Hi All,
I want to develop an 3D Image rendering software using DIRECTX which can perform some 3D Operations.My customer wants the software developed on .Net Framework.
I have experience in coding in MFC in VC6.0.If i develop an application in MFC dialog based application in Visual Studio 2008,will it be built on .Net Framework?
Also,i have done some image processing coding in C++.Basically i have some classes defined in .h and .cpp files which i want to include in the .Net application which i am going to develop.
For the above requirements should i go for VC++.Net(Forms based developed in VS 2008) application or VC++(MFC based developed in VS 2008)?
Please advice.
Thanks ,
Ashwath.
|
|
|
|
|
I would use C#.
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]
|
|
|
|
|
CPallini wrote: I would use C#
... and OpenGL instead of DirectX (  ).
L u n a t i c F r i n g e
|
|
|
|
|
Well, why does the customer tell you what technology to use to build a software? Shouldn't you (the developer) be suggesting what's best for accomplishing a given task?
You could wrap your C++ image processing code into a COM dll and use it from C#, instead of writing the whole thing from scratch in C#.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: You could wrap your C++ image processing code into a COM dll and use it from C#, instead of writing the whole thing from scratch in C#.
Why bother with COM? It's simple enough to write DLLImport statements and use a native C++ DLL as is.
L u n a t i c F r i n g e
|
|
|
|
|
by writing functionalities in COM u'll be able to build it as server components and call them in any technology(e.g C#)as client and can perform out of process calling easily..
DLL's always not allow you out of process calling untill RPC which's tough to manage.
So I think writing COM dll in VC++ idea is better and integrating it with C# will blend things moore significant way..
|
|
|
|
|
Thank you very much for the advice.Well,if i develop the software using
VC++(MFC) in Visual Studio 2008 IDE, will it be built on .Net framework.Why i ask is because i have good experience in VC++(MFC).
Thanks,
Ashwath.
|
|
|
|
|
ashwath1979 wrote: Well,if i develop the software using
VC++(MFC) in Visual Studio 2008 IDE, will it be built on .Net framework
What are you talking about? Unless you target one of those versions of the .NET framework and write managed code, your application would remain native. Just because you use the VS 2008 IDE doesn't mean your application is built on .NET framework.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Thanks Rajesh for the answer.If i develop a VC++.Net application(Form type),will it be developed on .Net framework.
|
|
|
|
|
You mean a managed c++ (C++/CLI) application? Then yes, it would be using the .NET framework.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Yes, i have choosen the "windows forms application"(Managed c++/cli) type project in the "new project" menu.This is built on top of .Net framework right?
Please advice,
thanks,
Ashwath
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
