GDIのメモリ使用量
グラフィックデバイスインターフェイスサポートマネージャー（GDI）を書き換える過程で、Timo Kreuzerはメモリの巨大な浪費としか言えないものに直面しました。 作成されたオブジェクトに割り当てられたメモリの量は常にフルページでした。 オブジェクトがその属性を格納するためにこのような大量のメモリを必要とするかどうかに関係なく、4 Kb。 これにより、メモリアドレスが浪費されるだけでなく、メモリが大幅に無駄になります。 Timoは、これが、一度に多くのメモリページのタスクマネージャーでリークを引き起こす原因の1つであることを示唆しています。 Win32kにはこのような割り当てのためのキャッシュメカニズムがあり、明らかに、解放されたページを再利用しないため、一定時間内にすべてのシステムメモリが使い果たされる可能性があります。
幸いなことに、Timoはこれらの問題を解決することができました。 彼は、各プロセスのオブジェクト属性のタイプごとにメモリプールを開発しました。 オブジェクトが作成または破棄されるたびに、これらのプールでメモリが割り当てまたは割り当て解除されます。 プールはセクションに編成され、そのサイズは4 Kbの1ページから最大64 Kbまで異なります。 各プールは1つのパーティションで始まり、必要に応じてより大きな数を追加できますが、各オブジェクトの作成時に割り当てられるメモリの合計量は、各属性に必要な実際の量を超えません。 ビットマップは、各プールの空きメモリセグメントを示すために使用され、配布可能なメモリの検索は、作成時にオブジェクトの各属性をページごとにページングする方法が使用されたときよりもはるかに高速です。
プールは、高速化と無駄なメモリの除去に加えて、古いキャッシュメカニズムの必要性も排除します。 プール自体は一種のキャッシュとして機能し、オブジェクトの作成中にすぐに使用できるメモリの予約を含んでいます。 したがって、Win32kでは、古いメモリブロックを処理し、新しいオブジェクトで再利用できるように準備するために設計された追加のメカニズムは必要ありません。
新しいUSBドライバー
Johannes Anderwaldは、カーネルからWin32kおよびサウンドサポートまで、幅広いReactOSコンポーネントに取り組んでおり、現在はUSBの開発に忙しくしています。 彼は、USBサポートの導入に関心を示し、Michael MartinがUSBドライバーをCからC ++に書き換えて読みやすく、サポートしやすくすることを提案しました。 マイケルはそれに同意し、すべての活動を新しいEHCIドライバーに完全に集中させました。 彼らの現在の目標は、このドライバーを、その機能がMichaelによって書かれた古いEHCIドライバーの機能に匹敵するような状態に改良することです。 I / O要求パケットをEHCIドライバーに送信するusbhubドライバーの開発に進む前に、古いドライバーの開発を中止することが決定されました。
Summer of Codeで受け入れられたプロジェクト
ReactOSプロジェクトには、Google Summer of Codeの下で6人の空きがあり、選択したプロジェクトに関するすべての情報がここに投稿されました 。 個人的な理由から、これらのプロジェクトの本質をより詳細に説明するのに十分な時間がありませんでした。
TCP / IPドライバー
ReactOSネットワークスタックにTCP / IPプロトコルの高品質な実装を実装するための多くの試みが既にありました。 後者はoskitライブラリを使用してTCP / UDPをサポートすることでしたが、その統合は非常に複雑なプロセスでした。 私たちが使用しているサードパーティのライブラリでは、そもそも新しいバージョンが別のプロジェクトによってリリースされたときに簡単に更新できる可能性があります。 コードをシステムと密接に統合する必要がある場合、タスクははるかに複雑です。 lwIPライブラリは主に組み込みシステムでの使用を目的としており、非常に軽量で内蔵型です。 ReactOSネットワークスタックに正しく統合できることを願っています。
Explorer_new
新しいシェルの作業は、数年前にThomas Bluemelによって始まり、Andrew Hillによって続けられました。 欠落している機能のほとんどは、shell32ライブラリの不完全な実装の結果です。主にexplorer_newの精度は、その準備に依存します。 したがって、explorer_newでの作業は、Shell32ライブラリでの作業も意味します。 このプロジェクトには既に多数の開発がありますが、その完成には多くの努力が必要です。
テーマのサポート
テーマのサポートは、ReactOSで最も要望の多い機能の1つですが、ほとんどの場合、美しいユーザーインターフェイスがプロジェクトにより多くの人々を引き付けると考えるユーザーのみがそれを求めます。 また、Windowsのコンポーネントの文書化が不十分であるため、適切に実装することが困難です。 それでも、Giannis Adamopoulosはこの方向で研究を行っており、このコンポーネントの実装に対処できると考えています。
オーディオミキシング
Johannes Anderwald氏はReactOSサウンドスタックでの作業にある程度成功しましたが、それでも、複数のオーディオストリームの同時管理のサポートを開発するには、さらに多くの作業が必要です。 これは非常に必要な機能です。特に、ユーザーがOSまたはアプリケーションで発生するイベントについて可聴アラートを持っている場合はそうです。 現在、ReactOSはこれらの機能を非常に不十分にサポートしているため、オーディオミキサーを使用すると、システムをさらに使いやすくすることができます。
カーネルモードテストスイート
カーネル機能と直接やり取りする一連のテストにより、ReactOSの起動時またはシステムの正常な機能の中断時にクラッシュにつながる問題の検索が大幅に高速化され、容易になります。 テストが失敗した場合、OSで重大な障害が発生する可能性が高いため、それらの実装方法を確認することも興味深いです。
GDIフォントドライバー
数年前、ニュースリリースの1つで、ReactOSでのフォントのレンダリングに関連する問題について詳細に説明しました。 詳細に興味がある場合は、ここで詳細を確認できます。 つまり、ReactOSのレンダリング方法は完全に間違っていることが判明し、フォントのグリフによって提供される情報のほとんどを無視しました。 有効なフォントドライバーは、この問題を解決し、Win32サブシステムのアーキテクチャの別の大きな欠陥を救うことができます。
別の開発者
Gabriel Ilardiはしばらく前にコミットアクセスを受け取りましたが、彼が数週間IRCチャンネルにいなかったため、前のニュースリリースを書いたときにこの事実が頭から飛び出しました。 いずれにせよ、私たちのランクに参加している別の開発者を歓迎してください。
翻訳者： evilslon 、 Farwalker 、 serrox