Concept behind fixing x64 sync.

So, I’m going to share my concept here, and see if it does flesh out. If I don’t have time, hopefully someone else can be inspired by it and try and poke it. (That’s how I came up with the patch in the first place. Seeing someone else’s fix to the problem, looking at it, deciding there was an even better way, and actually fixing that)

Here’s the basic concepts:

Hotsync plugins have two main parts: The file, and a registry key.

The file was the easy part. It just checks for the specific version numbers, and calls it good.

However, there’s two problems when you’re running Office in x64 mode.

Problem 1: the Palm Hotsync files will be in Program Files (x86) and Office will be in regular Program Files. If it’s looking for a specific Office file in a specific location, it won’t find it, due to sandboxing of x86 programs to maintain compatibility.

Problem 2: The registry has a separate section for x64 and x86 apps.

What we know: Hotsync looks at a version number in outlook.exe itself. How? That’s the way the patches that inspired my patch worked. People would hex-edit outlook.exe to change the version number and that would fix it (Until Windows Update updated Outlook).

Knowing this, the assumption can be made that there is a possibility that it either has problems seeing the version number in x64 versions of Outlook, or it cannot see Outlook at all. I’m still looking for a program that would allow me to walk through a program’s steps, one-by-one until it’s done what it needs to do, but I have a feeling that is part of it. I’ve never actually looked at the whole contents of the Hotsync Conduit file either, so there could be a hard-coded path in there, or other problems.

What else we know: It doesn’t work with Office Click-To-Run apps. This further strengthens my belief that it could be something to do with file paths. I will have to dig into this more, but since I don’t use CTR apps, it’ll be a bit more difficult. Maybe at a future date.

How to test things:

For file paths: install Office to a custom path and see if it still works. If it does, then we know it’s looking for a registry key, if it doesn’t, then we know it’s looking for a file path. (I’m hoping it’s a registry key, because otherwise it would be a mess to deal with logistically, along with also being a million times worse from a programming standpoint). If it is a registry key, there are a few things I would need to test.

For registry keys: Is it a specific key it is looking for? If it is looking for something like Path_to_Exe, it should be simple enough to just create a new key pointing to the x64 key.

If it is something more complex, it will take quite a bit of debugging.

I’m going to use a program that detects registry changes between runs, get Office installed, and then install Hotsync and the plugin, and run a scan after each install. Compare registry edits made and start hunting. I believe there is a systernals program that would allow me to see direct registry accesses by different programs. This would be useful to see where Hotsync is reading to when it starts and see if it’s looking for specific keys.

After doing the initial run (In a VM), I’ll do another run after installing Office in a different file path. Hopefully finding the location keys. One of these keys should hopefully help me locate what Hotsync is looking for.

That’s all the ideas I have right now. If I find more, I’ll add them.


About Author
Someone who feels the need to help others using the information that I have discovered. If someone else finds it useful, I'm more than happy to have helped.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: