Extension Modules > COM
Couple Api ideas for embedding
Support:
Dave,
Great progress! I'm looking forward to start using some of this code.
Do you think this would work with Mono as well? (COM & Mono)
--- Quote ---Note that there is very little that ties COM Interop to Windows. COM is a binary standard, so anyone who follows that standard can use the COM Interop functionality in mono.
--- End quote ---
John
dzzie:
Not sure I understand so I will kinda talk out loud.
Its true the COM standard can be implemented as a method of Interface and function pointer discovery on any system. Its just a communication protocol.
If the question is could this technique be used to call .NET code written in Mono, its possible I suppose. I know C# has a way of registering .NET classes for use with COM by using a COM visible attribute, creating a typelib, and registering itself in the registry. Going from COM to .NET and back feels like functionality that MS shoehorned in for compatibility reasons.
I have also seen an example where shellcode could initialize the .NET runtime and call code written in IL for execution. If i wanted to interact with .NET code I think I would look first at this technique because it probably does not require special registration of the .NET classes on the target system.
(this isnt the example i was thinking of but all i could find in a quick search)
http://blog.didierstevens.com/2010/04/13/net-shellcode/
I havent looked at these examples in depth but I would say being able to host the CLR in your code and let script basic call out to its methods should be doable from the shellcode example.
It comes down to having clients to talk to and how to you find them. On Windows COM is heavily registry dependent to locate the class containers (dlls)
Support:
Dave,
Is this a 32 bit Windows only solution? IUP has a OCX container (ATL) that the webview control runs in. Maybe it could be used with your extension module.
Thanks for all the hard work you have put into this.
John
dzzie:
I have been a high level COM user mostly, and have dealt with the low level details just a handful of times.
I believe you can write 64bit COM servers. COM also supports remote servers such as a machine across the network
and out of process servers like a seperate exe on same machine. Right now I have only specified it to create in process servers which means that only 32bit servers could be used if it was compiled in 32bit mode.
I have not tested if it compiles properly for x64. I will be using it for interacting with VB6 COM classes (dlls) which are exclusively
32 bit. My dev system is only 32 bit as well. I have been avoiding the WOW64 environment because of things like file and registry redirection. Since VB6 is limited to 32 bit only it just adds headache and no value.
As far as interacting with OCX controls. In order host a container you need to implemented a bunch of COM interfaces to give
it a place to display itself. I have no experience with these on a low level in C. Just calling methods on a COM object probably arent enough to display a GUI unless it has methods like CreateForm etc. OCX can also house regular COM classes as well so this is possible for self hosting I have a hexeditor control like this.
The experiments I am currently do with this are my cutting edge of what I can pull off lol. Which is what makes it fun :)
Cross platform dev, 32/64 compatiable code and low level COM are all new to me so no guarantees on what changes may be needed to get it to work outside of the environment I am building this for.
Support:
The IUP ATL container takes care of all the display and initialization issues. It doesn't provide method and and event support. There is Lua COM support for the container but that is about it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version