Win32API質問箱 Build126

**デフォルトの名無しさん** · 2020/05/01(金) 22:16:51.96

Win32APIについての質問はこちらへどうぞ。

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

■過去スレ
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2019 Part4 https://mevius.5ch.net/test/read.cgi/tech/1585715794/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2020/05/01(金) 22:19:24.75

■番外編
WindowsDDK各種についてのスレ
https://mevius.5ch.net/test/read.cgi/tech/1049116134/
D言語 Part35
https://mevius.5ch.net/test/read.cgi/tech/1571979866/
Cygwin + MinGW + GCC 相談室 Part 8
https://mevius.5ch.net/test/read.cgi/tech/1411399211/

**デフォルトの名無しさん** · 2020/05/01(金) 22:21:36.71

■ネイティブなやつとか
【GUI】wxWidgets(旧wxWindows) その5【サイザー】
https://mevius.5ch.net/test/read.cgi/tech/1270793556/
【Win/Mac/Linux/Android/iOS】 Qt 総合スレ 19
https://mevius.5ch.net/test/read.cgi/tech/1571891527/
●●●●TCL/TKなら俺に聞け 4●●●●
https://mevius.5ch.net/test/read.cgi/tech/1375678740/

**デフォルトの名無しさん** · 2020/05/01(金) 22:26:39.20

■需要あるかしらん
VRプログラム雑談【Unity/UnrealEngine】【HTC Vive/Oculus Rift/その他VR】
https://mevius.5ch.net/test/read.cgi/tech/1478142101/
OpenGL 2.0 専用スレ
https://mevius.5ch.net/test/read.cgi/tech/1126268759/
【boot】nasm【loader】
https://mevius.5ch.net/test/read.cgi/tech/1377053129/
nim
https://mevius.5ch.net/test/read.cgi/tech/1519896738/
Gtkプログラミング on Windows!!!
https://mevius.5ch.net/test/read.cgi/tech/1147024203/
Borland C++ Compiler オ　ワ　タ
https://mevius.5ch.net/test/read.cgi/tech/1206951221/

**デフォルトの名無しさん** · 2020/05/02(土) 14:36:08.36

MemoryMappedFile で造ったファイルのパスとかファイル名を取得する方法はありますか？

**デフォルトの名無しさん** · 2020/05/03(日) 07:50:20.86

991 蟻人間 ◆T6xkBnTXz7B0 sage ▼ 2020/04/07(火) 19:03:16.48 ID:qBIbpTMr [1回目]
https://archive.org/details/NTDocumentation/mode/2up

992 デフォルトの名無しさん ▼ 2020/04/07(火) 19:09:20.97 ID:G5F9VLMp [1回目]
>>991
下部の他のリンクが色々あるね

**デフォルトの名無しさん** · 2020/05/03(日) 09:53:31.92

GJ（袖の下）

**デフォルトの名無しさん** · 2020/05/03(日) 17:24:33.80

>>5
https://github.com/katahiromz/Handles

**デフォルトの名無しさん** · 2020/05/04(月) 03:41:12.64

MoveFileって同一ドライブであればディレクトリも移動できたんだな
エクスプローラーだと一瞬だし何かおかしいと思ってたが
今まで再帰で糞真面目に移動してた

>Windows NT/2000：この関数の ANSI 版では、名前は最大 MAX_PATH 文字に制限されている。
>この制限をほぼ 32,000 ワイド文字へ拡張するには、この関数の Unicode 版を呼び出し、パスの前に "\\?\" という接頭辞を追加する。
これも知らなかった
ファイラーとか作ってる人ってこの辺ちゃんと処理してる？

**デフォルトの名無しさん** · 2020/05/04(月) 03:41:23.17

MoveFileって同一ドライブであればディレクトリも移動できたんだな
エクスプローラーだと一瞬だし何かおかしいと思ってたが
今まで再帰で糞真面目に移動してた

