[DUG] Renaming file in use

[Ross Levis]

> ShellExecute works fine. It is not posting a message. ShellExecute 
> will
not return until the new process is spawned. Also, I am passing 0 as the 
first param.

I'm doing exactly this to run a silent Inno setup install.  On some 
slower PC's the setup executable often did not load.  After inserting a 
sleep, it did always load, but this caused problems with the program 
still being open when the setup attempted to install the file.

Semi related to this, I am using a Mutex while the app is running to 
prevent another instance, and also to use the feature in Inno Setup to 
warn that the program is running during install or uninstall.  My app 
specifically releases the mutex well before the ShellExecute but this 
doesn't seem to take effect, even with ProcessMessages and sleeps after 
the release, Inno still says the program is running.  And this occurs 
mostly on faster PC's.  I would have thought the mutex release would be 
instant, so I'm bemused by this one as well.

Ross.

----- Original Message ----- 
From: "Kyley Harris" <kyleyharris at gmail.com>
To: "NZ Borland Developers Group - Delphi List" <delphi at ns3.123.co.nz>
Sent: Saturday, December 03, 2005 12:22 AM
Subject: Re: [DUG] Renaming file in use


That is a working example.

ShellExecute works fine. It is not posting a message. ShellExecute will
not return until the
new process is spawned. Also, I am passing 0 as the first param. Clearly
this is a basic example, and if your application uses mutexes
or any other behaviour to prevent it running 2 times, then this would 
not
work very well unless
you removed the mutex.

Halt is also not necessarily the killing technique of choice.
Depending on how much you care, Application.Terminate is a cleaner way 
of
doing it. But then who knows what
may then keep running to prevent the new copy loading properly. I would
generally never run this in a form or button for such reasons, but put 
all
this code in a routine called directly before application.initialize,
and then halt without launching any of the normal windows management 
that
TApplication does.


FOLLOWING IS A MORE REALISTIC EXAMPLE. Except in my real life i'd
generally be connecting to an update server
via tcp and downloading an update on the fly and saving it to 
ParamStr(0)
after doing the rename.
but putting a file there is easier.

to test this, just pick any other program and copy it to the folder and
call it new.exe you will find that it
works seamlessly. ( PS. if not WinXP then DONT WASTE TIME TESTING! Why?
Because I dont sell software to win98 )

program PTest;

uses
   Forms,
   sysutils,
   windows,
   shellapi,
   utest in 'utest.pas' {Form1};

{$R *.res}

begin

   if FileExists(ExtractFilePath(Paramstr(0))+'new.exe') then
   if RenameFile(ParamStr(0),ChangeFileExt(paramStr(0),'.bak')) then
   begin
     CopyFile(PChar(ExtractFilePath(Paramstr(0))+'new.exe'),pchar( 
ParamStr(0)),true);
     ShellExecute(0,'open',pchar(ParamStr(0)),'','',sw_show);
     Halt;
   end;

   Application.Initialize;
   Application.CreateForm(TForm1, Form1);
   Application.Run;
end.




On Sat, 03 Dec 2005 00:09:33 +1300, Ross Levis 
<ross at stationplaylist.com>
wrote:

> Are you sure you can run a ShellExecute just before terminating the
> program?  I've tried that and found the ShellExecute didn't run unless 
> I
> put a sleep for half a second or so before terminating the program.  I
> though perhaps the message was still to get to processed before the 
> app
> terminated, and the app terminating killed the message, or something 
> or
> that.
>
> Ross.
>
> ----- Original Message -----
> From: "Kyley Harris" <kyleyharris at gmail.com>
> To: "NZ Borland Developers Group - Delphi List" <delphi at ns3.123.co.nz>
> Sent: Friday, December 02, 2005 11:08 PM
> Subject: Re: [DUG] Renaming file in use
>
>
> Like it or hate it..
>
>    if RenameFile(ParamStr(0),ChangeFileExt(paramStr(0),'.bak')) then
>    begin
>      CopyFile(PChar(ExtractFilePath(Paramstr(0))+'new.exe'),pchar(
> ParamStr(0)),true);
>      ShellExecute(0,'open',pchar(ParamStr(0)),'','',sw_show);
>      Halt;
>    end;
>
> This is a valid method of updating an application under windows, and 
> is
> a
> design feature.
>
> I completely dispute the fact that this helps viruses.
>
> If a virus wants to replace ditto.exe, with ditto.exe (which is now a
> virus) its certainly doesn't need
> to sneak around and rename a file. If the virus is there, then its 
> going
> to do a kill process/or a copyfile.
> if they want to takeover a dll that is in use, typically they would 
> bind
> them selves in as a startup process to
> override the dll's etc before those dll's are used. Windows XP
> automatically kills any dlls and replaces them if they are system dlls
> for
> just such a virus prevention, so no real concern there either.
>
> It doesn't need to worry about renaming something????  besides that.
> Viruses hijack processes by binding themselves in as stubs on the
> application which still runs the normal code so that you don't find
> out...
> if they
> renamed a file to replace it with something else you would find out 
> very
> quickly when the job is not getting done anymore....
>
> On Fri, 02 Dec 2005 18:28:48 +1300, Rohit Gupta <r.gupta at xtra.co.nz>
> wrote:
>
>> Sean,
>>
>> I thought I would try this out and you are right, another crappo from
>> Microsoft.  Not only can you rename the file, it also renames the 
>> path
>> in the shortcut that launched it.  Another way a virus can get in.
>> And
>> you can even rename the dll thats in use.  Further to that if you
>> rename
>> a system dll, it silently copies it from the backup.  All test on
>> win2k.  Will all this really work the same way on XP, 2kserver,
>> 2k3server, Terminal Services, a pc using Domain Server and Longhorn
>> ????
>>
>> I would still maintain that its is idotic to rely on this mechanism.
>> Any
>> primitive virus protection thingy should foil this.  But does it ?
>> :-(
>> Zonealarm certainly did not complain.
>>
>> I despair.  Its worth the effort to write a virus to teach MS a
>> lesson.
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi



-- 
Kyley Harris
+64-21-671821
_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi