【日本語訳】

7.3. Wineアーキテクチャ
7.3.1. 全体図

Wineの実装は、いくつものサブシステムが実装されていないにせよ、Windows NTアーキテクチャに近いです。(16ビットサポートは、サブシステムではなく、32ビットWindows EXEに実装されていることを思い出してください。) 全体図がここにあります。

+---------------------+                                  \
|     Windows EXE     |                                   } アプリケーション
+---------------------+                                  /

+---------+ +---------+                                  \
| Windows | | Windows |                                   \ アプリケーション & システムDLL群
|   DLL   | |   DLL   |                                   /
+---------+ +---------+                                  /

+---------+ +---------+    +------------+  +--------+  \
|  GDI32  | |  USER32 |    |            |  |        |   \
|   DLL   | |   DLL   |    |            |  |  Wine  |    \
+---------+ +---------+    |            |  |サーバー|     \ コアシステムDLL群
+---------------------+    |            |  |        |     / (左側)
|    Kernel32 DLL     |    |サブシステム|  |NTライク|    /
|(Win32 サブシステム) |    |Posix, OS/2 |  | Kernel |   /
+---------------------+    +------------+  |        |  /
                                         |        |
+---------------------------------------+  |        |
|                 NTDLL                 |  |        |
+---------------------------------------+  +--------+

+---------------------------------------+               \
|   Wine 実行ファイル (wine-?スレッド)  |                } unix実行ファイル
+---------------------------------------+               /
+---------------------------------------------------+   \
|                 Wine ドライバ群                   |    } Wine固有のDLL群
+---------------------------------------------------+   /

+------------+    +------------+     +--------------+   \
|    libc    |    |   libX11   |     |他のライブラリ|    } unix共有ライブラリ群
+------------+    +------------+     +--------------+   /  (ユーザー空間)

+---------------------------------------------------+   \
|        Unix カーネル (Linux,*BSD,Solaris,OS/X)    |    } (Unix) カーネル空間
+---------------------------------------------------+   /
+---------------------------------------------------+   \
|              Unix デバイスドライバ群              |    } Unix ドライバ群 (カーネル空間)
+---------------------------------------------------+   /

Wineは最低限「３大」DLL(KERNEL/KERNEL32とGDI/GDI32とUSER/USER32)を完全に置き換えなければなりません。他の全てのDLLはこの上に積み重なっています。しかしWineは(多くの理由から)NT方式の実装に傾きつつあるので、もう一つNTDLLをコアDLLとしてWineで実装しなければならず、数多くのKERNEL32およびADVAPI32機能をNTDLLを通して実装しなければなりません。

今日現在、(Win32のそれと分かれた)本物のサブシステムはWineに実装されていません。

WineサーバーはコアDLL群の実装のバックボーンを提供します。これは主にプロセス間同期とオブジェクト共有を実装します。これは、実装の観点からみると、NTカーネルとして見ることができます。(例えWineのDLLとWineサーバー間で使われているAPIとプロトコルがWine固有であるとしてもです。)

WineはUnixドライバをPC上の様々なハードウェアにアクセスするのに使用しています。しかしながら、一部のケースでは、Wineは(Windowsの意味の)ドライバーを物理的なハードウェアデバイスに提供しています。このドライバはUnixドライバのプロキシとなります。(例えば、実例として、X11やSDLドライバと一緒にグラフィカル部分、OSSやALSAドライバと一緒にオーディオなど…)

Wineが提供する全てのDLLは、可能な限りWindowsプラットフォームからエクスポートされるAPI群に留まろうとしています。これに当てはまらないのはごくわずかであり、適切にドキュメントされています (WineのDLLはWine固有のAPIをエクスポートしています)。通常、これらは __wine プレフィクスが付いています。

これから、これらの全てのコンポーネントのさらなる詳細を見ていきましょう。

【原文】
7.3. Wine architecture
7.3.1. Global picture

Wine implementation is closer to the Windows NT architecture, even if several subsystems are not implemented yet (remind also that 16bit support is implemented in a 32-bit Windows EXE, not as a subsystem). Here’s the overall picture:

