trial version in vfp

[eyeshield21]

what is the easiest way to create a demo which will expire after such and
such days?
and also to prevent the user to change system date

 

[Olaf Doschke]

There is no way to disable someone setting their system date. But you can of course check the currtent time from internet instead of system time.

See thread184-1724601

loXmlHttp = Createobject("MSXML2.XMLHTTP")
loXmlHttp.Open("HEAD", "[URL unfurl="true"]https://www.google.com/?q=",.F.)[/URL]
loXmlHttp.Send()
Do While loXmlHttp.readyState <>4
   DoEvents
Enddo
? loXmlHttp.getResponseHeader("Date")

This is working with any site, not only with google, so you might also put in your server, eg the product homepage.

You can also measure usage time and store it encrypted in a file or registry key. Anyway, why not make use of third party tools?

Bye, Olaf.

 

[eyeshield21]

can you give me best sample of third party tools pls..

 

[Olaf Doschke]

Sorry, I never used one, but heard good things about Wibu. The thing is, they have years of experience in licensing and signing and en/decrypting files. They also should do better than checking system time.

Bye, Olaf.

 

[Mike Lewis]

If you are finding it difficult to work out how to check the Internet time, then at least start with checking the time of the user's local system, which you can do with the DATETIME() function. When the user installs the demo, store the time in the registry (or some other out-of-the way place that the user is unlikely to come across). Then, each time you start the app, compare the time with the one that is stored. If the time has expired, decline to run the app.

It's true that a knowledgeable user can subvert the system by changing the system time, but in practice would many people actually do that? You have decide if it is worth taking the risk

A better solution might be to not use a time-limited demo at all, but to limit the app is some functional way. For example, if it is an accounting system, you might limit the number of customer accounts; in a payroll, you could limit the number of employees; and so on.

That has the advantage that the user can take as long as they need to evaluate the system, without worrying about the demo expiring. It is also harder to subvert. It's true that a very small business might be able to use the demo for real (if they only have very few customers or employees or whatever), but even that could be an advantage. They start using the demo version, but as they grow, they find themselves locked into it, and are more or less obliged to upgrade to the full version after they reach the critical size.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JackTheC]

Not perfect, but you can count the number of times the application is started en keep a counter in a secure, hidden or unknown place in the registry: You can use this application 20 times. 12 times left....

 

[Olaf Doschke]

Actually I also find the data limitation the best choice. Time limits can even be circumvented in case internet time is measures, if you reinstall on a virtual machine, when the version expires set up the next virtual machine etc.
The data limitation can't be circumvented, really. It would be tedious to replace databases with partial customers, products, employees or whatever is the core topic of a databased Software.

The reason I never needed such things is I always only had individual customers and they pay the working hours, so it's not a business calculation you need to sell X licenses or have X users. The main problem with license restrictions are false positives, eg a valid customer changes hardware and you make a key depending on hardware IDs. You'd need a way to transfer a license, invalidate the original installation and activate a new one. You need to cope with many detail problems not the topic of your development, another reason to let this be done by third party and in case your revenue is very valuable with each single license, like costly creative software suites of Adobe are, then you better even protect with hardware keys/dongles/sticks.

The business of individual software development I am in does not need such protection, the customer himself has a big interest not letting competition get this software.

Bye, Olaf.

 

[Tore Bleken]

To get the absolutely correct date and time from Internet, I just created this small function. Normally you pass no parameters, and you will get the local date and time as a DateTime value.

Note that I haven't had the chance to test it too much, please report any problems with it. You will of course need an internet connection to call it without errors.

