30 day evaluation
Blitz3D Forums/Blitz3D Beginners Area/30 day evaluation
| ||
| Dear all, I would like to create a 30 day working version of my program for evaluation purposes to send out on cd. I've no idea as to how to go about doing this, so is there any code in blitz3d that will fulfill this function, or do I need to purchase something? I'm happy to pay. Shawnus |
| ||
| There have been topics on this kinda limitation elsewhere... I think you may need to do something with the registry to prevent users fromjust re-installing. Il try an find some links... ... can't find the discussion threads, think theyve been archived somewhere now :( Have a look here, though, this may help some: http://www.blitzbasic.com/codearcs/codearcs.php?code=1136 |
| ||
| i use a third party product called 1Way that works pretty darn well and its inexpensive to boot. http://atma-software.com/1way/ look around though, there are several others out there. i felt this one was the best for the buck. i could provide a userlib .decls and some sample code as well if you decide to go this route. it does require a DLL to be installed with your app. i use a product called MoleBoxPro that wraps the DLL in with my EXE. there are several freebies out there that do that as well. |
| ||
| its easy, the first time your program runs you just have to make a file with written the date. Of course the file should have a bizarre name as libbootsrc.txt and should be hidden somewhere in the system folder(possibly invisible). Then every time your app is run you read that file and verify if 30 days have past. There is always the risk that the user alters the system time, so you should also put a "30 uses" limitation, or better keep just that limitation. |
| ||
| You can also pay a lot for a program called ARMADILLO and I am still considering it. |
| ||
| Thanks everyone Shawnus |
| ||
| if you go along with Najdorf's suggestion, store the current date in that file as well. only store it if the current date is greater than the stored date though and then use the stored date to do your checking. that way if they do set the date back it wont have an effect because the stored date will be greater than the current date. on a side note... Najdorf. you mentioned an invisible file. i was trying to do that very thing not to long ago, but was unable to figure it out. marking the file as hidden is ok, but i was actually trying to make a truly invisible file. were you talking marking as hidden or do you know a technique to make the file truly invisible? |
| ||
| I meant hidden... I dont think you can really make it invisible, or maybe you can but I've never seen one (thats because they're invisible, you wierdo... lol...) |
| ||
| There is something you can search for about reading and writing INI files... if you combined that with a slight encryption... all would be grand! Search the B3D section for INI file and encryption -RZ |
| ||
| For encription, there's some really easy stuff in the Blitz3D documentation regarding XOr. Or, for something much easier, just take each number & convert it to ASCII using Asc() (when writing) and back to normal using Chr$() (when reading). For most users, ASCII looks like some sort of heavy encryption, and is therefore difficult to figure out how to edit. |
| ||
| unless you use a hex editor to edit the datefile and suddenly the character info is all there alongside the hex codes :) perhaps you could do something with terrabits data packer at runtime so that the program can write its own timestamp back into the pak file rendering it incaccessible to users? possibly encrypt it as well.. a simple crc32 checksum of the install date would probably suffice especially if you mess with the generator this would reduce the date/time string to 4 bytes :) bear in mind tho that if you want to check against current date to stop people setting the clock back then you need a 2 way encryption |
| ||
| Note that he said 'most users.' Most users aren't going to have a hex editor or know to use one. As for the users who would know and who would do that, fighting them gets to be a waste of resources. |
| ||
| dont mess with the geeks man... |
| ||
| Well I would say also think when programming your app/game etc, that if you write it correctly you can either remove all but say two levels or remove save move etc. Basically full function of the app/game, but you cannot either try all levels, play full game or maybe save the data. I prefer just putting in a crippling section stopping the user from using the app without limits. They can then play around as long as they want until they are happy OR NOT!! For the game I am doing. Because it reads scripts to generate each game I am planning to disable the import scripts and the main script that comes with it to maybe so many years ie, first 2 levels. Mango |
| ||
| Hello All; A few bits of information for those that are wanting to put a time limit on their games for Trial purposes. Do not use the Registry: Using the registry to set time limits on your games is fine If you are making a game that is going to be used by children to educate, thus the parents will run it and then Buy it. Other then that, on a good game, Fighter - High impact type of games, you can near about guaranty that the user will find a way to go around the registry. It is not that difficult to do. You need to find a wrapper that will grab the .exe file and wrap it with a Hardware inventory list. What this will do is run the program on the Current Install only of the Windows OP. So that the only way to further run the program without first purchasing it is to ...(Something that only the true die-hard gamer/hacker will do) Reload the OP to extend their time every 30 days. (Useless and meaningless but people do, do it) The software that we use to sell came with 30-day trials. And the wrapper that we used luckily was unbreakable. No cracks came out for it for the 2 yrs that it was available. But previous versions of the program running a lower-end wrapper was cracked and found all over the net. Very sad day to find that out, but a better wrapper was made, we got it and it worked like a charm. Unfortunately that wrapper will not work with Blitz. As it is a source code wrapper, that was made especially for Delphi & C++ Language codes. (Borland Code) ---------------------------------- #1: Do not use the Registry. #2: Find a Wrapper that grabs hardware Inventory. HTH Carrzkiss |
| ||
| I used google to search for "Antipiracy Software" and got a lot of interesting info... -RZ |
| ||
| #2: Find a Wrapper that grabs hardware Inventory. That's very good anti-piracy advice, and very bad customer service advice. Every time one of your customers changes a piece of hardware, reinstalls windows, gets a new computer, buys a game on their internet-enabled desktop to play on their no-internet laptop, etc, the game refuses to run. Any time your anti-piracy measures are annoying your legitimate users, you've crossed the line IMO. Refer to any one of a million complaints about Steam to see what I mean. They barely endured it for HL2. They won't endure it on Indie Games. |
| ||
| Worth a look :) I tried it and it also picks up if you alter the date. http://www.softwarekey.com/swk_products/trial_creator/ |
   |