Win32API質問箱 Build125

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/02/27(水) 15:09:08.64ID:6ExXwgQU
Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
 英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build124
http://mevius.5ch.net/test/read.cgi/tech/1510395780/
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2019
http://mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2017 Part6
http://mevius.5ch.net/test/read.cgi/tech/1528645068/
【C++】 DirectX初心者質問スレ Part41 【C】
http://mevius.5ch.net/test/read.cgi/tech/1521786252/
2019/11/09(土) 21:35:29.14ID:hHKZwsDl
GetPixelって内部でどうやってるのかな
毎回呼び出すと遅いんだよね
2019/11/09(土) 22:19:46.16ID:HyuDdIlK
故意に減速してるようだね

ビットマップオブジェクトにキャッシュしといて
そこから取ると普通の速度になる
2019/11/09(土) 22:41:44.97ID:e6n/6jzv
gnsk
2019/11/09(土) 23:25:01.42ID:HanEs9+F
仮にVRAMから1ピクセルだけ毎度読み戻してたらそらクソ重いやろとは思うが
今のDWMってGDI周りの扱いがどうなってんのかよくわかんねえからな
2019/11/10(日) 06:21:08.90ID:nWjdF62e
XPでは爆速だったのがVistaから突然遅くなった
2019/11/10(日) 09:02:24.14ID:R9o6dqtJ
TOPMOSTの競合の話ではない
"ごく稀に TOPMOST ウィンドウが通常のウィンドウの背面に移動してしまう現象が発生するとお問い合わせいただいています。"
"•Windows 8.1 以降、Windows 10 でも数十回に 1 回程度この現象が発生します。"
2019/11/10(日) 09:11:24.47ID:IRh+3wYd
>>611
メモリー積め
ってかPC買い替えろ
2019/11/10(日) 09:22:52.91ID:nWjdF62e
>>613
GetPixelの話だよ?
2019/11/10(日) 10:13:14.69ID:2HW6YGp5
それはAeroのせいかも知れない。
色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって
いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、
その場所に重なっている全ての Window の色が分からないと、画面に表示される
色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、
各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの
ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、
アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
再描画をさせるのが伝統的やり方。
このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、
例えたった1点の色であっても、非常に沢山のCPUパワーを必要としてしまう可能性が
ある。仮想VRAMにキャッシュしておけば高速化できる可能性は高いが。
2019/11/10(日) 10:14:06.88ID:2HW6YGp5
>>615
誤:色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、
誤:色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、
2019/11/10(日) 10:48:16.19ID:IRh+3wYd
>>614
ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね
Windows 7から改良されたからマシになってるはず
2019/11/10(日) 11:26:39.91ID:GjrjejsC
aeroで半透明になるから描画に時間かかる←わかる
だからgetpixelに時間かかる←う〜ん

呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
2019/11/10(日) 11:30:44.05ID:42Oft6n8
getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い
個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い
個別の描画内容は多分システムメモリ上にある
大体そんなような動作っぽい
getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな
2019/11/10(日) 12:37:49.81ID:R9o6dqtJ
> 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
1x1のビットマップに転送して取得しているのでxpでも遅かった
2019/11/10(日) 13:55:52.22ID:fP398yW4
>>615
> そのWindowにWM_PAINTメッセージを送って、
> アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
> 再描画をさせるのが伝統的やり方。
> このやり方に従っているなら

もうやってないというか「重なり」なんて概念がないよ。
動画再生して、他のウインドウの後ろに隠して、
その状態でタスクバーにマウス乗せてみ
画面に表示されてなくても、ウインドウの中身は更新されてるからさ。

最小化したときはアプリ側で描画止めてるソフトが多いけど
それでも最小化した時点の縮小画面は見れるし

Windows VistaのAeroから変わってるんだわ。
半透明処理もGPUにやらせてるからWindows 2000の頃と違い格段に軽くなってる。
2019/11/10(日) 13:57:05.17ID:fP398yW4
>>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された
623デフォルトの名無しさん
垢版 |
2019/11/10(日) 14:11:16.15ID:hRll0rFL
>>606
GetDC GetPixel で取れない場合
http://maverickproj.web.あれ.com/d3d11_04.html
http://ka-ka-xyz.はて?.com/entry/20101209/1291890231
https://codeday.me/jp/qa/20190207/239003.html
2019/11/10(日) 14:11:28.61ID:O4L9SaaX
GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。
2019/11/10(日) 14:17:16.14ID:fP398yW4
昔はVRAMにあったものがGPUのメモリにあるわけだからね。

