Crystal 1.9におけるWindowsサポート

HertzDevil
技術 #機能 #windows #リンク

Crystal 1.9のリリースに伴い、コンパイラと標準ライブラリは、MSVCツールチェーンを使用したx64 WindowsのTier 1サポートに向けて大きく前進しました。公式のWindowsリリースはまだ準備中ですが、残っている問題はわずかであり、今後数ヶ月で解決される見込みです。1.9で達成されたことと、今後達成すべきことを簡単にまとめたものです。

GUIインストーラ

installer

初めて、Windows用のGUIインストーラが登場しました！これにより、コンパイラと標準ライブラリに必要なすべてのサードパーティ依存関係をインストールできます。PATH環境変数にコンパイラを追加し、ファイルの関連付けを設定し、適切に更新またはアンインストールし、Windows SDKまたはMicrosoft Visual Studioが検出できない場合にユーザーに警告します。このセットアップは、これらのMicrosoftコンポーネントのインストール以外では、新しいマシンで「そのまま」動作することが期待されます。コマンドライン環境に慣れていないWindowsユーザーにとって、より効率的なCrystalの使用体験を提供します。

今後の1.9リリースでは、このGUIインストーラのダウンロードオプションが提供されます。マイナーリリースまたはパッチリリースが利用可能になるたびに、GitHub Actionsで新しいインストーラがビルドされるため、通常は上記のスクリーンショットのようなナイトリービルド用のインストーラは表示されません。ただし、ナイトリーバージョンとの間での更新は変わりません。GitHubアカウントをお持ちの場合は、crystal-installer このCI実行からのアーティファクトをお試しになり、見つかった問題を報告してください。Inno Setupを使用して、Windowsワークフローの説明に従って、インストーラをローカルにビルドすることもできます。

動的リンク

過去3ヶ月間の作業の多くは、Windowsでのロード時動的リンクを可能な限りシームレスにサポートすることに費やされました。-Dpreview_dllコンパイル時フラグを使用して、実験的な動的リンクサポートを有効にできます。詳細については、リファレンスマニュアル（1.9、master）を参照してください。簡単な概要を以下に示します。

  • @[Link("foo")]は、静的リンクを行う場合にfoo-static.libをfoo.libの前に、動的リンクを行う場合にfoo-dynamic.libをfoo.libの前に検索するようにコンパイラに指示します。これにより、同じディレクトリ内に両方のライブラリを並べて配置できます。
  • 静的リンクは/MTを意味し、動的リンクは/MDを意味します。独自のCライブラリは、適切なMSVCリンカーフラグを使用してビルドする必要があります。
  • コンパイラフラグ-Dpreview_win32_delay_loadが指定されている場合、CRYSTAL_LIBRARY_RPATHビルド時環境変数を使用して、デフォルトの検索順序にDLL検索パスを追加できます。これはELFバイナリ用のDT_RPATHを参考にしています。同様に$ORIGINをサポートし、再配置可能な動的リンクされたWindowsバイナリを可能にします。

Crystal 1.9および1.10では、静的リンクがWindowsのデフォルトのリンクモードのままです。-Dpreview_dllコンパイラフラグにより、これらのバージョンで動的リンクを有効にできます。その後、動的リンクがデフォルトになり、他のシステムと同様に、静的リンクには--staticが必要になります。ビルドスクリプトで静的リンクに依存している場合は、適切に--staticを追加してください。

その他の重要な進歩

  • IO.pipeは非同期になりました（#13362）。これにより、Windowsの一部の重要な機能、特にProcessのストリームをIOにパイプすること、および非同期Logバックエンドでの並行処理が可能になります。FileやSTDOUTなどの標準ストリームは、現時点ではまだ同期です。
  • timeoutは、select式内で正しく動作するようになりました（#13525）。
  • Time::Locationは、すぐにIANAタイムゾーン名を尊重するようになりました（#13517）、夏時間遷移のないローカルタイムゾーンも同様に（#13516）。
  • STDIN、STDOUT、STDERRは、テキストモードではなくバイナリモードで開かれるようになりました（#13397）。これは、CRLF改行を含む特定のソースファイルでマクロrunが動作するために必要です。
  • Unixソケットは、Windowsが実際に実装している範囲でサポートされるようになりました（#13493）、その他いくつかの雑多なソケットAPIも同様です（#13325、#13326、#13363、#13364）。
  • 読み取り専用のファイルとディレクトリを適切に削除できるようになりました（#13462、#13626）。

残りの課題

Windowsに関する未解決の問題のリストは、このGitHubプロジェクトで確認できます。公式のWindowsリリースが利用可能になるまでに、「ToDo」と「進行中」の列を解決することを目指しています。この記事を書いている時点での主な残りの問題は次のとおりです。

  • Process.new(shell: true)の動作（#9030）
  • ファイルAPIでの長いパスのサポート（#13420）
  • 浮動小数点数のプラットフォームに依存しないsprintf（#12473）
  • /SUBSYSTEM:WINDOWSのより実用的な使用方法（#13058、#13330）
  • Process#close in Process.run（#13425）
  • crystal play（#13492）とcrystal i（#12396）
  • -Dpreview_mt下でのチャネルの動作が正しくない

標準ライブラリテストスイートでpending_win32タグが付けられた仕様の数は、前回のマイナーリリース以来、35から8に減少しました。これは急速な進歩を示しており、この進歩は次の開発サイクルにも引き継がれるでしょう。