UltraCompare on Windows needs Microsoft Word to convert temporarily binary stored Microsoft Word documents to RTF respectively plain text for text comparison.

I have UltraCompare Professional installed on computers with Office 97, 2003, 2007 and 2010. The comparison of *.doc and *.docx files with UltraCompare Professional works on those computers. I don't have any computer with a newer Office. (By the way: Best MS Office ever is Office 2003 in my point of view for many reasons.)

I could see with Sysinternals Process Monitor that UltraCompare queries on comparing MS Word documents first the registry key HKEY_CURRENT_USER\Software\Classes\Word.Application and in case of this key not existing as by default on HKEY_CLASSES_ROOT\Word.Application which usually exists on MS Word being installed to get the CLSID value.

The CLSID value is for MS Word 2007 and 2010: {000209FF-0000-0000-C000-000000000046}

So 32-bit UltraCompare running on 32-bit Windows queries next HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046} and 32-bit UltraCompare on 64-bit Windows queries HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-C000-000000000046}.

After a few more registry queries UltraCompare knows finally where (last registered) Office is installed with the directory which should contain WINWORD.EXE which is executed by UltraCompare for the conversion of the MS Word files to compare.

I don't know if MS Word 2016 registers itself like former versions of MS Word in Windows registry. So I don't know if this registry queries are in general also successful on Windows computers with Office 2016 installed, but I think so.

A possible problem could be that architecture of installed UltraCompare is different to architecture of installed Microsoft Office which could be a problem because of registry redirector. The class identifier key {000209FF-0000-0000-C000-000000000046} contains the subkey InprocHandler32 which means on 64-bit Windows with either 64-bit or 32-bit Office installed that there is HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046} for 64-bit applications and HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-C000-000000000046} for 32-bit applications which are really different and no redirection is taking place by registry redirector.

So on 64-bit Windows finding the installation location of 64-bit Office by 32-bit UltraCompare might fail as well as finding installation location of 32-bit Office by 64-bit UltraCompare. I don't know if that is really occurring as I'm using on my 64-bit Windows machines 32-bit UltraCompare and 32-bit MS Office.

Well, in my point of view it would be better to get full path to WINWORD.EXE if being installed at all by querying the standard value of registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\Winword.exe which would be easier and would work independent on architecture of Windows, Office and UltraCompare.

However, all I wrote above is what I think according to what I see in Process Monitor log on running MS Word files compare with UltraCompare and what I know from registry redirector handling and is speculative for that reason. Please ask IDM support by email for a definite answer.