通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。

だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。
2019/11/10(日) 15:48:36.60ID:GjrjejsC
でもaero切ると描画速いよw
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
2019/11/10(日) 15:51:41.38ID:u8+xJCBj
同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
2019/11/10(日) 16:09:15.77ID:GjrjejsC
もう滅茶苦茶だなw

そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ

で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ
2019/11/10(日) 16:51:52.04ID:invbJGJm
Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど
2019/11/12(火) 19:29:29.86ID:fqP05o8Z
HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。
2019/11/12(火) 19:33:32.19ID:R9AMJEW8
>>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。
2019/11/12(火) 20:44:06.06ID:mKGma296
>>630
SetWorldTransform
633デフォルトの名無しさん
垢版 |
2019/11/13(水) 10:09:58.07ID:OceCV+VL
DirectX使えば自由
634デフォルトの名無しさん
垢版 |
2019/11/19(火) 11:11:30.06ID:NEogfZFa
いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。
2019/11/25(月) 20:46:42.81ID:0q+n1Hac
Windows10 での symlink
https://social.msdn.microsoft.com/forums/ja-jp/c6141e7e-0327-4b27-a1b8-d453a169a57b/windows10-1239112398-symlink
63649
垢版 |
2019/11/25(月) 22:38:11.66ID:dg2mzwJY
>>630
GDIPlusは駄目なん?
2019/11/25(月) 22:53:59.71ID:S0HuE7/3
StretchBltでマイナスの値を指定するとミラーリングできるらしい。
http://forums.codeguru.com/showthread.php?524692-BitBlt-with-mirroring
2019/11/26(火) 00:15:01.51ID:FXTOqUMb
どっかで阿鼻叫喚が始まる予感
ttps://twitter.com/MurakamiShinyu/status/994781934407553024
https://twitter.com/5chan_nel (5ch newer account)
639デフォルトの名無しさん
垢版 |
2019/11/26(火) 09:59:26.09ID:c3SEnPpX


いよいよcp932ともおさらばか
試行錯誤はあっても良い流れは認めよう
問題が出たら出たで治せば良いんだから
治す範囲がどんだけあっても諦めるな
なにもやらないよりまし
2019/11/26(火) 10:49:04.39ID:LSm6MssX
一年前以上からあるオプトイン設定の話だが
2019/11/26(火) 11:36:11.45ID:fVihpbt7
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。

cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。

Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
2019/11/26(火) 11:45:03.56ID:fVihpbt7
「ワールドワイド言語サポートで Unicode UTF-8 を使用」をするとどうなるか?

Unicode対応のアプリ・・・設定とはとは無関係にUnicode対応

Unicode非対応のアプリ・・・
  日本語アプリはcp932でないと動かない。
  ASCIIしか使えないアプリはcp932でもUTF-8でも動く。
  UTF-8に対応したアプリは現時点ではまず存在しない。
  この設定は今後UTF-8に対応したアプリが作られたときのための設定
  この設定はデフォルト値でしかないのでUTF-8にしてもchcp932相当のことをすればcp932アプリは動く
  互換モードの設定でコードページを指定できるようになるかもしれないね
643デフォルトの名無しさん
垢版 |
2019/11/26(火) 11:55:01.45ID:sOexhNbU
コマンドプロンプトは怪しいな
2019/11/26(火) 11:55:11.67ID:dbvsSdaZ
いまだにファイルパスがユニコード対応してないアプリあるからな。氏ねと言いたくなる
2019/11/26(火) 11:57:13.82ID:fVihpbt7
>>643
コマンドプロンプトはUnicode対応だよ
cp932の状態でもdirでUnicodeのファイル名表示できてるじゃん
646デフォルトの名無しさん
垢版 |
2019/11/26(火) 12:05:13.97ID:sOexhNbU
chcp 65001
でバグバグになるのいつ治るの
2019/11/26(火) 12:08:00.36ID:fVihpbt7
>>646
表示が崩れる問題なら直ってる。
動作自体なら以前から問題なく動いている。
2019/11/26(火) 12:30:13.72ID:4pvDP8OD
>>641
こういう流れになってますが
ttps://twitter.com/unagix/status/1198150980317016065

