LabVIEW
ActiveX CIN
Solved!
evgan wrote:You're right,
I try to explain what I need.
There are two situations which can satisfy me.
1. I create ActiveX in CIN using C/C++ code, do something, convert its pointer to Automation Refnum and pass it to the LabVIEW VI for the further use.
2. I create ActiveX in LabVIEW VI as an Automation Refnum, pass it to CIN, cast it to C/C++ pointer, do something, cast the pointer to Automation Refnum and return it to VI for the further use.
For my aims I can not use a Call Library Function Node or an other ActiveX. Only CIN is suitable for me.
Thank you.
1) There is no documented (and I believe exported) C API to create an Automation refnum!
2) And there is also no documented (and I believe exported) C API to convert an Automation refnum into an Active X object pointer.
Casting certainly won't work because LabVIEW refnums are simply some associative integer indexing into a LabVIEW internal magic cookie jar for the specific refnum class.
That all said you should also disabandon the idea to start with CINs for new designs. They are legacy technology maintained for backwards compatibility but not going to be extended for new LabVIEW platforms/features. The correct way for new designs to incorporate external code in LabVIEW are shared libraries (DLL, so, Framework).
Rolf Kalbermatter
evgan wrote:Hello, Rolf,
You confirmed my guess that it's impossible to make a type casting from ActiveX to Refnum and back, but I hoped there is an undocumented way to do it.
The CIN seems to be a nice place to hide something what I wouldn't want to show, for example, a call to "entirelly" hidden interface, not visible neither in typelib nor in metadata. It's easy to do in C++, but impossible in LabVIEW, because, a VI can't see this specific interface.
Thank you, Evgan
Just as you couldn't in any other Visual interface type programming environment relying on the typelibrary informatio such as Visual Basic, Delphi, etc. etc. You could still wrap the entire class in another ActiveX interface that implements your hidden functionality and adds wrappers to all other methods. I know that is not elegant nor desirable, but I think here the problem to be with the ActiveX component meaning to need to hide a certain object interface, rather than with LabVIEW not being able to access such an interface.
Rolf Kalbermatter
evgan wrote:Hello, Rolf,
You advice me to make a containment (create a wrapper, which implements my hidden interface and call my visible interface).
But I must create an ActiveX which can work if some hidden initial actions was made.
Nobody can run the ActiveX, if he doesn't know this actions. It is very simple.
It's very easy to do in C++ (for example, using h-file), but there are no h-files in LabVIEW.
This ActiveX must work in my LabVIEW only and nobody else can run it, even any other LabVIEW process, if it doesn't know initial actions.
If I create the wrapper everybody can use it, because it has an open interface and call initial actions.
I found that it very easy to do using CIN. The CIN has a very hidden and closed nature.
Unfortunately, I can't pass pointer (C/C++) to ActiveX to CIN and back.
Now I am searching other solution, based on the LabVIEW Call Library Function Node, which, in contrast to CIN, can pass ActiveX pointers.
If you want I can inform you how to do this using other way.
Well I think you make a fundamental reasoning error here. You say you can't put your "secret" code in a wrapper since nobody not even another LabVIEW process must be able to execute that secret code. But putting it in a CIN or DLL does not solve that. I can take apart your VI and execute your CIN/DLL in another process with absolutely no problem just as I can take your wrapper ActiveX control and execute it. The only advantage you have is a little more obscurity.
But you must be aware that obscurity is never equal to security. Basically if you feel this obscurity to be enough for your security needs then I pose the question why even bother? Just for the fun of it?
The proper solution for this involves some challenge/response mechanisme during intialisation of your interface with some encryption/hash methods. That is security although even then it's not failproof because I can also just take your ActiveX control and disassemble it and figure out the challenge/response mechanisme. The question is always only if the complexity of figuring out your challenge/response algorithme will cost more than the gain one could expect from being able to circumvent it.
A hidden interface can be fairly easily identified in a disassmbly and even easier so if you can disassemble a client that is using it. So this is very little effort. Finding and understanding cryptographical algorithmes is usually a bit more difficult but so is designing them and a bad cryptographic protection is often worse than no protection at all.
I have no idea what you are trying to protect here, but just because you feel you have something great that needs protection, does not mean it is so. Basically if you are talking about a limited potential market it does not make much sense to spend lots of time into protecting something when you have not put several times that much into marketing to get your protected product sold at all. If you are talking about mass market then any protection will be cracked sooner or later.
Rolf Kalbermatter
evgan wrote:Thank you, Rolf,
I agree with you to 100%.
Only one detail I'd like to clear.
Our experts in LabVIEW explained me that after building a LabVEW project to EXE-module it's impossible to pull out and see the CIN.
Is it true? If not, please, answer me.
Evgan
Well before LabVIEW 8.0 it was absolutely not true. You could rename yourapp.exe to yourapp.llb and open that file in LabVIEW and see all the VIs in there. True, there was no diagram in those VIs so you could not just open them in LabVIEW and look at the diagram but you could nevertheless copy them out of that "LLB" and use them from another LabVIEW program.
Since LabVIEW 8 the trick with renaming the exe into an LLB does not work anymore but that does not mean that some of the LabVIEW cracks out there can not get at the compiled LLB that is still inside the exe.
Rolf Kalbermatter
