Cannot overwrite program's existing jumplist

[GoogleCodeExporter]

See issue #57.

Two possibilites:
1. Add items to an existing program jump list
2. Overwrite an existing program jump list outright

#1 requires that I can read jump lists. #2 requires that I detect when the
jump list is being overwritten, and prevent that.

Any ideas as to how I can do #2? I can't figure it out. Are jump lists
applied via window messages? If not, I can't trap those. 
Potentially, I could inject the Explorer.exe process and detect when the
jump list is being read. But I don't know how to detect such a thing.

Ideas???

Original issue reported on code.google.com by mar.mar...@gmail.com on 31 May 2010 at 5:50

[GoogleCodeExporter]

Original comment by mar.mar...@gmail.com on 31 May 2010 at 5:50

• Added labels: Milestone-Release2.0, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

There may also be a folder where jump list tasks (and maybe the list itself???) 
is
stored. I'm pretty sure there's a folder for "pinned" items. Where is it?

Original comment by mar.mar...@gmail.com on 31 May 2010 at 6:00

[GoogleCodeExporter]

Stack Overflow question:
http://stackoverflow.com/questions/2945320/where-is-win7s-jump-list-data-stored

Original comment by mar.mar...@gmail.com on 31 May 2010 at 6:29

[GoogleCodeExporter]

Here's another idea: Mouse hooks! Although it sounds as bad to me as polling...

Basically, detect when a person is right-clicking on the affected program icon. 
When
he does so, call Jumplist.Refresh(); on it, and reload the jump list.

Worth noting is that I THINK JL data might be stored in
AppData\Local\Microsoft\Windows\Usr[something].dat. And that file's infinitely
read/write-locked, so I can't get a handle on it. The thing is, the read/write 
dates
don't match up to actual JL applying.

Original comment by mar.mar...@gmail.com on 1 Jun 2010 at 12:48

[GoogleCodeExporter]

Looking at WinSpy, the Win7 taskbar replaces the old taskbar message 
interfaces, and
MS designed the taskbar "window" to be un-interfaceable. That sure is a pain.

MSTaskListWClass

http://www.google.com/search?q=mstasklistwclass

Original comment by mar.mar...@gmail.com on 2 Jun 2010 at 2:34

[GoogleCodeExporter]

The AHK folks have tried a crack at this

http://www.autohotkey.com/forum/topic22763-60.html

Original comment by mar.mar...@gmail.com on 2 Jun 2010 at 2:35

[GoogleCodeExporter]

Idea #3: DLL redirection, specifically COM redirection.

http://docs.google.com/viewer?a=v&q=cache:GfWW8UBZsgwJ:www.milw0rm.com/papers/10
5+windows+redirect+function+call&hl=en&gl=us&pid=bl&srcid=ADGEESjuBKRnt-Z8F2Gt3o
-NswiHaCPYJl66xgVVZPEHvWj4n4y9sPgj2kclz5ERX4tzg2gKq1U_kAjFzv4GXRlCanzFB2nguK8HhM
BFe3e5WBsOYKrBB4nWC_bnLA68IOQ_OJH1BMoZ&sig=AHIEtbR-K77FSwiavBJHoaMyKX_1SafIXw

Jump lists are applied via ICustomDestinationList::CommitList(). If I could 
forward
the rest of that interface on my custom DLL, and just suppress CommitList for 
an app
that calls it, then problem solved! Doesn't solve issue #57, but that's a hack 
anyways...

The ? is, how do I do this for COM interfaces?

MSDN DLL/COM redirect: 
http://msdn.microsoft.com/en-us/library/aa375142%28VS.85%29.aspx

ICustomDestinationList:
http://msdn.microsoft.com/en-us/library/dd378399%28v=VS.85%29.aspx

Original comment by mar.mar...@gmail.com on 2 Jun 2010 at 4:03

[GoogleCodeExporter]

IAT (Import Address Tables) may work too.

http://sandsprite.com/CodeStuff/IAT_Hooking.html
http://en.wikipedia.org/wiki/Portable_Executable#Import_Table