動かなくなるんじゃなくて、破壊されて動かなくなるのが正解なのでは?
https://twitter.com/5chan_nel (5ch newer account)
2019/11/26(火) 12:31:57.39ID:Yz+apKYY
>>648
破壊されて動かなくなるとは、一体どこにそんな証拠があるのでしょうか?
2019/11/26(火) 12:39:10.74ID:Yz+apKYY
実際に試した人たち
https://qiita.com/obaba/items/c88c6ef833cac23bb01e
https://adatarag3.blogspot.com/2019/03/pcwindows10utf-8.html
https://chiyosuke.blogspot.com/2019/05/windowsutf-8.html

「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」から
「日本語(日本)」に戻して文字化けが直った人
https://kuronyankotan.com/?p=1596
2019/11/26(火) 12:50:39.23ID:4pvDP8OD
全てのA系APIがUTF-8をI/Oするんじゃろ?
非対応アプリがテキスト系ファイルI/Oしたら死ぬのでは?
2019/11/26(火) 13:01:13.64ID:Yz+apKYY
>>651
WindowsはUnicode対応なので関係ない話
非対応アプリが動かなくなるだけ
2019/11/26(火) 13:03:50.25ID:Yz+apKYY
だいたい全てのA系APIがUTF-8をI/Oしたからって
何の問題があるんだ?

今までだってそれは、全てのA系APIがSJISとかASCIIとか
韓国や中国のなにかに変更するスイッチだっただろうと
そこにUTF-8が増えただけに過ぎない。
2019/11/26(火) 13:06:07.48ID:VJ34cQn0
Windows自体は昔からUTF16だと思ってたんだけど、
いつのまにかUTF8になってたの?
2019/11/26(火) 13:08:57.76ID:njyF587z
A系
2019/11/26(火) 13:12:06.34ID:Yz+apKYY
>>654
Windows NTはUTF-16だよ?

この設定はUnicodeに対応してない古いWindows 9xアプリのための
互換モード設定だから

将来的に互換モードとして使っていたこの機能をUTF-8アプリの
移植用に利用しようとか考えてるんでしょ? Linuxアプリのこともあるし。

WindowsネイティブのUnicode(UTF-16)モードとは別に
UTF-8モードが追加されたってだけの話
657デフォルトの名無しさん
垢版 |
2019/11/26(火) 13:29:27.34ID:4pvDP8OD
>>652-653
>>651

A系アプリの問題の話なのに、なんでWindows自体の話になるの?
てか、>651のみならずリンク元の流れすら読んでない感じ?
まあ実際俺も試したわけじゃないけど、書いてることが事実だとすると
設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
2019/11/26(火) 13:35:05.31ID:Yz+apKYY
> A系アプリの問題の話なのに、なんでWindows自体の話になるの?

A系アプリってなんだ? A系っていうのはWindows APIのAPIの末尾のAだろ
Windows APIの話なんだからWindowsの話だろ?

Windows自体はWindows APIのW系(Unicode)を原則として使用してるが
古いアプリのためにA系のAPIも提供してる。Windows はW系を使ってるので
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
したところで何の影響もない。影響があるのは古いアプリのみ

> 設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
それならデータ消せばいいだけだろ。アプリの都合なんか知るか
659デフォルトの名無しさん
垢版 |
2019/11/26(火) 13:46:31.66ID:dAEqoOXB
朝鮮人は息を吐くように嘘を吐く
2019/11/26(火) 13:47:38.02ID:4pvDP8OD
>>658
>それならデータ消せばいいだけだろ。アプリの都合なんか知るか

だからそのアプリの話を一貫してしてるんだけど?
アプリのデータを消す?
大事な既存データでも消したらOK? 馬鹿? 仕事したことない?
システムプロファイルも全て戻らないということなので、戻したら動く保証はどこにもない

何度も言うけど、A系アプリの話だからな?

例えばCの話をしてるのにJaveや.NETが今は主流だからCなんて知らん
って的外れなこと言ってるだけだお前は
2019/11/26(火) 13:55:16.74ID:Yz+apKYY
>>660
何が言いたいのかわからん。
アプリが動かなくてなってもWindowsは問題なく動くだろ

SJISにしか対応してないアプリのコードページを変えてデータが壊れたって
それはアプリの動作保証外の使い方をしたからってだけで
OSのせいでもアプリのせいでもない。

