# Using Dinkey Pro/FD with LabVIEW

The Shell protection method supports Windows executables (stand-alone applications) produced by the LabVIEW Application Builder.

API protection checks in LabVIEW are implemented using the Virtual Instruments dp32.vi and dp64.vi to communicate with the dongle via the appropriate shared library (dpwin32.dll on 32-bit Windows, dplin64.so on 64-bit Linux, etc.). You should lock these shared libraries with the API method using DinkeyAdd as described in the user manual, and distribute the locked libraries with your software.

Using the Dinkey Pro/FD API in LabVIEW is very similar to using the API with text-based programming languages. See Modifying Your Code in the user manual for information on using the API.

In LabVIEW, the `DRIS` is a cluster with some slight differences to the `DRIS` documented in Structures > DRIS Structure in the user manual. These differences are:

- The fields `header` and `size` are set automatically by the dp32 and dp64 VIs. You do not need to set these fields in your code.
- `rw_data_ptr` is replaced by `rw_data`. This field is an array of bytes representing the actual data passed to/received from the dongle (rather than a pointer to it). Internally, the array is converted to a cluster. Because LabVIEW limits the number of elements in cluster to 256, the maximum size of data that can be passed to/from the dongle in a single protection check is 256 bytes. You must set the `USE_FUNCTION_ARGUMENT` flag when using this field.

In the user manual, possible values for the `function` and `flags` fields are referred to by the symbolic names used in other programming languages. Their literal values are provided here for your reference:

Function | Value
--- | ---
PROTECTION_CHECK | 1
EXECUTE_ALGORITHM | 2
WRITE_DATA_AREA | 3
READ_DATA_AREA | 4
ENCRYPT_USER_DATA | 5
DECRYPT_USER_DATA | 6
FAST_PRESENCE_CHECK | 7
STOP_NET_USER | 8

Flag | Value
--- | ---
DEC_ONE_EXEC | 1
DEC_MANY_EXECS | 2
START_NET_USER | 4
USE_FUNCTION_ARGUMENT | 16
CHECK_LOCAL_FIRST | 32
CHECK_NETWORK_FIRST | 64
USE_ALT_LICENCE_NAME | 128
DONT_SET_MAXDAYS_EXPIRY | 256
MATCH_DONGLE_NUMBER | 512
DONT_RETURN_FD_DRIVE | 1024

The VIs also have a `Path` input that must be used to specify the path to the locked API library. See the LabVIEW documentation for the Call Library Function Node for more information on specifying paths to shared libraries.

The dp32 and dp64 VIs do not support DRIS encryption or user data encryption/decryption.

Before you distribute your application, you must protect it from modification. In general, it is best to use the LabVIEW Application Builder to create a standalone application that can be run outside of LabVIEW. If you are distributing your LabVIEW code as a module to be used in other LabVIEW VIs, don't forget to remove the block diagram from the VI so that end users cannot modify the code! For more information on this, see the LabVIEW documentation.

## LabVIEW Example Files

- dp32.vi - a VI that provides a 32-bit LabVIEW interface to the Dinkey Pro/FD API.
- dp64.vi - a VI that provides a 64-bit LabVIEW interface to the Dinkey Pro/FD API.
- sample.vi - a simple example of using dp32.vi.

## Supported Versions

The LabVIEW sample code provided with the Dinkey Pro/FD SDK was written using LabVIEW 8.5 for Windows, and tested using LabVIEW 8.5 on 32-bit Windows and LabVIEW 2018 on 64-bit Windows. All newer versions should be backwards compatible. The sample code may also work with older versions, but no guarantees can be made, and support for older versions is likely to be very limited.

The sample code should also work without modification on macOS and Linux. If you have problems calling our API from LabVIEW on macOS or Linux, please contact us with full details of the platform and LabVIEW version that you are using.

## Try It Yourself

The sample code is designed to teach you how to use the Dinkey Pro/FD API in LabVIEW programs. Experiment with the sample code to understand how the API works, and read the chapter Increasing Your Protection in the user manual for many suggestions on how to make the best use of the API features.

sample.vi gives a simple example of using the dp32 VI to perform a protection check. If you are using 64-bit LabVIEW, replace dp32 with the dp64 VI. The VI calls the API and checks that the return code is 0 and that the SDSN of the dongle is 10101 (i.e. a demo dongle), turning on the LED indicator if both are correct.

Controls and indicators for the other input and output variables are included to allow you to experiment with other dongle features. It is strongly recommended that you use these other features to improve the security of the dongle protection. See the chapter Increasing Your Protection in the user manual for many suggestions on how to do this.

To run sample.vi you will first need to use DinkeyAdd to produce a locked copy of the shared library for your platform, and program a dongle (if you are using Plus or Net dongles). Set the value of the Path control to the location of the locked library.