>Windows NT/2000：この関数の ANSI 版では、名前は最大 MAX_PATH 文字に制限されている。
>この制限をほぼ 32,000 ワイド文字へ拡張するには、この関数の Unicode 版を呼び出し、パスの前に "\\?\" という接頭辞を追加する。
これも知らなかった
ファイラーとか作ってる人ってこの辺ちゃんと処理してる？

**デフォルトの名無しさん** · 2020/05/04(月) 03:42:02.69

2重に書き込んじゃった
なんかごめん

**デフォルトの名無しさん** · 2020/05/04(月) 04:51:07.67

はい
ttps://m.facebook.com/dnobori/posts/2142836202459674

◆QZaw55cn4c · 2020/05/04(月) 09:21:39.93

>>9
私も最近知ったので、xcopy を書き直して日々の作業につかっています
https://mevius.5ch.net/test/read.cgi/tech/1434079972/53

**デフォルトの名無しさん** · 2020/05/06(水) 16:46:07.85

GetQueueStatus() API って Windows10（もしかすると 8）以降
動作が遅くなってない？
（未だに VB6 で作成したソフトをメンテナンスしている関係で調べてたら、
DoEvents より遅くなっていることに気が付きました）

**デフォルトの名無しさん** · 2020/05/06(水) 16:50:51.19

>>14
それとも、64bit OS だからでしょうか？
（Windows10 の方は 64bit です）

**デフォルトの名無しさん** · 2020/05/06(水) 17:20:26.54

連投すみません。
64bit OS だから遅くなるということはないですよね・・・
g++ で簡単な速度計測用のプログラムを使って確認してみました所、
Windows7 と Windows10 では、約 6 倍くらい速度差がありました。
（まさか、Windows10 で遅いのは、Windows Defender が原因だったりして・・・）

**デフォルトの名無しさん** · 2020/05/07(木) 10:15:27.49

まさかWindows10のデフォルトの電源モードが省電力になってるのを知らないとか

**デフォルトの名無しさん** · 2020/05/07(木) 11:13:42.62

基本的なことかもしれませんが、教えてもらいたいことがあります。
Win32APIで作成中のゲームで、ウィンドウを最小化してみてタスクバー格納してみたら、
画像の背景部分の画像が消えて、背景が真っ白になってしまいました。

もとのプログラムでは、背景画像の描画時に
InvalidateRect(hWnd, NULL, FALSE);
と第3引数FALSEで背景画像を残しているつもりなのですが、
どうやら再描画の際に、TRUEで再描画してしまっているので白い背景に置き換わるのかと（予想ですので、正しい保証はありません）。

最小化しても、画像を保存する方法を教えてください。

タスクバーに格納中の状態にマウスを合わせて内部表示させてみたところ、
格納中のときは背景を表示できてるようです。
タスクバーから出した時に、背景が消えてしまいます。

なお、画面のチラツキを防ぐために背景描画時にオフスクリーン（裏画面）をしています。

**デフォルトの名無しさん** · 2020/05/07(木) 11:31:50.93

心当たりがあるならやってみろよω

**デフォルトの名無しさん** · 2020/05/07(木) 11:43:40.94

自分のプログラムじゃなくてOSからの再描画要求でWM_ERASEBKGNDも走って
ウィンドウクラスのブラシでクリア（既定の動作）されてるパターンじゃねえのん

**デフォルトの名無しさん** · 2020/05/07(木) 13:19:26.03

>>20
とりあえず
case WM_ERASEBKGND:
return 1;

case WM_PAINT:
（以下略）
ってコード追加して試してみたけど、改善しなかったです。

ウィンドウクラスをどう変更すればいいか、ワカラナイです。

**デフォルトの名無しさん** · 2020/05/07(木) 13:30:27.13

InvalidateRectに関係なく、描画が必要な際にWM_PAINTが送られてくる。
BeginPaintで描画が必要な領域を調べてその後自分で描画する必要がある。