データ消えたら困るなら保証外の使い方をするなよ。
バックアップぐらい取れ。
662デフォルトの名無しさん
垢版 |
2019/11/26(火) 13:58:46.51ID:dAEqoOXB
役に立つ人柱はここか
https://chiyosuke.blogspot.com/2019/05/windowsutf-8.html
https://srad.jp/story/17/11/14/0640253/
2019/11/26(火) 14:08:16.07ID:dbvsSdaZ
英語圏の人間向けであって、日本人が使うオプションじゃないからな
大手のソフト含めて対応してない(設定変えるとおかしくなる)のは山ほどあるよ
2019/11/26(火) 14:13:24.26ID:JyI6kWkc
>>660
君はちょっと落ち着け

>>648の内容はシステムの設定を元に戻せないという話であって
アプリの話じゃないだろ

そして
>大事な既存データでも消したらOK? 馬鹿? 仕事したことない?
だったらβの機能なんか使うなよ、で終わりだよ

βじゃなくなるときに、キレイに全部戻せるようになってるか、
SJISアプリは切り捨てますって発表があるかのどっちかだろ
2019/11/26(火) 14:17:07.29ID:4pvDP8OD
>>661
なんでWindowsが動かなくなる(だったりWindowsの問題や責任)話と勘違いしてるの?
単純に設定変えたらA系アプリに問題があるねってだけの話だぞ?
的外れも甚だしいし視野が狭すぎる

過去資産を使ってるクライアントを持ってたら、この手の話には敏感になるわ
バックアップとかそういう次元の話じゃない
お前みたいなのがクライアントのサポートしたらクライアントが居なくなるレベル
2019/11/26(火) 14:22:54.58ID:Yz+apKYY
>>665
だから何が言いたいんだよ。
cp932前提の古いアプリはUTF-8で動きませんって
当たり前の話なだけだろ
2019/11/26(火) 14:24:20.04ID:Yz+apKYY
つーか、最初っから俺が言ってるんだわ

641 自分:デフォルトの名無しさん[sage] 投稿日:2019/11/26(火) 11:36:11.45 ID:fVihpbt7 [1/4]
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。

cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。

Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
2019/11/26(火) 14:28:45.38ID:4pvDP8OD
>>664
> だったらβの機能なんか使うなよ、で終わりだよ
まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
割を食うのはこっちになったりすると目も当てられんからね

>>666
そんな当たり前の次元の話を一切してないからね
669デフォルトの名無しさん
垢版 |
2019/11/26(火) 14:29:07.54ID:dAEqoOXB
ふ〜ん
Pythonで問題起きるのか

Rubyはどうなんだろ
670デフォルトの名無しさん
垢版 |
2019/11/26(火) 14:32:29.48ID:dAEqoOXB
上の >>662 のPythonの人は
PYTHONENCODING=utf-8の方を気にしてるけど
setdefaultencodingとかはどうしてるのかな
2019/11/26(火) 14:34:38.59ID:4pvDP8OD
>>667
> cp932使ってる古いアプリは、この設定にすると
> 動かなくなるだけ。つまり捨てるしか無い。

この時点で間違ってる
つーかW系A系のAPIの使い分けしたことあれば、A系の動作が変わることでどうなるのか
ってある程度予想できそうなもんだけど、なんでここまで勘違いが続けられるの?
2019/11/26(火) 14:46:41.11ID:LSm6MssX
プロファイル壊されるってゆーてるリンクの連中だけが情報量ゼロなの草
2019/11/26(火) 14:53:48.35ID:hqQvrruW
結局W系で作るしかないんだから余計なことは考えなくていいよ
674デフォルトの名無しさん
垢版 |
2019/11/26(火) 14:54:37.98ID:ogXaluX+
fopen()の振る舞いで困るかも。Win32のfopen()はutf8を特別扱いするから。
675デフォルトの名無しさん
垢版 |
2019/11/26(火) 14:56:55.82ID:dAEqoOXB
レジストリの読み書きも気になるな
2019/11/26(火) 15:01:36.94ID:JyI6kWkc
>>671
いわゆるバイナリモードを使うとBOMがついてきちゃうとか、
いろいろトラブルが発生する可能性はあるね
前回のアップデートでもコンソールで文字化けする問題があったし

それをざっくり言えば、古いアプリを捨てるか、設定変えんな、
という話になるだろ
APIオタクと運用を見てる人で視点が違うことを理解しなよ

>>668
>まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても

