銀杏の木

まず、Build Environment の `ReactOS Build Environment for Unix-compatible Operating Systems Version 2.1.2' から RosBE をダウンロードし中身を展開する。

RosBE-Unix-2.1.2/sources/make.tar.bz2 アーカイブの中にある configure を編集し、

を、

と変更し、アーカイブの中身を更新してから、

として、表示に従い RosBE のインストール先を指定し RosBE をインストールする（ configure の編集をしないまま RosBE-Builder.sh を実行すると alloca の未定義参照のエラーで RosBE のソースのコンパイルに失敗する。（※１））。デフォルトでは /usr/local/RosBE にインストールされるので、その場合は前もって su で root 権限をもたせておく。

次に、

を実行し、reactos のソース環境をクローンする。

それから、

のようにして RosBE のシェルに入り、

とすることで reactos/output-MinGW-i386/ 以下が作成される。

この後、

で reactos/output-MinGW-i386 の中に移動するが、そのまま ninja bootcd を実行したのでは、 gcc がコンパイル中にプリコンパイルヘッダのエラーが起きビルドが通らない（※２, ※３）ので、 reactos/output-MinGW-i386/CMakeCache.txt を編集し、

を、

のように変更してから、

とすることで ReactOS のブートＣＤが作成される。

※１：Install older version of gnu-make in Ubuntu 18.04

※２：RosBE problems

※３：Cannot build on Debian Stretch amd64

VMware Player をインストールして使用する場合に、 `Create a New Virtual Machine' から guest OS の iso イメージを読み込み起動しようとしたとき、 modconfig がモジュールを更新しようとするときがある。その際に vmmon のコンパイルのところで止まってしまい実行出来なかった。

止まってしまう原因はいくつかあって、まず、 vmmon, vmnet のソースコードの一部が最近のカーネルと不整合を起こしているためコンパイル時にエラーとなることと、 script の実行時にもエラーが出ること、そして、コンパイルして作成されるカーネルモジュール vmmon.ko, vmnet.ko に署名がされていないため起動に失敗することだ。

まず、カーネルコードとの不整合については、 Michal Kubeček 氏の GitHub に修正版のソース一式を挙げてくださっているので、そちらを使用させていただく。

としてサービスを停止しておいてから、氏の GitHub の INSTALL に記述されている通り、

としてやれば vmmon.ko, vmnet.ko の修正版がインストールされる。（ 14.1.1 のところは使用する VMwarePlayer のバージョンに置き換える。ただし、氏の GitHub に修正版が上がっていることが前提。）

これで vmmon, vmnet のコンパイル時のエラーは解消される。

このとき、 make したとき、

といったエラーも出るが、これは LANG=C make とすることで解消できる。

この後、 make install した後そのまま、

とした場合、

のように２つのモジュールの起動に失敗するが、これは UEFI の validation 機能が有効になっている場合に更新したカーネルモジュールに署名がされていないためなので、

のようにして vmmon.ko, vmnet.ko に署名してやると起動できるようになる。 MOK.priv, MOK.der は事前に作成しキーを登録しておかなければいけない。

VMware が自動的にモジュールを更新しようとしたとき、この署名の操作をしないため、 UEFI の validation が有効になっていると更新に失敗するはずだ。（ VMware はなぜこの問題に対応しないのだろう？ ）

こちらのサイト を参考にした。

切替可能な gcc を一覧に登録するには、

とする。ここで、 70 は優先順位を表し、大きい数値ほど優先順位が高くなる。

このとき、同時に、

とすると、 gcc と g++ の２つのリストをそれぞれ別々に管理して別々に切り替えできそうに思うが、これだと g++ の方を設定しようとしたとき、 g++ は gcc のスレーブなのでだめ、と怒られエラーになる。

gcc, g++, gcov のバージョンを連動させて切り替える場合、 g++, gcov は gcc のスレーブなので、

