Labviewguru:
Actually the C/C++ forum would be a very poor place to discuss this
problem since almost no C/C++ programmers know anything at all about
NI or the LabVIEW development environment - and CINs are an even rarer
topic yet - but at least some of us LabVIEW developers know something
about C/C++ development which is more common. This guy has a very
difficult problem indeed if he doesn't have the source code. His best
options are:
1) Find a way to get a copy of the source code. By far the best
approach. Try locating the developer (assuming the developer hasn't
died in which case he'll need a OUIJI board and Madam Cleo make
contact.)
Try contacting the company that developed the CIN - perhaps they still
have the source in a file cabinet or hard drive somewhere. (assuming
the company hasn't folded.) If the company did fold, was it bought
out by someone else? They may have the old records still even if the
company has changed hands.
If this company has good customer service at all they should be
willing to help. Offer them a small contract to fix the problem if
they know the hardware.
2) Decompile it and/or run a debugger on it. There are a number of
decompilers available. This can help a lot but it is not guaranteed
to work. It also requires a skilled C/C++ developer.
I've written CIN's but I've never tried to decompile a CIN before so
there may be unforeseen difficulties with this approach as opposed to
decompiling a regular EXE or DLL.
This is why I am opposed to using CIN's in code these days because it
is so proprietary, when all the other development environments support
DLL and ActiveX server. I no longer write CIN's because the code
can't be reused outside of the NI development environment. I predict
that CIN's won't be around (unless maybe for compatibility reasons
with older LV code) in the next major release of LV.
Also, many developers protect executable targets by encrypting them so
that you can't decompile them.
Finally, there may be copyright issues with directly reverse
engineering the code. It would be better to try option #1 first.
3) He already knows the data types being input and output and what the
overall goal of the program is supposed to be so another option is to
replace the unknown code with code of his own based on program
requirements/specifications. Can he deduce what the general purpose
of the CIN is supposed to be? If so he could try to figure out how to
would implement it just by going at it either in LabVIEW or if
necessary in C/C++.
This can be difficult if it involves I/O with a proprietary piece of
hardware. If so then he will need to get all the documentation from
the manufacturer, like a software development kit, etc. before
proceeding with this route.
4) Given that the inputs and outputs are known, he could set up some
for loops etc or user controls etc. to go into the CIN and try to
reverse engineer it by mapping inputs to outputs, i.e. put in values
to the CIN and try to deduce what it is doing by watching the outputs.
This is very time consuming, difficult and error prone especially if
the CIN interacts with hardware.
5) Replace the unknown hardware and associated code interface nodes
with known hardware and known code. Be sure to get the source if it
is from a small time company (mom and pop shop). Obviously big names
like TI, IBM, NI, and Microsoft are not likely to give you source but
if the comapny is small, it seems like a reasonable request to ask for
the sourcec given how quickly companies come and go these days. You
may have to sign a non-disclosure /non-compete agreement to get the
code.
6) Finally, contact NI with the problem, they may have some special
tools for reverse engineering CIN's beyon what I have mentioned but I
doubt it.
Douglas De Clue
LabVIEW developer (and sometimes C/C++ developer)
ddeclue@bellsouth.net
Labviewguru wrote in message news:<506500000005000000E9890000-1023576873000@exchange.ni.com>...
> You should check for the answer to this on a C/C++ forum. I know that
> there are a number of ways to see what exactly a piece of compiled
> code does (though not in LabVIEW), but you may not be able to exactly
> figure out the code.
>
> Your best bet is going to be getting the source code, as there is
> really no way of knowing what is going on without it.
>
> There may be ways to bring the code over however, but I don't know of
> any personally.