それは契約文書にきちんと盛り込むべきだね
2019/11/26(火) 15:25:37.49ID:SWHzOLKZ
MultiByteToWideChar/WideCharToMultiByteの第一引数にシフトJISコードページ932を指定しないといけないらしい。CP_ACPだと死ぬ。
2019/11/26(火) 15:33:53.01ID:Yz+apKYY
>>672
壊されないよ。日本語が化けることはあっても
それは想定とは違うデータが入っただけだし
アプリの問題
2019/11/26(火) 15:37:00.29ID:SWHzOLKZ
シフトJISテキストファイルにUTF-8テキストが混ざったら、そりゃ文字化けするでしょう。
2019/11/26(火) 15:56:07.44ID:9NQ9wJPH
>>679
無茶苦茶になるよな
ありえんわ
2019/11/26(火) 16:01:44.16ID:Yz+apKYY
コードページを変えると文字化けするだろうね
それだけの話。別に動かなくなるわけじゃない。
コードページをもとに戻せば動く
壊れたデータは直せばいいだけ
2019/11/26(火) 16:02:07.57ID:ogXaluX+
main()に渡される引数文字列argvどうなります?
2019/11/26(火) 16:23:03.19ID:9NQ9wJPH
自前で先行バイト検出しながら文字列書き換えるような関数とか如何すんのよ
2019/11/26(火) 16:23:44.61ID:H048FZbZ
>>682
Unicode非対応アプリのmainだとして、

Unicode対応アプリ(からUnicode APIを使って)呼び出せば、引数全てがUTF-16からUTF-8に変換されてから
呼び出される。Unicode非対応アプリから呼び出せば、渡した文字列(バイト列)がそのまま渡される。

そこは今までと変わらない。今までもUnicode対応アプリから呼び出せば、設定されたコードページ(例えばcp932)に
変換されて呼び出される。違いはUTF-16からUTF-8だと変換できない文字がないので文字化けは一切発生しない。

なお、渡されたからと言ってアプリが正しくその文字列を扱えるかどうかは別の話
結局の所cp932専用で作られたアプリは完全に同じようには動かない。(ASCIIの範囲でなら問題ないだろう)
2019/11/26(火) 16:25:08.09ID:H048FZbZ
>>683
実装と場合(データ)によるとしか言えない。
Unicode(UTF-16)非対応の古いアプリは、想定したコードページでしか
まともに動かない。それだけの話だよ。
2019/11/26(火) 16:25:51.97ID:H048FZbZ
あと、システムプロファイルとか意味不明。
何の話をしてるのかわからないレベル。
2019/11/26(火) 16:30:59.10ID:H048FZbZ
ちなみにUnicodeから非Unicodeへの変換は変換できない文字があるから一部文字化けするが、
非UnicodeからUnicodeへの変換では文字化けすることはない。

だから、cp932を扱えるアプリがcp932でレジストリ(UTF-16)に書き込んでも
適切に変換が行われるし、そのアプリがUTF-8を使えるなら、それもレジストリに書き込んでも壊れたりしない。

例えばアプリ(cp932)から レジストリ(UTF-16)に書き込んで、
レジストリ(UTF-16)を アプリ(UTF-8)から参照することは問題なくできるということ
2019/11/26(火) 16:32:48.14ID:9NQ9wJPH
>>685
非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
そこにUTF-8とかねじ込まれても困るわ
2019/11/26(火) 16:32:49.98ID:H048FZbZ
もちろんレジストリ(UTF-16)をアプリ(cp932)で参照したときは扱えない文字列があるが、
それはファイル名(UTF-16)をアプリ(cp932)で扱えない文字があるという程度の話でしか無い。
2019/11/26(火) 16:35:04.40ID:ogXaluX+
マルチバイト文字を含むファイルパスが鬼門でしょ。
2019/11/26(火) 16:38:45.15ID:H048FZbZ
>>688
お前は意味がわかるように書き込め

> 非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
どういう使い分けがされてるのか書け

> オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
それって引数がWCHAR *ならW系が使われて、引数がCHAR *ならA系が使われるってだけだろ

