Re: Fujitsu support - need help - Netcobol for windows and licensed controls.

On Tue, 13 Jun 2006 13:15:53 -0600, Jeff Campbell <n8wxs@xxxxxxxx>
wrote:

Frederico Fonseca wrote:
On Mon, 12 Jun 2006 22:04:14 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxx> wrote:

"Frederico Fonseca" <real-email-in-msg-spam@xxxxxxxxx> wrote in message
news:2f4q82t0n3vadc2epu2385uk4jfh52i2a4@xxxxxxxxxx
On Sun, 11 Jun 2006 23:26:48 -0600, Jeff Campbell <n8wxs@xxxxxxxx>
wrote:

Frederico Fonseca wrote:
Hi all,


I have a question that so far I have been unable to solve, and either
someone here has a solution for it, or I would like to have someone
with an active maintenance contract with them to pose this question to
them.

Situation
Power COBOL V7, 3rd party OCX control, properly licensed.

When run in test machine it gets a message box appears saying "file
License.dat is not found. License Agreement can not be completed"
If we copy the ".lic" file into the same folder as the supplied
activeX .OCX then it works fine, but this is obviously ilegal to do,
as it is basically distibuiting the development license.

The file names are different. Isn't that relevant? How does the "license.dat"
file get created? (And what does it contain?) The ".lic" file appears to be the
development license key, while the "License.dat" file seems to be the deployment
license key. Correct? My assumption would be that the install script for your
application must copy or create the "License.dat" file, at installation time,
in the same directory as the newly installed copy of the .OCX file.
Incorrect. The message I mentioned here was just an example. On this
particular control it open a message window with a "thanks for trying
our software" and with a timer (incremental). What happens when a
control is found unlincensed is up to the control designer. Some do
pretty things others just return with "not licensed".

Sorry if I wasnt more clear on this, but did not consider this to be
an important aspect of this problem.



It may not be as illegal as you think. The supplier may have no problem with
you doing this. Talk to them.
I read the license they supply, then I spoke with them, then several
emails were exchanged with them regarding the technicalities, and ONLY
after all other venues were exhausted I did post in CLC asking for
help.


From what I have found so far it seems that FJ is not implementing the
functionality of IClassfactory2 interface which is the method many
ActiveX controls use to determine if the control is being distributed
from a legal copy of the software, and I have been unable to find a
way to "fix" this from within POWERCobol.
Jeff is correct and there is nothing Fujitsu can do about your problem. It
is down to the third party supplier to provide a run time license file (or
not).

This is true because the IClassFactory2 methods are implemented by the
windows COM library, not PowerCOBOL. The .OCX you are using invokes these
methods, not PowerCOBOL.
Incorrect for both Jeff and Pete.

IClassFactory is implemented within COM that part is correct, but it
is up to the container to allow for the available licensing controls
in order to allow controls to be added to it. Although the ActiveX
control does not NEED to use the IClassFactory it does need to
implement it (at least in C++). It is up to the container to see if it
is implemented and if required by the control then he (the container)
should use it.


I was incorrect above. IClassFactory and IClassFactory2 are *interfaces*
defined by COM. Their *implementations* are coded in the class object, ie,
your ActiveX component, not the COM library. The COM library will call the
implemented code when an instance of the ActiveX object is created at runtime.
IClassFactory and IClassFactory2 are classes implemented by the
ActiveX controls. Inherited from COM for sure, but still locally
implemented. See below.


The .OCX you are using may not allow 'runtime' license deployment on a
'development' licensed machine. The .OCX developer should have information
on the licensing requirements.
IClassFactory2 IS the method used to create objects that require a
license key/string to be supplied to the said object so they can
verify they are valid. Other methods include supplying a property on
the object, or supplying a ".lic" file that is only used for runtime
validation and not development.
No, it is only a CONVENTION and nobody writing COM controls HAS to implement
that interface (I don't). I would contact the supplier and explain the
problem. If they require validation through that interface, they should
provide a method which implements it. If they don't, then it is fair to ask
them how the component is to be validated at run time.

They may require you to do it directly using the COM library. Whichever way
you look at it, it is hardly a Fujitsu problem.

PowerCOBOL is simply a container just like any other COM container. If you
placed this component on a server side page, would you complain to Microsoft
because ASP was unable to instantiate it? :-)
I didn't, but others did. And note that a component is not the same
thing as an ActiveX Control.

Fujitsu cannot possibly know how every third party supplier is going to
require run time validation.(If they require it at all...)
as I said this validation is a subset of the IClassFactory (which FJ
DOES implement), and it is a subset used to validate licensing. Once
it is implemented correctly by any container, it will work with ALL
third party controls used within that container.

Not possible. I might use a trapdoor algorithm to compute a license key,
while another developer might use one or more registry values to store a
precomputed license key. Another developer might use a file 8-) to store
the key. The control's IClassFactory2 code would have to be implementation
unique to handle these and any other possible license methods. No two
controls will necessarily do it the *same* way.
You still do not understand how the IClassFactory2 works. I will try
to explain this to you.

IClassFactory2 is an extension of IClassFactory.
This extension enables a class factory executing on a licensed machine
to provide a license key that can be used later to create an object
instance on an unlicensed machine. Such considerations are important
for objects like controls that are used to build applications on a
licensed machine. Subsequently, the application built must be able to
run on an unlicensed machine. The license key gives only that one
client application the right to instantiate objects through
IClassFactory2 when a full machine license does not exist.



