Double click an application.

[petermeachem]

Does anyone know what happens if two people double click the same .exe at the same time. Is it possible to get a read lock?
Also what happens with ini files. If two people read one at the same time (via the .exe of course), can you get a lock? Or if person one reads while person two writes to the ini?
It's something I've never thought of before, but this programme is to be installed on a Citrix Server, so there will be a single copy which everyone will execute. Peter Meachem
peter@accuflight.com

 

[snalwala]

have u ever heard about in process and out of process ???? exe's are all out of process applications. That means every time you excess it it opens a new instance of it. it doesnt get locked any time. Just you can make it read only thru' windows....

 

[MichaelRed]

The ".INI" part is somewhat more complicated. In effect, you should be using the username and having a seperate ".INI" file for each user.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[petermeachem]

I just read this in some Terminal Server stuff on Microsoft.

Most Win32 applications install in a pseudo user-global fashion by default, even when the session is not in installation mode. These applications make use of Terminal Server's registry, where each user can have a unique set of registry settings. Win16 applications use INI files for configuration settings. They must be installed using installation mode so that multiple users have separate copies of these files. It is recommended that you always install any Windows application, whether 16-bit or 32-bit, using installation mode.

So it looks like there is a single copy of the exe and each person has their own ini, which is of course exactly what is wanted. I wonder if the operating system is smart enough to recognize App.Path as pointing to the users home directory, and not to where the exe is?
Up early today Michael! Peter Meachem
peter@accuflight.com

 

[strongm]

snalwala, your assertation where the executable file is concerned is not completely accurate. Whilst other processes can indeed read it, the file tends to be 100% locked for write access (although the requirement to actually write to it is likely to be low)