Ticket #44436

TTXBind()関数の引数 Version の仕様

Open Date: 2022-04-22 07:57 Last Update: 2022-05-17 00:30

Reporter:
Owner:
(None)
Status:
Open
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
None
File:
6
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

TTXプラグイン登録時 TTXBind() 関数呼び出しの引数 Version は以前から 23 となっている。
特に意図していないなら Teraterm Pro version 2.3 を指す?23ではなく、動作するTeratermのバージョンを指定してもよいのではないでしょうか。

Ticket History (3/24 Histories)

2022-04-22 07:57 Updated by: tomo3136
  • New Ticket "TTXBind()関数の引数 Version の仕様" created
2022-04-23 02:21 Updated by: doda
Comment

そうですね。 5.0でTTXの互換性が一部無くなったので、両対応のTTXを作れるようにする為にもバージョンを上げるいい機会だと思います。

新しいバージョンが出るたびに上げていくかは検討が必要だと思います。

毎回上げるとすると、5.0で50だと5.10が出た時に問題になるので500スタートの方がいいでしょうか。 59 -> 510 でも大小関係は保たれるのでそれでいいのかもしれませんが。

毎回上げず、互換性に影響がある変更があった場合のみ上げるようにするならば50から1ずつ増やすので問題ないでしょう。

2022-04-26 06:38 Updated by: tomo3136
  • File ttx用差分メモ.xlsx (File ID: 9109) is attached
2022-04-26 06:39 Updated by: tomo3136
Comment

一番の目的は、4.106 以下と 5 以降の分離だと思います。

理想は「毎回上げず、互換性に影響がある変更があった場合のみ上げる」なのですが、 何をもって「互換性に影響がある変更」とするかが問題と思います。

TTXでの互換性は、バイナリ互換であってほしいので対象は以下と考えられます。

  1. TTXExports 構造体のメンバ
  2. TTXExports メンバ関数の引数のフック関数テーブル
  3. フック関数の引数
  4. PTTSet, PComVar, PGetHNRec, PKeyMap の構造体
  5. 構造体メンバや変数で使う値(IdTCPIPなど)
  6. ウインドウハンドラに投げるメッセージIDやパラメータ

TTX API の互換性で見たら (1)-(3) といったところでしょうか。この範囲内なら50 から 1 ずつ増やすでもよさそうです。

(4) も互換性の有無は判別できるとは思いますが、リリース直前まで上げるのか上げないのか迷いそうです。

(5)-(6) も含めるなら、互換性の管理は難しいため、毎回上げてTTXプラグイン側に判断を丸投げといったところだと思います。


PTTSet の RunningVersion は、構造体中のオフセットが最後のほうにあり、 今後リリース時にオフセットが異なってしまう可能性があります。 それならば、毎回上げて TTX プラグイン側で判断したほうがよさそうです。

ちなみに v4.106 と v5.0alpha(r9858) のバイナリ互換は LogDefaultName[] までとなります。 (LogDefaultPath[] が *LogDefaultPathW となったため)


よって、自分の見解では 引数の Version は、 RunningVersion のように自動で計算させたほうが後々面倒がないのではと思っています。

RunningVersion は、メジャーバージョン *10000 としていますが、引数の Version は、 WORD 型(2バイト分)なので、 *1000 か *100 くらいで良いと思います。

マイナーバージョンが 100 を超えると読みにくく、 *10 では心もとないので *100 (500スタート)のほうが良いのではないでしょうか。

バージョン間の差分を簡易的に調べてみたので添付します。

2022-04-26 06:58 Updated by: tomo3136
  • File ttx用差分メモ.xlsx (File ID: 9109) is deleted
2022-05-12 22:30 Updated by: nmaya
Comment

ちなみに v4.106 と v5.0alpha(r9858) のバイナリ互換は LogDefaultName[] までとなります。 (LogDefaultPath[] が *LogDefaultPathW となったため)

がんばって互換性を維持しても無駄になるかもしれませんが、これは構造体の途中にメンバを追加したり、削除・変更したりするのではなく、追加するなら一番最後にし、使わなくても予約として残す、というお作法を破っている感じですか?(むかし何か追加したときに注意されたような記憶が…)

2022-05-13 06:51 Updated by: tomo3136
  • File TTXTest_TTTypes.zip (File ID: 9213) is attached
2022-05-13 06:51 Updated by: tomo3136
  • File TTXTest_TTTypes.zip (File ID: 9214) is attached
2022-05-13 06:51 Updated by: tomo3136
  • File TTXTest_TTTypes.zip (File ID: 9215) is attached
2022-05-13 06:52 Updated by: tomo3136
  • File TTXTest_TTTypes.zip (File ID: 9215) is deleted
2022-05-13 06:52 Updated by: tomo3136
  • File TTXTest_TTTypes.zip (File ID: 9214) is deleted
2022-05-13 06:52 Updated by: tomo3136
  • File TTXTest_TTTypes.zip (File ID: 9213) is deleted
2022-05-13 06:52 Updated by: tomo3136
Comment