+---------------------+                                  \
|     Windows EXE     |                                   } application
+---------------------+                                  /

+---------+ +---------+                                  \
| Windows | | Windows |                                   \ application & system DLLs
|   DLL   | |   DLL   |                                   /
+---------+ +---------+                                  /

+---------+ +---------+     +-----------+  +--------+  \
|  GDI32  | |  USER32 |     |           |  |        |   \
|   DLL   | |   DLL   |     |           |  |  Wine  |    \
+---------+ +---------+     |           |  | Server |     \ core system DLLs
+---------------------+     |           |  |        |     / (on the left side)
|    Kernel32 DLL     |     | Subsystem |  | NT-like|    /
|  (Win32 subsystem)  |     |Posix, OS/2|  | Kernel |   /
+---------------------+     +-----------+  |        |  /
                                         |        |
+---------------------------------------+  |        |
|                 NTDLL                 |  |        |
+---------------------------------------+  +--------+

+---------------------------------------+               \
|   Wine executable (wine-?thread)      |                } unix executable
+---------------------------------------+               /
+---------------------------------------------------+   \
|                   Wine drivers                    |    } Wine specific DLLs
+---------------------------------------------------+   /

+------------+    +------------+     +--------------+   \
|    libc    |    |   libX11   |     |  other libs  |    } unix shared libraries
+------------+    +------------+     +--------------+   /  (user space)

+---------------------------------------------------+   \
|         Unix kernel (Linux,*BSD,Solaris,OS/X)     |    } (Unix) kernel space
+---------------------------------------------------+   /
+---------------------------------------------------+   \
|                 Unix device drivers               |    } Unix drivers (kernel space)
+---------------------------------------------------+   /

Wine must at least completely replace the “Big Three” DLLs (KERNEL/KERNEL32, GDI/GDI32, and USER/USER32), which all other DLLs are layered on top of. But since Wine is (for various reasons) leaning towards the NT way of implementing things, the NTDLL is another core DLL to be implemented in Wine, and many KERNEL32 and ADVAPI32 features will be implemented through the NTDLL.

As of today, no real subsystem (apart the Win32 one) has been implemented in Wine.

The Wine server provides the backbone for the implementation of the core DLLs. It mainly implementents inter-process synchronization and object sharing. It can be seen, from a functional point of view, as a NT kernel (even if the APIs and protocols used between Wine’s DLL and the Wine server are Wine specific).

Wine uses the Unix drivers to access the various hardware pieces on the box. However, in some cases, Wine will provide a driver (in Windows sense) to a physical hardware device. This driver will be a proxy to the Unix driver (this is the case, for example, for the graphical part with X11 or SDL drivers, audio with OSS or ALSA drivers…).

All DLLs provided by Wine try to stick as much as possible to the exported APIs from the Windows platforms. There are rare cases where this is not the case, and have been propertly documented (Wine DLLs export some Wine specific APIs). Usually, those are prefixed with __wine.

Let’s now review in greater details all of those components.

Chapter 7. Overview
7章　概要Table of Contents
7.1. Wine Overview
7.2. Standard Windows Architectures
7.3. Wine architecture
内容
7.1. Wine概要
7.2. 標準Windowsアーキテクチャ
7.3. Wineアーキテクチャ

Brief overview of Wine’s architecture…
Wineのアーキテクチャの簡単な概要…

7.1. Wine Overview
7.1. Wine概要

With the fundamental architecture of Wine stabilizing, and people starting to think that we might soon be ready to actually release this thing, it may be time to take a look at how Wine actually works and operates.
Wineの基本的なアーキテクチャが固まってきて、実際にこれをリリースする準備がすぐにできるかもしれないと、皆が考え始めたので、Wineが実際にどのように動作しているのか、ちょっと見ておく時期かもしれない。

7.1.1. Foreword
7.1.1. 序

