Closed Bug 573349 Opened 14 years ago Closed 13 years ago

windows 7 Contacts can't be displayed because wap32.dll loading fails

Categories

(Thunderbird :: Address Book, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 573348

People

(Reporter: wech, Unassigned)

Details

User-Agent:       Opera/9.80 (Windows NT 6.1; U; de) Presto/2.5.24 Version/10.54
Build Identifier: 3.05 and latest trunk (2010-06-19)

The interface still exists, but the path to the wab32.dll read from the registry contains a environment variable specifying the common files directory ("%CommonProgramFiles(x86)%\\System\\wab32.dll"), which prevents LoadLibrary to access the dll.

After applying the described patch, accessing the windows contacts in thunderbird works again.

Reproducible: Always

Steps to Reproduce:
1. setup Outlook Express as contacts folder http://kb.mozillazine.org/Using_Outlook_(Express)_contacts_with_Thunderbird_or_Mozilla_Mail
2. restart thunderbird and open addressbook

Actual Results:  
new address source is not being displayed

Expected Results:  
windows contacts should be displayed

The interface still exists, but the path to the wab32.dll read from the registry contains a environment variable specifying the common files directory ("%CommonProgramFiles(x86)%\\System\\wab32.dll"), which prevents LoadLibrary to access the dll.

it can easily fixed trough the following patch, which replaces the variable with the real value:

comm-central\mailnews\addrbook\src\nsWabAddressBook.cpp
Line 89

   if (keyHandle) { RegCloseKey(keyHandle) ; }
+
+	//resolve environment var in path from registry like "%CommonProgramFiles(x86)%\\System\\wab32.dll" on windows 7
+		if( wabDLLPath[0] == '%' ) {
+		TCHAR tmpPart[MAX_PATH];
+		LPTSTR pEnvVarNameEnd = strchr( wabDLLPath+1, L'%' );
+		if( pEnvVarNameEnd ) {
+			*pEnvVarNameEnd = 0; //terminate env var name
+			LPCTSTR pEnvVal = getenv(wabDLLPath+1);
+			strcpy(tmpPart, pEnvVarNameEnd+1); //save string part after env-var-name
+			strcpy(wabDLLPath, pEnvVal != NULL ? pEnvVal : tmpPart );
+			strcat(wabDLLPath, tmpPart );
+		}
+	}

    mLibrary = LoadLibrary( (lstrlen(wabDLLPath)) ? wabDLLPath : WAB_DLL_NAME );
This bug also affects OpenOffice.org (OOo) which uses SeaMonkey code for its address-book access. See http://www.openoffice.org/issues/show_bug.cgi?id=91079 for an OOo description of it.

Christoph's diagnosis of the reason for the problem seems exactly right to me. In the OOo issue description I suggest a work-round (patch your Windows Registry to use the use the full pathname rather than an environment variable). I suggest the patch proposed is not ideal, however.

I think the code change suggested is

* over-complicated, because it repeats code packaged by Microsoft, and

* fragile, because it translates only one environment variable at the start of the registry value.

I suggest a better fix (sorry, I cannot at present compile this into a test build, so this is not a patch) to replace all the registry access part of nsWabAddressBook::LoadWABLibrary with

    const LSTATUS  ss = SHRegGetValue( HKEY_LOCAL_MACHINE, WAB_DLL_PATH_KEY, NULL,
            SRRF_RT_REG_SZ, NULL, wabDLLPath, &byteCount );
    if (ERROR_SUCCESS == ss)
        ...

This uses Microsoft's SHRegGetValue function - available from Windows XP SP2 - to do all the work, including translating environment strings where appropriate. SHRegGetValue is obsolete from Windows Vista, but still supported and working; from Vista onwards, RegGetValue is preferred.

Alternatively, use ExpandEnvironmentStrings() in place of the block starting if( wabDLLPath[0] == '%' ). This should be applied only if the registry value has keyType == REG_EXPAND_SZ.

If neither of those is appropriate, the patch code above should be altered to test for REG_EXPAND_SZ type and then loop expanding every %name% to its value, not just the first value at the start of the path.

[When I applied the work-round to fix my copy of OOo 3.3, it also cured Nokia's Ovi Suite, so either Nokia use Mozilla's library, or have repeated the same registry access error.]
See also bug 573348 which suggests the same patch. I haven't repeated my comments there, just referred to this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.