Haikuオペレーティングシステムのデスクトップ。
その後、いくつかの既存のアプリケーションとライブラリを改良しようとしました。 これは、この記事で取り上げるさまざまなオープンソースリポジトリでの私の小さな活動です。 その中で、私が遭遇した問題を一貫して説明し、それらを解決する方法について話します。 私は、Haikuのサポートを提供し、開発者が代替オペレーティングシステムの存在に関心を持つように、この作業中に作成されたパッチのほとんどを上流の既存プロジェクトに送信しようとしました。
Haikuオペレーティングシステムはハイブリッドコアを使用します。これは、必要なモジュールを動的にロードする機能を備えたマイクロカーネルアーキテクチャの実装です。 元Be Inc.エンジニアによって開発されたNewOSカーネルのフォークに基づいています。 、Travis Geiselbrechtによる。 今日、この開発者はGoogleで新しいGoogle Fuchsiaオペレーティングシステム用のZirconと呼ばれるカーネルに取り組んでいますが、それは別の話です。 そのため、Haiku開発者はBeOSとのバイナリ互換性を宣言しているため、2つの使い慣れたアーキテクチャブランチではなく、x86_64、x86、およびx86_gcc2の3つのサポートを強制されます。 後者のアーキテクチャは、 GCC 2.95の古いバージョンのコンパイラとの互換性の負荷です。 彼女のおかげで、元のBeOSオペレーティングシステム用に作成されたアプリケーションを実行できるようになりました。 残念ながら、この互換性の負荷により、Haiku開発者はシステムAPIでC ++プログラミング言語の最新機能を使用できません。 ただし、x86_64とx86の2つのアーキテクチャのみのインストールイメージを準備します。 問題は、x86用のHaikuディストリビューションがハイブリッドであるということです。すべてのシステムコンポーネントはバイナリ互換性のためにx86_gcc2で構築されているという事実にもかかわらず、ユーザーは最新のコンパイラーおよびx86アーキテクチャー向けに設計された最新のアプリケーションをインストールまたは構築する機会が与えられます。 x86_64アーキテクチャのHaikuディストリビューションは完全に64ビットであり、32ビットのBeOSおよびHaikuアプリケーションを実行する機能はありません。 ただし、APIレベルには互換性があるため、BeOSまたはHaiku x86のアプリケーションのソースコードを手元に持っている場合は、Haiku x86_64で簡単にコンパイルでき、すべてが機能するはずです。 特定のBeOSアプリケーションまたは32ビットHaikuアプリケーションをサポートする必要がない場合、x86_64アーキテクチャのオペレーティングシステムイメージを実際のハードウェアにインストールすることをお勧めします。
このオペレーティングシステムでは、 POSIX標準が部分的にサポートされていると言う価値があります。 この基盤により、UNIXに似たシステムに似ており、ソフトウェアの移植が容易になります。 メインのプログラミング言語はC ++です。HaikuのパブリックAPIは主にオブジェクト指向プログラミングパラダイムを追求するため、積極的に使用されています。 それでも、Cプログラミング言語の使用を禁止する人はいません。ほとんどの場合にのみ、対応する互換性レイヤーを記述する必要があります。 オペレーティングシステムのソフトウェアインターフェイスは、特定の機会、たとえばインターフェイスやネットワークサポートを担当する個別のシステムフレームワークにグループ化されます。 これは、 macOSまたはQtフレームワークで利用可能なものに少し似ています。 Haiku開発者はマルチユーザーモードの操作を提供する方向にいくつかのシフトがありますが、このオペレーティングシステムはシングルユーザーであることに注意する必要があります。
Haikuで利用できる高度なアプリケーションウィンドウ管理システムを使用することの前向きな経験を、この記事の読者と共有するしかありません。 私の意見では、これは最も便利なものの1つであり、その点でこのOSの特徴です。
Haikuオペレーティングシステムの高度なウィンドウ管理：タイリングとタブのサポート。
Windowsは、最新のブラウザーで行われているように、タブで互いに固定し、相互に接続し、便利にサイズを変更できます。 単純なタイリング 、一部のアプリケーションのコンテキストをあるウィンドウから別のウィンドウに転送すること、およびレプリカントがサポートされています。 ローカルウィンドウシステムのすべての機能の詳細については、 公式ドキュメントを参照してください 。そこには、必要なすべてのショートカットキーが記載されています。
この記事では、Haikuのすべての機能の完全な概要を説明しません。Haikuに興味のある人は、インターネット上で必要な情報を簡単に見つけることができるからです。
内容：
1. Haikuのパッケージとリポジトリ
2.最初のステップ：Adamant Armor Affection Adventureの移植
3.既存のNXEngineポートの変更（洞窟物語）
4. Gishゲームの移植
5. BeGameLauncherプロジェクト。ゲームのランチャーをすばやく作成できます。
6. Xash3Dの移植：伝説の半減期ゲームと公式アドオン
7.ゲーム「シリアスサム」の2つの部分を移植する：最初の出会いと2番目の出会い
8. Vangersゲームの移植
9. Haiku用のSDL2ライブラリでのダイアログの実装
10. Cool Readerのフォークの移植
11. KeymapSwitcherプログラムの最終化
12.結論
1. Haikuのパッケージとリポジトリ
オリジナルのBeOSと比較して、Haikuには重要な革新が現れました。これは、さまざまなソースからソフトウェアを取得およびインストールするためのさまざまなツールを含むパッケージ管理システムです。 そのようなソースには、 HaikuおよびHaikuPortsの公式リポジトリ、非公式リポジトリ、および単純に別個の特別に準備されたHPKGパッケージがあります。 ソフトウェアをインストールおよび更新するこのような機能は、Unixライクなオペレーティングシステムの世界で長い間知られていましたが、現在ではすべてのパワーと便利さがHaikuに到達しています。 パッケージマネージャーを中心に構築されたインフラストラクチャのおかげで、開発者は新しいオープンソースアプリケーションを簡単に移植したり、既存のオープンソースアプリケーションを変更したり、HaikuPortsソフトウェアポートリポジトリに作業結果を追加したりできます。その後、すべてのHaikuユーザーが利用できるようになります。 結果として、結果のエコシステムは、 Homebrewを備えたmacOSオペレーティングシステム、 ポートを備えたFreeBSD、 MSYS2を備えた Windows、またはAURを備えたArch Linuxに類似しています 。
HaikuPorterと呼ばれるパッケージのビルドとソフトウェアの移植のためのツールは、オペレーティングシステムとは別に提供され、GitHubのリポジトリにある小さなマニュアルを使用してインストールされます。 同じGitHubからこのユーティリティをインストールすると、開発者が作業しているレシピツリー全体がダウンロードされます。 レシピは、HaikuPorterが必要なHPKGパッケージを収集する手順を含む通常のシェルスクリプトです。 ツール自体がPython 2プログラミング言語で記述され、既存のパッケージ管理システムと密接に相互作用し、内部で標準ツールGitを使用してソフトウェアのソースコードへの変更を修正し、一連のパッチを生成することは注目に値します。 このテクノロジースタックのおかげで、HPKGパッケージとソフトウェアパッチをパッチセットファイルの形式で作成するためのレシピを作成するのは非常に便利で簡単です。 ほとんどの場合、HaikuPorterを使用するときは3つのコマンドのみを使用する必要がありました。
alias hp="haikuporter -S -j4 --get-dependencies --no-source-packages" hp libsdl2 hp libsdl2 -c hp libsdl2 -e
最初のコマンドは選択したパッケージを収集し、2番目のコマンドはビルドディレクトリをクリアし、3番目のコマンドはコミットによって作業ディレクトリのGitリポジトリに記録された変更に応じてパッチセットを作成または更新します。
したがって、パッケージをHaikuPortsリポジトリに公開してすべてのHaikuユーザーが利用できるようにするには、開発者はHaikuPorterをインストールし、レシピツリーを展開し、HPKGパッケージをローカルで収集してテストし、レシピツリーのフォークにコミットする必要があります。次に、GitHubでプルリクエストを発行します。 Haiku開発者は公開された作業を検討する必要があります。その後、変更をリポジトリにマージするか、修正のために送信するかを決定します。 変更が受け入れられると、ビルドサーバーにインストールされた同じHaikuPorterがパッケージをリモートで収集し、リポジトリに自動的に公開します。
Haikuオペレーティングシステムの「R1 / beta1」のベータ版に特別なHaikuDepotプログラムが追加されました。これにより、ターミナルのコンソールコマンドではなく、グラフィカルユーザーインターフェイスを介してパッケージとリポジトリを操作できます。
Haikuオペレーティングシステムで実行されているHaikuDepotプログラム。
このツールのおかげで、経験の浅い初心者や初心者のHaikuユーザーがパッケージベースを便利に管理できます。 このアプリケーションは、既存のパッケージマネージャーのGUIシェルであるだけでなく、追加の機能も実装していることに注意してください。 たとえば、許可されたユーザーは、インストール可能なパッケージのレビューを評価および作成できます。 さらに、HaikuDepotには特別なHaiku Depot Webサイトがあり、インターネットでパッケージの変更を表示したり、個々のHPKGパッケージをダウンロードしたりできます。
<<コンテンツへスキップ
2.最初のステップ：Adamant Armor Affection Adventureの移植
VirtualBox仮想マシンのオペレーティングシステムの機能に精通した後、SDL2ライブラリを評価して、先ほどAndroidプラットフォームに移行することについて書いたAdamant Armor Affection AdventureゲームをHaikuに移植することにしました。 プログラムをビルドするのにソースコードを変更する必要はありませんでした。必要なすべてのツール、ライブラリ、ヘッダーファイルをリポジトリからインストールし、次を実行しました。
cmake -DCMAKE_BUILD_TYPE=Release -DGLES=off -DANDROID=off -DCMAKE_C_FLAGS="-D__linux__" -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake --build .
" - D__linux__" -DSDL2_INCLUDE_DIR = `finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR =` finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp -DCMAKE_C_FLAGS =オフ= cmake -DCMAKE_BUILD_TYPE=Release -DGLES=off -DANDROID=off -DCMAKE_C_FLAGS="-D__linux__" -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake --build .
HaikuにはPOSIXがあるため、-D__linux__または-D__unix__定義は 、プラットフォームの定義に関連する多くの問題を解決します。 ただし、同様のビルドの問題がある場合は、プロジェクトソースコードでの使用を中止し、Haikuサポートを実装するのが最善であることに注意してください。 特定の引数を指定してfinddirシステムユーティリティを呼び出すと、さまざまなアーキテクチャのヘッダーファイルへの正しいパスを取得できます。
したがって、上記のコマンドを実行することで、完全に実行可能な実行可能ファイルをコンパイルし、ゲームは完全に機能しました。 ゲームで自給自足のHPKGパッケージを準備するのはクールだと思ったので、必要な情報を探してインターネットに深く入りました。 それから、上記のセクションで書いたHaikuPorterなど、ソフトウェアを移植するための便利なツールについては知りませんでした。そこで、目標を達成するために、システムパッケージをごまかして分解し、内部にどのように配置されるかを確認しました。類推によって行います。
インターネットで必要な情報を見つけ、ローカルファイルマネージャーに組み込まれたExpanderアーカイバーを使用してランダムシステムパッケージを解凍し、 .PackageInfoファイルを見つけて編集し、アプリケーションの構造に従ってファイルを置き換えました。 次に、HPKGパッケージをビルドしてシステムにインストールするコマンドを実行しました。
package create -C AAAA/ aaaa.pkg pkgman install aaaa.pkg
残念ながら、「アプリケーション」メニューからゲームを起動することはできませんでした。 ターミナルで実行可能ファイルを実行すると、アプリケーションの実行と実行に必要なデータファイルを見つけることができないというエラーを受け取りました。 この場合、ターミナルでアプリケーションパッケージのディレクトリに移動すると、すべてが正常に開始されました。 これにより、メニューからゲームを開始するときに、アプリケーションディレクトリを強制的に変更する必要があるという考えが得られました。 これは、シェルスクリプトを使用するか、ゲームのソースを変更することで実行できます。 2番目のオプションを選択し、このコードに似たものを追加しました。
#ifdef __HAIKU__ // To make it able to start from Deskbar chdir(dirname(argv[0])); #endif
開始関数main（）の最初に、この問題を完全に解決し、パッケージが機能することが判明しました。 Linux.org.ruの Haikuベータリリースに関するニュースのコメントで、私は組み立てられたパッケージへのリンクを削除し、このオペレーティングシステムのアクティブなユーザーコミュニティに誘導するように誰かに頼み、就寝しました。
Haikuで実行されるAdamant Armor Affection Adventureゲームポート。
朝、 3dEyesニックネームを使用している人が私にメールを書いた。 後に判明したように、アクティブなHaiku開発者の1人であり、このオペレーティングシステムのQtフレームワークポートの作成者であるGerasim Troeglazovは 、この名前の後ろに隠れていました。 彼は、HaikuPortsリポジトリを見せてくれ、HaikuPorterユーティリティの使い方を教えてくれました。 さらに、彼はAdamant Armor Affection AdventureのHPKGパッケージを作成するためのレシピを作成し、HaikuDepotに追加しました。
この開発者によって行われたすべての変更を分析した後、手動で組み立てられたパッケージにいくつかの欠点があることに気付きました。たとえば、インストールされたパッケージのマウントされたディレクトリには書き込み機能がないため、設定は保存されませんでした。 パッケージに設定や保存を書き込む際のこの問題は、記録のためにアクセスでき、ユーザーデータを保存するための特別なディレクトリにあるシンボリックリンクの助けを借りてエレガントに解決されました。 また、私のパッケージには独自のアイコンがありませんでした。
さらに、Haikuには3Dグラフィックスのハードウェアアクセラレーションがなく、同じOpenGLがCPUパワーを使用してプログラムでレンダリングされることを学びました。 重いグラフィックアプリケーションの場合、これはもちろん良くありませんが、古いゲームではこれで十分です。 ゲームパッケージを具体的にチェックし、Haikuを古いラップトップ、つまり実際のハードウェアにインストールすることも決めました。 驚いたことに、Adamant Armor Affection Adventureの画像は非常に高速にレンダリングされたため、ハードウェアアクセラレーションの欠如について私に言わなかった場合、レンダリングがプロセッサによって行われることに気付かなかったでしょう。
プロジェクトソース： https : //github.com/EXL/AdamantArmorAffectionAdventure
HPKGパッケージの手動作成をより良い時期まで延期し、HaikuPorterツールの使用とレシピの作成に完全に切り替えました。 ただし、パッケージの手動での再組み立てが必要な場合があります。 たとえば、 HaikuPorterが.PackageInfoファイルのHaiku nightバージョンを高すぎる値に設定し、リリースバージョンのオペレーティングシステムでパッケージをテストする必要がある場合。 Gerasimの応答性と経験のおかげで、Haikuオペレーティングシステム用のパッケージを作成することの多くの微妙な点を理解でき、さらに作業を続けたことは注目に値します。
<<コンテンツへスキップ
3.既存のNXEngineポートの変更（洞窟物語）
Cave Storyゲーム用のNXEngineエンジンのフォークにリンクしているレシピをHaikuPortsリポジトリで見つけて非常に驚きました。これは長い間ブログで分析していました 。 レシピとパッチはZoltánMizseiという名前の開発者によって準備されました。彼はニックネームextrowerkを使用し、Haikuの多くのパッケージのアクティブなメンテナーです。
表面的な分析、パッケージのインストール、およびアプリケーションの起動により、この記事の前のセクションで説明したのと同じ問題が明らかになりました。ゲームの保存が機能せず、設定も保存されず、パッケージに元のアイコンがありません。 私はこれらの欠点を修正することに決め、最初にextrowerkのすべての作業を統合して、パッチの作業を開始しました。 Haikuオペレーティングシステム用のオリジナルのMakefileを作成し、さまざまなユーザーデータの書き込みと保存を修正しました。
Haikuオペレーティングシステムで起動されたNXEngineエンジンに基づいたCave Storyゲームのポート。
ゲームではロシア語版と英語版が異なる実行可能ファイルとデータファイルのセットを想定しているため、2つのバージョンを一度に組み合わせて、ユーザーが選択したシステム言語に基づいて適切なバージョンを自動的に選択する共通パッケージを作成することにしました。 これは、最も単純なシェルスクリプトによって実装されました。
#!/bin/bash if [[ `locale -l` == ru* ]] ; then EXE="`finddir B_SYSTEM_APPS_DIRECTORY`/NXEngine/RUS/Cave Story" else EXE="`finddir B_SYSTEM_APPS_DIRECTORY`/NXEngine/ENG/Cave Story" fi "$EXE" $@
このスクリプトは、[アプリケーション]メニューでゲームアイテムが選択されたときに起動され、現在のシステムロケールを決定します。 ユーザーがシステム言語としてロシア語を選択した場合、ゲームのロシア語版が起動し、その他の場合はすべて英語版が起動します。
しかし、アプリケーションの元のアイコンを作成すると、かなりいじることが必要になりました。 実際には、Haikuオペレーティングシステムでは、 Be File Systemファイルシステムの属性として設定されている特別なHVIF形式のベクトルアイコンのみが許可されています。 公式ドキュメントには、アプリケーション用の独自のアイコンの作成に関する2つの大きなマニュアルがあります。 最初のマニュアルでは、描画とデザインのスタイルについて説明し、 2番目のマニュアルでは、 アイコン作成用に設計されたIcon-O-Maticシステムプログラムの使用方法について詳しく説明しています。
Icon-O-Maticを使用すると、最も単純なSVGファイルをインポートし、結果のアイコンをHaikuPorterに必要な形式（HVIF RDefと呼ばれ、同じHVIFを表すがテキストビューに変換される形式）にエクスポートできます。 RDefファイルには、画像だけでなく、アプリケーションのバージョンやその説明などの追加情報も含めることができます。 ある意味では、これらのファイルはWindowsで使用されるRESファイルに似ています。 レシピの次のコマンドは、RDefファイルをコンパイルし、結果を特別な属性に設定します。
rc nxengine-launcher.rdef resattr -o "$appsDir/NXEngine/Cave Story" nxengine-launcher.rsrc addResourcesToBinaries $sourceDir/build/nxengine-rus.rdef "$appsDir/NXEngine/RUS/Cave Story"
さらに、関数addResourcesToBinariesがレシピで定義されているため、この作業を自動化できます。 Icon-O-Maticの問題は1つですが、非常に深刻です。人気のあるInkscapeベクトルエディターが保存するSVGファイルは開かないか、勾配などの必要な機能をサポートせずにインポートされます。 したがって、さまざまな有料および無料のオンラインおよびオフラインコンバーターを使用してラスターイメージをベクターイメージに変換し、その結果のSVGファイルをIcon-O-Maticプログラムで開くアドベンチャークエストは、惨めに失敗しました。 後で、SVGファイルを開く問題を解決し、回避策を見つけましたが、これについては以下で説明します。 それまでの間、Icon-O-Maticプログラムの標準機能を使用して、自分でアイコンを描画することにしました。 30分間のピクセルのハードコピーの後、次のアートを得ました。
Haikuオペレーティングシステムの標準Icon-O-Maticプログラム。
はい、ピクセルエディターのジャンルで画像を作成するためにベクターエディターを使用しました。 芸術にあまり精通していない男性に対する私のアマチュア的な見方では、それは非常にうまくいきました。 このアイコンを目的の形式で保存し、すべての変更を準備し、レシピを更新して、すべてをHaikuPortsリポジトリに送信しました。
プロジェクトソースコード： https : //github.com/EXL/NXEngine
念のため、作成したパッケージをゲームCave Story（同Do物語）のファンサイトに送信しました。このサイトでは、管理者がHaikuオペレーティングシステムをダウンロードセクションに追加しました。
<<コンテンツへスキップ
4. Gishゲームの移植
私がHaikuに移行することにした次のプロジェクトは、以前Androidに移植したGishゲームです。 HaikuPortsリポジトリには、Freegishと呼ばれるゲームの未完成の無料実装のレシピがありました。そこで、元のゲームも追加することにしました。ただし、データファイルはありません。エンジンとは異なり、個別に配信され、まったく無料ではありません。
Haikuオペレーティングシステムで実行されるGishゲームポート。
このゲームの移植に関して特別な問題はありませんでした。 実行可能ファイルは、次のビルドコマンドが実行された直後にコンパイルされました。
cmake gish/src/main/cpp/ \ -DGLES=0 \ -DANDROID=0 \ -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` \ -DCMAKE_C_FLAGS="`sdl2-config --cflags` -D__linux__" \ -DCMAKE_BUILD_TYPE=Release cmake --build .
次に、「アプリケーション」メニューからゲームを起動する機能を実装し、記録のためにアクセス可能なディレクトリにユーザーデータを保存するためのサポートを提供しました。
char* getHaikuSettingsPath() { char path[PATH_MAX]; find_directory(B_USER_SETTINGS_DIRECTORY, -1, false, path, sizeof(path)); strcat(path, "/Gish/"); return strdup(path); }
Haiku APIのfind_directory（）関数を使用するgetHaikuSettingsPath（）関数は、必要なディレクトリへのフルパスを形成します。
プロジェクトソースコード： https : //github.com/EXL/Gish
次の質問を解決するために残りました：ユーザーは、Gishゲームの元のファイルを含むディレクトリをどのように選択する必要がありますか？ シェルスクリプトとアラートシステムユーティリティを使用して問題の解決を試みることもできますが、この問題にさらに徹底的に取り組み、Haiku APIとInterface Kitフレームワークを使用して便利なGUIランチャーを実装することにしました。
<<コンテンツへスキップ
5. BeGameLauncherプロジェクト。ゲームのランチャーをすばやく作成できます。
1998年の古い標準で、BeGameLauncherプロジェクトをC ++で記述し、オペレーティングシステムのネイティブツールを使用してグラフィカルユーザーインターフェイスを備えたアプリケーションを作成することにしました。 HaikuとBeOSの多くのプログラムの名前は「Be」プレフィックスで始まるため、私はそのようなプロジェクト名を選択することも決めました。 Haiku APIの一部であるInterface Kitフレームワークに慣れることから始めることにしました。 公式のHaiku Webサイトにあるかなり詳細なドキュメントに加えて、初心者の開発者が特定のシステムクラスがどのように機能するかをすばやく理解できる、2つの単に優れたDarkWyrmレッスンコースを見つけました。 最初のコースは、Haikuを使用したプログラミングの学習と呼ばれ、最初はC ++プログラミング言語の基礎をカバーします。これは初心者にとって非常に役立ちます。 2番目のコースは、 Haikuでのプログラミングと呼ばれ、すでにC ++に精通しており、この言語の基本的な知識がある人を対象としています。 どちらのコースも、Haiku APIの最も多様な側面について説明しているため、このオペレーティングシステム用のアプリケーションの作成を開始したい人にとって非常に役立ちます。
この優れた資料を斜めに読んだ後、Haiku APIについて一般的な印象を与え、次のステップについて考え始めました。 私はすでにC ++プログラミング言語で記述され、オブジェクト指向プログラミングパラダイムを使用するQtフレームワークを使用してアプリケーションアプリケーションを開発した経験があります。 そのため、Haiku APIは、シグナルとスロットシステムがないことを除いて、非常に似ています。そのため、Qtとの類似点や比較をよく取り上げます。 さらに、Haiku APIで一般的なイベント駆動型プログラミングの原則を使用することも注目に値します。HaikuAPIでは、さまざまなエンティティがイベントまたはメッセージの送信を通じて相互にやり取りできます。 ここでのQEventクラスの類似物はBMessageクラスであり、その周りにオブジェクトの相互作用のシステムが構築されます。 BMessageクラスのインスタンスは通常、一意の番号を取得します。これにより、一般的なイベントフィルターで送信者とそのアクションを識別できます。
私のプロジェクトでは、目的の機能を実装できる適切なHaiku APIクラスを選択する必要がありました。 まず、外部アプリケーションを起動するには、 QProcessクラスまたはexecve（） POSIX関数の類似物を見つける必要がありました。これは、ちなみにHaikuオペレーティングシステムでも正常に機能しますが、ネイティブツールを使用することが望ましいと判断しましたが、このケースでは、POSIX関数を介してアプリケーションを実行する機能が残っていました。 プロセス間通信クラスBRosterは 、この目的に最適でした。 実行可能ファイルへのパスを指定して引数を渡すことができる適切なLaunch（）メソッドが見つかりました。 ランチャーはいくつかのパラメーター（たとえば、ユーザーが選択したゲームデータファイルのディレクトリ）を保存できるはずなので、これをすべて行うクラスが必要でした。 Qtでは、このようなクラスはQSettingsと呼ばれ、Haiku APIでは、 Gerasimからの指示に従って 、非常に便利な機能を備えたBMessageクラスが既にわかっています。 問題は、このクラスの情報を簡単にシリアル化し、たとえばディスクに保存できることです。 これは非常に便利で、多くの場合、ユーザーデータをプログラムに記録するために使用されます。そのため、ランチャーを実装するためにプロジェクトに設定を保存するためにこのクラスを選択しました。残念ながら、Haiku APIはQDebugクラスの類似物を見つけられなかったため、開発プロセス中に標準Cプログラミング言語のfprintf（）関数を使用してstderrにデバッグ出力を送信しました。
// .h #if __cplusplus >= 201103L #define BeDebug(...) fprintf(stderr, __VA_ARGS__) #else extern void BeDebug(const char *format, ...); #endif // __cplusplus == 201103L // .cpp #if __cplusplus < 201103L #include <cstdarg> void BeDebug(const char *format, ...) { va_list args; va_start(args, format); vfprintf(stderr, format, args); va_end(args); } #endif
この関数は、私にとって便利なBeDebug（）エンティティでラップしました。これは、選択した言語標準に応じて、マクロまたは関数のいずれかです。これは、C ++ 98が可変数の引数を持つマクロをサポートしていないという事実のために行われました。
Qtフレームワークには、ユーザーが注意を払う必要のある情報（エラーや警告など）を含むモーダルダイアログを作成できる便利なQMessageBoxクラスもあります。 Haiku APIには、この目的のためのBAlertクラスがあります。その実装はQtで利用可能なものとはわずかに異なります。たとえば、このクラスのオブジェクトは、スタックではなくヒープ上に作成する必要があります。これは、何らかのユーザーアクションの後、自身を削除する必要があるためです。グラフィカルインターフェイスの他のクラスについては、ここではまったく問題がなく、問題なく必要なものがすべて見つかりました。
ここで、プロジェクトの単純なアーキテクチャについて考えるべきでした。静的ライブラリの作成に焦点を当てることに決めました。静的ライブラリには、独自の派生クラスを継承するように設計された2つのクラスがあります。最初で最も重要なクラス、BeLauncherBase、メインランチャーウィンドウの作成、すべてのユーザーパラメーターの転送を担当し、独自のGUI要素を追加する機能を提供します。2番目のクラスBeAboutWindowは、別のウィンドウに表示される情報を使用して「プログラムについて...」ダイアログを開くだけです。したがって、プログラマーは、ランチャーを作成するために、たとえばGishをプレイするための2つの簡単なステップを実行する必要があります。
class GishAboutWindow : public BeAboutWindow { ... }; class GishLauncher : public BeLauncherBase { ... }; int main(void) { BeApp *beApp = new BeApp(SIGNATURE); GishLauncher *gishLauncher = new GishLauncher(BeUtils::GetPathToHomeDir()); beApp->SetMainWindow(gishLauncher); beApp->Run(); delete beApp; beApp = NULL; return 0; }
まず、適切な開始関数main（）を作成し、次に、上記の2つのクラスを単純に継承し、それらに必要なメソッドを実装します。その後、静的ライブラリへのリンクを含むC ++ファイルをコンパイルし、Gishゲームのランチャーの準備が整いました。
ゲームGishのポートのランチャーにあるダイアログ「プログラムについて...」
次に、ランチャーからエンジン自体またはゲームの実行可能ファイルにパラメーターを転送する方法について考えました。この問題を解決する方法は2つしかありませんでした。最初の方法は、環境変数を変更することでした。実際には、「実行」ボタンをクリックした後、ランチャーは単にsetenv（）関数を呼び出してすべてのパラメーターを環境変数に入れ、ゲームエンジンはgetenv（）関数を使用してこれらのパラメーターを読み取ります。ここで発生する可能性のある唯一の問題は、BRosterクラスとそのLaunch（）メソッドにありました：このクラスの助けを借りて起動されたアプリケーションが、ランチャーで設定されたすべての環境変数を継承するかどうかは知りませんでした。少し実験した後、環境変数の継承が確認され、このメソッドをプロジェクトに完全に実装しました。問題を解決する2番目の方法は、特別なコマンドラインパラメーターを設定することでした。実際には、ランチャーは単にすべての設定を適切な引数に入れ、それらを使用してアプリケーションの実行可能ファイルを呼び出します。しかし、ゲームエンジンは既にそれらを個別に処理する必要があり、いくつかの困難が生じました。たとえば、ゲームがコマンドラインパラメーターを介してゲームファイルへのパスを指定する可能性を想定していない場合、エンジン自体の引数パーサーを変更する必要がありました。これらの問題にもかかわらず、この相互作用の方法を実装した結果、すべてを組み合わせる絶好の機会を得ました。これにより、一部のランチャーでユーザー引数を指定するための文字列を作成できました。
すべてが設計されたとき、プロジェクトにアセンブリシステムを選択することにしました。 2つのオプションだけが考慮されました：Makefile "on steroids"およびCMake。最初のケースでは、Haikuオペレーティングシステムの開発者が便利なmakefile-engineパッケージを準備し、Haiku APIでアプリケーションの作成を開始することで開発者が直面するすべての必要な機能（翻訳の自動生成やアプリケーションリソースのコンパイルなど）を収集しました。しかし、私は簡単な方法を探している人ではないので、CMakeを選択し、makefile-engineパッケージから作業の一部をそれに移しました。その結果、プロジェクトリポジトリ内の結果の巨大なアセンブリスクリプトを確認できます。リンクは以下に残しておきます。
Haiku用のGishゲームポートランチャーのスクリーンショット。
アプリケーションのローカライズについて少し説明したいと思います。 Qtフレームワークには、このための便利なtr（）ラッパー関数、2つの補助ユーティリティlreleaseおよびlupdateがあり、これらは翻訳ファイルの生成に関与しています。フレームワークには、翻訳者向けに設計された便利なグラフィカルユーザーインターフェイスを備えた特別なQt Linguistプログラムも含まれています。 Haiku APIでは、アプリケーションローカリゼーションツールはあまり便利でなく、古風です。翻訳する必要がある行を特別なマクロB_TRANSLATE（）でラップし、定義B_TRANSLATION_CONTEXTをソースファイルに追加することをお勧めします。、翻訳可能な文字列のグループを別のグループから分離します。その後、非常に奇妙なことを行う必要があります。すべてのプロジェクトソースファイルで-DB_COLLECTING_CATKEYSフラグを使用してコンパイラプリプロセッサを設定し、grepユーティリティを使用して魔法をかけ、最後に巨大なPREファイルを取得します。collectcatkeysユーティリティが機能するのは、このファイルを使用することです。これにより、翻訳者向けに人間が読み取り可能でユーザーフレンドリーなCATKEYSファイルが既に作成されます。文字列をローカライズした後、linkcatkeysユーティリティを使用する必要があります、実行可能ファイルのリソースに翻訳を追加します。したがって、特定のシステム言語を選択すると、アプリケーションは翻訳された行を表示します。奇妙なことに、アプリケーションのローカリゼーションに関するHaiku APIドキュメントにはほとんど情報が含まれていません。しかし、公式サイトで、このオペレーティングシステムのアプリケーション翻訳の多くの側面を詳述した優れた記事Localizing an applicationを見つけました。私の理解では、元のBeOSにはLocale Kitフレームワークがなく、Haikuにのみ追加されました。
次のステップは、C ++プログラミング言語でアプリケーションを開発するための環境を選択することでした。俳句は次のように、リポジトリなどHaikuPorts IDEで利用可能な、Qtフレームワークに移植されたという事実のためのQt CreatorをとKDevelop。さらに、JVMポートがあります。これにより、NetBeansやIntelliJ IDEAなどのJavaプログラミング言語で記述されたIDEを使用できます。 Qt Creator開発環境を選択しました。特に最新バージョンでは、LibClangパーサーを使用したコードの高品質分析があり、標準パーサーよりもはるかに正確かつ高速に動作します。
Haikuオペレーティングシステムで実行される統合開発環境Qt Creator。
Haikuのよく知られたクロスプラットフォームIDEに関しては、すべてがうまくいきます。しかし、排他的なソリューションはどうでしょうか？DarkWyrmが後援し、現在Adam Fowlerをサポートしている、Paladinと呼ばれる非常に興味深いプロジェクトに言及するしかありません。このプログラムにより、オペレーティングシステムのディストリビューションでPeテキストエディタをほぼ実際のIDEで使用できます。
HaikuPortsリポジトリからインストールされた、Haiku用のPaladin IDE。
Haikuウィンドウシステムに統合されたタイルを使用して、Peエディターの側面にPaladinウィンドウを接続し、ターミナルを追加できます。また、HaikuPortsリポジトリには、Windows用の一般的なNotepad ++プログラムに似た便利なKoderテキストエディタがあり、Scintillaプロジェクトの経験に基づいています。私のアプリケーションでは、プロジェクトPLDファイルを作成しました。PaladinIDEを使用する開発者であれば、このプログラムでプロジェクトを簡単に開くことができます。
Qt Creator開発環境がセットアップされて準備が整ったとき、私は計画されたすべての機能を実現し始めました。最初に遭遇した問題は、システムフォントのサイズを変更する際のコントロールのスケーリングに関するものでした。当初、BeOSでは、GUI要素を配置するためのコード全体が座標で明示的に設定されていました。非常に不便で冗長であり、たとえば同じフォントサイズの変更でアプリケーションのフォーム全体が分散して使用できなくなるなど、膨大な問題が山積みになりました。幸いなことに、Haikuはこの問題を解決しようとし、Interface Kitフレームワークの一部であるLayout APIを追加しました。
レイアウトAPIを使用することにより、ランチャーはHaikuのシステムフォントのサイズの変更に正しく応答します。
この革新により、ポジショニングコントロールに関する問題が完全に解決され、レイアウトAPIを使用してアプリケーションを書き直しました。これにより、一部の場所でコード長が大幅に短縮されました。 Haikuの公式Webサイトで、Laying It All Outという一連の興味深い記事を見つけました。この記事では、このソフトウェアインターフェイスが作成された理由を説明し、その使用例を示しています。
Gerasimは、私のライブラリを使用して、移植したゲームのランチャーを作成しようとしたときに別の問題を特定しました。問題は、Haikuオペレーティングシステム自体のソースコードに目を向けて、さまざまな機能を実装することでした。特に、そこでBRosterクラスのオブジェクトでLaunch（）メソッドを使用する例を見つけました。問題は、この例が正しくなく、Gerasimによって移植されたゲームエンジンがランチャーによって設定された引数を正しく解析できなかったという事実に現れました。 Haikuのソースコードをさらに詳しく調べたところ、Launch（）メソッドの場合、自動的に設定されるため、実行可能ファイルへのフルパスを含む必要がある最初の引数を明示的に設定する必要はないことがわかりました。
// Error const char* args[] = { "/bin/open", fURL.String(), NULL }; be_roster->Launch(&ref, 2, args); // Good const char* args[] = { fURL.String(), NULL }; be_roster->Launch(&ref, 1, args); // See "src/kits/app/Roster.cpp", BRoster::ArgVector::Init() method: if (error == B_OK) { fArgs[0] = fAppPath.Path(); // <= Here if (argc > 0 && args != NULL) { for (int i = 0; i < argc; i++) fArgs[i + 1] = args[i]; if (hasDocArg) fArgs[fArgc - 1] = fDocPath.Path(); } // NULL terminate (eg required by load_image()) fArgs[fArgc] = NULL; }
Launch（）メソッドのドキュメントには、最初の引数が不要であると書かれていません。これがおそらく開発者がこのコードを誤って書いた理由です。私は自分のプロジェクトでこのエラーを修正し、Gerasimの問題は自動的に解決しました。しかし、Haikuオペレーティングシステム自体のこの小さな間違いはどうでしょうか。私もそれを修正することにしました。幸いなことに、それは非常に簡単であることがわかりました！ GitHubを使用してHaiku Code Review Gerritリソースにログインし、SSH公開キーを追加し、Haikuソースコードをフォークし、コミットコミットを作成し、結果のパッチをCode reviewに特権開発者に送信する必要があります。
git clone ssh://EXL@git.haiku-os.org/haiku --depth=1 -b master && cd haiku git commit git push origin master:refs/for/master
既に送信されたパッチを更新する必要がある場合、変更または新しいコミットを送信する前に、コミットメッセージの最後にHaiku Code Reviewサービスから提供されたIDを追加してください。パッチの送信後、Haiku開発者は修正のために承認、拒否、または提出する必要があります。私の場合、修正はすぐに受け入れられ、この小さな欠陥は現在どこでも修正されています。リポジトリにパッチを送信する前にパッチをテストする必要がある場合は、Perforce Jamビルドシステムのフォークであり、Haikuオペレーティングシステムのコードベース全体をビルドするために使用されるjamユーティリティを使用して、別のアプリケーションをコンパイルすることができます。ソースコードリポジトリには、ReadMe.Compiling.mdファイルがあります。、コンパイルのすべてのトリックに対処するのに役立ちます。
私のプロジェクトを仕上げている間に、Icon-O-MaticプログラムがInkscapeベクトルエディターを使用して作成されたSVGファイルを開かない理由を見つけました。問題は、Icon-O-MaticはviewBox属性を処理できないことですが、この属性のない単純なSVGファイルを見つけてInkscapeで編集し、プレーンSVGファイルとして保存すると、Icon-Oで開きます -マティック。そのため、編集可能で、問題なくIcon-O-Maticで開く特別に準備されたSVGファイルをリポジトリに配置しました。さらに、プロジェクトのReadMeファイルに、Inkscapeを使用してランチャー用のアイコンを作成する方法に関する簡単な説明を追加しました。
さまざまな静的アナライザーを使用してプロジェクトのコードをチェックすることにしましたが、深刻な問題は見つかりませんでした。しかし、後で、彼らが検出できない問題を見つけました。静的メソッドという事実GetBitmap（）クラスBTranslationUtilsが NULLを返すことができます：
// Somewhere fBitmap = BTranslationUtils::GetBitmap(B_PNG_FORMAT, fIndex); void BeImageView::Draw(BRect rect) { // Fail const BRect bitmapRect = fBitmap->Bounds(); ... }
また、Draw（）メソッドでは、fBitmapクラスのフィールドの有効性を確認するのをうっかり忘れていました。そのため、特定の画像が見つからなかった場合、アプリケーションは予期せずクラッシュしましたが、計画によると、代わりに赤い正方形を描画することでした。この話では、静的アナライザーは万能薬とはほど遠く、C ++プログラミング言語でコードを操作する際には注意を払う必要があります。
BeGameLauncherプロジェクトのソースコードとすべてのベストプラクティスがGitHubのリポジトリにアップロードされます。このプログラムが誰かに役立ち、Haikuのシンプルなアプリケーションとしてのある種のチュートリアルになることを願っています：
プロジェクトソースコード：https : //github.com/EXL/BeGameLauncher
HaikuPortsリポジトリーのレシピで私のランチャーを使用する人へのちょっとしたアドバイス。一部のプログラムが読み取り、ランチャーのみをそこに残すHaikuアプリケーションのリストからゲームの実行可能ファイルを非表示にする場合は、次のトリックを使用できます。
settype -t application/x-vnd.Be-elfexecutable $appsDir/Gish/engine/Gish rc $portDir/additional-files/gish.rdef -o gish.rsrc resattr -o $appsDir/Gish/engine/Gish gish.rsrc
これにより、アプリケーションのクイック起動を行うQuickLaunchなどのさまざまなプログラムからランチャーによって渡されるパラメーターなしで実行可能ファイルを実行する機能が除外されます。この場合、実行可能ファイルの元のアイコンが保存されます。
<<コンテンツへスキップ
6. Xash3Dの移植：伝説の半減期ゲームと公式アドオン
Xash3Dプロジェクトは、ゲームHalf-Lifeおよびその公式アドオンで使用されるGoldSrcエンジンの無料実装です。 Xash3Dの開発の背後には、国内のプログラマーであるミシャおじさんがいます。彼はまだ開発と改善を調整しています。少し後に、Windows以外の膨大な数のオペレーティングシステムをサポートして、FWGS Xash3Dのフォークを作成した他の開発者がプロジェクトに参加しました。今日、FWGS Xash3Dプロジェクトの主要なプログラマーはmittornとa1batross（libpony）であり、最後の人はかつて人気のあったMotoFan.Ruフォーラムに積極的に参加していました , .
: Haiku, Xash3D , Haiku Half-Life, ? — .
, , Xash3D, Haiku. -, -D__linux__実行可能ファイルと多数のライブラリをビルドしようとしました。驚いたことに、事態は非常に速く、夕方までにゲームのデータファイルを転送し、ハーフライフを起動して、ブラックメサのメインステーションまで電車に乗りました。
Qash Creator IDEでXash3DエンジンをHaikuに移植するプロセス。
プロジェクトではクロスプラットフォームのSDL2ライブラリを使用しているため、プラットフォームに依存するコードを記述する必要がないため、エンジンの移植が大幅に簡素化されます。たとえば、サウンドの出力、OpenGLコンテキストを使用したウィンドウの作成、入力イベントの処理などです。これらはすべてSDL2ライブラリに既に実装されており、すぐに使用できます。 Haikuにはネットワークスタックを実装する別のライブラリがあり、エンジンにリンクする必要があるため、ネットワークサポートで小さな問題が発生しました。
ランチャーを作成するプロジェクトは、私がもう少し上に書いたものですが、とても役に立ちました。 C ++クラスの継承を使用して、その機能を真剣に拡張し、ゲームへのさまざまな追加を選択する機能を実装しました。
Haiku用のXash3Dエンジンポートランチャーのスクリーンショット。
アイデアは次のとおりです。特定のアドオンを起動するためにゲームエンジンを柔軟に調整できる3つの環境変数を定義すること。この場合、ユーザーが実行可能ファイルのさまざまな引数で遊んで、必要なデータファイルのあるディレクトリにあるだけのエンジンのポータブル起動の可能性を残しておくと便利です。したがって、最初の環境変数XASH3D_BASEDIRは、ユーザーがランチャーから選択したゲームファイルを含むディレクトリを担当します。 2番目の変数XASH3D_GAMEは、ユーザーがランチャーで開始することを選択した追加項目を担当します。そして、ここに3番目の変数XASH3D_MIRRORDIRがあります、上級ユーザーのみに役立ちます。 Xash3Dシステムディレクトリをユーザーが書き込み可能なディスク領域にミラーリングできます。したがって、Haikuの下でXash3Dエンジンでアドオンゲームをリリースしたい人は、プロジェクトのソースコードからさまざまなアーキテクチャのいくつかの動的ライブラリを収集するだけです
。•./cl_dlls/libclient-haiku.so
•./dlls/ libserver -haiku .so
•./cl_dlls/libclient-haiku64.so
•./dlls/libserver-haiku64.so
そして、それらをアドオンの適切なディレクトリに配置します。私のXash3D移植版では、Half-Lifeゲームの人気アドオン、つまりBlue ShiftとOpposing Forceのライブラリをプリコンパイルすることにしました、ユーザーはデータファイルをダウンロードし、ディレクトリを選択して、ライブラリをコンパイルせずにゲームを開始できます。
Xash3Dエンジンを移植する過程で、おかしな問題に遭遇しました。--helpパラメーターが渡されたときに生成される実行可能ファイルの引数のヘルプメッセージの長さを決定するために、エンジンは定義済みのサイズのMAX_SYSPATH定数を使用しました。これは、別のMAX_PATH定数のエイリアスです。だから、長い間、なぜこの証明書が不完全に発行され、最も興味深い場所で切断されたのか理解できませんでした。最初に私はそれを標準エラー出力ストリームに奇妙な方法で罪を犯しましたstderrはバッファリングを接続し、強制的に無効にしようとしました。しばらくして、HaikuオペレーティングシステムのMAX_PATH定数が非常に小さいことに驚いたことを思い出しました。この定数は、1024バイトのパスサイズを想定しています。メッセージサイズを標準の4096バイトに増やすとすぐに、私の推測は完全に成功しました。問題は解決しました。この面白い話から次の結論を引き出す必要があります。MAX_PATH定数は、ファイルパスに関連付けられていない文字配列では使用しないでください。
HaikuオペレーティングシステムでXash3Dエンジンを使用して立ち上げられたゲームHalf-Lifeのスクリーンショットのコラージュと、公式に追加されたBlue ShiftおよびOpposing Force（プレビュー、参照により増加）。
別の問題は、エンジン自体の機能を使用してゲームのアドオンを選択するとクラッシュすることでした。 XASH_INTERNAL_GAMELIBS定義セットを使用すると、クライアントライブラリが1回ではなく2回ロードされたことが判明しました。これには同様の問題が伴いました。a1batrossが私に説明したように、これはOpenVGUIライブラリをクライアントライブラリに静的にリンクできるようにするために行われました。 HaikuのXash3Dポートでは、このライブラリはまったく使用されないため、デフォルトの使用を避けましたXASH_INTERNAL_GAMELIBSおよびこのバグをエンジンの開発者に報告しました。
次に、Xash3Dで実行されているゲーム内のリンクをクリックすると、Haiku に組み込まれたWebPositiveブラウザーを開くことができないことに気付きました。問題は本当に奇妙でした。なぜなら、ターミナルからエンジンを起動したとき、ブラウザが開いたのですが、ランチャーを使用して起動したとき、彼はそれを拒否しました。コードを少し調べたところ、そこでexecve（）という呼び出しが見つかりました。これをsystem（）に置き換えようとしましたが、その後問題なくブラウザが開き始めました。
Xash3Dエンジンは、エラー発生時にSDL_ShowSimpleMessageBox（）およびSDL_ShowMessageBox（）関数の呼び出しを積極的に使用します。、Haiku用のSDL2ライブラリの現在のポートのみがこれらのダイアログの作成をサポートしていません。ライブラリのバージョンには、この機能がありません。ただし、この問題の修正については後述します。
Haiku Depotリポジトリに公開されたXash3Dエンジンのポート。
Xash3DエンジンをHaikuに転送する前に、Gerasim TroeglazovがSDL2でマウスカーソルキャプチャを実装したことも注目に値します。それ以前は、3Dゲームをプレイすることはほとんど不可能でした。少し後に、彼はトリッキーなバグを修正しました。このバグでは、宇宙空間でのプレイヤーの動きが徐々に遅くなり、ゲームがひどく遅くなり始めました。デフォルトでは、マウスカーソルイベントは、画面上の動きのすべての履歴とともに送信されていました。したがって、この物語はゲーム中に急速に膨らみ、すべてが大きく減速し始めました。 Haiku SDL2ポートでこの機能を無効にすると、この問題が解決され、問題なくHalf-Lifeをプレイできるようになりました。ただし、弱いハードウェアでの3Dアクセラレーションの欠如は、それ自体が感じられます。また、ゲームがウィンドウ内で適切に機能し、まったくスローダウンしない場合、フルスクリーンモードではFPSが大幅に低下します。ただし、ここでは、少なくとも一般的なIntelプロセッサに組み込まれているGPUの場合、ビデオドライバーにハードウェアアクセラレーションを追加するだけです。
プロジェクトのソースコード：https : //github.com/FWGS/xash3d
リポジトリで受け入れたFWGS Xash3Dプロジェクトの開発者にソースコードへのすべての変更を送信しました。 。
<<コンテンツへスキップ
7.ゲーム「シリアスサム」の2つの部分を移植する：最初の出会いと2番目の出会い
最近、Croteamの開発者がSerious Engineシリーズのソースコードを投稿しました。これはSerious Samシリーズのゲームで使用されています：First EncounterとThe Second Encounter。私はそれをHaikuオペレーティングシステムに移植し、ソースコードをダウンロードして作業を開始することにしました。
Haiku用のSerious Engineポートランチャーのスクリーンショット。
変更後の実行可能ファイルのアセンブリは問題なく行われましたが、エラーがSDL2ダイアログに注入されたため、ゲームの起動はそれほど容易ではありませんでした。この実装は、Haikuのこのライブラリのバージョンでは使用できません。そのため、実績のある標準エラー出力ストリームであるstderrを選択し、問題をゆっくりと整理する必要がありました。これは、主に必要なゲームデータファイルがないことが判明しました。
Serious Samのスクリーンショット：HaikuオペレーティングシステムのSerious Engineポートを使用して起動したSecond Encounterゲーム。
ダウンロードしたファイルを必要なディレクトリに分解したので、この素晴らしいゲームの2番目の部分を問題なく実行でき、美しいジャングルを少し走り抜けることさえできました。 3Dアクセラレーションがないにもかかわらず、フルスクリーンモードではなくウィンドウで実行すると、プロセッサはゲームのグラフィックチャームを描画します。もちろん、このエンジンは、上で書いたXash3Dエンジンよりもはるかに低いFPSで動作しますが、ここのグラフィックスはよりモダンで優れています。ちょっとした操作の後、ゲームの最初の部分を起動することができました。これには、異なる実行可能ファイルと異なる動的ライブラリのセットが必要です。驚いたことに、彼女は少し速く稼いで、明らかにその中のグラフィックスはそれほど厳しいものではありません。エンジンの設定を登ると、プロセッサーの負荷を大幅に減らすことができる膨大な数のグラフィカルパラメーターが見つかりました。Haikuの場合、これは非常に役立つことが判明しました。
Serious Samのスクリーンショット：Haikuオペレーティングシステム用のSerious Engineのポートを使用して開始されたFirst Encounterゲーム。
ゲームの2つの部分に一度に1つのパッケージを作成することにしました。それらの切り替えは、適切なデータファイルのセットがあるディレクトリを選択するだけで実行されます。たとえば、ランチャーのユーザーがゲームSerious Sam：The First Encounterのファイルを含むディレクトリを選択すると、対応する実行可能ファイルが起動され、対応する動的ライブラリのセットがロードされます。そして、彼がゲームSerious Sam：The Second Encounterのファイルを含むディレクトリを選択すると、ランチャーはそれに応じて、共有ライブラリのセットをロードする別の実行可能ファイルを起動します。
残念ながら、問題がなかったわけではありません。ゲームのビデオモードの解像度を繰り返し変更すると、エンジン全体が低下しました。この場合、私のLinuxディストリビューションでは、このクラッシュはそうではありませんでした。問題の特定と修正に多くの時間を費やしました。全体のポイントは、解像度を変更するたびに、SDL_Windowウィンドウが破壊され、再び作成されることがわかった同時に、OpenGLレンダラーは時間内に切り替えることができず、台無しになったウィンドウにそこに何かを描画しようとしました。 HaikuのSDL2ライブラリへの移植がこのようなトリックを起こすことはできませんでした。この問題を解決するための簡単な試みはすべて役に立たなかったため、解像度を変更してもウィンドウが壊れないようにロジックに真剣に取り組み、動作を変更する必要がありましたが、そのパラメーターは単に変更されました。これはクラッシュを取り除くのに役立ちましたが、追加の制限を追加しました：今、フルスクリーンモードをアクティブにするには、エンジンを再起動する必要があります。
別の問題は、ゲーム内の音楽の不足でした。ただし、Linuxでは、この問題は発生しませんでした。エンジンのソースコードを調べると、音楽の再生はlibvorbisfileライブラリに依存していることがわかりました。、しかしエンジン自体はリンクしませんが、dlopen（）システム関数を使用してOGGオーディオファイルストリームをこのライブラリにフィードします。問題は、バージョンのないライブラリファイルへのシンボリックリンクがないため、エンジンがHaikuでこのライブラリを見つけられなかったことです。
void CUnixDynamicLoader::DoOpen(const char *lib) { // Small HACK for Haiku OS (: #ifdef __HAIKU__ static int vorbis_cnt = 3; char path[PATH_MAX]; char libpath[PATH_MAX]; find_directory(B_SYSTEM_LIB_DIRECTORY, -1, false, libpath, PATH_MAX); if (strstr(lib, "vorbis")) { snprintf(path, sizeof(path), "%s/libvorbisfile.so.%c", libpath, char(vorbis_cnt + '0')); vorbis_cnt++; lib = path; } #endif // fprintf(stderr, "dlopen => %s\n", lib); module = ::dlopen(lib, RTLD_LAZY | RTLD_GLOBAL); SetError(); }
必要なライブラリへのフルパスを関数に置き換える小さなトリックが、完全に機能するソリューションであることが判明しました。そして、不在のライブラリはエンジンによって数回検索されるため、将来のために、次のメジャーバージョンをロードする可能性を残しました。彼らがAPIを壊さないことを願っています。
私が遭遇した次の問題は、x86アーキテクチャーでプロセッサー周波数を判別できないことでしたが、x86_64ではすべて正常に機能しました。 x86で実行する場合、エンジンはSERIOUS_MHZという名前の環境変数を設定するように要求しましたその中に適切な周波数を設定しましたが、それは非常に驚きました。私はそれをやろうとしましたが、ゲームは本当に始まりましたが、何らかの理由で動作が遅すぎました。ゲームのソースコードを登ってみると、長い間問題の原因を見つけることができず、Haiku APIを使用して正しいプロセッサ周波数を取得してゲームエンジンに置き換えるコードを記述しました。
#include <kernel/OS.h> #include <stdio.h> ... uint64 cpuFreq = 0; uint32 count = 0; get_cpu_topology_info(NULL, &count); if (count != 0) { cpu_topology_node_info *topology = new cpu_topology_node_info[count]; get_cpu_topology_info(topology, &count); for (uint32 i = 0; i < count; ++i) { if(topology[i].type == B_TOPOLOGY_CORE) { cpuFreq = topology[i].data.core.default_frequency; } } delete[] topology; } fprintf(stderr, "%llu\n", cpuFreq);
しかし、それは助けにはなりませんでした。次に、x86_64のエンジンログを確認し、CPU周波数が通常1 MHzで決定されていることを確認しましたが、すべて正常に動作します。コードをさらに調べ続けると、__GNU_INLINE_X86_32__ defineの否定に出くわしました。これは、アプリケーションがx86アーキテクチャ用に構築されたときに自動的に公開されますが、x86_64用ではありません。この定義の下では、インラインアセンブラーやrdtsc命令などのさまざまな魔法を使用してプロセッサ周波数を取得したり、/ proc / cpuinfoファイルを読み取ったりする代わりに、SDL2タイマーを使用するように指示するフラグが非表示になったため、このフラグをアクティブにし、私の問題を解決したx86用。
最後の欠陥は私の不注意に関連していました。アセンブリファイルを見逃したCMakeLists.txtは、-march = nativeフラグを設定します。これは、文字通りコンパイラーに指示します。マシンコードのブロックを生成するときは、コンピューターのプロセッサーで利用可能なすべての洗練された最新の命令を使用します。
if(NOT PANDORA AND NOT HAIKU) message("Warning: arch-native will be used!") add_compile_options(-march=native) endif() if(HAIKU) if(CMAKE_SIZEOF_VOID_P EQUAL 4) # 32-bit message("Warning: Will building 32-bit executable with MMX, SSE, SSE2 support.") add_compile_options(-mmmx -msse -msse2) else() # 64-bit message("Warning: Will building 64-bit executable.") endif() endif()
このため、リポジトリ内のパッケージは最も強力なビルドサーバーの下で排他的に収集され、普通の人間のコンピューターでの実行を拒否し、間違った指示とオペコードをりました。このフラグを無効にし、MMX、SSE、およびSSE2命令のサポートを手動で追加すると、この問題が解決されただけでなく、このプロジェクトで大量のインラインアセンブラーをコンパイルできるようになりました。
残念なことに、Croteamの開発者はエンジンリポジトリへのパッチを受け入れないため、作業を分岐してそこに配置しました。
プロジェクトソースコード：https : //github.com/EXLMOTODEV/Serious-Engine
Serious Samゲームを起動するためのすぐにインストールできるパッケージは、HaikuPortsリポジトリですでに利用可能です。ゲームデータファイルをダウンロードすることを忘れないでください。
<<コンテンツへスキップ
8. Vangersゲームの移植
率直に言って、最近まで、私はこのゲームに完全に不慣れでした。それは遠い90年代に国内の開発スタジオKD Labによって作られました。しかし、Haikuオペレーティングシステムの議論に専念していたTelegram IMの会議の参加者は、Vangerovの移植を求め、このゲームのソースがあるGitHubリポジトリへのリンクを教えてくれました。
Haiku用のVangerゲームポートランチャーのスクリーンショット。
ソースコードをHaikuに取り込み、コンパイルしようとしましたが、特別な問題なく成功しました。いくつかのヘッダーファイルが不足していることと、このゲームのエンジンで使用されるFFmpegライブラリへのパスを少し工夫する必要がありました。パッケージ化のためにソースコードの準備をすぐに開始したため、環境変数VANGERS_DATAを追加し、書き込み可能なユーザーディレクトリにエンジンログを移動しました。
Qt Creator IDEでVangerゲームをHaikuに移植するプロセス。
ゲーム自体を開始し、しばらくして、KD Labのメンバーが作成した雰囲気全体に感謝しました。しばらくして、私はニンバスをインキュベーターに軽く運び、Phをポディッシュに運び始めました。その後、なんとか3番目にエリクを連れて行きました。十分にプレイしたので、私はライブラリーに基づいてこのゲーム用のランチャーを準備し始めました。
Haikuオペレーティングシステムで実行されるVangerのゲームポート。
私が最初に遭遇した問題は、デジタル配信サービスGOG.comとSteamを使用して公式に取得できるゲームデータファイルがエンジンで動作したくないということでした。ニックネームstalkergを使用し、WangerをLinuxに移植している人に連絡する必要がありました。彼は、どのファイルを置き換えるかを教えてくれたので、すべてが始まり、動作し始めました。私は彼の勧めに従い、必要なものを手に入れました。
上で書いたNXEngine（Cave Story）ポートの場合のように、ロシア語版と英語版は異なる実行可能ファイルで異なりますが、データファイルのあるディレクトリは一般的で、違いはスクリプトのみです。stalkergのプロンプトで、オプション-DBINARY_SCRIPT = Offを使用してゲームエンジンをコンパイルしようとしました。これらのスクリプトがゲームデータファイルディレクトリにある場合、実行時にこれらのスクリプトの動的コンパイルをアクティブにしました。これにより、ランチャーを作成することができました。ランチャーでは、言語を切り替えることができます。アイデアは次のとおりです。ゲームディレクトリは事前にチェックされており、必要なスクリプトがない場合は、パッケージの内部からコピーされます。その後、ロシア語版または英語版の実行可能ファイルが既に実行されています。
Haiku Depotリポジトリに公開されているVangerのゲームポート。
Wangerを移植するとき、Haikuで気に入っている共有ライブラリに関連する1つの興味深い機能を使用しました。ゲームエンジンは、バイノーラルサウンドをリアルタイムで生成する動的ライブラリlibclunk.soに依存しています。そして、Linuxで環境変数LD_LIBRARY_PATHでこのライブラリへのパスを置き換えて、これを保存する前にこの変数にあったものを保存するように指を壊す必要がある場合、HaikuではWindowsのように便利に行われます。共有ライブラリを実行可能ファイルの横に置くだけで十分です。Haikuの場合、ライブラリは./lib/ディレクトリに配置する必要があるという点だけが異なります。私の意見では、時間と神経を大幅に節約できます。したがって、このライブラリの静的コンパイルを考慮しないことにしました。
プロジェクトソースコード：https : //github.com/KranX/Vangers
Wanger開発者はゲームエンジンへの私の変更を受け入れ、リポジトリインフラストラクチャで最近発生したfakapにもかかわらず、すぐにインストールできるパッケージをHaikuPortsリポジトリまたはHaikuDepotプログラムからダウンロードできますFedora Linuxディストリビューションを新しいバージョンに更新します。
<<コンテンツへスキップ
9. Haiku用のSDL2ライブラリでのダイアログの実装
上で書いたXash3DとSerious Engineエンジンを移植するとき、ダイアログの実装が完全に欠如しているため、SDL2ライブラリのローカルポートに偶然出くわしました。ダイアログはSDL_ShowSimpleMessageBox（）およびSDL_ShowMessageBox（）の2つの関数によって呼び出され、エラーなどの重要な情報をユーザーに通知できます。これらのダイアログの実装は、Windows、macOS、iOS、X11、およびAndroidの多くのプラットフォームおよびオペレーティングシステムで利用できますが、何らかの理由でHaikuにありません。この省略を修正し、この機能をSDL2ライブラリポートに追加することにしました。
Haiku API、またはむしろInterface Kitフレームワークには、すばらしいクラスBAlertがありますこのようなダイアログを実装するのに最適です。それをベースとして選択することにしました。気になった唯一のことは、BAlertが作成するダイアログで、3つ以上のボタンを配置できるかどうかわからなかったことです。上記で書いたこのクラスのメモリ管理の機能も思い出しました：オブジェクトはヒープ上でのみ作成でき、スタック上では作成できません。Go（）メソッドと後続のユーザーアクションを呼び出した後、自身を削除するためです。いくつかの実験を行った後、私はすべての疑問を払拭し、このクラスから継承し、実装を書き始めました。
Haikuオペレーティングシステム用のSDL2ライブラリでのダイアログの実装。
私が遭遇した最初の難しさは、BAlertクラスまたはその子孫のオブジェクトを使用するとき、明らかにアプリケーションをapp_serverに登録して対話できるようにするために、BApplicationシステムクラスのインスタンスを作成する必要があったことです。このクラスのインスタンスを作成しましたが、別のプロセスまたは作成されたウィンドウからBAlertダイアログを呼び出すと、アプリケーションにBApplicationクラスの2つのオブジェクトを含めることができないという事実に関連する別のエラーが発生しました。幸い、この問題の解決策も見つかりました。 Haiku APIには、クラスの現在のインスタンスへのグローバルポインターがありますbe_appと呼ばれるBApplicationは、Qtフレームワークの対応するもので、現在のアプリケーションオブジェクトへのポインターを定義する特別なqAppマクロです。したがって、be_appポインターのNULLをチェックするだけで十分です。チェックが成功したら、必要なオブジェクトを作成します。したがって、これらの問題はすべて解決されました。
SDL2ライブラリはCプログラミング言語で記述されており、Haiku APIはご存じのようにC ++プログラミング言語を使用していることに注意してください。このため、リンク中の文字解決に問題がないように、コードの一部をextern "C"バインディング規則でコーティングする必要があります。また、代わりにnew、new演算子（std :: nothrow）を使用して、例外をスローする代わりに、割り当てられたメモリのNULLをチェックできるようにする必要があります。SDL2の処理はもちろんサポートしていません。
残りは複雑なものではありませんでした。 SDL2エンティティと表現をHaiku APIと互換性のある方法で変換し、それらが正しく機能することを確認する関数をいくつか作成します。さまざまなチェックのために、小さなテストを拡張しました。、異なるオペレーティングシステムで定期的に実行し、結果を分析し、作業を評価しました。結局、私は夢中になって、ボタンとダイアログの背景に異なる色を設定するなど、カスタマイズのサポートさえしました。これはSDL2ライブラリAPIでサポートされていますが、最初はそのようなものを実装する予定はありませんでした。
プログラマがこのダイアログに非常に長い行を吐き出すことにした場合、BAlertクラスオブジェクト内で使用されるBTextViewクラスオブジェクトは、引数trueでSetWordWrap（）メソッドを呼び出す必要があります。そのようなプログラマーを腕に当てて、対話を画面にフィットさせる。簡単なことは何もないように思われます。strlen（）関数を使用して文字列の長さをチェックし、正しいことを行います。唯一の問題は、SDL2がUTF-8で同じように機能することです。つまり、strlen（）関数は文字数ではなくバイト数を返します。 Haiku APIとBString文字列クラスは、バイト単位ではなく文字単位で文字列の長さを調べることができるCountChars（）メソッドを持つレスキューに来ます：
bool CheckLongLines(const char *aMessage) { int final = 0; // This UTF-8 friendly. PS G_MAX_STRING_LENGTH = 120 BString message = aMessage; int32 length = message.CountChars(); for (int i = 0, c = 0; i < length; ++i) { c++; if (*(message.CharAt(i)) == '\n') { c = 0; } if (c > final) { final = c; } } return (final > G_MAX_STRING_LENGTH); }
この関数は、メッセージのテキストで120文字を超える行をチェックし、存在する場合はtrueを返します。 UTF-8に関しては、一部のHaikuシステムフォントでは中国語文字がサポートされていない瞬間がまだありました。したがって、たとえば、ウィンドウタイトルに中国語の碑文をインストールすることはできません。しかし、ロシア語のテキストは問題なくインストールされます。
パッケージの準備中に、x86_gcc2アーキテクチャのビルドエラーが発生しました。これは、SDL2ライブラリレシピでアクティブ化されます。最も古いGCC 2.95コンパイラは、コメントされたコードが以下のものと同等であると推測できないことが判明しました。
rgb_color ConvertColorType(const SDL_MessageBoxColor *aColor) const { // return { aColor->r, aColor->g, aColor->b, 255 }; rgb_color color = { aColor->r, aColor->g, aColor->b, color.alpha = 255 }; return color; }
, .
SDL2 HaikuPorts, Xash3D Serious Engine - , , . SDL2 , HaikuPorts upstream SDL2. - BE_* HAIKU_* , .
<<
10. Cool Readerのフォークの移植
私は長い間、Vadim Lopatin（Buggins）によって書かれたCool Readerプログラムのフォークを開発してきました。これに関する対応する記事は私のウェブサイトで利用可能です。その記事へのコメントの中で、私のブログの読者は、電子書籍を読むためのお気に入りのアプリケーションの新しい機能を見たいか、すでに実装されているプログラム機能のエラーや欠点を修正したいのか、絶えず退会しています。
Haikuで実行しているCool Readerのフォーク。
HaikuPortsリポジトリで、オリジナルのCool Readerプログラムを作成するためのレシピを見つけましたが、SourceForgeリソースで発生する一定の変更により、アプリケーションのソースコードがダウンロードできなくなったため、このレシピは動作しませんでした。次に、Cool Readerの新しいバージョンとして、フォークをHaikuPortsリポジトリに転送することにしました。 Gerasimのすべてのパッチをコードに適用し、レシピのいくつかの欠陥を修正し、それに基づいて、すべてのHaikuユーザーがすでに利用できる新しいパッケージを作成しました。 Cool Readerフォークのソースコードは、このGitHubリポジトリにあります：
プロジェクトソースコード：https : //github.com/EXLMOTODEV/coolreader
私が遭遇した唯一の問題は、Gerasimのパッチの転送の不正確さでした。__HAIKU__ defineに加えて、ビルドシステムのどこかで_LINUX defineも設定されました。ほとんどの場合、ソースコードリストの最後の1つが最初であったため、条件付きコンパイルで失望しました。プリプロセッサの優先ルールに従って、Haikuの場合は_LINUXでフレーム化されたコードが正確にコンパイルされましたが、まったく異なるものが必要でした。しかし、それにもかかわらず、プログラムは起動して機能し、必要な場所にのみ設定を保存しました。パッケージを正しく優先順位付けし、再構築したところ、問題は完全に解決しました。
<<コンテンツへスキップ
11. KeymapSwitcherプログラムの最終化
最近、多くの一般的なオペレーティングシステムが新しいキーボードショートカットMeta / Opt / Cmd / Win + Spaceに切り替えて、キーボードレイアウトを切り替えています。今では何も変更して構成する必要がないので、とても便利に思えました。 GNOME 3シェルを搭載したmacOS、Windows、またはLinuxを実行しているコンピューターの前に座って、入力言語を変更するこの便利な組み合わせはどこでも機能します。 Androidモバイルオペレーティングシステムでさえ、そのアナログを持っています。一般的に、私はずっと前にこのキーボードショートカットに切り替え、非常に慣れました。残念なことに
、KeymapSwitcherHaikuに付属しているため、レイアウトを切り替えるための便利なキーの組み合わせを設定できませんでした。そのため、このオペレーティングシステムでテキストを操作するときに不便を感じていました。そのため、このアプリケーションを少し変更して、ソースコードの検索を開始することにしました。このプログラムは、Haikuディストリビューションに含まれていますが、オペレーティングシステム自体のソースコードとは別に提供されていることが判明しました。さらに、アプリケーションはHaikuPortsリポジトリで利用可能であり、それを通じて更新されます。通知されたように、KeymapSwitcherはキーボードレイアウトを変更するための特別なAPIを実装する予定であり、いつかこのプログラムの必要性が完全になくなるため、Haikuには含まれていません。
キーボードレイアウトを切り替えるための一般的なキーボードショートカットを備えたHaikuオペレーティングシステム上のKeymapSwitcher。
KeymapSwitcherコードの複雑さに怖がっていたにもかかわらず、コメントのおかげですぐに適切な場所を見つけ、プログラムコードに小さなパッチを導入しました。これにより、Haikuのテキストの入力が大幅に容易になりました。私が克服できなかった唯一の小さな欠陥は、言語を切り替えるためにOptキーをリリースする必要があるということです。つまり、Optを押したままにします選択した言語を切り替えるスペースは機能しません。しかし、これは入力中の言語切り替えを絶対に妨げるものではないため、プログラムリポジトリにパッチを送信し、HaikuPortsのアプリケーションパッケージを更新した後、KeymapSwitcherの新しいバージョンをすべてのHaikuユーザーがインストールできるようになりました。
プロジェクトのソースコード：https : //github.com/HaikuArchives/KeymapSwitcher
キーボードレイアウトを切り替えるこのキーボードショートカットのユーザーが私だけではないことを願っています。
<<コンテンツへスキップ
12.結論
Haiku APIを研究し、このオペレーティングシステム用に新しいアプリケーションを移植したり既存のアプリケーションを更新した結果として生じたさまざまなエキゾチックな問題を解決したことで、多くの貴重な経験と喜びを得ることができました。いくつかの大規模プロジェクトのソースコードリポジトリでHaikuサポートパッチを宣伝することができ、この美しいオペレーティングシステムに何らかの形で関連する新しい興味深い人々に会いました。
Haikuオペレーティングシステムで実行されているさまざまなアプリケーション。
将来、3Dハードウェアアクセラレーションや人気のあるブラウザーの欠如、現代のハードウェアへの不十分なサポートなどの今日の問題がすべて正常に解決され、Haikuがそのユニークな機能とオリジナルデザインに感謝する開発者とユーザーから新しい血の流入を受け取ることを心から願っています。幸いなことに、開発はまだ止まっておらず、このオペレーティングシステムのローカルフォーラムでは、3DアクセラレーションとGTK + 3ライブラリの移植に関するホットトピックが取り上げられ、QtWebEngineコンポーネントの移植の可能性がHaikuPortsリポジトリで議論されています。 GTK + 3ポートは、人気のあるFirefoxおよびChromiumブラウザーの起動と操作につながる可能性があり、QtWebEngineは、Otter BrowserやFalkonなどのQtフレームワークに基づく最新のブラウザーでBlinkエンジンを使用できるようにします。
すでに、たとえば、LubuntuディストリビューションやWindows XPの代わりに、古くて弱いラップトップまたはネットブックを持っている人にこのオペレーティングシステムをお勧めできます。あなたはそれがどれほど速くて反応するのかに驚くでしょう。はい、古いブラウザとそれらに関連付けられた不具合のために、一部のサイトの表示に少し制限する必要がありますが、ほとんどの場合、古いハードウェアではこの制限は重要ではありません。
私のすべてのポートと改良はすでに公開されており、すべてのHaikuユーザーがインストールできます。ソースコードへのすべての変更は、元のライセンスの下でそれぞれのリポジトリで利用できます。この作業では、膨大な量の資料を使用しましたが、その主なものは以下の有用なリンクで強調します。リソースstackoverflow.comおよびgoogle.comをお持ちいただきありがとうございます。
1. Haikuオペレーティングシステムの公式Webサイト。
2. Haikuオペレーティングシステムの公式フォーラム。
3. Haikuユーザー向けの公式ドキュメント。
4. Haiku開発者向けの公式ドキュメント。
5. Haikuグラフィカルユーザーインターフェイスの機能の説明。
6. Haikuアプリケーションのアイコンを作成するための推奨事項。
7. Icon-O-Maticプログラムの説明とその使用のヒント。
8.ベクトルHVIFアイコンの形式の説明。
9. Interface Kitフレームワークの公式ドキュメント。
10. Locale Kitフレームワークの公式ドキュメント。
11. Haikuのアプリケーションのローカライズに関する記事。
12. Layout APIの公式ドキュメント。
13. HaikuでのLayout APIの実装を説明する一連の記事。
14. HaikuオペレーティングシステムのソースコードのGitHubリポジトリ。
15. HaikuPortsレシピツリーのGitHubリポジトリ。
16.既製のHPKGパッケージHaiku Depot Webのリポジトリのインターネットバージョン。
17. INSTEAD開発者Peter Kosykhのブログに関する興味深い記事「Haiku：lamp geek-OS」。
18. INSTEAD開発者Peter Kosykhのブログの記事「Haiku：Immersion」。
19. DarkWyrmのプログラミングレッスン「Haikuによるプログラミングの学習」。
20. DarkWyrmのプログラミングレッスン「Programming With Haiku」。
21.「Haikuに生命はありますか？」という出版物Linux.org.ruリソースについて、私から。
22. Haikuオペレーティングシステムの議論に特化したTelegram IMでの会議。
リソースのすべてのユーザーにおめでとうhabr新年あけましておめでとうございます、彼らに幸せなクリスマス休暇を！新しい2019年に皆さんに幸運を！
<<コンテンツへスキップ