devblogs-microsoft-com-oldnewthing

複数のコルーチンが1つの非同期操作（IAsyncOperation）の結果を共有する方法について解説。各コルーチンが順番待ちで結果を取得できる実装アプローチを紹介する。

Windows RuntimeのIAsyncOperationの結果をキャッシュし、そのキャッシュが有効であることを確認する方法について解説。複数のコルーチンが同じ非同期操作の結果を効率的に共有できるようにするテクニックを紹介する。

本記事では、Windows Runtimeの非同期操作をC#やJavaScriptでは複数回awaitできるのに対し、C++/WinRTではそれが許可されない理由を、各言語の設計哲学の違いから解説しています。

本記事では、System.Diagnostics.Processクラスにおいて、Startメソッドを自身が呼び出した場合にのみ有効となるプロパティに関する混乱を解消するための仮想的な再設計案を提示する。これらのプロパティをStartを呼び出した場合のみアクセス可能な場所に配置することで、誤用を防ぐ方法を検討する。

COMのSTA（シングルスレッドアパートメント）スレッドはアイドル時にメッセージポンプが必要ですが、サンプルコードでポンプ処理が行われていないように見えるのは、スレッドがアイドル状態になることがなく、メッセージを待つ機会がないためです。つまり、実際にはメッセージ処理が必要ない状況だからこそ、そのようなコードが成立しているという説明です。

答えは「使えません」ですが、代替手段でごまかせるかもしれません。本記事では、Windows RuntimeからWin32構造体を直接利用できない場合の回避策について解説します。

クラシックなTreeViewコントロールでは、アイテムを名前またはlParamのいずれか一方でしか並べ替えられない。両方の基準を同時に使いたい場合は、一方の値からもう一方を導出できるようにしておく必要がある。

ERROR_ARENA_TRASHED は、記憶域（メモリ）の管理ブロックが破壊されたことを示すWindowsのエラーコードです。本記事では、MS-DOS時代のメモリアリーナ管理に端を発するこのエラーの由来と歴史的背景について解説しています。

この記事は、書かれた当初から誤って報告されていたパリティフラグの問題について取り上げています。現代の開発者がパリティフラグのデバッグを軽視している現状を、具体例を交えて指摘しています。

本記事では、CreateFileMapping関数が常にERROR_ALREADY_EXISTSを返す原因について解説する。その答えは単純で「既に存在するから」である。この一見シンプルな問いに対して、Windowsの名前付きマッピングオブジェクトの動作を理解する重要性が示されている。

もちろん、互換性のためです。32ビットx86システム上のWindowsクライアントエディションがRAMを4GBに人為的に制限する理由について、互換性の問題が原因であると説明しています。

既存のデータ構造を活用し、ディレクトリ内の最新10ファイルだけを残して他を削除する際、定数領域かつ線形時間で動作する効率的なアルゴリズムを紹介。従来の並べ替えに頼らないシンプルな手法を解説する。

キーボードレイアウトを切り替えた際に発生するハングアップ問題について解説。システム内部の処理の流れを追いながら、問題の原因とその回避策を考察する。

ハンドルをプライベートなコンテナ内に配置することで、CreateProcessが継承するハンドルを細かく制御する方法について解説します。特定のハンドルだけを子プロセスに渡したい場合に有用なテクニックを紹介します。

ファイルIDを追跡することで、ReadDirectoryChangesWを使用したリネーム（名前変更）の検出において、より確実に処理できるようになる方法について解説します。

リソース文字列をUnicode対応にアップグレードするとき、文字列リテラルの前に「L」プレフィックスを付けないと、8ビットコードページにマッピングされてしまい、Unicodeとして正しく扱われません。適切にLプレフィックスを指定することで、意図したUnicode文字列として正しく解釈されるようになります。

静的ライブラリには通用しない、というのがその理由です。APIの動作をリンクするSDKのバージョンに応じて変える方式は一見柔軟に見えますが、静的ライブラリと動的ライブラリで動作が異なる複雑さを生み、開発者にとって予測不能なバグの原因となります。結局のところ、このアプローチは実用的ではないと結論づけています。

本記事では、TABキーの動作をめぐるマイクロソフトとIBMの間の論争を取り上げ、両社の組織構造の違いが製品設計に与えた影響を解説する。このエピソードを通じて、大企業間の協業におけるコミュニケーションと責任範囲の不一致が、いかに些細な技術的決定にまで影響を及ぼすかを浮き彫りにする。

Windowsに「バイナリファイルを書き込んでいる」ことを伝える必要はありません。なぜなら、ファイルシステムレベルではすべてのファイルはバイナリだからです。この記事は、テキストモードとバイナリモードの区別が意味を持たないことを指摘しています。

この記事では、プロセス間で共有されるリーダー/ライターロックにおいて、所有者プロセスが異常終了した場合の復旧方法について解説する。特に「アバンダンメント（放棄）」の問題に焦点を当て、ロックの所有者がクラッシュした際に、他のプロセスが安全にロックを解放し、システムのデッドロックを防ぐ手法を説明する。

本記事では、プロセス間で共有されるリーダー/ライターロックにおいて、リーダー数に制限がある場合の排他制御の実装方法を解説しています。特に、複数のプロセスが同時にリーダーロックを取得しようとする「占有（grabby）」な状況で、公平に順番を待たせる仕組みについて詳しく説明します。

排他取得（書き込み）が共有取得（読み取り）に対して公平に競争できるようにする方法について解説します。本記事は、複数プロセス間で動作するリーダー/ライターロックの実装シリーズの第3回目です。

プロセス間で共有可能なリーダー/ライターロックを、同時リーダー数に制限を設けて実装する方法について解説。第1回目では、セマフォを用いた基本的なアプローチを紹介する。

C言語の関数呼び出しにおいて、渡すレジスタパラメータが不足するとアーキテクチャによって深刻度が異なる。特にItaniumアーキテクチャでは、この問題がさらに悪化することを指摘している。

scope_exit RAII型内で例外が発生した場合の対処方法について解説しています。ただし、そうした防御策を実装する価値が必ずしもあるとは限らないと指摘しています。この記事は、スコープ終了時に自動実行される処理で例外が発生する可能性と、そのリスクへの対応について考察しています。

アンインストーラーがExplorerにコードを注入したことで発生したクラッシュ事例について解説。問題の本質は「自分が立っている階段をうっかり壊してしまう」ようなものであり、システムの安定性を損なう危険性を指摘している。

いわゆる「フラクタルページマッピング」について説明しています。ページテーブル自体をメモリにマッピングする手法で、ページテーブルを介してページテーブルを参照するという再帰的な構造を持っています。

レジスタをゼロクリアする際、XOR命令が最も一般的な方法として定着しましたが、SUB命令でも同様の結果が得られるにもかかわらず、なぜXORが好まれるのかについて考察します。歴史的経緯やパフォーマンス特性、コードサイズなどの要因が関係している可能性があります。

ピクセルがアライメントされていなくても、アライメントされたアクセスを使用する必要がありました。バンク切り替えメモリを搭載したビデオカードでは、24ビット/ピクセル形式の処理に特別な考慮が必要でした。

コンパイラが書いていないコードについて文句を言っている場合、誰がそれを書いたのかを特定する必要があります。この記事では、実際には存在しない->演算子の使用に関するエラーメッセージを理解する方法を解説します。