Re: Temp directory and directory of the .exe file.

Actually, yes, it is a Really Bad Idea. Why could anyone think it is a Good Idea?

In any kind of shared environment, it means that every user gets to inherit the most
recent user's changes, which doesn't even make sense!

Or do you know that not one of your users will EVER, under ANY CIRCUMSTANCES, make your
program available on a multiuser machine? Or via putting in a shared folder on a network?
Or exercise good judgment and put it in a protected folder? Or put it in a shared folder
used by multiple VMs?

It is bad practice, and always has been. It makes your application vulnerable to various
virus attacks, and it means you cannot run in a multiuser environment (even an environment
with multiple user IDs on the machine, logging on sequentially, not necessarily in a
Terminal Services environment).

And it doesn't work if you put the executable in a shared network folder for everyone to
use, or in a shared folder (even on one machine) used by multiple VMs.

How many things are wrong with the concept?
1) It is dangerous on single-user machines
2) It doesn't work at all on multiuser machines
3) It doesn't work at all if the executable is in a shared network folder
4) It doesn't work at all in a Terminal Services environment
5) It doesn't work at all in a VM environment if the folder is in a shared location
....and probably more, but these are the highlights!

There wasn't any joke.

You don't have to work for Microsoft to recognize a Really Bad Idea.

Use the AppData folder to hold per-user settings! You can even use my SHGetFolderPath
Explorer to generate the code you need, so there is no real excuse for using a Win16 idea
that wasn't even a good idea in Win16!
joe
On Wed, 17 Jun 2009 16:47:11 -0700, sg <sg@xxxxxx> wrote:

So, Microsoft still thinks standalone folders with portable .exe's
writing ini/xml files to the GetModuleFileName folder is a bad idea?

I don't get the joke.

Joseph M. Newcomer wrote:
At which point you will have a useless path, because most executables are in protected
directories, and if they aren't, they should be. Security and sanity are both
consequences of such a decision. It is no longer considered sensible to write into the
executable directory, and most systems are configured to prevent this.
joe
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: porting 32-bit to 64-bit on Xeon
    ... IDE to build 64-bit applications while you maintain the same code base ... To set the 64-bit build environment variables, ... Build Environment Window", point to "Set Windows XP 64 Build ... change the folder to the \Microsoft Visual ...
    (microsoft.public.vc.mfc)
  • Re: Temp directory and directory of the .exe file.
    ... Joseph M. Newcomer wrote: ... In any kind of shared environment, it means that every user gets to inherit the most ... Or exercise good judgment and put it in a protected folder? ...
    (microsoft.public.vc.mfc)
  • Re: porting 32-bit to 64-bit on Xeon
    ... IDE to build 64-bit applications while you maintain the same code base ... Set the 64-Bit Build Environment ... Build Environment Window", point to "Set Windows XP 64 Build ... change the folder to the \Microsoft Visual ...
    (microsoft.public.vc.language)
  • Issues in locking down aspnet user security in shared environment
    ... I am trying to lock down file access of some sites in a shared hosting ... environment so that different users can only access their own site's ... enabled site *must* have asp.net user have read access on the folder above ... Is there any whitepaper on how to very securely lockdown asp.net sites in a ...
    (microsoft.public.dotnet.framework.aspnet.security)
Loading