Overwriting existing compiled .exe's

[John Balshaw]

Hi All,

I suspect this is a Windows executable issue, but I'll ask all the same

I've just about finished with my mammoth task of converting all our old Basic PDS programmes into PB 4.0.

When I made a change to my programmes with Basic PDS, I could just overwrite the executable with the most up to date version in the knowledge that when our users quit out and re-entered the programmes, then they'd have the most up to date version.

Now, with PB4.0 executables I find that I can't overwrite them until all the users have stopped using them (I'm guessing that Windows pages the programmes in and out so it puts a file lock on them to ensure nothing untoward happens?).

Is this correct, or is there some change I can make to the executable to allow it to be overwritten when it's time for it to be updated?

Thanks, John

[Michael Mattias]

Absolutely the expected and normal behavior: Cannot overwrite a file in use.

Under Windows, a PE (EXE or DLL) file is in use when executing.

[John Balshaw]

Absolutely the expected and normal behavior: Cannot overwrite a file in use.

Under Windows, a PE (EXE or DLL) file is in use when executing.

Thanks Michael,

To be honest I expected this, but hoped there was some way I could fool Windows into executing the programmes like my old Basic PDS stuff - If Windows _did_ actually load the entire programme in at one time I'd be 'safe' as the programmes are totally self-contained units.

It just means that from now on I'll have to set my alarm for 8pm when I've got updates to propagate

Regards, John

[Michael Mattias]

If users reboot each day, you can queue the files for installation at that time using the WinAPI MoveFileEx() function.

[John Balshaw]

I don't believe it would work for us - we keep our executables on a network drive, so everyone would have to be off the system for it to work.

Probably the best idea is to stick them all into an 'update' directory and have one of my housekeeping machines copy them onto the network drive through the night.

Regards, John

[Chris Holbrook]

suppose that your users start a particular program via a shortcut. Have the shortcut COPY the executable to a local drive and load it from there. Have a startup batch file which cleans out the local directory so that executables therein are never more than a day old - or something like that. Then the server executables are never locked for longer than it takes to COPY them.

[John Balshaw]

Thanks Chris, good idea - I'll change that slightly so I'm check for new executables at every 'run' (just in case there's a huge error which has surfaced, otherwise the programme'd only get updated first thing in the morning)

Regards, John

[Anthony Giambalvo]

Overwriting existing compiled .exe's

I actually do something like this with my applications. The latest version of each application is stored on the network in its own directory, and is run locally. Each application has an 'appname'.ini file ('appname' is also the name of the main .exe) that identifies the current version directory, the name of each application file and the version number for each on the local machine. This .ini file allows applications to be installed in different locations by different clients. When I update an application or component, I just upload the file to the remote location and update the .ini file with the version number.

Each application has a CheckUpdate() function that is called at startup. CheckUpdate() checks for an update by comparing information in the local and remote .ini files, and if a newer version for any file exists, runs "update.exe 'appname'", then terminates itself.

Update reads the local and remote .ini files and copies all files that have been updated from the remote location to the local folder, updates the local .ini file, and restarts the application. I wrote Update using PBCC about 10 years ago and if I can find the source code in my archives, I'll post it for you.

[John Balshaw]

Thanks, it's always interesting to have a dig through someone else's code. But for the moment I've settled with :-

xcopy /d /y /c /q h:\PROGS\*.exe %temp%

At login.

My executables live in PROGS, anything with a newer timestamp is copied to the %temp% directory, where I then run it - not as elegant as your method, but a whole lot faster and easier

Regards, John

[Guy Dombrowski]

Simple

The power of those good old DOS Commands.
They are often forgotten.

[Hubert Brandel]

Hi,

I am not shure that it works with EXE, but a DLL file could be RENAMEd even it is in use. Than copy the new one into the directory. All new users have the new one at once, and the other by next programstart.

Hubert

[George Bleck]

a DLL file could be RENAMEd even it is in use

I'm gonna think no on that with a slight caveat. If the DLL is loaded into memory I would think windows would prevent this. Only if the DLL is not currently loaded in memory or if the library is released with FREELIBRARY would I think you could rename it.

This is without me testing it and I could be completely wrong.

[Hubert Brandel]

Hi,

I didn't test ist, because I do only have EXE files.

But 2 or 3 users in our Xbase++ Forum use many DLLs in there programs, used from over 50 clients in a lan and the wrote that this is there way for updates. The DLLs are dynamic linked in Xbase++.

BUT - why thinking, make a test by now !

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
    MSGBOX "This is a Test"
END FUNCTION

I just build this little TEST.EXE and start it.
The msgbox is shown and waiting for OK.
Now I just change in the Explorer the name to TEST-1.EXE - no error message, the msgbox still shows program is running.
Now I start TEST-1.EXE - no problem and
change name to TEST-2.EXE ...

So it is true, you can RENAME a running EXE and used DLL !

My system is Win2000 and I am a administrator.
Maybe a USER is not allowed

[Michael Mattias]

I'm gonna think no on that with a slight caveat. If the DLL is loaded into memory I would think windows would prevent this

I did test and was shocked that "apparently" (meaning File Explorer handled it) you can rename either a running EXE or DLL. (win/xp pro sp2 all updates)

No, I don't know what happens if the O/S needs to swap in either later, but I frankly found this pretty scary and would not be surprised if this became a "security issue" resulting in a service pack or other update.

But let's not deal with that right now.

The important question here is, "I need a way to update executable files pretty much transparent to all the users on my network." I think we've seen some ideas here which address that.

Perhaps not elegant, but if it works, is relatively efficient and is maintainable, it can't be all bad, can it?

MCM

[Hubert Brandel]

No, I don't know what happens if the O/S needs to swap in either later, but I frankly found this pretty scary and would not be surprised if this became a "security issue" resulting in a service pack or other update.

Hi,

I think this is a 'feature' from windows for update, because the have to update there DLLs and EXE too on a running PC.
The running EXE process self don't care about the NAME of the file, he has got a filehandle

Bye
Hubert