mDN Wrapper

Implementation Method - Wrapper DLL

Positioned between the application and the original DLL, the wrapper DLL hooks the application DLL call and operates different processing than that in the original DLL.

The application DLL call is passed to the wrapper. The wrapper performs additional processing and calls the original DLL entry. Next, the processing result of the original DLL is returned to the wrapper and the wrapper again performs additional processing, then the final result is returned to the application.

With mDN Wrapper, to provide name resolution of multilingual domain names, a wrapper DLL is provided for the following WINSOCK DLLs:

WSOCK32.DLL (WINSOCK V1.1)

WS2_32.DLL (WINSOCK V2.0)

Note : The 16-bit version of WINSOCK (WINSOCK.DLL) is not supported.

APIs Subject to Processing

mDN Wrapper performs additional processing on only those APIs that are associated with WINSOCK name resolution. The following WINSOCK APIs are subject to processing.

When both the WINSOCK 1.1 and WINSOCK 2.0 APIs exist:

gethostbyaddr

gethostbyname

WSAAsyncGetHostByAddr

WSAAsyncGetHostByName

When only the WINSOCK 2.0 API exists:

WSALookupServiceBeginA

WSALookupServiceNextA

WSALookupServiceEnd

Some applications independently resolve domain names without using these APIs. For example, nslookup internally generates and interprets DNS requests independently. Naturally, mDN Wrapper does not provide multilingual domain name support to these applications.

On the other hand, mdnsproxy multilingalizes requests and responses of DNSs on the network, thus these applications can support multilingual domain names. It is recommended that you change which one is used to suit the situation.

NOTICE: WINSOCK 2.0 also provides WSALookupServiceBeginW and WSALookupServiceNextW for WIDE CHARACTER based name resolver APIs, however, these are not wrapped. These APIs are internationalized for Microsoft specifications and therefore should be used within that framework. We determined that it is dangerous to use mDN Kit to convert these APIs to another multilingual framework.

APIs Not Subject to Processing

Regarding WINSOCK APIs other than those above, mDN Wrapper does not do anything and calls the original WINSOCK API.

mDN Wrapper is designed to copy and rename the original WINSOCK DLL and call it.

wsock32.dll

Name is changed to wsock32o.dll

ws2_32.dll

Name is changed to ws2_32o.dll

A wrapper DLL is created with the same name as the original WINSOCK DLL. Therefore, when mDN Wrapper has been installed, their names are as follows:

wsock32.dll

mDN Wrapper for WINSOCK V1.1

ws2_32.dll

mDN Wrapper for WINSOCK V2.0

wsock32o.dll

Original WINSOCK V1.1 DLL

ws2_32o.dll

Original WINSOCK V2.0 DLL

Asynchronous API

Conversion of domain names must be carried out in the following sequence:

When request is sent to DNS

Local encoding is converted to DNS encoding

When response is received from DNS

DNS encoding is converted to local encoding

With synchronous API, conversion from local encoding to DNS encoding is performed before the original API is called and conversion from DNS encoding to local encoding is performed when control is returned from the original API.

However, the following WINSOCKs API are asynchronous APIs and control is returned before response is received from the DNS.

WSAAsyncGetHostByAddr

WSAAsyncGetHostByName

With those APIs, the completion of name resolution is notified via the message to Windows. For that reason, in order to convert from DNS encoding to local encoding, the wrapper needs to hook the message queue of the window procedure to which notification is sent and capture the completion message.

Therefore, when an asynchronous API is called, mDN Wrapper sets the hook (this is specified by the parameter of the API) to the window procedure to which notification is sent. When the hook detects the completion message (this is also specified by the parameter of the API), the hook converts the domain name in the storage area of the result (this is also specified by the paramter of the API) from the DNS side encoding to local encoding.

Installing Wrapper DLL

The WINSOCK DLL is placed in the system directory of the Windows. To surely wrap WINSOCK, the following need to be performed in the system directory;

Change the names of original WINSOCK DLLs:

ren wsock32.dll wsock32o.dll
ren ws2_32.dll  ws2_32o.dll

