lock or read-only sequence file

[HysHysHys]

Hi all,

Is it possible to lock a TestStand sequence and also disallow any user (also administrator) to view and edit the contents of subsequences (or any step) of this file.

I have a C API (compile as a DLL) and I want to make a TestStand wrapper of this C Api. For each C functions, I want to make a sub sequence in Test Stand that simplify user life but also hide a license mecanism (by calling my license server api in sub step). Of course these steps should be hide and should be not editable or deletable.

The only thing that the user should be able to do is to call any sequences in this file and to specify any parameters for these sequences.

Vincent

[Scott_Richardson]

Vincent -
Currently TestStand does not have any features to lock or prevent a sequence file from being read. The only options that you have is to force a license mechanism or protect intellectual property is to more it into a binary code module (DLL, vi, etc).

I should mention that I am not sure that such a locking feature could be complete because of the openness of the TestStand API. For example TestStand cannot prevent simple access to a sequence file and its contents because your code in the sequence file and code modules that the file calls need the API to access the context which includes the file during runtime.

Scott Richardson (NI)

[HysHysHys]

Thanks Scott,

1) My main problem is that we also distribute our C-Api as a single product. This Api already checks for user license, but it cannot know if it was called from TestStand or directly from C/C++ code. This is why I want to add a simple hidden license check directly in TestStand.

Do you think it's possible in my C API dll to detect automatically if it was called from TestStand or from C/C++?

2) Is it possible to do something with the TestStand deployement tool, as making a read-only binary package including my sequence files and my subsequence?

Thanks
Vincent

[Scott_Richardson]

Vincent -
1) The SDK function GetModuleHandle retrieves a module handle for the specified module name if the mdoule file has been mapped into the address space of the calling process. So you could see if the "teengn.dll" file is loaded, which would suggest that the TestStand is being used, nothing more.

2) The deployment tool is just a packaging tool for copying TestStand and user files to a system. The files installed on the target system are not any different than the original source files.

Scott Richardson (NI)