別のオープンソース

それから誰もこれらの言葉を使わなかった。 その意味さえ知っていたかどうかはわかりません。 プログラママガジンの2つの問題の1つで、初めてウラジミールクラドフのKey Object Libraryプロジェクト、または研究所の前のKOLについて学びました。母は、地域のプログラミングコンテストに参加したことを記念して私に手紙を書きました。 記事のタイトルは「 プログラムの中心に数えられます！」 »それは雑誌の同じ号の中で、私が最初に.NETについて学んだようです。 そして、リソースに対するこのような法外な要件は、ソフトウェア業界の巨人がIT業界に対してほとんど転換したように見えました。 （Windows 98からのCeleron 433 64MBハードウェアの部門で30分から始まる、同じクラスメートの1人の金型で構成される実験室の友人を今でも思い出します。スチームタスクがあったときに同じマシンでDiablo IIをブレーキなしでプレイしていました完了:)



そして、KOLは異なっていました。 彼は、作業の速度と実行可能ファイルのサイズを強調しました。 当時、インターネットからそれぞれ10メガバイトのソフトウェアアップデートをダウンロードするのはよくありませんでした。 Delphiの下で書いた人にとっては、VCLを使用するか、Delphiの標準ビジュアルライブラリ（ちなみに、そのアーキテクトも.NETフレームワークの作成に取り組んだ）を使用するか、Windows APIを使用するかのどちらかを選択しました。



VCLがひどいことは言うまでもありませんが、中規模から大規模のプロジェクトで素晴らしい仕事をしました。 しかし、初心者のプログラマーが最も書く小さなユーティリティの場合、彼は完全には適合しませんでした。 実行可能ファイルの最小サイズは、Delphiのバージョンに応じて250〜350 kbでしたが、アプリケーションにさまざまなコントロールが追加されると非常に急速に増加しました。 これは、まず第一に、各コントロールが最大12個の親を持つクラスの高度に分岐したツリーの結果でした。 さらに、最初のAMD K5-100コンピューターで空のアプリケーションを約0.5秒間起動することをVCLに許せず、MFC（古いビジュアルスタジオの標準フレームワーク）上のアプリケーションはほとんどすぐに開始しました:)



どうやらウラジミール・クラドフは同じ問題を心配し、ある時点でXCLの作成に取り掛かりました。XCLは、VCLと同じ原理に基づいて構築されたライブラリですが、実行可能ファイルのサイズを慎重に尊重します。 しかし、実行可能ファイルのサイズに影響を与える方法はたくさんあると言わなければなりません（パッカーの形で後処理をカウントしません）。 同じタスクを実行する異なるコードは、サイズが大きく異なる場合があります。 しかし、このアプローチの非効率性が明らかになったとき、このプロジェクトの作業は長続きしませんでした（1年の変化の歴史から判断すると）。 コンパクトフレームワークデバイスを再考する新しい試みはKOLでした。



KOLアプローチの主な知識は、 1つの PControlクラスにすべての標準コントロールの機能を投獄することでした。 一見、1つのクラスがディレクトリツリーとボタンを担当する場合、これは無意味に思えますが、機能しました。 全体の秘密は、異なるコントロールの異なるデザイナーにありました。 すべてのアドオンはMCKでした。これは、出力コードを生成して同様のKOLコンポーネントを作成するVCLのアドオンです。 つまり 使い慣れたDelphi環境で作業して、フォームにボタンを投げると、同じフォームでMCKが生成したコードが純粋なKOLで生成されます。 同時に、アプリケーションの開始サイズは20 kbまたは10 kbで、ちょっとしたトリックがあり、「リリース」で使用できるDelphiシステムライブラリを置き換えました。



ライブラリを開発しているコミュニティは小さくても友好的でした。 もちろん、ウラジミールは図書館の発展に最大の貢献をしましたが、他者の役割を過大評価することも困難でした。 まだ完全に環境に優しいこのフレンドリーなチームで、私は研究所の最初のコースに参加しました。 メインフォーラムは、バグトラックと組み合わせて、サイトdelphimaster.ruにありました 。 Vladimirによって作成されたユーティリティを使用して行われた差分形式のコミットは、関心のあるすべての人によって行われました（差分の形式が他のオープンソースアナログと互換性があるかどうかはまだわかりません）。 新しいバージョンは、永続的なチームリーダーによってリリースされました。 ライブラリを使用できるライセンスについては、これまで議論されていなかったようです。 公式サイトには、シンプルでわかりやすい「ソースコード付きで無料で提供」があります。



