Concept SoftwareConcept Software Forum
  Home | Log In | Register | Calendar | Search | Help
   
Concept Software Forum > General Information > Pre-Sales Questions > x64 support  
Forum Quick Jump
 
New Topic Post Reply Printable Version
[ << Previous Thread | Next Thread >> | Show Newest Post First ]

bubble
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2006
Total Posts : 2
  		   Posted 3/29/2006 7:52 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
We are currently using your protection methods as our software key. It doesn't work on x64 systems software developer says its 16bit and needs to be at least 32bit to run. Do you have any upgrade that supports x64 software key for our software
Back to Top
 

Brian_Metzler
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2005
Total Posts : 248
  		   Posted 3/30/2006 11:05 AM (GMT -5)    Quote This PostAlert An Admin About This Post.
The only thing that is currently supported with Protection PLUS is running a 32-bit executable on a 64-bit platform. Within the next few releases, we will natively support 64-bit executables/binaries on 64-bit platforms, with our APIs.

The only thing that might be causing a problem with a previous version is if you are using the BIOS algorithm. This is because the BIOS algorithm requires an external driver to properly grab the information. This was originally done with Machnm1.exe, which is a 16-bit executable. As of Windows x64, Microsoft removed the 16-bit compatibility layer known as WOWEXEC. We have since added support for Machnm32.sys (released in v4.2.1.7) and Machnm64.sys(released in 4.2.1.12).

To properly run a program that uses the BIOS algorithm on x64 based systems, you need to reference Machnm64.sys. This can be done by either using the COMPNO_BIOS64 flag, or just the COMPNO_BIOS flag.

If you use the COMPNO_BIOS flag, it will automatically choose the best driver to attempt first, based on operating system.

Please note that Machnm64.sys is needed to get the BIOS information from a Windows x64 system (Windows XP 64-bit Edition, Windows 2003 64-bit Edition, and Windows Vista 64-bit Edition).

Machnm32.sys was created to help with the errors "Cannot communicate with Machnm1.exe!" on Windows NT based systems (Windows NT 4.0, Windows 2000, Windows XP, Windows 2003, and Windows Vista).

I hope this helps.
Back to Top
 

bubble
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2006
Total Posts : 2
  		   Posted 3/30/2006 11:17 AM (GMT -5)    Quote This PostAlert An Admin About This Post.
Okay I have another question. We had a report of our software not working and the software developer said it was from the key software "you" and I installed our software on my system at home AMD 64bit duel core 4200+ running XP x64 OS and it worked fine and yes we use the bios function.

Should this not have worked? the guy that said it doesn't work is running Intel 64 bit chip equivalent to the AMD x64 chip
Back to Top
 

Brian_Metzler
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2005
Total Posts : 248
  		   Posted 3/30/2006 5:37 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
There are no chipset dependencies built within the BIOS algorithm, or any of the existing Protection PLUS libraries.

