FLEXlm v4.0 has a completely new API, where every function uses a job handle. In the new API, all the lm_xxx() functions are replaced by lc_xxx() functions. Each lc_xxx() function is identical to the pre 4.0 lm_xxx() function with the addition of a job handle pointer as its first parameter. So, for example, lm_checkin() was called as:
lm_checkin(feature, keep_connection) |
so, lc_checkin is:
lc_checkin(job, feature, keep_connection) |
In this call “job” is a (LM_HANDLE *).
The lc_ prefix stands for “license client function”, while the ls_, used for functions in liblmgr_s.a, stands for “license server function”.
The old API has been preserved with a set of macros in lm_client.h; however, if you want to use the old API, you will need to make the following code changes:
You must invoke either the LM_DATA or LM_DATA_STATIC macro in one of your modules. If you have all your lm_xxx() calls in a single module, Globetrotter Software recommends invoking the LM_DATA_STATIC macro near the top of this module (after including lm_client.h).
If you have lm_xxx() calls in more than one module, you must either use LM_DATA in one module (to generate globals) and LM_DATA_REF in every other module which calls lm_xxx() functions, OR, you can pass the FLEXlm variables using the LM_DATA_STATIC, LM_DATA_PARAM, and LM_DATA_DECL macros. An example of how you would pass the variables as parameters:
#include "lm_client.h" LM_DATA; [...] my_function(LM_DATA_PARAM, p1, p2, p3); [...] void my_function(LM_DATA_PARAM, p1, p2, p3) LM_DATA_DECL; int p1; char *p2. int p3; {...}Note in the example above, LM_DATA declares the variables, LM_DATA_PARAM generates the parameter list to pass them to the called function (and as the declaration in the called function), and LM_DATA_DECL declares them inside the called function. These macros are in lm_client.h.
When you call lm_init(), you MUST specify “&lm_job” as the job handle in the third parameter, e.g.:
rc = lm_init(VENDOR_NAME, &code, &lm_job);
Finally, if you use any of the following internal FLEXlm client-library functions (l_xxx functions), you must add a job handle (lm_job) as the first parameter:
Table B-1. Internal FLEXlm Client-Library Functions
l_allfeat
l_asc_hostid
l_basic_conn
l_checkoff
l_check
l_clr_rcv_queue
l_conn_msg
l_connect_port
l_connect
l_date
l_ether_id
l_featon
l_get_id
l_get_lfile
l_get_port
l_getattr_init
l_handshake
l_host
l_init_file
l_lookup
l_lookup_serv
l_master_list_lfp
l_msgrdy
l_open_file
l_parse_feature_line
l_parse_server_line
l_print_config
l_print_server
l_rcvmsg
l_rcvmsg_type
l_rcvheart
l_read_lfile
l_resend_cmd
l_set_errno
l_set_license_path
l_sndmsg
l_start_ok
l_timer_add
l_timer_delete
l_timer_job_done
l_timer_change
l_upgrade_feat
l_validdate
With the new API, each lc_xxx function takes the job handle as a first argument, so there is effectively no “current job.” If you are using the LM_DATA macro and lm_xxx functions, then you can change “current jobs” by simply setting lm_job to the current job handle, since, all the lc_xxx functions get lm_job as the job handle.
FLEXlm v4.0 added a fifth vendor key to increase the security of your binaries. This key is XORd (“^”) into your two encryption seeds, so that your encryption seeds never appear anywhere in your program or vendor daemon. This fifth vendor key, also, never appears in your application code. The only place they occur is in calls to the new lc_crypt function, which should only be used to generate license files.
The version argument to lc_checkout() has been changed from a double floating point number to a string. FLEXlm requires that the string be a valid floating point number, so the only change that has occurred is that double-quotes (“) must be added around the version argument.
Example, before FLEXlm v4.0:
lm_checkout("f1", 1.0, 1, LM_CO_WAIT, &code, LM_DUP_NONE);
|
Current:
lc_checkout(job, "f1", "1.0", 1, LM_CO_WAIT, &code, LM_DUP_NONE); |
In FLEXlm v4.0, there is no use of floating-point in the libraries, and all the alternate floating-point libraries have been removed from the kits.
The LM_USERS struct previously contained three members that have been replaced. The old members were:
LM_SERVER *server; /* License server */ LM_LICENSE_HANDLE license; /* License handle */ LM_FEATURE_HANDLE feature; /* feature handle */ |
The replacement members are:
CONFIG_PTR ul_conf; /* CONFIG associated */ LM_LICENSE_HANDLE ul_license_handle; /* Server's license handle */ |
The new members provide a better description of the license that the user is using. Note the following equivalences:
old: server => new: ul_conf->server old: license.handle => new: ul_license_handle old: feature.code => new: ul_conf->code |
 | Note: Old->feature.code was a char * — new->ul_conf->code is a char array. |
Change any pre-4.0 references you have in your license generator from l_crypt() to lc_crypt(). This new name was made for additional security on Windows platforms, where DLLs are used. To take advantage of this security feature, never call lc_crypt() (or the new lc_cryptstr() function) in programs that are shipped to customers.
Before calling lc_crypt(), or lc_cryptstr(), you must add the following or similar code:
LM_CODE(code, ENCRYPTION_CODE_1, ENCRYPTION_CODE_2, VENDOR_KEY1, VENDOR_KEY2, VENDOR_KEY3, VENDOR_KEY4, VENDOR_KEY5); VENDORCODE vc; [...] (void) memcpy((char *)&vc, (char *)&code, sizeof(vc)); vc.data[0] ^= VENDOR_KEY5; vc.data[1] ^= VENDOR_KEY5; lc_crypt(lm_job, &conf, l_bin_date(0), &vc); |