I have been asked to create a self deleting exe, it has been a curious task
that has proved fruitless
I have searched in various places but to no avail, if anyone can help me I
would be very grateful
thanks dave

I'm pretty sure that you can't delete an executable while it's in use. One
way to delete it is on reboot using the MoveFileEx API and forcing a reboot.

It would be easier to shell to another program that will delete the Exe for
you and immediately end the program.

Simple:

Private Sub KillMyself()
Shell "C:\MyDeleteProgram.Exe"
End
End Sub

Your Delete Program would have one module and one sub:

Public sub Main()
    kill "C:\MyExe.Exe"
end sub


You may have to add a call to the SLEEP api to allow your original EXE to
end before you delete it.

Private Declare Sub Sleep Lib "kernel32" Alias "Sleep" (ByVal dwMilliseconds
As Long)

Public sub Main()
    sleep 2000 'play with this number till you get something that works.
    kill "C:\MyExe.Exe"
end sub

If your original exe will not always have the same name,  send a command
line to your Delete Program.

Private Sub KillMyself()
Shell "C:\MyDeleteProgram.Exe " & app.path & "\" & app.exeName & ".exe"
End

Private Declare Sub Sleep Lib "kernel32" Alias "Sleep" (ByVal dwMilliseconds
As Long)

Public sub Main()
    sleep 2000
    kill command
end sub

Show quoteHide quote

Show quote Hide quote aaaaaaaaaaaaaaaaaaaauuuuuuuuuuuuuugggggggggggggggghhhhhhhhhhhh!!!!!!!!!!!!!!!!!!

I know. Sigh.

Show quoteHide quote

"ajones" wrote...
LOL

@echo off
del dm.bat

A batch file can delete itself.

Show quote Hide quote Really should be
    Public Sub Main()
        Kill "C:\MyExe.Exe"
        Shell "C:\MyDeleteMyDeleteProgram.Exe"
        End
    End Sub

Ad Nauseum...

I don't think you can do this in VB. You'll need to write something in C
that will delete your VB exe and the C exe. This shouldn't be too difficult.
You'll need a retry period of a few seconds at least to allow your VB.exe to
exit.

Probably the best bet is to mark the file for deletion at reboot, using
MoveFileEx API  with the MOVEFILE_DELAY_UNTIL_REBOOT flag. It works on Win2K or
later; for pre-Win2K, you get to fumble around with WinInit.Ini. See this link
at MSDN:

http://msdn2.microsoft.com/en-us/library/aa365240.aspx

caver_dave wrote:
there will be some more groans ... I've done it,
and it *does* use the Evil End Statement:

http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/2b555c3923ec2531



    Bob

Show quote Hide quote There is something deliciously brutal about that method, almost like taking a
screwdriver and scraping the program right off the hard drive. Nothing like good
old DOS, where real men can write batch files that delete themselves, no
questions asked.

There is no need to use the end statement. I presume tho you were kidding
when you posted this.

Michael

Thanks to all for all your help

I think that I will try the batch file method first.

Taking the "real man" DOS method, 
then I shall be going off for a cold beer, a raw steak and a hot woman!!
though not necessarily in that order!

(miss quoted from kayak by W. Nealy deceased)

All jokes aside thanks

dave

Don't bother. It's a fricken terrible way to do it. Considering you've been
asked to do this I would advice against presenting this solution to whoever
ask you to do it. If I asked someone to do this and they came back with such
a solution I would be none too impressed. Doing something in C++ would be
very easy and would be the correct way to do it. If you don't know C then
ask and a C group and come back with a solution that will impress your boss.

Michael

Show quote Hide quote I'm curious, why would C or CPP be able to delete a file that is
locked by the OS ?

I don't know the details but I know it can. I asked someone to do this for
me once and they did it.

Michael

Michael C wrote:
....and you didn't look inside.

No, my role was manager in this case.

Michael

So for all you know the program COULD have spawned a batch file which first
deleted the executable and then deleted itself

Dave O.

Show quoteHide quote

I'd be *very* suprised if it did.

Michael

Show quote Hide quote If the bat file thing will work 100% of the time, I don't see too much
wrong with it.

The exe to do whatever is needed could write the .bat file to the user
temp directory, shell the bat file, then close. The bat file could have a
pause in it first thing to allow the exe to finish, then delete the exe
that created the bat file, then delete itself.

Thanks for the laugh.  You  are entitled to your own opinions, but do realize
they are just that, 'your own opinions'!  If you want to impress someone, then
how about working up a solution in raw machine code, or go the OOL
approach and provide the answer in Small Talk.

You have no reservations about using the underlying programming interface
of Windows, but disdain a solution that uses the Disk Operating System?
It just seems a bit too particular to favor one, and not like the other....

