Peter Duniho replied to PeterW
21-Nov-09 04:47 AM
Even ignoring the specific functionality of the application, that seems
like a needless feature to me. A regular uninstall should be able to
remove the program just as well. Just tell your users to use the normal
uninstall that is part of your program's setup.
Alternatively, just use the "RunOnce" registry key, and have the users
reboot as part of the deletion process (so that the command you add to
the "RunOnce" key can be executed...this presumes that "RunOnce" and
rebooting is supported on Windows Mobile, which I do not know much about).
Besides, the idea that the user will erase "all traces" of the software
also seems somewhat misplaced. A user using the software who just
happens to be traveling through some country where the software is
illegal is not going to delete the software permanently. Presumably they
intend to reinstall at some later point, and they very well may keep a
copy on their person for that purpose (in case, for example, they
anticipate having trouble getting online).
It seems to me there are a number of "good" suggestions (inasmuch as the
idea is one needing solving, which is debatable :) ) in the article (and
some not-so-good...the "inject code into another process" idea is awful,
and probably will not work on any computer with DEP enabled).
In addition, generally anything you can do in C++, you can do in C#.
You may have to use p/invoke to access unmanaged Win32 features, but
otherwise it should work. I note that a number of the examples have an
asm block, but as near as I can tell for the most part that is just
obfuscation. You should be able to achieve the same results just by
calling the appropriate functions normally.
Of all those suggestions in the article, I would say that the
the various choices. It actually uses built-in, OS-supported API to do
the work rather than trying to hijack some other mechanism to do the
work. Best of all, there is nothing about it that requires you to be
running unmanaged code; you should be able to do the whole thing as
managed code.
Some modifications I'd make to the suggestion though:
-- Just write a stand-alone deletion application that you use to
create the temporary "DELETE_ON_CLOSE" file. Compile it, store it in
your main application's resource data, and then just write it out the
file at the appropriate time (it should be very small). (I see that
this is included as "an alternative method" at the very end of that
suggestion).
-- Don't mess around with the sleeping logic. Instead, use a
reliable inter-process mechanism for the main application and the
deletion application to communicate (e.g. named Mutex, sockets, pipe, etc.).
Of course, all this assumes this is actually a feature you should be
spending your time on. Honestly, it seems to me it is not. Just make
sure your uninstall works as it is supposed to and removes "all traces"
of the program. Then just tell your users to use that instead.
And tell your European governments that are putting up speed cameras to
do it the way other civilized governments do it: announce the locations
of cameras with signs. Then, the cameras serve more as an actual speed
control mechanism rather than a revenue-enhancement mechanism. That
way, you do not even need your application. :)
Pete