【PC】マイクロソフト、Windows 10にUNIX系OSと似た擬似コンソール実装
■ このスレッドは過去ログ倉庫に格納されています
長い間、Windowsにはネイティブに動作するOpenSSHの実装が存在しない状況が続いてきた。コンソールアプリケーションもかなりトリッキーな実装を行っている。UNIX系オペレーティングシステムでは当たり前に実現できていることが、Windowsでは実現されてこなかった。
Windowsでも結果的に同じように見える振る舞いを実現できるが、UNIX系のオペレーティングが提供している仕組みとあまりに違いすぎるため、これまでUNIX系オペレーティングで提供されてきたコンソールに関連するコマンドの移植は進んでこなかった。しかし、2018年秋のWinodws 10アップデートでこの状況が大きく変わる可能性がある。
Microsoftは現在開発を進めているWindows 10に「擬似端末（Pseudo Console）」の機能を実装するようだ。実装する機能の詳細は「Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY) - Windows Command Line Tools For Developers」にまとまっている。
UNIX系オペレーティングで実装されている仕組みとよく似ており、こうした機能を利用しているコマンドの移植がこれまでと比べて格段に簡単になるものと見られる。開発者は注目しておきたい機能だ。
物理的ターミナルはキー入力の受け取りや入力されたデータのバッファリングと送信、逆に送られてくるメッセージの処理と表示といった処理を行っている。マシンの性能が向上し、マルチウィンドウシステム上で複数のターミナルアプリケーションを実行できるようになると、これまで物理ターミナルが実施していた処理をソフトウェア的に行う必要性がでてきた。この時に開発された仕組みが擬似端末だ。物理ターミナルが行っていたような処理を擬似端末が担う。
擬似端末はsshでサーバにログインする場合などにも使われている。現在であれば、sshでサーバにログインすればその分だけ/dev/pts/にファイルが生えてくることを確認できるだろう。sshでログインするとその分だけ擬似端末が使われている。こうした仕組みがあることで、ターミナルを利用するコマンドを簡単に開発できるようになっている。
これまでのWindowには擬似端末の仕組みが用意されていなかったため、Windows版のOpenSSHは以下の画面のようにWindowsで提供されている機能を使って動作を実現していた。オリジナルのOpenSSHの実装系と比べると、Windows風のコードを従来の実装に交ぜることになる。
https://news.mynavi.jp/article/20180817-679662/ 太郎丸@転職コンサル@tenche1204
年功序列が残っている大企業は今でも窓際族の中年だらけです。特に大手商社などでは仕事をしてい
ないのに年収2000万の50代のおじさんたちで溢れかえっています。彼らは窓際で新聞を読んでいるだ
けで2000万も貰えることから社内でWindows2000と呼ばれてます。 >>78
創造主様に「死ね！」と言っている様に感じた >>61
サーバーコア使えばいいじゃん
もしかして存在知らなかったの？ >>78
initとカーネルのコード追えば解る
initがシグナル受けて終了処理やって最後にshutdownシステムコール発行、カーネルが終了処理やって最後にACPIのshutdown実行、ACPIが電源切る(PCの場合) せめて、UNIXベースにして、Windows風GUIを載っけろよ。
まぁ、どちらにしろ、OSXかLinuxを使うけどね。 インストールしてきた
Linuxのコンソールがあるとホッとする いくらやってもダメなWindows、いい加減もうUnixにしたら 日本政府の組織ですらGmailを使っているんだからな
ITが弱いアメリカの属国だよな 尚、Windows10の仕様上
すべての操作は記録され、専用サーバへ送信されます >>33
> 3.1のころみたくコンソール単独でも起動できるようにしてほしい。軽いオプションほしい
既にあるだろ。 >>56
文字コードもさっさとUTF-8にしてほしい 朱子学の模範例である林羅山
ZEIKIN@ccakahada
2017年8月28日
林羅山のwikipedia、修道士の「地球球体説と地動説を論破」して結果的に棄教まで追い
込むわ、方広寺鐘銘事件の例のいちゃもんで豊臣家滅ぼすわ、上下定文の理で身分制度を
絶対化するわで、めっちゃ強かったです。
倉本圭造@keizokuramoto
2014年12月27日
下呂温泉を日本三大名湯に入れた林羅山はイエズス会修道士と地動説について公開討論して
『天動説側に立って勝った』らしい（笑）その修道士は精神が動揺して棄教までしたとか。
ここまで行くと清々しい現実歪曲空間（ジョブズの）だな！と思って憧れた。
いしやんＷＲＸ＠走り屋小説＆ＴＲＰＧ@ishiyanwrx
2013年7月7日
江戸時代の儒学者・林羅山は欧州からきた知識人を相手に討論し、なんとまあ地動説を論破
しなさったそうな。無論、現実に地球は回っているわけでして。これは偉い人が説得力のあ
る論陣を張ってもそいつが常に正しいわけじゃないことの明確な証左でしょう。 >>71
今はPowerShellだけで一通りなんでもできる。 >>94
Shift_JISは日本製、UFT-8は外国製。
Microsoftは日本製であることを考慮して
DOSやWindowsにShift_JIS採用しているから互換性無視して変えることは絶対にないだろうね。 >>76
Windowsの構造を知ってたらそんな戯言は言わないと思うが。
まぁ、ビジ板なんてバカしかいないから突っ込むだけ無駄だが。
と言うかこの記事が何寝言言ってるんだ？という記事なわけだが。 >>98
Windowsもファイルシステムの一部でUTF使っているんだけどな
ハートマークのファイル名作れるだろう >>94 >>98
コマンドプロンプトで、chcp 65001 でできるだろ。 そんなことも知らんのか？ >>102
デフォルトでって話だろ
自分のPCだけ換えても意味無いからな >>57
macOSはBSD系UNIXがベースだ
ことさら売りにしていない とにかくShift_JISは辞めろ
MSさえ撤廃すれば日本人の目が覚める
あと、UTF-8のBOM付き辞めろ 狂人はなぜかやたら「UTF-8のBOM」を攻撃するという話がまた裏付けられた。 >>110
そもそもUTF-8にBOMなど必要ない
UTF-8にバイトオーダーなど無いから
Excelの.csvファイルなんかでいまだにBOM付き必須になっている意固地さはなんだろね MSはLinux文化も認めて両対応を進めているんだから、他のOSでも対応を強化すればいいだけ >>111
U+FEFFは単にバイトオーダーを示すためだけのものじゃあないから。
UTF-8にバイト順は関係ないが、RFC等で言うところのBOM(U+FEFF)に意味はある。 >>104
レジストリ設定で、コマンドプロンプトのコードページ初期値は、ユーザーアカウント
毎に変えられる。 さらに言えば、コンソールアプリ内からも、SetThreadLocale()
というAPIで変えられるし、関数名から判るとおり、スレッド毎に変えられる。
ttps://msdn.microsoft.com/ja-jp/library/cc448087.aspx
そんなことも知らないの？ 最近追加された新しいAPIではなく、XPよりも前の
Windows NT 3.51から実装されている。
日本語版がShift JIS(CP932)なのは、過去のソフトウェア資産の互換性を保つため。 >>94既にベータ版機能として利用可能だろ
だが有効にすると結構なアプリが誤動作する Windowsの性で、過去のソフトウェア資産が殆ど死にそうになってる >>117
だから何？
ディフォルトの意味わかってないのか？ w >>120
BOMの件も同様だけど、決め打ちでしかソフトウェアを組めない馬鹿は死ね。 そういうこと。 >>121
こんな所で喚いてないでソフトメーカーに言えよ、バーカ 多分身内の誰かへの当てこすりなんだろう
察してやろう >>117
寝言は世の中に溢れるShift-JIS文書を全部レジストリ設定wでUTF-8に変換してから言えw
お前のPCのローカル環境の話はチラシの裏にでも書いてろ池沼 >>116
あんたそりゃUTF-16のBOMでしょ >>126
ファイル先頭のFEFFかFFFEの２バイトでUTF-16文字コードのバイトオーダーを指定するんだよ
FEFFならビッグエンディアン UTF-8 0xEF 0xBB 0xBF
UTF-16
BE 0xFE 0xFF
LE 0xFF 0xFE >>127
まさかと思ったが U+FEFF という表記がバイト列じゃなくてコードポイントを表しているという
基礎知識すらないんじゃ話にならん。Unicodeについて語る資格なし。 UnicodeがはじまったころはアメリカではASCII、ヨーロッパなどではISO-8859、日本ではShift_JISやEUC-JPが
主流であり、使用されている符号化方式がUnicodeであることを明確に区別する必要があった。その方法として、
先頭のデータにテキスト以外のデータを入れることが発案された。
また、1文字が数バイトに渡るUnicodeでは、エンディアンの違いが認識できないと、例えばPowerPC Macintoshと
x86 MS-DOSとの間で正常にデータの交換ができないため、この先頭バイトにより区別できるようにされた。 >>131
生半可な知識ですね。
コードポイントって単なるコード表の中の文字位置のことですよ。
BOMの必要性とは関係ない話。
そもそもあなた>>116でBOM(U+FEFF)って書いているじゃないですか
なんか生かじりで人にからんでいますねえ 通信ならバイトオーダーを調整出来るだろうけど
ファイル共有やってたらどうしようもないな >>17
大型アップデートはHDDだと3〜4時間は平気でかかる
SSDでも1時間は必要 >>135
4月の大型アップデート30分も掛かんなかったけど、どんだけオンボロPC使ってるの？
まあ、初期の頃は結構ひどかったけど、年々短くなってきてる印象だけどね
ただ、累積Updateを積み上げたときは酷い
実家にあるPC、ほとんど触られてないからか帰省のたびに山のようなアップデートが来ててうざかったから
そちらはCloudReadyに置き換えた >>133
流石にこれは恥ずかしい
Unicodeスカラ値 とか知らんのかよ w きっとコードポイント知らなかったんだろうな
とりあえずググってみたがMuT7wP7Tの言ってることは理解できなかったみたいなw >>140
エミュレータ使わずにできるようになるからいいよねっていうスレなんだよ エミュレータだと出来たことが出来なくなったりは、しない？ >>105 >>107
なんも反論できない人が書くような常套手段のようなレス
て思ったら>>133で、まあそういう人なのねと納得ｗ >>136
オンボロ？i5の6300Uだけど
スペックは高い方だ >>144
なんでCPUを真っ先に出すの
ストレージとメモリについて出す方が適切だろうに 以前からコンソールあったでしょ
config.sysとかタイプするやつ >>138
>>139
何言ってるのかなぁ、この人たち
UTF-8でBOMが必要か否かの話を表記方法の話にすり替えている
最初に絡んだID:MuT7wP7T君はどこへ逃げたのでしょうか？
ID:Zt3S6RPU君と同じ匂いしますけど
コードポイントだとかUnicodeスカラー値とかってさも自慢げにタームだけ振り回しているけど、それがBOMの必要性と何の関係があるのかという言及が一切ありませんね。 ボクは逃げも隠れもしないよ
ID:TaAA6koY=ID:P88+4vq6
だからね >>116
↑
これ書いた人、きちんと落とし前付けてね
UTF-8のBOMの話にUTF-16のBOM表記（ビッグエンディアン）持ち出して、「RFC等で言うところの」などと頓珍漢過ぎてわからんのですわ。 >>148
必要か否かの話なんてしてない
BOM(U+FEFF)に
> あんたそりゃUTF-16のBOMでしょ
とか言うアホを嘲笑してるだけ w >>151
>必要か否かの話なんてしてない
>>116の意味は？
それと
>>125のどこがおかしいのか指摘して欲しい >>57
Mac は互換じゃない
Unixそのもの
しかもNeXTSTEP譲りのGUIで完璧 >>152
> U+FEFFは単にバイトオーダーを示すためだけのものじゃあないから。
→ >>130, >>132の前半
> >>125のどこがおかしいのか指摘して欲しい
→ U+FEFFはコードポイントの表記でUTF-8にもあるからU+FEFFを見てUTF-16と思いこむのは知識が足りなさ過ぎ
ちなみにU+FEFFのバイト列がどうなるかは>>129が書いてる >>152
とりあえず落ち着いて皆のレスを声に出して100回読んでから出直せゆとり >>145
ストレージはSSDって最初に書いただろ
オンボロとか的外れな指摘にはCPU出せばそれで十分
別に君にトラブル解決してもらうために質問してるわけでもなし Embedded化したXpのAM1マシンですら1時間も掛からん。
トラブルシュートすらできん無能は、なんでもWindowsのせいか。おめでてぇな。 >>156
空きはどれだけあるのか、PCIe接続なのか、そもそもメモリの容量と帯域はなんなのか
全くといっていいほどレスから分からないから、なにもしようがない
アスペなの君 わからないならスルー
5チャンネルからのお願いです ubuntuの上でWindowsを動かせはいいのではないか？ >>160
MS-DOS上でWindowsを動かしたようにか？ コマンドラインはCygwin使ってるな
コマンドプロンプトはUTF-8に対応してないからな
今はもう、テキストファイルはよほどの理由がない限りUTF-8にしてる >>154
君は>>129の意味わかってないでしょ？
ちょっと気の毒な感じがする。 >>154
>U+FEFFはコードポイントの表記でUTF-8にもあるから
テキストとバイナリの区別ついているか？
大丈夫？ >>163
> 君は>>129の意味わかってないでしょ？
なら説明してみ
> ちょっと気の毒な感じがする。
お前さんがな w
>>164
> テキストとバイナリの区別ついているか？
テキスト？
頭大丈夫？ >>165
>なら説明してみ
BOM付きUTF-8ならファイル先頭から３バイトがEF,BB,BF
UTF-16ならファイル先頭から２バイトがFE,FFもしくはFF,FE。前者ならビックエンディアン、後者ならリトルエンディアン
わかった？
君はスクリプト言語しか経験ないのかな？ >>165
ターミナルでUTF-8（BOM付）とUFT-16エンコーディングのファイルを16進ダンプしてみ C:\Users\user>filedump utf16L.txt
-------- 0 1 2 3 4 5 6 7 8 9 a b c d e f 3 7 b f
00000000 : fffe226f 575b0d00 0a00 .."oW[....
C:\Users\user>filedump utf16B.txt
-------- 0 1 2 3 4 5 6 7 8 9 a b c d e f 3 7 b f
00000000 : feff6f22 5b57000d 000a ..o"[W....
C:\Users\user>type utf16L.txt
漢字
C:\Users\user>type utf16B.txt
o"[W >>166-167
> BOM付きUTF-8ならファイル先頭から３バイトがEF,BB,BF
> UTF-16ならファイル先頭から２バイトがFE,FFもしくはFF,FE。前者ならビックエンディアン、後者ならリトルエンディアン
それ…
>> ちなみにU+FEFFのバイト列がどうなるかは>>129が書いてる
で書かれてるバイト列のことなんだけど…
で、テキストってどこから出てきたんだ？ w 先頭2バイトのコードは、テキストデータでは使われない値 すでにubuntuとかsuseのbash入れられるのになんで？ >>158
中途半端に知識のある典型的なコミュ障オタクだね、君
だから君にどうにかしてもらおうとなん思ってないから、そんな情報はいらんのだよ
大体、SATAだろうがNVMeだろうが、メモリ帯域幅がどうであろうが、
ことWindows updateにおいてはそんなもんの影響は大したことは無い
僕ちゃんのハイスペマシンだと30分かからず終わるのかもしれないが、
激安でもない普通に売ってる現行機でも、大型アップデートには相当の時間がかかるもの
所要時間なんてググればスペックと一緒にいくらでも出てくるわ U+FEFFがBOMのコードポイントだってことは理解できたのかな？w 今更
アップルの通って着た路線を真似するなよ。
最低。 ■ このスレッドは過去ログ倉庫に格納されています