By the way, how many installation packages do you know of that do not
use temporary files???

LFS

Show quote Hide quote You've gotta be kidding me. Surely anyone with half a brain will see that
batch file is a *very* poor solution.

Michael

Show quote Hide quote Why?

-ralph

Are you guys actually serious? I'm starting to suspect you're trolling. I
can understand using a dos command if it is an *absolute* last resort but in
this case there is an easy way around it. I remember saying recently that if
I got on a newsgroup and said the world was round someone say it was flat.
No matter how far out an idea there is always someone arguing it. Doesn't
this thing have your hack-o-metre (tm) going off the gauge?

Anyway, in answer to your question, it has no timeout, hence no error
warning, permissions might deny running a bat file. If it fails it will sit
on 100% cpu forever and cause problems shutting down. If we need to add
functionality we will be restricted to batch file commands hence it is
inflexible. But the real reason for not doing this is that it just feels
wrong. When something feels wrong there are more than likely unforseen
issues that will arise at a later date. As an example, we might fun this on
our dev machine and get no problems, release it and think everything is all
fine and dandy. But then the customer's virus scanner picks up on this and
interferes with the process somehow. It might warn that a program is
exhibiting virus like behaviour, which the customer will not enjoy. It might
deny the batch file altogether, still with a warning. It might allow the
batch file but deny the delete. Anything could happen.

I'm sure you'll reply with fixes for some of the above problems, but please
don't bother if you can't fix all of them.

I don't see what the issue is with using C. The wizard will create a blank
project for you and you just need to insert the appropriate API call to
delete the file and maybe one include statement and a loop that times out
after x seconds. Very simple stuff and then it has been done properly.

Michael

Do you think this C program will be able to delete itself while making the API
call? Or are you just talking about deleting the main program file? If the
latter, the issue then becomes, how do you delete the C program, etc. Have a
look at the link in Tony Proctor's post in this thread.

I'm not sure how it was done but it did get done.

Michael

You could be right that it was not as easy as I suggested. I asked someone
to write me something in C that would delete an exe. They did it in fairly
quick time and didn't mention any issues so I assumed it was easy.

Michael

The obvious response to this is that the OP may not have anything to compile
C with.  I don't!

That said, I gotta go with you on the rest of the post (which I've
snipped)...having to resort to a DOS batch file just screams of hack to me,
and I'd avoid it unless there were no other way.



Rob

What about shelling out to the command line interpreter?  There are hundreds
of posts where the solution includes a call to COMSPEC to do this or that.
Its the same mechanism, except the batch file allows for additional commands!

As far as I am concerned, if a simple method works where you need it to work,
then it is the right solution....

LFS

Except this solution is likely not to work.

Michael

It's the fact that you're using the shell that I have problems with, not the
fact that you're calling a batch file.  There are times when it's necessary,
but I agree with Michael (which doesn't happen often)...using the shell, no
matter how you're calling it, should be avoided unless there's simply no
other way, or the other way would require an inordinate amount of effort.
In this case, most of the alternate methods DO require an inordinate amount
of effort, so you might be best to go with the batch file, but as a rule, I
consider that a last resort, not a first one.

To each his own, though...I'm not here to dictate to anybody how they should
program. :-)



Rob

On Mon, 14 May 2007 21:19:39 -0400, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote:
in <uzQQp8olHHA.4***@TK2MSFTNGP05.phx.gbl>

Show quoteHide quoteTo me, whatever works works.  And any argument regarding technique is
ridiculous.
Frank

<youare@kidding.right> wrote in message
Except this technique is *very* likely to fail.

This is one of those things that comes back and bites you later. As a one
off it's easy to fix if it does but if an app gets full of hacks like this
(and don't think this is anything other than a hack) then it becomes
difficult to maintain.

This bat file is also very limited, something as simple as showing a
messagebox if it fails is not possible.

Michael

in <#Ifr$PplHHA.4***@TK2MSFTNGP04.phx.gbl>

Show quoteHide quoteBite me.
Frank

<snip>

What API call ?

There are not many things that C can do that VB can't
(except for device drivers)

I'm not sure of the exact implementation.

There's PLENTY that C can do that VB can't. VB can only do windows apps and
dlls that run on windows. C can do pretty much anything. I've written
embedded stuff for 8 bit processors in C.

Michael

Michael C <nospam@nospam.com> wrote:
As opposed to those of us with a wholly intact brain, eh?

Here's an article that discusses the general issue:
http://www.catch22.net/tuts/selfdel.asp. It contains a comprehensive
explanation of the problem, and some very interesting "solutions"

    Tony Proctor

Show quoteHide quote

That's a very interesting read, Tony. A much better read than Michael C's
statement informing us that one of the methods previously mentioned in this
thread (and also mentioned in the link you posted) was "a frecken terrible
way to do it" and informing us of the fact that it is very easy to do in C++
but, apparently, according to his later response, not quite so easy that
Michael C actually knows how to do it himself ;-)

