ファイルの場所を コマンドプロンプトを開く で 管理者ではないときに 32bit アプリから 64bit OS上で起動したときに 32bit で起動してしまうのを修正

[m-tmatma]

#623 の対応で、ファイルの場所をコマンドプロンプトを開く と ファイルの場所を管理者としてコマンドプロンプトを開く で、64bit OS から 32bit アプリで実行した場合に、開くコマンドプロンプトがそれぞれ 32bit と 64bit とで異なるのを修正する。

ファイルの場所をコマンドプロンプトを開く で 管理者として開く場合、および通常のコマンドプロンプトで開く場合で、いずれの場合でも、OS のネイティブ版の コマンドプロンプトが開くようにする。

#623 (comment)

[m-tmatma]

確認方法

1. 64bit OS 上で 32bit 版アプリを起動する
2. 何かファイルを開く
3. 右クリックメニューから、コマンドプロンプトを開く を選ぶ
4. 開いたコマンドプロンプトで setを実行して PROCESSOR_ARCHITECTUREが AMD64を確認する

[k-takata]

64bit版cmd.exeが起動していることを確認できました。

[ds14050]

バグだという認識には同意しませんが、実用上のメリットがあるからそういう動作にするということであれば、それに反対するわけでもありません。

32ビット版のコマンドプロンプトからは32ビット版のメモ帳が起動し、64ビット版からは64ビット版が起動するので、自分はそういう関連を期待するからです。

[m-tmatma]

管理者のコマンドプロントと普通のコマンドプロントの振る舞いが違うのが、バグです。
統一されていたらバグではないです。

[k-takata]

32bit版だと、wsl.exeやOpenSSH（Win10 1803までならcurl.exeも）などいくつかのコマンドが使えない制限があります。たいていの人にとっては64bit版の方が便利なのではないでしょうか。

[berryzplus]

ほぼ話に付いて行けてないです。
どこに向かってるか説明が欲しい感じです。

コマンドプロンプトが何のためにあるかの認識は人によって違うと思います。最善はユーザが自分で選べるのがいいです。

とりま、管理者コマンドプロンプトは32bitが良いです。

管理者プロンプトってのは、今風のUACに対応してない古いツールを救済するためのものです。64bitツールにはそもそも不要なはずです。存在目的が違うなら違うことしていいと思います。

[k-takata]

どこに向かってるか説明が欲しい感じです。

私の意見は、管理者プロンプトも通常プロンプトも64bit版を開く方がユーザーにとって便利なのでは、ということです。

管理者プロンプトってのは、今風のUACに対応してない古いツールを救済するためのものです。

そうは思いません。bcdedit, fsutil, mklink, powercfg など管理者権限が必要な管理用コマンドラインツールを動かすのが第一目的でしょう。（ちなみにbcdeditも32bit版は存在しません。）
利便性を考えると、管理者かどうかに関係なく64bit版を開くのが良いと考えます。
今まで、32bitプロンプトを開いたことで問題に当たったことはありますが、64bit版を使ったことで問題に当たったことはないです。

逆に32bit版が必要な具体的な例はありますか？

[berryzplus]

bcdedit, fsutil, mklink, powercfg など管理者権限が必要な管理用コマンドラインツールを動かすのが第一目的でしょう。

• bcdedit windows起動モードの変更に使う
• fsutil ファイルシステムのチェックに使う
• mklink ハードリンクやシンボリックリンクを作るのに使う
• powercf 電源管理設定をいじるのに使う

mklink 以外は、便利に使えていいツールじゃない気がしました。
個人的にハードリンクはよく使うので、そのためだけに管理者コマンドプロンプトを起動する機会はあります。ハードリンクじゃなくてよいならpsからシンボリックリンク作るのに管理者権限は要らないはず。

逆に32bit版が必要な具体的な例はありますか？

regsvr32とかodbcad32とかdevenvとか・・・。

[ds14050]

繰り返しますが、実用上のメリットから64ビット版を起動することに反対はしていません。

管理者のコマンドプロントと普通のコマンドプロントの振る舞いが違うのが、バグです。
統一されていたらバグではないです。

これだけなら、直す方を間違えていると反論します。

[m-tmatma]

管理者のコマンドプロントと普通のコマンドプロントの振る舞いが違うのが、バグです。
統一されていたらバグではないです。

バグだという認識には同意しませんが、

最初のコメントは、上記のコメントに対するものです。

[ds14050]

最初のコメントは、上記のコメントに対するものです。

正しく理解していると思います。それをバグだと認識したとして、いじる方を間違えているのではないかと書きました。

泥仕合にするつもりはないので三度繰り返しますが、実用上のメリットから64ビット版を起動することに反対はしていません。

この PR のタイトルからの引用ですが「32bit アプリから 64bit OS上で起動したときに 32bit で起動してしまう」ことを修正するなら、目的はバグ修正ではなく実用上のメリットに基づくものではないかというのです。

バグ修正をかかげるなら対象は管理者用プロンプトの起動の方になるのではないかというのです。

この PR にはまだ bug ラベルが付いています。

[berryzplus]

64bitOS上で64bitコマンドプロンプトを起動するのは普通だと思うんですよね。

このPR前の状態の認識

OS	sakura	cmd	cmd(Admin)
64	64	64	64
64	32	32	64
32	64	×	×
32	32	32	32

こうなると思ってたんだけど、違うってことなんですよね。

[m-tmatma]

どっちでもいいので label を外しておきます。

[ds14050]

どっちでもいいので label (引用者補足: bug ラベル) を外しておきます。

たとえばこういう Issue があります> #619 「選択開始の挙動が、通常と矩形で異なる。」