InvalidateRectは再描画したい部分を指定するために存在し、第3パラは
単純にその際に消去するかどうかを指すのみ。

今回のはタスクバーから出したときにOSが再描画しろと仰ってWM_PAINTを発行してるから従いなさい。

**デフォルトの名無しさん** · 2020/05/07(木) 13:57:37.73

ここ数年触ってなかったけどなーんかWM_ERASEBKGNDの挙動が変わってるような気がするなあ
こんな役に立たなかったっけ・・・？

>>18
とりあえずWNDCLASSのhbrBackgroundを0にすればOSによる背景消去は無視されると思うけどどうよ？

**デフォルトの名無しさん** · 2020/05/07(木) 14:27:53.31

>>18
それは最小化したときのWin32の昔からの挙動。
InvalidateRect() の bErase や WM_ERASEBKGND は、今残っている画像を
消すか消さないかを制御することはできるが、
ただそれだけのことで、消す以前に現実に画像が画面上に残っていない場合は、
消えたままとなる。

Windowsは、Aeroなどより前の時代、各Windowは原則的に仮想VRAMを持たずに
自分で実VRAMに描画する方針だったので、最小化して戻したときは、
自分で再描画しない限りは、デスクトップの画像か、背景色で真っ白に消された
状態で復帰するだけだった。

Aero以後は、仮想VRAMを持つモードがあるとされる。

**デフォルトの名無しさん** · 2020/05/07(木) 14:28:13.03

NGワードのテスト
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);

**デフォルトの名無しさん** · 2020/05/07(木) 14:30:50.43

NGワードで、結果が書き込めない。
投稿文の何がマズイかワカラン。

**デフォルトの名無しさん** · 2020/05/07(木) 14:35:05.81

とりあえず、
wcex.hbrBackground = 0;// (HBRUSH)(COLOR_WINDOW + 1);
と変えてみました。

ですが結果はタスクバーから出した際に再描画されてしまいます。

ですが、背景の色が黒に変わりました。（以前は背景が白で再描画でした。）

たまたま自作ゲームでは背景色が黒でしたので、これはこれで好都合かもです。

**デフォルトの名無しさん** · 2020/05/07(木) 14:35:46.38

>>25のコードがあったので、>>27のコードに変えてみた。
結果はダメだったです。

**デフォルトの名無しさん** · 2020/05/07(木) 14:46:04.24

NG ワードは、MANGO 板のスレで、絞り込みができる

cmd＠.exe
ls の特定のオプションとか

はてなブログのURL で、吸い込まれるような動きをしたら、絶対に続けて書き込んではいけない。
3日ぐらいアクセス禁止にされる

twitter の長いURL も、吸い込まれるものがあるとか

**デフォルトの名無しさん** · 2020/05/07(木) 15:30:22.36

>>22
>今回のはタスクバーから出したときにOSが再描画しろと仰ってWM_PAINTを発行してるから従いなさい。

ご指示の通りにして、とりあえず解決しました。

Windowsの場合、OSが割り込んで、むりやり画面クリアして再描画してしまう場合があることも意識して、
画像の描画プログラムを組み立てる必要もあるのですね。

処理を軽くしようとして、背景は1度書いたら背景フラグをオンにして再描画しないようにしてたのですが、
OS割り込みによる再描画を考慮してなかったので、
裏目に出てしまったようです。

**デフォルトの名無しさん** · 2020/05/07(木) 15:47:08.20

吸い込まれるってなんのことや

**デフォルトの名無しさん** · 2020/05/07(木) 16:15:55.38

>>30
OS割り込みというか、WM_SIZE メッセージが来たら、背景も何もかも
全部再描画するようにすれば良いだけ。

**デフォルトの名無しさん** · 2020/05/07(木) 16:18:19.91