Wine is often used as a recursive acronym, standing for “Wine Is Not an Emulator”. Sometimes it is also known to be used for “Windows Emulator”. In a way, both meanings are correct, only seen from different perspectives. The first meaning says that Wine is not a virtual machine, it does not emulate a CPU, and you are not supposed to install Windows nor any Windows device drivers on top of it; rather, Wine is an implementation of the Windows API, and can be used as a library to port Windows applications to Unix. The second meaning, obviously, is that to Windows binaries (.exe files), Wine does look like Windows, and emulates its behaviour and quirks rather closely.
Wineはよく”Wine Is Not an Emulator”を表す再帰的頭字語として使われる。時々、”Windows Emulator”(の意味)でも使われていることが知られている。ある意味、両方とも正しい。異なる視点から見ているだけである。最初の意味は、Wineは仮想マシンではなく、CPUをエミュレートせず、WindowsやWindowsのデバイスドライバをそれにインストールすると思われず、むしろWineはWindows APIの実装の一つであり、WindowsアプリケーションをUnixに移植するためのライブラリとして使うことができると思われるだろう。次の意味は、明らかに、これはWindowsバイナリ(.exeファイル)のためのものであり、そしてWindowsに似ていてその振る舞いや癖を忠実にエミュレートするということだ。

“Emulator”: The “Emulator” perspective should not be thought of as if Wine is a typical inefficient emulation layer that means Wine can’t be anything but slow – the faithfulness to the badly designed Windows API may of course impose a minor overhead in some cases, but this is both balanced out by the higher efficiency of the Unix platforms Wine runs on, and that other possible abstraction libraries (like Motif, GTK+, CORBA, etc) has a runtime overhead typically comparable to Wine’s.
“エミュレータ”: “エミュレータ”という視点から、まるでWineが遅い以外の何者でもない意味の、典型的な非効率的なエミュレーションレイヤという風に思われるべきではない。
まずいデザインのWindows APIに忠実であることは、いくつかの場合では確かにわずかなオーバーヘッドを強いるかもしれない。だが、これはWineが走る、より効率の高いUnixプラットフォームで相殺される。その上、他の有力な抽象化ライブラリ(Motif、GTK+、CORBA、など)は一般的にWineのそれに匹敵するランタイムオーバーヘッドを持っている。

7.1.2. Executables
7.1.2. 実行ファイル

Wine’s main task is to run Windows executables under non Windows operating systems. It supports different types of executables:
Wineの主な役割は、Windowsの実行ファイルをWindowsではないオペレーティングシステム上で走らせる事だ。異なるタイプの実行ファイルをサポートしている。

DOS executable. Those are even older programs, using the DOS format (either .com or .exe (the later being also called MZ)).
DOS実行ファイル。DOS形式(.comや.exe(後者はMZとも呼ばれる))を使用する、実に古いプログラム達である。

Windows NE executable, also called 16 bit. They were the native processes run by Windows 2.x and 3.x. NE stands for New Executable .
16ビットとも呼ばれる、Windows NE実行ファイル。Windows 2.xや3.xのネイティブプロセス達であった。NEはNew Executableを意味する。

Windows PE executable. These are programs were introduced in Windows 95 (and became the native formats for all later Windows version), even if 16 bit applications were still supported. PE stands for Portable Executable, in a sense where the format of the executable (as a file) is independent of the CPU (even if the content of the file – the code – is CPU dependent).
Windows PE実行ファイル。16ビットアプリケーションがまだサポートされていたにせよ、Windows 95で導入されたプログラム達である。(そしてその後の全てのWindowsバージョンでネイティブフォーマットとなった。) PEはPortable Executableを意味し、その実行ファイルの形式は(ファイルとしては)ある程度CPUに非依存である(たとえ、ファイルの中身 – コード – はCPU依存であったとしても)。

Winelib executable. These are applications, written using the Windows API, but compiled as a Unix executable. Wine provides the tools to create such executables.
Winelib実行ファイル。Windows APIを使用して書かれたアプリケーション達なのだが、Unix実行ファイルとしてコンパイルされている。Wineはこのような実行ファイルを生成するためのツールを提供している。

Let’s quickly review the main differences for the supported executables:
サポートされている実行ファイルの違いについてちょっとレビューしよう:

Table 7-1. Wine executables
表 7-1. Wine実行ファイル