Copy Wrapper DLLs:

copy somewhere\wsock32.dll wsock32.dll
copy somewhere\ws2_32.dll  ws2_32.dll
copy another DLLs also

However, this kind of replacement of DLLs in the system directory is a very risky operation.

Once the DLL is replaced, if the same operation is repeated again, the original WINSOCK DLL will be lost.

Some service packs and applications re-install WINSOCK DLLs. This may also disable WINSOCK.

When such status occurs, it is possible that the entire network function will become disabled, or, in the worst case, Windows will not boot.

Therefore, mDN Wrapper shall provide application wrapping as a basic function, not at the system level.

Basically, in Windows, DLLs are searched in the following order:

Load directory of application

%SystemRoot%\System32

%SystemRoot%

Directory specified by PATH

and the first one found is loaded. Because of that, in general, installing the DLL in the load directory of the application enables calling of WINSOCK from the application to be wrapped.

However, some applications and DLLs have a specific DLL linked without going through the search path. mDN Wrapper cannot handle this structure of application or DLL.

Note : Netscape seems to be bound to a specific DLL and wrap cannot be performed by installing the wrapper DLL in the application directory. WINSOCK DLL itself seems to be bound to the related DLL of the system directory. On the other hand, because Internet Explorer and Windows Media Player follow the standard search path, wrap can be performed.

Location of Encoding Conversion

Versions of windows that support WINSOCK 2.0 have DLLs that correspond to WINSOCK 1.1 and 2.0, respectively. Calling of the WINSOCK 1.1 API is redirected to the same entry for 2.0.

In this case, calling of 1.1 and 2.0 are both passed to the DLL of V2.0. Therefore, conversion of encoding should be performed at the wrapper DLL side of 2.0 only.

On the other hand, when only WINSOCK 1.1 is supported (Win95), there is only a DLL that corresponds to 1.1.

In that case, naturally the wrapper DLL for 1.1 is used for encoding conversion.

When mDN Wrapper is installed in the Windows system directory, the operation is as shown above, therefore, conversion must be performed as follows.

WINSOCK 2.0 exists 2.0 wrapper is used for conversion

WINSOCK 1.1 only 1.1 wrapper is used for conversion

However, when the wrapper DLL is installed in the application directory, the operation is different. Since WINSOCK 1.1 DLL attached to the Windows is bound to WINSOCK2.0 located in the system directory, calling of the WINSOCK 1.1 API is not re-directed to the WINSOCK2.0 wrapper DLL at the application directory side. For that reason, when the wrapper DLL is installed in the application directory, it is necessary to convert encoding for both the 1.1 and 2.0 DLL. The operation of WINSOCK 1.1 DLL attached to Windows2000 is different. It seems re-directed to the WINSOCK2.0 wrapper DLL at the application directory side.

Such binding between DLLs is not documented and operation may differ depending on the environment and version being used. Therefore, with mDN Wrapper, the registry value is used to determine which wrapper DLL is used for conversion so that differences related to the installation location or version are neutralized.

The registry setting for mDN Wrapper is placed under the following registries:

    
HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN
HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN

The location for encoding conversion is determined by the Registry value Where(REG_DWORD) under the above. The effective values are as follows:

0

Converted at both WINSOCK 1.1 and WINSOCK 2.0

1

When WINSOCK 2.0 exists, converted only at WINSOCK 2.0
When only WINSOCK 1.1 exists, converted only WINSOCK 1.1

2

Converted only at WINSOCK 1.1

3

Converted only at WINSOCK 2.0

With other than Windows 2000, when the wrapper DLL is installed in the application directory, "0" needs to be set and when installed in the system directory or application directory of Windows 2000, "1" needs to be set. If no value is set in the registry, "0" is assumed. This is based on installation in the application directory.

Original/Converted Encoding

Wrapper DLL converts the domain name to be resolved from the local encoding used by the client machine to the DNS server encoding and returns the domain name (DNS server encoding) returned from the DNS to the local encoding used by the client machine.

