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/

**デフォルトの名無しさん** · 2021/08/19(木) 01:26:06.58

>>725
＞実際にはコピーした後で削除している。
それは異なるドライブの場合だろ？
同じドライブの場合はファイルシステムの書き換えだけのはずだろ

**デフォルトの名無しさん** · 2021/08/19(木) 03:06:16.65

>>725-726
レスありがとうございます
質問が長くなったので要点を絞り込んだつもりでしたが、もう少し追記させていただきます

dst_pathはpathの拡張子のみを変更したものですので、同じドライブ・フォルダになります
また、MoveFileの仕組みは仰るような仕組みで理解しているつもりですが、renameでも解決しないのが理解に苦しむところです
（といってもrenameの実装がどうなっているのか知らないのですが）

この処理で行っていることは、テキストログ中の不要な行を削除したいということで、

【現在の処理】
Dを削除。
SをDに移動(実際はSをDにコピーしてSを削除)。
Dを読み込みながら、Sに新規書き込み（削除したい行を読み捨てながら）。

という単純なことを行っていますのでご提案そのままではだめですが

【修正案】
Sを読み込みながら、Dに新規書き込み（削除したい行を読み捨てながら）。
Sを削除。
DをSにリネーム(MoveFile/rename)。

が思い付くのですが、そうするとSを書き込んでいるところ（全く別の場所ですが）で
もしかしてエラーが出るようになるのではという不安があります

いっそのことMoveFileの代わりになるものを自分で作ることも思い浮かびますが、
そもそも論として今回のような処理でここまでするものなのか？
という疑問と疑心暗鬼に陥っています

**デフォルトの名無しさん** · 2021/08/19(木) 09:56:10.36

原因についてはわかりませんが。。。
MoveFile()代替として、ハンドル開いた状態でファイル名を変更する場合にはSetFileInformationByHandle()を使用する。

