I want to create generic shortcuts in Windows 10 using a target path
extension of the shell path, something like
%windir%\explorer.exe shell:AppData ..\Local\Temp
%windir%\explorer.exe shell:AppData works by itself, takes me to roaming userfiles.
I could use
%windir%\explorer.exe shell:UsersFilesFolder
which would take me to %UserProfile% and append from there (if I could find out how) only it would be handy to be able to go up a level if possible as well.
I can't work out
How to append a further couple directories into the shortcut target path
How to go up one directory first (..?)
What is the syntax to make this work?
First of all, %Temp% might not be the same as %LOCALAPPDATA%\Temp!
The way to create a perfect shortcut to %Temp% is not that easy, ideally the .lnk should only contain a EXP_SZ_LINK:EXP_SZ_LINK_SIG block with the %Temp% string. You have to manually delete the ItemIdList block to get a .lnk file like that. %Temp% is extra complicated because it does not have a special folder canonical name you can use with the shell: protocol.
I don't believe the shell: protocol supports .. nor . path components.
shell:AppData ..\Local is also wrong because the local appdata folder might be somewhere else (< Windows Vista used different names) and a better command would be %windir%\explorer.exe "shell:LocalAppData" (and in turn %windir%\explorer.exe "shell:Local AppData\Temp") but all of those commands have other issues.
First of all, Explorer might not be the users shell and you risk not obeying the users preferences.
Another problem is that a .lnk file contains the attributes of its target and because the link actually points to a .exe file your .lnk file will not have the FILE_ATTRIBUTE_DIRECTORY bit set for its target attribute and the shell will not understand that it points to a folder. A .lnk that points to a folder will sometimes open in the same window when navigating the shell instead of opening a new file browser window.
The .lnk binary format is documented and by breaking the rules a little bit I have been able to create a link that points to a file/folder inside a special shell folder by combining a EXP_SPECIAL_FOLDER block with a manipulated ItemIdList but for whatever reason this trick does not work for deeper paths.
A EXP_SPECIAL_FOLDER block and a empty ItemIdList is the only way to create shortcuts to special folders that is guaranteed to work on all systems but you have to create it manually, the IShellLink implementation adds system specific blocks that might break things if you try to use the link on another system.
The .lnk format has not changed much since Windows 95 and there is simply no easy way to create shortcuts relative to special folders that also work when they are copied to other systems. The relative path string in a .lnk is relative to the .lnk file itself and is not helpful in this case.
I would recommend that you simply create the .lnk on the target system in your installer/application and let IShellLink fill in as much information as possible behind your back.
I am trying to open a .chm file.
I downloaded the source, extracted it, and double clicked on Waffle.chm and clicked "Open" but no matter what element in the chm file I click, I get the message:
Navigation to the webpage was canceled.
What you can try:
Retype the address.
What's going on here?
Summary
Microsoft Security Updates 896358 & 840315 block display of CHM file contents when opened from a network drive (or a UNC path). This is Windows' attempt to stop attack vectors for viruses/malware from infecting your computer and has blocked out the .chm file that draw data over the "InfoTech" protocol, which this chm file uses.
Microsoft's summary of the problem: http://support.microsoft.com/kb/896054
Solutions
If you are using Windows Server 2008, Windows 7, windows has created a quick fix. Right click the chm file, and you will get the "yourfile.chm Properties" dialog box, at the bottom, a button called "Unblock" appears. Click Unblock and press OK, and try to open the chm file again, it works correctly. This option is not available for earlier versions of Windows before WindowsXP (SP3).
Solve the problem by moving your chm file OFF the network drive. You may be unaware you are using a network drive, double check now: Right click your .chm file, click properties and look at the "location" field. If it starts with two backslashes like this: \\epicserver\blah\, then you are using a networked drive. So to fix it, Copy the chm file, and paste it into a local drive, like C:\ or E:. Then try to reopen the chm file, windows does not freak out.
Last resort, if you can't copy/move the file off the networked drive. If you must open it where it sits, and you are using a lesser version of windows like XP, Vista, ME or other, you will have to manually tell Windows not to freak out over this .chm file. HHReg (HTML Help Registration Utility) Utility Automates this Task. Basically you download the HHReg utility, load your .chm file, press OK, and it will create the necessary registry keys to tell Windows not to block it. For more info: http://www.winhelponline.com/blog/fix-cannot-view-chm-files-network-xp-2003-vista/
Windows 8 or 10? --> Upgrade to Windows XP.
"unblocking" the file fixes the problem. Screenshot:
Win 8 x64:
just move it to another folder or rename your folder (in my case: my folder was "c#").
avoid to use symbol on folder name. name it with letter.
done.
In addition to Eric Leschinski's answer, and because this is stackoverflow, a programmatical solution:
Windows uses hidden file forks to mark content as "downloaded". Truncating these unblocks the file. The name of the stream used for CHM's is "Zone.Identifier". One can access streams by appending :streamname when opening the file. (keep backups the first time, in case your RTL messes that up!)
In Delphi it would look like this:
var f : file;
begin
writeln('unblocking ',s);
assignfile(f,'some.chm:Zone.Identifier');
rewrite(f,1);
truncate(f);
closefile(f);
end;
I'm told that on non forked filesystems (like FAT32) there are hidden files, but I haven't gotten to the bottom of that yet.
P.s. Delphi's DeleteFile() should also recognize forks.
The definitive solution is to allow the InfoTech protocol to work in the intranet zone.
Add the following value to the registry and the problem should be solved:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001
More info here: http://support.microsoft.com/kb/896054
Go to Start
Type regsvr32 hhctrl.ocx
You should get a success message like:
" DllRegisterServer in hhctrl.ocx succeeded "
Now try to open your CHM file again.
other way is to use different third party software. This link shows more third party software to view chm files...
I tried with SumatraPDF and it work fine.
I fixed this programmatically in my software, using C++ Builder.
Before I assign the CHM help file, Application->HelpFile = HelpFileName, I check to see if it contains the "Zone.Identifier" stream, and when it does, I simply remove it.
String ZIStream(HelpFileName + ":Zone.Identifier") ;
if (FileExists(ZIStream))
{ DeleteFile(ZIStream) ; }
There are apparently different levels of authentication. Most articles I read tell you to set the MaxAllowedZone to '1' which means that local machine zone and intranet zone are allowed but '4' allows access for 'all' zones.
For more info, read this article:
https://support.microsoft.com/en-us/kb/892675
This is how my registry looks (I wasn't sure it would work with the wild cards but it seems to work for me):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"
As an additional note, weirdly the "UrlAllowList" key was required to make this work on another PC but not my test one. It's probably not required at all but when I added it, it fixed the problem. The user may have not closed the original file or something like that. So just a consideration. I suggest try the least and test it, then add if needed. Once you confirm, you can deploy if needed. Good Luck!
Edit: P.S. Another method that worked was mapping the path to the network locally by using mklink /d (symbolic linking in Windows 7 or newer) but mapping a network drive letter (Z: for testing) did not work. Just food for thought and I did not have to 'Unblock' any files. Also the accepted 'Solution' did not resolve the issue for me.
Moving to local folder is the quickest solution, nothing else worked for me esp because I was not admin on my system (can't edit registery etc), which is a typical case in a work environment.
Create a folder in C:\help drive, lets call it help and copy the files there and open.
Do not copy to mydocuments or anywhere else, those locations are usually on network drive in office setup and will not work.
I am trying to learn how to write firefox extensions. I download an HelloWorld example from here but I can't figure out how to register it.
I found my profiles extension folder (Easy since I use the latest Firefox version) but couldn't really understand what is this "Pointer file" that I need to create (tried a shortcut but it didn't work).
What is this "Pointer File"?
How can I register it correctly?
I am using Win 7 if matters.
Thank You.
You have to create a file in the extensions folder with the ID of the add-on as name (e.g. helloworld#mozilla.doslash.org). This file should contain only one line which is the absolute path to the folder where the add-on is contained (e.g. C:\\my\path\to\addon (or however windows paths look like)).
The add-on name is located inside of the install.rdf file. Usually, it's a GUID string, but for the demo it will look like an email address.
The filename will need to match that exactly and be free of any .txt extensions, so be careful your text editor doesn't automatically give it an extension.
I'm implementing a custom URL handler in .NET. To test this, I have created a few different .url files and put them on my Desktop. This generally works fine, but behaves oddly if I change the file's contents, specifically the URL= line. Doing so has no effect — the old URL continues to be opened. Renaming the file, however, works. The file looks like this:
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,0
[InternetShortcut]
URL=myCustomScheme://some/url/pointing/somewhere
IDList=
All shortcuts I create through New → Shortcut receive the same UUID, so changing that probably won't help.
Is there some internal .url file / URL mapping cache in Windows?
I have a reason to believe that URL files are interpreted by some Internet Explorer component at the time of creation (not biblical). They are only interpreted initially, the first time the file is created. Any modifications to the URL file later on will not be committed. This is because the shortcut is not stored in the file. This is why the file can be modified later on so that it becomes empty, as a 0 byte file and the URL file will appear to be working anyway. The shortcut data is stored in the "Web Document" field as a file property in the NTFS file system. The file merely serves the purpose of pointing to it. You might be able to modify these property fields programmatically, which would supposedly "edit the file". It's a painful exercise just to edit what appears to be a simple text file.
Additionally, once a file name has been used for a URL file, it cannot be reused for new files, no matter what disk or path you save it to. So you have to keep assigning unique file names, never used previously, for each new URL file you create. This has to do with how Internet Explorer caches web content. It remembers what file names have been used already and maps those names to previously defined URL addresses. To reuse a name (or when you run out of ideas for new and unique file names) you have to clear Temporary Internet Files.
Windows 7: %localappdata%\Microsoft\Windows\Temporary Internet Files
Windows 8: %localappdata%\Microsoft\Windows\INetCache
To directly answer your question: yes, it does.
Windows 7 Caches your Filenames and sometimes, as you said, the filenames in specific locations.
Start regedit and search for the following
HKEY_USERS\S-1-5-21-x-x-x-x\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
where S-1-5-21-x-x-x-x is your currently logged in User.
There you can see that most (or all?) files have been cached which you have ever accessed.
Maybe you can also deactivate the MUICaching programatically. Maybe this site helps you: Disable Caching
I had a similar issue, and it turns out the culprit was Firefox.
If by chance your web browser is Firefox, your cache directories may be corrupted.
You can either create a new Profile, or take your chances cleaning things out of C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\
I've found my desktop .url shortcut contents cached in %LocalAppData%\Microsoft\Windows\Caches.
There are a few (several?) files with filenames like {<SOME_GUID>}.<x>.ver0x<XXXXXXXXXXXXXXXX>.db. Two of them had the .url files cached.
Unfortunately, I've found no information on what they are or how to refresh them. Everybody just deletes them as part of some cache clean-up operation.
I want to implement a File Explorer, It is different from a normal file explorer, it first scan file system and store information into database, them read file system information from Database, and display them, I need to store the icons of the file, how can I do this? Is there any Windows APIs?
Many thanks!
SHGetFileInfo can get a handle for the icon of a file.
You need to use SHGetFileInfo. This looks like a pretty good example for .NET.