3 TB の HDD が壊れかけて一部読み取れなくなったけど家の中の空き容量が 2 TB しかなくてさぁ困ったぞという状態の作者です。
タイトルの通りですが、64-bit の Windowsアプリケーションに対応した Wine をリリースしました。いつものところからどうぞ。
GW くらいからずっと製作には入っていたんですが、新しい開発環境作ったりとか久しぶりにユニバーサルバイナリを作ったりとかで滅茶苦茶手こずりました。しかも Wine の 64-bit は 32-bit もコンパイルしなきゃいけないので 32-bit だけだった今までの倍のコンパイルが必要になるんです。50 回以上は Wine のコンパイルをしたと思います。本当に ccache 様様でした。この辺の苦労話は書いておかないと自分でも忘れそうなので後で書こうと思います。
新しい Wine というか Nihonshu と EasyWine は 64/32/16-bit の Windowsアプリケーションに対応しています。今後はこの形式でビルドしていくのでこれまでの 32-bit 版については開発を終了することにしました。ですので前回分が最後のリリースということになります。
最初は Wine 4.7 と 4.8 のソースを使ってたんですが、どうも Wine エクスプローラが落ちる…。依存関係やらコンパイル方法とか色々試したんですが改善せず、ソースを 4.0 まで戻したら普通に動きました。ですので今回の Wine のソースは Stable の 4.0.1 を使用しています。
以下、64-bit 対応版を Nihonshu64 と EasyWine64 とします。ざっくりした変更点とかはダウンロードのページでご確認ください。
まず、macOSの 対応状況ですが、上は Mojave で普通に動きました。あと、Mojave で 32-bit 版のコンパイルも出来たのでまだ暫くは開発も大丈夫かなと思っています。Mojave では Xcodeに 32-bit が含まれなくなったので MacPortsと Homebrew で Wine のビルドが出来なくなっているので Wine の導入が難しくなってるみたいですね（Homebrew の方はバイナリリリースで対応しているみたいですが）。下は El Capitanまでは確認しましたが Yosemite や Mavericksではどうだかわかりません。
今回からライブラリをユニバーサルバイナリ化したため、全体的にファイルサイズが増えています。圧縮ファイルで 100 MB 前後、展開すると 500 MB 近くになります。WINEPREFIX の作成にも 700 MB くらい容量を使いますのでストレージの空き容量にご注意ください。また、Geckoは 32-bit と 64-bit が必要になるのでインストールのダイアログが 2 回表示される点にも注意してください。
Nihonshu64 と EasyWine64 は 64-bit 専用ではなく、64-bit モードとして起動します。そのため、32-bit アプリケーションも動かすことが出来るというわけです。しかし、WINEPREFIX は 32-bit と 64-bit で共有出来ないため、既に WINEPREFIX が 32-bit 環境用として作成されている場合は新たに 64-bit 環境用の WINEPREFIX を作成しなくてはなりません。EasyWine ではどうしても WINEPREFIX を変える必要があったため、64-bit モードの場合は WINEPREFIX が ~/Library/Caches/Wine/prefixes/default64がになります。データの引き継ぎ等は出来ないため新しくアプリケーションをインストールするか、32-bit の WINEPREFIX からコピーするなどしてください。
公式のドキュメントにも載っていますが、Nihonshu64 ユーザであれば下記のように実行することで 32-bit の WINEPREFIX を作成することができます。
WINEARCH=win32 WINEPREFIX=$HOME/.wine32 nihonshu explore
EasyWine64 の場合はアプリケーション名を見て 32-bit と 64-bit の動作が切り替わるようになっています。デフォルトは EasyWine64.appですので 64-bit モードで動作します。これを EasyWine32.appなどにリネームすることで WINEARCH=win32の指定が出来ます。正確には EasyWine64.appという名前以外であればすべて 32-bit モードになります。
EasyWine64 はこれまで通り DMG形式での配布となりますが、ディスクイメージから直接すると激的に遅くなることが確認されていますので、必ずデスクトップなどの内蔵のストレージ等にコピーしてからご利用ください。相対パスで動作するようにしてあるので /Applicationsに入れる必要はありません。
既知のバグで一部で日本語の文字間幅がおかしくなっています（例えばメモ帳とか）。これは Linuxでも同じなのでフォント云々よりは Wine のソース側の問題かなと思っています。Windowsには詳しくないのでここがどのライブラリを使用しているのかわかりません。Wine 3.x 系のときは問題なかった気がするので Wine 4.x 系からですかね。
64-bit 対応版製作時の苦労話とか
clang のオプション変わってたのに気づかなかった
ずっと gccを使っていたので LDFLAGSに -Wl,-arch,i386とか -Wl,-arch,x86_64って設定してました。最近の clang 使っててどうもユニバーサルライブラリが作れないなー？と思ってたら無視されてました。最近の Xcodeだと 32-bit 対応してないよという先入観があったので 3 日くらい気づかなかったと思います。
Mojave でも 32-bit の Wine はコンパイル出来るよ！古い Xcodeならね！
上記の clang のオプションの罠に気づかず、Xcode 8 系 と Xcode 9 系両方試しました。普通にユニバーサルで作れましたありがとうございました。
複数のバージョンの Xcode.app を使い分ける場合は xcode-select --switchで切り替えれば良いです。SDKROOT環境変数とかは設定した方が無難ですね。
mkdir -p /Applications/Xcode_9 cd /Applications/Xcode_9 xip -x Xcode9のアーカイブ.xip xcode-select -s /Applications/Xcode_9/Xcode.app
ライブラリの話
ユニバーサルライブラリを作成するにあたって、gnutls とかのライブラリも増やそうかなぁと思ってたんですが、otoolと DYLD_PRINT_LIBRARIESで確認したらどうも libjpeg とか libtiff、libusb あたりって使われてないんですよね…。macOSだとフレームワークが大量にあり、ImageIO.framework の中に libjpeg や libtiff 相当のものが入ってるので要らないのでは…ということでライブラリを最小限の libpng、freetype、Little-CMSに絞りました。もしかしたらこれによって何らかの不具合が出るかもしれません。gnutls のユニバーサルライブラリのコンパイルは本当にしんどいので出来ればやりたくないですね。いまはカメラ系もやっていないので gphoto とかはリクエストがあれば入れようかと思います。
freetypeはちょっと弄ったんですが、あまり違いがわからないですね。自分が持ってる MacBook Airの 1366x768 では今回新しく内蔵したフォントとは相性いいと思ったんですけど Retinaで見たらそれほどでもなかったです。Cairo とか使えれば滅茶苦茶綺麗になるんですけどね。
フォントの話
いままでなんとかヒラギノで置き換えようと思ってきたんですが、どうも細くて見づらい…。あとなんか新しい macOSになってシステムフォント増えてる…。もうシステムフォントでやりくりするのツライ…。
ってなったのでゴシック系だけフォントを差し替えました。IPAMona ではないです。ライセンスが面倒なので。しばらくこの辺は調整する時間が無さそうなので現状のままで我慢していただくか自分で何とかしてください。
ちなみに AviUtl は解像度の低いディスプレイで開くと一部のダイアログが画面外まで伸びるためボタンが押せないことがわかっています。
メニューバーが自動的に隠れるのを辞めた
不満を言う人がいるので…。まぁ不満がある人しかネットに書かないので不満しか目に入らないわけですが。
1366x768 のディスプレイだとメニューバーのせいで 1280x800 のウィンドウで下が切れるんですよ！Retinaとかセレブなディスプレイ使ってる人にはわからないでしょうよ！！！
という思いもありますが、パッチの整理も兼ねて一旦デフォルトに戻しました。ご意見あればマシュマロあたりにどうぞ。
ゲームパッド買いました
Wine でゲームパッドって試したことなかったので HORI の PS4用のワイヤレスコントローラーライトというのを買ってみました。これ色々と曲者だったので別記事で書く予定ですが、macOSでは多分使えません。Linuxでは有線でも無線でも使えます。ただ、有線だと 11 ボタンで、無線だと 15 ボタンになるという謎仕様です（他にもいっぱい謎仕様ある）。macOSでは Amazonで売ってる怪しい Buffalo のクラシックコントローラー（SFC）を使っています。アナログジョイスティックよりやっぱり十字キー派ですね。
私はいつまで Wine を作り続けるのか
ここまで読んだそこのあなた、物好きですね。残念ながらお得なクーポンコードとかはありませんよ。
以前も書きましたが私はもう Macユーザではないです。Linuxでも Wine は使っていますが、Windowsから送られてきた ZIP ファイルを 7-Zipで開く程度にしか使っていません。（最近ちょっと東方やるようになりましたけど…）
そろそろ皆さんも Nihonshu や EasyWine を卒業しませんか？
先日、公式の macOSバイナリの中身を覗いてみたんですよ。そしたらライブラリの日付とかが滅茶苦茶古いし、余計なファイルも入ったまま。まぁ動くんですけど。
Homebrew を使ったほうが皆さんのテクニカルスキルの向上にも繋がりますし、あちらにはメンテナンスしてくれる人もたくさんいます。それはもう世界中にたくさん。勝てるわけないじゃん。
CrossOver や PlayOnMac なんて素晴らしいアプリケーションもあるじゃないですか。おい、WineSkin さぼってんじゃないよ。
Wikipediaにも載っていないような怪しいソフトをいつまで使い続けますか？そのソフトは密造酒ではありませんか？
先日、知り合いに素で作者であることがバレました。別に隠してたわけでもないんですけど。いつ脅されるか気になって夜も寝られません。嘘です。ぐっすり寝てます。で、なんとなくそこでバレたのがそろそろ転機かな？みたいに思ったわけです。
今年は何か新しいことをしようと思ったので Wine の同人誌でも作ろうと思っていました。昔書いた記事とかも整理してそろそろ消したいので。改めて検証したりして、いまでも有効なものは同人誌の方にまとめようかな、と。
その作ろうとしてる同人誌は『Macでも東方で遊ぼう！』みたいな本になるかもしれないのですが、色々難しいかなと思っています。「同人誌なんだから好きなこと書けばいいじゃない」という意見もあるかと思いますが、製作者様の意図にそぐわないものは出せませんよね。
私は 2chとか日常的に見る人間ではないのですが、追加対応とかのためにたまにエゴサ的なことはしてます。2chを見ると「あぁ、2chのユーザーにも使ってくれてる人がいるのだなぁ」と嬉しく思います。それはいいんです。ですが、某初心者向け掲示板の書き込み内容のレベルがちょっとひどくて、回答者の方々に手間をかけるだけでなく、これはもしや問い合わせがいろんなソフト開発者様に行ってしまうのではないかと危惧しています。
ソフトの開発者様にも色々な方がいらっしゃると思います。「Macでも使ってもらえるなら歓迎ですよ」という方もいれば「動作環境に Windowsって書いてあるのになんでそういうことを広めようとするんですか？」という方もいらっしゃると思います。
以前、「EasyWine はバンドル化に対応していない」という書き込みを目にしたことがありますが、バンドル化の機能を実装しないのには理由があります。Wine は Windows OS を無限に複製出来ると言っても過言ではありません。安易にバンドル化の機能を実装するとバンドル化したそれを安易に配布してしまう人が必ず出ててくると思っているので実装していません。それを言ったら仮想化ソフトウェアは皆同じですし、既に Wine に関してはネット上にたくさんの情報があるので今更そんなこと考えても…と思ったりもするのですが。
この辺詳しい方がいらっしゃればマシュマロとかでご意見いただけたらな、と。
おっと、もう寝ないと(｡ŏ﹏ŏ)