x64 のビルドに対応する

[m-tmatma]

x64 のビルドに対応する

参考

64 ビット Windows プログラミング ガイド
https://msdn.microsoft.com/ja-jp/library/bb427430(v=vs.85).aspx

[m-tmatma]

• 0c59d50 で sln を開いて x64 を新規作成してビルドしたら大量の警告は出たが、 x64 用のバイナリができた。
• b96c061 でも成功した。
• x64 のコンパイルでは HeaderMake.exe と MakefileMake.exe の Win32 版をビルドして実行するようにする必要がある。(32bit OS 上ではクロスコンパイルするとき x64 HeaderMake.exe と MakefileMake.exe のバイナリは実行できないから)

以下作成したバイナリの COFF File Header (Object and Image) の Machine フィールド(リトルエンディアン) が、IMAGE_FILE_MACHINE_AMD64 (0x8664 ) になっている。

[m-tmatma]

プロジェクトの構成が固まってから対応する

[berryzplus]

課題は色々ありますが、対応には賛成です。

https://github.com/sakura-editor/sakura/blob/master/sakura/sakura_vc2017.vcxproj
96行目のここ(プリプロセッサ定義)とか
WIN32;_WINDOWS;NOMINMAX;WINVER=0x0500;_WIN32_WINNT=0x0500;_WIN32_IE=0x0501;NDEBUG;%(PreprocessorDefinitions)

慣例的にはWIN32を定義してしまう場合が多いです。
いちおう、WindowsSDKの仕様としては_WINDOWSを定義しておくと、
対象とするアーキテクチャの設定に応じてWIN32かWIN64が定義されるようになっています。

ここの定義には他に４つ改善要望があるので、適切なタイミングで提案していきたいと思っています。

[m-tmatma]

参考情報です。

(こういう Tips は チケットに書かずに Wiki か Markdown に書いたほうがいいかもしれませんが)

上記 URL で 96 のところの数字をクリックすると … の表示が出るのでクリックすると
メニューが出ます。

それで、Copy permalink を選ぶと以下のような URL がクリップボードにコピーされます。
このリンクは、git の Hash を含むのでファイルが変更されて行番号がずれても有効です。

sakura/sakura/sakura_vc2017.vcxproj

Line 96 in b96c061

<PreprocessorDefinitions>WIN32;_WINDOWS;NOMINMAX;WINVER=0x0500;_WIN32_WINNT=0x0500;_WIN32_IE=0x0501;NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>

96 のところをクリックしたあと、Shift を押しながら、100 を押すと
96 行目から 100 行目が選択されて同様にすると以下のような URL がクリップボードにコピーされます。

sakura/sakura/sakura_vc2017.vcxproj

Lines 96 to 100 in b96c061

	<PreprocessorDefinitions>WIN32;_WINDOWS;NOMINMAX;WINVER=0x0500;_WIN32_WINNT=0x0500;_WIN32_IE=0x0501;NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
	<StringPooling>true</StringPooling>
	<RuntimeLibrary>MultiThreaded</RuntimeLibrary>
	<TreatWChar_tAsBuiltInType>true</TreatWChar_tAsBuiltInType>
	<ForceConformanceInForLoopScope>true</ForceConformanceInForLoopScope>

[m-tmatma]

プロジェクトの構成が固まってから対応する

#31 がマージされたので準備が整った。

ここの定義には他に４つ改善要望があるので、適切なタイミングで提案していきたいと思っています。

よろしくおねがいします。

[berryzplus]

ここの定義には他に４つ改善要望があるので、適切なタイミングで提案していきたいと思っています。

よろしくおねがいします。

プリプロセッサシンボルの話（WIN32と他4つ）を追記しておきます。

