1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<!-- $Id: wrapper.html,v 1.5 2001/10/23 06:04:19 miyayama Exp $ -->
<html lang="en-US">
<head>
<title>mDN Wrapper - Program Specification</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<link rev="made" href="mailto:idn-cmt@nic.ad.jp">
<link rel="stylesheet" type="text/css" href="spec.css">
</head>
<body>
<h1>mDN Wrapper</h1>
<!-- =========================================================== -->
<hr>
<h2>Implementation Method - Wrapper DLL</h2>
<p>
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.
</p>
<blockquote>
<p class="center-image">
<img src="../../img/spec/wrapper.jpg" alt="how wrapper DLL works">
</p>
</blockquote>
<p>
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.
</p>
<p>
With mDN Wrapper, to provide name resolution of multilingual domain names, a wrapper DLL is provided for the following WINSOCK DLLs:
</p>
<blockquote>
<ul>
<li><code>WSOCK32.DLL</code> (WINSOCK V1.1)
<li><code>WS2_32.DLL </code> (WINSOCK V2.0)
</ul>
</blockquote>
<p>
Note : The 16-bit version of WINSOCK (<code>WINSOCK.DLL</code>) is not supported.
</p>
<!-- =========================================================== -->
<hr>
<h2>APIs Subject to Processing</h2>
<p>
mDN Wrapper performs additional processing on only those APIs that are associated with WINSOCK name resolution. The following WINSOCK APIs are subject to processing.
</p>
<p>
When both the WINSOCK 1.1 and WINSOCK 2.0 APIs exist:
</p>
<blockquote>
<ul>
<li><code>gethostbyaddr</code>
<li><code>gethostbyname</code>
<li><code>WSAAsyncGetHostByAddr</code>
<li><code>WSAAsyncGetHostByName</code>
</ul>
</blockquote>
<p>
When only the WINSOCK 2.0 API exists:
</p>
<blockquote>
<ul>
<li><code>WSALookupServiceBeginA</code>
<li><code>WSALookupServiceNextA</code>
<li><code>WSALookupServiceEnd</code>
</ul>
</blockquote>
<p>
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.
</p>
<p>
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.
</p>
<p>
NOTICE: WINSOCK 2.0 also provides <code>WSALookupServiceBeginW</code>
and <code>WSALookupServiceNextW</code> 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.
</p>
<!-- =========================================================== -->
<hr>
<h2>APIs Not Subject to Processing</h2>
<p>
Regarding WINSOCK APIs other than those above, mDN Wrapper does not do anything and calls the original WINSOCK API.
</p>
<p>
mDN Wrapper is designed to copy and rename the original WINSOCK DLL and call it.
</p>
<blockquote>
<dl>
<dt><code>wsock32.dll</code>
<dd>Name is changed to <code>wsock32o.dll</code>
<dt><code>ws2_32.dll</code>
<dd>Name is changed to <code>ws2_32o.dll</code>
</dl>
</blockquote>
<p>
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:
</p>
<blockquote>
<dl>
<dt><code>wsock32.dll</code>
<dd>mDN Wrapper for WINSOCK V1.1
<dt><code>ws2_32.dll</code>
<dd>mDN Wrapper for WINSOCK V2.0
<dt><code>wsock32o.dll</code>
<dd>Original WINSOCK V1.1 DLL
<dt><code>ws2_32o.dll</code>
<dd>Original WINSOCK V2.0 DLL
</dl>
</blockquote>
<!-- =========================================================== -->
<hr>
<h2>Asynchronous API</h2>
<p>
Conversion of domain names must be carried out in the following sequence:
</p>
<blockquote>
<dl>
<dt>When request is sent to DNS
<dd>Local encoding is converted to DNS encoding
<dt>When response is received from DNS
<dd>DNS encoding is converted to local encoding
</dl>
</blockquote>
<p>
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.
</p>
<p>
However, the following WINSOCKs API are asynchronous APIs and control is returned before response is received from the DNS.
</p>
<blockquote>
<ul>
<li><code>WSAAsyncGetHostByAddr</code>
<li><code>WSAAsyncGetHostByName</code>
</ul>
</blockquote>
<p>
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.
</p>
<p>
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.
</p>
<!-- =========================================================== -->
<hr>
<h2>Installing Wrapper DLL</h2>
<p>
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;
</p>
<p>
Change the names of original WINSOCK DLLs:
</p>
<blockquote>
<pre>
ren wsock32.dll wsock32o.dll
ren ws2_32.dll ws2_32o.dll
</pre>
</blockquote>
<p>
Copy Wrapper DLLs:
</p>
<blockquote>
<pre>
copy somewhere\wsock32.dll wsock32.dll
copy somewhere\ws2_32.dll ws2_32.dll
copy another DLLs also
</pre>
</blockquote>
<p>
However, this kind of replacement of DLLs in the system directory is a very risky operation.
</p>
<blockquote>
<ol>
<li>Once the DLL is replaced, <strong>if the same operation is repeated again, the original WINSOCK DLL will be lost.</strong>
<li>Some service packs and applications <strong>re-install WINSOCK DLLs. This may also disable WINSOCK.</strong>
</ol>
</blockquote>
<p>
When such status occurs, it is possible that the entire network function will become disabled, or, in the worst case, Windows will not boot.
</p>
<p>
Therefore, mDN Wrapper shall provide application wrapping as a basic function, not at the system level.
</p>
<p>
Basically, in Windows, DLLs are searched in the following order:
</p>
<blockquote>
<ol>
<li>Load directory of application
<li><code>%SystemRoot%\System32</code>
<li><code>%SystemRoot%</code>
<li>Directory specified by <code>PATH</code>
</ol>
</blockquote>
<p>
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.
</p>
<p>
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.
</p>
<blockquote>
<p>
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.
</p>
</blockquote>
<!-- =========================================================== -->
<hr>
<h2>Location of Encoding Conversion</h2>
<p>
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.
</p>
<blockquote>
<p class="center-image">
<img src="../../img/spec/winsock2.jpg" alt="calling winsock2.0 through winsock1.1">
</p>
</blockquote>
<p>
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.
</p>
<p>
On the other hand, when only WINSOCK 1.1 is supported (Win95), there is only a DLL that corresponds to 1.1.
</p>
<blockquote>
<p class="center-image">
<img src="../../img/spec/winsock1.jpg" alt="calling only winsock1.1">
</p>
</blockquote>
<p>
In that case, naturally the wrapper DLL for 1.1 is used for encoding conversion.
</p>
<p>
When mDN Wrapper is installed in the Windows system directory, the operation is as shown above, therefore, conversion must be performed as follows.
</p>
<blockquote>
<ul>
<li>WINSOCK 2.0 exists 2.0 wrapper is used for conversion
<li>WINSOCK 1.1 only 1.1 wrapper is used for conversion
</ul>
</blockquote>
<p>
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.
</p>
<p>
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.
</p>
<p>
The registry setting for mDN Wrapper is placed under the following registries:
</p>
<blockquote>
<pre>
HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN
HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN
</pre>
</blockquote>
<p>
The location for encoding conversion is determined by the Registry value Where(<code>REG_DWORD</code>) under the above. The effective values are as follows:
</p>
<blockquote>
<dl>
<dt>0
<dd>Converted at both WINSOCK 1.1 and WINSOCK 2.0
<dt>1
<dd>When WINSOCK 2.0 exists, converted only at WINSOCK 2.0<br>
When only WINSOCK 1.1 exists, converted only WINSOCK 1.1
<dt>2
<dd>Converted only at WINSOCK 1.1
<dt>3
<dd>Converted only at WINSOCK 2.0
</dl>
</blockquote>
<p>
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.
</p>
<!-- =========================================================== -->
<hr>
<h2>Original/Converted Encoding</h2>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<blockquote>
<ul>
<li><code>HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN\PerProg</code>
<li><code>HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN\PerProg</code>
</ul>
</blockquote>
<p>
For example, with Internet Explorer it is placed under the following registry using <code>IEXPLORE</code> of the execution module name as the key.
</p>
<blockquote>
<p>
<code>HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN\PerProg\IEXPLORE</code>
</p>
</blockquote>
<p>
The local encoding name is specified by the Registry Encoding value (REG_SZ). This also must be one that can be recognized by libmdn.
</p>
<blockquote>
<p>Registry-value <code>Encoding</code> (<code>REG_SZ</code>)
</p>
</blockquote>
<p>
Indicates the encoding name unique to the application program (when other than default encoding is required).
</p>
<!-- =========================================================== -->
<hr>
<h2>Log</h2>
<p>
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.
</p>
<ul>
<li>Log level
<li>Log file
</ul>
<p>
Both the log level and log file are set under the following registries.<br>
</p>
<blockquote>
<pre>
HKEY_LOCAL_MACHINE\SOFTWARE\JPNIC\MDN
HKEY_CURRENT_USER\SOFTWARE\JPNIC\MDN
</pre>
</blockquote>
<p>
The log level is specified using
</p>
<blockquote>
<p>
Registry value <code>LogLevel</code> (<code>REG_DWORD</code>)
</p>
</blockquote>
<p>
The defined values are as follows.
</p>
<dl>
<dt>-1 (0xFFFFFFFF) <dd>[None] No log is output
<dt>0<dd>[Fatal] Outputs only fatal errors
<dt>1<dd>[Error] Outputs errors that are not fatal
<dt>2<dd>[Warning] Outputs warning messages as well
<dt>3<dd>[Info] Outputs information other than errors as well
<dt>4<dd>[Trace] Outputs program trace information
</dl>
<p>
Note that this level specification is for the log level to be output by <a href="library.html">MDN library</a> 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.
</p>
<p>
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 <code>mdn_wrapper.log</code> under the directory where mDN Wrapper is installed.
</p>
<p>
Note that the configuration program can be used to set the log level and log file settings.
</p>
<!-- =========================================================== -->
<hr>
<h2>Registry Setting - Summary</h2>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<h3>Registry Priority</h3>
<p>
mDN Wrapper configuration information stored under
</p>
<blockquote>
<p>
<code>Software\JPNIC\MDN</code>
</p>
</blockquote>
<p>
of <code>HKEY_LOCAL_MACHINE</code>, <code>HKEY_CURRENT_USER</code>. mDN Wrapper first loads the setting of <code>HKEY_LOCAL_MACHINE</code> and overrides the setting using the setting at <code>HKEY_CURRENT_USER</code> side, if any. Usually, only the <code>HKEY_LOCAL_MACHINE</code> side is set. The <code>HKEY_CURRENT_USER</code> side is also set only when it is desired to use different for each user.
</p>
<p>
In particular, the configuration program loads and saves only the settings of <code>HKEY_LOCAL_MACHINE</code>. Be careful when using the configuration file to set settings.
</p>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<h3>Registry Key</h3>
<p>
There are common settings and program-specific settings.
</p>
<p>
Common definition:
</p>
<blockquote>
<table summary="Registry key (common definition)">
<tr><td><code>Software\JPNIC\MDN\Where</code>
<td>Conversion location</tr>
<tr><td><code>Software\JPNIC\MDN\ConFile</code>
<td>Configuration file name</tr>
<tr><td><code>Software\JPNIC\MDN\LogLevel</code>
<td>Log level</tr>
<tr><td><code>Software\JPNIC\MDN\LogFile</code>
<td>Log file</tr>
</table>
</blockquote>
<p>
Program-specific Settings:
</p>
<blockquote>
<table summary="Registry key (Program-specific Settings)">
<tr>
<td><code>Software\JPNIC\MDN\PerProg\<name>\Where</code>
<td>Conversion location
</tr>
<tr>
<td><code>Software\JPNIC\MDN\PerProg\<name>\Encoding</code>
<td>DNS side encoding name
</tr>
</table>
</blockquote>
<p>
When the program-specific settings are not specified:
</p>
<blockquote>
<table summary="Registry key is not set">
<tr><td>Where<td>Setting of common definitions</tr>
<tr><td>Encoding<td>Code page of process</tr>
</table>
</blockquote>
<p>
are assumed.
</p>
</body>
</html>
|
