AnyDeskからRustDeskへ

 最近RustDeskを知ったので、AnyDeskからRustDeskに移行してみました。

RustDeskの方が後発（だと思う）ですが、これ、完全にAnyDeskを意識していますね。すごく似たような表示だし、ほとんど同じように使えます。

比較表を作ってみました。ただし、Windows版での動作評価限定です。LinuxやAndroid版は使っていないので、詳しくは知りません。

比較項目	AnyDesk	RustDesk
インストール必要？	インストール無しで使用可	インストール無しで使用可
UAC操作（※３）	対応（要インストール）	対応（要インストール）
特権レベルウィンドウの操作（※４）	可（要インストール）	可（要インストール）
接続の簡単さ	数桁のIDを入力	数桁のIDを入力
無人接続	可（パスワード設定後）	可（パスワード設定後）
画像のきれいさ	まずまず	やや粗い
表示ラグ	少ない	やや遅れる
ファイル転送	可	可
クリップボード共有	可	可
音声再生	可	可
チャット機能	有	有
英語←→日本語切替 （IME操作）	難あり	ALT+漢字キー または 変換キー
CTRL+ALT+DEL対応	対応	対応
デスクトップLock対応	対応	対応
TLS	対応	対応
自前サーバ対応（※１）	不可	可
マルチディスプレイ対応（※２）	不可	不可
商用利用	有償	制限なし
目立った不具合	ローカルPC側でまれにWindowsキー、SHIFT/CTRLキーが使えなくなる	アンダースコア"_"入力不可

※１：サーバとは、ホールパンチング処理と接続先の管理を行うものでRustDeskでは自前のPCをサーバにすることで、反応速度とセキュリティを向上させることが可能なようです。

サーバを自前で建てなくても使用可。その場合は、どこかのサーバを経由して接続管理がされるようです。

AnyDeskの方は、ベンダーのサーバを使うのでしょうか。詳しくはよく分かりませんが、画面共有開始時のホールパンチングにインターネット上のサーバにいったん接続することは確実だと思われます。

※２：「マルチディスプレイ対応」とは、リモート側PCがマルチディスプレイ構成のときにそれぞれのディスプレイ（デスクトップ）の内容を、ローカルPC上で表示・共有できるか？という意味です。残念ながら、リモート側PCのプライマリディスプレイの内容しか、こちら側で表示・操作できないようでした。（セカンダリディスプレイを表示・操作できる方法があれば教えてください）

※３：リモート側でUACが入る操作（アプリのインストールなど）を行った時に、操作ができるかどうか？ということです。AnyDesk/RustDesk共にインストールしておけば、UAC操作になってもちゃんと遠隔操作できます。（特権レベルで実行されるサービスとしてインストールされる模様）

インストールしていない場合は、リモートがUACになった途端、こちらから操作できなくなるので注意。

※４：AnyDesk/RustDesk共、インストールなしで起動している場合は、リモート側で特権レベルで実行されているアプリはこちら側から操作できません。Windowsタスクマネージャがその一例です。タスクマネージャを起動することはできますが、そのウィンドウ内を走査してタブを切り替えるといった操作ができません。

AnyDesk/RustDeskをインストールしておけば、UAC同様、問題なく操作できます。

不具合については、AnyDeskはWindowsキーや、SHIFT/CTRL/ALTキーがAnyDeskにキャプチャされてしまうことがあるので、ローカルPC側でWindowsキーを押してもSTARTメニューが開けなかったり、英文字入力がすべて大文字（SHIFTキー押しっぱなし？）になることがありました。

特に、AnyDeskでリモートに接続しようとしている最中に、Windows+CTRL+←（または→）操作で仮想デスクトップを切り替えると、必ずWindowsキーがキャプチャされたままになって、STARTメニューが開けません。また、同じ操作で別の仮想デスクトップ画面に切り替えることも出来なくなります。

これを解消するには、タスクトレイにあるAnyDeskを強制KILLすることです。これで再びWindowsキーが使えるようになります。

同じWindowsキー絡みでは、リモートPC側でWindowsキーを押すと、リモート側だけでなく、ローカルPC側でも同時にSTARTメニューが開いたり閉じたりすることがあります。これも、キー操作のキャプチャ処理がリモート側なのかローカルPC側なのかがおかしくなっているものと推測されます。

更にAnyDeskの話ですが、IMEに日本語・英語切り替えがダメです。リモート側で日本語入力しようとして漢字キーを押すと、リモート側で日本語モードになると同時に、ローカル側も日本語モードになってしまうので、とてつもなく入力しにくいです。マウスでタスクトレイをクリックして日本語・英語切り替えすれば回避できますが、いちいちマウスでクリックする人はほとんどいないでしょう。