多くの補助ライブラリがフレームワークの下で作成および移植され、すべてが主なイデオロギーに準拠しています。



他のオープンソースプロジェクトと同様に、誰もが開発中に何かを見つけました。 ウラジミールには、KOLで構築された中小規模のプロジェクトが数多くあります。

• ImgSearch-類似画像を見つけて削除するためのプログラム。 かつて、それはよりよく機能し、おそらくimageDupelessに知られていました。
• Zoomer- （ 注意 、ページにウイルスが存在することを教えてくれます。プログラム自体は正常です）。 MMXを使用した独自のスケーリングアルゴリズムを備えた高速で非常に優れた画像ファイルビューアー。Vladimirは拷問の下でも配ることに同意しませんでした:)
• EmuZWin-スペクトルエミュレーター（S48およびS128）。 マルチカラー（48K、128、128 / + 2 / + 3、ペンタゴン）、スムーズスケール、およびその他の非常に長いリストをサポート:)

これらおよびその他の小さなアプリケーションは、 KOLソフトウェアのページで見つけることができます。 ウラジミール自身が繰り返し言っているように、図書館は彼の主な作品で彼によって積極的に使用されています。



もちろん、私の目標は完全に異なっていました。 私にとって、これは主にプログラミングの練習でした。 さて、彼らが今言うように、ただの楽しみのために。 私は、図書館にたった4つの多かれ少なかれ重要な貢献をしました。 私はまだ年表を覚えていないので、重要度の昇順でリストします。

GradientPanelコントロールの新しいレンダリング

書き込みの理由は、以前の実装の非常に遅い速度です。 新しい実装では、古い実装でサポートされていた一部のタイプの塗りがサポートされていないため、デフォルトでは有効になっていません。

TinyPicturesライブラリ

もちろん、これはKOLで写真をダウンロードするための最初のライブラリでも最高のライブラリでもありませんでした。 しかし、それは非常にトリッキーでした:) BMP JPGおよびGIF形式のダウンローダーは、コンパイルされたビューで1キロバイトを超えませんでした。 これはどのように可能ですか？ OLEオートメーション関数OleLoadPictureが使用されました。 もちろん、これはグラフィックエディターのオプションではありませんでした。少なくともこの機能は壊れた画像を読み込むことができませんでした。 しかし、一部のインストーラーにとっては、それが一番でした。 しかし、PNGではすべてがより複雑でした。 もちろん、私はいくつかのライブラリをKOLの基礎としては取りませんでした（どのライブラリも覚えていません）が、PNGを自分の頭でテストするための一連の写真を見つけましたが、多くの形式は機能しませんでした。 私はそれを終えなければなりませんでした。 それから、PNG形式がどのような能力を持ち、どれだけ違うのかを知りました（こんにちは！）。

古い透明システムの交換

KOLを使用すると、任意の要素を任意の形状で描画できます。 ウラジミールが実現し、後で改善したことは、ウィンドウレスコントロール（つまり、画像とラベル）を除いてVCLにはありませんでした。 私の改善点は次のとおりです。以前は、透明な要素は親によってそれ自体の上に描画され、次にそれ自体の上に描画されていました。 透明な要素が20個ある場合、各要素はそれ自体に親をペイントしました。 私の決定は、子要素を描画することではなく、すべての子を自分で描画する親に再描画のリクエストを送信することでした。 簡単に聞こえますが、実際には、GDIが意図していないことを実行するのは非常に困難でした。 それでも、達成された結果は、少なくとも90％のケースで正常に機能し、以前のバージョンよりも高速に機能したようです。

圧潰制御

