system("del argv"); //windows, rm for unix instead of del
you can also do cool stuff like parse argv to see what your program's name is currently. If its the original name, do one thing, if its another name, give an error message or whatever. Then you can rename instead of delete. /shrug we had a program at a place I worked where changing the name put it into a demo mode that was stable, the original name was the in-progress version, so we could give a demo on short notice without having to maintain a stable version just for that nonsense.
You can get as fancy/stupid as you like here, you can have it check the date/time and only work if that is less than some value, so your code only worked for a day or two, etc.
there isn't anything you can do that IS foolproof for a single executable. Fools are too creative. I mean, burning to a cd or putting on a write protected usb disk are even stronger than read-only. Permissions also mess with it, if the admin set it to execute read only and the users / other accounts only have execute status. You can try writing something somewhere, but a good hex-editor or decompiler will thwart that pretty fast. You can try time of creation of the executable against a constant timestamp but back-dating the computer beats that.
If the user knows what the program is going to try to do (run once and attempt to prevent future runs) it can probably be defeated by some hackery by a determined enough person. Beating all the determined people, if its even possible, would take a massive effort. I assumed he just wanted to know if it could be done / toy more than some sort of high end security mission impossible type program.
it would be much easier to set this up so the user had to access it via some client software that you provided and the client triggered the server to self destruct. A pair of programs like that could be fairly secure, if you were able to prevent (detect, really) if the user made their own client. A bit of encryption theory applied there would be nearly foolproof.
If you have a website you could store a value on the server and check if it has been executed, but this works only with internet connection.
Commercial applications do frequently use this. The program contacts a license server over network. The program simply does not start without a valid license, so if either net is down or server expires your license, then ...
I like Jonnin's suggestion to only allow it to run only a certain date.
This has many advantages, one being that someone could backup or copy the file.
Other ways i have seen include a SN# file that changes after the first use making it invalid without the correct value.
Windows may not allow a file to delete itself, since it's in use.
One way around that would be to call the file to delete from another file, such as a batch file.
You could also replace the file with another saying the program can not be ran twice...
You cannot delete or modify the executable of a running process on Windows -- it is locked. There are various ways to ask Windows to delete the file for you some time after it terminates, but simply deleting (or corrupting) the executable image is a very simple solution.
Without verified cloud connectivity permitting an executable to run once, there is no way to guarantee run-once. Even big companies like Google and Amazon aren't interested in spending the capital necessary to do something like this. Cloud connectivity facilitates running things a lot of times -- in app purchases, usage statistics, advertising, etc.
Why would you want to do this anyway?
Installers, for example, will check to see if the program has not already been installed, and even check the program's version, then ask the user if something is going the wrong way. This is different than preventing the installer from running, though.
The simplest solution would be to create a registry entry in current user software that, by being present, marks your program as having been previously executed. Most users will not know how to find and remove said entry and permit reuse.
Barring a registry entry, stick a little file somewhere (like appdata/roaming or in $HOME) that signals the same thing.
Still curious: what on earth are you doing this for?
there used to be ways to tell windows to unlock files that are in use (allowing deletion or modification, great for pulling videos or sounds etc out of the internet cache), but I havent tried this since winxp or maybe the one right after that. I don't know if they still work. By default, you cannot, my mistake on recommending that.
you can in that case bury the real code in a dll or other library which if not present or garbled don't execute. This has the same flaws as the single machine program against a stubborn user, though.