定義シンボル	定義値	シンボルの意味と対応内容(目論見)
WIN32	-	Windows 32bitのAPIを参照する宣言。_WINDOWSを定義していれば不要なのでx64対応を見据えて外したい。
NOMINMAX	-	Windows SDKのmin/maxマクロを使わない宣言。定義しないとSTLのstd::minと競合するので宣言しておいた方がコーディングが楽。ビルドごとに変わるものではないのでstdafx.hに移動したい。
WINVER	0x0500	ターゲットOSのバージョン宣言。windowsがNT/9xの2系統に分かれていた時代の名残。_WIN32_WINNTに対応する適切な値を定義してくれる仕組みがあるため定義不要。
_WIN32_WINNT	0x0500	ターゲットOSのバージョン宣言。0x500＝win2000。win2000の稼働環境は入手性が低いので0x502に上げたい。0x0502＝win xp SP2。WinMainの冒頭で行っているDLL検索パスの固定処理で使っているAPIの対応状況が、win7以降(またはwin xp SP2以降で脆弱性パッチ適用)なので0x0501にすると色々めんどくさい。（ちなみにいまは0x0500なのでさらにめんどくさい状態 😄 ）ビルドごとに変わるものではないのでstdafx.hに移動したい。
_WIN32_IE	0x0501	ターゲット環境(IE)のバージョン宣言。昔のwindowsにはIEが付属しておらず、別売りだったらしい。PC好きのおっちゃんと仲良くなると秋葉原(東京)やら大須(名古屋)やらにメディアを買いに行った話を聞かせてもらえることがある。windowsGUIの一部はcomctl32.dllで提供されており、comctl32.dllはIEのコンポーネントなのでwindowsGUIのどの部品が使えるかはIEバージョンの影響を受ける。ただし、それはIE4以前の時代の話で、現在では(ほぼ)気にしなくてよい。_WIN32_WINNTに対応する適切な値を定義してくれる仕組みがあるため定義不要。

各シンボルの定義を実際どうするかについては、別issueを起こして進めていくつもりです。

[m-tmatma]

各シンボルの定義を実際どうするかについては、別issueを起こして進めていくつもりです。

よろしくおねがいします

[kobake]

（必要かどうかはさておき）Win2000環境は自分のほうでたぶん準備できます（iso持っているのでvirtualboxに展開できるはず）。
逆にXPの環境は自分は持ってないです。

サクラエディタの Windows OS のサポート範囲もどこかのタイミングで精査したいところですね。

ちなみにWin7以降の動作環境を用意するとしたらこのあたりが使えるかな、と思っています。
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

[berryzplus]

W2k環境はメディアがあるのに構築出来ませんでした。どうもCPUクロック1.5GHz未満の制約があるらしくて、実機か専用vmを用意しない限り無理と結論しました。w2k以前の稼動マシンはレアなので、ジャンクでなければwin10搭載の新品より高いです。w2kを起動できる専用vmは見つかっていません。

Xp以降ならハードの制約がなさそうで、ライセンスさえあれば現行機にvmを構築出来ます。探せばwebサービスもあるかも知れません。

これたぶん、issue上げて試したもの残す感じがいいですね。

[kobake]

CPUクロック1.5GHz未満の制約があるらしくて、実機か専用vmを用意しない限り無理と結論しました

ふむふむ。参考サイト等あれば教えていただけると助かります。

[m-tmatma]

x64 版を使うには 正規表現ライブラリも x64 版が必要ですね。

[k-takata]

WIN32 (および _WIN32) は 64bit版でも定義されているべきものです。プロジェクトファイルで定義しなかった場合でも、WinDef.h で定義されるはずです。

[m-tmatma]

#72 がマージされたら、テスト用の PR を投げようと思います。

x64 での警告は 624 個出ているが、以下の 3 種類の警告です。

• Warning C4244
• Warning C4267
• Warning C4477

64bit 変数から 32bit 変数に変換されてデータ落ちします、と printf の指定が違いますよ、
という警告です。

一個一個見ていくのは時間がかかりそう。

以下で対応された方に協力していただけたらいいのですが。
https://sourceforge.net/p/sakura-editor/wiki/64bit/

[kobake]

x64 対応、分担してやれそうですか。

分担するとしたら master から x64 ブランチ切って、x64 からそれぞれ作業ブランチ切って x64 にマージする PR 出していって、ぜんぶマージされて x64 動作がうまい感じに安定したことが確認できたら master にマージする流れが良いかな、と思っています。

もしくは「x64 ビルドはまだ安定していません」という注記を README に書いておいた上で master で作業しちゃうというのもアリです。

SourceForge 時代のコミッタの方々に一声かけてみますが、反応なければ今いるメンバーで頑張って対応しちゃいましょう。

[m-tmatma]

分担するとしたら master から x64 ブランチ切って、x64 からそれぞれ作業ブランチ切って x64 にマージする PR 出していって、ぜんぶマージされて x64 動作がうまい感じに安定したことが確認できたら master にマージする流れが良いかな、と思っています。

はい。それでいいと思います。

#76 の対応後にやるのがいいと思います。

もしくは「x64 ビルドはまだ安定していません」という注記を README に書いておいた上で master で作業しちゃうというのもアリです。

