Sample code to call Runtime modules in Delphi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This project is written in Delphi 10.3 but should also work in other versions. If you want to create traditional Delphi applications under Windows please use the VCL projects instead. The source files in the project are: File name Description apitest.pas main source code file dris.pas contains DRIS structure definition and other definitions. apitest.fmx form design DllTest.dpr project file DllTest.dproj project file The idea is to include the dris.pas file in your project and use/modify which ever functions from apitest.pas you feel are appropriate. This sample has been tested under Win32, Win64, Mac32 and Mac64 environments. In order to build and deploy under MacOS you need to setup a remote Mac machine using profile. The sample code contains 11 functions. You will not need to use all these functions in your code. Just use which ever functions are most appropriate and customise in your own way. The sample code is just a guide. You should implement the protection in a stronger way using the techniques described in the "Increasing your Protection" chapter of the manual. Code marked with !!!! are places where you should customise the sample code so that it will work properly: * Change the MY_SDSN value to the value of your SDSN * Change the MY_PRODCODE value to the Product Code in the dongle * Change the MyAlgorithm code (if you call a user algorithm) * Change the CryptDRIS code (if you encrypt the DRIS) * Change the CryptApiData (if you encrypt Data you send to our API) * Change the MyRWAlgorithm code (if encrypt Data you send to our API using the R/W algorithm) You will also probably want to replace our error messages with your own. However, you should still display or log any error codes returned by the protection check otherwise you will not be able to identify the cause of the error. (You can look up error codes in our knowledge base: microcosm.com/kb). This project calls the appropriate dynamic runtime module for the OS. (Note, in Windows you could link with the static module instead (we do this for the ObjTest project in the VCL samples). However, we do not supply the correct static libraries for MacOS. This is because Delphi requires the object modules to be in its own custom format.) Note - you should run DinkeyAdd and protect all the runtime modules that you require (for each platform that you want to support. e.g. dpwin64.dll for Windows 64-bit). Do not protect your program directly. Because your program is linked to this library it is protected. The protected library will need to be in the same folder as your compiled program for it to run correctly (in the Mac of MacOS it needs to reside in the Contents/MacOS directory of your application bundle). You can add the protected library to the list of deployment files (Project | Deployment) so that it is copied to the correct location when you deploy it. The Delphi compile has a few quirks under 64-bit MacOS build: 1) You need to have the runtime dynamic module dpmac64.dylib to be present in the project folder for the project to build correctly (this is not necessary under the other build platforms). 2) There is a bug in the linker so that the dpmac64.dylib is not referenced correctly from the deployed application (if you run otool -L on the application you will see that it only references dpmac64.dylib. It should be @rpath/dpmac64.dylib.) The linker does this correctly for the 32-bit build. After deploying you need to open a terminal, change directory to the application /Contents/MacOS directory and then run the following command: install_name_tool -change dpmac64.dylib @rpath/dpmac64.dylib <application name> Ideally you would modify the deployment under MacOS64 so that a script executes this each time. Unfortunately, there doesn't seem to be a way of doing this. Debug Modules ~~~~~~~~~~~~~~ Note - once the runtime module is protected you will not be able to debug your program - after our API has been called. Our strong anti-debug code will cause the debugger to throw an exception. If you do want to debug your code then you can use our debug modules: e.g. dpwin64debug.dll for 64-bit Windows, but these should not be used for release. You could setup your project so that your code links the debug module during your debug build and the standard module when you produce your release code. Note: the debug module has the following restrictions: 1) It will not correctly start a network user (network dongles only). However, other than that the protection check will function correctly and return success. 2) You will not be able to encrypt the DRIS. (If you do encrypt the DRIS in your release build then you should make sure that CryptDRIS does not get called in your debug build). 3) The protection check will take slightly longer than normal. 4) The DDGetNetUserList function will return error 428 (not implemented). 5) A temporary subprocess is created which may be (falsely) detected as malicious by anti-virus programs. Differences with the VCL code ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DRIS: The longint type is changed to FixedInt because longint can be 8-bytes in some platforms The longword type is change to FixedUInt because longword can be 8-bytes in some platforms More conditional code to call native dynamic library on different platforms Uses the dynamic modules and does not link with the static modules APITEST: Uses ShowMessage rather than MessageDlg (now deprecated)