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.
Note : dnsproxy makes DNS request/response multilingual on the network and also can make these applications multilingual. It is recommended they be used as needed. Note : WINSOCK 2.0 has the following APIs for WIDE CHARACTER based name resolution. 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.
WSALookupServiceBeginW WSALookupServiceNextW
APIs Not Subject to Processing
Regarding WINSOCK APIs other than those above, mDN Wrapper does not do anything and calls the original WINSOCK API. WINSOCK DLL includes entries that are not documented. Regarding those entries, since call parameters, etc. are not known, it is not possible to call the original DLL entries using codes inside the wrapper. Therefore, for the entries other than the above, mDN Wrapper uses 'function forwarding' to forward calling of a DLL to the original DLL.
When 'function forwarding' is used, it is necessary to explicitly specify the forward destination DLL name when the wrapper DLL is created. The DLL name must be different from the wrapper itself, that is, a different name that the original DLL. mDN wrapper copies the original WINSOCK DLL as a different name and uses it as the forward destination DLL.
wsock32.dll -> wsock32o.dll ws2_32.dll -> 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 -> DNS encoding - When response is received from DNS
DNS encoding -> 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:
- Copy Wrapper DLLs:
However, this kind of replacement of DLLs in the system directory is a very risky operation.
a) Once the DLL is replaced, if the same operation is repeated again, the original WINSOCK DLL will be lost. b) 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.
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 directory:
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:
Registry Where (REG_DWORD)
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
When the wrapper DLL is installed in the application directory, "0" needs to be set and when installed in the system directory, "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 is specified by the registry. In this registry, the default encoding (currently, it is RACE) is set when mDN Wrapper is installed. This registry can be changed to some other encoding method.
The registry setting for mDN Wrapper is placed under the following directory.
DNS side encoding is specified by the registry encoding value(REG_SZ). This encoding name must be one that can be recognized by libmdn.
HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN
Registry Encoding (REG_SZ)Set DNS server side encoding name.
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 server 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 directory 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 directory 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 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 registry.
HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN
HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN
The log level is specified using the 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
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\MDNof 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 setting 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
0:Both WINSOCK1.1 and WINSOCK2.0
1:At WINSOCK2.0 when exists
2:At WINSOCK1.1 only
3:At WINSOCK2.0 only
Software\JPNIC\MDN\Encoding DNS side encoding name
Software\JPNIC\MDN\Normalize Method of normalization
Software\JPNIC\MDN\LogLevel Log level
Software\JPNIC\MDN\LogFile Log file
Program-specific Settings
Conversion location and program side encoding can be specified for each program.These are set under the following key hive using the value using the program name as the key.
Software\JPNIC\MDN\PerProg\<name>\Where Software\JPNIC\MDN\PerProg\<name>\EncodingWhen they are not specified:
are assumed.
Where 0 Converts at both 1.1 and 2.0 Encoding Code page of process