[pre]
*getrealtime.prg
Lparameters tnTimesone
Local lcCorrect As String, ;
lcDateString As String, ;
lcURL As String, ;
lnCorrection As Number, ;
lnStrict As Number, ;
loWinHttp As [WinHttp.WinHttpRequest.5.1], ;
ltDateTime As Datetime
m.lcURL = [

http://www.timeapi.org/utc/now

]
m.lnStrict = Set([Strictdate])
Set StrictDate To 1
m.loWinHttp = Createobject([WinHttp.WinHttpRequest.5.1])
m.loWinHttp.Open([GET], m.lcURL, .F.)
m.loWinHttp.Send()
m.lcDateString = m.loWinHttp.ResponseText
If Empty(m.lcDateString) Or Isnull(m.lcDateString)
m.ltDateTime = {-:}
Else
m.ltDateTime = Ctot(Left(m.lcDateString, 19))
If pcount()=0
m.lcCorrect = Substr(m.lcDateString, 20)
If !Empty(m.lcCorrect)
m.lnCorrection = 3600 * Val(Substr(m.lcCorrect, 2, 2)) + 60 * Val(Substr(m.lcCorrect, 5, 2))
Do Case
Case Left(m.lcCorrect, 1) = [+]
m.ltDateTime = m.ltDateTime + m.lnCorrection
Case Left(m.lcCorrect, 1) = [-]
m.ltDateTime = m.ltDateTime - m.lnCorrection
Otherwise
m.ltDateTime = {-:}
Endcase
Endif
Else
m.ltDateTime = m.ltDateTime + 3600 * m.tnTimesone
Endif
Endif
Set StrictDate To m.lnStrict
Return m.ltDateTime
[/pre]

 

[Olaf Doschke]

Hm,

That time API is resulting about 10:15+01:00 right now and

http://www.timeanddate.com/worldclock/timezone/utc

is giving 09:15 UTC.
It seems the bias part rather has to be subtracted to get real UTC.

To get the 30 day trial expiration you won't need to convert to local time at all, but it's obviously a nice addition to be able to see whether the system clock is not in sync with real local time. Well, at least if the system time zone os set correctly.

Bye, Olaf.

 

[Tore Bleken]

As far as I can see, is the time API able to see where you call from, so to say, and give you the correct date and time accordingly. If you use my function without any parameter, does it report the correct time? It does from where I live, Norway.

 

[Olaf Doschke]

Tore, it does for germany, too, but rather by coincidence. MET is UTC+2 now, about 11 am.

Since the api returns 10 and bias +01:00 that makes it a total of UTC+2 by coincidence.

Someone from US may verify, but I think you need to apply -bias to get UTC and then add the time zone bias of the OS to get local time.
Several other sources of UTC report current hour of 9:00, so there is no doubt 10am is not UTC.

Aside of that the time format given is an XML timestamp and that uses ISO 8601, where the bias is defined as time zone difference already applied in the time portion and not to be applied to it. So the timestamps are from a server in a timezone, which now has +1 difference to UTC. As said you need to apply the negative bias to get UTC and then apply the current time zone offset from UTC (which depends on DST, UTC never switches from summer to winter time).

Bye, Olaf.

 

[Tore Bleken]

I will test it again when we switch to "winter time". Still I think this function is very usable.

 

[Olaf Doschke]

You don't need to wait for winter time to see.

Even with he assumption the server determines the location of the caller, which is partialy doable, this is wrong right now in germany and every ip based or header based determination of a callers geolocation is never perfect, it can be overrden by going through a proxy. To verify I used an anonymizer service to emulate a call from US and the returned value is still with bias +01:00.

Also simply look at it from the definition of the URL:

http://www.timeapi.org/utc/now.

This is saying ít's UTC and it only is, if you subtract the bias, not add it. The bias is not predicting your time zone, if t should do that, it would need to be +2 here in germany and even though middle european time zone is +1 in winter, it surely needs to be different time zone offsets or US or other time zones, when using anonymizer proxies, but it's still +01:00 then.

Bye, Olaf.

 

[Tore Bleken]

Anyway, I added the option to pass an offset as a parameter. And I think it's possible to get the accurate offset from the WMI, maybe I will add that option one of these days. But for my needs, the function is adequate.

 

[Olaf Doschke]

Well, if you need to pass in a wrong offset to get the right time, it's quite inadequate.