これを安易にバグ認定してどちらかを修正に走ってしまうと、2ch.sc で指摘があった、矩形選択開始は Shift+F6 だけでなく Alt+矢印 にも割り当てられていて、そちらの割り当てではその方が自然だったということを見落とします。範囲選択開始の方を修正した場合でも、「バグ」仕様になじんでいたこれまでのユーザーをバグ認定によって切り捨ててしまいます。

修正が選好に基づくのかバグに基づくのかは妥当性の判断に大きな影響を持ちますから、というよりバグの場合判断の余地が残されませんから、どちらでも同じではありません。

[m-tmatma]

リリースされた機能とリリースされていない機能は分けて考える必要があります。

今回の機能はまだリリースされていなし、実装されてから時間がたっていません。
そのため基本的に「バグ」仕様になじんでいたこれまでのユーザーという前提は
考慮する必要はありません。

想定していた仕様で実装されていなかったので、バグとしました。

ただ対応前に事前に想定する仕様がきちんと共有されていたのか? という点では
共通認識になっていなかったのかもしれないので期待する仕様をチケットで
議論してからPR を投げる、あるいは、途中でチケットで共有しておいた方が
よかったのかもしれないです。

[KENCHjp]

これを安易にバグ認定してどちらかを修正に走ってしまうと、

以前、安易にバグって言葉を使いたくないと @kobake さんも言ってましたが、言葉の定義次第かもしれませんけど、仕様通りになっていない事はバグなんだと思います（例えば、AとBを加算する関数が、AとBを乗算するとか）。

#619 はバグかどうかという議論で言うと、「選択開始と矩形選択開始の振る舞いの違い」はバグではないと思います。
ただ「選択を開始する」とメニューにあるのに、「選択を終了する（トグル）」振る舞いをしてしまうのはメニュー名が機能を表せてない（類似な矩形選択を開始するがトグルになっていない）のは混乱を招いているのではないかとの問題提起があったのをうけたIssueです。果たしてメニュー表記がバグかどうかと言うと一概には言えないかもしれません。
コマンドの生い立ちで今の振る舞いが目的に合っているのならば、通常選択F6は「選択を開始・終了する」とあったら混乱を招いてなかったかもしれません（「選択を開始・終了」にしたほうがいいといういみではありませんが）

話はここにもどって、元々をよく見てませんでしたが、各々のコマンドプロンプトでカレントパスを指定するのに指定の仕方が違ってそれをsakuraで対応したってはなしでしたっけ？（それは解決済？）

議論になっている64bitと32bitどっちを起動するべきかは、選べるようにしてればいいんじゃないかと。。。（身もふたもないかな）
サクラからコマンドプロンプトを開く動機は人それぞれかもしれませんが、少なくても、ファイルの場所を コマンドプロンプトを開く動機に、bcdedit, fsutil, mklink, powercfg これらを目的としているとも思えないですし、そもそも32bitでなければならない訳でもなさそうかな。

[berryzplus]

間違ってたら突っ込んで。

話はここにもどって、元々をよく見てませんでしたが、各々のコマンドプロンプトでカレントパスを指定するのに指定の仕方が違ってそれをsakuraで対応したってはなしでしたっけ？（それは解決済？）

うんにゃ。64bit windowsで32bit SAKURA editorを起動してるときに、普通の「コマンドプロンプトで開く」すると32bitプロンプトが開くように実装されてたみたいです。管理者プロンプトの方は64bitが開いてたので「64bit windows で 32bitプロンプト開くのおかしくね？」というツッコミが入りました。で、バグでしたゴメンナサイ（＝設計意図と違う動きをしてるのでバグです）で bug ラベルが付いてた感じです。bug ラベルを付けること自体に問題はないと思っています。

採取的にこうなった認識(変更前 : #627 (comment))

OS	sakura	cmd	cmd(Admin)
64	64	64	64
64	32	32 64	64
32	64	×	×
32	32	32	32

[ds14050]

32ビットプロセスから32ビットプロセスが起動するのは予期できる挙動です。

[KENCHjp]

@berryzplus さん、まとめありがとうございます。
@ds14050 さん、確かに、自分のプロセスに応じてプロンプトを開くのか、乗っかってるOSに応じてプロンプトを開くのかは、予期できる挙動ですが、この機能を実装した人が意図してなかったら、それをbugと呼ぶ動機も分からなくもないですが、焦点はすでにそこではなくて、OS64+Sakura32の時に、一般権限と管理者権限で挙動が変わってしまうのがいいのかどうかってこと（なのかな。。。）

実装上、OS64+Sakura32の管理者権限で、32bitのコマンドプロンプト開けるんでしたっけ。。。
個人的には、結果的振舞いとして、OS64+Sakura32の時のコマンドプロンプトは32bitでもいいかなと思う方ですが、( @ds14050 さん派かな )、コマンドプロンプトを裸で起動するときに、狙って32bitのコマンドプロンプトを開こうとはしないとおもうので、乗っかってるOSに応じるほうがユーザフレンドリーなのかなと。

[ds14050]

すでにマージはされているので結論は出ているんです。k-takata さんが挙げてくださったように、64ビット版を起動することのメリットもあります。berryzplus さんのように 64 ビット OS だから 64 ビットプロセスが自然だろうと考える人もいます。

そこへ向かう過程において、この PR の修正内容に対してバグラベルが妥当かどうかという疑問と、安易に貼り付けて議論を停止してしまうことへの懸念を表明しました。

[ds14050]

「バグ」は強制的な力を持ちうるセンシティブな言葉です。だからこそ見過ごせずに「同意しない」と最初にコメントしました。そうしなければ以後は従うしかないからです。