DOS (.COM or .EXE) Win16 (NE) Win32 (PE) Winelib
Multitasking Only one application at a time (except for TSR) Cooperative Preemptive Preemptive
Address space One MB of memory, where each application is loaded and unloaded. All 16 bit applications share a single address space, protected mode. Each application has it’s own address space. Requires MMU support from CPU. Each application has it’s own address space. Requires MMU support from CPU.
Windows API No Windows API but the DOS API (like Int 21h traps). Will call the 16 bit Windows API. Will call the 32 bit Windows API. Will call the 32 bit Windows API, and possibly also the Unix APIs.
Code (CPU level) Only available on x86 in real mode. Code and data are in segmented forms, with 16 bit offsets. Processor is in real mode. Only available on IA-32 architectures, code and data are in segmented forms, with 16 bit offsets (hence the 16 bit name). Processor is in protected mode. Available (with NT) on several CPUs, including IA-32. On this CPU, uses a flat memory model with 32 bit offsets (hence the 32 bit name). Flat model, with 32 bit addresses.
Multi-threading Not available. Not available. Available. Available, but must use the Win32 APIs for threading and synchronization, not the Unix ones.

マルチタスク
DOS (.COM or .EXE) 同時に一つのアプリケーションのみ(TSRを除く)
Win16 (NE) 協調(型)
Win32 (PE) プリエンプティブ(割り込み型)
Winelib プリエンプティブ(割り込み型)

アドレス空間
DOS (.COM or .EXE) それぞれのアプリケーションがロード/アンロードされる場合に、1MBのメモリ
Win16 (NE) 全ての16ビットアプリケーションは単一のメモリをプロテクトモードで共有
Win32 (PE) それぞれのアプリケーションはそれぞれ自分のメモリ空間を持つ。CPUのMMUサポートが必要
Winelib それぞれのアプリケーションはそれぞれ自分のメモリ空間を持つ。CPUのMMUサポートが必要

Windows API
DOS (.COM or .EXE) Windows APIではなくDOS API (Int 21hトラップのような)
Win16 (NE) 16ビット Windows APIを呼び出し
Win32 (PE) 32ビット Windows APIを呼び出し
Winelib 32ビット Windows APIを呼び出し、場合によってはUnix APIも

コード(CPUレベル)
DOS (.COM or .EXE) x86リアルモードのみ利用可能。コードとデータは16ビットのオフセット付きセグメント形式。プロセッサはリアルモード。
Win16 (NE) IA-32アーキテクチャのみ利用可能。コードとデータは16ビットのオフセット付きセグメント形式(なので16ビットという名前)。プロセッサはプロテクトモード。
Win32 (PE) IA-32を含む様々なCPU(NTにおいて)。このCPUでは32ビットのオフセット付きのフラットなメモリモデル(なので32ビットという名前)。
Winelib 32ビットアドレスのフラットなモデル。

マルチスレッド
DOS (.COM or .EXE) 利用できない
Win16 (NE) 利用できない
Win32 (PE) 利用できる
Winelib 利用できるが、UnixのではなくWin32 APIをスレッディングと同期に使用しなければならない

Wine deals with this issue by launching a separate Wine process (which is in fact a Unix process) for each Win32 process, but not for Win16 tasks. Win16 tasks are run as different intersynchronized Unix-threads in the same dedicated Wine process; this Wine process is commonly known as a WOW process (Windows on Windows), referring to a similar mechanism used by Windows NT.
Wineはこの事柄を独立したWineプロセス(実際にはUnixプロセス)をそれぞれのWin32プロセス毎にラウンチすることで対応する。しかしWin16タスクはそうではない。Win16タスク達は、専用の同じWineプロセス内の、相互に同期された違うUnixスレッドとして走る。このWineプロセスは、Windows NTで使われる似たメカニズムから、一般にWOWプロセス(Windows on Windows)として知られている。

Synchronization between the Win16 tasks running in the WOW process is normally done through the Win16 mutex – whenever one of them is running, it holds the Win16 mutex, keeping the others from running. When the task wishes to let the other tasks run, the thread releases the Win16 mutex, and one of the waiting threads will then acquire it and let its task run.
WOWプロセス内で走るWin16タスク間の同期は、通常Win16ミューテックスを通してなされる。それらの一つが動いているときはいつでも、Win16ミューテックスを保持することで、他が走るのを避ける。そのタスクが他のタスクを走らせようと望んだときは、そのスレッドはWin16ミューテックスを解放し、待っているスレッドの一つがそれ(ミューテックス)を間もなく獲得し、そのタスクが走らされる。

