I'll start by quoting a message from dilettante that he posted a time ago in another thread but this question is for everyone.
Originally Posted by dilettante
DLLs get a little trickier.
Do you have an idea about how to do that?
Originally Posted by dilettante
You can either put your public classes into an OCX instead of making separate DLLs (you don't need a separate DLL) and just rely on the controls licensing.
Without adding an OCX.
Originally Posted by dilettante
Or if you insist on DLL licensing you need another mechanism... don't think VB6 (ActiveX really) offers one, you'd have to roll your own.
And without the client developer having to hardcode the license information in the source code of the program, because if she/he shares the source code with another developer, the license should not work and the other developer should not be able to grab the license information and use it in another program either.
The idea is:
I'll offer at my site a DLL that has to work in this way:
When someone downloads it and install it either by the install program or by downloading just the DLL file and registering it, it should work "in demo mode".
When someone purchases a license, she/he must be able to enter the license somehow.
I'm thinking of two ways: by executing an exe with a little GUI to enter the license, or by starting a new project in the IDE and calling a DLL method like for instance EnterLicense, sending the license information as parameters. The DLL will then store the license information in that computer.
Then to close that project, not saving it.
Then the DLL should start working "licensed" in the IDE.
So far, no problem (anyway any better way to enter the license is welcome).
When the developer compiles the program, the DLL should work in the client program licensed.
And here starts the big issue. I don't envisage any way to add information to the exe file at compile time that could be available when the program runs compiled to tell the DLL that it is licensed.
Option 2: Make a different DLL for the licenced clients.
(instead of using always the same, that is an advantage to have only one file when making updates/upgrades)
I would like to make both DLLs binary compatibles, to avoid problems to the developers when switching from demo to licensed.
The developer would have to enter the license the same as with the other option above.
If another developer gets access of a licensed version of the DLL (from some compiled program that she/he found on the internet maybe), it should not work in the IDE without license.
So far feasible.
The problem comes that this second "unlicensed" developer could develop in the IDE with the demo version of the DLL and after compiling the program she/he could put the DLL version intended for licensed and it will work as it was licensed, because both DLL are binary compatibles and therefore can be interchanged.
I don't find a workaround for that either.
Option 3: Different, not compatible DLL for demo and licensed.
That would cause troubles for the developers when need to switch from the demo version that downloaded from the site and already applied to the program to this new non-compatible DLL. When loading the project the IDE will throw errors.
The idea of this component is making the life easier to the developers, not to cause problems. The licensing mechanism must be easy, simple (for them), secure and it must work.
Ideas?
I think that this problem of licensing DLLs must be addressed in the past by many developers/companies. Eevn so, I could not find much information on the web.
I don't envisage any way to add information to the exe file at compile time that could be available when the program runs compiled to tell the DLL that it is licensed.
Maybe by adding some information to the end of the exe file.
or by generating a license file that tells the dll it is registered (for distribute only) then the developer should add the license file to the installation package.
Maybe by adding some information to the end of the exe file.
or by generating a license file that tells the dll it is registered (for distribute only) then the developer should add the license file to the installation package.
To add more dependency files is to add problems. This should work without "problems" (of forgetting to add a file and having "why isn't it working?" support calls).
The OCX files can add information to the exe because they save properties into the exe at compile time and after they are read when the program runs.
At desing time these properties are saved in the *.frm, *.ctl files of the client program.
But the DLL files AFAIK do not have a mechanism to save "properties" into the exe.
And whatever mechanism, to add information at the end of the exe file or in some other place, it must be done automatically when the client program compiles. The client developer should not be required to run a patcher program to add the license.
if the developer will digitally sign the exe then you cant do any thing after signing, you should add the information before signing.
and after signing the exe you have to calculate the signature size to read the license information.
the easiest way is by making an activator installed with the dll.
if the developer will digitally sign the exe then you cant do any thing after signing, you should add the information before signing.
and after signing the exe you have to calculate the signature size to read the license information.
the easiest way is by making an activator installed with the dll.
I have no idea whether they will sign the exe or not.
Whatever I do it need to be at compile time (and that is before).
some developers use resource editor after compiling and i saw that at well known companies like (intuit quickbooks).
In this case, this can cause an error while calculating the license information.
some developers use resource editor after compiling and i saw that at well known companies like (intuit quickbooks).
In this case, this can cause an error while calculating the license information.
I don't see why it would cause an error since I'm not planning to use any resource.
And even if that was the case, they would have to be intructed not to emove that data because that would remove the license information of the component.
Why not always calling a EnterLicense method of the Dll?
So an app developer would always call that method in Sub Main.
Only drawback would be maybe that the license key is exposed in a Const.
Why not always calling a EnterLicense method of the Dll?
So an app developer would always call that method in Sub Main.
Only drawback would be maybe that the license key is exposed in a Const.
Yes, the license would be exposed.
The idea is that the developer keep the license information privately (hopefully) and doesn't share it with others.
From the OP:
Originally Posted by Eduardo-
And without the client developer having to hardcode the license information in the source code of the program, because if she/he shares the source code with another developer, the license should not work and the other developer should not be able to grab the license information and use it in another program either.
I'm already almost convinced that I'll have to switch to an OCX.
Better, I would be able to add some controls.
The only drawback is that the client program will have to load a form (which will have to have a control on it) to supply the license information before using the component.
I have already an idea about what other function I can add to that control.
It seems that MS didn't think that the DLLs could have licenses by themselves (without being part of an exe program). They didn't produce any mechanism to handle licenses for DLLs.
Hello Trick, and that can be done from the DLL at compile time? (and without having to ship other files along with the DLL)
You just asked for storing the data to an EXE itself. Do you need restrict the EXE functionality? I made the example of licensing, please look at this method (description).
What is the demo mode?
I suggested to encrypt the part of the code and stay unencrypted the other part. When the user purchase the license the DLL tries to decrypt the code which opens the full functionality. If the license is incorrect or the license is not found you can return an error code from the DLL. You can encrypt each dll with the different keys so the two arbitrary DLLs have different licenses without recompilation. Is that scenario is what you wish?
Look, I don't see that that program can be used with DLLs. Still, if it could do something, what it can do? I could do the same without another program if something could be possible.
What is the demo mode?
I suggested to encrypt the part of the code and stay unencrypted the other part. When the user purchase the license the DLL tries to decrypt the code which opens the full functionality. If the license is incorrect or the license is not found you can return an error code from the DLL. You can encrypt each dll with the different keys so the two arbitrary DLLs have different licenses without recompilation. Is that scenario is what you wish?
The scenario is that it is a direct replacement of the VB6's printer object but that has print preview capability. Basically that's what it is.
The demo will be fully functional but will print a logo of my "company" at the bottom of each page and a small legend saying "demo version".
There is not encryption anywhere now.
But as I said in another post, I'm already almost convinced that I'll have to switch to an OCX.
To license DLLs seems to be too cumbersome.
And I'm already thinking in perhaps adding some controls.
Thanks guys. I think I'll go with the OCX option.
I'll be away some days (still not sure) so perhaps I won't be able to respond quickly at the forum if there is any further answer.
Thanks.
I'm not sure I see a big problem here either. Just spit-balling, if it were me, and I wanted a DEMO version and a FULL version, I'd just stick some kind of registration information in the registry.
First, I'd have to make a couple of decisions. Do I want the license to be per-machine or per-user or per-site. I suppose per-site does get a bit tricky. And, per-user, I'd probably just require some kind of on-line check.
However, per-machine seems pretty easy to me. Just find something unique about the machine, maybe it's name, maybe it's NIC card MAC address, IDK there are several things ... and then, intermingle this with a supplied license code, and stuff that in the registry. The fact that it's intermingled with that unique machine means it wouldn't matter if the user found the registry entry.
Now, you may ask what I mean by intermingling. There are several schemes, and I'll let others answer that if they so choose. But, to me, that's not a difficult problem.
Therefore, why all the discussion about altering DLLs and/or EXEs. That just seems like silliness to me.
And, if you really want to be secure, have the user report that unique machine ID (such as MAC address) into your registration web-page, such that the code they get (for intermingling) already has that MAC address somewhat built into it. That way, you could possibly allow a user to re-register (maybe up to three times) their software. I'm not exactly sure how it works, but Microsoft Office seems to use some scheme similar to this.
And, regarding the statement that "anything is hackable", well, of course it is. However, it comes down to how hard someone is willing to work to hack it, and also how often you issue updates. If you issue updates often, each update will need to be hacked, which is some prevention in itself.
Also, just to say it, if it were me, and we're talking about a DLL, I'd just build in some "registration call" to the primary class of the DLL. No biggie to my eyes.
Just My Thoughts,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I'm not sure I see a big problem here either. Just spit-balling, if it were me, and I wanted a DEMO version and a FULL version, I'd just stick some kind of registration information in the registry.
First, I'd have to make a couple of decisions. Do I want the license to be per-machine or per-user or per-site. I suppose per-site does get a bit tricky. And, per-user, I'd probably just require some kind of on-line check.
However, per-machine seems pretty easy to me. Just find something unique about the machine, maybe it's name, maybe it's NIC card MAC address, IDK there are several things ... and then, intermingle this with a supplied license code, and stuff that in the registry. The fact that it's intermingled with that unique machine means it wouldn't matter if the user found the registry entry.
Now, you may ask what I mean by intermingling. There are several schemes, and I'll let others answer that if they so choose. But, to me, that's not a difficult problem.
Therefore, why all the discussion about altering DLLs and/or EXEs. That just seems like silliness to me.
And, if you really want to be secure, have the user report that unique machine ID (such as MAC address) into your registration web-page, such that the code they get (for intermingling) already has that MAC address somewhat built into it. That way, you could possibly allow a user to re-register (maybe up to three times) their software. I'm not exactly sure how it works, but Microsoft Office seems to use some scheme similar to this.
And, regarding the statement that "anything is hackable", well, of course it is. However, it comes down to how hard someone is willing to work to hack it, and also how often you issue updates. If you issue updates often, each update will need to be hacked, which is some prevention in itself.
Also, just to say it, if it were me, and we're talking about a DLL, I'd just build in some "registration call" to the primary class of the DLL. No biggie to my eyes.
How to Append a file to an EXE or Dll or any binary file.
Code:
http://www.planet-source-code.com/vb/scripts/ShowCodeAsText.asp?txtCodeId=9330&lngWId=1
'**************************************
' Name: How to Append a file to an EXE
' Description:This is just to show you h
' ow to append a file to an executable. Co
' uld be handy if you wanna save maybe a t
' ag to your exe file. Have not test it wi
' th very large files but small file works
' perfectly.
' By: Adriaan Putter (from psc cd)
'
'
' Inputs:None
'
' Returns:None
'
'Assumes:None
'
'Side Effects:There could be problems wi
' th large files, I dont know.
'**************************************
Private Sub AppendToExe(exefile$,filetoappend$)
Open filetoappend$ For Binary As #1
filedata$ = String(LOF(1), " ")
Get #1, , filedata$
Close #1
Open exefile$ For Binary As #1
f = LOF(1)
Seek #1, f + 1
Put #1, , "WAP" 'any identifer
Put #1, , filedata$
Close #1
End Sub
Private Sub ExtractFromExe(exefile$,filetoextr$)
Open exefile$ For Binary As #1
filedata$ = String(LOF(1), " ")
Get #1, , filedata$
Close #1
pos = InStr(1, filedata$, "WAP")
f$ = Mid$(filedata$, pos + 3)
Open filetoextr$ For Binary As #2
Put #2, , f$
Close #2
End Sub
the attachment is for write and read string from the end of the binary file.
How to Append a file to an EXE or Dll or any binary file.
Code:
http://www.planet-source-code.com/vb/scripts/ShowCodeAsText.asp?txtCodeId=9330&lngWId=1
'**************************************
' Name: How to Append a file to an EXE
' Description:This is just to show you h
' ow to append a file to an executable. Co
' uld be handy if you wanna save maybe a t
' ag to your exe file. Have not test it wi
' th very large files but small file works
' perfectly.
' By: Adriaan Putter (from psc cd)
'
'
' Inputs:None
'
' Returns:None
'
'Assumes:None
'
'Side Effects:There could be problems wi
' th large files, I dont know.
'**************************************
Private Sub AppendToExe(exefile$,filetoappend$)
Open filetoappend$ For Binary As #1
filedata$ = String(LOF(1), " ")
Get #1, , filedata$
Close #1
Open exefile$ For Binary As #1
f = LOF(1)
Seek #1, f + 1
Put #1, , "WAP" 'any identifer
Put #1, , filedata$
Close #1
End Sub
Private Sub ExtractFromExe(exefile$,filetoextr$)
Open exefile$ For Binary As #1
filedata$ = String(LOF(1), " ")
Get #1, , filedata$
Close #1
pos = InStr(1, filedata$, "WAP")
f$ = Mid$(filedata$, pos + 3)
Open filetoextr$ For Binary As #2
Put #2, , f$
Close #2
End Sub
the attachment is for write and read string from the end of the binary file.
I know how to open a file (exe or whatever) and change binary data, but I would need to write to the exe at compile time, or otherwise immediately after the compilation finishes, that't the issue and not writing to an exe file (that is a file like any other file)
That's the point.
While I'm writing an idea came... if the DLL can detect that the client project is being compiled, it could set a timer that checks if the exe file (it also would have to find the path of the exe file, and that could be another issue) is still locked. When it is unlocked it means that the compilation ended. The timer should keep working after the IDE returned to design time (I suppose) since the DLL is compiled.
Other issue is to find a proper place to write the information inside the exe.
It seems too complex, and I'm not sure if that would work. But this could be a path to explore if I want to insist in the DLL choice (which is now almost ruled out by the OCX option).
my advice to you is (never touch the executable file).
because the client may have an issue in his software and may thinks it is because the data that you had added to it.
and as i mentioned before, if the client will digitally sign the software then you have to calculate the signature size to get your license information correctly and that not easy.
and you cant add any data to the exe after signing because that will damage the signature and make it invalid.
my advice to you is (never touch the executable file).
because the client may have an issue in his software and may thinks it is because the data that you had added to it.
and as i mentioned before, if the client will digitally sign the software then you have to calculate the signature size to get your license information correctly and that not easy.
and you cant add any data to the exe after signing because that will damage the signature and make it invalid.
Yes, of course. You are the one that suggested to write to the exe.
I asked to add the data to the exe at compile time (not after), as VB6 normally does with OCX components.
I have no idea if that can be possible with ActiveX DLL.
What I learnt is that almost everything is possible (in some way), but some things are too difficult or has some drawbacks or are too cumbersome to do. So, I conclude that in principle it seems "impossible" to do.
For the ones that still didn't understand what I was tryint to do:
When you use an ActiveX control, for example some special label that comes in an OCX. You add the label to a form, then go to a property, for example Caption. You set the caption to something, for example "Testing to change the caption".
Then go to compile the exe. Once compiled that caption that you set at design time is now saved into the exe.
I wanted to do the same but not with an OCX and a control but with a DLL and a Class module.
But it seems impossible to save anything from a DLL.
Good bye, and thank you all.
PS: I had chosen a DLL instead of an OCX because since my component doesn't need controls to work, I wanted to avoid in the client project having to check "Remove information about unused ActiveX Controls" in the project properties. (I want to avoid problems as much as possible)
But now one control will be necessary at least for the license, then back to OCX.
And the good thing is that now I could add some other auxiliary controls.
Last edited by Eduardo-; Jun 5th, 2019 at 12:46 AM.
When you use an ActiveX control, for example some special label that comes in an OCX. You add the label to a form, then go to a property, for example Caption. You set the caption to something, for example "Testing to change the caption".
Then go to compile the exe. Once compiled that caption that you set at design time is now saved into the exe.
But I already decided to go the OCX route. I'm seeing some other benefits (like that many people like to have a control on the form, something that they see and can "touch").
Thank you anyway Trick.
Last edited by Eduardo-; Jun 5th, 2019 at 05:29 AM.
Originally Posted by dilettante
Reply With Quote
