this program will self-destruct in 5 seconds...

mzimmers

@J.Hilk honestly, this idea is so schlock that I'm happy to go with the timestamp of when the image was built. The first-opened would be nice, but then I'm looking at a more elaborate implementation, and I don't feel like spending a lot of time on something I already think is lame (I much prefer spending a lot of time on something, THEN deciding it's lame).

J.Hilk

@mzimmers to be honest,
so kost easy way, on Windows at leasr, would be using QSettings with native format,

that creates a regestry entry. If you use a some what cryptic key, you should be set.

low key, not much effort, presistent even after reinstall

mzimmers

I forgot to mention, this needs to run on MacOS.

JonB

@mzimmers
Let me get this right. You want a way to know the datetime when an executable was built, in as simple a way as possible? Approximate will do. We don't want to put a timestamp into the code at build time. So what about just looking at the last-modified time of your actual executable application file at runtime?

mzimmers

@JonB that should work!

QDateTime QFileInfo::lastModified() const

Thanks.

JonB

@mzimmers
Yes, it's pretty simple if it suffices. I forget which call, but Qt library I think can give you full path to currently running executable for passing to QFileInfo.

mzimmers

@JonB oh that would be nice...it would save me the trouble of passing argv[0] into the widget, and needing a delegate c'tor and other stuff. I'll look for that, and post it here if/when I find it.

EDIT:

QString QCoreApplication::applicationFilePath()

Let it never be said that Qt does not rock.

JonB

@mzimmers
argv[0] can be changed, does not have to be path. This function tries a bit, be aware of:

Warning: On Linux, this function will try to get the path from the /proc file system. If that fails, it assumes that argv[0] contains the absolute file name of the executable. The function also assumes that the current directory has not been changed by the application.

May use a native call under Windows, I don't know.

Chris Kawa

I realize that you said you want something low effort, but breaking that "protection" will take whole 2 seconds. A simple touch yourapp will give you 3 more days (or whatever). You might as well show a popup asking to kindly stop using the app after X days and it will be the same level of "security".

Sorry to be negative about this but I suggest you either treat this seriously and invest in a real licensing scheme or do nothing. Otherwise it's just silly annoyance and code bloat that achieves nothing.

JonB

@Chris-Kawa
I had no idea the OP had said this was anything about licensing? I thought he was just looking for a quick & dirty method for some unknown purpose.

Chris Kawa

@JonB Well, he said

If this sounds crazy, I can scrap this idea and tell the customer he needs to buy some license management software for us.

so I assumed it's suppose to be a DRM type of thing.

mzimmers

Hi Chris - yeah, you're right. That's why I was hoping for a timestamp that might be built into the app (and not visible through the file system). This whole thing is silly, but the exercise might at least be useful to someone reading this later on.

EDIT:
Your sentiment is still valid, but this might obviate the specific problem you identified:

QDateTime QFileInfo::birthTime() const

JonB

@Chris-Kawa
Ohhhh! I stopped reading when @mzimmers wrote

If this sounds crazy, ...

Now I notice the thread title... :)

@J-Hilk indicated that your build system may allow inserting a datetime into C++ code being compiled, or similar. That would be better than file time, but nothing like @Chris-Kawa 's proper solution.

mzimmers

@JonB said in this program will self-destruct in 5 seconds...:

@Chris-Kawa
Ohhhh! I stopped reading when @mzimmers wrote

If this sounds crazy, ...

Probably should have stopped reading when you saw my name!

Chris Kawa

@mzimmers You can heave a timestamp no problem. There are __DATE__ and __TIME__ macros in C++ that will expand to current date/time at compilation moment, but it's useless for this purpose unless you plan to compile a separate executable for each customer right before he starts to use it.

Just go the whole mile and invest in a licensing app/lib that does encryption, passwords, trials and all the shabang. No need to reinvent the wheel. It won't be that round anyway ;)

mzimmers

So, as long as we're on the subject...can anyone recommend a lightweight license manager?

JonB

@mzimmers
A file's "birth" (creation) time can be altered just as its last modified time can. Any attribute of the file will not be robust. The compiled-in way is better.

JonB

@mzimmers
Just one thing: do you have 100 potential sites/users or 1?

And the second one thing: is your application in a server environment?

mzimmers

@JonB closer to 1 than 100. And, I'm not sure what you mean by "a server environment," but the app might have to run without the benefit of network access, if that's what you meant.

JonB

@mzimmers
That's kind of what I thought. On both counts I would politely suggest that going down a licence manager route would be unnecessarily expensive/complex.