>>32
なお、WM_SIZE が来ても、その場で本当に再描画するという意味ではない。
WM_PAINT つまり、MFC でいうなら、OnDraw() 関数の中で背景も何もかも
再描画されるように工夫する。
そのためには、何らかのフラグを用意して、普段は0にしておき、WM_SIZE
メッセージハンドラであるOnSize()の中で 1 にする。
OnDraw()関数の最後で0にする。

**デフォルトの名無しさん** · 2020/05/07(木) 16:56:41.22

>>31
描き込んでもレスに反映されないことがある
可笑しいと思ってもう一度そのまま同じ内容を描き込むと
そのままアク禁

**デフォルトの名無しさん** · 2020/05/07(木) 17:08:25.79

大きさ固定で BMP に描画
WM_PAINT は BMP を BitBｌt するだけ

大きさが変わったとき自分の意思で表示内容を更新する時は BMP をゼロから描画しなおす

WM_SIZINGで大きさが変わったを知って
見合ったサイズのBMPに作り直し→表示内容を更新

**デフォルトの名無しさん** · 2020/05/07(木) 17:33:56.09

VBAでAPI使ってるレベルの者だが、メモリDCからBitbltするだけじゃね?

**デフォルトの名無しさん** · 2020/05/07(木) 17:42:01.72

とにかく、最小化状態から通常状態に戻したときは、何もかもそれまでの描画が
失われるのは昔からのWindowsの仕様。
普段は高速化のため部分描画をしたい場合は、そうしておいて、WM_SIZEが
来た直後にだけは、なんとか色々な方法で工夫して全体描画すればよい。

**デフォルトの名無しさん** · 2020/05/08(金) 00:39:11.34

CreateWindow関数って存在しないの知ってる？これ豆な

**デフォルトの名無しさん** · 2020/05/08(金) 01:17:12.85

>>38
マクロでは存在している。
実際のDLL内での関数名は、Unicode版と非Unicode版でそれぞれ語尾にWとAが付くが。

◆QZaw55cn4c · 2020/05/08(金) 01:23:45.95

>>39
CreateWindow
って、ファイルシステムとは関係ないのに、どうして A と W を実装しているのでしょうか？

**デフォルトの名無しさん** · 2020/05/08(金) 01:51:09.10

>>40
結論的には、クラス名、Window名が CHARかWCHARかの違い。
今見てみたら、
1. CreateWindowA、CreateWindowWも、それぞれ、
　 CreateWindowExA、CreateWindowExW に置き変わるマクロである。

2. CreateWindowは、UNICODE マクロが定義されていれば、
　 CreateWindowW を通じて、CreateWindowExW に置き換わる。
　定義されていなければ、
　 CreateWindowA を通じて、CreateWindowExA に置き換わる。

3. A 系は、クラス名、Window名が、CHARへのポインタであるのに対し、
　 W 系は、クラス名、Window名が、WHARへのポインタである。

4. CreateWindow() や、CreateWindowEx() は、クラス名、Window名が、
　どちらも、TCHARへのポインタであるので、UNICODEマクロが定義されている
　かどうかで、それらの文字列がCHARかWCHARに自動的に切り替わる。　

**デフォルトの名無しさん** · 2020/05/08(金) 05:42:10.41

～Exって関数名、拡張は１回きりって浅はかな付け方を
よくここまで堂々とやるなって感心しちまう

**デフォルトの名無しさん** · 2020/05/08(金) 07:16:28.52

バージョン増えると後ろに2とか番号付くぐらい適当だよ

**デフォルトの名無しさん** · 2020/05/08(金) 08:24:01.23

なんなら***ExExもアリだからな
Exが一度だけという浅はかな固定観念に縛られていてはMSには成れないのさ

**デフォルトの名無しさん** · 2020/05/08(金) 08:34:41.07

GetTextExtentPoint32にもっとEx付けたい

**デフォルトの名無しさん** · 2020/05/08(金) 08:35:06.55