master でやるのはやめたほうがいいと思います。

[m-tmatma]

分担するとしたら master から x64 ブランチ切って、

このブランチは https://github.com/sakura-editor/sakura 上に作って

x64 からそれぞれ作業ブランチ切って

このブランチは 各作業者のアカウント上でブランチを作って作業したほうがいいと思います。

理由は、x64 ブランチを https://github.com/sakura-editor/sakura 上に作ることで作業しやすくなる。

appveyor でのビルドインスタンスがフリーのプランだと1アカウント毎に同時に1インスタンスしか利用できないので
作業中のコミットを各アカウントでのビルドに分散させることで https://github.com/sakura-editor/sakura 用の
appveyor のビルドを他の用途のビルドに使えるようにするためです

[m-tmatma]

プロジェクトの設定変更と Appveyor の設定変更だけの
修正を行うPR だけを行なって、readme に作業中と
注意書きをするのを想定してますか？

ソース自体の修正はx64 用のブランチで行い、
対応が完了した時点で master に入れるのが、いいと思います。

[kobake]

ブランチ作業で良いと思います

[kobake]

x64 ブランチを作成しました。ここに変更内容を集めていきましょう。

[m-tmatma]

x64 ブランチを作成しました。ここに変更内容を集めていきましょう。

x64 対応する前に #76 を入れたいです。
#76 がマージされたら rebase したいです。

[kobake]

x64 ブランチを最新 master に合わせました

[kobake]

作業被りを防ぐため、 @m-tmatma さんのほうで既に着手済みの作業があったら教えてください。

関連 PR

• [WIP] x64 作業集約場所 x64 作業集約場所：2018-06-27 をもって master に統合する #86

関連 Issue

• [x64対応] (着手済) バージョン情報ダイアログに 32bit / 64bit の表示を入れる [x64対応] バージョン表示に 32bit / 64bit の表示を入れる #87

[kobake]

Warning 状況を以下 Wiki にまとめました。
https://github.com/sakura-editor/sakura/wiki/x64

• C4267: 333件
• C4244: 288件
• C4477: 3件

Warning 対応の分担単位ってどうしましょうか。
Warning 種別毎にガッツリ区切ってしまいますか。（上記 Warning 対応するとしたら3件に分割して分担）

[m-tmatma]

x64 版を使うには 正規表現ライブラリも x64 版が必要ですね。

#81 で検討

[m-tmatma]

作業被りを防ぐため、 @m-tmatma さんのほうで既に着手済みの作業があったら教えてください。

いまのところありません。

[m-tmatma]

慣例的にはWIN32を定義してしまう場合が多いです。
いちおう、WindowsSDKの仕様としては_WINDOWSを定義しておくと、
対象とするアーキテクチャの設定に応じてWIN32かWIN64が定義されるようになっています。

https://msdn.microsoft.com/ja-jp/library/b0084kay.aspx によると _WIN64 はコンパイラによって
定義されるので、確実です。

_WIN64 コンパイル対象が 64 ビット ARM または x64 とする場合は、1 として定義します。 それ以外の場合、定義されていません。

[m-tmatma]

_M_AMD64 値 100 のコンパイルの場合その対象となる x64 プロセッサは、整数リテラルとして定義します。 それ以外の場合、定義されていません。

x64 限定の場合 _M_AMD64 が使えます。

参考

• https://stackoverflow.com/questions/42550334/difference-between-msvc-builtin-macros-m-amd64-and-m-x64
• https://blogs.msdn.microsoft.com/reiley/2011/08/12/macro-revisited/

[berryzplus]

「ビルドすること」自体はとっくの昔にできていたと思うので一旦閉じておきます。

• x64 でビルドできる。
  • x64 のコンパイラを使ってビルドして exe ができる。
  • x64 のコンパイラを使ってビルドした exe がそれなりに動く。
    • 主要機能が正常動作するようであればこの基準はクリア。
  • x64 のコンパイラを使ってビルドした exe がまともに動く。
    • 全機能の正常動作が確認できたらこの基準はクリア。
  • x64 のコンパイラを使ってビルドしたときに変な警告が出なくなる。
    • 警告が出ないことと正常動作できることとの間に関連性はないが分かりやすい指標ではある。

たぶん、このissueで目指していたのは「exeができる」だと思うので閉じて問題ないと判断しました。
（そうじゃないissueは他に立てられていたような気がします。）