パスワードを忘れた? アカウント作成
16379 story

Vistaでのゲーム開発で続発したトラブルの「笑えない原因」 114

ストーリー by GetSet
判ってみれば何でもないが、非常にありがち 部門より

あるAnonymous Coward 曰く、

GAME Watchの記事より。
Vistaでのゲーム開発においてIME関連のトラブルが頻発していたようだが、その原因の1つが「SDKのサンプルコードにバグがあり、開発者が知らずに使いまわしていた」ということだったらしい。
サンプルコードを作成してレビューしたマイクロソフト、知らずに使い回した開発者ともにミスがあったわけだが、とくに開発者の立場では、わかってはいても見逃しがちなミスではないかと思う。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2007年09月28日 22時39分 (#1225913)
    # タレコミ人です

    本文に自分の感想をつらつら書くのもアレだったので省きましたが、個人的には、スライド [impress.co.jp]にある
    動いていても信用ならない
    バグはコピペで広がる
    何かあるとOSのせいになる
    というのが印象的でした。最後のはともかく、上の2つは大変ごもっともで。

    また、本文には
    これまでのIMM32は、このフラグを親切にも無視し続けていた
    とありますが、どちらかというと「APIのバグを直したら、そのバグに依存して異常動作を免れていた他のコンポーネントが動かなくなった」という、これまたありがちな事態なのではないかと思います。
    • 類似の内容として、RegOpenKeyEx [microsoft.com]のsamDesiredを0に指定してたらWin9xでは動くのにNT系で動かないってのがありましたね。

      # ちゃんと引数が何を意味しているかや何を設定すべきか見直しましょうという事かっ
      --
      誰も信じちゃいけない、裏切られるから。
      私を信じないで、貴方を裏切ってしまうから。
      親コメント
    • by Anonymous Coward on 2007年09月29日 0時24分 (#1225981)
      セキュリティの重鎮、高木先生がPHPの教本のサンプルからセキュリティホールが広がる可能性を示したエントリを書かれたことがあります。

      プログラミング解説書籍の脆弱性をどうするか
      http://takagi-hiromitsu.jp/diary/20051227.html

      サンプルというのはその重要性とはうらはらに気軽に書かれ、そのくせ多くの人にコピペされて使われるものです。
      最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。
      親コメント
      • 最近はサンプルがサンプルであるがゆえにセキュリティ上脆弱であることを付記するドキュメントも増えましたが、これからは心あるプログラマは製品と同等にサンプルの品質にも気を配るべきなのでしょう。

        サンプルコードには目的があるので、その目的にどれだけ合っているかがサンプルコードの品質として非常に重要です。目的を無視して、そのまま使えるかどうかだけをサンプルコードの品質として見るならば、役に立つサンプルコードは書けなくなるでしょう。目的に合っているかどうかも含めて品質と呼ぶなら、サンプルコードの品質が重要なのはもちろんですし、これまでも重要性は認識されていたのではないでしょうか。

        例えば、 C 言語の入門書を最近手に取ったことがないのですが、 15 年ほど前の本では、最初の方に C 言語のプログラムの例として例えばこんなコードが書かれていることも珍しくなかったように思います (C 言語のプログラムの形に慣れてもらうとか、コンパイル・実行の仕方を説明するとか、入出力の方法を説明するなどの目的で)。

        #include <stdio.h>
        int main()
        {
            char name[50];
            printf("あなたの名前は何ですか? ");
            gets(name);
            printf("こんにちは、%sさん!\n", name);
            return 0;
        }

        後ろの章で文字列処理か入出力をきちんと取り扱う段階になって、初めて「じつは第 1 章に書いてあったプログラム 1.3 には問題があったのです」などと説明されるわけです。全部一度に説明しても理解できないので、これは悪くない方法だと思います。

        言語の入門書ではなくてライブラリーのドキュメントでも、サンプルコードでは目的が大事だというのは変わりません。 API 関数の呼び出し方の説明なら、その説明に特化して他の要素を無視した方が説明したい部分がわかりやすくなるというのはよくあることです。そのため、エラーチェックをしないコードが載ったり、そのまま使ったらセキュリティー的に大問題なコードが載ったりしますが、それが悪いことかどうかは状況によります。 (もちろん、目的がよくわからないサンプルコードというのも世の中にはたくさんありますが……。)

        Game Watch の記事にある DirectX SDK のサンプルコードの話は、記事によれば、コードを書いた側も正しく書いてあるつもりの部分がじつは間違っていたということのようで、「サンプルコードだからそのまま使えないのは仕方ない」という類のものではなさそうですが。

        親コメント
        • by Anonymous Coward on 2007年09月29日 8時38分 (#1226059)
          >後ろの章で文字列処理か入出力をきちんと取り扱う段階になって、
          >初めて「じつは第 1 章に書いてあったプログラム 1.3 には
          >問題があったのです」などと説明されるわけです。
          >全部一度に説明しても理解できないので、
          >これは悪くない方法だと思います。
          いえ、悪い方法だとおもいます。
          このような説明では「どこで読むのをやめてもOK」なものを
          示すべきです。
          他に書きようがないなら、せめてそこに脚注等をつけ、
          後まで読まないとまずいことを明示すべきでしょう。
          ユーザが後ろの章まで読まずに、この部分を
          そもままコピペしたらどうなるのでしょうか?
          さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか?

          良い説明を書くには、穴がないように細心の注意を払います。
          せめて教科書くらいは、そうあってほしいものです。
          親コメント
          • by Anonymous Coward on 2007年09月29日 10時31分 (#1226084)
            悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。

            その章では、まずは大雑把にCを理解しようとかだったかな?

            ##その本は、C言語とC++言語を熟知している人が
            書いたものだと感じた。
            親コメント
            • 悪い例を載せたページには「悪い実装例です詳しい話は後で説明します」とか書いてあったと思う。

              書いてあったかもしれません。憶えていません。

              このようなサンプルコードがどれか 1 冊の本に書いてあったという印象ではなくて、あちこちの本に書いてあったような印象がありますが、この点についても記憶に自信があるわけではありません。

              親コメント
          • いえ、悪い方法だとおもいます。
            このような説明では「どこで読むのをやめてもOK」なものを
            示すべきです。

            「べき」かどうかはスタンスの違いの問題です。僕は、入門書にもいろいろな種類があって良いと考えています。もちろん、どこで読むのをやめても間違った知識を持つことがないような入門書があっても良いですが、通読することを前提として、途中で読むのをやめたら間違った知識を持ってしまうかもしれないような入門書があっても良いと考えています。

            他に書きようがないなら、せめてそこに脚注等をつけ、
            後まで読まないとまずいことを明示すべきでしょう。

            それも、「明示すべき」かどうかはスタンスの違いです。そのような状況で脚注等を付けない著者がいても、悪いとは僕は思いません。

            ユーザが後ろの章まで読まずに、この部分を
            そもままコピペしたらどうなるのでしょうか?
            さらにそれが伝言ゲームで他人に伝わっていくとどうなるのでしょうか?

            仮にそうなってしまったら不幸なことですね。でも、入門書を途中まで読んだだけでプログラミング言語を理解できたと考えるような人には、その入門書は向いていなかったというだけのことです。そういう人もいるからというだけの理由で、すべての入門書はこうあるべきなどと規定するのは、つまらないと思います。

            親コメント
          • >いえ、悪い方法だとおもいます。
            >このような説明では「どこで読むのをやめてもOK」なものを
            >示すべきです。

            賛成です

            その部分だけ読んで使う人もいるでしょう、と言うより、かつて私もそうした覚えがあります。
            数百ページのネットワークプログラミングの本だったと記憶しています。

            締め切りが迫っていたら、本を全部読んでから実装なんてのんきなことやってられませんから。

            親コメント
    • by Anonymous Coward on 2007年09月29日 19時39分 (#1226207)
      > 「APIのバグを直したら、そのバグに依存して異常動作を免れていた

      Vista で とあるマイナーなAPI関数(複数の引数で呼び出す)が改訂されまして、
      これまで「Reserved なんで ゼロを指定しておくように」とされてた
      4つめの引数に意味が追加されました。

      その引数に設定するのは、とある Define値 2種のどちらかと規定され直しています。

      ところが! その引数にゼロが指定されてると、
      「不正な引数が設定されるのでエラー」
      となってしまうのです。

      誰だよ、 Vistaは XPと互換性があるって言ってたの。

      # セキュリティとか ユーザー権限とかとはまったく無関係なAPIなんだよ

      親コメント
    • by Anonymous Coward on 2007年09月28日 23時43分 (#1225963)
      ありがちだろうか。
      事態はもっと奇怪だよね。

      この部分、実はVista以前のずっと昔から間違ったまま放置されてきていたのだが、NyaRuRu氏によると「これまでのIMM32は、このフラグを親切にも無視し続けていた」ということだ。

       つまり、従来の環境ではプログラムが誤っているのにもかかわらず正常に動作してしまい、誰もバグに気がつかなかった。

      ・バグは昔からあった
      ・でもバグが露呈しないバグがあった
      ・バグが露呈しないバグを直したら、最初のバグが出て来た
      こうじゃないのか。2重のバグと言うべき。
      利用したプログラマがこれ→http://www.watch.impress.co.jp/game/docs/20070927/wv05.htm [impress.co.jp]を自嘲的に笑うところか怒るところかは議論があるだろうが。
      親コメント
    • by mitil (29556) on 2007年09月29日 2時59分 (#1226022) 日記
      えーと、だからプログラマーはマシン語を理解しておくべき? [srad.jp]とかいう話が出てきて(略

      # と話を蒸し返してみる。

      それはともかくとして、コンパイラーやフレームワークのバグに悩まされた私は、
      これからはライブラリーの中身にも悩まないといけないんですねorz
      親コメント
    • >何かあるとOSのせいになる
      これは、非常に納得できるような。
      「msが……」とか「winが……」という話ではなくて、
      トラブルの原因を、自分たち以外の何かに求める傾向というのは、あるような気がします。

      初めから、「自分の作ったコードにエラーが無い」と確信している人は居ないと思います。
      ですが、隅々まで把握できている(つもりの)自分のコードが、
      問題となっている現象を発生させない、という確信を持ってしまったら、
      「osのせい」とか「hwのせい」とか「隣のセクションが担当しているモジュールのせい」とか、
      自分以外の悪者をでっちあげてしまう事はよくあります。
      osって、そういう時に憎しみの対称にするには、手頃で便利なアイテムのような。
      悪口や罵詈雑言を言っても、聞こえる範囲に関係者は居ないし。
      「俺様はosにケチを付けられる程のスキル持ちなんだぜぇ」みたいな、自己拡大感も味わえるし。

      // そして「何をツボってるのさ?」と聞いてきた、通りがかりの同僚に、
      // 単純なスペルミスを指摘されてしまう罠。
      親コメント
      • >何かあるとOSのせいになる

        ちょっとオフトピ気味ですが、Microsoft 自身もこれは分かっているようで、下位互換性を維持するための涙ぐましい対処が Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング! (大型本) [amazon.co.jp] (THE OLD NEW THING - PRACTICAL DEVELOPMENT THROUGHOUT THE EVOLUTION OF WINDOWS の和訳。和訳タイトルは不適切だと思います) に載っています。そんなことまでやってるのかと思った一例を挙げておきます。

        「13.2 プログラムがドキュメントに載っていない構造に進入するとき」より
        [エクスプローラ] ウィンドウの振る舞いをシェル拡張から変更したいと考えたベンダーがいた。(中略)彼らはドキュメントに載っていないウィンドウメッセージを使用して、シェル拡張からエクスプローラの内部構造の1つへのポインタを取得した。(中略)
        ベンダーが認識したものと探していたものは、偶然にも多重継承クラスの基本クラスだった。複数の基本クラスを持つクラスがある場合、コンパイラがそれらの基本クラスをメモリに割り当てる順序は保証されない。たまたま、このベンダーがテストしたすべてのバージョンの Windows では、それらは X、Y、Zの順序で割り当てられていた。
        Windows 2000 を除けば。
        Windows 2000 のコンパイラは、X、Z、Yがその順序であると判断した。(中略)しばらくして、システムはクラッシュした。
        プログラムが (Yをつかむために) X を探しにいったら、最初に偽の X が見つかるように、「偽のX、Y」を作成しなければならなかった。
        その方法を考え出すために週の大半がつぶれた。

        親コメント
  • by Anonymous Coward on 2007年09月29日 0時39分 (#1225985)
    サンプルコードってのは説明のために冗長な書き方してたりして、ふつー、そのままじゃ使い物にならん。
    MSのサンプルだろうが、そのへんの技術サイトのだろうが、このへんは変わらん。
    だから実用コードにするにはひと手間入れるし、それでサンプルのバグだって気づく。

    コピペじゃスキルは上がらんよ。
    • by Anonymous Coward on 2007年09月29日 1時55分 (#1226010)
      いや、ゲーム業界のプログラマは、もはや全体的な質を把握できる人間がいないほど分業化されていて
      ハードのリッチ化に伴って構造が巨大化してるにも関わらず、リリース速度を落とすことが出来ない
      だから質が低下「した」のではなく、もともと低い、というか、そもそもプログラムで一生食べよう
      なんて思っていないバイトだから価値観が違うわけで、そういう人間しかいない万年デスマーチ体質になれば、
      「コピペしていたらスキルがつかない」とか、もっともな教訓のでる幕はないでしょうよ、と。
      親コメント
    • by Anonymous Coward on 2007年09月29日 9時25分 (#1226070)
      質問サイトで応答してみるとよく分かりますよ。
      おまえ・・・これ、業務用のプログラムそのものじゃないか?って思えるものから、時には会社名入っているコードまで貼り付けて教えて下さいとか・・・
      んで、「ここが違う」「ここを理解していないから勉強しなさい」って書くとキレられるんですよね。
      さらには、「親切なつもりのバカ」が現れてソースを貼り付けることも。

      こうして、プログラム=タダ、という意識とプログラマのスキルの低下が進むのよね。
      「親切なつもりのバカ」は、何も考えないで貼り付けてるんだろうけど。
      親コメント
    • そりゃまーそうですが、DirectXって2か月に一回アップデートがでて、そのたびに仕様が変わったり、新しい方法でやった方がよくなったりするんですよね。新機能なので詳細なドキュメントはアリマセンとか。

      理解してやりかた覚えて~とかのノウハウがアップデートのたびにマッサラにされたりするんで、コピペしたくなる気持ちがも分かるっていうか。
      親コメント
    • いくらコピペでもさすがに入力と出力でテストくらいはしてると思うのですが、
      この問題の本質は「サンプルコードがブラックボックス的に組み込まれている」点ではないでしょうか.

      サンプルコードの本質は、ある特定の処理方法の「やり方」を提示することであり、
      プログラマは本来、そこにある手順、ロジック、変数等の意味を理解しないといけません.
      理想は理解した上でコードを自作して動作を検証することですが、急ぎ仕事でコピペする場合でも
      上記理解は必須だと思います.

      それを、わからない変数やフラグをそのままでコピペするから今回のような問題が起こる.
      そういう意味では、プログラマの質の低下は結構深刻なのかもしれません.

      # テストで漏れてるのも問題っちゃ問題ですが、それはまた別の話.
      親コメント
    • しかし、NyaRuRu氏ですらおそらくコピペ [hatena.ne.jp]と言及されてますし・・
      親コメント
  • 実に喜ばしいことだ! (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2007年09月28日 22時55分 (#1225922)
    何にしてもVistaのバッドニュースはマカーにとっては実に喜ばしいことだ!がはははは!



    MacOS X にもゲーム一杯出てクレヨン....orz
  • VB付属のセットアップ用プログラムがバグってて2バイト文字絡みの不具合が出る [microsoft.com]
    ATL使って2バイト文字パス使うと環境によって不具合が出る [microsoft.com]
    なんかがありました。

    # Setup1.exeはその他のOffice Developer版とかも同じバグ持ちだった気がする。
    --
    誰も信じちゃいけない、裏切られるから。
    私を信じないで、貴方を裏切ってしまうから。
  • by gonta (11642) on 2007年09月29日 13時28分 (#1226113) 日記
    MSのサンプルコードなんて、そんなもんすよ!という意見が多く見られますが本当ですか?

    昔、趣味でMacOSのプログラミングをやってました。InsideMacやプログラミング本を参考にいろいろやっていましたが、InsideMacなんてそのままじゃ絶対に動かない。「概念の」コードとか、前後にいろいろ付加してはじめて動くコードとか。

    Win32もつまみ食いしましたが、そっちは一発で動く。やっぱりシェアが広いと需要もそれだけあり、書籍・サンプル類が充実するんだな、うらやましいな、と思った記憶があります。正直びっくりです。
    --
    -- gonta --
    "May Macintosh be with you"
    • そうですね。おまけにPascalでクロージャ使ってるのとかはそのままC/C++に持っていけないし...。
      # 新し目のInsideMacintoshではC/C++のサンプルもありましたが...。&言語変換している点ですでにコピぺじゃないけど。
      もともとMac≒XLib, Windows≒XToolKitくらいのプログラムしやすさの差がありましたしね。Windowsの方が随分プログラマにとっての環境は良いと思いますよ。
      --
      Best regards, でぃーすけ
      親コメント
    • 元々の母数が多いのでトチってる絶対数も多いっていうオチな気もします。
      あとはCJKで使われる多バイト文字とかIME周りは向こうじゃ常用してる人の母数が少ないので問題が潰されにくいのかも。

      日本語のリファレンス周りも不完全とはいえ他環境と比較したら充実してますし、開発という点で見たらWindows環境は便利だと思いますよ。
      # ただし、日本語情報は稀に記号類が欠落したり古いとかあるので英語版も念の為に見た方が安心。
      # それでもゼロから英文で読まないといけないとかソースを読み解かないといけないわけではないので大分楽。
      ## もちろん、トラブル時はその限りじゃありませんし、MS側がミスる時もありますが。
      --
      誰も信じちゃいけない、裏切られるから。
      私を信じないで、貴方を裏切ってしまうから。
      親コメント
  • 何をいまさら、 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2007年09月28日 22時51分 (#1225919)
    MS のサンプルコードなどまったく当てにならない。
    そもそも、動作する以前にコンパイルすら通らないコードだったりするんだから、

    なぜ、サンプルコードを動かすだけにたっぷりと時間をかけなければならないのか
    不思議でしょうがないです。
    しかも、なんでそんなに時間がかかるんだ!、と怒られた日にゃぁ、

    同様の体験をしている人は多数いるはず、
    • Re:何をいまさら、 (スコア:3, すばらしい洞察)

      by narunaru (30931) <{mikahosi} {at} {abox9.so-net.ne.jp}> on 2007年09月28日 23時30分 (#1225949)
      サンプルコードではエラー処理や、例外的な状況に対応するための
      処理を省いていることが普通。したがってサンプルコードをそのまま
      適用すると、特定の条件化で不具合を起こすのは別段に珍しいことじゃない。

      まともな開発者ならサンプルコードをそのまま利用するようなことはしない。

      ましてIME関係の処理なんて、本家MSHQの人間にはまったく関係ないのだから、
      サンプルにバグが無いことのほうが不思議(ぉ
      親コメント
      • by Anonymous Coward on 2007年09月29日 0時43分 (#1225987)
        実際、何もかも自分で作るようなコーディングでもしない限り、理解の浅い
        ライブラリを使うことは避けられない上に、最近は~クックブックとか
        逆引き~というまさにコピペで使うためのコード集が当たり前で、コピペを
        推奨するような流れでさえあります。

        サンプルコードと言えども、コピペされることを意識して、ある程度のチェックは
        しておく必要のある時代になってしまったのかもしれません。
        親コメント
        • Re:何をいまさら、 (スコア:2, すばらしい洞察)

          by Anonymous Coward on 2007年09月29日 9時01分 (#1226063)
          そう言われて気付いたんだけども、
          サンプルコードと実用コードの「差が少なく」なるような言語が、
          「より高級な」言語だと言えるのだろうね。

          たとえば配列の境界チェックとか、チェックを違反したら例外を挙げてくれるとか、
          そういう性質が有る言語なら、最初に作った文字列のサイズが最悪足りなくても、後から何とかできるし、発覚もしやすい。

          Cはねー。想定外の事態になったとき、それを誰も(処理系が)教えてくれるわけではない、ってのが(Javaとかに比べれば)しんどいのだよね。

          #Cでエラーリカバリーを書いてったら、コードの70%以上がリカバリーになっちゃったので、こりゃヤバイと思ったAC。
          親コメント
      • by Anonymous Coward on 2007年09月29日 10時13分 (#1226078)
        サンプルってことでMSは元々のコメントを消すべきじゃなかったんだ。
        とか思う。Win32 DDKのベータとか3rdパーティの作ったソースがそのままで
        「何でこんな機能が必須なんだ?誰も使わないのに~実装が面倒だぜ」とか愚痴入ってておもしろかったもんだ。
        #ベータ取れたDDKでは同じソースはあったけどコメントが消えてた
        ちなみにAppleのDDKだと茶目っ気たっぷりに「ここにエラー処理が必要だよね?」とか書いてあって思いっきり脱力した経験あり。それを知りたいからサンプル見てるんだろがー。とか思った。
        親コメント
    • Re:何をいまさら、 (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2007年09月29日 7時26分 (#1226048)

      動作する以前にコンパイルすら通らないコードだったりするんだから、

      コンパイルすら通らないんだったら当てにならないことは明らかだからかえって問題ないでしょう。

      動いていても信用ならない

      という点こそがまさに問題になったわけで。

      もっともこの件はNyaRuRu氏のブログでかなり前から明らかにされていた [hatena.ne.jp]ので、サンプルをそのまま鵜呑みにしない程度にアンテナを張ってる人だったらとっくに知っていたでしょう。したがって「何をいまさら」という結論だけは同意します。

      親コメント
    • by Anonymous Coward on 2007年09月28日 23時31分 (#1225951)
      コンパイルが通らないはなかったけど、

      まれにリソースをリークしてくれたりするサンプルがあったなー

      発見されたバグはどんどん直っていくはずだから、
      歴代のサンプルのdiffを取ってみると面白いのかもしれないね。
      親コメント
  • もしかして (スコア:1, 興味深い)

    by Anonymous Coward on 2007年09月28日 23時10分 (#1225933)
    >Vistaでのゲーム開発においてIME関連のトラブルが頻発していたようだが、
    >その原因の1つが「SDKのサンプルコードにバグがあり、開発者が知らずに使いまわしていた」と

    Apple製品のロックが外れないバグ?
  • by Anonymous Coward on 2007年09月29日 9時23分 (#1226068)
    本来そのためのUnitTestだよなー。

    でも公開されてないコードのUnitTestは、こっちが自力で書くのは大抵無茶。特に今回のように微妙に変な引数があったとき、「これで正しい」と言い切れるUnitTestを外部の者が書くのはほぼ無理。

    それでだ。
    昔はともかく最近はNUnit…じゃなく同等競合製品(苦笑)のMS謹製のUnitTestツールも有るんだったよね。

    じゃあそれで書いたUnitTestのソースを公開しやがれ>MS

    もともとUnitTestって、「このメソッドをちゃんと動かせるサンプル、をメソッドごとに添付する」という(Smalltalkの)文化を、もう一歩押し進めたものだったそうだ。
    UnitTestはサンプルだと見なせる。
    そして、UnitTestということは「ちゃんと動くか、それともハマルか」どちらなのかがハッキリ言い切れる状態なコードだということであり、サンプルとしての「使える度」も向上しているということ。

    全部は無理にしても、可能な限り公開して欲しいな。
    本体の(おそらく長大すぎるのであろう)ソース公開より、Testの公開のほうが、おそらく技術的には有用だ。

    MSがおそらく最後の砦と考えてるであろうソース全公開までは課されずに済むので、これはMSにとっても悪い話ではないはず。

    いっぽうで「ブラックボックスだから駄目じゃん。「だから」ソース公開しろ」と言ってる人々も、Testが公開されればブラックボックスではなくなるという意味で、状況が前進するのだし。
    (Stallman系は満足させられないが、それはまた別の話。)

    UnitTestが実は無い、なんてこと言ったら笑い転げてあげますよ?>MS
typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚

読み込み中...