HANDLE h =CreateFileW(srcfilename, GENERIC_READ| GENERIC_WRITE| DELETE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
size_t fri_size =sizeof(FILE_RENAME_INFO)+(wcslen(dstfilename)+1)*sizeof(wchar_t);
FILE_RENAME_INFO *fri =(FILE_RENAME_INFO *)malloc(fri_size); memset(fri, 0, fri_size);
wcscpy(fri->FileName, dstfilename);
fri->ReplaceIfExists =TRUE;
fri->FileNameLength =(DWORD)wcslen(dstfilename);
fri->RootDirectory =NULL;
BOOL res =SetFileInformationByHandle(h, FileRenameInfo, fri, (DWORD)fri_size);
free(fri);
CloseHandle(h);

**デフォルトの名無しさん** · 2021/08/19(木) 18:37:22.67

>>724
fopenでのエラーを調べるならGetLastErrorじゃなくてerrnoじゃないかな？

**デフォルトの名無しさん** · 2021/08/19(木) 21:29:03.55

>>724
カーネル内でのリソース開放は即座に行われるとは限らない。
お触りしたプロセスがいなくなった後でもカーネルの中で残ることがある。
この場合は成功するまでfopen()するしかないね。

**デフォルトの名無しさん** · 2021/08/20(金) 01:37:15.55

皆さんありがとうございます

>>728
対象ファイルがテキストファイルで一行ずつの処理のため、CreateFile系では
fgets系のAPIがないのでそこまで自作する必要がある点で最終手段として取っておきたいと思います

>>729
内部でWin32APIを叩いているイメージがありましたが、確かに言われてみればerrnoを使うべきですね
そのようにしてみます

**デフォルトの名無しさん** · 2021/08/20(金) 01:39:08.93

>>730
本件とは別件で新たな質問になってしまいますが、

プロセスAでファイルAをunlinkで削除
WM_APPを別プロセスBにPostMessageで通知
プロセスBでファイルAを再作成（プロセスBが起動していなくても、起動時にファイルAが無ければ再作成）

という箇所があるのですが、要するにキャッシュファイル的なものを削除して別プロセスで再作成を指示するようなことをしています
ここも稀に（？）再作成で失敗することがあるので気になっていました

Windowsプログラミングにおいて、ファイルの削除や移動についてはその後ウェイトを挟むか、
ファイルの作成でエラーが出たらリトライを入れるというのは常識的なものなのでしょうか？

**デフォルトの名無しさん** · 2021/08/20(金) 07:19:25.62

確実に作りたければ、中間ファイル作るやろ

**デフォルトの名無しさん** · 2021/08/20(金) 07:42:41.01

まーた覚え立ての言葉使いたがる子供が

**デフォルトの名無しさん** · 2021/08/20(金) 09:25:06.01

>>732
常識って人それぞれだからなあ...
エラー終了して使用者に丸投げするか、どこまでリトライするか、
ウエイトするのかリトライするのかはプログラムの次第だし...

今回の件のように、直前に誰かがお触りしてるのが
確実なのであれば、リトライするかウエイト入れるのが
確実だと思うよ。

**デフォルトの名無しさん** · 2021/08/21(土) 10:35:42.11

>>724
closeしてないやん？

**デフォルトの名無しさん** · 2021/08/21(土) 10:38:21.22

>>731
CreateFile したハンドルを FILE * に変換したら fgets 使えるが

**デフォルトの名無しさん** · 2021/08/21(土) 10:40:30.17

>>732
>Windowsプログラミングにおいて、ファイルの削除や移動についてはその後ウェイトを挟むか、
>ファイルの作成でエラーが出たらリトライを入れるというのは常識的なものなのでしょうか？

根本的な思い違いをしているに一票

**デフォルトの名無しさん** · 2021/08/21(土) 11:38:33.02

>>736
>>724がfcloseしていないというならそもそもfopenしただけとも言えるわけで説明のために以降は省いているってわかると思うんだが
そもそもが閉じ忘れならMoveFileも失敗するだろう

**デフォルトの名無しさん** · 2021/08/21(土) 12:28:01.97

>>737
せやな

_osfhandleとかfdopenをキーワードにggr

**デフォルトの名無しさん** · 2021/08/21(土) 12:54:10.92

そこまでせんでもcreatefileしたハンドルで移動してから一旦閉じてfopenでよくね？

**ハノン** ◆QZaw55cn4c · 2021/08/21(土) 14:27:27.29

再現できる簡単なソースは公開可能ですか？

**デフォルトの名無しさん** · 2021/08/21(土) 21:53:40.08

>>741
今回の問題は、いったん閉じてもカーネルが握ってるのでfopen()できないって話で

**デフォルトの名無しさん** · 2021/08/22(日) 12:32:08.06

>>743
だからMoveFileを代替しても同じやんって話で

**デフォルトの名無しさん** · 2021/08/22(日) 14:46:53.71

MoveFileEx「あのっ」

**デフォルトの名無しさん** · 2021/08/22(日) 16:25:47.23

論理的に考えれば「カーネル」が
握るわけ無いだろう。
ゴルフか麻雀でもしているののか

**デフォルトの名無しさん** · 2021/08/22(日) 16:40:10.74

ロクに質問読まずにというか理解せずにレスしてる馬鹿は何なの

**デフォルトの名無しさん** · 2021/08/22(日) 17:05:53.52

747の同類かと

**デフォルトの名無しさん** · 2021/08/22(日) 18:03:47.50

>>732
環境依存なことを考えて戻り値確認するのは別にWindowsに限らないし、戻り値が正常でも外部デバイス相手だとドライバ次第なこともある
別件で、組み込みWindowsでユーザがアプリが正常終了してすぐに電源コード引っこ抜くから
キャッシュがHDDに書き込まれずに消えるって事例はあったな

**デフォルトの名無しさん** · 2021/08/23(月) 07:47:18.19

>>749
NAS関係でOK出ているのに書き込まれて
いないってのはあったな

**デフォルトの名無しさん** · 2021/08/25(水) 19:50:31.67

LoadLibraryとかGetProcAddressしたものは
必ずFreeLibraryしないといけませんか？
自分のプロセスが必ず終了するときにFreeLibraryせずに放置しても勝手に解放される？

**デフォルトの名無しさん** · 2021/08/25(水) 20:26:18.34

>>75
されるわけないだろ
OSがナイナイしてくれるだけ

**デフォルトの名無しさん** · 2021/08/25(水) 21:58:54.28

>>751
プロセスごと始末してくれるから放置で構わん

**デフォルトの名無しさん** · 2021/08/26(木) 05:00:21.78

変な日本語・・・

**デフォルトの名無しさん** · 2021/08/26(木) 16:28:52.50

こっちくんな

**デフォルトの名無しさん** · 2021/08/26(木) 17:50:13.63

やって来ました
メッセージボックスで「計算結果はXX」って表示したくて

1 LPCWSTR func() {LPCWSTR a = L"//計算結果の値"; return a;} //計算結果を文字列にして返す関数
2 //以下WinMain()内
3 LPCWSTR a = L"計算結果は";
4 LPCWSTR b = func();
5 LPCWSTR c = 文字列を連結する関数(a, b); //StringCchCatW(), lstrcatW()などを試したがだめだった
6 MessageBoxW(hWnd, c, L"タイトルバー", MB_OK);

と書いたが動かなかった・・・
まず、1行目の「L"//計算結果の値"」に計算結果の変数を入れる方法がわからない
そして、5行目のLPCWSTR型の文字列を連結する方法がわからなからない
一日の大半がエラーとのにらめっこに費やされて辛い・・・
頼む、手伝ってくれさい

**デフォルトの名無しさん** · 2021/08/26(木) 17:58:52.10

宿題スレ案件ですか？

**デフォルトの名無しさん** · 2021/08/26(木) 18:24:36.40

>>757
いや普通にニート

**デフォルトの名無しさん** · 2021/08/26(木) 18:27:20.48

>>756
Win32APIではなくC言語の文字列とポインタの違いを勉強するところからやり直し

**デフォルトの名無しさん** · 2021/08/26(木) 18:29:12.42

wsprintf

**デフォルトの名無しさん** · 2021/08/26(木) 19:08:13.70

ニートならできないことは諦めればいいんじゃね？

**デフォルトの名無しさん** · 2021/08/26(木) 19:18:34.62

>>756

1 void func(CString &str) { str = "計算結果の値" } //計算結果を参照型引数の str に返す関数
2 //以下WinMain()内
3 CString str1 = "計算結果は";
4 CString strKekka;
5 func( strKekka );　// strKekka に計算結果の文字列が入って返って来る。
6 CString str2 = str1 + strKekka;
7 str2 を wide 文字列に直して、wpszText に入れる。 // ここはやり方を調べる。
8 MessageBoxW(hWnd, wpszText, L"タイトルバー", MB_OK);

**デフォルトの名無しさん** · 2021/08/26(木) 19:19:53.55

>>756
自分がどう書いたのかソースそのまま出して

**デフォルトの名無しさん** · 2021/08/26(木) 19:21:59.37

普通にwstringベースで作れ。
win32のwchar_t*型渡すところで、data()やc_str()使え。

std::to_wstring で数値などなどメジャーな数値型はwstringになる。

最初はwin32の型に代替名つけまくりな文化は
一体なんの型だよって感じで戸惑うわな。

**デフォルトの名無しさん** · 2021/08/26(木) 19:22:39.20

>>762
以下の関数を使えば、7 は、
wchar_t *wpszText = ConvertAcpMbcsToUtf16(str2);
でいける。

wchar_t *ConvertAcpMbcsToUtf16( const char *pszStr )
{
　　// ワイド文字列(UTF16, unicode) へ変換後の文字列長を得る
　　int　　　　　　lenUnicode　　= MultiByteToWideChar( CP_THREAD_ACP, 0, pszStr, -1, NULL, 0 );
　　
　　// 必要な分だけワイド文字列(UTF16, unicode) のバッファを確保
　　wchar_t　　　　*pbufUnicode　　　　= new wchar_t [lenUnicode];
　　if ( pbufUnicode == NULL ) {
　　　　return　　NULL;
　　}
　　
　　// デフォルトコードページ(ShiftJISなど) からワイド文字列(UTF16, unicode) へ変換する :
　　MultiByteToWideChar( CP_THREAD_ACP, 0, pszStr, -1, pbufUnicode, lenUnicode );
　　
　　return　　pbufUnicode;

**デフォルトの名無しさん** · 2021/08/26(木) 19:24:55.54

>>765
訂正:
1. は代入文の最後にセミコロンが抜けていたので正しくはこう :
void func(CString &str) { str = "計算結果の値"; }

**デフォルトの名無しさん** · 2021/08/26(木) 19:30:35.44

おっと、最後、MessageBoxW ではなく、MessageBoxA を使っていれば、
7や >>765 の工程は不要で、
MessageBoxA(hWnd, str2, "タイトルバー", MB_OK);
だけでいける。

**デフォルトの名無しさん** · 2021/08/26(木) 19:32:37.80

なのでまとめると以下のようになる :

void func(CString &str) { str = "計算結果の値"; }

// 以下WinMain()内
CString strKekka;
func( strKekka );　// strKekka に計算結果の文字列が入って返って来る。
CString str2 = CString("計算結果は") + strKekka;
MessageBoxA(hWnd, str2, "タイトルバー", MB_OK);

**デフォルトの名無しさん** · 2021/08/26(木) 22:24:23.76

連結はstrcatかsprintf("%s%s", s1, s2 )のTCHAR(wchar_t)版でいけるやろ
あとLPCWSTRはポインタなので、ちゃんと割り当てしてなくて未初期化のままとかないだろうな？

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 02:18:22.79

LPCWSTRのCはCONST(定数)という意味だから、変更できない。WはWide、つまりUTF-16.
Win32をやる前にC言語の文字列処理をマスターしてくれ。
wsprintfは時代遅れ。バッファオーバーフローを避けるため、バッファサイズ指定できる<strsafe.h>のStringCch...関数群を推奨。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 02:34:26.66

ポインタ変数は実体を持たない。文字列扱うにはバッファが必要。動的にバッファを確保して楽したいなら、標準C++のstd::wstringか、MFC/WTLのCStringWを使う。
ただし、std::wstringを使う場合でC文字列が欲しい場合はc_str()メソッドを使う必要がある。下手な型キャストはケガのもと。

**デフォルトの名無しさん** · 2021/08/27(金) 07:26:15.44

WindowsでC/C++を学ぼうとすると、文字列の扱いは混乱するだろうね
OSを特定しない教科書に載ってるようなやり方もできるから心配するな
一応の結果の表示をできるようになったら、とりあえずその方法だけ使って次に進んで、一通り理解したらまた文字列処理に戻ってくるといいんじゃないかな

**デフォルトの名無しさん** · 2021/08/27(金) 07:43:07.26

ぎゃー
教えてくれたのに遅れてすまん
今からエディター起動する

**デフォルトの名無しさん** · 2021/08/27(金) 08:37:51.16

スレタイ読もうな？

**デフォルトの名無しさん** · 2021/08/27(金) 10:35:04.22

>>770-771
この段階の人には情報過多

**デフォルトの名無しさん** · 2021/08/27(金) 10:43:55.91

C言語の基礎からやり直せ、と助言するのが正しい

**デフォルトの名無しさん** · 2021/08/27(金) 11:25:56.35

付き合ってくれた人が多くて感謝！
上のコードで実験しながら知識の掘り下げも含めて少し調べてみる
ありがとうな
いつか立派なプログラマーになってこのスレで恩返しするわ（泣ける）

>>774
文字列の扱いがここまで面倒だとは思ってなかった
Windows APIの関数に適当に投げ込むだけだと思ってた

>>776
入門書は読んだだけで実作は先週始めた
（これ以上は理解が進まないので実作をすることにした）
まだ知識が実践で使えるように修正されてない状態
まあ知識もないんだが

**デフォルトの名無しさん** · 2021/08/27(金) 11:59:25.59

お前には完成する能力は無い

**デフォルトの名無しさん** · 2021/08/27(金) 12:35:37.97

先が思いやられるな
特にWin32APIにこだわる理由が無いならC#でやることをおすすめする

**デフォルトの名無しさん** · 2021/08/27(金) 18:42:32.62

特殊な理由でもない限りネイティブc/c++なんて使わんでいいよ

**デフォルトの名無しさん** · 2021/08/27(金) 19:44:48.26

Cだと、こんな感じかな
- - - - - - - - - - - - - - - -
LPCTSTR a;
int b;
TCHAR c[20];

a = TEXT("計算結果は");
b = 2;
wsprintf(c, TEXT("%s%d"), a,b);
MessageBox(NULL, c, TEXT("タイトルバー"), MB_OK);

**デフォルトの名無しさん** · 2021/08/27(金) 20:04:56.02

今でもTEXT()って要るの？

**デフォルトの名無しさん** · 2021/08/27(金) 20:22:50.96

なんでせっかくTCHAR使っててwsprintfやねん

**デフォルトの名無しさん** · 2021/08/27(金) 20:24:35.54

MBCSかUNICODE決め打ちならいらない
LPCTSTR,TCHARも同じ

**デフォルトの名無しさん** · 2021/08/27(金) 20:35:07.25

>>783
#ifdef UNICODE
#define wsprintf wsprintfW
#else
#define wsprintf wsprintfA

**デフォルトの名無しさん** · 2021/08/27(金) 20:36:31.85

>>783
wsprintfはTCHARでは

**デフォルトの名無しさん** · 2021/08/27(金) 20:36:59.87

>>785
つ >>760

**デフォルトの名無しさん** · 2021/08/27(金) 20:42:31.64

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 20:45:13.11

sprintf/swprintfはC標準。
wsprintfはWin32。
これはテストに出ないぞ！

**デフォルトの名無しさん** · 2021/08/27(金) 20:48:57.74

>>789
Win32apiのスレなので、それ以外の答えを
書いた奴全員アウトあるね

**デフォルトの名無しさん** · 2021/08/27(金) 22:20:01.88

>>786
TCHARはワイドとマルチバイトの両方なんだからwprintf決め打ちじゃなくて_tprintf

**デフォルトの名無しさん** · 2021/08/27(金) 22:35:10.18

>>791
wsprintfはTCHARでは

**デフォルトの名無しさん** · 2021/08/27(金) 22:53:41.84

>>782
これからWin32APIを理解し始めようと考えている人には、そうゆう疑問を持てるレベルにまで頑張って到達してほしいな、という思いでマクロ表記にしてみたよ。
実用上、必要か不要か・・・で言えば場合によるんだろうけど。
現時点でWin32API が内部で ANSI と UNICODE を明確に区別しているので、作法として気にする必要はあると思われます

**デフォルトの名無しさん** · 2021/08/27(金) 23:06:30.48

>>792
なんでだよｗ
wprintfはWCHAR

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:07:19.75

_T系の関数マクロは<tchar.h>で定義されていて、主にC実行時関数を振り分ける。これらはAnsi/Wideを振り分けるTEXT系とは別に分離された機構になっている。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:09:32.07

>>794
wprintfはC標準のワイド関数。
wsprintfはWin32関数でA/W版がある。
一文字違いに注意。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:18:41.05

UNICODEマクロでA/Wの振り分け。
頭に下線のついた_UNICODEマクロで_T系の振り分けができる。
これらはVisual Studioで適切にソリューション/プロジェクトの設定を行えば自動で定義される。
GCCやclangでは-municode をコンパイルオプションに追加する。

ただし、ユニコードプロジェクトではWinMainはwWinMainに切り替わるので注意しよう。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:22:46.33

ユニコードプロジェクトにせず、代わりにUNCODEマクロと_UNCODEマクロを定義済みにするというやり方もある。こちらはCMakeでよく使う。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:25:34.94

ユニコードプロジェクトではないときにUnicode のコマンドラインを取得したい場合は、GetCommandLineWと
CommandLineToArgvWと
LocalFree を使う。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:32:23.92

ミッキマウスミッキマウスミッキミッキマウス
天安門事件
旭日旗☀

**デフォルトの名無しさん** · 2021/08/28(土) 06:56:04.31

,>>798
まぁ今となってはWindowsのUTF16LEはUNCO(ウンコ)なコードだったな
2バイト固定で1文字ってのは、簡易な多言語対応とstrlen系の文字数計算に楽だったんだろうけどそれだけだろ

**デフォルトの名無しさん** · 2021/08/28(土) 08:30:55.56

サロゲートペアに対応したので、その文字数計算も単純にできなくなってしまった。
文字数計算がややこしいのはUTF-8もそうなので、UTF16～が全然ダメということではないが。

開発面では、将来的に UTF-16（IVS）が必要になってくると、UTF8でいいじゃん、ということになって。
Visual stduio のデフォルトが再度ANSI（UTF-8）に戻る可能性はある。
長い目でWin32APIを見るなら、ANSIアプリの構築方法も忘れないでおく必要はありそうだ

**デフォルトの名無しさん** · 2021/08/28(土) 09:06:21.83

アラビア語かなんか知らんが、サロゲートペアの問題ではなく、さらに
UTF32 では 2 文字(32BIT x 2) なのに、画面上では文字の上や下に斜線
が入るような文字がある。日本語の濁点のようなもの。サに点々を打ってザ
と書くようなのを、サ + ” みたいな二文字で表現するらしい。
そんなものまで日本人が対応しなくて良いと個人的には思ってる。

**デフォルトの名無しさん** · 2021/08/28(土) 09:09:13.47

UTF8 --> UTF16(サロゲートペア) --> UTF32 1 文字
の問題だけでなく、特殊な言語では、
UTF8 --> UTF32 2文字 --> 画面上では 1 文字
の問題が有るということ。
日本人が対応できるのは、UTF32 1文字が画面上で1文字に見えるまでが限界。

**デフォルトの名無しさん** · 2021/08/28(土) 09:33:08.48

KPS 9566-2000にはフル対応しる

**デフォルトの名無しさん** · 2021/08/28(土) 09:53:59.20

>>803
> サ + ” みたいな二文字で表現するらしい
Macってこれだよね
UTF-8-MACくたばれ

**デフォルトの名無しさん** · 2021/08/28(土) 10:02:21.59

>>779
C#だっておバンバン

**デフォルトの名無しさん** · 2021/08/28(土) 10:50:07.25

>>794
勘違いしましたごめんなさいは？ｗ

**デフォルトの名無しさん** · 2021/08/28(土) 12:21:19.46

>>803
>そんなものまで日本人が対応しなくて良いと個人的には思ってる。
欠けリンゴの世界ではそっち採用してるからファイル名の扱いとか厄介だよ

**デフォルトの名無しさん** · 2021/08/28(土) 13:14:56.03

>>801
MBCSのsjisとeucに戻りたいかというと、嫌かな(´・ω・`)
今の敵は絵文字

**デフォルトの名無しさん** · 2021/08/28(土) 13:29:17.35

中東とアメリカは中が悪いから、わざと変な文字コードにしたのかも知れんな。
経済的な敵である日本を倒すため、オートリピートなんてそもそも不要なIMEのON/OFF
キーに普通のアルファベットキーよりも開始時間の短いオートリピート機能を付けた
上に、現在のON/OFF状態を画面の右下の分かりにくい場所に小さく表示したりとか
と同じで。

**ハノン** ◆QZaw55cn4c · 2021/08/28(土) 14:51:45.63

>>811
政治の世界と商売の世界は違いますよ、商売のためならなんでもするのが商売人というやつですよ

**デフォルトの名無しさん** · 2021/08/28(土) 15:17:42.31

そして悪徳へ

**デフォルトの名無しさん** · 2021/08/28(土) 17:32:49.86

>>794
スレタイ３回音読してからごめんなさいは？

**ハノン** ◆QZaw55cn4c · 2021/08/28(土) 18:09:30.98

ワンワンワンごめんなさい

**デフォルトの名無しさん** · 2021/08/29(日) 01:17:36.66

どうでもいいけどオリパラのRPCはリモートプロシージャコールじゃなくてなんちゃってロシア
まめな

**デフォルトの名無しさん** · 2021/09/06(月) 20:30:01.34

ﾌﾌﾌﾌﾌ…で埋められたWin32アプリデバッグメモリを思い出した人、どのくらいいるかな

「フフフ…」4歳娘が撮影した花火に家族で爆笑! 見ると笑顔になる“奇跡の1枚”の状況を父親に聞いた | FNNプライムオンライン
https://www.fnn.jp/articles/-/224754

**デフォルトの名無しさん** · 2021/09/06(月) 20:54:15.47

0xABADBABE がwindows7のUSB
0xBAADF00D がlocal alloc

深淵に到達するとﾌﾌﾌじゃないのよ

**デフォルトの名無しさん** · 2021/09/09(木) 19:55:16.63

ｶｶｶ

**デフォルトの名無しさん** · 2021/09/10(金) 06:52:10.21

六歌仙のひとり

**デフォルトの名無しさん** · 2021/09/10(金) 11:54:52.84

Debugモードで実行すると配列の中身が「ﾌﾌﾌﾉﾌﾌﾌ」になってワロタ

**デフォルトの名無しさん** · 2021/09/10(金) 11:56:22.34

16進数で表示して英語で読んでみ

**デフォルトの名無しさん** · 2021/09/11(土) 21:33:34.97

INT3

**デフォルトの名無しさん** · 2021/09/11(土) 23:15:17.42

dabadabada

**デフォルトの名無しさん** · 2021/09/15(水) 09:50:59.74

HANDLE SetClipboardData(UINT uFormat, HANDLE hMem);
に渡すhMemは必ずGlobalAllocで確保したものでなくてはいけないのでしょうか？

mallocやnewやスタック領域のポインタを渡すとどうなるんでしょうか・・・？