Limiter trial of a Program

[jcc3inc]

Gentlemen:

I have made a program to modify code for machine tool CNC use. I would like to be able to offer it to prospective users for either a limited number of use cycles, or for a limited number of days use. What code can I put in the .EXE file in order to accomplish this?

I'm interested in the logical approach to this.

Thanks in advance.

Jack C.

 

[Buff1]

You can check the date against a limit date but the user
could always reset the clock date back.

mo$=mid$(date$,1,2)
da$=mid$(date$,4,2)
yr$=mid$(date$,7)
(assumes mmddyyyy)

you could set a counter to write to the exe in a specified location a string and check that each time the program is run. (or write to a hidden file).

then you could always delete the file if the counter is
past a limit.

What I do is set it up as a demo and not allow certain functions if it's the demo version. Then when they buy it,
they get full access.

 

[CodePost]

Like Buff, I also usualy make a special compiled version for demo software with the extra features removed.

Another good method is to have the program look for a 'key' file. If it's there, then have the program access the extra features.

You could appened extra info on the end of the EXE, I do that often and have writen a small tutorial on how here:

http://sys.blissdev.com/dav/?exeappend

One thing I've used in the past is the 'marker' method -- have the EXE file mark itself with info. Every compiled QB4.5 program has the name of it's BAS source inside the EXE. If your BAS was named 'DEMO27B.BAS' then near the beginning of the compiled EXE you would see 'blDEMO27B' in there. The DEMO27B text can be altered without effecting the programs execution (don't change the bl before it). You could OPEN the EXE, grab first 1000 bytes, have INSTR look for the data position and SEEK to that location. You would only need a few bytes for a counter marker. Of course there could be problems, such as if the user sets the EXE to read-only.

- Dav

 

[CubeE101]

You could give it a timer to time out after 10 minutes or so, so they can get the feel, then iritate them so they will buy the full version ;-)

(I would stick with the EXE method mentioned above)

Is this for dos PCs or Windows?

If it is for windows, there are tricks you can do to use the registry for this type of stuff...

Or...

Generate a code from the system Date & Time...
Display the Code to them...

Save an encrypted version of the code with some extra random bytes to a binary file...

Have them send the code to you where you then run the code through a program to generate a second (Activation) code...

Send the Activation code back to them...

The program should use the same method to generate the second code, and activate the program with a Counter...

Store the counter in the file along with the activation code...

Each time the program starts, it checks for this file, checks the codes and decrements the counter and saves it back to the file...

Also if the Activation code matches the register code, have it generate new codes and save them back to the file too, this way it makes it harder to crack...

If the file does not exist, it will not run.
If the file has been tampered with, it will not run.

If you want to use a 30 day trial instead...

You also use the modify date of the created file as a reference to the system clock, so they can't keep setting back the system clock... the system time must be > than the modify date... you might want to store this, encrypted in the file also...

Hope this gives you a few ideas ;-)

Good luck,
-Josh

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[quebasic2]

On buffs site I belive, is information on how to write to use asm in qbasic to write to the opening sectors of your qbasic file. That way, each time the file was run, you could check a varible in the opening sectors and subtract one from it until the time limit had run out. However, anyone with a little knowledge and a dissammbeler could crack the program. But it is about the best way to do a time trial.

 

[SJZero]

Why not write a file with the date of the first day the program is run into %systemroot%, then every day after, and if the clock is turned back before the previous date, the program disables itself by writing something in that file? It's a bit sloppy, but I dare you to find a better way under DOS to prevent a user from just installing/uninstalling to get another trial period.

 

[CubeE101]

if you are running it in windows, you use some command line methods to read and write to the registery...

The BEST way to do this is to buy a copy of VB.
Port your code over to that.
Get a 30 day trial wrapper, and forget about doing this in QB...

There are reasons that QB is outdated and this is one of them.

Are you planning to market a program written in QB?

You could get into some legal issues there...

Microsoft no longer licenses this software, so you can't buy it, and it is still illegal to profit off of non-licensed copywritten software.

Qb is more or less a toy anymore, and everything that is produced from it should be open source, and non-profit, for learning purposes or just for fun.

Given these facts there is no need for a 30 day trial.

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[jcc3inc]

CubE101:

I purchased the copy of Quickbasic several years ago and have the registration etc..I understand M$ no longer supports this so I didn't bother sending it in!

Regarding VBasic,could someone please comment on the speed of programs with a lot of calculations when using VB vs Quickbasic? My main interest is in machine control where speed is of the highest importance. Is VBasic able to do calculations substantially faster that compiled QBasic? Does it have to do with handling 32 bits instead if 16 bits?
My lack of formal programming training is a disadvantage.

Thanks for your comments,
Jack C.

 

[dilettante]

Brings up a question I don't think I have seen a good answer to. Has anybody found links to good information on speed comparisons between QBasic/QuickBasic and the various versions of Visual Basic?

My own experience is that 16-bit programs running under native MS-DOS are much slower than Visual Basic 6 programs that do a lot of crunching. Of course if the Windows box is burdened with services and other tasks running it isn't an apples to apples comparison. Just as a program updating a GUI display is going to tend to be slower than character-mode output under DOS.

