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/08(金) 12:17:45.01ID:2aYByRbi
>>594
ちょと見せてみて？
2019/11/08(金) 13:27:31.55ID:D1bzmSlR
あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ
2019/11/08(金) 13:56:39.50ID:1R79qYgq
ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ
2019/11/08(金) 21:00:43.55ID:lpVjWTGo
TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう
https://social.msdn.microsoft.com/Forums/ja-JP/17563f89-9838-4beb-925f-32f47d90c994/topmost
2019/11/08(金) 21:14:49.46ID:sQQR9KNr
TOPMOST同士があるからな
2019/11/09(土) 13:55:21.92ID:hHKZwsDl
タスクマネージャもよく後ろに移動する時あるけど何なのあれ
601デフォルトの名無しさん
垢版 |
2019/11/09(土) 14:13:06.87ID:BZG37V3w
API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる
2019/11/09(土) 15:42:27.57ID:01iIJK4d
タスクバーより手前にくる時もある

別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある
2019/11/09(土) 17:34:31.94ID:GyhiHYRD
もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？
毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね
それなら諦めてGetPixel使いますが
2019/11/09(土) 17:44:43.05ID:HanEs9+F
アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね
Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど
2019/11/09(土) 17:56:17.05ID:HyuDdIlK
TOPMOSTなんて思い上がった言葉ですぐ気がつけよ
スレッドの優先度でさえ最優先ではなくタイムクリティカルだろうが
2019/11/09(土) 18:03:02.50ID:GyhiHYRD
>>604
こりゃ失礼、ありがとうございます
なんか昔いじった気がしたんですが、あれはオフスクリーンバッファだったか……
PC98じゃあるまいし、言われて見りゃ無理くさいすね

画面上の変化を監視して作業自動化する様なのを頼まれたのですが、
監視するべきは数ピクセルなので、おとなしくGetDC(nullptr)からGetPixelします
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切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
2019/11/10(日) 15:51:41.38ID:u8+xJCBj
同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
2019/11/10(日) 16:09:15.77ID:GjrjejsC
もう滅茶苦茶だなｗ

そりゃ同じことをするなら一般的には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に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。