この問題を解決するAnyDesk-IME-Off-controlという便利なツールを作ってくれている人がおられて、これを使うと少し幸せになれます。なぜ「少し」だけなのかは、このツールを使っていても、やっぱりリモート／ローカルで同時に日本語モードになってしまうことがあったからです。理由や再現方法ははっきりしませんが、何かを契機にして比較的頻繁にそういう現象が起き始めます。

RustDeskの致命的な不具合は、リモート側にアンダースコア"_"が入力できないことです（バージョン1.1.9で確認）。これは、githubでも不具合報告されています。回避策は、日本語モードにして「した」を変換する方法があります。他には、クリップボードに"_"をコピーして貼り付ける方法があります（が、面倒過ぎるので、早く直してほしい）。

RuskDeskもWindowsキーを押しっぱなし（キャプチャしっぱなし）問題が発生することがありますが、現象は少し違っていて、こちらは比較的軽微な問題です。リモート側で何かキー操作（例えば「１」を入力）をしようとすると、同時にその操作がローカルPC側でも「Windows+1キー」と認識されてしまうことがあります。つまり、リモートPCには「１」が入力され、同時にローカルPC側ではMS-Edgeが起動（タスクバーにピン止めしている１番目のアプリが起動）することがあります。

こちらも、不具合のきっかけは、仮想デスクトップの切り替え操作（Windows+CTRL+←）と関係がありそうです。そういう操作をしない人は、この問題は出ないのかも知れません。

解決方法は、リモート側とローカルPC側の両方で、落ち着いてWindowsキーを１回しっかりと押すことです。これでキー入力の異常なキャプチャ状態が解消されるようです。

[備忘録]VivadoプロジェクトがRead-onlyになって開けなくなったときの対処

 Vivadoを使ってFPGAの開発をしているとき、何かの拍子でプロジェクトが開けなくなったことが何度かあった。プロジェクトが何故かRead-onlyモードになり、すべてのIPコアがLockされた状態になって、Synthesis/Implementを含むすべての操作が禁止される状態になることがあった。

Xilinxのフォーラムでも質問が出ていたが、有益な情報はなかった。

https://support.xilinx.com/s/question/0D52E00006lLhAGSA0/vivado-project-converts-to-read-only?language=ja

これまでは、プロジェクトディレクトリを丸ごと削除して、新しくソースをgitからcheckoutしてなんとかやりくりしていたが、ようやく原因と解決方法が分かったので、その備忘録を記録。

（原因）

IPコアのディレクトリに、コンテナ化（Enable Container）したIPコア名と同じ名前のサブディレクトリが存在するときに発生する。

（対処方法）

そのIPコアをコンテナ化しているならば拡張子.xcixファイルだけあれば良いので、同名のサブディレクトリを削除する。

例えば、コンテナ化したmyIP.xcixファイルがプロジェクトにあるならば、myIPという名前のディレクトリは削除する。

このことに気付いてからよくよくTclコンソールをよーく見てみると、ちゃんと原因が出力されていた！

CRITICAL WARNING: [Project 1-635] The core container source file '（プロジェクトのIPが置かれるディレクトリ）/hogehoge.xcix' is sitting next to the IP directory '（プロジェクトのIPが置かれるディレクトリ）/hogehoge'. This configuration is not supported and will lead to unexpected behavior. The project will be opened as read-only. To resolve the issue, please move aside the IP directory and reopen the project.

WARNING: [Project 1-312] File not found as '（プロジェクトのIPが置かれるディレクトリ）/hogehoge.xci'; using path '（プロジェクトのIPが置かれるディレクトリ）/hogehoge.xci' instead.

なぜこんなことになったのかはっきりしたことは覚えていないが、そういえばコンテナ化IPファイル.xcixはバイナリファイルなのでgitでは扱いにくいなと思って、コンテナ化を解除（Disable Container）したことがあった。そのときに作られた（だろう）サブディレクトリが残っていたのかも知れない。

[備忘録] Git For Windowsをアップデートしたらリモートリポジトリにpush/fetchできなくなった件

Git For Windows 2.33.1以降で発生する模様。

OpenSSHのバージョンが8.8以上に上がると、ssh接続時にデフォルトでRSAキーの使用が禁止されるようになったせいらしい。

RSAを使用している場合、非推奨ながらsshのconfigに

PubkeyAcceptedAlgorithms +ssh-rsa

