I was going through the source code of a rainmeter skin and i could not understand :
TextShortcut1=Computer
TextShortcut2=Libraries
TextShortcut3=Internet
TextShortcut4=Media Player
TextShortcut5=Control Panel
TextShortcut6=Trash
TextShortcut7=ShutDown
TextPath1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
TextPath2=shell:Libraries
TextPath3=http://google.com
TextPath4=shell:MusicLibrary
TextPath5=::{21EC2020-3AEA-1069-A2DD-08002b30309d}
TextPath6=::{645FF040-5081-101B-9F08-00AA002F954E}
TextPath7=rundll32.exe user32.dll LockWorkStation
Can anyone tell me what
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
::{21EC2020-3AEA-1069-A2DD-08002b30309d}
::{645FF040-5081-101B-9F08-00AA002F954E}
these are
and also how can we get one of these for a specific location from our computer.
Those are CLSID (Windows Class Identifiers). Certain special folders within the operating system are identified by unique strings.
20D04FE0-3AEA-1069-A2D8-08002B30309D is My Computer
21EC2020-3AEA-1069-A2DD-08002b30309d is Control Panel
645FF040-5081-101B-9F08-00AA002F954E is Recycle Bin
Source:
http://www.sevenforums.com/tutorials/110919-clsid-key-list-windows-7-a.html
In response to the comment:
can i have Class Identifiers for any folder on Computer or is it just
the bunch of those.
There isn't much reason for you to add more clsids, since you can just go to other locations by typing the normal path. This is a set list that is in the registry somewhere for special folders that don't really have "paths" like C:\windows does.
what is "shell:Something" is it a cmd command or location
shell: is similar to above. It is a convenient way of accessing special folders. Here is a good site for a list: http://smallvoid.com/article/winnt-shell-keyword.html . It is more of a shortcut for Windows Explorer to access a specific location than it is a command. You cant use them in batch files as far as I know (no command line stuff).
what is %something% like %temp%
Those are environment variables. You can usually count on certain ones existing, but the user can change these. Here is a list of some more: http://en.wikipedia.org/wiki/Environment_variables#Microsoft_Windows
how do they all differ?
Well, basically, they are just different ways of accessing the same thing. Some things are more backwards compatible than others, so you have to make that choice when the time comes. If you know your app is going to be on Windows 7 and above, you can make use of some of the more convenient shell:something ones. But if it needs to run on Windows 2000, you might have to rely more on older stuff like environment variables. Environment variables can also be customized by the user.
Related
I've created a simply toolbox/dashboard in Visual Studio Express in VB for my work that contains links to all of the software and shortcuts we use on a day-to-day basis (see the image below, company name/app names covered to protect the innocent :p)
This was originally created for just me, then I modified the code to work on my co-workers computer. The changes that needed modifying were the addresses for each of the apps. Say, for example, App 1 is directly on the C:\ drive for me, but for my co-worker it is buried in C:\Program Files\blah blah blah. I would have to go in and hard code that path for each and every differing app path, and then if something happens and the path changes, I have to recode it again before deploying it.
What I would like to do it something where the user can modify the path so all I have to do is deploy the executable and the user can modify the path on their own. What would be the best way to accomplish this? Would it be best to have the executable look for a text file to read from/write to? Is there an easier and more effective way to do this? I'm open to any suggestions at this point
If you shellexecute just the program name, it will be looked up in the AppPaths registry key. See HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths. Plus it will open anything. If you want to open a text file a.txt, register it as a.exe. Typing a will run the command (notepad c:\somewhere\a.txt).
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).
I have searched for hours trying to find a reason why certain environment variables are visible in control-panel>system>advance-system-settings>environment-variables. Where are the other variables set and why are they not visible here?
Windows stores the location of per-user special folders under the following Registry key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
The common special folders are specified in the same path under HKEY_LOCAL_MACHINE instead:
HKEY_LOCAL MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
As for why they're not exposed in the GUI like other user variables, I can only speculate. But my guess is that it's because they're not really intended to be changed by the user. The paths are determined by the system, and are intended for internal use by applications.
The variables that are shown in the GUI dialog are the ones that the user can modify.
Others like APPDATA have values that are determined by the system and so Windows doesn't show them in the dialog that allows you to edit them.
For the complete list of Windows environment variables including hidden ones take a look at Environment Variables Wiki: System variables, Hidden variables.
Hope that helps.
I need to create a directory inside a windows users 'home' directory (c:\Documents and Settings\someusername\ or c:\users\someusername\). This directory will exist permanently but will only contain temporary files.
What is is the best location for this directory within the users profile if I want to be a good citizen? I should note that my program will be run by (possibly) non-admin users and will only need access to their own profile, but they must have permission to create the folder.
Using My Documents\NameOfMyApp\ is possible I guess, but that seems intrusive.
Is there a better location for this type of data, and a specific MFC call to access it?
I'd consider using the AppData directory. You can get its location with SHGetSpecialFolderLocation passing it CSIDL_APPDATA; (or a number of alternatives -- nearly every version of Windows adds a new replacement for SHGetSpecialFolderLocation, SHGetSpecialFolderPath, or (often) both).
Take a look at the following win32 calls:
GetUserProfileDirectory
GetAllUsersProfileDirectory
GetDefaultUserProfileDirectory
You probably want to use GetUserProfileDirectory and put your data in a sub-directory with your appname.
You will definitely want to use the function because there is no "\documents and settings" folder on vista and up, they changed to it "\user".
Being a good application citizen, you should use:
[drive]:\Documents and Settings[username]\Application Data[AppName] or
[drive]:\Documents and Settings[username]\Local Settings\Application Data[AppName]
(On Vista and Win7, "Documents and Settings" is replaced, most sensibly with "Users")
The environment variable USERPROFILE will provide the, you guessed it, User Profile Path.
The TEMP path provides the path to the user's individual temp directory
If the temp files aren't user-specific, you could use C:\temp
EDIT: If you are to use a user-specific location, I highly recommend that you use the environment variables (USERPATH on XP and 2000) rather than hard-coding the paths.
-Waldo
P.S. Thank you for asking this. I see bad behaviour from Waaaay too many applications. The root of the C: drive is not where you should be dumping things! At the very least, (test for the presence of, creating if necessary, and) use C:\Temp.
With the environment variable %allusersprofile% I can get the directory where common settings are stored. But most programs store their settings in the sub-folder "anwendungsdaten" (German, application data). Is there a way to get the direct path to this folder? The problem is that its name is language dependent.
Thanks.
Not sure about what programming language you're using, so I'll assume the basic Windows api. In XP you can call SHGetFolderPath with CSIDL_COMMON_APPDATA as a parameter. It looks like Vista and 7 have a new set of functions that do the same thing, you'd probably want to call SHGetKnownFolderPath.
In Windows Forms, you can use the Application.UserAppDataPath property.
I can't see any direct way to get hold of this information directly. If nothing else comes up, the only thing that comes to mind is something hacky that will probably work in 99% of all cases:
Take %USERPROFILE%
Take %APPDATA%
Take %APPDATA% and replace %USERPROFILE% by null. The "rest" should be "/Application Data" or "/Anwendungsdaten" or whatever
Take %ALLUSERSPROFILE%
Add the result of step 3. to it
You should end up with the correct, localized path to the "Appdata" directory of the "All users" profile.
Note: This is untested and I have little experience in this field. But it might work.
I'm not aware of any direct way to get it, but if language is your concern then you could grab the end of %APPDATA%, from the last '\' symbol to the end of the string, and append that to %allusersprofile%.