The most informative article on hooks I've seen:
http://www.codeguru.com/cpp/w-p/system/misc/article.php/c5667

Looks like a good source: http://unlmtd.wordpress.com/2007/08/21/iat-hooking/
* Does this mean "listen for window messages, and then intercept a function 
call and
return our own function?"

Original comment by mar.mar...@gmail.com on 2 Jun 2010 at 4:11

[GoogleCodeExporter]

Original comment by mar.mar...@gmail.com on 2 Jun 2010 at 4:14

• Added labels: Comment-NeedsComment

[GoogleCodeExporter]

Issue 65 has been merged into this issue.

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:12

[GoogleCodeExporter]

Issue 72 has been merged into this issue.

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:29

[GoogleCodeExporter]

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:37

• Added labels: Comment-Needs

[GoogleCodeExporter]

See issue 76. MRUs and pinned lists are stored under 
%appdata%\Microsoft\Windows\Recent\AutomaticDestintinations. Still no word on 
where tasks and custom categories are stored, however.

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:38

• Removed labels: Comment-NeedsComment

[GoogleCodeExporter]

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:48

• Added labels: Milestone-Release0.7
• Removed labels: Comment-Needs, Milestone-Release2.0

[GoogleCodeExporter]

C:\Users\MarcoZ\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations

AutomaticDestinations is where MRUs are stored; CustomDestinations is where 
custom data is stored.

Though what's weird is, some programs like IE and Firefox update their OWN cdms 
list, while the JLE cdms is untouched. Should see what happens with Chrome.

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:59

[GoogleCodeExporter]

Seems the behavior differs on a case-by-case basis:

* IE and Firefox: Updates their own cdms files; JLE cdms files are untouched; 
jump list is not affected
* Chrome: Can't test - no jump list?
* foobar2000: JLE cdms file is modified; own cdms file is modified; jump list 
reverts to using own cdms file. Maybe foobar2000 changes its appID back /after/ 
T7EBackground does?

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 1:53

[GoogleCodeExporter]

* Windows Live Mail: Same as IE and Firefox: own cdms file is changed, but jump 
list is untouched.

A catch-all behavior may be to,
1. Back up the original cdms and adms files (problem: how to find out what they 
are?)

2. Delete the originals. Make hard links (not symlinks) that point to the new 
cdms and adms files

3a. Lock the new cdms files so that no changes can be made to them (but keep 
the adms files modifiable; they ARE MRU lists after all!)
** Setting the adms file to "Read Only" does not work: the jump list does not 
display the MRU at all.
** Setting the cdms file to "Read Only" DOES work: but the program throws an 
"Access Denied" exception. Might be worth doing FileWatcher for sloppy-coded 
programs.

3b. Set a FileWatcher and copy back any cdms files that are changed.
** How much battery power will this take? IE, Firefox, Chrome, and other 
programs that make their own custom Frequent/Recent lists will be changing the 
cdms file A LOT if the original is hardlinked to the JLE cdms file. Maybe 
provide an opt-in option: "Check this box if your jump list is being 
overwritten"?

TL;DR -- 
* For custom lists, hardlink the old cdms file to the new one and watch for any 
changes. Even if the window appID changes to reflect the old cdms file, it'll 
still be using the new data (although this is sloppy: appID should be watched 
for too.)
* For MRUs, hardlink the old adms file to the new one, and allow changes. The 
jump lists for both shortcuts will be synchronized.
* When de-regging a program, copy back the old cdms file to the original 
location. Delete the new cdms file. For adms, copy the new adms file to the old 
location, and delete the new adms file.

Maintenance of the Custom/Automatic directories might be worth a separate 
issue. This could get messy if not managed correctly.

Original comment by marcoaza...@gmail.com on 27 Mar 2011 at 2:31

[GoogleCodeExporter]

Opera 11: Modifies the cdms file that corresponds with its appID (e.g. the 
modified cdms is untouched when using JLE appID; when using original appId, JLE 
cdms is untouched)

Original comment by marcoaza...@gmail.com on 27 Mar 2011 at 2:50