如何在我的 Delphi 应用程序中设置 14 天试用限制
我希望为我的软件添加 14 天的试用限制。 该程序是用 Delphi 7 编写的。
任何帮助将不胜感激。
I'm looking to add a 14-Day trial limit to my software. The program has been written in Delphi 7.
Any help would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
您可以尝试 Turbopower OnGuard。 现在这是开源的。
http://sourceforge.net/projects/tponguard/
You could try Turbopower OnGuard. This is now opensource.
http://sourceforge.net/projects/tponguard/
您可以使用多种技巧，但没有一个是 100% 保存失败的。
但我认为最好的方法是提供功能有限的试用版。 例如：不打印、不保存项目或只能保存小项目。
这样您就可以避免麻烦，并且潜在的客户可以花时间评估您的项目。
编辑：如果你建立一个机制来检查是否倒转。 请务必留出余量，否则如果您返回其他时区，程序将被锁定。 或者在冬天把时钟拨回。 我认为 25 小时的时间足以涵盖所有内容。 （为了节省时间，您可以建立一个限制，否则用户可以每天回滚时间。）。
但保持付费客户的最佳方法是提供良好的支持。 如果服务不好我就会停止产品。
There are several tricks you can use, but none of them 100% fail save.
But I think the best way, is to give trial versions with limited functionality. For example: No printing, no save of project, or only small projects can be saved.
That way you avoid the hassle and possible clients can take the time to evaluate your project.
EDIT: If you build a mechanism to check against roling back the clock. Be sure to build in a margin, else the program will be locked if you travel back to an other timezone. Or put the clock back in wintertime. I think a margin of 25 hour will cover everything. (And to be at the save side, you can build in a limit else, the user can roll back the time each day.).
But the best way to keep paying customers, is giving good support. I discontinue products if the service is bad.
对于有时间限制的应用程序，您需要防止的事情之一是用户回滚他们的日历，以便应用程序仍然可以运行。 解决这个问题的一种方法是在应用程序启动时在隐藏的注册表位置（或任何地方）存储时间戳。 如果当前日期/时间早于应用程序记录的最后一个时间戳，则意味着用户已回滚日历，您应该禁用该应用程序。
然而，时间限制对于程序员和用户来说都是一个真正的痛苦。 这也不是一个很好的营销理念：为什么要费力去分发有有效期的促销材料（这就是您的试用版）？ 这就像一家公司邮寄纸质广告，两周后就会解体。
如果您的试用版在功能上存在缺陷，那么即使几个月或几年后您仍然可以从中获得销售。
One of the things you need to guard against with a time-limited application is users' rolling their calendar back so the application still works. One way around this is to store in your hidden registry place (or wherever) a timestamp whenever the application is started up. If the current date/time is ever earlier than the last timestamp recorded by your app, that means the user has rolled the calendar back and you should disable the application.
Time-limitation is a real pain, though, both for the programmer and the user. It's also not a great marketing idea: why go to the trouble of distributing promotional material (which is what your trial version is) that has an expiration date? It would be like a company mailing out advertisements on paper designed to disintegrate after two weeks.
If your trial version is functionally crippled instead, you might still get sales out of it even months or years later.
您可以在此处找到类似的问题。
总的来说，我发现时间限制比功能限制更有用。 正如我在评论中所解释的 游戏猫帖子
You can find the similar question here.
On general note i find time restriction much more useful than functionality restriction. As i explained in the comment to Gamecat post
执行任何这些检查时需要注意的事项。 从您以任一方向输入的日期算起，该日期绝不会超过 14 天。 解决大多数此类限制的常见方法是提前几年设置日期，安装并运行软件，然后将日期设置回当前时间。 如果你被硬编码为从原始开始日期起 14 天就死掉，那么用户有几年的时间来尝试你的软件。 检查另一个方向也给用户最多 28 天的时间。
something to be aware of when performing any of these checks. That the date is never GREATER than 14 days from the date you entered in either direction. A common method around most of these types of limits is to set the date a few years in advance, install and run your software, then set the date back to the current time. If you are hard coded to die 14 days from the original start date, then the user has a few years to try your software. Checking the other direction also gives the user at most 28 days.
我用过犰狳、Asprotect 和 Winlicense。 Armadillo 和 Asprotect 都存在严重的问题，例如被某些 AV 视为病毒/木马、不兼容问题等。
我还没有使用 Winlicense 来发表太多意见，但支持非常好。
显然，两者都是比您所要求的更完整的解决方案 - 它们包括保护、许可、密钥等。
正如其他人提到的，有时限制功能或添加水印是最好的选择。 我为我的一个程序添加了水印(STGThumb)，销售额增长了约 400%...
I have used Armadillo, Asprotect and Winlicense. Both Armadillo and Asprotect have had serious problems, such as being considered viruses/trojans by some AVs, incompatibility problems, etc.
I haven't used Winlicense enough to have much of an opinion, but support is pretty great.
Obviously both are more complete solutions than what you are asking for - they include protection, licensing, keys, etc.
As mentioned by others, sometimes limiting a feature or adding a watermark is the best option. I've added a watermark to one of my programs (STGThumb) and sales went up about 400%...
我建议制作一个带有时间戳的试用序列号，并强制用户在安装软件时将其输入软件中。 您甚至可以在设置完成后通过调用服务器端页面来自动化它。
试用序列号中的时间戳允许您在需要时延长试用期。
此外，您可以倒数以避免用户在安装时更改年份：
例如，如果您在 2008 年 11 月 15 日（服务器时间）生成了 14 天试用版，则可以检查定位日期必须大于 1.11.2008 或小于 24.11。使用或输入序列号时始终为 2008。
I would recommend making a trial serial number with timestamp and force user to enter it into software when its installed. You can even automate it by calling server side page after setup is done.
Timestamp in trial serial key allows you to extend their trial if needed.
In addition you can count backwards to avoid user from changing year when installing:
e.g. if you have 14 days trial generated at 15.11.2008 (server time), you can check that locate date must be greater than 1.11.2008 or less than 24.11.2008 always when serial is used or entered.
您可以使用 SoftwareShield 等专业工具。
我在我们的应用程序中使用它，它提供了多种许可证模型，包括限时演示。
You can use a professional tool as SoftwareShield.
I use it in our apps and it provides several licence's models, including timelimited demo.
我创建了自己的密钥生成器（用于创建密钥的单独程序）。 键值存储在与我的程序同名的二进制文件中，只是扩展名不同。 示例：myprogram.key
我存储：
姓名
电子邮件
RegType（REG、试用）
注册日期
FirstRun (0 OR 1)
程序查找文件。 如果不存在，它会向用户抛出一条消息并关闭。 密钥文件生成器将值写入加密字符串中，然后使用内置流例程写入这些值。
我创建了一个与该程序一起分发的试用密钥。 如果有人注册，我会为他们创建一个官方 REG 密钥。
不管怎样，如果他们正在运行我的程序，它首先会查找密钥文件。 如果找到，它会检查注册类型，如果是注册版本，则加载程序，并显示注册信息。 我还存储一个注册日期，我将其与程序运行的日期进行比较 - 如果注册日期大于或等于今天的日期，则会提示用户重新注册。
如果发现密钥文件存储了 TRIAL 的 RegType，那么他们第一次运行它的日期将存储在密钥文件中，并且首次运行标志设置为 1。然后他们可以使用它 14 天。 每次运行程序时，都会将存储的日期与运行日期进行比较。
写起来非常简单的过程。 它是万无一失的吗？ 不，什么都没有！ 我的应用程序取得了巨大成功。 它并不广为人知，因此没有黑客想要破解它。
I created my own key generater (separate program for creating keys). The key values are stored in a binary file with the same name as my program, just a different ext. Example: myprogram.key
I store:
Name
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
The program looks for the file. If it is not there, it throws a message to the user and closes. The key file generator writes the values in encrypted strings which are then written using the built in stream routines.
I create a TRIAL Key that i distribute with the program. If someone registers, i then create them an official REG key.
Anway, if they are running my program, it first looks for the key file. if found, it checks the reg type, if its a regitered version, then the program loads, and the registration info is displayed. I also store a regdate, which i compare with the day the program runs and - if the regdate is greater than or equal to todays date, the user get sprompted to re-register.
If it finds that the key file stores a RegType of TRIAL, then the date they first ran it is stored in the keyfile, and the flag first run is set to 1. They can then use it for 14 days. Each time they run the program, the date stored is compared with the running date.
Very simple process to write. Is it fool proof? NO, nothing is! I have had great success with my app. Its not wide known, so there are no hackers lookijng to hack it.
最好是从您的服务器获取注册信息。
最大的缺点： 1. 服务器必须始终在线！ 2. 用户必须连接到互联网（当它使用您的应用程序时）。
要开始使用，您可以使用 Delphi 许可证管理库来帮助您加密许可证信息并生成基于字符串的密钥，您可以在注册时将其发送给客户。 那里的图书馆很少。
无论如何，您发送到服务器的任何内容都需要基于 该计算机的硬件指纹。 否则您的许可证密钥将在某些软件网站上泄露，每个人都可以使用该密钥。 但如果密钥是基于硬件的，那么如果泄露到互联网上就毫无用处。
并且不要做得太过分！ 不存在牢不可破的软件保护。 如果微软做不到，你也不会做。 专注于为您的应用程序添加良好的功能，而不是创建防弹保护系统（这是不可能的）。
The best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
To get you started you can use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration. There are quite few libraries out there.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
And don't over do it! There is no such thing as unbreakable software protection. If Microsoft could not do it, you will not do it. Concentrate on adding nice features to your app instead of creating a bullet proof protection system (which is not possible).