として、連動して切り替わるように設定する。

この状態で、

とすると、切り替え可能な gcc の一覧が表示され、 gcc のバージョンを選択することで、使用する gcc, g++, gcov のバージョンを連動させて選択することができる。

JPNIC を見ると、ドメイン名とは、ウェブアドレスまたは電子メールアドレスの内、下の下線の部分で、ドット (.) で区切られた各部分を「ラベル」と呼び、右端のラベルから左に向けて、トップレベルドメイン、第２レベルドメイン、第３レベルドメイン、・・・と呼ばれるらしい。

・電子メールアドレスの場合：

email@bar.co.jp

・ウェブアドレスの場合：

www.foo.co.jp

また、文字列の長さについては、

• ドメイン名全体では、２５３文字以下。
• １つのラベルは、６３文字以下。
• 日本語ドメインの場合は、ラベル１つは、１５文字以下。

使える文字は、

ラベルには大文字、小文字の区別はない。

• 英字(A-Z)。
• 数字(0-9)。
• ハイフン(-)。
• 日本語ドメインの場合は、上に加えて全角ひらがな、カタカナ、漢字、全角記号。

だが、 JPNIC の説明には、ドメイン名全体およびラベル１つの最長の文字数については書かれていても、最短で何文字以上必要かが言及されていない。

.jp ドメイン名の登録管理は JPNIC がしているんじゃないのか、もっときちんとした説明はないの？と検索してみると、どうも２０００年に JPNIC 総会で新会社設立が決議され同年設立された JPRS という企業に移管したようで、現在はそこが管理をしているようだ。

JPRS の「使用できる文字」によると、

• 英数字 .jp ドメイン名の場合、３文字以上６３文字以下
• 日本語 .jp ドメイン名の場合、１文字以上１５文字以下

と、しっかり明記されていた。つまり、 a.jp （半角のみ）はダメだが、あ.jp （全角の ‘あ’ １文字）はオーケー、ということになる。（ こちらによると .cn ドメインでは取得できるらしい。管理団体の考え方によってまちまち、ということか？）

ちなみに、同じページに、「全角ひらがな・カタカナ・漢字・半角英数字（A～Z、0～9）・半角のハイフン「-」上記以外に「・」「ヽ」「ヾ」「ゝ」「ゞ」「々」「ー」なども使用可能」とあるので、意外だが全角アルファベットは日本語ドメイン名としては使用できない。全角アルファベットは半角アルファベットと区別されない仕様のようだ。実際 chrome の URL 入力欄に全角アルファベットで英数字ドメイン名を入力してみると、英数字ドメイン名に置換され何もなかったかのようにページが開いた。

これまでに何度か google code-prettify を用いて記事中にソースコードを挿入してみて、コツが分かってきたのでメモしておく。

（１）ソースコード以外の部分を入力し、 Wysiwyg 表示モードで確認しておく。

（２）ソース表示モードにして、

(a) ”<pre><code class=”prettyprint linenums lang-*”>”

(b) “</code></pre>”

を入力する。（ lang-* の * の部分は、貼りつけたいソースコードの種類から、 code-prettify が持っている lang-* の中から最も近い構文のものを選ぶ。（例） “lang-css” など）

（３） (a) と (b) で囲まれた部分に、ソースコードを貼りつける。貼りつけるソースコードの改行はテキストの状態で改行しておく。改行コードは LF だと余計な改行が勝手に追加されてしまうので、 CRLF にする。１行目は (a) の直後に改行せずつないで書き、最終行は (b) の直前にこちらも改行せずつないで書く。（そうしないと、空白行が出来てしまう。）

（４）ソースコードを挿入したら、 Wysiwyg 表示モードなどに切り替えず、ソース表示モードにしたまま、記事を投稿する。（モードを切り替えてしまうと、ソースコードの改行が削除され、ずらずら１行につながってしまう。

これで、きれいにソースコードが挿入される。