これまで、これは私が単独で完了した最大のプロジェクトです。 フォーラムの誰かが、RB ControlsライブラリをKOLに移植することで、彼らの成果を何らかの形で示しました。 ちなみに、元のRB ControlsはIEの少なくとも1つのアドオンで使用されています（maxthonらしい）。 移植されたコンポーネントのデモは次のようになりました。







同意する、かなりいい。 さらに、優れたカスタマイズオプション。 しかし、これらすべての速度は驚くほどではありませんでした（ コンパイルされた例を見ることができます）。 私が理解しているように、VCLの元のRBも輝いていませんでした。 私のさらなる行動を推測するのは難しくありません。私は、RB Controlsに似たコントロールのバージョンに取り組み始めましたが、内部では完全に異なります-GRushコントロール。



その結果、いくつかの種類の塗りつぶし、押したときとホバーしたときの滑らかな流れ、滑らかな丸い角（hello、css3！）、影付きのテキストと画像の両方を使用する機能を備えたコントロールが得られました。 これらはすべて、当時のCeleron 500でも非常に高速に機能しました。コンポーネントセットには、Button、Panel、CheckBox、RadioBox、Splitter（他の2つのコンポーネントのユーザーサイズ変更用スライダー）、ProgressBarが含まれていました。



この作業は、最初のプロジェクトである迅速なグラデーション塗りつぶしに役立ちました。 すべての重要なセクションは徹底的にテストされ、MMXを使用してアセンブラーで多くが記述されました。 チェンジログのいくつかのポイントを再読した後、そのような懐かしさは次のようになります。

[+] USE_MEMSAVEMODE ( ). - Paterns , . ( ).

[*] BitmapAntialias4X MMX ( ), XXX_BorderRoundWidth/Height. - GDI, BitmapAntialias2X ( MMX) ( USE_2XAA_INSTEAD_OF_4XAA).

いくつかの「衝撃的な」事実を示します。

-RB Controlsデモを全画面に展開すると、スプリッターを使用してパネルのサイズを変更している間、私から7メートル、最大50メモリーを消費します。

-GRushデモは、850 Kbを消費するウィンドウサイズと最大3 Mbのサイズ変更中に、ほぼ同じです（ コンパイルされた例 ）。 ビデオメモリの変更不可能な表面、変数-dibに使用する秘secret。

-サイズが1900×1100ピクセルのグラデーションパネル（ など ）で、1秒間に70回のレンダリングが可能な、丸みを帯びた4倍のアイロンがけされた各100×100ピクセルの角。 ラウンドコーナーなしで最大320回。 これは単一のAthlon 5200コア上にありますが、これはコンポーネントがサイズ変更または作成されたときに発生する「ゼロから」レンダリングであると言わなければなりません。 誰もコンポーネントに触れない場合、キャッシュサーフェスからはるかに速く描画されます。



別の言及は、MCKでコンポーネントを構成するための視覚的なウィザードです。 前述したように、MCKコンポーネントは本質的に同じVCLコンポーネントです。 これはボタンやパネルには大きな役割を果たしません。両方は両方のフレームワーク（KOLとVCL）にあります。 しかし、VCLにはGRushコントロールはありませんが、多くの設定があります。 そして、本格的なエディターを作成するには、それらをVCLに移植する必要があります。 アイデア自体は悪くありませんが、設定エディターのためではありません！ 私は異なった行動をしました。 私の知る限り、私の前、そしておそらくその後、誰もこれをしませんでした。 エディターとして実際のGRushコントロールを備えたKOLフォームを起動しました。 つまり KOLフォームはDelphi環境自体で機能しました。 エディターは次のようになりました。







私がしようとしていたことはすべて言ったと思う。 ストーリーは、昨日のハーバーに関するアンケート「プログラミングの権限はありますか」に触発されたもので、著者は明らかに隠すことを好んでいました（調査は伝統的に否定的です、はい）。



ところで、私は1つの興味深いアーカイバで古いftpを見つけました。 自分でやったことすらわからない。 VCL対KOLおよびVCL＆RB対KOL＆GRushに関するいくつかのデモプロジェクトがあります。 プログラムのサイズ、ダウンロード速度、メモリ消費量を比較できます。