【Bash】Windows Subsystem for Linux【WSL】4
■ このスレッドは過去ログ倉庫に格納されています
5ch(2ch)するだけなら問題ないかw
つうかDATがSJISなんだよな・・・ 5chもグローバル化の波に乗るかもよ?笑
多言語板が出来そうだが、キリル文字の荒しとかでそう。
まあそしたらAA香具師とか死にそうだけど。 🐧Д가
5chの場合、全部SJISで一部の板は文字参照としてunicode文字が表示できる
キリル文字はそもそもSJISに収録されてる(unicode前から顔文字に使われてたし) ファイルアクセス超遅い
configure終わらん
virtual boxにいれたopensuseのが速い謎 virtual boxのが速いってのは
ちゃんと仮想osと共有してるホストwindowsのディレクトリで
仮想oSから作業しての話ね。
ほんと謎 そりゃWindowsと協調して動作するよりも
Windowsと切り離して動かしたほうが速いだろうなとしか
当たり前じゃね? 物にもよるけどVMだとディスクキャッシュが効いて、ホストで動かすより速いこともある。
ディスクのスピードテストしてみれば分かる。 vboxsfとしてマウントしたwindowsディレクトリだから
当然windowsとは協調動作してますよ。 だからそれ以外の話だよ
システム環境をチェックするconfigureが
共有ディレクトリを多量にアクセスするわけなかろう cofigureが遅いのは、ファイルアクセスのせいはあまり関係ないと思う。
makeはそれほど遅くない。
cygwinと同じでforkが遅いせいだとおもう。
cofigure遅いといっても、cygwinにくらべたら、wslはだいぶ速い。
でも、native linuxからするとくそといいたくなるが。 Windowsにfork相当の機能がないのがそもそもの問題なんだよな。
今のMSならカーネルにforkもしくはforkが速くなる機能を
実装してくれると思う。 >>813
なるほどそっちか。
たまにfork自体を失敗するMSYS2よりマシかもしれんけど。
となるとVMつかった方がいいな。 >>815
使ってる部分もあると思うけど、NTカーネルAPIがWindowsの
本当のAPIでそれを利用する形でWin32APIが作られてる。
それと同じレイヤーでWSLが実装されているわけだから
基本的にはWin32APIを使わずにNTカーネルAPIを呼び出してるはずだよ >>816
VMは実質二台のパソコンを使うようなもので、
ホストOSとのデータのやり取りが面倒なんだよ。
つまりWindowsのテキストエディタを使って
プログラミングしてLinuxで動かすとかね。 >>817
だったらfork相当の機能がなくても困らないじゃん。
いにしえのPosixサブシステムと同じことすればいいんだし。 >>819
> だったらfork相当の機能がなくても困らないじゃん。
なんで?
> いにしえのPosixサブシステムと同じことすればいいんだし。
だからいにしえのPOSIXサブシステムも遅かったんだろ? >>814
RtlCloneUserProcess >>821
あー、はい。そのAPIがLinuxのforkに比べて遅いんでしょうね。
調べてくれてありがとね >>818
wslで/mnt/c経由でアクセスするのと、
virtual boxで /media/... 経由でアクセスするのと全く一緒だけどな。 >>823
一緒だからこそ、そこで差は出ないってことだよ。
つまり、差がでるのは共有ディレクトリではない所だということ
ここまですぐにわからんかね? あ、速度の話と勘違いしたわw
>>823
virtualboxで/media経由でアクセスするには、共有フォルダの設定が必要で、
さらに仮想マシンのOSにGuest Additionsをインストールしなければいけない
もちろんOSのインストールも必要だな。
気軽さがぜんぜん違うよ >>825
WSLでxで日本語使えるまでの設定どんだけ苦労したかwww
絶対virtualboxのが設定まで含めて楽w >>822
余談ですが、WSL Debian で sh (dash) を ksh93 で代用した時は、fork 処理が sh より速かったように思います。 前にも書いたけど、WSLのforkが遅いのはウイルス対策ソフトの影響もあるようだ。リアルタイム検索止めるとforkが早くなる。 defender糞遅くなるからビルドするときとか毎回切るわ >>827
ksh93は、他のシェルならforkを使うような場面でも
forkを使わずに(無理やり?)実現している場合があるので
fork処理が速いではなく、fork回数が違っている可能性が高い >>826
> WSLでxで日本語使えるまでの設定どんだけ苦労したかwww
WindowsがあるんだからXいらないよ LXDE試したことあるけど、デスクトップ環境を部分的にしか動かせない。
WSLでそこまでやるのはもう趣味レベル。
単にGoとかのスクリプト動かしたいけどWindowsだと面倒くさい時にしか使わない。
コンパイルやビルドは素直にVMでやったほうがいいわ。 >>837
普通にメモ帳でそのファイル名で保存できた
っていうかそれ、日本語ファイル名じゃないしw >>831
それ、聞いたことある。自分ではkshをうまく扱えなくて、つかってない。 hyper-vのパススルーディスクで、別SSDにインストールしたubuntuを使うと、I/Oのベンチで
windows側と比べて95%ほど出てるのでとても快適な環境なんだけど、linuxゲストだと
hyper-vの動的メモリ管理がひどくて、2GBから16GBで動的割り当てにしていると、linux側で2GBも
使ってないのに、すぐに16GB確保されちゃう。
・WSLは遅いし
・virtualbox with hyper-vは、別ドライブからの起動がうまくいかないし
・vmwareはhyper-vと仲悪いし
で、決定打に欠ける。
メモリ安くなったから、64GBにして解決するのもありかもしれない。 >>838
ファイル名はOSの管轄だからメモ帳とは関係ないだろ
NTFSのファイル名はそもそもUTF16が仕様だし
NT3.1でも対応したフォントさえあれば可能 >>843
batはロケール依存。今もUnicodeでファイル名を渡せない仕様。 >>842
Dynamic MemoryなんてWindowsゲストでもうんこでや(ボソ >>843
カーネル回りはUnicode前提で作られているけど
上部はWin9xとの互換性のためにShiftJISを採用
W系文字列とA系文字列を変換しつつ動いてる。
VC8.0からワイド文字がデフォルトに変更された。が・・・
未だにマルチバイトでビルドされたソフトも存在する。 \
 ̄ヽ、 _ノ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
`'ー '´
○
o
//三ミ彡ミヽ
//////⌒ ⌒ヾ ヽヽ
/.////ト、 i | | |i
|.| | | | ト、 ,二、| | | ||
ハ ハ | | | | / | // | | |
| } | } | | | |;;竺、、、///} ||
{ V .} | | | |ミ三ヲ` |/ / |/}
〉へと.ヽ| |こン / // ィ| と思うしぇしぇしぇであった
}イ`'( } `ー, へ、´ /| ||
\ヽ ノ { ノ`T⌒ }// >>844
> batはロケール依存。今もUnicodeでファイル名を渡せない仕様。
それはお前がコマンドプロンプトをsjisで起動してるからだろ
chcpでコードページを切り替えろよ >>846
> カーネル回りはUnicode前提で作られているけど
> 上部はWin9xとの互換性のためにShiftJISを採用
上部ってなに? Windowsと関係ない
一部のアプリがSJISを使っているからって、
WindowsはUnicodeなんだけど >>849
マルチバイトでビルドされたソフトには異なるロケールで引数渡しできない。文字化けする。>>846 さんの言ってることが現実。
Windows向けPerlディストリビューションのStrawberry Perlもマルチバイトでビルドされたソフトのひとつだよ。 >>852
残念ながら、OSはわざわざシステム本来のロケールに引数を復元してからアプリに渡すのでアプリの問題じゃなくてOSの問題なのよ。
つまり chcp 65001 しててもアプリにはコードページ932の文字列が渡される。アプリ側ではどうしようもない。 > OSはわざわざシステム本来のロケールに引数を復元してからアプリに渡すので
ダウト。そんな事しない 別に引数渡ししなくてもプロセス間で情報をやり取りする方法あるしな。 chcpはファイル入出力のコードページには何も影響しないよ。 ファイル入出力?何言ってんだ?そんな話はしてねえぞ。 OS(カーネル)はそんなことしない、引数の値をただ渡すだけ。そもそも、OSはどこにも噛んでない。
シェルの問題、パイプを噛ませるならともかく。 Visual Studio でビルドしたバイナリだとmain()で始まるバイナリであっても、
GetCommandLineW() と CommandLineToArgvW()でオリジナルに近いコマンド引数をUTF-16で得ることはできるね。 >>861
何を試すか示されてないのに、
どうやって試せと?w
お前なら何を試すんだ? ここでのOSの機能ってのはNTkernel<各種サブシステムを含む<コマンドラインを含む標準機能
って定義で揉めているの?
また文系が本質に関係ない所で暴れているのか ファイル名の話をしてるかと思ったら突然batがどうこう言いだして次はAPIか
何がやりたいのやら カーネルがUnicodeでシェルがShiftJISだった
それだけ コマンドプロンプト自体は少しずつ進化していってる。
昔は表示できない非SJIS文字が多かった。単にchcpしただけでは対応できなかった。 >>863
そうじゃない。
OSはAPIを提供している。
その中には古いOSやアプリとの互換性を保つためのAPIもある。
その互換性を重視したAPIを使ったアプリの仕様は
アプリの問題でありOSの問題ではないということ >>865
> カーネルがUnicodeでシェルがShiftJISだった
それだけだと中国でもShiftJISみたいだろw
それにシェルとコマンドプロンプトの違いもわかってない。
Windowsにおいてエクスプローラーもシェルだし、こっちは完全Unicode対応
Windows NT系は最初からUnicode。コマンドプロンプトもUnicode対応だが
互換性のためにデフォルトでは「Unicode対応でないプログラムの言語」の設定に
対応したコードページになっておりこれは変更できる。
ここまでかいて「それだけ」と言えるんだよ 古いAPIをいまだに使ってるライブラリが存在するのが問題ってのは全然問題じゃない。
互換性は必要なのだからOSの問題でもない。アプリもメンテが大変だから対応でなくても仕方ない。
できないことをやろうとする利用者の問題だろ。 取り敢えずおまえらが重箱の隅をつついてヽ(゚∀。)ノウェ―イってやってるってだけはわかったわ
そんなに文句垂れるならVM使うなり、サブマシンをサーバー化してSSH/MOSH,RDPでつなぐなりすればいいだけ。
WSLは成長途中で成熟すらしてないのに文句垂れるのはアホ。MsWinだって温故知新の如く開発をしている。それでもIEやレガシーシステム捨てないような阿呆のために互換性を捏ね繰り回して考えている。
我々利用者は限られた選択肢をどうするかだけだろ
利用者として要求するならインサイダープログラムにでもさんかしてフィードバックでもしろ。そうじゃなきゃ知識ある人間が文句垂れんなよ。 >>870
そういう人どこにでもいるから気にしない。
WSLには本当に感謝してる人もいるってことを忘れないでね。 sjis は、国際化されていない。
日本国内だけしか使えない
一方、UTF-8 は、すべての国(多国間)で使える
だから外人は、sjis 対応では作っていないから、ほとんどのアプリでバグる。
漏れら日本人が、言語一覧表に表示される、何百もの言語に対応しないのと同じ
ただ、WSL がすごいのは、Windows側のsjis のファイル名を、
Linux側では、UTF-8 に自動的に変換して、読めるようにしている >>872
逆。Unicodeのファイル名を可能な限りsjisで読めるように擬態してきたのがWindows NTのすごさ。 どっちでもよい。
単純にWindowsの開発が凄いってことだ Windows界隈でUnicodeというとUTF-16を指す、よね?
MSがすべての文字は16bitで固定的に表現できるって言ってた気がする UnicodeとSJISでは文字の並びが違うからそのまま文字列ソートしたら違う結果になる。
SJISの並び順を維持したままソートするのがWindowsNTの地味な偉さでそ。 厳密にはアプリがソートする時に使うSJIS互換の比較関数をWindowsNTが提供している。もちろんアプリはそれを使う義務はないけど。 アプリもAPIもOSの一部の機能を使ってるからOSが基本だな。
リストビューとかソートするプログラムもソート順だけ指定してあとはOSにお任せ。 >>874
ほんとそうですね。Linuxの10年先行ってる。 Windowsではなく、WindowsNTを作ったカトラー(DEC出身)がすごいのだ
むしろWindows1.0〜Meとの互換のためにNTの潜在能力を出し切れていない面が多い >>881
カトラーが作ったわけじゃないんだけどね。若い人かな? Windows API には、sjis/unicode 用の2つの関数がある。
すべて2種類作られている
MFC では、_T( )マクロで文字列を囲むと、両方に対応できる。
_T( "日本語" )
この型を、TCHAR 型と言う
そして、ソースコードのビルド時に、どちらのエンコードを使うか、指定できる
どの道、sjis を使うのは、日本人だけ。
外人のアプリでバグるから、どうしようもない
unicode なら外人も使うから、バグらない 外人が適当な実装するからバグりまくってた印象しかない
外人<Unicode対応したぜ!he he(ASCII相当な英数字しか通らない) >>872
Windows-31JはIANAにも登録されてると思うのだが ま、なんというか、WSLは織田政権が甲州征伐を決断したような「ついに来た」感はあるよね。 >>872
> ただ、WSL がすごいのは、Windows側のsjis のファイル名を、
Windows側にsjis のファイル名なんて一つもないよ。
すべてUnicodeのファイル名になってる。 >>883
> Windows API には、sjis/unicode 用の2つの関数がある。
あははw SJISは日本語専用なのに
日本語専用のAPIがあるわけないじゃないですかw
こういうレベルだから馬鹿にされるんやで >>875
> MSがすべての文字は16bitで固定的に表現できるって言ってた気がする
MSは言っていない。言っていたのはUnicodeを作ってる連中 >>876
> UnicodeとSJISでは文字の並びが違うからそのまま文字列ソートしたら違う結果になる。
ほんと言ってることのレベルが低すぎて哀れ
文字の並び? Unicodeでは文字の並びは文字コードの並びではない。
Unicodeではどういう順番にするかという並べ方が複数定義されてる
現在のロケールに合わせて適切な順番を選んでいるだけ >>872
今はもうsjisなんか使ってない
Unicodeを使って開発している。
外国人もUnicodeを使っている。そうしないと絵文字すら使えないから。
逆に言えば絵文字が使えればUnicode対応
Unicode対応で作ってるからほとんどのアプリはバグらない >>892
時系列?
Unicodeが最初にできて(文字の並びも)
Windows NTがUnicodeを採用して
その後にUTF-8が作られた
これでいい?
何がメチャクチャなのか知らんが FDもVFATにunicodeで入れてんじゃなかったか >>893
最初が間違いだな
元々UnicodeはJStarのコードだよ
Etehernet(イエローケーブル)とか
長い間、画面解像度が1/72inchだったのもそうだ >>884
英語圏はデータ増えるの嫌って
A系関数I決め打ちで作ってるソフトが多かった気がするけどなあ
そもそも9x全盛期だったが W系がデフォになったのもVS2005のVCからだし ■ このスレッドは過去ログ倉庫に格納されています