It might be the fact that you are running against Machnm64.sys, and he is not. This would definately cause a problem on his side. Please make sure that Machnm64.sys is copied into the Windows\System32 and Windows\SysWOW64 folder on the target system.
(There is a known bug in 4.2.1.12 that if the file isn't in both directories, it will not properly be loaded.)
Back to Top
 

Harshad
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2009
Total Posts : 28
  		   Posted 5/26/2009 4:57 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
Protection Plus 4.5.9.1 and Instant Plus 3.0.0.3 native 64 bit libraries are now available.

Regards,
Harshad
Back to Top
 

LonOrenstein
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2008
Total Posts : 7
  		   Posted 6/2/2009 9:13 AM (GMT -5)    Quote This PostAlert An Admin About This Post.
Hello Folks,
 
We have an x32 .NET application which uses Protection PLUS .Net API. Users on x64 (Vista x64 Ultimate) get the following error when the LFFile component is being initialized - "is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)".
 
The component is initialized as follows:

            this.licenseFile = new SKCLNET.LFile();
            this.licenseFile.CPAlgorithm = 65536;   // Code 1 don't work also
            this.licenseFile.CPAlgorithmDrive = "0";
            this.licenseFile.CPTolerance = 20;
            this.licenseFile.DateFormat = "M/d/yyyy";
            this.licenseFile.EZTrial = true;
            this.licenseFile.LFOpenFlags = SKLFOPENFLAGS.CREATE_NORMAL;
            this.licenseFile.LFPassword = "******xx";
            this.licenseFile.LFType = SKLFTYPES.FILE;
            this.licenseFile.Name = "licenseFile";
            this.licenseFile.SemPath = "C:\\";
            this.licenseFile.SemPrefix = "sema";
            this.licenseFile.SemType = SKSEMTYPES.SEMFILE;
            this.licenseFile.UseEZTrigger = true;
            this.licenseFile.UseLastUsedTime = true;
            this.licenseFile.LFName = "license.dll";
 
Copying the MACHNM1.EXE, MACHNM32.SYS, and MACHNM64.SYS into System, System32, SysWOW64 files doesn't help us. We also tried to use the Enhanced (COMPNO_ENHANCED [65536]) algorithm and the legacy algorithm with COMPNO_BIOS [1] set but it did not help.
 
I would appreciate if anyone would come up with a solution.
 
Thanks,
Lon
Back to Top
 

woz
Forum Moderator



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2004
Total Posts : 357
  		   Posted 6/2/2009 9:16 AM (GMT -5)    Quote This PostAlert An Admin About This Post.
Lon,

Are you setting your .NET project settings to target Win32 instead of Any CPU?

Mike
SoftwareKey.com

Back to Top
 

LonOrenstein
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2008
Total Posts : 7
  		   Posted 6/2/2009 10:36 AM (GMT -5)    Quote This PostAlert An Admin About This Post.
Thank you for the answer.
 
Any CPU is set in project settings.
 
Thanks,
Lon
Back to Top
 

LonOrenstein
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2008
Total Posts : 7
  		   Posted 6/5/2009 9:03 AM (GMT -5)    Quote This PostAlert An Admin About This Post.
We are still having the issue I submitted a few days ago in this thread.
 
I would greatly appreciate any help.
 
Thanks,
Lon
Back to Top
 

KevinD
Forum Moderator



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2007
Total Posts : 737
  		   Posted 6/8/2009 12:13 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
Lon:

Did you change the target platform from 'Any CPU' to 'x86' (Win32) as suggested by Mike? This is required when using our 32bit .NET component on 64bit Windows.

Let us know if you have any further questions.

Regards,
Kevin

SoftwareKey.com Support Team
Back to Top
 

GlenT
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2008
Total Posts : 2
  		   Posted 8/25/2009 6:57 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
Sorry if this slightly hijacks the thread, but I've had the same issue as above ( "is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)").
 
It was resolved as suggested (changing to x86 rather than All CPU). However, now I can only get a computer number (CPCompNo) of "1". The program can still be registered, but I'd assume there should be a better number :)
 
Below is the code I'm using to initialise the LFile. (Using C# and SKCLNET)
// Create the license file object
_SK = new SKCLNET.LFile();
// Setup the error event
_SK.Error += new SKCLNET.LFile.__Delegate_Error(LicenseFile_Error);
// Setup the status changed event
_SK.StatusChanged += new SKCLNET.LFile.__Delegate_StatusChanged(LicenseFile_StatusChanged);
// Setup the trigger event
_SK.Trigger += new SKCLNET.LFile.__Delegate_Trigger(LicenseFile_Trigger);
// Setup the Algorithm to be used
//_SK.CPAlgorithm = 65535; // COMPNO_ENHANCED (Tried with and without this line)
// Setup what the license file object will do if the license file does not exist
_SK.LFOpenFlags = SKLFOPENFLAGS.CREATE_MISSING;
// Set the type of license, file or registry
_SK.LFType = SKLFTYPES.FILE;
// Set EZTrial to false, we aren't using that method
_SK.EZTrial = false;
// Set the password. (Extract this to somewhere else?, encrypt?)
_SK.LFPassword = insertpasswordhere;
// Set the path for the semaphores
_SK.SemPath = Application.StartupPath + @"\";
_SK.TCSeed = insertTCseedhere;
_HardwareCode = _SK.TCSessionCode;
Any suggestions would be fantastic!
 
 
Back to Top
 

KevinD
Forum Moderator



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2007
Total Posts : 737
  		   Posted 9/1/2009 12:09 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
Glen,

>>It was resolved as suggested (changing to x86 rather than All CPU). However, now I can only get a computer number (CPCompNo) of "1"

>>SK.CPAlgorithm = 65535; // COMPNO_ENHANCED

COMPNO_ENHANCED is actually defined as 65536. Using 65535 will cause all Computer ID algorithms except the Enhanced algorithms to be used. The Computer ID of '1' is likely coming back from our unsupported BIOS algorithm.

Let us know if you have any further questions.

Regards,
Kevin

SoftwareKey.com Support Team
Back to Top
 

ppfeifer
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Oct 2009
Total Posts : 1
  		   Posted 10/21/2009 5:11 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
So, if there is native support now for 64 bit OSes, do we still need to set the target platform to x86, or can it be set back to "Any CPU".
--Pat
Back to Top
 

woz
Forum Moderator



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2004
Total Posts : 357
  		   Posted 10/21/2009 5:20 PM (GMT -5)    Quote This PostAlert An Admin About This Post.
Pat,

SKCLNET is a 32-bit library, so you must always target x86 platform.
Back to Top
 
New Topic Post Reply Printable Version
Forum powered by dotNetBB v2.42
dotNetBB © 2000-2010
© Concept Software 2002-2009 :: All Rights Reserved ::

Forum Disclaimer | Need Support? | Forum Help Manual