I need to setup a script in group policy that we be used in different regions of the world. Are environmental variables such as %ProgramFiles% language specific? I'm hoping that a script of %ProgramFiles% can be used both in spain and france even though their language is setup for the specific regions.
Thanks
No. They are not language specific.
When you use %ProgramFiles% the operating system will check in Windows registry where %ProgramFiles% maps to. This mapping is done during Windows installation and therefore using the placeholder %ProgramFiles% you'll have a language/country agnostic solution.
No, but do watch out. I encountered a application that looked in "c:\Program Files" (hard coded, apparently). Tried to run it on a German (maybe it was French? Don't recall) version of Windows. "Program Files" is something else in German - I don't recall what, but it didn't parse as expected and of course the program failed.
Related
So i recently got myself into a sticky situation, it seems like windows 'forgot' about a program I had installed (some drives changed letters / not really sure what happened).. I could find files that it created, but in 'Programs' and 'Add/Remove Programs' it is not there.
Also, when I use the 'programs' installer, it says it cant install because it exists already (to some extent), and I can un-install because windows doesn't know it exists.
BUT! I have an executable of the 'program' that works.
So I am wondering what the difference is between an executable, and what windows considers to be, and keeps track of, a 'program'.
This is definitely the kind of program that would show up in 'add/remove programs', as I have several other very similar ones from the same company that show up there, and I know it used to show up there.
I am not looking for wikipedia answers, I am interested in what exactly a 'program' is. What are the necessary pieces that make up a 'program' as far as windows is concerned?
For a program to show up in "add/remove programs", it needs to be installed. Typically, this is done through an installer that takes care of registering the program with windows and modifies the environment so that the program functions properly.
It may modify the registry to store user preferences for example...
When you have just an executable, it's not necessarily installed. It may be standalone.
Some programs don't absolutely need to be installed even if it's the canonical way to add a program in the Windows system. That's why it may work.
Another executable may fail because it relies on modifying the state of the system to work properly.
I hope it helps :)
Actual question
How can I "redirect" (symbolic links?) or temporarily change the values of %HOMEDRIVE% and %HOMEPATH% (maybe based on two batch scripts that change the values when I start working at the machine and reset everything after I'm done)?
Background
A lot of Windows programs pick up either system variable %USERPROFILE% or a combination of %HOMEDRIVE% and %HOMEPATH in order to figure out where a user's "home" directory is that they need to use (e.g. C:\Users\JohnDoe). Being a fan of the philosophy of portable apps (see at the bottom what I mean by that), I'm wondering if I could somehow make my home directory portable, i.e. have it point to a directory on a portable device. Or, in other words, I would like to make it "dynamically changeable".
What I tried
I've read a bit about Set and Setx and tried this:
Finding out what the current variable values are:
C:\Users\JohnDoe> Set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\<username>
Set them:
C:\Users\JohnDoe> Setx HOMEDRIVE "d:"
C:\Users\JohnDoe> Setx HOMEPATH "\home"
That creates HOMEDIR and HOMEPATH as user-specific environment variables (see Control Panel >> System >> Environment Variables). But the "global ones" did not change and e.g. RStudio will not recognize the user-specific variables (still writes to C:\Users\JohnDoes\[...]).
C:\Users\JohnDoe> Set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\<username>
Portable Apps
For example, see PortableApps.com or simply think "software that simply has been installed to a portable device instead of C:\Program Files\<app-name>". The latter works a treat for me for programs that don't really care about %HOMEDRIVE% and %HOMEPATH% (e.g. Eclipse or R).
Some others (e.g. Git) just need to be tweaked a little bit (e.g. see this post).
Yet some others (e.g. RStudio) run in fact smoothly off the portable device, but write stuff to the user's "home" directory. That's the kind of software that I would like to tell to use a directory on my portable device instead.
While you can change the environment variables this wont work for all applications, as there is also a Shell folder API in Windows which gives various user specific locations.
So it is better to use the actual Windows method to change the profile. And no this will not be possible to be a mobile device as it expects a stable and available location for the registry database of the user.
I think when setting up windows (and with sysprep) one can specify a location for the }users} folder (different drive). The quickest thing to move are the special library folders, you can change their location in the Explorer Properties view.
I have my own installer program which I use to install several applications I have written.
I have been updating this program to avoid the application's data file updates going to the user's VirtualStore, as I read this was a "bad thing". I am doing this by storing the program and common data files separately in their correct locations, instead of sticking everything in Program Files like we used to do in the days of XP.
I am also now using SHGetFolderPath (yes, it's deprecated, but I still need to support my XP users), to get known folders instead of trawling the registry, which is another "bad thing" (I read).
The next thing I was trying to do was rewrite the installer code to avoid registry redirection to Wow6432Node when writing stuff to HKLM, as I thought this was another "bad thing".
However, although I could put the application specific stuff that goes there (like the install folder, if the user decides to install in other than the default), the killer is the need to put the uninstall info in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall. For 32-bit stuff running on a 64-bit system, this is redirected to Wow6432Node. I don't see any way round this - is it in fact possible?
UAC registry redirection could reasonably be described as a "bad thing" because it is designed specifically to provide compatibility with improperly written software, i.e., software that assumes it is going to be run with administrator privilege.
WOW64 registry redirection is a different beast; it's designed to provide compatibility with properly written 32-bit software. If your software is 32-bit, and has no specific need to be 64-bit aware, there's nothing wrong with letting it run in the emulation environment as-is, including allowing registry settings to be redirected to Wow6432Node.
You can bypass WOW64 registry redirection if necessary, but you shouldn't do this arbitrarily, only if there is a specific reason. If WOW64 redirection worries you, the only good alternative is to provide a 64-bit version of your program.
This is a very "BAD THING" !
Microsoft solves a security problem by hiding thing at another place !
I've created a programm to ask the user for some additional parameters (language, directory for lessons) during installation of the app. I tested the programm profoundly, and the registry entries were made perfectly. However during setup the entries were hidden at some strange place!
If Microsoft wants to redirect these enties it should at least be some option to be set.
Never hide things, and think they will not notice, because it's transparant.
Doing this properly would involve an option to be set, so users are aware of the redirection !
I store the MRU of logins to my application in a file called login.ini and I save it in widnows application folders.
I noticed that on some systems — I don't know why; I cannot find a common cause — the user cannot create the file, whereas it creates all other files in the same folder.
The only reason I can think of is that some antivirus/windows setting/... doesn't allow this particular user to create the file on this system.
I solved the problem by renaming the file and it seems ok, but I'd like to be sure. Does anyone know more?
Note for bounty:
This is a related question I asked that details a little more what I am doing.
A little Google-fu turns up that other Windows developers have sucessfully created login.ini for their programs, and others use it in a third-party Windows login management program, so I would expect that its "reservedness" is partially dependent on its location in the file system (i.e. in the system files). However, I don't think the name "login.ini" is a system-wide reserved name, no.
I think you're right - certain antivirus programs MAY be messing with the creation of that file, as it is a fairly likely candidate imho for a virus filename. It looks as if it may already have been used for that purpose somewhere (apparently outside of the US), tho don't quote me on that.
So, if a different name works for you, I'd go with that. :)
Anti-virus is a definite possibility for messing with your file. Stuff like that happened all the time to me when I was using Norton.
'login.ini' is not a system-wide reserved name, it would only mess things up with the OS if you had it in the (assuming your drive is C:) C:\WINDOWS or C:\WINDOWS\System32 directories.
If you just have the file in an application files directory (like C:\Program Files or C:\All Users\Application Settings and such) it shouldn't interfere with the system.
If you determine that anti-virus is a definite problem, you could change the name to something like loginData and maybe make up a new file extension if you want to (assuming you are just going to read the file from a program, where the extension doesn't matter. otherwise stick to a recognized file extension)
I want to differentiate between Windows XP and Windows 7 in a XML file. Thought i will use an environment variable for it inside the XML.
However I could not find any system environment variable defined in windows that gives this information.
I see the %OSTYPE% variable but it is only available in Windows 7. It is not defined in XP.
Is there anyway i could do this?
Note that i would like a solution which purely depends on system environment variables. I do not want to create new variables based on executing some command, because i want to use this variable in a XML file.
Near as I can tell the environment variable in XP is "OS".
OS: Lists the name of the operating system. (Windows XP and Windows 2000 list the operating system as Windows_NT.)
See:
http://www.techrepublic.com/article/understanding-windows-xps-environment-variables/5986211
No exactly preset environment variables but...
This article is from Microsoft and it refers to a program called gettype.exe, I don't know if this is a built-in or not. I'm not on Windows to test. Anyway, maybe it helps you.
There's also ver which looks built-in - here's an example script using that.