19/10/02 11:02:31.08 I2VMZsV4.net
sizeofに括弧つけるかどうかなんて
正直どうでも良くね？
443:デフォルトの名無しさん
19/10/02 11:33:56.30 Jzurp0++.net
構造体にサイズ入れることが一番多いからあんまつけないな
444:デフォルトの名無しさん
19/10/02 13:04:47.75 55+aQRnY.net
64bit化してからHOGE_PTRが増えてさらに混乱
445:デフォルトの名無しさん
19/10/07 18:52:52.31 gF1mLPnp.net
sizeof付けるの嫌ならラッパー作ってそっちで呼び出せよ
win32APIの仕様がそーなるんだからしかたねーじゃん。手続き通りに記述するしかない。
446:デフォルトの名無しさん
19/10/07 20:15:04.08 WFXsDvHg.net
perlでWin32APIを使うライブラリWin32::APIを使ってると、
32bitと64bitで異なる構造体のアラインメントを正しく解釈してくれないので、アセンブラ並みに低レベルな記述が必要になることがある。
447:デフォルトの名無しさん
19/10/07 21:01:12.36 Byy1mx9U.net
cからperl呼ぶのも腐ってるな
448:デフォルトの名無しさん
19/10/07 22:23:56.51 WFXsDvHg.net
>>440
世の中には発酵食品が沢山ある。
発酵 腐敗 熟成 の違いを見極めるのは難しい。
449:
19/10/09 21:21:44.79 ggd9iNPq.net
質問です。
SetFilePointer()
URLﾘﾝｸ(docs.microsoft.com)
を FILE_END で使ったことのある方はおられますか？
第3引数 PLONG lpDistanceToMoveHigh を 0 （そして第 2 引数 LONG lDistanceToMove も 0 ）で使うと、FILE_END であっても当のファイルが 4GB 以上の場合にはポインタがファイルの最後に設定されない現象があるようです
この場合ダミー変数（毎回 0 を投入している）を設けて lpDistanceToMoveHigh にそのアドレスを設定すると FILE_END がその本来の意味を示すようにみえます。
推量形で記述しているのは、私の環境（mingw64-gcc）ではコンパイラのオプティマイザが過剰に効いている可能性があり -O0 でコンパイルしてはじめて、ある程度この現象が確認できたという事情のためです。
これは一般的な話なのでしょうか？
450:
19/10/09 21:24:08.20 ggd9iNPq.net
>>442
ソースを晒します
URLﾘﾝｸ(ideone.com)
451:デフォルトの名無しさん
19/10/09 21:49:31.92 75Pp/Qaq.net
longの場所になぜintを使う
452:
19/10/09 22:06:12.13 ggd9iNPq.net
>>444
printf("sizeof(int):%d, sizeof(LONG):%d\n", sizeof(int), sizeof(LONG));
$ ./a.exe
sizeof(int):4, sizeof(LONG):4
453:デフォルトの名無しさん
19/10/09 22:12:20.45 wmrCsqX1.net
lpDistanceToMoveHighがNULLの時のFILE_ENDは単純にファイルサイズも下位32bitだけ見て処理してそう
でかいファイル扱うなら素直にSetFilePointerEx使った方がよさげ
454:
19/10/09 22:39:59.07 ggd9iNPq.net
>>44
455:6 *Ex には気がつきませんでした 昔書いたものをみると s1 = GetFileSize(f, &s2); SetFilePointer(f, s1, (PLONG)&s2, FILE_BEGIN); WriteFile(f, p, strlen(p), &n, 0); ってやっていましたから、どうも、昔も同じところで嵌ったらしく、お茶を濁す方法まで昔と同じのまま、しかもその記憶が今はない… もうなにもかも忘れてしまった… コメントありがとうございました
456:デフォルトの名無しさん
19/10/15 14:52:27.44 iJLx9DXs.net
書き込むなよクソコテの分際で
457:
19/10/15 19:34:41 6pml1OhP.net
みんなクソだと思ってたけど
458:デフォルトの名無しさん
19/10/15 20:02:45.72 M5SL5EtX.net
そうなんだ
病気だね
459:デフォルトの名無しさん
19/10/15 20:59:08.69 H14rNUWV.net
こんな場所でこんなクソ書き込みしてるくせに自身のクソさ加減に気付かないなんて病気だぞ☆
460:デフォルトの名無しさん
19/10/15 22:41:36.61 72mqelru.net
そうなんだ
病気だね
461:
19/10/17 09:57:15 z4eLhP/Z.net
PCが複数のネットワークにつながっています。
IUPnPDeviceFinderで検索するネットワークを指定するのはどうしたらいいのでしょう？
462:デフォルトの名無しさん
19/10/21 22:12:09 EXgPOVjA.net
CSPのハンドルであるHCRYPTPROVなんだけど、
これってスレッドセーフ？
具体的には、同じハンドル使って別スレッドで同時にCryptGenRandom()呼んでも大丈夫なものなの？
Goのcrypt/randが排他せずに同じハンドルで呼んでいて気になったんで
463:デフォルトの名無しさん
19/10/21 23:03:30.44 xGMxn7s7.net
7から10にしたらこんな感じで画面外の領域が描画されなくなってしまいました URLﾘﾝｸ(i.imgur.com)
Windows10で画面外の領域を描画させるような関数か方法はありますか？
InvalidateRect、UpdateWindow、RedrawWindow、PrintWindow、DwmGetDxSharedSurfaceは試しましたが無理そうです
ソースです URLﾘﾝｸ(dotup.org)
464:蟻人間 ◆T6xkBnTXz7B0
19/10/21 23:12:02 LVq8IpRv.net
>>455
CreateDC("DISPLAY", ...)
CAPTUREBLT
465:デフォルトの名無しさん
19/10/22 00:53:22 VVF85bpK.net
>>456
CreateDCではディスプレイに表示されてる領域のデバイスコンテキストしか取得できませんでした
ウィンドウの外ではなく、ディスプレイの外に出ている領域を取得したいのです
CAPTUREBLTは単体だと真っ黒、SRCCOPYと一緒に指定してもSRCCOPY単体と変化はありませんでした
466:デフォルトの名無しさん
19/10/22 01:13:45.23 tgq7+oc3.net
455に貼ってるスクショでは単に5chのページが途中までしか描画されないように
見えるだけで、"画面外の領域"の意味がよく分からんが・・・・
それはともかく、実は管理者権限で実行するといけちゃうとか？
467:デフォルトの名無しさん
19/10/22 02:01:10.02 VVF85bpK.net
>>458
別アプリ（画像ではブラウザ）をSetWindowPosでウィンドウの一部がディスプレイの外に出る位置に移動して
そのウィンドウの内容をBitBltで取得して自分のウィンドウに表示してるんですが
ディスプレイに表示されてないディスプレイの外に出た部分が真っ白になってしまいます
すいません、説明下手なのでソースを見てもらえると助かります
468:デフォルトの名無しさん
19/10/22 02:29:09.84 rKj5dIYC.net
まともに説明もできないソースだとそもそも何したいのかわからないほどのバグな気がする
469:デフォルトの名無しさん
19/10/22 02:57:41.77 tgq7+oc3.net
対象となるアプリのスクショを取るようなアプリでOK?
面倒なので
470:試さないけど、単に画面外に描画しても無駄なので描画してない だけのような気がするが、その理屈なら画面外ではなくその上に別ウィンドウを 表示させるとどうなるんだろうなってことと、対象アプリがブラウザ以外だと どうなるんだろうなってことなど突き詰めたい項目が（面倒くさくなり以下略
471:デフォルトの名無しさん
19/10/22 09:19:42.21 cLGxu2gX.net
Windows7でaero有効なら画面に見えていないウィンドウからbitbltできるが、10でaero廃止されたのが
関係しているのかな。
10でもタスクバーのウィンドウプレビューは表示されるから7と同じようにできてもいいとは思うが。
472:デフォルトの名無しさん
19/10/22 09:22:47.36 swuil85R.net
10でも取れるぞ。これは確実
ソース見てないから原因はしらね
473:デフォルトの名無しさん
19/10/22 12:27:17.50 VVF85bpK.net
>>461
OKです
デスクトップのデバイスコンテキストから転送すると上にある別ウィンドウの画像込みになりますが
対象アプリのデバイスコンテキストから転送すると対象アプリの画像だけを取得できます
対象はブラウザ以外でも描画されない部分が白か黒かの違いだけです URLﾘﾝｸ(i.imgur.com)
>>462
プレビューでも描画されないです URLﾘﾝｸ(imgur.com)
474:デフォルトの名無しさん
19/10/22 13:41:14.15 fxbuxtP/.net
画面コピー貼る前にソース貼れ
475:
19/10/22 13:44:24.15 afWm6mlf.net
>>464
早く解決したいのだったらソースを貼らないと
476:デフォルトの名無しさん
19/10/22 13:47:22.65 PRXTlxOV.net
そのコードだとキャプチャできないのは確認したけどプレビューまではそんな風にならんな
なんとなくOS自体の省力設定に連動して
OSがクリップしてる or アプリ自身のクリップを引き起こしてる臭いけど
新しめのキャプチャAPIだと↓
URLﾘﾝｸ(docs.microsoft.com)
477:デフォルトの名無しさん
19/10/22 13:55:50.74 PRXTlxOV.net
補足、そっからじゃC++のデスクトップアプリからの使い方がわかんねえな
URLﾘﾝｸ(github.com)
478:デフォルトの名無しさん
19/10/22 14:05:08.56 VVF85bpK.net
>>465
>>466
>>455 で張ってますが落とせないとかありますか？
別のろだで用意したほうがいいですか？
>>467
うちだと実機でも仮想PCでもプレビュー欠けてるんですよね
仮想PCに新規でWin10入れて確かめてみます
C++のソースありがたいです。試してきます
479:デフォルトの名無しさん
19/10/22 14:09:15.53 fxbuxtP/.net
一度memdcにコピーする手間があったような
480:デフォルトの名無しさん
19/10/22 14:32:05.02 cLGxu2gX.net
俺も>>455と同じようなキャプチャソフトを自作してたんで今win10で試してみたが
ウィンドウが画面外にはみ出しているからといってキャプチャできないことはないな。
プレビューが欠けるということもなかったが。
>>464
プレビューが欠けるのが特定のアプリだけならそのアプリの問題だろうから
あきらめるしかないだろうねえ。
どのアプリでも欠けるとしたらwindowsの設定かGPUの問題かなにかかな。
481:デフォルトの名無しさん
19/10/22 15:53:33.65 VVF85bpK.net
クリーンインストールWin10でも症状変わらず
ScreenCaptureforHWNDも変わりませんでした
>>471
画面内で表示してから画面外に移動してキャプチャしてませんか？
キャプチャはできても更新がされない感じなので
移動してから内容更新するとキャプチャ画像とプレビューがこうなります URLﾘﾝｸ(imgur.com)
482:デフォルトの名無しさん
19/10/22 16:05:23.75 cLGxu2gX.net
それをedgeとかでやっても同じなん？
動画を表示していもプレビューは随時更新されるが、ふつう。
483:デフォルトの名無しさん
19/10/22 16:09:29.85 tgq7+oc3.net
他のキャプチャソフトではどうなるの？っと
484:デフォルトの名無しさん
19/10/22 17:18:39.23 An+rmEaC.net
コンパイラ設定が
485:xp互換だと撮れないってのもあるな
486:49
19/10/22 17:33:47.67 8AVeU+tz.net
そもそも何がしたいのか分からない。
487:デフォルトの名無しさん
19/10/22 18:06:58.79 PRXTlxOV.net
こっちで試してる限りでもいまいち挙動に一貫性がなくて確証は無いんだが
そのWaterfoxってのだけ更新時に画面外のレンダリングを省いてるのはプレビューで確認できたんで
検証するのにそれは外した方がいいな
画面外に出たアプリのWM_PAINTでrcPaintが差分を返すのは正常な挙動なので
アプリ自体の画面更新と内容の取得のタイミングによってはプレビューがそうなる理屈は説明できる
キャプチャに用いているBitBltとも内容が異なるのはGDIとDWMでは見てるバッファが違うのかもしれない
ただ全部のアプリがそうなるとなるとこっちじゃ現象自体が確認できないのでなんとも
488:455
19/10/22 21:17:47.98 VVF85bpK.net
>>473
>>477
Firefox、Waterfox、Chrome、VisualStudio2019、MPCBE、ペイント、メモ帳
画面外に出た部分はプレビュー更新されないし、BitBltも更新されてない画像しか取れない
Edge、フォト
画面外に出た部分もプレビュー更新される、BitBltでは画面内でも画像が取れない
IE
画面外に出た部分もプレビュー更新される、BitBltでは画像が取れたり取れなかったり不安定
動画です URLﾘﾝｸ(dotup.org)
>>474
Loiloだと画面外は真っ黒でした。他は名前言ってもらえれば試します
>>475
x64でプラットフォームツールセットはVisual Studio 2019(v142)なのでXP互換ではないと思います
>>476
ウィンドウの一部が画面外に出ても、ウィンドウがすべて画面内にあるのと同じようにキャプチャしたいです
489:デフォルトの名無しさん
19/10/22 21:59:23.80 JI3aTgMm.net
ディスプレイ外にはみ出した窓があってそのはみ出したリージョン内で表示更新かかってて
そいつを ALT+PrtScr でキャプチャしてもうまく取れてないなら厳しいんでないかな
490:デフォルトの名無しさん
19/10/22 22:11:54.49 An+rmEaC.net
俺自作のソフトはキャプチャできるが、ALT+PrtScrはキャプチャできん＠win10
491:デフォルトの名無しさん
19/10/22 22:35:32.44 YGRhwcPr.net
グラボに依存とか？
492:デフォルトの名無しさん
19/10/22 22:54:01.75 cLGxu2gX.net
>>478
なるほど、ペイントで現象確認した。
GPUリソースを食わないよう改善した結果とかかねえ。
493:デフォルトの名無しさん
19/10/22 22:56:43.07 HSQTG8Jj.net
どうなんだろう。BitBlt(,,,SRCCOPY | CAPTUREBLT) しか方法ないのかね。
494:デフォルトの名無しさん
19/10/22 23:00:04.93 GE3t6WX1.net
2段階のアクセラレータはどのようにやるのがいいの？
Visual Studio のCtrl+K Bみたいな・・・
495:蟻人間
19/10/22 23:03:39.56 QN5InCe0.net
>>484
アクセスキーテーブル切り替えか、
状態遷移だろうよ。
496:デフォルトの名無しさん
19/10/22 23:10:21.12 PRXTlxOV.net
なんかだんだんワケがわからなくなってきたが再度確認したら
基本的にUWPアプリ以外は画面外の再描画しないっぽいな（Chromium系はやっぱり描画されてるけど）
ほとんどのアプリが律義にrcPaint見てるとも思えんし描画先がGDIだと強制的にOSでクリップされてんのかしら？
おそらくWindows Compositionが噛んでてBitBltで取れないUWPアプリはWindows.Graphics.Captureで取れるけど
UWPアプリ以外でクリップ済みのイメージしか取れないのはまあ当然っちゃ当然
497:デフォルトの名無しさん
19/10/22 23:28:56.03 An+rmEaC.net
win10でUWPでない従来のアプリの画面外キャプチャできるよ
win7がaeroオフだと撮れなかったみたいに何らかの条件があるのかもしれないが
498:デフォルトの名無しさん
19/10/23 00:49:00.28 /s0IRa9G.net
Mozilla Firefoxなどサードパーティ大手は今もWin32APIをネイティブに使っており.NETは使ってない。
499:デフォルトの名無しさん
19/10/23 01:17:59.09 VREi5cKF.net
エクスプローラのアドレスバーで「デスクトップ」とか「ダウンロード」って入れたら
そこのパスに移動しますが、「デスクトップ」（という日本語）からパスに変換するAPIはありますか？
500:蟻人間
19/10/23 01:29:37.00 DFr4VJRt.net
>>489
SHGetLocalizedNameの逆写像っぽい。CSIDLからテーブルを作るのが楽かと。
501:デフォルトの名無しさん
19/10/23 01:33:15.99 VREi5cKF.net
あれ？なんか上の方に同じような質問がｗ
502:デフォルトの名無しさん
19/10/23 01:52:47.01 VREi5cKF.net
なんかめちゃくちゃめんどくさそうｗ
503:デフォルトの名無しさん
19/10/23 02:38:41.47 /s0IRa9G.net
SHGetFolderPath() でCSIDLコンプリートをめざすとか
504:蟻人間
19/10/23 03:33:00.02 bxABcYeD.net
URLﾘﾝｸ(github.com)
作ったぞ。自由に使え。
505:デフォルトの名無しさん
19/10/23 04:05:49 /s0IRa9G.net
>>494
早いですね。
とはいえ、実在するパスからの逆引きだと、「コントロール パネル」とか「プリンター」みたいな仮想フォルダ名は取れない。
506:蟻人間
19/10/23 04:20:43.92 DFr4VJRt.net
仮想フォルダならPIDLを使うのではないか？
507:蟻人間
19/10/23 04:23:26.39 DFr4VJRt.net
PIDLとGUIDをどうやれば結び付けられるか？ え～と
508:蟻人間 ◆T6xkBnTXz7B0
19/10/23 04:25:53 DFr4VJRt.net
URLﾘﾝｸ(stackoverflow.com)
ここにヒントが。
509:蟻人間
19/10/23 04:32:28.94 DFr4VJRt.net
落ちます。
510:蟻人間 ◆T6xkBnTXz7B0
19/10/23 04:40:22 DFr4VJRt.net
仮想フォルダならレジストリを見る方法があるが、KnownFolderの方が正しい方法に思える。
511:デフォルトの名無しさん
19/10/23 04:47:44 /s0IRa9G.net
WTL公式gitレポジトリにあるエクスプローラもどきアプリのサンプルが参考になるかも。
URLﾘﾝｸ(sourceforge.net)
512:デフォルトの名無しさん
19/10/23 12:55:03.32 hZZQZDty.net
画面外のスクショが取れない件、1809からの挙動のようだねえ
URLﾘﾝｸ(stackoverflow.com)
513:デフォルトの名無しさん
19/10/23 12:59:02.01 ou8vQa3g.net
>>502
日本語で
514:デフォルトの名無しさん
19/10/23 15:31:41.90 J1BMEu9t.net
いや判るだろ
1809 update 入れた後に可笑しくなったんだろω
515:455
19/10/23 21:03:31.35 i0lmBL5A.net
1809以降の挙動ならプログラムじゃなくてWindows側の問題みたいですね
BitBltだけじゃなくプレビューにも問題出てるからバグっぽいですし
そのうちアップデートで治ることを期待しつつプログラムでの対応は諦めます
いろいろ答えてくれた皆様ありがとうございました
516:蟻人間
19/10/23 22:21:30.01 bxABcYeD.net
やっぱりKnownFolderから取得できた。
URLﾘﾝｸ(github.com)
自由に使え。
517:蟻人間
19/10/23 23:01:48.53 bxABcYeD.net
揚げ物
518:デフォルトの名無しさん
19/10/24 00:20:06.38 ywNA7G1O.net
ありがとう。だがしかし別のアプローチで
俺が解決したい（本当の）問題は解決できていたのだよ
まあ誰かの役に立つだろうから放っておいたけどな
すまんなｗww
519:デフォルトの名無しさん
19/10/24 00:41:12.27 Fw8n9fLr.net
アップデートで直るかっちゅーても挙動自体は描画の最適化とも言えるので仕様としてこのままいきそうだけどなあ
自作ので試してみたけどやはり一部でも画面外に出てると無効領域をクライアント全体と指定しても
強制的にクリップされたHDCが返ってくるね
BeginPaintだけじゃなくてWM_PAINT外でのGetDCでも同様
DXGI swap chainが出力先ならクリップされない
普段窓を画面外に追い出したままにするってことがないから気付かなかったなコレ
520:デフォルトの名無しさん
19/11/04 15:23:29.75 /C5zJSxn.net
SetForegroundWindowでフォーカスを奪えない、
入力中にフォーカスが奪われるとウザいからWindowsが
奪えないようにしてるって話はよく聞くと思うけど
逆にエクスプローラが起動すると（バックグラウンドなのに）
フォーカスを奪ってくれて困ってるんだけど対応策ない？
ウザいんだがｗ
521:
19/11/04 15:58:26.30 fwURXfb5.net
>>447
さらに追試を重ねていました
悪いときは 10G, うまくいっても 5000G 程度（日によってばらばらです）で
FILE_END ができなくなる現象は、
FILE_END が悪いのではなく、システムで圧縮するように指定するとそういうことがおきることがわかってきました。
Windows もいろいろとあてにならない、もう linux に軸足を移そうか、と思案しています
522:デフォルトの名無しさん
19/11/04 16:19:56.83 1IiqNDSP.net
>>510
SetFocus()を使うと好きなコントロールにフォーカスを与えることが出来る。
SetForegroundWindow()は余り効果が無い。
523:デフォルトの名無しさん
19/11/04 16:52:05.66 KwYoxUXo.net
longポインタ引数にintポインタ渡して>>445みたいなトンチンカンな返答する人が何か言ってる
524:
19/11/04 18:29:13.81 fwURXfb5.net
>>513
>>445 を日本語に翻訳してみました。
URLﾘﾝｸ(docs.microsoft.com)
では api 関数の第二引数は 「LONG」で定義されています。
ここで注意しないといけないのは「long」ではなくて「LONG」。
すなわち LONG は win32api.h で定義されている型です。これが実際の環境ではどう typedef されているかは環境依存です。
それを調べるために >>445 で実際に sizeof(LONG) の値を出力させると sizeof(LONG) = 4
私は >>443 で第二引数に int (そして渡す値は 0) を使っていますが sizeof(int) = 4
値は 0 だから signed/unsigned については問題ない
そして sizeof(int) = sizeof(LONG) だからなおさら問題ないのです。
昔は DWORD (Double WORD) と定義されていましたが、1 word = 2 bytes, 2 words = 4 bytes
32bit 環境での普通の int のサイズは 4 なので昔から int を当てて問題なかったのですよ
結論：>>513 >>444 はニワカ、win32api スレに投稿する前に 10 年 ROM ってください
525:デフォルトの名無しさん
19/11/04 18:55:51.87 KwYoxUXo.net
>>514
445のどこがWindows環境？
526:デフォルトの名無しさん
19/11/04 19:29:40.39 ex697rOI.net
DOS窓でprintf出力しながらWin32APIだって使えるからWin環境
527:デフォルトの名無しさん
19/11/04 20:03:10.14 xxqq9QlV.net
LONGは、WPARAMやLPARAMと型変換する危険コードが多い気が。もちろん古いコードだけど。
528:
19/11/04 20:32:15.68 fwURXfb5.net
>>515
だから、あなたは 10 年 ROM ってなさい、ってさっき言ったでしょう？
529:デフォルトの名無しさん
19/11/04 23:46:10.01 hiiCgg8I.net
ここはWin32スレなんだからWin64や総称であるWindows APIはスレ違い
32ビットの話だけしてろ
530:
19/11/05 00:15:09.88 SbnLKNM3.net
>>519
残念ながらその意見に賛同する人は少数派だと思いますよ
531:デフォルトの名無しさん
19/11/05 01:54:03.16 RTdVMJgD.net
Win64APIなんてどっから出てきたの？
532:デフォルトの名無しさん
19/11/05 11:28:00.41 f5fZl2jz.net
> 昔は DWORD (Double WORD) と定義されていましたが
LPARAMは 16bit,32bit共に LONG (符号付整数)
533:デフォルトの名無しさん
19/11/05 11:48:37.07 McETm4vA.net
>>519
64bitプログラミングであっても使用するAPIは実体としてはWin32APIだぞ
Win64APIなんて実体はなく、論理的に実装区分として呼び分ける程度
つまりスレチでも何でもない
534:デフォルトの名無しさん
19/11/05 19:37:14.92 wVD+ILW8.net
double wordが32bitだなんて本来word幅が16bitという前提の話でインテルなら80286までのはずが386でパスされathlon64で再びパスされるという異常事態が今も続いているわけなんだが
535:デフォルトの名無しさん
19/11/05 20:20:06.81 Rmlz0hln.net
>>524
16bit CPUや32bit CPUという言葉と
ポインタ = アドレス幅が違うことは普通にあるってわかってる？
8086は16bit CPUでレジスタ幅は16bitだがアドレス幅は20bit（最大1MB）
80286も16bit CPUだがアドレス幅は24bit（最大16MB）
80386は32bit CPUでレジスタ幅、アドレス幅ともに32bitで
分かりやすい時代がPentiumの第一世代（1995年ぐらい）ぐらいまで続いたが
Pentium Proからは物理アドレス拡張が搭載され32bit CPUだが
アドレスバスは36bit（最大64GB）になったんだが
536:デフォルトの名無しさん
19/11/05 20:52:13.30 mHpC8FDb.net
>>525
釈迦に説法ご苦労
537:デフォルトの名無しさん
19/11/05 21:08:53.99 Rmlz0hln.net
釈迦は俺やしｗ
538:デフォルトの名無しさん
19/11/05 21:43:32.83 mHpC8FDb.net
俺メインフレームでdiagnose命令とかいじくってて
別な案件でhdlでcpu書いたりしてるけど
539:デフォルトの名無しさん
19/11/06 01:32:27 k1IDaN6Q.net
メインフレームw
何歳になってもイキリ小僧してるんだな
サルのパパとママはご存命かい？
540:デフォルトの名無しさん
19/11/06 02:20:55.89 71FJFoA8.net
>>529
何イキっとんねん
541:デフォルトの名無しさん
19/11/06 04:07:48 Z1mcKm+J.net
イキなりえなり
542:デフォルトの名無しさん
19/11/06 07:21:07 cnDla3Ge.net
>>525
ソフト的なAPIの話に物理アドレス空間で語るバカ乙w
543:デフォルトの名無しさん
19/11/06 12:01:28.81 o3tEvZiY.net
釈迦がどうかはともかく
>>525 が全くトンチンカンなレスであることは事実
いつものあいつだろ
544:デフォルトの名無しさん
19/11/06 15:05:39.69 Z1mcKm+J.net
>>532
APIの話だというのなら、OSが16bitだろうが32bitだろうが
APIの仕様が代わるわけないんやで
異常事態でもなんでもなく、それが高い互換性の理由だ
545:蟻人間
19/11/06 15:13:44.92 Z1hQUtYe.net
64ビット対応で
Get/SetWindowLongよりもGet/SetWindowLongPtrを使え。とか、
DialogProcの戻り値をINT_PTRにしろ。
とかの若干の変更点があるようだ。
546:デフォルトの名無しさん
19/11/06 15:19:20.45 o3tEvZiY.net
HANDLEもこっそりtypedefに_PTR変えたんだっけ
547:デフォルトの名無しさん
19/11/07 01:18:36.16 7K0XtVuo.net
ダイアログプロシージャの戻り値がめんどうなことになる
x86じゃBOOLだけどx64だとINT_PTR
でもVC6だとBOOLはintだという
548:デフォルトの名無しさん
19/11/07 01:32:58.79 sEmiRyTj.net
歴史的理由で仕方のない面もあるが、
単一のソースで16bitと32bit、32bitと64bitでコンパイルできるようにしてきたから
型の実態は結局なんなんだ？って悩むことになってる。
もうそろそろネイティブ型だけを使えるようになってほしいが
そのために言語を変えるほうが楽だろうな
549:デフォルトの名無しさん
19/11/07 01:44:34.42 ubAK6fog.net
intとlongのサイズ違うこともあるしな
c#みたいにint32みたいなの最初から用意しとけよ
550:デフォルトの名無しさん
19/11/07 01:48:09.03 cfOynPV2.net
stdint.h使おう
551:デフォルトの名無しさん
19/11/07 02:23:16 +N3PsKU8.net
前に聞いた話だと、大型機が64BIT化した後も、intは、32BITの事が多いらしい。
552:デフォルトの名無しさん
19/11/07 02:26:43 4jX7Qkw7.net
いいかげんな知識で語りたがるやつ多すぎ
553:デフォルトの名無しさん
19/11/07 02:27:07 +N3PsKU8.net
32BIT時代は、整数サイズとポインタサイズが一致していて、サイズの選び方に
悩むことが無く便利だった。果たして、整数型を全部64BITにして良いものか
どうか。原則的に速度は変わらないとしても使用メモリは増えてしまう。
恐らく、exeファイルのサイズも増加するだろう。
554:デフォルトの名無しさん
19/11/07 02:42:22 sEmiRyTj.net
コンピュータが遅かった時代はCPUに最適なデータ型を
使うことが重要だったが、今は数値型しかなくて
データサイズは自動的に決まりますとかばかりだもんな
555:デフォルトの名無しさん
19/11/07 02:44:07 +N3PsKU8.net
64BITポインタptrと配列添え字idxに対して、
ptr[idx]
と書いた場合、idxが32BITと64BITだと実は、32BITの方が
1クロック増えてしまう可能性が高い。なぜなら、マシン語レベルでは、
上記の演算で、ptrは64BIT整数として扱われ、ptr[idx]は、
*(ptr+idx)として処理される。ところが、64BIT+64BITの整数演算は
あるが、64BIT+32BITの整数演算は無い事が多い。なので、
idxが32BITだと、いったん、64BITにBIT幅を拡張する命令を1つ
挿入する必要がある。
だから、64BITポインタのアーキテクチャだと、idxも64BITにした方が
速度が上がる可能性が高い。
556:デフォルトの名無しさん
19/11/07 02:45:21 +N3PsKU8.net
>>544
>今は数値型しかなくてデータサイズは自動的に決まりますとかばかりだもんな
C++だと今でもデータサイズは明示します。
557:デフォルトの名無しさん
19/11/07 02:54:21.19 PsJP4fV8.net
size_t型が無難にして最強
558:デフォルトの名無しさん
19/11/07 03:00:35.26 sEmiRyTj.net
>>546
他の言語の話や。今は速度よりも利便性のほうが重要や
559:デフォルトの名無しさん
19/11/07 03:18:33 +N3PsKU8.net
>>548
例えば、JavaScriptだと、数値型のデータサイズが自動的に決められている
わけではなく、常に double 型(64BIT 浮動小数点型)なのですが、
整数は32BIT整数型までだと double型に精度を落とすことなく完全に
収まるので、何も考えずに正しく扱えるだけです。
JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
560:デフォルトの名無しさん
19/11/07 03:23:20 +N3PsKU8.net
>>549
また、JavaScriptは、シンプルな使い方では、原則、整数型がなく、
console.log(54 / 10);
とすると、5.4と表示されます。これは、54や10が整数ではなく、
54.0 や 10.0 という double 型浮動小数点として扱われているためです。
これは、Sun/Oracle の Java とは全く結果が異なります。後者では、
54/10は、「整数除算」なので、結果は整数の「5」となります。
561:デフォルトの名無しさん
19/11/07 03:38:26 sEmiRyTj.net
> JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
64bitも使うのかって話なんだけどな？ 52bitで十分だろう？
URLﾘﾝｸ(sbfl.net)
> JavaScriptのNumber（数値型）は倍精度浮動小数点数となります。
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。
562:デフォルトの名無しさん
19/11/07 03:39:52.10 sEmiRyTj.net
なんだ。JavaScriptにBigIntあるじゃん
Numberで表せる最大の整数値は十分な値にも思えますが、
分野によってはこれでも足りなくなることがあります。そこで導入されたのがBigIntです。
BigIntは、任意精度の整数を表す新しいプリミティブ型です。
任意精度の整数値については、基本的にCPUに搭載されている計算機は対応していないので、計算はソフトウェアによって行われます。
563:デフォルトの名無しさん
19/11/07 03:43:05 sEmiRyTj.net
やっぱりどんなときでもプログラマがデータ型を
選んでくださいっていうのは時代遅れだと思わ
564:デフォルトの名無しさん
19/11/07 03:53:54.05 +N3PsKU8.net
>>553
自動化することは可能ですが、現在の技術でそういうところまで自動化した
言語を使ってコンパイラ処理系を書くと、コンパイル速度が100倍遅くなる
かも知れません。これはコンパイル意を作成した経験に基づく話です。
もの凄く厳しい世界が実はまだ沢山残っています。
565:デフォルトの名無しさん
19/11/07 03:55:32.96 +N3PsKU8.net
>>554
誤：かも知れません。これはコンパイル意を作成した経験に基づく話です。
正：かも知れません。これはコンパイラを作成した経験に基づく話です。
566:デフォルトの名無しさん
19/11/07 03:58:19 sEmiRyTj.net
100倍遅くなるなら100倍高速なコンピュータを使えばいいだけ
567:デフォルトの名無しさん
19/11/07 03:58:57 sEmiRyTj.net
今より100倍遅かった時代もあるのに
何を言ってるんだろうか？
それこそ時代遅れの感覚
568:デフォルトの名無しさん
19/11/07 03:59:39 sEmiRyTj.net
あと、「かも知れません。」とかいう推測はどうでもいいから
コンパイラを作り上げた俺が言うのだから
説得力は高いだろうし
569:デフォルトの名無しさん
19/11/07 04:00:34.74 +N3PsKU8.net
>>555
GPGPUなどの世界でも、乗算速度がfloatとdoubleでは、4倍以上も違うような
例も多いのです。また、doubleをサポートして無いGPGPUの場合、doubleの乗算を
floatや整数型などにバラして処理するので数10倍かかります。
なので、慎重になる必要があります。
CPUの場合でもintとdoubleで速度がかなり違うことが多いです。
570:デフォルトの名無しさん
19/11/07 04:02:01.90 sEmiRyTj.net
あと極まれにスピードが重要な部分があるから
全部スピード重要視しろとかいうアホな感覚なｗ
あれはやめてほしい。
極稀に重要なら、極稀に使うものを作ればいいだけ
よく使うものを短くする。（仕事の）圧縮の鉄則
571:デフォルトの名無しさん
19/11/07 04:02:17.73 +N3PsKU8.net
>>558
あなたより私の方が良いコンパイラを作っている可能性も有りますよね。
572:デフォルトの名無しさん
19/11/07 04:05:54.80 +N3PsKU8.net
>>560
自動化の道は検討の価値はあるでしょう。
しかし、int32型とint10000000型を自動的に取捨選択できるほど、
コンパイラが賢くなるのは恐らく遠い未来です。
どこかで機能制限や精度を人間が指示する必要があると考えられます。
573:デフォルトの名無しさん
19/11/07 04:07:52.13 sEmiRyTj.net
>>561
そういう俺のほうが優れてるとか言う主張をしたいなら、
個人を特定できるような情報をだせ
574:デフォルトの名無しさん
19/11/07 04:08:39 sEmiRyTj.net
>>562
コンパイラが無理なら実行時にメモリ拡張すればいいだけ
そういうことも思いつかないから、その程度止まりなんだよｗ
575:デフォルトの名無しさん
19/11/07 04:08:50 +N3PsKU8.net
>>563
それはお互い様です。
576:デフォルトの名無しさん
19/11/07 04:11:41.18 +N3PsKU8.net
>>564
それでは明らかに遅く、数値計算、コンパイラ、翻訳、AI、データ処理、
OSなどの作成には向いていない言語になるでしょう。
577:デフォルトの名無しさん
19/11/07 04:12:20.64 sEmiRyTj.net
大胆に変数はすべて128bitしかないという言語だって考えられる
最大 340282366920938463463374607431768211456 までしか扱えないが
578:デフォルトの名無しさん
19/11/07 04:13:03 sEmiRyTj.net
>>566
そんな言語が今はたくさんあり実用化されています。
579:デフォルトの名無しさん
19/11/07 04:17:30.53 +N3PsKU8.net
>>567
64BIT整数ですら効率を考えて使用を躊躇する世界に我々はまだいます。
あなたが普段使っているコンパイラも、非常に細かい高速化を施して
あるので快適に使えているだけで、PythonやJavaScript、Rubyなどの
動的言語では達成できません。
例えば、JavaScriptの遅さは、全てdouble型にして、変数は、全てheapメモリ
から確保することが主原因の一つです。それだけでC++の数十倍以上遅くなっています。
あなたの考えてことは、JavaScriptをさらに遅くするような結果となるでしょう。
580:デフォルトの名無しさん
19/11/07 04:18:51.44 +N3PsKU8.net
>>568
有りますが、C/C++、Java、PythonやJavaScript、Ruby、Java、Kotlinなどの
メジャー言語ではそのような方針はとっていません。
581:デフォルトの名無しさん
19/11/07 04:23:37 +N3PsKU8.net
>>564
「その程度どまり」と言いますけど、あなたは私の作品を全く見てませんね。
全く発表してませんから。
582:デフォルトの名無しさん
19/11/07 05:42:32.39 xrNXmkmc.net
スレ違いのバカ二人はどこかよそに行って気の済むまで殴り合ってきてくれ
583:デフォルトの名無しさん
19/11/07 06:22:21 D8b5RtWG.net
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。
ひどい説明だな
どのくらいひどいかというと
WM_SYSTEMMENU並み
584:デフォルトの名無しさん
19/11/07 11:03:05.72 JQdG/Jj/.net
公共の場で変数型のピロートークですか
585:デフォルトの名無しさん
19/11/07 11:05:56.88 dB1QBG
586:Xo.net
587:デフォルトの名無しさん
19/11/07 11:27:25.53 nSoHFrko.net
>>575
NULLは0だから～
site_tはどうせintだから～
こういう馬鹿なハケンが一人いると崩壊するよね
588:デフォルトの名無しさん
19/11/07 12:11:51.38 sEmiRyTj.net
とか言うやつほどnullptrのことを知らなそうｗ
589:デフォルトの名無しさん
19/11/07 12:17:00.95 9pMbL+ZJ.net
（´∀｀）＜ぬるぽ
590:デフォルトの名無しさん
19/11/07 17:55:20.14 7K0XtVuo.net
#ifdef _WIN64
#define BOOLX64 INT_PTR
#else
#define BOOLX64 BOOL
#endif
BOOLX64 CALLBACK Dlg(HWND hw, UINT msg, WPARAM wp, LPARAM lp)
こうやって回避してるわ
591:デフォルトの名無しさん
19/11/07 18:14:03.25 2gAeIIzZ.net
Windowsのデータ型だけのヘッダファイルって無いかしら？
データ型はあちこちで使わざるを得ないから、あちこちでincludeしたいけど、
APIのヘッダファイルはincludeしたくない。
APIを直接使うのは面倒だから、全部ラップしてるんだよね。
だから他からは使えないようにしたい。
592:デフォルトの名無しさん
19/11/07 19:03:13.60 +mjs9icr.net
データ型もラップしとけよ
593:デフォルトの名無しさん
19/11/07 19:07:36.74 2gAeIIzZ.net
>>581
どうやってラップすればいいですかね？
594:デフォルトの名無しさん
19/11/07 19:16:08.80 2gAeIIzZ.net
なんとなくわかったからいいやｗ
595:デフォルトの名無しさん
19/11/07 21:31:30.10 6aSe0RTj.net
横にそれるが
データ型もAPIの一部だと思ってるがあってるよな？
596:デフォルトの名無しさん
19/11/07 21:47:07.60 nSoHFrko.net
アプリケーション独自の型なんか知りませんがな
597:デフォルトの名無しさん
19/11/07 23:33:07.15 rEYaLqlI.net
個人的には構造化したほうがやりいいかな
598:デフォルトの名無しさん
19/11/08 03:59:17.05 ksOnEph7.net
お前らMFCでも使ってろ
599:デフォルトの名無しさん
19/11/08 04:54:11 2aYByRbi.net
普通のアプリならMFCが一番だと思うんだがなあ
変に角を丸くするとか透明にするとかされても使いにくいだけだろうに
600:デフォルトの名無しさん
19/11/08 05:57:08.22 bt2cbsd4.net
むしろMFC = 角を丸くするとか透明だろ
MFC以外でそんなの見たことないわｗ
601:デフォルトの名無しさん
19/11/08 07:30:44.18 D1bzmSlR.net
あんまりMFC関係なくね？
WS_EX_LAYEREDもSetWindowRgnもAPIを陽に意識して使うわけで
MFCはラッパーとしての薄さがありがたいだけやん
602:デフォルトの名無しさん
19/11/08 07:52:07.38 tDaXxZK7.net
MFCはかゆいところに手が届かないからな
廃れたWTLがいい
603:デフォルトの名無しさん
19/11/08 09:32:12.24 MipGbP9q.net
>>591
WTLは廃れてないよ。今もちゃくちゃくと最新コードがコミットされ続けている。現時点で2019年11月3日(日)が最終更新。
URLﾘﾝｸ(git.code.sf.net)
604:デフォルトの名無しさん
19/11/08 11:37:03.54 bt2cbsd4.net
廃れたかどうかは、使ってる人がいるかどうかであって
作っている人がいるかどうかではない
605:デフォルトの名無しさん
19/11/08 12:13:14.99 xtk88Sle.net
俺が使ってるから廃れてないぞ
606:デフォルトの名無しさん
19/11/08 12:17:45.01 2aYByRbi.net
>>594
ちょと見せてみて？
607:デフォルトの名無しさん
19/11/08 13:27:31.55 D1bzmSlR.net
あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ
608:デフォルトの名無しさん
19/11/08 13:56:39.50 1R79qYgq.net
ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ
609:デフォルトの名無しさん
19/11/08 21:00:43.55 lpVjWTGo.net
TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう
URLﾘﾝｸ(social.msdn.microsoft.com)
610:デフォルトの名無しさん
19/11/08 21:14:49.46 sQQR9KNr.net
TOPMOST同士があるからな
611:デフォルトの名無しさん
19/11/09 13:55:21.92 hHKZwsDl.net
タスクマネージャもよく後ろに移動する時あるけど何なのあれ
612:デフォルトの名無しさん
19/11/09 14:13:06.87 BZG37V3w.net
API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる
613:デフォルトの名無しさん
19/11/09 15:42:27.57 01iIJK4d.net
タスクバーより手前にくる時もある
別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある
614:デフォルトの名無しさん
19/11/09 17:34:31.94 GyhiHYRD.net
もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？
毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね
それなら諦めてGetPixel使いますが
615:デフォルトの名無しさん
19/11/09 17:44:43.05 HanEs9+F.net
アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね
Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど
616:デフォルトの名無しさん
19/11/09 17:56:17.05 HyuDdIlK.net
TOPMOSTなんて思い上がった言葉ですぐ気がつけよ
スレッドの優先度でさえ最優先ではなくタイムクリティカルだろうが
617:デフォルトの名無しさん
19/11/09 18:03:02.50 GyhiHYRD.net
>>604
こりゃ失礼、ありがとうございます
なんか昔いじった気がしたんですが、あれはオフスクリーンバッファだったか……
PC98じゃあるまいし、言われて見りゃ無理くさいすね
画面上の変化を監視して作業自動化する様なのを頼まれたのですが、
監視するべきは数ピクセルなので、おとなしくGetDC(nullptr)からGetPixelします
618:デフォルトの名無しさん
19/11/09 21:35:29.14 hHKZwsDl.net
GetPixelって内部でどうやってるのかな
毎回呼び出すと遅いんだよね
619:デフォルトの名無しさん
19/11/09 22:19:46.16 HyuDdIlK.net
故意に減速してるようだね
ビットマップオブジェクトにキャッシュしといて
そこから取ると普通の速度になる
620:デフォルトの名無しさん
19/11/09 22:41:44.97 e6n/6jzv.net
gnsk
621:デフォルトの名無しさん
19/11/09 23:25:01.42 HanEs9+F.net
仮にVRAMから1ピクセルだけ毎度読み戻してたらそらクソ重いやろとは思うが
今のDWMってGDI周りの扱いがどうなってんのかよくわかんねえからな
622:デフォルトの名無しさん
19/11/10 06:21:08.90 nWjdF62e.net
XPでは爆速だったのがVistaから突然遅くなった
623:デフォルトの名無しさん
19/11/10 09:02:24.14 R9o6dqtJ.net
TOPMOSTの競合の話ではない
"ごく稀に TOPMOST ウィンドウが通常のウィンドウの背面に移動してしまう現象が発生するとお問い合わせいただいています。"
"•Windows 8.1 以降、Windows 10 でも数十回に 1 回程度この現象が発生します。"
624:デフォルトの名無しさん
19/11/10 09:11:24.47 IRh+3wYd.net
>>611
メモリー積め
ってかPC買い替えろ
625:デフォルトの名無しさん
19/11/10 09:22:52.91 nWjdF62e.net
>>613
GetPixelの話だよ？
626:デフォルトの名無しさん
19/11/10 10:13:14.69 2HW6YGp5.net
それはAeroのせいかも知れない。
色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって
いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、
その場所に重なっている全ての Window の色が分からないと、画面に表示される
色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、
各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの
ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、
アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
再描画をさせるのが伝統的やり方。
このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、
例えたった1点の色であっても、非常に沢山のCPUパワーを必要としてしまう可能性が
ある。仮想VRAMにキャッシュしておけば高速化できる可能性は高いが。
627:デフォルトの名無しさん
19/11/10 10:14:06.88 2HW6YGp5.net
>>615
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、
628:デフォルトの名無しさん
19/11/10 10:48:16.19 IRh+3wYd.net
>>614
ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね
Windows 7から改良されたからマシになってるはず
629:デフォルトの名無しさん
19/11/10 11:26:39.91 GjrjejsC.net
aeroで半透明になるから描画に時間かかる←わかる
だからgetpixelに時間かかる←う～ん
呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
630:デフォルトの名無しさん
19/11/10 11:30:44.05 42Oft6n8.net
getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い
個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い
個別の描画内容は多分システムメモリ上にある
大体そんなような動作っぽい
getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな
631:デフォルトの名無しさん
19/11/10 12:37:49.81 R9o6dqtJ.net
> 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
1x1のビットマップに転送して取得しているのでxpでも遅かった
632:デフォルトの名無しさん
19/11/10 13:55:52.22 fP398yW4.net
>>615
> そのWindowにWM_PAINTメッセージを送って、
> アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
> 再描画をさせるのが伝統的やり方。
> このやり方に従っているなら
もうやってないというか「重なり」なんて概念がないよ。
動画再生して、他のウインドウの後ろに隠して、
その状態でタスクバーにマウス乗せてみ
画面に表示されてなくても、ウインドウの中身は更新されてるからさ。
最小化したときはアプリ側で描画止めてるソフトが多いけど
それでも最小化した時点の縮小画面は見れるし
Windows VistaのAeroから変わってるんだわ。
半透明処理もGPUにやらせてるからWindows 2000の頃と違い格段に軽くなってる。
633:デフォルトの名無しさん
19/11/10 13:57:05.17 fP398yW4.net
>>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された
634:デフォルトの名無しさん
19/11/10 14:11:16.15 hRll0rFL.net
>>606
GetDC GetPixel で取れない場合
URLﾘﾝｸ(maverickproj.web.)<)はて？.com/entry/20101209/1291890231
URLﾘﾝｸ(codeday.me)
635:デフォルトの名無しさん
19/11/10 14:11:28.61 O4L9SaaX.net
GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。
636:デフォルトの名無しさん
19/11/10 14:17:16.14 fP398yW4.net
昔はVRAMにあったものがGPUのメモリにあるわけだからね。
通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。
だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。
637:デフォルトの名無しさん
19/11/10 15:48:36.60 GjrjejsC.net
でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
638:デフォルトの名無しさん
19/11/10 15:51:41.38 u8+xJCBj.net
同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
639:デフォルトの名無しさん
19/11/10 16:09:15.77 GjrjejsC.net
もう滅茶苦茶だなｗ
そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ
で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ
640:デフォルトの名無しさん
19/11/10 16:51:52.04 invbJGJm.net
Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど
641:デフォルトの名無しさん
19/11/12 19:29:29.86 fqP05o8Z.net
HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。
642:デフォルトの名無しさん
19/11/12 19:33:32.19 R9AMJEW8.net
>>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。
643:デフォルトの名無しさん
19/11/12 20:44:06.06 mKGma296.net
>>630
SetWorldTransform
644:デフォルトの名無しさん
19/11/13 10:09:58.07 OceCV+VL.net
DirectX使えば自由
645:デフォルトの名無しさん
19/11/19 11:11:30.06 NEogfZFa.net
いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。
646:デフォルトの名無しさん
19/11/25 20:46:42.81 0q+n1Hac.net
Windows10 での symlink
URLﾘﾝｸ(social.msdn.microsoft.com)
647:49
19/11/25 22:38:11.66 dg2mzwJY.net
>>630
GDIPlusは駄目なん?
648:蟻人間
19/11/25 22:53:59.71 S0HuE7/3.net
StretchBltでマイナスの値を指定するとミラーリングできるらしい。
URLﾘﾝｸ(forums.codeguru.com)
649:デフォルトの名無しさん
19/11/26 00:15:01.51 FXTOqUMb.net
どっかで阿鼻叫喚が始まる予感
URLﾘﾝｸ(twitter.com)
(deleted an unsolicited ad)
650:デフォルトの名無しさん
19/11/26 09:59:26.09 c3SEnPpX.net
お
いよいよcp932ともおさらばか
試行錯誤はあっても良い流れは認めよう
問題が出たら出たで治せば良いんだから
治す範囲がどんだけあっても諦めるな
なにもやらないよりまし
651:デフォルトの名無しさん
19/11/26 10:49:04 LSm6MssX.net
一年前以上からあるオプトイン設定の話だが
652:デフォルトの名無しさん
19/11/26 11:36:11 fVihpbt7.net
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
653:デフォルトの名無しさん
19/11/26 11:45:03.56 fVihpbt7.net
「ワールドワイド言語サポートで Unicode UTF-8 を使用」をするとどうなるか？
Unicode対応のアプリ・・・設定とはとは無関係にUnicode対応
Unicode非対応のアプリ・・・
日本語アプリはcp932でないと動かない。
ASCIIしか使えないアプリはcp932でもUTF-8でも動く。
UTF-8に対応したアプリは現時点ではまず存在しない。
この設定は今後UTF-8に対応したアプリが作られたときのための設定
この設定はデフォルト値でしかないのでUTF-8にしてもchcp932相当のことをすればcp932アプリは動く
互換モードの設定でコードページを指定できるようになるかもしれないね
654:デフォルトの名無しさん
19/11/26 11:55:01.45 sOexhNbU.net
コマンドプロンプトは怪しいな
655:デフォルトの名無しさん
19/11/26 11:55:11.67 dbvsSdaZ.net
いまだにファイルパスがユニコード対応してないアプリあるからな。氏ねと言いたくなる
656:デフォルトの名無しさん
19/11/26 11:57:13.82 fVihpbt7.net
>>643
コマンドプロンプトはUnicode対応だよ
cp932の状態でもdirでUnicodeのファイル名表示できてるじゃん
657:デフォルトの名無しさん
19/11/26 12:05:13.97 sOexhNbU.net
chcp 65001
でバグバグになるのいつ治るの
658:デフォルトの名無しさん
19/11/26 12:08:00.36 fVihpbt7.net
>>646
表示が崩れる問題なら直ってる。
動作自体なら以前から問題なく動いている。
659:デフォルトの名無しさん
19/11/26 12:30:13.72 4pvDP8OD.net
>>641
こういう流れになってますが
URLﾘﾝｸ(twitter.com)
動かなくなるんじゃなくて、破壊されて動かなくなるのが正解なのでは？
(deleted an unsolicited ad)
660:デフォルトの名無しさん
19/11/26 12:31:57.39 Yz+apKYY.net
>>648
破壊されて動かなくなるとは、一体どこにそんな証拠があるのでしょうか？
661:デフォルトの名無しさん
19/11/26 12:39:10.74 Yz+apKYY.net
実際に試した人たち
URLﾘﾝｸ(qiita.com)
URLﾘﾝｸ(adatarag3.blogspot.com)
URLﾘﾝｸ(chiyosuke.blogspot.com)
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」から
「日本語（日本）」に戻して文字化けが直った人
URLﾘﾝｸ(kuronyankotan.com)
662:デフォルトの名無しさん
19/11/26 12:50:39.23 4pvDP8OD.net
全てのA系APIがUTF-8をI/Oするんじゃろ？
非対応アプリがテキスト系ファイルI/Oしたら死ぬのでは？
663:デフォルトの名無しさん
19/11/26 13:01:13.64 Yz+apKYY.net
>>651
WindowsはUnicode対応なので関係ない話
非対応アプリが動かなくなるだけ
664:デフォルトの名無しさん
19/11/26 13:03:50.25 Yz+apKYY.net
だいたい全てのA系APIがUTF-8をI/Oしたからって
何の問題があるんだ？
今までだってそれは、全てのA系APIがSJISとかASCIIとか
韓国や中国のなにかに変更するスイッチだっただろうと
そこにUTF-8が増えただけに過ぎない。
665:デフォルトの名無しさん
19/11/26 13:06:07.48 VJ34cQn0.net
Windows自体は昔からUTF16だと思ってたんだけど、
いつのまにかUTF8になってたの？
666:デフォルトの名無しさん
19/11/26 13:08:57.76 njyF587z.net
A系
667:デフォルトの名無しさん
19/11/26 13:12:06.34 Yz+apKYY.net
>>654
Windows NTはUTF-16だよ？
この設定はUnicodeに対応してない古いWindows 9xアプリのための
互換モード設定だから
将来的に互換モードとして使っていたこの機能をUTF-8アプリの
移植用に利用しようとか考えてるんでしょ？ Linuxアプリのこともあるし。
WindowsネイティブのUnicode（UTF-16）モードとは別に
UTF-8モードが追加されたってだけの話
668:デフォルトの名無しさん
19/11/26 13:29:27 4pvDP8OD.net
>>652-653
>>651
A系アプリの問題の話なのに、なんでWindows自体の話になるの？
てか、>651のみならずリンク元の流れすら読んでない感じ？
まあ実際俺も試したわけじゃないけど、書いてることが事実だとすると
設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
669:デフォルトの名無しさん
19/11/26 13:35:05 Yz+apKYY.net
> A系アプリの問題の話なのに、なんでWindows自体の話になるの？
A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
Windows APIの話なんだからWindowsの話だろ？
Windows自体はWindows APIのW系（Unicode）を原則として使用してるが
古いアプリのためにA系のAPIも提供してる。Windows はW系を使ってるので
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
したところで何の影響もない。影響があるのは古いアプリのみ
> 設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
それならデータ消せばいいだけだろ。アプリの都合なんか知るか
670:デフォルトの名無しさん
19/11/26 13:46:31 dAEqoOXB.net
朝鮮人は息を吐くように嘘を吐く
671:デフォルトの名無しさん
19/11/26 13:47:38 4pvDP8OD.net
>>658
>それならデータ消せばいいだけだろ。アプリの都合なんか知るか
だからそのアプリの話を一貫してしてるんだけど？
アプリのデータを消す？
大事な既存データでも消したらOK? 馬鹿？ 仕事したことない？
システムプロファイルも全て戻らないということなので、戻したら動く保証はどこにもない
何度も言うけど、A系アプリの話だからな？
例えばCの話をしてるのにJaveや.NETが今は主流だからCなんて知らん
って的外れなこと言ってるだけだお前は
672:デフォルトの名無しさん
19/11/26 13:55:16 Yz+apKYY.net
>>660
何が言いたいのかわからん。
アプリが動かなくてなってもWindowsは問題なく動くだろ
SJISにしか対応してないアプリのコードページを変えてデータが壊れたって
それはアプリの動作保証外の使い方をしたからってだけで
OSのせいでもアプリのせいでもない。
データ消えたら困るなら保証外の使い方をするなよ。
バックアップぐらい取れ。
673:デフォルトの名無しさん
19/11/26 13:58:46 dAEqoOXB.net
役に立つ人柱はここか
URLﾘﾝｸ(chiyosuke.blogspot.com)
URLﾘﾝｸ(srad.jp)
674:デフォルトの名無しさん
19/11/26 14:08:16 dbvsSdaZ.net
英語圏の人間向けであって、日本人が使うオプションじゃないからな
大手のソフト含めて対応してない（設定変えるとおかしくなる）のは山ほどあるよ
675:デフォルトの名無しさん
19/11/26 14:13:24 JyI6kWkc.net
>>660
君はちょっと落ち着け
>>648の内容はシステムの設定を元に戻せないという話であって
アプリの話じゃないだろ
そして
>大事な既存データでも消したらOK? 馬鹿？ 仕事したことない？
だったらβの機能なんか使うなよ、で終わりだよ
βじゃなくなるときに、キレイに全部戻せるようになってるか、
SJISアプリは切り捨てますって発表があるかのどっちかだろ
676:デフォルトの名無しさん
19/11/26 14:17:07 4pvDP8OD.net
>>661
なんでWindowsが動かなくなる（だったりWindowsの問題や責任）話と勘違いしてるの？
単純に設定変えたらA系アプリに問題があるねってだけの話だぞ？
的外れも甚だしいし視野が狭すぎる
過去資産を使ってるクライアントを持ってたら、この手の話には敏感になるわ
バックアップとかそういう次元の話じゃない
お前みたいなのがクライアントのサポートしたらクライアントが居なくなるレベル
677:デフォルトの名無しさん
19/11/26 14:22:54.58 Yz+apKYY.net
>>665
だから何が言いたいんだよ。
cp932前提の古いアプリはUTF-8で動きませんって
当たり前の話なだけだろ
678:デフォルトの名無しさん
19/11/26 14:24:20.04 Yz+apKYY.net
つーか、最初っから俺が言ってるんだわ
641 自分：デフォルトの名無しさん[sage] 投稿日：2019/11/26(火) 11:36:11.45 ID:fVihpbt7 [1/4]
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
679:デフォルトの名無しさん
19/11/26 14:28:45.38 4pvDP8OD.net
>>664
> だったらβの機能なんか使うなよ、で終わりだよ
まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
割を食うのはこっちになったりすると目も当てられんからね
>>666
そんな当たり前の次元の話を一切してないからね
680:デフォルトの名無しさん
19/11/26 14:29:07.54 dAEqoOXB.net
ふ～ん
Pythonで問題起きるのか
Rubyはどうなんだろ
681:デフォルトの名無しさん
19/11/26 14:32:29.48 dAEqoOXB.net
上の >>662 のPythonの人は
PYTHONENCODING=utf-8の方を気にしてるけど
setdefaultencodingとかはどうしてるのかな
682:デフォルトの名無しさん
19/11/26 14:34:38.59 4pvDP8OD.net
>>667
> cp932使ってる古いアプリは、この設定にすると
> 動かなくなるだけ。つまり捨てるしか無い。
この時点で間違ってる
つーかW系A系のAPIの使い分けしたことあれば、A系の動作が変わることでどうなるのか
ってある程度予想できそうなもんだけど、なんでここまで勘違いが続けられるの？
683:デフォルトの名無しさん
19/11/26 14:46:41.11 LSm6MssX.net
プロファイル壊されるってゆーてるリンクの連中だけが情報量ゼロなの草
684:デフォルトの名無しさん
19/11/26 14:53:48 hqQvrruW.net
結局W系で作るしかないんだから余計なことは考えなくていいよ
685:デフォルトの名無しさん
19/11/26 14:54:37 ogXaluX+.net
fopen()の振る舞いで困るかも。Win32のfopen()はutf8を特別扱いするから。
686:デフォルトの名無しさん
19/11/26 14:56:55 dAEqoOXB.net
レジストリの読み書きも気になるな
687:デフォルトの名無しさん
19/11/26 15:01:36 JyI6kWkc.net
>>671
いわゆるバイナリモードを使うとBOMがついてきちゃうとか、
いろいろトラブルが発生する可能性はあるね
前回のアップデートでもコンソールで文字化けする問題があったし
それをざっくり言えば、古いアプリを捨てるか、設定変えんな、
という話になるだろ
APIオタクと運用を見てる人で視点が違うことを理解しなよ
>>668
>まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
それは契約文書にきちんと盛り込むべきだね
688:蟻人間 ◆T6xkBnTXz7B0
19/11/26 15:25:37 SWHzOLKZ.net
MultiByteToWideChar/WideCharToMultiByteの第一引数にシフトJISコードページ932を指定しないといけないらしい。CP_ACPだと死ぬ。
689:デフォルトの名無しさん
19/11/26 15:33:53 Yz+apKYY.net
>>672
壊されないよ。日本語が化けることはあっても
それは想定とは違うデータが入っただけだし
アプリの問題
690:蟻人間
19/11/26 15:37:00.29 SWHzOLKZ.net
シフトJISテキストファイルにUTF-8テキストが混ざったら、そりゃ文字化けするでしょう。
691:デフォルトの名無しさん
19/11/26 15:56:07 9NQ9wJPH.net
>>679
無茶苦茶になるよな
ありえんわ
692:デフォルトの名無しさん
19/11/26 16:01:44.16 Yz+apKYY.net
コードページを変えると文字化けするだろうね
それだけの話。別に動かなくなるわけじゃない。
コードページをもとに戻せば動く
壊れたデータは直せばいいだけ
693:デフォルトの名無しさん
19/11/26 16:02:07.57 ogXaluX+.net
main()に渡される引数文字列argvどうなります？
694:デフォルトの名無しさん
19/11/26 16:23:03.19 9NQ9wJPH.net
自前で先行バイト検出しながら文字列書き換えるような関数とか如何すんのよ
695:デフォルトの名無しさん
19/11/26 16:23:44.61 H048FZbZ.net
>>682
Unicode非対応アプリのmainだとして、
Unicode対応アプリ（からUnicode APIを使って）呼び出せば、引数全てがUTF-16からUTF-8に変換されてから
呼び出される。Unicode非対応アプリから呼び出せば、渡した文字列（バイト列）がそのまま渡される。
そこは今までと変わらない。今までもUnicode対応アプリから呼び出せば、設定されたコードページ（例えばcp932）に
変換されて呼び出される。違いはUTF-16からUTF-8だと変換できない文字がないので文字化けは一切発生しない。
なお、渡されたからと言ってアプリが正しくその文字列を扱えるかどうかは別の話
結局の所cp932専用で作られたアプリは完全に同じようには動かない。（ASCIIの範囲でなら問題ないだろう）
696:デフォルトの名無しさん
19/11/26 16:25:08.09 H048FZbZ.net
>>683
実装と場合（データ）によるとしか言えない。
Unicode（UTF-16）非対応の古いアプリは、想定したコードページでしか
まともに動かない。それだけの話だよ。
697:デフォルトの名無しさん
19/11/26 16:25:51.97 H048FZbZ.net
あと、システムプロファイルとか意味不明。
何の話をしてるのかわからないレベル。
698:デフォルトの名無しさん
19/11/26 16:30:59 H048FZbZ.net
ちなみにUnicodeから非Unicodeへの変換は変換できない文字があるから一部文字化けするが、
非UnicodeからUnicodeへの変換では文字化けすることはない。
だから、cp932を扱えるアプリがcp932でレジストリ（UTF-16）に書き込んでも
適切に変換が行われるし、そのアプリがUTF-8を使えるなら、それもレジストリに書き込んでも壊れたりしない。
例えばアプリ（cp932）から レジストリ（UTF-16）に書き込んで、
レジストリ（UTF-16）を アプリ（UTF-8）から参照することは問題なくできるということ
699:デフォルトの名無しさん
19/11/26 16:32:48 9NQ9wJPH.net
>>685
非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
そこにUTF-8とかねじ込まれても困るわ
700:デフォルトの名無しさん
19/11/26 16:32:49 H048FZbZ.net
もちろんレジストリ（UTF-16）をアプリ（cp932）で参照したときは扱えない文字列があるが、
それはファイル名（UTF-16）をアプリ（cp932）で扱えない文字があるという程度の話でしか無い。
701:デフォルトの名無しさん
19/11/26 16:35:04.40 ogXaluX+.net
マルチバイト文字を含むファイルパスが鬼門でしょ。
702:デフォルトの名無しさん
19/11/26 16:38:45.15 H048FZbZ.net
>>688
お前は意味がわかるように書き込め
> 非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
どういう使い分けがされてるのか書け
> オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
それって引数がWCHAR *ならW系が使われて、引数がCHAR *ならA系が使われるってだけだろ
> そこにUTF-8とかねじ込まれても困るわ
そこにってどこよ？何が困るんだよ。
UTF-8はCHAR*を使うって理解してるか？
今までA系はASCIIだけでなくSJISや多数の文字コードで使われていたというのに
UTF-8が増
703:えたごときで何も困らんだろ
704:デフォルトの名無しさん
19/11/26 16:41:18.53 H048FZbZ.net
>>690
鬼門っていうか、単にUnicode非対応のアプリは
想定しているコードページに変換できない文字を扱えないってだけだけどな
たったこれだけのことなのに何をグダグダ言ってるのかわからん
705:デフォルトの名無しさん
19/11/26 16:56:51.07 ogXaluX+.net
バッチファイルは厄介。あればだが。
706:デフォルトの名無しさん
19/11/26 16:59:13.07 JyI6kWkc.net
>>684
UTF8アプリなんて存在するんだっけ？
707:デフォルトの名無しさん
19/11/26 17:02:23.79 9NQ9wJPH.net
>>691
たとえUnicodeに対応しているプログラムであっても何らかの出力ファイルをSJISで出力するような構造だと、
それを勝手にUTF-8に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな
708:デフォルトの名無しさん
19/11/26 17:12:43 H048FZbZ.net
>>694
まずないだろうね。作れるようになったのは最近だし。
念ために言っておくけど、ないっていうのは
Unicode対応アプリではない（＝A系APIを使う）かつASCII文字としてUTF-8を使うアプリのことね。
UTF-8はUnicodeだろというツッコミはいらん。
WindowsにおいてUnicode対応とはUTF-16アプリのこと
最近Unicode非対応の古いアプリでもUTF-8が使えるようになったから、
古いアプリをUTF-8用として作り直して新しくすることでA系のまま
Unicode対応にできるとかいうジョークのような話ｗ
それするぐらいなら最初からUnicode対応として.NETとかで作りますわ。
完全に将来のLinuxアプリなどの移植用。多分最終的にマニフェストとかで
このアプリはUTF-8アプリですって指定できるようになるんじゃない？
709:デフォルトの名無しさん
19/11/26 17:13:45 H048FZbZ.net
>>695
だからなんなんだよ？
当たり前の話するな。OSともアプリとも関係ない話だわ
LinuxでもMacでも同じことは起きるわ。だからなんだんだよ
710:デフォルトの名無しさん
19/11/26 17:14:18 H048FZbZ.net
結論を書け結論を。お前がいいたいこが何かを書け。
711:デフォルトの名無しさん
19/11/26 17:16:25 9NQ9wJPH.net
>>698
勝手に文字コードを変えんなってだけやろ
利用者の意思で変えさせろと
712:デフォルトの名無しさん
19/11/26 17:44:52 H048FZbZ.net
>>698
勝手に変えてない。お前は馬鹿なのか？
713:デフォルトの名無しさん
19/11/26 17:48:56 FXTOqUMb.net
クッソ伸びてて草
MBSCなソフトがA系APIでデータ読み書きしてたら非対応のUTF8に書き換わってて、
以降データが文字化けしたまま困ることになるんだから、元に戻せばOKとか非対応なんだから
仕方ないとか、こればかりは擁護不可能の的外れ
表示だけの問題じゃなく記録データにも影響があって、こいつばかりは復元ソフトでも組まないと戻せない
MBSCなソフトは使えないだけならば、単純にA系APIを廃止すればいいだけなんだが
MSはお節介にもどうにかして過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
用意したって点だけ見ても、単純に非対応とか元に戻せばいいというような話ではない
年末にお父ちゃんから、古い宛名印刷ソフトのデータが壊れたって連絡が来るかも知れないくらいには、
時と場合によっては取り返しが付かない
今のところデフォでこの切り替えは無効だが、将来もしかしたら～というのが現時点でのキモだろう
714:デフォルトの名無しさん
19/11/26 17:59:10 4DbW4sNm.net
>>701
そんな長々と書かなくても、
SJISのファイルにUTF-8で書き込んだら文字化けしたのと同じことでしょ
そんなのLinuxでもmacOSでも起きる問題だって言ってるんだが
715:デフォルトの名無しさん
19/11/26 18:00:34 4DbW4sNm.net
>>701
> 過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
意味不。単にUTF-8にも対応したってだけ
コードページを一つ増やしたに過ぎない。
A系の挙動は昔から設定で変更できた。
716:デフォルトの名無しさん
19/11/26 18:02:42.72 4DbW4sNm.net
もしかしてこいつは、ユーザーが設定変更しなくても
アップデートで勝手にUTF-8に変わるとか思ってるのか？
ならものすごくマヌケだｗ
717:デフォルトの名無しさん
19/11/26 18:12:52.84 FXTOqUMb.net
あー、アホが一人混じってるから伸びてるのか
把握
718:デフォルトの名無しさん
19/11/26 18:18:38.91 4DbW4sNm.net
今度はレスしなかったところを見ると図星だったか
719:デフォルトの名無しさん
19/11/26 18:39:40.59 9NQ9wJPH.net
>>700
編集して上書きしたらUTF-8に変るんじゃなく新規での作成がUTF-8になるだけ？
それなら俺の誤解だったわ
勝手に変えるのなら死ねだが
720:デフォルトの名無しさん
19/11/26 18:49:29.78 4DbW4sNm.net
本当にアホだったな。ユーザーが意図的に変えない限り変わらないってのに
721:デフォルトの名無しさん
19/11/26 18:55:32.97 FXTOqUMb.net
論旨はは>>638よりは>>648みたらはっきりしてる
”安易に設定変更したらA系使ってるソフトが恐い”ってことだけであって、”問題ない”
と連呼してるアホ一人が理解力0というかマイナスなだけ
722:デフォルトの名無しさん
19/11/26 18:55:56.87 4DbW4sNm.net
しかもエアプなんだろうな。
>>638は古い情報で、
そもそも「ベータ: ワールドワイド言語サポートで Unicode UTF-8 を使用」の設定と
『メモ帳の文字コードと全く関係ない』話だってのもわかってないんだろう
『当時』はたまたまそこの設定がデフォルトになっていただけで、
今は常にUTF-8（BOMなし）
メモ帳は古いアプリでもなんでも無いしな
で、メモ帳が保存するテキストファイルの文字コードと
古いアプリの挙動も全く関係ない話。そんなの考えるまでもなくわかること
こいつずっとテキストファイルのデフォルトの文字コードと
APIの話をごっちゃにしてたのかよ
完全に素人だ
723:デフォルトの名無しさん
19/11/26 18:58:15.43 9NQ9wJPH.net
>>710
言っとくが俺と>>701は別人だからな
724:デフォルトの名無しさん
19/11/26 18:58:43.20 4DbW4sNm.net
725:>>709 >”問題ない”と連呼してる 連呼の意味わかってる？ｗ ”問題ない”で >>638以降のレスを探すと >>684で一回しか書いていない。しかも関係ない話 お前は思い込みが激しいってことがはっきりわかったな
726:デフォルトの名無しさん
19/11/26 19:05:03.16 4pvDP8OD.net
はい、論点誤魔化してきたね
未だに文字化けする程度の認識しかしてないから、話するだけ無駄だと思うよ
メモ帳とか連呼の定義とか持ちだしてきてもう意味不明
そもそもWinAPIのプログラムも組んだことないの丸わかりだから、キチガイに付き合うだけ損
727:デフォルトの名無しさん
19/11/26 19:05:29.42 dbvsSdaZ.net
例えば標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
そんなの使ってたら、ファイル前半はシフトJIS、後半はUTF8になって、どっちでも読めなくなる
これは極端な例だけど同じようなことはそこら中で起こりえる
728:デフォルトの名無しさん
19/11/26 19:05:45.18 FXTOqUMb.net
メモ帳・・・・？
ヤベえなこいつ
729:デフォルトの名無しさん
19/11/26 19:09:39.48 s8aO6zrT.net
だんだん論点ずれてきてるやん
730:デフォルトの名無しさん
19/11/26 19:09:52.88 4pvDP8OD.net
>>709
んだ
>>714
そうだね
単純にそういう話になると思ってたんだが、このスレでこのレベルの未経験者が話しに入ってくるとは思わなかった
731:デフォルトの名無しさん
19/11/26 19:11:27.01 4DbW4sNm.net
はぁ、リンク先も読んでないのかよ
>>638のリンク先読めよ・・・
URLﾘﾝｸ(twitter.com)
> 今までデフォルトでShift JISだったもの（メモ帳をはじめ…）が
> この設定をすると「メモ帳」の「名前を付けて保存」で「文字コード: ANSI」
> （デフォルト）だとBOM無しのUTF-8、「文字コード: UTF-8」だと
> BOM付きのUTF-8のファイルになります。
↑注意 これは古い話で今は当てはまらない
(deleted an unsolicited ad)
732:デフォルトの名無しさん
19/11/26 19:12:17.71 4DbW4sNm.net
>>717
> 単純にそういう話になると思ってたんだが、
その話は当たり前で、LinuxでもmacOSでも同じことになると
さんざん言ってる
733:デフォルトの名無しさん
19/11/26 19:17:08.27 4DbW4sNm.net
ちなみに
> 標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
これはコードページとは何の関係もない。
当たり前だがSJISで出力してるアプリは、
コードページをどう変更しようが、SJISで出力される。
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
チェックを入れたところで、SJISで出力してるアプリが
UTF-8で出力するように変わることはない。
734:デフォルトの名無しさん
19/11/26 19:18:48.31 9NQ9wJPH.net
設定変更しなければ良い、ってのは利用者の目線で開発者の発想ではないわな
735:
19/11/26 19:19:13.34 eitz3RWA.net
>>658
＞A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
＞Windows APIの話なんだからWindowsの話だろ？
win32api には同じ api 関数に対して A 系と W 系の二つの異なった関数が準備されているんです
A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います
736:
19/11/26 19:20:16.92 eitz3RWA.net
>>674
win32api に fopen は存在しません、CreateHandle ならば存在しますが
737:デフォルトの名無しさん
19/11/26 19:21:22.69 4DbW4sNm.net
もちろん、「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
の設定（コードページ）を見て、アプリ内部でその文字コードに変換して
出力するように作られてるアプリは別な。
あくまでA系APIを使ってるアプリの話
SJIS前提で作られてるアプリは、SJISでしか出力しません。
ただしAPIがUTF-8前提として処理するのでASCII以外だと
出力がおかしくなります。
738:デフォルトの名無しさん
19/11/26 19:22:46.52 4DbW4sNm.net
>>722
> A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います
うんしってる。そして新設された「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
というのは、A系を使ってASCII互換のUTF-8を使えるようになる機能です。
739:
19/11/26 19:22:59.57 eitz3RWA.net
問題のオプションが A系 W系に関係するものか、誰か見解を出していただけませんか？
740:
19/11/26 19:24:22.44 eitz3RWA.net
>>725
thanks!
741:デフォルトの名無しさん
19/11/26 19:25:39.71 4pvDP8OD.net
>>718
>>648読んでる？
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
>>719
> その話は当たり前で、LinuxでもmacOSでも同じことになると
> さんざん言ってる
今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？
>>720
> 当たり前だがSJISで出力してるアプリは、
> コードページをどう変更しようが、SJISで出力される。
君は、
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
これ自体がウソだって言ってるんだね？
ダラダラ連投せずに、そう書けば？
742:デフォルトの名無しさん
19/11/26 19:26:51.40 4DbW4sNm.net
>>728
> 今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？
だから他のOSでも起きる、SJISのファイルにUTF-8で書き込むと壊れるという話を
ごちゃまぜにするなと言ってる。
それはWin32APIと関係ない話だと言ってるだけ
743:デフォルトの名無しさん
19/11/26 19:32:03.78 4pvDP8OD.net
>>729
> SJISのファイルにUTF-8で書き込むと壊れるという話を
なぜそのようなことが起こるのか、どういうきっかけで起こるのか、影響範囲はどうなっているのか、
A系APIの挙動が変わるからだ
という話なだけでしょうが
他のOSを例に出す意味がない
君の主張は、APIの挙動は変わらないということなんだね？
要点をまとめなよ
744:デフォルトの名無しさん
19/11/26 19:36:44.09 4DbW4sNm.net
>>728
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
「ダウト」なのの１つ目は「半端ねぇ」の部分。
A系APIは昔から、コードページの設定をみてそのコードページの文字コードを
前提として処理している。昔から当たり前のことで今更驚くことじゃない。
英語ならASCIIを前提として処理するし、日本語に設定すればSJISを前提として
処理するするようになるし、韓国語や中国語にすれば、その国文字コードを前提して処理する。
20年以上そういう機能だった。
そしてもう一つはI/Oするって所。APIが設定に応じた文字コードを前提とするだけで別にI/Oするわけじゃない。
どの文字コードを使うかはアプリによる。SJIS専用のアプリはSJISしかI/Oしない。
UTF-8を前提としてる状態でSJISを流すとおかしくなるというだけで、
それらのAPIがUTF-8でI/Oするように変わるわけじゃない。
（エラーメッセージとかはSJISのリソースを使うようになるが、
これはAPIが変換してるわけじゃなくコードページに応じたリソースに変えてるだけ）
745:デフォルトの名無しさん
19/11/26 19:40:06.72 4DbW4sNm.net
>>730
要点 「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」の設定によるAPIの挙動と
アプリが入出力する文字コード（ファイル等を含む）は関係は一切ない
アプリが入出力する文字コードはアプリの実装によって決まる。
（Win32 APIと関係ないから、他のOSも同じという話につながる）
746:デフォルトの名無しさん
19/11/26 20:15:32.91 9NQ9wJPH.net
APIの挙動変るのはやっぱヤベーな
iniから文字列を取り出す >UTF-8
今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
これを利用したディレクトリトラバーサルとかも可能なんじゃね？
747:デフォルトの名無しさん
19/11/26 21:07:20.59 Qm31cF9G.net
まずは公式ドキュメントを読め
話はそれからだ
Visual C++ のテキストと文字列
URLﾘﾝｸ(docs.microsoft.com)
748:
19/11/26 21:10:43.31 eitz3RWA.net
>>734
VC のドキュメントがなんの役に立つ？
749:デフォルトの名無しさん
19/11/26 22:34:01.39 JUtzLycC.net
他のソースはないかな。
βとはいえMSが単なるロケールの追加じゃなくてそんな過激なスイッチを導入しようとする意図がよくわからん。
750:デフォルトの名無しさん
19/11/26 23:00:16.55 dbvsSdaZ.net
英語圏だと切り替えても英語入出力だけするなら何も変わらないしメリットの方が多い
日本語圏じゃデメリットしかないがｗ
751:デフォルトの名無しさん
19/11/26 23:01:00.12 JyI6kWkc.net
>>719
> その話は当たり前で、
本当？
SJISアプリをUTF-8アプリとして動作させるんだぜ？
printf("あほまぬけ\n"); こんなアプリがあったときに、
設定前と設定後で出てくる文字コードが違うんだぜ？
Linuxでそんなことが起こるかよ。
752:デフォルトの名無しさん
19/11/26 23:03:08.88 JyI6kWkc.net
>>737
シングルバイトアプリがマルチバイトアプリとして動くわけ？
もっと変なことになるだろそれ
753:デフォルトの名無しさん
19/11/26 23:32:37.50 9NQ9wJPH.net
_tcsincなんかマルチバイト前提にしか使わないような関数だろ
�
754:ﾇんな挙動になるんだ
755:デフォルトの名無しさん
19/11/26 23:33:44.60 4vHYq+aK.net
「ワールドワイド言語サポートで Unicode UTF-8 を使用」にチェックを入れ
なければUnicode非対応のアプリは従来通り動くし、これにチェックを入れな
ければ動かない既存のアプリっていうのも現状では無いんでしょう？
非対応アプリを対応させるのに要するコスト以上の利益が今後見込めるなら
アプリ開発元も対応させるだろうけど、そうでないなら放置されるんじゃ
ないかなあ。
MSがUnicode非対応アプリを切り捨てるようなことをすれば、Windows離れ
(＝パソコン離れ)が進むだけでしょ。
756:デフォルトの名無しさん
19/11/26 23:36:26.55 JUtzLycC.net
CP1252のアプリにUTF8突っ込まれてもやっぱり困るだけだよなぁ。
757:デフォルトの名無しさん
19/11/26 23:40:34.75 oARfCEQj.net
いきなりなんとかアプリで括るから話が噛み合ってないのでは？
まず確認すべきなのはAPIの挙動がどう変わるのかで、
次に典型的なsjisアプリでAPIをどう使っているのか
だから影響はこうだみたいな
誰か整理して教えて
758:デフォルトの名無しさん
19/11/26 23:43:29.50 dbvsSdaZ.net
>>738
> printf("あほまぬけ\n"); こんなアプリがあったときに、
設定後は文字化け出力
759:デフォルトの名無しさん
19/11/26 23:56:56.29 4pvDP8OD.net
>>731
こちらの論拠は全てこのツイートにあるしこれベースで話していたわけで、
最初から君の主張がそれなら話が早かったんだけどね
端からAPI関係ないと言われても話が通じず意味不明にしか思わない
しかしはっきり言って、どっちも信用ならんｗ
自分でテストするしかないわもう
760:デフォルトの名無しさん
19/11/26 23:58:07.39 JUtzLycC.net
ググってみて気付いたが一年以上前の話題なのね、これ。
761:デフォルトの名無しさん
19/11/27 03:15:27 j6pNPBz/.net
>>738
> 設定前と設定後で出てくる文字コードが違うんだぜ？
違うという証拠は？
printf("あほまぬけ\n"); と書いてコンパイルしたとき
\0で終わるSJISのバイト列が格納されてるに過ぎない。
それが設定で変わるわけ無いだろ。
762:デフォルトの名無しさん
19/11/27 03:32:29.18 j6pNPBz/.net
>>733
> APIの挙動変るのはやっぱヤベーな
それは英語圏のASCII前提で作られているアプリでSJISを使うと
\（0x5c）が含まれる「表」などで誤動作するって話と同じこと
URLﾘﾝｸ(www.kent-web.com)
> 今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
> これを利用したディレクトリトラバーサルとかも可能なんじゃね？
UTF-8は文字の一部にASCIIコードが含まれることはないのでそのようなことは発生しない。
というかそもそもが「英語圏で作られた日本語などを扱えないUnixアプリ」でこのような問題が
起きないように考慮されて作られたのがUTF-8だから
763:デフォルトの名無しさん
19/11/27 03:36:29.35 h6Shw8l2.net
>>747
A系のAPIがUTF-8に変換されるってのは、そういうことだろう？
764:デフォルトの名無しさん
19/11/27 03:37:49.05 h6Shw8l2.net
>>748
>UTF-8は文字の一部にASCIIコードが含まれることはないのでそのようなことは発生しない。
ねぇねぇ？
大丈夫？