The primary infrastructure needed is to generate the type lib file for .Net to consume
For Delphi or C++, type lib is not that necessary for consuming Island COM I guess.
Ah, thereās that as well I suppose, yes. That;'d portably be tricky/impossible without compiler support.
Iām wondering if using Hydra is an option for now, for you to bridge Island and .NET. It uses COM underneath as well, but I donāt believe it depends on having a TLB, as Hydra can generate matching interface code for both sides.
Iāll get someone from the team to jump in here.
Yes Hydra is an option. I wasnāt aware it uses COM beneath
But this is not convenient for those who donāt have access to Hydra
I am just exploring options to distribute Island-developed solutions to other non-elements languages ( I really like it performance due to the LLVM backend)
1 Like
full qualified COM server should export
function DllGetClassObject(const CLSID, IID: TGUID; var Obj): HResult; stdcall;
function DllCanUnloadNow: HResult; stdcall;
function DllRegisterServer: HResult; stdcall;
function DllUnregisterServer: HResult; stdcall;
I saw to Delphi & FPC sources and it is about 100kb code (~2500 lines) that should be ported to Island for supporting above methods.
I donāt think, that VC++ analogue of COM server will have less codeā¦
we can log an issue for implementing this feature in Island for the future but if you need it is now, you can manually port existing COM Server implementation to Island.
2 Likes
That is cool! I think that is a great feature - it enables Island to integrate with other language and platform; or terms otherwise, other languages and platform can benefit from Island native performance. Really looking forward to it. I can wrap up my TensorFlow-Island as a COM component. Please let me know when it is ready (Alpha, Beta testing) - I can help with the testing at least.
Just a kind reminder - those exported functions are for in-process COM server; an in-process COM server is good enough for me, though.
Also a type library generator would still be needed for other languages to consume the COM server, especially those .NET languages.
- I am not sure your plan about the Island/TypeLib, but if a TypeLib can be generated correctly for Island COM server, then a COM importer would be an easy next step for Island COM client, which means this Feature Request for Island COM Importer is resolved simutaneously too. One stone kills two birds?
This is cool. Does it support arrays, and complex COM types? Any limitation on what COM types are currently being supported?
Hi,
this implementation doesnāt touch any COM types, so I think, standard COM limitation can be applied here.
if host and com server were written in island - you can pass usual [island] interface and pass via it any types.
As I see it, this example is an in-process COM object (activeX dll).
Is it also possible to create an out-of-process COM object (activeX exe)?
Hi,
at this moment we support only dll mode.
Can you give some examples when exe mode is required?
An activeX exe can run distributed (DCOM), an activeX dll can not.
(But is was only a question for information)
Hi,
Can you create a simple DCOM testcase, pls?
we will review it and try to add this support to Island
you can drop email to support@ for keeping privacy
The email was sent.
In case it went unnoticed, The last release of Elements contains a C# template for the ActiveX (COM) dll library. I am certain that the other languages will follow soon 
Waiting for bug in Oxidizer to be fixed so I can translate them, didnāt have the time to translate them manually 
1 Like
Template has now been ported to all five (Go doesnāt do classes) languages, for tomorrowās 2665.
1 Like