Brynhildr

KeroRemote

リモートデスクトップエンジニアのブログ。


Brynhildr(ブリュンヒルデ)はシェアウェアになりました
引き続きご利用される場合はライセンスのご購入が必要です
詳しくは「こちら」をご覧ください
リモートデスクトップ「Gungnir 0.3.0」リリース



令和の時代にWindows 2000に対応したGungnirが大復活でございます。

Gungnir Download



リモートデスクトップ「Gungnir 0.3.0」をリリースしました。

はい、前回のバージョンアップで終息させるつもりでしたが約3年ぶりに復活することになりました。まあ計画変更はいつものことですので大目に見てください。

さて、そんな復活したGungnirですが、基本的にはあまり変わっておりませんが、いくつか変わった点をご紹介します。

まず、権利表記を「IchiGeki」から「LAUNCELOT CO. LTD.」に変更しました。もうIchiGekiは名乗ってないですし、KANEKOも恥ずかしいので、私が代表を務める会社(株式会社ランスロット)にしました。

次に、BrynhildrとVerethragnaにも修正を施しましたVP8のゼロデイ脆弱性(CVE-2023-5217)を対処しました。Gungnirも対処したつもりでしたけど抜けてました。まー、その頃は再リリースするつもりもなかったですので。

次に、GungnirをWindows 2000などの古いOSにも対応させました。Gungnirは中身的にBrynhildrとほぼ同じなのですが、Gungnirは標準でDesktop Duplication API(DDA)に対応させてましたのでWindows 2000などではDirectXの絡みでモジュールの起動ができなかったのです。これを「gungnir_dda.dll」とゆー風にDDAの機能を分離させてWindows 2000などではそのDLLを呼ばずWindows 2000などでも動くよーにしました。今日日Windows 2000に対応させる話なんてあんまないと思いますので完全にネタなんですけど。

ちなみに、対応OSの表記からWindows Severを外しましたけど、特に最新のServer 2022とかでのチェックはしてませんけど、ServerのアーキテクチャがWindowsと同じであればたぶん動くと思いますので特に表記しなくても大丈夫かなと思い外しました。もしServerのほーで動かんぞー、とゆーことがありましたらご一報頂ければと思います。もうMSMVPじゃないんでOSを手に入れることが難しいんですけど、その時は誰かにテストしてもらおうと甘い気持ちで考えてる所存でございます。

次に、newフォルダによるアップデートを廃止しました。Verethragnaでバッチファイルによる入れ替えも可能と分かりましたので廃止にしました。

次に、暗号化における鍵長を256bitに変更しまして暗号強度を強化しました。これもVerethragnaを参考にしてます。

あと、約3年ものたまりにたまった不具合とか脆弱性とか軽微な修正が入っております。

そもそも、Gungnirの位置づけはBrynhildrの先行的なプロトタイプでして、アセンブラの部分にかなり手が入っており、パフォーマンスに関してはいまだにBrynhildrよりも上回っています。BrynhildrはFPSが30をベースに比べてGungnirはFPSが60をベースですし。

その後、Gungnirのパフォーマンスをさらに上回るVerethragnaを登場させましたので、Gungnirの役目は終えたよーにも思えましたが、Verethragnaではさすがに古いOSに対応まではしなかったんです。

でもって、Brynhildrの方はあまりにユーザー数が多く、その影響の度合いがあまりに大きいので気軽にバージョンアップをすることができません。デグレでもしよーものならそれこそ大変ですし。

ですので、VerethragnaとBrynhildrの中間であり気軽に手を入れることができ古いOSでも動くGungnirがちょーどええんでは、とゆーことになりこーなりました。

https://gungnir.remotedesktop.jp

これに合わせて、Gungnirのウェブサイトもこしらえました。まんまVerethragnaのウェブサイトなのですがVerethragnaのウェブサイトも自分がデザインしているのでしょーがありませんよね。いらないところをかなり端折ってあります。シンプル版とゆーか超手抜き版です。ダウンロードもこちらよりできるよーにしました。これまでGungnirのダウンロードとか説明はかなりてきとーでしたけど少しマシになりました、まだベータ版ですけど。

あとたまーにご連絡を頂くGungnirを法人でのご利用についてもお気軽にウェブサイトからお問合せくださいませ。

とゆーことで引き続きGungnirをよろしくお願いいたします。


6件のコメント ... ( 管理人承認制 )



最近思うのは、SSEとかAVX512とかやっぱり対応してるCPUでSIMDは、画像処理に使うと速いはずだよなぁ(起動時チェックで非対応なら使わなければいい?)、とか、


スレッド数は論理コア数よりも物理コア数、または並列度が高いなら物理コア数+1が速いよなぁ、とか、
Intelの非対称さんは、たしか物理コア数相当は、全Eコア+半分の物理Pコア(P側はハイパースレッディングあるから物理的には半分、つまりP3×2スレッド、E4スレッドなら、物理5コア相当)だなぁ、とか(記憶違いならすみません)。


半分ひとりごとでした。


通りすがり  2024/07/23


凄くお詳しいですね・・・。


KANEKO  2024/07/23


最近ちょっとC#でSIMD触った事がありまして・・・結局自分の用途だと合わなかったんですが、画像って配列上に綺麗に並んでる上に並列化しやすいんで、やっぱり使わない手はないんじゃないかなぁとか思った次第です。
C#の場合、結構楽で、CPUごとにどの命令使えるかを調べる必要はなく、「演算を最大何バイトまとめて計算できるか」を取得できるので、その単位て配列を刻んで投げるだけで良かったです。CPUは実行中に突然変わるもんではないので、アプリ起動時に一回だけ調べればおーけーです。
Cでもこの発想で作れば、SSEとか非対応のCPUでも使えるけど、対応マシンなら速くなっちゃうんじゃないかと思っちゃった訳です・・・。(起動時のチェックはCで組むと面倒くさそうですけど。)


さらに、起動時にCPUコア数分のスレッドを用意しておいて、その刻みにすればさらに速いんじゃね?的な


もちろんオーバーヘッドはありますが、うまいことやれば(スレッドは毎回起こして終わらすんではなく、セマフォやミューテックス等のCPUをほぼ食わない待ち処理で同期取るとか)、画像処理なら元が取れるんじゃないかなぁと、勝手に夢が膨らんでしまった訳です。


ざっと調べた限り、コンパイラーの自動ベクトル化機能というのがあって、対応している場合のみこっちを呼んで、非対応ならこっちを呼ぶみたいな仕組みも作れるようです(関数ポインタを上手く使えば、ループ毎にif文呼ぶのも防げそう。まぁここ数年のx86系CPUは分岐予測がかなり賢くなったので、ifで分岐してもそれほど遅くないと思いますが・・・。)


ご参考まで、です。


通りすがり  2024/07/23


なるほど、ありがとうございます。


ちなみにGungnirはx86命令のアセンブラ処理を並列化させてます。


KANEKO  2024/07/23


はい、心得ております・・・!
AVX512は、float(32bit)であれば、理論的には1スレッドからさらに16並列にできる命令なので、リクツ的にはマルチスレッドからさらに16倍速いはずなので・・・という。


通りすがり  2024/07/23


16倍!夢がありますね!


KANEKO  2024/07/24




... 不具合報告の際は、アプリのバージョンやOS等の動作環境の記載を御願い致します。

表記されている会社名・製品名・システム名などは、各社の商標、または登録商標です。
当サイトはAmazon.co.jpアソシエイトプログラムに参加しています。
© 2010-2024 LAUNCELOT CO. LTD.