> そこにUTF-8とかねじ込まれても困るわ
そこにってどこよ?何が困るんだよ。
UTF-8はCHAR*を使うって理解してるか?
今までA系はASCIIだけでなくSJISや多数の文字コードで使われていたというのに
UTF-8が増えたごときで何も困らんだろ
2019/11/26(火) 16:41:18.53ID:H048FZbZ
>>690
鬼門っていうか、単にUnicode非対応のアプリは
想定しているコードページに変換できない文字を扱えないってだけだけどな
たったこれだけのことなのに何をグダグダ言ってるのかわからん
2019/11/26(火) 16:56:51.07ID:ogXaluX+
バッチファイルは厄介。あればだが。
2019/11/26(火) 16:59:13.07ID:JyI6kWkc
>>684
UTF8アプリなんて存在するんだっけ?
2019/11/26(火) 17:02:23.79ID:9NQ9wJPH
>>691
たとえUnicodeに対応しているプログラムであっても何らかの出力ファイルをSJISで出力するような構造だと、
それを勝手にUTF-8に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな
2019/11/26(火) 17:12:43.83ID:H048FZbZ
>>694
まずないだろうね。作れるようになったのは最近だし。
念ために言っておくけど、ないっていうのは
Unicode対応アプリではない(=A系APIを使う)かつASCII文字としてUTF-8を使うアプリのことね。

UTF-8はUnicodeだろというツッコミはいらん。
WindowsにおいてUnicode対応とはUTF-16アプリのこと

最近Unicode非対応の古いアプリでもUTF-8が使えるようになったから、
古いアプリをUTF-8用として作り直して新しくすることでA系のまま
Unicode対応にできるとかいうジョークのような話w

それするぐらいなら最初からUnicode対応として.NETとかで作りますわ。
完全に将来のLinuxアプリなどの移植用。多分最終的にマニフェストとかで
このアプリはUTF-8アプリですって指定できるようになるんじゃない?
2019/11/26(火) 17:13:45.02ID:H048FZbZ
>>695
だからなんなんだよ?
当たり前の話するな。OSともアプリとも関係ない話だわ
LinuxでもMacでも同じことは起きるわ。だからなんだんだよ
2019/11/26(火) 17:14:18.74ID:H048FZbZ
結論を書け結論を。お前がいいたいこが何かを書け。
2019/11/26(火) 17:16:25.46ID:9NQ9wJPH
>>698
勝手に文字コードを変えんなってだけやろ
利用者の意思で変えさせろと
2019/11/26(火) 17:44:52.60ID:H048FZbZ
>>698
勝手に変えてない。お前は馬鹿なのか?
2019/11/26(火) 17:48:56.90ID:FXTOqUMb
クッソ伸びてて草

MBSCなソフトがA系APIでデータ読み書きしてたら非対応のUTF8に書き換わってて、
以降データが文字化けしたまま困ることになるんだから、元に戻せばOKとか非対応なんだから
仕方ないとか、こればかりは擁護不可能の的外れ
表示だけの問題じゃなく記録データにも影響があって、こいつばかりは復元ソフトでも組まないと戻せない

MBSCなソフトは使えないだけならば、単純にA系APIを廃止すればいいだけなんだが
MSはお節介にもどうにかして過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
用意したって点だけ見ても、単純に非対応とか元に戻せばいいというような話ではない

年末にお父ちゃんから、古い宛名印刷ソフトのデータが壊れたって連絡が来るかも知れないくらいには、
時と場合によっては取り返しが付かない

今のところデフォでこの切り替えは無効だが、将来もしかしたら〜というのが現時点でのキモだろう
2019/11/26(火) 17:59:10.05ID:4DbW4sNm
>>701
そんな長々と書かなくても、
SJISのファイルにUTF-8で書き込んだら文字化けしたのと同じことでしょ
そんなのLinuxでもmacOSでも起きる問題だって言ってるんだが
2019/11/26(火) 18:00:34.44ID:4DbW4sNm
>>701
> 過去資産を活かしてやろうってことでA系の挙動を変える選択肢を

意味不。単にUTF-8にも対応したってだけ
コードページを一つ増やしたに過ぎない。
A系の挙動は昔から設定で変更できた。
2019/11/26(火) 18:02:42.72ID:4DbW4sNm
もしかしてこいつは、ユーザーが設定変更しなくても
アップデートで勝手にUTF-8に変わるとか思ってるのか?
ならものすごくマヌケだw
2019/11/26(火) 18:12:52.84ID:FXTOqUMb
あー、アホが一人混じってるから伸びてるのか
把握
2019/11/26(火) 18:18:38.91ID:4DbW4sNm
今度はレスしなかったところを見ると図星だったか
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況