But what about raw crunching? Anyone seen any numbers on this, with some contrived though not unrealistic benchmark programs we could run for ourselves?


A crony of mine showed me one a while back that showed VBScript screaming compared to a QBasic (interpreted) program. Of course he freely admitted his script was doing most of its crunching via compiled components. It had something to do with combining two CSV files to create a new one, and used Jet SQL and the Text Driver to perform the inner-join and do all of the file I/O. The QBasic program was raw cabbage-chewing: string operations, temporary arrays, etc.

The QB version was more than 20 times slower running on a separate DOS machine with similar hardware specs to the Windows box. The input files came to something like 180MB as I recall. One input file was large, and the other was very small ~ 100KB (a sort of code-lookup table).

The only point this really illustrates is the advantage in Windows of an easy to use component technology and plenty of off the shelf components to do common things. The difference is that using components is routine in a VB/VBScript world, while using DOS libraries is an "advanced topic" for the QB/QuickBasic community.


Anyway, it might be nice to have something more factual to go on than I've seen so far. Sure, benchmarks have severe limitations. But if there is a huge difference it would be nice to know about it - and such gross differences on various tasks should be easy to show. Maybe stick to strictly VB/QB source without heavy use of libraries or components? I wonder if that is fair to either world though?

 

[dilettante]

Oops!

Sorry, I'm waaay off-topic with that last post. Sorry.

 

[CubeE101]

Visual Basic, such as VB6 is a compiled language.
It actually uses a variation of the VC++ compiles.
The calculations in VB are MUCH faster than anything in QB could be.

VB is 32 and compiled w/ more optimization.
QB is 16 and compiled loosely w/ little or no optimizations.

VC++ is still the fastest because it has even more optimiztions.

As far as porting code from qb to vb, it goes pretty smoothly.

You can cut out all the Screen commands. (welcome to Windows ;-)

I don't think peek/poke or inp/out are supported in vb.

but in exchange, you get access to a billion api commands that make the Peek/poke,etc... obsolete.

Overall, the syntax is more or less the same.
You get added support for OOP (Objects).
You don't have to set your screen modes.
You don't have to remember all of those memory/port addresses.

Switching to VB is a win/win situation.

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[jcc3inc]

Gentlemen and ladies:

Thanks for your replies about VBasic vs compiled QB45.
In my case I MUST have INP and OUT as I use the parallel port; however I have seen work-arounds to enable this to be used in VB (although I haven't tried them as I've done no VB programming).

As mentioned before, my field of interest in machine control. There are several individuals who make controllers which work in Windows, and two of them have managed to minimize or eliminate the Windows housekeeping routines which do not contribute directly to the machine control process. The result is a fast, smooth pulse train output which is desireable. Those who haven't handled the housekeeping activities either have very ragged pulse trains out which are not acceptable (one guy just gave up!), or else they have resorted to external means of generating the smooth pulse trains. So-- after that dissertation, my question is ,

"Where can I find info to control or eliminate those Windows functions which do not directly contribute to my running just the program needed for machine control and Nothing Else?"

Thank you for your comments and suggestions!

Regards,
Jack C.

 

[tsh73]

From my limited experience.
On speed:
I have a program that calculated schedules (for a school), brute forse search, 16 bit integers. Speed was basically the same in VB6 and QB4.

About win/win situation:
it happens that I still have some VB3 programs... They are of NO USE today! While I still can (and do) run QBasic code. I'm afraid same thing will be with VB6 with coming of VB.NET.

 

[dilettante]

jcc3inc,

It sounds like you need a real-time OS rather than either Windows or DOS. One way to start exploring this is to just do a google search on "real time operating system" and see where it leads you.

That said, for many smaller outfits trying to do things like machine control, DOS has always been "close enough."

If you want some of the advantages of Windows, I suspect you'll want to avoid the NT-based OSs (such as NT4, Win2K, XP, etc.) because they work hard at trying to be something else altogether. The hardware is normally "virtualized" to a significant extent, and the OS is optimized for multitasking and doesn't readily offer any sort of absolute task prioritization.

You can get access to the parallel port in NT via hacks or special kernel-mode drivers. I've even written code to drive flash memory device programmers over the parallel port for Win2K. But this is a lot less hassle and more reliable under a stripped Win95 or Win98.

You might try a search for a product/service called "98Lite" for this. There was a simple software product you can try for free (though $$ for commercial use) that strips a Win98 installation down to bare bones, optimized for speed and control. They had a service that could take this further if required, and supposedly even makes Win98 ROM-able (or at least easily flash-able into CF cards, etc.). I think they are still around.

I have used OEM installation scripts followed by my own BAT files to do a minimal Win95 install and then clean it out even further (delete more junk files, tweak and compact the registry). I turned off virtual memory and tweaked a lot of stuff. Then I played games using a large Windows RAM drive and relocated almost all "scratch" functions into it (TEMP directories, browser cache, etc.). Then I compressed the boot drive and imaged it onto a CF card. The result booted and ran with no floppy or HD at all. What a lot of work though!