そうですね。お作法は破られていますね。

お作法通り、追加するなら一番最後とするのが下位互換性を保てて良いかと思いますが、v4.xx の間にも何度か構造体のバイナリ互換性は失っています。

「Tera Term 5 について」https://ttssh2.osdn.jp/manual/5/ja/usage/migrate_to_5.html にて、

最後の行に「まだ変化する予定(メンバ名、順序、サイズ、型などなど)。」とあるので、

パス名が固定長配列から動的配列に移行したり、今後も構造が変わり、バイナリ互換性は失うと推測されます。

考え方を変え、お作法守るよりは、ビルドは最新のみとし、できるだけ下位互換性を得られるように

構造体のマッピング変換機能を持たせるようにしてみました。

テスト用のプラグインのソースコードを添付します。(TTXTest_TTTypes.zip)

tttypesフォルダは ttxversion_db.h のジェネレータ
TTXBind()で実行バージョンを登録し、TS()マクロやCV()マクロを使用して実行バージョンに合った構造体でアクセスします。
ついでに、TTXBind()で構造体にメンバが無ければプラグインを使用しないようにしています。

配列サイズが異なったり、細かい個別案件はあるものの 8 割くらいは、下位互換性を持たせられると思います。

v5.0 でビルドしたプラグインを v2.3 の環境にもっていってもボーレートの値 (ts->Baud) を取得できます。

プラグインが使用する構造体のメンバーは通常ほんの一部しかないのと思うので、プラグインの下位互換性を考慮して

構造体の変更にブレーキをかけるよりは、健全かなと思います。

構造体のバイナリ互換をあまり気にしなくなっても、大きく変更したらやはり互換性を保てなくなるので なんでもできるわけではないのですが。。。

2022-05-14 03:10 Updated by: zmatsuo
Comment

r9922 で LogDefaultPathの領域をリザーブとして確保するようにしました。

ANSI文字列でパスを入れていないので ここを参照しているプラグインがあると正常に動作しないことになります。 この対応では不十分ですね。

ひとまずは、このメンバー以降のオフセットが同じになったはずです。

Unicode,ANSI両方の文字列が準備されているメンバーもあるじゃないか、 と思われると思います。 互換性を持たせるためというのもありますが、 まだ作業中で手がついていない状態というのもあります。 できるところからやっていっています。

Tera Term プロジェクト内のソースでは LogDefaultPathは参照していなくて、 LogDefaultPathW を使っています。このメンバーについてはUnicodeへ移行した状態ですね。

プラグインの、バイナリ互換はちょっとしんどくて、ソース互換な感じで考えるのがよさそうかなと思います。

提案いただいている方法まだ見れていません。考えてみますね。

他にも直したほうがよいところがあったら指摘ください。

2022-05-14 07:33 Updated by: tomo3136
Comment

| ひとまずは、このメンバー以降のオフセットが同じになったはずです。

修正ありがとうございます。 オフセットは同じになるように調整されてることを確認しました。 簡易解析なので、ビルドして動作確認してみないととだめですが、とりあえずチェック結果だけ報告します。

  • 変更前 v4_106-v5_0(r9903).png
  • 変更前 v4_106-v5_0(r9922).png

ただ、すぐに EtermLookfeel の事前領域確保対応によるオフセットずれになるのあまり差はないと思われます。

各バージョンのオフセット比較用データも添付します。(dataフォルダ下、v5_0がr9903でv5_1がr9922に相当)

| プラグインの、バイナリ互換はちょっとしんどくて、ソース互換な感じで考えるのがよさそうかなと思います。

そうですね。全体として決まれば、ソース互換でもよいのでないでしょうか。

2022-05-15 00:56 Updated by: zmatsuo
Comment

| EtermLookfeel の事前領域確保対応によるオフセットずれ

対応したのを思い出しました(r9109) trunk(Tera Term 5)では対応していません。

eterm_lookfeel_t のメンバーを1つ減らせれば、 構造体でまとめた状態+互換性がある状態にできるか?・・

2022-05-15 08:10 Updated by: tomo3136
Comment

eterm_lookfeel_t のメンバーを1つ減らせれば、 構造体でまとめた状態+互換性がある状態にできるか?・・

バイナリ互換も目指すなら、構造体(eterm_lookfeel2_t)を追加して、追加分を最後に移動すればよいのではないでしょうか (a.patch)

次の範囲で互換性があるといえると思います。

  • tttset v4.67 - v5.0
  • TComvVr v4.89 - v5.0
2022-05-17 00:30 Updated by: zmatsuo
Comment

こんなことを考えながら調べてみます。

  1. vtdisp.cpp でテーマってどんなふうになってるんだろう? ticket #44376 (半透明の仕様)
  2. eterm_lookfeel_t.BGIgnoreThemeFile はなぜ必要だったのだろう?
  3. どうして再起動しないと背景は変更できないんだろう?
  4. ticket #44048 (iniファイル読み込みのUnicode化)

BGIgnoreThemeFile が ts になくてもよいならよいのですが・・。

Attachment File List

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login