With respect to multilingual encoding at the DNS side, a number of methods have been proposed. Wrapper DLL is structured to convert encoding to one of those DNS side encodings. This DNS side encoding can be specified by the configuration file.

On the other hand, the local encoding used by the application is usually derived from the code page of the process. Since the 'iconv' library used by Wrapper DLL can accept the code page name of the Windows as the encoding name, the code page name is used as the local encoding name as is.

However, some applications encode domain names using a specific multilingual encoding method. For example, with Internet Explorer, you can specify that domain names are to be expressed in UTF-8. UTF-8 encoding is one of the proposed multilingual methods, but multilingual DNS servers may accept only other encoding.

In order to handle this situation, mDN Wrapper is able to accept program-specific encoding as local encoding. Such program-specific local encoding shall be written in the registry.

Registry setting unique to the program for mDN Wrapper is placed under the following registries using the program name (execution module file name) as the key.

HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN\PerProg

HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN\PerProg

For example, with Internet Explorer it is placed under the following registry using IEXPLORE of the execution module name as the key.

HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN\PerProg\IEXPLORE

The local encoding name is specified by the Registry Encoding value (REG_SZ). This also must be one that can be recognized by libmdn.

Registry-value Encoding (REG_SZ)

Indicates the encoding name unique to the application program (when other than default encoding is required).

Log

When mDN Wrapper does not operate as expected, the log of operation can be very useful in resolving the problem. With mDN Wrapper, the following settings can be made with the registry setting.

Log level
Log file

Both the log level and log file are set under the following registries.

HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN
HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN

The log level is specified using

Registry value LogLevel (REG_DWORD)

The defined values are as follows.

-1 (0xFFFFFFFF): [None] No log is output
0: [Fatal] Outputs only fatal errors
1: [Error] Outputs errors that are not fatal
2: [Warning] Outputs warning messages as well
3: [Info] Outputs information other than errors as well
4: [Trace] Outputs program trace information

Note that this level specification is for the log level to be output by MDN library used by mDN Wrapper. In addition, mDN Wrapper itself outputs a log. The log cannot be specified and can only be switched ON and OFF. When -1 is specified, it is OFF; all other values switch the log ON. The default is -1.

Log file is used to specify the path to the file to which the log is to be output. The registry value LogFile(REG_SZ) is used to specify the path. The default is mdn_wrapper.log under the directory where mDN Wrapper is installed.

Note that the configuration program can be used to set the log level and log file settings.

Registry Setting - Summary

Registry Priority

mDN Wrapper configuration information stored under

Software\JPNIC\MDN

of HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER. mDN Wrapper first loads the setting of HKEY_LOCAL_MACHINE and overrides the setting using the setting at HKEY_CURRENT_USER side, if any. Usually, only the HKEY_LOCAL_MACHINE side is set. The HKEY_CURRENT_USER side is also set only when it is desired to use different for each user.

In particular, the configuration program loads and saves only the settings of HKEY_LOCAL_MACHINE. Be careful when using the configuration file to set settings.

Registry Key

There are common settings and program-specific settings.

Common definition:

Software\JPNIC\MDN\Where Conversion location

Software\JPNIC\MDN\ConFile Configuration file name

Software\JPNIC\MDN\LogLevel Log level

Software\JPNIC\MDN\LogFile Log file

Program-specific Settings:

Software\JPNIC\MDN\PerProg\<name>\Where Conversion location

Software\JPNIC\MDN\PerProg\<name>\Encoding DNS side encoding name

When the program-specific settings are not specified:

Where Setting of common definitions

Encoding Code page of process

are assumed.

`Software\JPNIC\MDN\Where`	Conversion location
`Software\JPNIC\MDN\ConFile`	Configuration file name
`Software\JPNIC\MDN\LogLevel`	Log level
`Software\JPNIC\MDN\LogFile`	Log file

`Software\JPNIC\MDN\PerProg\<name>\Where`	Conversion location
`Software\JPNIC\MDN\PerProg\<name>\Encoding`	DNS side encoding name

Where	Setting of common definitions
Encoding	Code page of process