My point is that you can customize Win9x to some degree.

In general though using Windows is like trying to convert a station wagon into a pickup truck or something. Neither Windows nor DOS were made for this sort of thing. The NT OSs even less so. Nor is Linux a solution, though you might consider it an approximation too if you want to go that route - I think there used to be a "real time Linux" kernel available.

Other solutions might include Windows CE or Win XP Embedded. This is a bit harder to "get your hands on" without a significant investment. You don't just buy a copy from NewEgg or Buy.com or Dell. These are also more or less compiled and linked for your hardware setup instead of being "run-time modular" loading dynamic drivers like the consumer Windows OSs.

I think the "cheap and easy" route that may be "good enough" is probably Windows 98 + 98Lite. Painless to look at anyway if you have a spare machine to play with and a copy of Win98 for it.

 

[CubeE101]

About the VB.Net...

I see where you are coming from, but I don't see vb6 going away for awhile, and if it does, QB will be long gone.

VB still supports 32bit windows code.

QB supports 16bit dos.

VB.Net is the next generation, but seems to be (from what I have seen) wrapped around data (such as XML).

These types of programs could prove themselfs or they could just be a fad, that is doomed to die.

but reguardless of wether or not vb.net goes mainstream fullblast, VB 6 is still an expandable and adaptable language that could be adapted to the changes.

where QB was just 1 small exe file that had a fixed set of code and supported use of 1 static library that had to be linked into the exe.

These are 2 totally different senarios, and I don't think VB will have the same fate as QB.

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[dilettante]

Back to the original question, I agree that a key file could do the trick.

You can play games hiding the file, or not. When the program starts and the key file is missing or invalid, prompt for the key.

You want to get sneaky with the key though, so they don't just go in and reset the dates or something.

With (for example) a key format like:

XTM0D0YYY0MMDDYYYYNNSS

X is some sentinal padding value.
SS is a Mod 100 checksum of the other digits.

If T = 1 is a "so many days" key:
Key starting value (create this, give it to the user):
Put an "install by" date into M0D0YYY0 when you create the key for them.
Put a random digit into X.
Put random digits into MMDDYYYY.
Put the days in NN, say 30.
Calc SS.
First run:
If SS is invalid, abort with error.
If M0D0YYY0 < current date, abort with error.
Replace MMDDYYYY with current date.
Decrement NN.
Recalc SS.
Store back, let program run.
Subsequent runs:
If SS is invalid, abort with error.
If NN = 0, abort with error.
If MMDDYYYY is current date, let program run.
If MMDDYYYY isn't current date:
Replace MMDDYYYY with current date.
Decrement NN.
Recalc SS.
Store back, let program run.

Note: This T = 1 allows NN "run days" that can be spaced out.
It doesn't provide a "cut off" date.

If T = 2, is a "so many times" key:
Key starting value:
Put an "install by" date into M0D0YYY0 when you create the key for them.
Put a random digit into X.
Put random digits into MMDDYYYY.
Put the number of times to run in NN, say 30.
Calc SS.
First run:
If SS is invalid, abort with error.
If M0D0YYY0 < current date, abort with error.
Decrement NN.
Recalc SS.
Store back, let program run.
Subsequent runs:
If SS is invalid, abort with error.
If NN = 0, abort with error.
Decrement NN.
Recalc SS.
Store back, let program run.

If T = 3, is a "run forever" key:
Key starting value:
Put random digits into M0D0YYY0 when you create the key for them.
Put a random digit into X.
Put random digits into MMDDYYYY.
Put random digits into NN.
Calc SS.
Each run:
If SS is invalid, abort with error.
Put current date into MMDDYYYY.
Increment NN Mod 100.
Recalc SS.
Store back, let program run.


Then obscure the key:

In the key file, perhaps record every digit "flipped" (9 for each 0, 8 for each 1, etc.). You can use a simple Mid$() against "9876543210" for that.

For the key you give them to enter by hand, you could encode each pair of digits in hex. Example:

For 7206012004123456782060

Give them 48060114040C22384E143C to enter.

Or break it up as 4806-0114-040C-2238-4E14-3C

Just have your "accept first time key" routine translate back to decimal digits.


This is just an "off the top of the head" idea. But I don't know of any handy QB code lying around to do something like this.

 

[MiggyD]

I, along with almost everyone else that has responded, would recommend a two pronged approach.

1) a file to store some information--such as the start (or last) date of use.

2) a marker within the EXE that your program will change.

For #1: If the instrument (like a sonagram machine) has a storage device, I would save the date (most likely the first date of use) to a file in the windows directory as not too many people would go there.

For #2: You can place a counter inside your EXE and have your compiled EXE modify it by opening and changing itself (unfortunately this suggestion is akin to self modifing viruses, but useful nonetheless).

--MiggyD

PS - I would place the checking routine at the fore-front of your program. I have seen where one doctor simply pushed the power switch off instead of shutting down windows.