No wonder he doesn't call himself Michael C++ ;-)

Mike

On Sun, 13 May 2007 21:23:14 +0100, "Tony Proctor"
<tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote:

An interesting read
- it looks a little hairy to say the least

I've just done a test using Basic 7.1 and an exe can delete itself
- I expect this would upset anti virus systems

Blimey talk about proliferation !
Thanks to all

I have looked into both vb & c solutions and have found solutions in both.

I have gone with the batch file as out of all of them it is the simplest and
does not involve me  rewiring my brain to work with C / Cpp.

To Mike C
my boss does not know any dos and very little vb and was quite impressed
that a bog standard GUI designer could do it.

Once again thanks guys
dave

Show quote Hide quote Even after all the potential issues that I listed you still went with this
"solution"?!? And your boss was impressed?!? Notice that not one single
person listed a workaround for any of the problems I listed.

Michael

Even though I'm with you 100% on this one, I think you're exaggerating the
flaws with a batch file.  Here's your comments repeated, and my comments on
them.

Why would a "del" fail and then sit in a busy loop?  Assuming the batch file
is on a local drive, if it fails in such a way that it busy loops, it's
probably cuz your drive is failing, in which case a stuck batch file is
going to be the least of your problems.

If you need added functionality, that can be addressed in an executable
file; the only purpose of the batch file is to delete the exe once all other
tasks are completed.  If you need functionality afterwards, you spawn
another executable, which you can then cause to self-delete in the same way.
I don't see this as an issue.

While I agree, I also think that using Exit Do or Exit For "feels wrong",
and you will never see those constructs in any program I've written.  That
doesn't mean that it's necessarily a bad thing for someone else who doesn't
have my structured programming prejudices.

Ummm...on-site testing wouldn't tell you about this problem?

I didn't "fix" a single one of them, but I did give reasons why they might
not be issues for someone.  Does that count?

As already discussed elsewhere in the thread, there is no appropriate API
call, so another solution needs to be found; C doesn't help with this,
unless you count the fact that you can use inline assembly (as documented on
the website someone linked to).



Rob

If it does fail, you can just delete it while it is still running, since it is a
batch file! :)


And this could never happen with any other kind of program except a batch file?
As I said in another post, I like the raw brutality of that batch file.

In the real world, I don't see much need for a self-deleting exe in the first
place. I say go with

Private Sub Command1_Click()
Shell "rundll32.exe shell32.dll," _
    & "Control_RunDLL appwiz.cpl", _
    vbNormalFocus
Unload Me
End Sub

which just takes the user to Add or Remove Programs :)

If it needs to delete a file, then it has to have permissions to do so.  That is
a given and has to be set up as a condition of installation.  After that, how
could it fail?

LFS

Show quote Hide quote I'm with Larry, I didn't see it as being that big of a problem, but was
curious why you did. I asked for an explanation, and you gave it. While I
can understand some of your concerns, I still don't see it as a 'bad
solution', if it works.

My guess no one bothered to reply with a 'workaround' because in practical
use - none is needed.

"... it has no timeout, hence no error warning"
I don't see that as problem because who would it report the timeout or error
to? And what would the program do when it received an error? I can't think
of any process that wouldn't have an opportunity to fail - given the right
circumstances.

"...  permissions might deny running a bat file."
More possible for a .bat or .com file than a .exe perhaps. If the
environment is unfriendly, its just unfriendly. Can happen to anyone.

"If it fails it will sit on 100% cpu forever and cause problems shutting
down." I doubt that - all its doing is deleting a file, if it fails it
fails. if it hangs it hangs. Windows shutdown is very good at killing off
unresponsive apps. But again, it might happen to any process.

"If we need to add functionality we will be restricted to batch file
commands hence it is inflexible."
What functionality? It is attempting to delete a file.

"But the real reason for not doing this is that it just feels wrong."
It doesn't fell that wrong to me, assuming it works. Howerver, I'm not that
convinced it will.

As for the rest of your points, upsetting virus-checkers, etc. That's the
risk you would run with any solution, except...

IMHO, I prefer Steve's suggestion. Sometimes we get too cute - Windows
offers this kind of service - why not just use it.

-ralph

Substitute for mscomm32.ocx?
How can I trim off leading zeros from a number? Help greatly appreciated!!!
VB 10 To Support Native Exe/DLL
Is there anyone uses VS6 on Windows2000 Pro?
Exiting from a Do Loop