You get the local bis with GetTimeZoneInformation also mentioned in thread184-1724601 by Mike Lewis.

And referencing the MSDN documentation better use GetDynamicTimeZoneInformation. To get your local current (dynamic) bias use this:

? GetDynamicUTCBias()

Procedure GetDynamicUTCBias() 
* UTC = local time + bias => local time = UTC - bias.
* bias is in minutes.

#Define TIME_ZONE_ID_UNKNOWN  0
#Define TIME_ZONE_ID_STANDARD 1
#Define TIME_ZONE_ID_DAYLIGHT 2
#Define TIME_ZONE_ID_INVALID  0xFFFFFFFF 

DECLARE INTEGER GetDynamicTimeZoneInformation IN kernel32;
    STRING @ lpTimeZoneInformation

Local lpTimeZoneInformation, lnTZID, lnTZBias, lnStandardBias, lnDaylightBias, lnDynamicBias

lpTimeZoneInformation = Space(429)

lnTZID = GetDynamicTimeZoneInformation(@lpTimeZoneInformation)
lnTZBias = CToBin(Substr(lpTimeZoneInformation,1,4),"SR")
lnStandardBias = CToBin(Substr(lpTimeZoneInformation,84,4),"SR")
lnDaylightBias = CToBin(Substr(lpTimeZoneInformation,169,4),"SR")

Do Case 
   Case lnTZID = TIME_ZONE_ID_INVALID  
      Error "Your system timezone setting is invalid"
   Case lnTZID = TIME_ZONE_ID_UNKNOWN OR lnTZID = TIME_ZONE_ID_STANDARD
      * A Warning on TIME_ZONE_ID_UNKNOWN would be appropriate
      * but let's keep it to a minimum handling of special cases
      * and assume standard time in this case
      lnDynamicBias = lnTZBias+lnStandardBias
   Case lnTZID = TIME_ZONE_ID_DAYLIGHT
      lnDynamicBias = lnTZBias+lnDaylightBias
EndCase

Return lnDynamicBias

As said this gives 2 hours difference to UTC currently for the middleeuropean summer time zone.

Bye, Olaf.

 

[Tore Bleken]

I have done some research also, and see the same as you. When I wrote the program, I saw that the time I saw on

http://www.timeapi.org/utc/now,

was correct if I added the offset which came last. This is why I assumed that this offset was the difference between UTC and my local time, which was a wrong assumption. This should be easy to fix, but since I don't really need it, I won't give it any high priority.

 

[ggreen61]

Why do a limited demo based on calendar time? Why not limit the number of records stored into a specific table. For instance, limit the number of journal entries that are entered to be 100 as a demo. You would store the registration of your program -- if unregistered, limit to 100 journal entries. If registered, then no limit...

 

[Mike Lewis]

Why do a limited demo based on calendar time? Why not limit the number of records stored into a specific table.

Yes, that's exactly what I (and others) suggested at the outset. The trouble is that the original questioner hasn't been back or given us any feedback on our suggestions. So we don't know if this discussion on internet time is relevant to him, or is just a distraction (I'm not saying we shouldn't be having the discussion. On the contrary. It's very interesting, and might well be relevant to other people. But it would help if Mr Eyeshield would let us know what he thinks of our suggestions, so that we can focus on the points that will help him.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

You have been given some good advice above.
I also think that the record count limitation would be a better approach.

Regardless, in addition to those suggestions above, here is another one.
If you should happen to have a SQL Server running on your network, you could also get the current DateTime from it, since it is less likely (but not impossible) that someone would change the DateTime of a centralized Server than they might on a Workstation.

See:

http://blog.sqlauthority.com/2007/0...-sql-server-current_timestamp-getdate-fn-now/

Good Luck,
JRB-Bldr

 

[GriffMG]

How hard would it be to spoof a time server like

http://www.timeapi.org/utc/now

perhaps a line in the hosts file and a little imagination...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​