[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
496: 蟻人間 ◆T6xkBnTXz7B0 2019/10/23(水)04:20 ID:DFr4VJRt(2/6) AAS
仮想フォルダならPIDLを使うのではないか？
497: 蟻人間 ◆T6xkBnTXz7B0 2019/10/23(水)04:23 ID:DFr4VJRt(3/6) AAS
PIDLとGUIDをどうやれば結び付けられるか？ え〜と
498: 蟻人間 ◆T6xkBnTXz7B0 2019/10/23(水)04:25 ID:DFr4VJRt(4/6) AAS
外部ﾘﾝｸ:stackoverflow.com
ここにヒントが。
499: 蟻人間 ◆T6xkBnTXz7B0 2019/10/23(水)04:32 ID:DFr4VJRt(5/6) AAS
落ちます。
500: 蟻人間 ◆T6xkBnTXz7B0 2019/10/23(水)04:40 ID:DFr4VJRt(6/6) AAS
仮想フォルダならレジストリを見る方法があるが、KnownFolderの方が正しい方法に思える。
501: 2019/10/23(水)04:47 ID:/s0IRa9G(4/4) AAS
WTL公式gitレポジトリにあるエクスプローラもどきアプリのサンプルが参考になるかも。
外部ﾘﾝｸ:sourceforge.net
502(1): 2019/10/23(水)12:55 ID:hZZQZDty(1) AAS
画面外のスクショが取れない件、1809からの挙動のようだねえ
外部ﾘﾝｸ:stackoverflow.com
503: 2019/10/23(水)12:59 ID:ou8vQa3g(1) AAS
>>502
日本語で
504: 2019/10/23(水)15:31 ID:J1BMEu9t(1) AAS
いや判るだろ
1809 update 入れた後に可笑しくなったんだろω
505: 455 2019/10/23(水)21:03 ID:i0lmBL5A(1) AAS
1809以降の挙動ならプログラムじゃなくてWindows側の問題みたいですね
BitBltだけじゃなくプレビューにも問題出てるからバグっぽいですし
そのうちアップデートで治ることを期待しつつプログラムでの対応は諦めます
いろいろ答えてくれた皆様ありがとうございました
506: 蟻人間 ◆T6xkBnTXz7B0 2019/10/23(水)22:21 ID:bxABcYeD(2/3) AAS
やっぱりKnownFolderから取得できた。
外部ﾘﾝｸ[cpp]:github.com
自由に使え。
507: 蟻人間 ◆T6xkBnTXz7B0 [age] 2019/10/23(水)23:01 ID:bxABcYeD(3/3) AAS
揚げ物
508: 2019/10/24(木)00:20 ID:ywNA7G1O(1) AAS
ありがとう。だがしかし別のアプローチで
俺が解決したい（本当の）問題は解決できていたのだよ
まあ誰かの役に立つだろうから放っておいたけどな
すまんなｗww
509: 2019/10/24(木)00:41 ID:Fw8n9fLr(1) AAS
アップデートで直るかっちゅーても挙動自体は描画の最適化とも言えるので仕様としてこのままいきそうだけどなあ
自作ので試してみたけどやはり一部でも画面外に出てると無効領域をクライアント全体と指定しても
強制的にクリップされたHDCが返ってくるね
BeginPaintだけじゃなくてWM_PAINT外でのGetDCでも同様
DXGI swap chainが出力先ならクリップされない
普段窓を画面外に追い出したままにするってことがないから気付かなかったなコレ
510(1): 2019/11/04(月)15:23 ID:/C5zJSxn(1) AAS
SetForegroundWindowでフォーカスを奪えない、
入力中にフォーカスが奪われるとウザいからWindowsが
奪えないようにしてるって話はよく聞くと思うけど
逆にエクスプローラが起動すると（バックグラウンドなのに）
フォーカスを奪ってくれて困ってるんだけど対応策ない？
ウザいんだがｗ
511: ◆QZaw55cn4c 2019/11/04(月)15:58 ID:fwURXfb5(1/3) AAS
>>447
さらに追試を重ねていました
悪いときは 10G, うまくいっても 5000G 程度（日によってばらばらです）で
FILE_END ができなくなる現象は、
FILE_END が悪いのではなく、システムで圧縮するように指定するとそういうことがおきることがわかってきました。
Windows もいろいろとあてにならない、もう linux に軸足を移そうか、と思案しています
512: 2019/11/04(月)16:19 ID:1IiqNDSP(1) AAS
>>510
SetFocus()を使うと好きなコントロールにフォーカスを与えることが出来る。
SetForegroundWindow()は余り効果が無い。
513(1): 2019/11/04(月)16:52 ID:KwYoxUXo(1/2) AAS
longポインタ引数にintポインタ渡して>>445みたいなトンチンカンな返答する人が何か言ってる
514(1): ◆QZaw55cn4c 2019/11/04(月)18:29 ID:fwURXfb5(2/3) AAS
>>513
>>445 を日本語に翻訳してみました。
外部ﾘﾝｸ: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) だからなおさら問題ないのです。
省3
515(1): 2019/11/04(月)18:55 ID:KwYoxUXo(2/2) AAS
>>514
445のどこがWindows環境？
516: 2019/11/04(月)19:29 ID:ex697rOI(1) AAS
DOS窓でprintf出力しながらWin32APIだって使えるからWin環境
517: 2019/11/04(月)20:03 ID:xxqq9QlV(1) AAS
LONGは、WPARAMやLPARAMと型変換する危険コードが多い気が。もちろん古いコードだけど。
518: ◆QZaw55cn4c 2019/11/04(月)20:32 ID:fwURXfb5(3/3) AAS
>>515
だから、あなたは 10 年 ROM ってなさい、ってさっき言ったでしょう？
519(2): 2019/11/04(月)23:46 ID:hiiCgg8I(1) AAS
ここはWin32スレなんだからWin64や総称であるWindows APIはスレ違い
32ビットの話だけしてろ
520: ◆QZaw55cn4c 2019/11/05(火)00:15 ID:SbnLKNM3(1) AAS
>>519
残念ながらその意見に賛同する人は少数派だと思いますよ
521: 2019/11/05(火)01:54 ID:RTdVMJgD(1) AAS
Win64APIなんてどっから出てきたの？
522: 2019/11/05(火)11:28 ID:f5fZl2jz(1) AAS
> 昔は DWORD (Double WORD) と定義されていましたが
LPARAMは 16bit,32bit共に LONG (符号付整数)
523: 2019/11/05(火)11:48 ID:McETm4vA(1) AAS
>>519
64bitプログラミングであっても使用するAPIは実体としてはWin32APIだぞ
Win64APIなんて実体はなく、論理的に実装区分として呼び分ける程度
つまりスレチでも何でもない
524(1): 2019/11/05(火)19:37 ID:wVD+ILW8(1) AAS
double wordが32bitだなんて本来word幅が16bitという前提の話でインテルなら80286までのはずが386でパスされathlon64で再びパスされるという異常事態が今も続いているわけなんだが
525(3): 2019/11/05(火)20:20 ID:Rmlz0hln(1/2) AAS
>>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）になったんだが
526: 2019/11/05(火)20:52 ID:mHpC8FDb(1/2) AAS
>>525
釈迦に説法ご苦労
527: 2019/11/05(火)21:08 ID:Rmlz0hln(2/2) AAS
釈迦は俺やしｗ
528: 2019/11/05(火)21:43 ID:mHpC8FDb(2/2) AAS
俺メインフレームでdiagnose命令とかいじくってて
別な案件でhdlでcpu書いたりしてるけど
529(1): 2019/11/06(水)01:32 ID:k1IDaN6Q(1) AAS
メインフレームw
何歳になってもイキリ小僧してるんだな
サルのパパとママはご存命かい？
530: 2019/11/06(水)02:20 ID:71FJFoA8(1) AAS
>>529
何イキっとんねん
531: 2019/11/06(水)04:07 ID:Z1mcKm+J(1/2) AAS
イキなりえなり
532(1): 2019/11/06(水)07:21 ID:cnDla3Ge(1) AAS
>>525
ソフト的なAPIの話に物理アドレス空間で語るバカ乙w
533: 2019/11/06(水)12:01 ID:o3tEvZiY(1/2) AAS
釈迦がどうかはともかく
>>525 が全くトンチンカンなレスであることは事実
いつものあいつだろ
534: 2019/11/06(水)15:05 ID:Z1mcKm+J(2/2) AAS
>>532
APIの話だというのなら、OSが16bitだろうが32bitだろうが
APIの仕様が代わるわけないんやで
異常事態でもなんでもなく、それが高い互換性の理由だ
535: 蟻人間 ◆T6xkBnTXz7B0 2019/11/06(水)15:13 ID:Z1hQUtYe(1) AAS
64ビット対応で
Get/SetWindowLongよりもGet/SetWindowLongPtrを使え。とか、
DialogProcの戻り値をINT_PTRにしろ。
とかの若干の変更点があるようだ。
536: 2019/11/06(水)15:19 ID:o3tEvZiY(2/2) AAS
HANDLEもこっそりtypedefに_PTR変えたんだっけ
537: 2019/11/07(木)01:18 ID:7K0XtVuo(1/2) AAS
ダイアログプロシージャの戻り値がめんどうなことになる
x86じゃBOOLだけどx64だとINT_PTR
でもVC6だとBOOLはintだという
538: 2019/11/07(木)01:32 ID:sEmiRyTj(1/15) AAS
歴史的理由で仕方のない面もあるが、
単一のソースで16bitと32bit、32bitと64bitでコンパイルできるようにしてきたから
型の実態は結局なんなんだ？って悩むことになってる。
もうそろそろネイティブ型だけを使えるようになってほしいが
そのために言語を変えるほうが楽だろうな
539: 2019/11/07(木)01:44 ID:ubAK6fog(1) AAS
intとlongのサイズ違うこともあるしな
c#みたいにint32みたいなの最初から用意しとけよ
540: 2019/11/07(木)01:48 ID:cfOynPV2(1) AAS
stdint.h使おう
541: 2019/11/07(木)02:23 ID:+N3PsKU8(1/16) AAS
前に聞いた話だと、大型機が64BIT化した後も、intは、32BITの事が多いらしい。
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
ちょと見せてみて？
上下前次1-新書関写板覧索設栞歴
あと 407 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s