じゃあ逆にどうしろと？
eclipse のソースコードなんかでも、インターフェースはバージョン番号増やしてく感じだよ

IDocumentExtension
IDocumentExtension2
IDocumentExtension3
IDocumentExtension4

**デフォルトの名無しさん** · 2020/05/08(金) 10:55:14.01

IDocumentExtension98
IDocumentExtension98SE
IDocumentExtensionMe
IDocumentExtension2000
IDocumentExtensionXP

**デフォルトの名無しさん** · 2020/05/08(金) 12:40:05.23

IDocumentExtension7
IDocumentExtension8.1
IDocumentExtension10
IDocumentExtension2000
あれ？2000が一番新しいんかな？

**デフォルトの名無しさん** · 2020/05/08(金) 13:00:29.63

IDocumentExtension8.1って、ここだけメンバーなの？

**デフォルトの名無しさん** · 2020/05/08(金) 14:42:14.34

CreateWindowは元々これが実体
win98辺りでunicode対応となってから内部でAとWに分けられてって流れじゃなかったっけ

歴史長いんだからよっぽどの先見の明がないと名前の整合性なんて無理でしょ
内部の関数ならまだしも外部公開のAPIなんてね
名前や仕様がころころ変わって阿鼻叫喚になるよりマシ

**デフォルトの名無しさん** · 2020/05/08(金) 14:59:13.46

あったねー　MFC42.DLLだっけ？

**デフォルトの名無しさん** · 2020/05/08(金) 16:27:41.55

Aって ASCII の A ？
W は、 Wide の W ？
でいいんけ？

**デフォルトの名無しさん** · 2020/05/08(金) 17:08:17.38

ANSI かな

**デフォルトの名無しさん** · 2020/05/08(金) 19:58:44.84

>>50
win16(win3.1)では実態
win32(NT,95)でAとWに分割。マクロで互換性をキープ
ただし9xは殆どのW系を実装しておらず失敗する
win32cとか呼ばれてた

**デフォルトの名無しさん** · 2020/05/08(金) 20:55:35.84

文字コードの ANSI って、なんなんだろ

ASCII とか Shift-JIS とかだと分かるけど、
ANSI って言われると、…ん？ ANSI …？ってなる

メモ帳の ANSI って、Shift-JIS のことなんだっけ？
なんで Shift-JIS をこんなわけわからん名前にしてるんだろ

**蟻人間** ◆T6xkBnTXz7B0 · 2020/05/08(金) 21:14:31.19

ウィンドウズのマルチバイト文字列変換は、コードページ切り替えで実現している。
既定のコードページANSI (CP_ACP)は、日本語ウィンドウズでは932（Shift_JIS）に転送される。英語圏のウィンドウズでは1252などになる。具体的な値はGetACP関数で取得できる。

シフトJIS変換では、WideCharToMultiByteとMultiByteToWideCharの第一引数にCP_ACPではなく、明示的に932を指定した方がいい。

**デフォルトの名無しさん** · 2020/05/08(金) 21:16:27.83

ANSI・・・ JISと敵対する組織であり世界に暗躍するISO一味の筆頭
Shift-JIS・・・悪の秘密結社MSにより改造されたJIS

**デフォルトの名無しさん** · 2020/05/08(金) 21:18:08.68

>>54
CreateWindowは2000からAとWだね
95～98系はほぼUNICODE対応されておらず、リソースや文字列を扱うごく一部のしかない

>>55
ANSIがASCIIを制定
これをベースに各種ローカル文字コードが乱立
そしてUNICODEへ

**デフォルトの名無しさん** · 2020/05/08(金) 21:49:33.14

いい加減Aはサポートを打ち切っちゃえと思う
TCHARの為に無駄な手間が増える

**デフォルトの名無しさん** · 2020/05/08(金) 22:31:37.13

無理にTCHAR使わなくて良いんだよ
_Tも_Lも面倒なだけ

**デフォルトの名無しさん** · 2020/05/08(金) 22:37:21.10