winevdm is the Wine process dedicated to running the Win16 processes. Note that several instances of this process could exist, has Windows has support for different VDM (Virtual Dos Machines) in order to have Win16 processes running in different address spaces. Wine also uses the same architecture to run DOS programs (in this case, the DOS emulation is provided by a Wine only DLL called winedos.

winevdmはWin16プロセスを走らすため専用のWineプロセスである。このプロセスのたくさんのインスタンスが存在し得ることに注意しよう。異なるアドレス空間で走る複数のWin16プロセスを持つための、別々のVDM(Virtual Dos Machines)のサポートを持つ複数のWindowsを持つことがある。WineはDOSプログラムを走らせるのにもこれと同じアーキテクチャを使っている。(この場合、WineによるDOSエミュレーションは、winedosと呼ばれるWineにしかないDLLで提供される。)

そのうち救出しておかないとBlog止めちゃって消えるかもしれん。

□コアテクの路地

• エンジニアの働き甲斐を支えるもの [超雑談]
• 無線LANの利用 [OA用PCのLinux化]
• 不定期Wine談義(1) : WineはWindowsエミュレータではない (Wine Is Not an Emulator) [超雑談]
• 不定期Wine談義(2) : AsianuxでWineをセットアップする [超雑談]

「昔の自分の文章を読んでいると、なんというか、なんて賢かったんだろう自分は、と思うことがある。まるで自分ではないみたいだ。」

2009年9月ごろ、私はこう呟いていた。

「相手への思いやりがために、自分の志を忘れるな」というタイトルの文章をそれ以前に私は書き留めている。2004年12月9日。婚姻届を出して3日後のことである。内容はこうだ：

最近、他人を思いやる、という回路が働くようになったのだが、これが実に厄介だと感じている。一番厄介なのが、何が正しいのかよく分からなくなるのだ。
思いやる、ということは、相手に感情移入する面がある。と、相手にとって都合のいいこと悪いことを考えてしまう。すると、自分が今まで考えてきた正しいこと正しくないこと、というのをすっかり忘れてしまう可能性がある。凡人の僕ならなおさらである。
TPOに応じて(人格を使い分けろ)なんてことを要求する奴がいるが、そんなことを考え出したら、もう、人の何がうらやましかったのか、人生で何を達成したかったのか、なんていうことを忘れてしまう。そういう奴に限って、人生の目標は金を稼ぐことだったりするのだ。
こういう奴は自分がどんな人間として過ごそうが関係ないのだから、もしあなたが彼等の部下で、良い社員になろうとこのようなことを心がけようと思っているなら、即刻やめるべきだ。いいように使われて、結局自分がやりたかったことが少しもできないことになるかもしれない。

この文章を書いている現在、この文章を書いた背景は思い出せる。結婚できたのはつまり、他人を思いやるという回路が働くようになったからだ。結婚するということは、少なくとも別の1つの存在を内包するということだからだ。

思いやりと志は必ずしも相反するものではない。しかし優先順位がなければならない。私は志を大事にしたい。
ただ、志はベクトルである。たくさんのベクトルが一緒の方向になればすごくなるが、それらを揃えるのは「非常に」難しい。最初からそのために集まったならできる可能性がある、ぐらいだろうと思う。だから多くの人の志は、結婚したときに維持できなくなることも多い。

この不安を抱えながら、私はこの文章を書いていたんだろうと思う。

実際はそういうことはなかった。違うところから、志の崩壊は生まれた。
一つは2009年9月ごろ、呟いていたこと。もう一つは、私の価値観そのものが古くなってしまったことだ。

I made a set of rpm packages for running Chromium on CentOS5/RHEL5/AsianuxServer3.
To get latest information, go here.Below is the digest from current page of my Chromium page:

Download

This page provides a set of rpm packages to build your web browser from Chromium snapshot on CentOS 5.x, and also provides some pre-built binaries of the web browser. But pre-built browser binaries were just built for me. They are not new, and sometimes they may be useless…

To download binary rpms for x86: click here.

To download source rpms: click here.

(Currently there are no x86-64 binaries.)

NOTE: You can use rpm packages freely AT YOUR OWN RISK. Read here for the terms and condition of the Chromium browser.

Short instruction to run pre-built browser

1. Get following binary rpms: chromium-atk, chromium-cairo, chromium-expat, chromium-pango , chromium-glib2, chromium-gtk2, chromium-freetype, chromium-pixman , and chromium.

2. Install them into your CentOS system by “rpm -i” command. When you get some dependency errors, supply additional packages to fix them.

3. Choose “Chromium” on the gnome menu, Applications -> Internet, or run /usr/bin/chromium from a command line.

Short instruction to build your browser

1. Get all binary rpms except chromium, and get chromium source rpm.

2. Install them into your CentOS system by “rpm -i” command. When you get some dependency errors, supply additional packages to fix them also.
   Don’t forget to install chromium source rpm.

3. Install more development packages for compilation. (ex. gcc44-g++) See here if you are uncertain. The list is not accurate for CentOS5, but useful. In this time, you don’t need to install rpms that are already installed at 1st step with “chromium-” prefix. For example, you don’t need to install gtk2-devel because chromium-gtk2-devel has been installed.

4. Get recent source tarball, chromium.xxxxxx.tgz and depot_tools.tgz, from here, and put them on /usr/src/redhat/SOURCES/.

5. cd /usr/src/redhat/SPECS. Edit “Source0” in chromium.spec with your downloaded tarball file name. And set %enable_network 0, because we have already gotten recent sources.

6. Run “rpmbuild -ba chromium.spec”.
   If you fail to build Chromium, the reason may be one of two:

   (1) There are still rpm packages to be installed.

   (2) The source code in the tarball is now broken.
   If (2), you can try with “%enable_network 1” later. It will sync with newest code via network, and the bug may be fixed in the newest code. If (1), you must see error messages carefully, and google some keywords in the messages to find rpm package to install.

についてちょっと気がついたのでメモ。

例としてブロガーとして著名な池田信夫氏のこのエントリを読んでみます。

◎動機から入る？

書いた動機は一番下の

全世界に通じると称する超越的な「正義」を振り回して他国を侵略することほど正義から遠い行為はないのである。

だということが分かります。なぜなら、ここだけ浮いているからです。相当違和感があります。正義についての憂慮が動機になっているように感じました。ということでなにかしらの単語(「正義」など)から文章が展開できそうとなるとフラッと書いたら良いようです。

◎自分の好みの分野につなげる？

最初の

正義とか公正という概念は、

で正義と公正と２つの言葉を出しているのは、おそらくその次の公正についての文章に連続させるためだと思われます。なので、「とか公正」は後付けかもしれません。ちなみに「とか」って項目分繰り返し付けませんか？「AとかBとか」という風に。まあそれはいいんですが、ともかく、文章をつらつらと好みの分野で続けます。ちなみに私は経済学はわかりませんので、この辺に書いてある文章はほぼ理解できません。でも読んでしまいますが、そこに文章があれば。

◎結論への短絡線

つらつら進んで、言いたいことに接近したら、接続のための文章をいれます。

この意味で、正義の概念は民主主義のあり方と不可分である。この結論は平凡といえば平凡だが、

の部分ですね。この文章としての結論はここらしいんですけど、言いたいことは別なんで脱線してもう少し続いているんですね。

ちなみに、私がこの文章を書いた動機は、最後の一文が浮いているということが動機となって、そこから文章が書けそうだと思ったからです。

…で、ここまで書いて気がついたんですけど、国語の問題みたいですね。
なんで、「この国語の問題みたいですね」という文章を付けるが如く、「正義の概念は民主主義のあり方と不可分である。」が最初に書きたかったことで、「この結論は」以降は突然書き足したくなったことなのかもしれない、と思いつきました。はてさて。

いずれにせよ、これくらい緩くblogというものは書くもんなんじゃないかと思いつつ、新年の初エントリは終了とします。