を追加すると、とりあえずこれまでどおりRSAで接続は可能になった。

しかし、この方法はいつまで（安全に）使えるのだろう。

[備忘録]Windows11 Explorerの右クリックメニューの反応が遅くなる件、解決（か？）

「 Windows11の」と書いたけれど、Windows10を使っていた頃から出ていた現象、Explorerの右クリックメニュー(コンテキストメニュー）でしばらくフリーズする件について、ようやく解決方法が分かったので、その備忘録。

現象はWindows10の頃から出ていた。Windows11が出た頃、もしかして直るかもしれないと淡い期待を込めてアップデートしたけれど、結局は直らずじまい、だましだまし使ってきたけれど我慢の限界が来て調べてみました。

現象の回避策としては、

・TortoiseSVN用のIcon Overlay Handlerを無効にする

というものでした。

えっ！？Context Menu Handlerではなく、Icon Overlay Handlerの無効化！？

確かに変です、でもこれを無効にすることでコンテキストメニューはスッと表示されるようになりました。

これまで、メニューが表示されるまでに10～30秒くらい待たされることがありました。一度メニューが表示されるようになると、続けて右クリックするとすぐに表示されていました。しかし、何分か別の作業をして再度Explorerに戻ってメニューを開こうとすると、また何十秒も待たされました。Explorerとは別のファイラーを使っても、コンテキストメニューを表示させようとすると同じ現象が発生していました。本当にイライラしながらも何とか我慢して使っていましたが、これでイライラから解放されました。

最終的には、フリーソフトのShellExViewが大変役に立ちました。手軽にContext Menu HandlerをEnable/Disable切り替えができるので助かりました。

Shell ExtensionのContext Menu Handlerのどれかが悪さしているだろうことは想像に難くないので、自前のテストプログラムを作り、レジストリを走査してContext Menu Handlerを実装しているWindows内DLLをロード＆COM経由でハンドラを呼び出すようなテストをして調べていたのですが、作ったテストプログラムでは極端に遅くなる現象がどうしても再現せず、ほとんど諦めていました。

別の方法としては、ExplorerをVisual Studioのデバッガにアタッチしてシンボル情報（とは言っても、Windows系DLLのシンボルしか入手されませんが）や、デバッガ上のDLLロードタイミングなどから問題のDLLを探そうともしていましたが、こちらも問題の特定には至らなかったです。

それにしても、なぜIcon Overlay Handlerの無効化が回避策となり得るのか、本当に不思議です。でも、いいんです。PCなんてダマシダマシ使うものと割り切ってますから。

[備忘録]ブラウザがERR_CERT_COMMON_NAME_INVALIDエラーを出してページが開けない！

 自分用の備忘録。

今まで、ちゃんとアクセスできていたあるページがブラウザで開けなくなりました。何度やっても、「この接続ではプライバシーが保護されません」(ERR_CERT_COMMON_NAME_INVALID)と出ていました。

原因は基本的には証明書絡みなのだと思いました。ググると色々と出てきますが、今回の私のケースに当てはまるものは無かったので、ここで記録することにします。

原因は・・・・

• ESET Internet Securityが悪さをしていた！

ということだったようです。

というのも、この現象が発生したPCは２台あってその２台ともESETをアンインストールした時点で問題がなくなりました。その後、ESETを再インストールしてもエラーは再現せず、正しく目的のページが表示される状態に直りました。

確かに、エラーメッセージに、ESET SSL Filter CAなんたら～というのが出ていました。ググったところによると、ESETはhttpsでデータを取得するとき、ESET自身がhttpsで暗号化されたデータを取得したあと、PC内で一旦展開して内容をチェック、更にESET自身の証明書を付けてデータを元アプリに渡すとか何とか・・・（ゴニョゴニョ、詳しいことはよく分かりません！！中間者攻撃がやる方法と同じような方法で接続先との間に立って内容をチェックしているとか何とか・・・）。今回はどうもその部分が何故かぶっ壊れていたのだろうと推測します。

この問題が出ておかしくなったPCは２台。その他にも、ESETを入れているPC４台で調べてみたけれど、この現象は出ていませんでした。何か発動条件があるのだろう。

ちなみに、ERR_CERT_COMMON_NAME_INVALID問題が発生している状態で、そのエラー・警告を無視して続行すると、変なページに飛ばされていました。例えば、えいちてぃーてぃーぴー　コロン　スラッシュスラッシュ vebee ドット info とか（↓）、

他には、何故かApache2 Ubuntuのページとか（↓こんなヤツ）。

「飛ばされる」とは言ってもリダイレクトではなく、ブラウザのアドレスバーは自分で入力したURLのままで、ページの内容がこれらの妙なページが表示されるという不思議な状態でした。

備忘録：Windows10のバックアップ設定が開けない場合の対処

Windows 10の［バックアップと復元］（コントロールパネルで言うところの［コントロール パネル\すべてのコントロール パネル項目\バックアップと復元 (Windows 7)］）がエラーのせいで開けないとき、コマンドプロンプトを管理者権限で開いて、

wbadmin delete catalog

を実行すると開けるようになった！

[備忘録]ListViewCtrlでLVIS_SELECTEDなアイテムの色を変える方法

ListViewCtrlのアイテムの色を変える方法自体は、カスタムドロー（NM_CUSTOMDRAW）でできることは知っていて実際に使っていました。しかし、LVIS_SELECTEDで選択されたアイテムの色を変える方法、そして、そのListViewCtrlがフォーカスを外れても、同じ選択状態の色で表示する方法がどうしても分からなかったのですが、ようやくその方法が分かりました。それは、、、

カスタムドローのハンドラ内で、CDDS_ITEMPREPAINTイベントが来た時、

  lpCustomDraw->clrTextBk = RGB(x,y,z);

  lpCustomDraw->nmcd.uItemState = CDIS_DEFAULT;

とuItemStateの値を変更しておく、というものです。

この値を変更せずにそのままにしておくと、以降のカスタムドローイベントでデフォルト処理が走ってしまい、LVIS_SELECTEDなアイテム（ハイライトされたアイテム）はデフォルトのハイライト色で描画されてしまっていました。特に、フォーカスを失った時は選択表示でなくなってしまうか、LVS_SHOWSELALWAYSスタイルを付けていても薄いグレー表示になるので見にくかったですが、この方法で完全に選択された表示を維持できるようになりました。

[備忘録]64bit版Cygwin上で、32bitアプリを実行する

昔Cygwin上で使っていたsh-elf向けGCCを動かす必要が出てきたので、再度Cygwinをインストールして動かしてみたところ、エラーで動かない。

sh-elf-gcc.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

原因：64bit版Cygwinで32bit版実行ファイルを動かそうとしても、必要な32bit版共有ライブラリが見つからない。

対処：Develカテゴリのcygwin32パッケージをインストールすると動くようになるらしいが、今回のケースでは動かなかった。sh-elf-gccがcygintl-2.dllを要求しているが、どうやってもこのファイルをインストールすることができなかった。

回避策：たまたま見つけたcygintl-3.dllをcygintl-2.dllにリネームして使う。推測だが、これらの共有ライブラリは目的とする機能は同じでバージョンのみ違うと思われるので、使える可能性大。もちろん、このdllも32bit版である必要がある。

Cygwinには依存ライブラリを調べられるcygcheckがあるが、64bit版cygcheckは32bitバイナリの依存ライブラリを調べられない。代わりに、Dependency Walkerで調べるとcygintl-2.dllのほか、cygiconv-2.dllとcygwin1.dllを要求していることが判明。これらの32bit版ライブラリは比較的すぐに見つかった。

これらの共有DLLを適当なディレクトリにまとめて置いておく。そして、sh-elf-gccを実行するときには、

PATH=(32bit用DLLを置いたディレクトリ):$PATH sh-elf-gcc

とすることで、sh-elf-gccを使うときだけそのディレクトリにパスを通す。

これで、64bit用Cygwinでも、32bit用sh-elf-gccが動くようになった。

パサートヴァリアント2019年年間燃費

2019年の１年間で合計45252km走り、年間の平均燃費は19.74kmでした。

DSGの不安も完全に払拭されたので、アクセルは結構踏んでます。加速が必要なときはSモードを使う方が、ダウンサイジングターボ＋DCTの組み合わせには合っていると感じます。と言っても、先行車が居ることがほとんどなので、Dモードでゆっくり加速になることが多いです。
高速道路では走行車線で85km/hの巡航速度を保って大型車と同じくらいのスピードで走ることが多いので、燃費を稼ぐのは容易ですね。巡航速度をできるだけ長く保つことと、巡航速度まで如何に効率的に加速するかが重要と思われます。個人的にはふんわり加速すれば燃費に良いとは思えないです。アクセルをグイグイ踏んでも平均燃費への影響は小さいようです。「高速道路or郊外道路中心の乗り方で」という条件付きですが。

[備忘録]GitBacketのバージョンアップ顛末

GitBucketのバージョンアップに苦労した（というか、やり方が分からなかった）ので、その記録。

もとのバージョンはGitBucket 3.7、これを4.32.0に上げようと思いました。理由は、最近「git cloneが猛烈に遅い病」にかかっていることが判明して色々と調べたところ、どうもGitBucket自体が怪しいということになり、アップデートする決意をしました。
git cloneが遅くなる現象は、ネットでいくつか質問サイトに上がっていました。大体の回答は、大きなファイルをpushしたんだろう、とか、git fsck/git gcしたりしてリポジトリを整理したらというアドバイスが多かったように思いますが、スッキリそれで直ったという回答はあまり無かったように思います。実際、fsck/gcで改善しなかったし、大きなファイルもpushしていない、リポジトリサイズもそんなに大きくないので、当てはまる感じはしなかったです。

結局、

• どのクライアントからgit cloneしても猛烈に遅いこと
• GitBucketがホストしているすべてのリポジトリで同様であること
• GitBucketを通さずにgitサーバPC上のベアリポジトリを直接ファイルシステムからcloneすると問題ないこと

など総合的に考えて、リポジトリの破損が原因ではなく、GitBucketがトラブっているものと推測しました。


で、アップデートの方法ですが、GitBucketを停止して、gitbucket.warファイルを入れ替えれば済むものと思っていたけれど甘かった。3.x系から4.x系に上げるには、3.x系の最終版である3.14へのバージョンアップを経由してから、4.0に上げないといけないらしいということは検索で早めに調べがついていました。


3.7→3.14への移行方法：

ここでは、かなりの試行錯誤が必要でした。結果的にうまく言った方法は次のようなものでした。

1. 使っていた3.7のデータベースを、H2にてSQLファイルにエクスポート（バックアップ）
2. まっさらの状態でGitBucket 3.14を起動して、H2 ConsoleからエクスポートしたSQLファイルを実行して読み込み。
3. 上記２で生成されたdata.mv.dbファイルに入れ替えてから、再度3.14を起動。

これで、3.7のときのユーザー設定やリポジトリ設定が3.14に移行できました。

1.のエクスポートは、GitBucket 3.7のWEB-UIが起動しなかったので、たけぞうさんの指示通り、直接データベースから引き抜きました。

java -cp h2-1.4.190.jar org.h2.tools.Script -url jdbc:h2:~/.gitbucket/data -user sa -password sa -script backup.sql

なお、h2-1.4.xxxx.jarファイルは、tmpディレクトリにあるものを使いました。tmpディレクトリは c:\Users\(ユーザー名)\.gitbucket\ にあるもので、gitbucket.warを起動したときに展開される中身（jarライブラリ）のようです。

また、2.のSQLファイル実行は、GitBucket内のH2 Consoleから、次のように入力しました。

RUNSCRIPT FROM 'backup.sql'

SQLの結果は、デフォルトの接続先DBである、~/test.mv.dbに出力されていました。

3.14→4.0への移行方法：

これは、単純にgitbucket.warファイルの入れ替えだけで、データベースをうまくアップグレードしてくれました。要は、GitBucketを停止させてから、gitbucket.warファイルを更新し、再起動するだけです。

4.0→4.32への移行方法：

上と同じように、gitbucket.warファイルを入れ替えるだけで良かったのですが、いきなりバージョンを上げるとエラーが出ることが多かったです。4.0→4.1→4.2→・・・とチマチマ上げていかないと、起動時にエラーが出ました。そして、エラーが出るとデータベース

ファイルが更新されているのか、元のバージョンに戻してもエラーが出続けることがありました。つまり、うまくいったらデータベースのバックアップを取っておかないと、最初からやり直しになることがありました。

とはいえ、すべてのリリースバージョンを１つ１つ実行しないといけないわけでも無いようです。２～３つ飛ばしても、エラーは出ずにうまくデータベースを更新する時もありました。

ここまで細かくきざむ必要はなかったかも知れませんが、覚えている範囲では次のようなバージョンステップを踏みました。

4.0→4.1→4.2.1→4.3→4.5→4.6→4.7.1→4.8→4.9→4.10→4.11→4.12.1→4.13→4.14.1→4.15.0→4.19.3→4.20.0→4.25.0→4.26.0→4.27.0→4.28.0→4.29.0→4.30.0→4.31.0→4.32.0

これで、3.7のときの各種設定のまま、4.32.0に移行できました。ここまで約１日半くらいかかっていました。

ようやく、元の問題である「git clone超スロー病」が解決したかどうか試すことができる段階になったのですが、時間切れとなりましたので、それはまた別の日に。