自分でA環境切ってれば面倒は無いと思うが
AのAPI残してるからこそ生き延びてるレガシーアプリはまだ無視できねんじゃないかなあ
未だに日本語パスとかでコケるアプリがあるのはそのせいでもあるんだろうけど

**デフォルトの名無しさん** · 2020/05/08(金) 22:49:11.78

>>60
無理ではないけど...
Aを切ってくれないと思い切りが

そういえば
Wしか使えないWindowsが昔あったな

**デフォルトの名無しさん** · 2020/05/08(金) 22:50:57.33

CEとかだっけ

**デフォルトの名無しさん** · 2020/05/08(金) 22:52:30.48

おっ
よくご存じで

**デフォルトの名無しさん** · 2020/05/08(金) 23:52:07.44

レガシーな制御機器を扱うソフトからすると、OSでUNICODEに一本化されると困るというか面倒極まりない

**デフォルトの名無しさん** · 2020/05/09(土) 06:57:55.10

APIのA系がいらんというだけで
制御系は好きな文字コードでやれば良いんだよ

ファイルのアクセスや各種プロトコルでは
いろんな文字コードを使うはずで
全ての文字コード用に各種APIが対応してる
なんて必要は全く無い
変換APIだけ用意してくれれば良い

**デフォルトの名無しさん** · 2020/05/09(土) 11:08:41.27

>>66
言われてみればその通りやな

**デフォルトの名無しさん** · 2020/05/09(土) 11:14:28.38

OS側で文字を入力・加工したものを制御系に流す、又はその逆のことを全く考慮しないならそうだね

**デフォルトの名無しさん** · 2020/05/09(土) 11:39:49.17

でもUTF8って、マルチバイト文字じゃないの？
W系の関数ってUTF16だよね？

**デフォルトの名無しさん** · 2020/05/09(土) 11:56:33.06

UTF8とUTF16は表現が違うだけで空間は一緒やろ
(厳密には一対一ではない)

Shift_JIS と UTF16 とかで変換しようとすると化けたり欠けたりする
WideCharToMultiByte と MultiByteToWideChar の引数は UTF8 だけにするべき

**デフォルトの名無しさん** · 2020/05/09(土) 12:26:48.39

要求されているコード次第だろ。
SJISが必要な場面で変換できない文字が含まれていたならエラーにするだけ。

**デフォルトの名無しさん** · 2020/05/09(土) 12:29:46.42

Go は、ワイド・UTF-8。
Windows は、ANSI・CP932

だから、Windows のみ、変換が必要！

WSL なら、Linux/Windows間の変換を、Windowsが自動変換するだろ

**デフォルトの名無しさん** · 2020/05/09(土) 13:44:45.28

ちょっと前にWindows10がUTF8を使用する機能が追加されたと聞いたけど、あれはどういう仕組みなの？
開発するときはWCHARやW系の関数を使っててもいいの？

◆QZaw55cn4c · 2020/05/09(土) 13:53:34.15

>>73
＞Windows10がUTF8を使用する機能が追加された
設定で A 系がデフォで UTF-8 になると聞いています

**デフォルトの名無しさん** · 2020/05/09(土) 13:59:36.27

>>74
ということは、A系はなくすどころか、これから主流に戻っていくということ？

**デフォルトの名無しさん** · 2020/05/09(土) 17:38:12.35

内部はUTF16

**デフォルトの名無しさん** · 2020/05/09(土) 18:36:20.72

設定で変えないとな今だとちゃんとシステムがUTF8かどうか確認しないとバグるだろうなぁ。。。

**デフォルトの名無しさん** · 2020/05/09(土) 18:41:38.14

A系やWideCharToMultiByteを使ってかつsjisだと決め打ちしてるとバグるね

**デフォルトの名無しさん** · 2020/05/09(土) 20:45:09.00

