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???

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?

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

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.

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

The AHK folks have tried a crack at this

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

Idea #3: DLL redirection, specifically COM redirection.

http://docs.google.com/viewer?a=v&q=cache:GfWW8UBZsgwJ:www.milw0rm.com/papers/105+windows+redirect+function+call&hl=en&gl=us&pid=bl&srcid=ADGEESjuBKRnt-Z8F2Gt3o-NswiHaCPYJl66xgVVZPEHvWj4n4y9sPgj2kclz5ERX4tzg2gKq1U_kAjFzv4GXRlCanzFB2nguK8HhMBFe3e5WBsOYKrBB4nWC_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

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?"

Issue 65 has been merged into this issue.

Issue 72 has been merged into this issue.

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.

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.

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?

• 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.

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)