They have the following methods.
IClassFactory
CreateInstance
Creates an uninitialized object.
LockServer
Locks object application open in memory.


IClassFactory2
GetLicInfo -
Fills a LICINFO structure with information on the licensing
capabilities of this class factory.
RequestLicKey
Creates and returns a license key that the caller can save and use
later in calls to IClassFactory2::CreateInstanceLic.
CreateInstanceLic
Creates an instance of the licensed object given a license key from
IClassFactory2::RequestLicKey.


To instantiate the component within your client application, first try
to instantiate the object directly with IClassFactory::CreateInstance.
If CreateInstance succeeds, the second machine is licensed for the
component and objects can be created at will. If CreateInstance fails
with the return code CLASS_E_NOTLICENSED, the only way to create the
object is to pass the run-time key to the
IClassFactory2::CreateInstanceLic method. CreateInstanceLic verifies
the key and creates the object if the key is valid.

In this way, an application built with components (such as controls)
can run on a machine that has no other license?only the client
application containing the run-time license is allowed to create the
component objects in question.

The IClassFactory2 interface supports flexibility in licensing
schemes. For example, the server implementor can encrypt license keys
in the component for added security. Server implementers can also
enable or disable levels of functionality in their objects by
providing different license keys for different functions. For example,
one key might allow a base level of functionality while another allows
basic and advanced functionality, and so on.

So this interface is only use to get the license information while on
the development machine (RequestLicKey). This is suplied in a
bitestring that the container MUST store if so required by the
component. The component can just implement the IClassFactory2 to say
that "no license is required", and as such the standard
IClassFactory::CreateInstance will work.
Or it may required a license, and if he (the Control) has choosen to
implement this with the IClassFactory2 method, then he will expect
this license (as retrieved by the RequestLicKey method) to be supplied
as part of the IClassFactory2::CreateInstanceLic method.

It is up to the Control to decide the content of that license string.
For example on the case of the control I am using it is a simple
readble string associated with the control name. Others, as mentioned
above, can supply an encrypted string.

There is a lot more information on the web about this implementation.
Please feel free to google for it (or www.microsoft.com)




(In my experience many suppliers don't require it, and there is nothing to
stop anyone re-usng their component once it is registered on a client
system. (Of course, the majority of clients are not developers and probably
don't have an Object Browser readily available to find out the methods and
properties...). Also, most clients would not even be aware the component was
there once they had installed the application.)
My experience (although not with FJ COBOL) is MANY suppliers do
require a runtime license, and most of them do implement it using only
the mentioned class. The fact that most "clients" do not notice that
they have available a illegal license of a piece of software will not
prevent BSA (or whatever similar legal entities available on your
country) from processing your company should it be found in 100 of
your computers, as supplying the ".lic" without proper authorization
would amount to piracy.

I honestly believe your best option here is to communicate with the
supplier.

Pete.

Not really. Best option would be for FJ to have this implemented
(which it seems they have not), and the second one would be for
someone that has gone through this problem to post the solution here
or by private email.
Note that I may now have found a solution but will not be testing this
until tomorrow (1 AM now, bed time).

If I am correct I will be happy to share the solution with anyone that
needs it.

And for clarification , V8 also has the same problem (just tried it).

So, it's not PowerCOBOL related. 8-) 8-)
No. Its is PowerCOBOL related, as they do not, apparently, implement
the IClassFactory2 methoed of creating objects. Although it is not
mandatory, it is highly advisable, as not implementing it just limits
the number of third party controls that can be used with the product.



Regards

Frederico Fonseca


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Jeff Campbell
n8wxs@xxxxxxxx

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
.

Relevant Pages

  • Re: Control problem
    ... > I've compiled a control with 'Requires license key' option checked. ... Does your control use any constituent controls that require a license key ... Can't Create VB ActiveX Control with Embedded Licensed Ctrl ...
    (microsoft.public.vb.controls)
  • Re: Fujitsu support - need help - Netcobol for windows and licensed controls.
    ... Power COBOL V7, 3rd party OCX control, properly licensed. ... as it is basically distibuiting the development license. ... is down to the third party supplier to provide a run time license file (or ... It is up to the container to see if it ...
    (comp.lang.cobol)
  • [very long report] my theory and practical tests
    ... I then went on and at 18 I got my car license, ... easy if you are familiar with clutch and gears on a bike, ... Shoulder checks and low speed control: ... *rear brake only* after the midpoint because the ...
    (uk.rec.motorcycles)
  • Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
    ... The fact this is a good license for making zillions of dollars, ... some jurisdictions allow the control of _other_ information via our ... hardware that is associated with our software, ... jurisdiction allows the controlling of various aspects of movie theaters ...
    (Linux-Kernel)
  • OFF LIST:Re: GPL encumbrance problems
    ... It's like seeing some whiz-bang control you might like to use if you're ... There>IS< a 'Gift Debt' that comes from using opensource, which according to my perspectives is the imperative to 'pass it forward'. ... That's a no brainer, I don't need to absorb all the money there is in circulation, unlike someone I could name. ... He believes that one should only sell copies, not license ...
    (Fedora)
Loading