聞いてるだけでよくわからなくなってくる
マルチバイト星人はこの先もしばらくは無駄な苦労をしていくことになりそう

**デフォルトの名無しさん** · 2020/05/09(土) 23:03:31.09

TCHAR はもういらない子

◆QZaw55cn4c · 2020/05/09(土) 23:48:55.23

>>80
mingw で提供されている <windows.h> は TCHAR を使っているから、おさらばするわけにはいかないでしょうね…
https://mevius.5ch.net/test/read.cgi/tech/1434079972/53

**デフォルトの名無しさん** · 2020/05/10(日) 00:10:35.50

マイクロソフトが提供為てるわけじゃないんだし知ったことかよ

**デフォルトの名無しさん** · 2020/05/10(日) 00:59:54.73

創造主は世界を A と W に分けた。

後の A&W である。

**デフォルトの名無しさん** · 2020/05/10(日) 07:07:50.16

>>70
> (厳密には一対一ではない)
UTF8 と UTF16 って符号化文字集合は同じだから全符号化表現が一対一対応するんだと思ってたわ
例えば何が一対一にならないん？

**デフォルトの名無しさん** · 2020/05/10(日) 09:57:36.15

同じ文字に複数の表現方法があるとか

**デフォルトの名無しさん** · 2020/05/10(日) 10:02:11.48

WinSockの話はこのスレであってる？
ブラウザを作りたいんだけど、書店で本を探しても無くってさ

**デフォルトの名無しさん** · 2020/05/10(日) 10:16:37.79

プロトコルはRFCをあたる
受け取ったデータの可視化やうそんこの文字指定から文字化け回避とか、そっちのほうは知らない

**デフォルトの名無しさん** · 2020/05/10(日) 10:18:22.51

>>86
自作ゲームに、将来的に通信対戦の機能とかをつけたいから。

**デフォルトの名無しさん** · 2020/05/10(日) 10:22:11.17

>>87
わかった。RFCを調べてみる。

あと、2ちゃんの別スレも見つかったから、それも調べてみる。
『ネットワークプログラミング相談室 Port30 [転載禁止]©2ch.net 』
https://mevius.5ch.net/test/read.cgi/tech/1414709836/

**デフォルトの名無しさん** · 2020/05/10(日) 11:03:37.16

フライドチキンはKFCでお願いします。

**デフォルトの名無しさん** · 2020/05/10(日) 21:18:11.74

筋トレやダイエットにはPFCバランスが大事らしい

**デフォルトの名無しさん** · 2020/05/11(月) 00:39:02.31

DFC
貧乳にアクセスするためのプロトコル

**デフォルトの名無しさん** · 2020/05/14(木) 17:10:26.05

32bit アプリサポート終了のお知らせ

**デフォルトの名無しさん** · 2020/05/14(木) 17:21:03.49

32bitOSが終わるだけでWOW64は無くならんと思うが

**デフォルトの名無しさん** · 2020/05/14(木) 18:11:15.76

それも時間の問題かも

**デフォルトの名無しさん** · 2020/05/14(木) 18:26:01.94

過去資産切り捨てるだけでメリット皆無
ってこの話題何回目だ

**デフォルトの名無しさん** · 2020/05/14(木) 18:27:58.15

コスト削減

**デフォルトの名無しさん** · 2020/05/14(木) 18:35:32.89

>>94
ということは16bitアプリ終了のお知らせってことか

**デフォルトの名無しさん** · 2020/05/14(木) 19:16:57.69

だね

**デフォルトの名無しさん** · 2020/05/14(木) 19:18:28.93

>>97
コスト削減どころかWindowsシェア削減になるね

**デフォルトの名無しさん** · 2020/05/14(木) 19:38:59.13

｢どころか｣
全然つながってない

32bitのシェアが減ればコストに見合わなくなるので
開発を打ち切るのは当然

それによってアプリ開発者も負担が減る

OSの64bit化で16bitを切ったのもそういう理由