Windows 8 Compatibility Issue

[Inertia]

I'm having difficulty getting the licensing software's software binding to function properly in Windows 8 (works fine in Win7 and XP).  The software binding feature creates registry entries and an ocx file in order to have a persistent record of when something was installed (so the user can't just uninstall and reinstall and have a fresh eval period).   As far as I can tell, these items are NOT created on my Windows 8 machine.  Has anyone tried this feature on Windows 8?  I think the VI that would initiate the creation of these entries is Get License Status.vi

[David_L]

Hi there,

I have definitely done testing in Windows 8 and have not seen any issues specifically that weren't affecting older  OSes.  Do you have any example code that demonstrates how you are using this so I can try to reproduce this here?  Windows 8 compatibility is important for us going forward so any issues you see we'd like to nail down and find a soluttion.

David

[Inertia]

I'm building on an XP machine and deploying to XP, Win7, Win7-64bit, Win8-64bit.  I've read that the SKCA32.dll has a 64-bit version (SKCA64.dll) and because I build on a 32-bit machine this dll never gets bound as a dependency.  I'm suspecting this may be part of the problem (Win7-64bit may provide more 32-bit compatiblility than Win8-64bit).  I'm going to try to build a simple example on a 64-bit machine to verify this theory.

[Inertia]

It appears that unless your application is run as admin, Win8 does not allow writing to the registry or system folders (Win7 appears to allow this as far as I can tell).  This security option prevents the software binding feature from working.  This is a Windows 8 issue (or "feature" if you talk to Microsoft).  I will have to verify that the registry can be written to or just disable my software...

[David_L]

So the very first time that any licensing components are called on a system, it should always be run as an admin.  This should also be the case with Win 7 and Vista.  If you are creating a LabVIEW toolkit, the RegisterAddon.exe should always be called as an Admin.  If you are using the TPLAT API in your LabVIEW-build EXE then the Installer should do some call to the licensing DLL while it already has Admin rights (all installers should always have admin rights during installation).  This can be as easy as just calling the Get License Status.vi or the pp_eztrial1() function in the keylib32.dll.  You don't need to do anything with this, but the act of calling this funciton (or VI) will automatically create the neccessary aliases that need admin priveleges.

As for the 32-64 bit dll ideas, you only need the DLL from the correct bitness that you have compiled your EXE.  In otherwords if you are using LabVIEW 32-bit on a 64-bit system, you only need the 32-bit dll. 

Hope this helps!

David

[Inertia]

We use a third party installer that doesn't perform any licensing functions, though we thought about adding licensing to it but an easier fix is for us just to check if we can write to the registry root (i.e. running as admin).  If we can write to the registry, then allow it to run as eval otherwise disable if not already activated.  This check is also helpful as our customers can update licensing within our app and we can inform them that they are not running with the appropriate privileges to do so.

Thanks for the help!

[David_L]

Sounds good, I'm glad you found a suitable solution!