[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
542: 2019/11/07(木)02:26 ID:4jX7Qkw7(1) AAS
いいかげんな知識で語りたがるやつ多すぎ
543: 2019/11/07(木)02:27 ID:+N3PsKU8(2/16) AAS
32BIT時代は、整数サイズとポインタサイズが一致していて、サイズの選び方に
悩むことが無く便利だった。果たして、整数型を全部64BITにして良いものか
どうか。原則的に速度は変わらないとしても使用メモリは増えてしまう。
恐らく、exeファイルのサイズも増加するだろう。
544(1): 2019/11/07(木)02:42 ID:sEmiRyTj(2/15) AAS
コンピュータが遅かった時代はCPUに最適なデータ型を
使うことが重要だったが、今は数値型しかなくて
データサイズは自動的に決まりますとかばかりだもんな
545(1): 2019/11/07(木)02:44 ID:+N3PsKU8(3/16) AAS
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にした方が
省1
546(1): 2019/11/07(木)02:45 ID:+N3PsKU8(4/16) AAS
>>544
>今は数値型しかなくてデータサイズは自動的に決まりますとかばかりだもんな
C++だと今でもデータサイズは明示します。
547: 2019/11/07(木)02:54 ID:PsJP4fV8(1) AAS
size_t型が無難にして最強
548(1): 2019/11/07(木)03:00 ID:sEmiRyTj(3/15) AAS
>>546
他の言語の話や。今は速度よりも利便性のほうが重要や
549(1): 2019/11/07(木)03:18 ID:+N3PsKU8(5/16) AAS
>>548
例えば、JavaScriptだと、数値型のデータサイズが自動的に決められている
わけではなく、常に double 型(64BIT 浮動小数点型)なのですが、
整数は32BIT整数型までだと double型に精度を落とすことなく完全に
収まるので、何も考えずに正しく扱えるだけです。
JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
550: 2019/11/07(木)03:23 ID:+N3PsKU8(6/16) AAS
>>549
また、JavaScriptは、シンプルな使い方では、原則、整数型がなく、
console.log(54 / 10);
とすると、5.4と表示されます。これは、54や10が整数ではなく、
54.0 や 10.0 という double 型浮動小数点として扱われているためです。
これは、Sun/Oracle の Java とは全く結果が異なります。後者では、
54/10は、「整数除算」なので、結果は整数の「5」となります。
551: 2019/11/07(木)03:38 ID:sEmiRyTj(4/15) AAS
> JavaScriptでは、64BIT 整数型は、伝統的には原則的に使えません。
64bitも使うのかって話なんだけどな？ 52bitで十分だろう？
外部ﾘﾝｸ:sbfl.net
> JavaScriptのNumber（数値型）は倍精度浮動小数点数となります。
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。
552: 2019/11/07(木)03:39 ID:sEmiRyTj(5/15) AAS
なんだ。JavaScriptにBigIntあるじゃん
Numberで表せる最大の整数値は十分な値にも思えますが、
分野によってはこれでも足りなくなることがあります。そこで導入されたのがBigIntです。
BigIntは、任意精度の整数を表す新しいプリミティブ型です。
任意精度の整数値については、基本的にCPUに搭載されている計算機は対応していないので、計算はソフトウェアによって行われます。
553(1): 2019/11/07(木)03:43 ID:sEmiRyTj(6/15) AAS
やっぱりどんなときでもプログラマがデータ型を
選んでくださいっていうのは時代遅れだと思わ
554(1): 2019/11/07(木)03:53 ID:+N3PsKU8(7/16) AAS
>>553
自動化することは可能ですが、現在の技術でそういうところまで自動化した
言語を使ってコンパイラ処理系を書くと、コンパイル速度が100倍遅くなる
かも知れません。これはコンパイル意を作成した経験に基づく話です。
もの凄く厳しい世界が実はまだ沢山残っています。
555(1): 2019/11/07(木)03:55 ID:+N3PsKU8(8/16) AAS
>>554
誤：かも知れません。これはコンパイル意を作成した経験に基づく話です。
正：かも知れません。これはコンパイラを作成した経験に基づく話です。
556: 2019/11/07(木)03:58 ID:sEmiRyTj(7/15) AAS
100倍遅くなるなら100倍高速なコンピュータを使えばいいだけ
557: 2019/11/07(木)03:58 ID:sEmiRyTj(8/15) AAS
今より100倍遅かった時代もあるのに
何を言ってるんだろうか？
それこそ時代遅れの感覚
558(1): 2019/11/07(木)03:59 ID:sEmiRyTj(9/15) AAS
あと、「かも知れません。」とかいう推測はどうでもいいから
コンパイラを作り上げた俺が言うのだから
説得力は高いだろうし
559: 2019/11/07(木)04:00 ID:+N3PsKU8(9/16) AAS
>>555
GPGPUなどの世界でも、乗算速度がfloatとdoubleでは、4倍以上も違うような
例も多いのです。また、doubleをサポートして無いGPGPUの場合、doubleの乗算を
floatや整数型などにバラして処理するので数10倍かかります。
なので、慎重になる必要があります。
CPUの場合でもintとdoubleで速度がかなり違うことが多いです。
560(1): 2019/11/07(木)04:02 ID:sEmiRyTj(10/15) AAS
あと極まれにスピードが重要な部分があるから
全部スピード重要視しろとかいうアホな感覚なｗ
あれはやめてほしい。
極稀に重要なら、極稀に使うものを作ればいいだけ
よく使うものを短くする。（仕事の）圧縮の鉄則
561(1): 2019/11/07(木)04:02 ID:+N3PsKU8(10/16) AAS
>>558
あなたより私の方が良いコンパイラを作っている可能性も有りますよね。
562(1): 2019/11/07(木)04:05 ID:+N3PsKU8(11/16) AAS
>>560
自動化の道は検討の価値はあるでしょう。
しかし、int32型とint10000000型を自動的に取捨選択できるほど、
コンパイラが賢くなるのは恐らく遠い未来です。
どこかで機能制限や精度を人間が指示する必要があると考えられます。
563(1): 2019/11/07(木)04:07 ID:sEmiRyTj(11/15) AAS
>>561
そういう俺のほうが優れてるとか言う主張をしたいなら、
個人を特定できるような情報をだせ
564(2): 2019/11/07(木)04:08 ID:sEmiRyTj(12/15) AAS
>>562
コンパイラが無理なら実行時にメモリ拡張すればいいだけ
そういうことも思いつかないから、その程度止まりなんだよｗ
565: 2019/11/07(木)04:08 ID:+N3PsKU8(12/16) AAS
>>563
それはお互い様です。
566(1): 2019/11/07(木)04:11 ID:+N3PsKU8(13/16) AAS
>>564
それでは明らかに遅く、数値計算、コンパイラ、翻訳、AI、データ処理、
OSなどの作成には向いていない言語になるでしょう。
567(1): 2019/11/07(木)04:12 ID:sEmiRyTj(13/15) AAS
大胆に変数はすべて128bitしかないという言語だって考えられる
最大 340282366920938463463374607431768211456 までしか扱えないが
568(1): 2019/11/07(木)04:13 ID:sEmiRyTj(14/15) AAS
>>566
そんな言語が今はたくさんあり実用化されています。
569: 2019/11/07(木)04:17 ID:+N3PsKU8(14/16) AAS
>>567
64BIT整数ですら効率を考えて使用を躊躇する世界に我々はまだいます。
あなたが普段使っているコンパイラも、非常に細かい高速化を施して
あるので快適に使えているだけで、PythonやJavaScript、Rubyなどの
動的言語では達成できません。
例えば、JavaScriptの遅さは、全てdouble型にして、変数は、全てheapメモリ
から確保することが主原因の一つです。それだけでC++の数十倍以上遅くなっています。
あなたの考えてことは、JavaScriptをさらに遅くするような結果となるでしょう。
570: 2019/11/07(木)04:18 ID:+N3PsKU8(15/16) AAS
>>568
有りますが、C/C++、Java、PythonやJavaScript、Ruby、Java、Kotlinなどの
メジャー言語ではそのような方針はとっていません。
571: 2019/11/07(木)04:23 ID:+N3PsKU8(16/16) AAS
>>564
「その程度どまり」と言いますけど、あなたは私の作品を全く見てませんね。
全く発表してませんから。
572: 2019/11/07(木)05:42 ID:xrNXmkmc(1) AAS
スレ違いのバカ二人はどこかよそに行って気の済むまで殴り合ってきてくれ
573: 2019/11/07(木)06:22 ID:D8b5RtWG(1) AAS
> つまり全体が64bitで、仮数部が52bitです。仮数部が52bitなので、
> Numberを用いて正確に表せる最大の整数は、53bitで表せる数から
> 1引いた数になり、(2^53 ? 1) = 9007199254740991となります。
ひどい説明だな
どのくらいひどいかというと
WM_SYSTEMMENU並み
574: 2019/11/07(木)11:03 ID:JQdG/Jj/(1) AAS
公共の場で変数型のピロートークですか
575(1): 2019/11/07(木)11:05 ID:dB1QBGXo(1) AAS
>>545
size_t 使え
576: 2019/11/07(木)11:27 ID:nSoHFrko(1/2) AAS
>>575
NULLは0だから〜
site_tはどうせintだから〜
こういう馬鹿なハケンが一人いると崩壊するよね
577: 2019/11/07(木)12:11 ID:sEmiRyTj(15/15) AAS
とか言うやつほどnullptrのことを知らなそうｗ
578: 2019/11/07(木)12:17 ID:9pMbL+ZJ(1) AAS
（´∀｀）＜ぬるぽ
579: 2019/11/07(木)17:55 ID:7K0XtVuo(2/2) AAS
#ifdef _WIN64
#define BOOLX64 INT_PTR
#else
#define BOOLX64 BOOL
#endif
BOOLX64 CALLBACK Dlg(HWND hw, UINT msg, WPARAM wp, LPARAM lp)
こうやって回避してるわ
580: 2019/11/07(木)18:14 ID:2gAeIIzZ(1/3) AAS
Windowsのデータ型だけのヘッダファイルって無いかしら？
データ型はあちこちで使わざるを得ないから、あちこちでincludeしたいけど、
APIのヘッダファイルはincludeしたくない。
APIを直接使うのは面倒だから、全部ラップしてるんだよね。
だから他からは使えないようにしたい。
581(1): 2019/11/07(木)19:03 ID:+mjs9icr(1) AAS
データ型もラップしとけよ
582: 2019/11/07(木)19:07 ID:2gAeIIzZ(2/3) AAS
>>581
どうやってラップすればいいですかね？
583: 2019/11/07(木)19:16 ID:2gAeIIzZ(3/3) AAS
なんとなくわかったからいいやｗ
584: 2019/11/07(木)21:31 ID:6aSe0RTj(1) AAS
横にそれるが
データ型もAPIの一部だと思ってるがあってるよな？
585: 2019/11/07(木)21:47 ID:nSoHFrko(2/2) AAS
アプリケーション独自の型なんか知りませんがな
586: 2019/11/07(木)23:33 ID:rEYaLqlI(1) AAS
個人的には構造化したほうがやりいいかな
587: 2019/11/08(金)03:59 ID:ksOnEph7(1) AAS
お前らMFCでも使ってろ
588: 2019/11/08(金)04:54 ID:2aYByRbi(1/2) AAS
普通のアプリならMFCが一番だと思うんだがなあ
変に角を丸くするとか透明にするとかされても使いにくいだけだろうに
589: 2019/11/08(金)05:57 ID:bt2cbsd4(1/2) AAS
むしろMFC = 角を丸くするとか透明だろ
MFC以外でそんなの見たことないわｗ
590: 2019/11/08(金)07:30 ID:D1bzmSlR(1/2) AAS
あんまりMFC関係なくね？
WS_EX_LAYEREDもSetWindowRgnもAPIを陽に意識して使うわけで
MFCはラッパーとしての薄さがありがたいだけやん
591(1): 2019/11/08(金)07:52 ID:tDaXxZK7(1) AAS
MFCはかゆいところに手が届かないからな
廃れたWTLがいい
592: 2019/11/08(金)09:32 ID:MipGbP9q(1) AAS
>>591
WTLは廃れてないよ。今もちゃくちゃくと最新コードがコミットされ続けている。現時点で2019年11月3日(日)が最終更新。
外部ﾘﾝｸ:git.code.sf.net
593: 2019/11/08(金)11:37 ID:bt2cbsd4(2/2) AAS
廃れたかどうかは、使ってる人がいるかどうかであって
作っている人がいるかどうかではない
594(1): 2019/11/08(金)12:13 ID:xtk88Sle(1) AAS
俺が使ってるから廃れてないぞ
595: 2019/11/08(金)12:17 ID:2aYByRbi(2/2) AAS
>>594
ちょと見せてみて？
596: 2019/11/08(金)13:27 ID:D1bzmSlR(2/2) AAS
あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ
597: 2019/11/08(金)13:56 ID:1R79qYgq(1) AAS
ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ
598: 2019/11/08(金)21:00 ID:lpVjWTGo(1) AAS
TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう
外部ﾘﾝｸ:social.msdn.microsoft.com
599: 2019/11/08(金)21:14 ID:sQQR9KNr(1) AAS
TOPMOST同士があるからな
600: 2019/11/09(土)13:55 ID:hHKZwsDl(1/2) AAS
タスクマネージャもよく後ろに移動する時あるけど何なのあれ
601: 2019/11/09(土)14:13 ID:BZG37V3w(1) AAS
API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる
602: 2019/11/09(土)15:42 ID:01iIJK4d(1) AAS
タスクバーより手前にくる時もある
別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある
603: 2019/11/09(土)17:34 ID:GyhiHYRD(1/2) AAS
もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？
毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね
それなら諦めてGetPixel使いますが
604(1): 2019/11/09(土)17:44 ID:HanEs9+F(1/2) AAS
アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね
Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど
605: 2019/11/09(土)17:56 ID:HyuDdIlK(1/2) AAS
TOPMOSTなんて思い上がった言葉ですぐ気がつけよ
スレッドの優先度でさえ最優先ではなくタイムクリティカルだろうが
606(1): 2019/11/09(土)18:03 ID:GyhiHYRD(2/2) AAS
>>604
こりゃ失礼、ありがとうございます
なんか昔いじった気がしたんですが、あれはオフスクリーンバッファだったか……
PC98じゃあるまいし、言われて見りゃ無理くさいすね
画面上の変化を監視して作業自動化する様なのを頼まれたのですが、
監視するべきは数ピクセルなので、おとなしくGetDC(nullptr)からGetPixelします
607: 2019/11/09(土)21:35 ID:hHKZwsDl(2/2) AAS
GetPixelって内部でどうやってるのかな
毎回呼び出すと遅いんだよね
608: 2019/11/09(土)22:19 ID:HyuDdIlK(2/2) AAS
故意に減速してるようだね
ビットマップオブジェクトにキャッシュしといて
そこから取ると普通の速度になる
609: 2019/11/09(土)22:41 ID:e6n/6jzv(1) AAS
gnsk
610: 2019/11/09(土)23:25 ID:HanEs9+F(2/2) AAS
仮にVRAMから1ピクセルだけ毎度読み戻してたらそらクソ重いやろとは思うが
今のDWMってGDI周りの扱いがどうなってんのかよくわかんねえからな
611(1): 2019/11/10(日)06:21 ID:nWjdF62e(1/2) AAS
XPでは爆速だったのがVistaから突然遅くなった
612: 2019/11/10(日)09:02 ID:R9o6dqtJ(1/2) AAS
TOPMOSTの競合の話ではない
"ごく稀に TOPMOST ウィンドウが通常のウィンドウの背面に移動してしまう現象が発生するとお問い合わせいただいています。"
"•Windows 8.1 以降、Windows 10 でも数十回に 1 回程度この現象が発生します。"
613(1): 2019/11/10(日)09:11 ID:IRh+3wYd(1/2) AAS
>>611
メモリー積め
ってかPC買い替えろ
614(1): 2019/11/10(日)09:22 ID:nWjdF62e(2/2) AAS
>>613
GetPixelの話だよ？
615(2): 2019/11/10(日)10:13 ID:2HW6YGp5(1/2) AAS
それはAeroのせいかも知れない。
色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって
いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、
その場所に重なっている全ての Window の色が分からないと、画面に表示される
色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、
各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの
ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、
アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
再描画をさせるのが伝統的やり方。
このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、
省2
616: 2019/11/10(日)10:14 ID:2HW6YGp5(2/2) AAS
>>615
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、
617: 2019/11/10(日)10:48 ID:IRh+3wYd(2/2) AAS
>>614
ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね
Windows 7から改良されたからマシになってるはず
618(1): 2019/11/10(日)11:26 ID:GjrjejsC(1/3) AAS
aeroで半透明になるから描画に時間かかる←わかる
だからgetpixelに時間かかる←う〜ん
呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
619: 2019/11/10(日)11:30 ID:42Oft6n8(1) AAS
getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い
個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い
個別の描画内容は多分システムメモリ上にある
大体そんなような動作っぽい
getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな
620: 2019/11/10(日)12:37 ID:R9o6dqtJ(2/2) AAS
> 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
1x1のビットマップに転送して取得しているのでxpでも遅かった
621: 2019/11/10(日)13:55 ID:fP398yW4(1/3) AAS
>>615
> そのWindowにWM_PAINTメッセージを送って、
> アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
> 再描画をさせるのが伝統的やり方。
> このやり方に従っているなら
もうやってないというか「重なり」なんて概念がないよ。
動画再生して、他のウインドウの後ろに隠して、
その状態でタスクバーにマウス乗せてみ
画面に表示されてなくても、ウインドウの中身は更新されてるからさ。
最小化したときはアプリ側で描画止めてるソフトが多いけど
省3
622: 2019/11/10(日)13:57 ID:fP398yW4(2/3) AAS
>>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された
623: 2019/11/10(日)14:11 ID:hRll0rFL(1) AAS
>>606
GetDC GetPixel で取れない場合
外部ﾘﾝｸ:maverickproj.web.あれ.com/d3d11_04.html
外部ﾘﾝｸ:ka-ka-xyz.はて？.com/entry/20101209/1291890231
外部ﾘﾝｸ[html]:codeday.me
624: 2019/11/10(日)14:11 ID:O4L9SaaX(1) AAS
GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。
625: 2019/11/10(日)14:17 ID:fP398yW4(3/3) AAS
昔はVRAMにあったものがGPUのメモリにあるわけだからね。
通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。
だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。
626: 2019/11/10(日)15:48 ID:GjrjejsC(2/3) AAS
でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
627: 2019/11/10(日)15:51 ID:u8+xJCBj(1) AAS
同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
628: 2019/11/10(日)16:09 ID:GjrjejsC(3/3) AAS
もう滅茶苦茶だなｗ
そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ
で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ
629: 2019/11/10(日)16:51 ID:invbJGJm(1) AAS
Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど
630(3): 2019/11/12(火)19:29 ID:fqP05o8Z(1) AAS
HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。
631: 2019/11/12(火)19:33 ID:R9AMJEW8(1) AAS
>>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。
632: 2019/11/12(火)20:44 ID:mKGma296(1) AAS
>>630
SetWorldTransform
633: 2019/11/13(水)10:09 ID:OceCV+VL(1) AAS
DirectX使えば自由
634: 2019/11/19(火)11:11 ID:NEogfZFa(1) AAS
いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。
635: 2019/11/25(月)20:46 ID:0q+n1Hac(1) AAS
Windows10 での symlink
外部ﾘﾝｸ:social.msdn.microsoft.com
636: 49 2019/11/25(月)22:38 ID:dg2mzwJY(1) AAS
>>630
GDIPlusは駄目なん?
637: 蟻人間 ◆T6xkBnTXz7B0 2019/11/25(月)22:53 ID:S0HuE7/3(1) AAS
StretchBltでマイナスの値を指定するとミラーリングできるらしい。
外部ﾘﾝｸ[php]:forums.codeguru.com
638(4): 2019/11/26(火)00:15 ID:FXTOqUMb(1/5) AAS
どっかで阿鼻叫喚が始まる予感
Twitterﾘﾝｸ:MurakamiShinyu
Twitterﾘﾝｸ:5chan_nel (5ch newer account)
639(2): 2019/11/26(火)09:59 ID:c3SEnPpX(1) AAS
お
いよいよcp932ともおさらばか
試行錯誤はあっても良い流れは認めよう
問題が出たら出たで治せば良いんだから
治す範囲がどんだけあっても諦めるな
なにもやらないよりまし
640: 2019/11/26(火)10:49 ID:LSm6MssX(1/2) AAS
一年前以上からあるオプトイン設定の話だが
641(1): 2019/11/26(火)11:36 ID:fVihpbt7(1/4) AAS
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
上下前次1-新書関写板覧索設栞歴
あと 361 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s