[ 新規に投稿する ]

ライブラリ作者への連絡についてNo.38448
fzok4234 さん 20/10/06 00:30 [ コメントを投稿する ]
  現在ライブラリに掲載されているマクロや強調表示などの開発者さんへの
不具合報告などの確実な連絡方法がわかりません。

当方において現在、こみやんま氏のhm.NET v1.701で不具合が出ており、
https://www.maruo.co.jp/turukame/4/x00614_.html?a=4#614
にて報告させていただきました。
しかし10日経った現在、一向に返答がなく、またこみやんま氏のサイト
http://xn--pckzexbx21r8q9b.net/
にも不具合報告のためのメールアドレス等がなく、こちらから連絡の取りようが
ない状態です。このため、hm.NETから呼び出されるDLLの作成に支障をきたして
おります。

現在、ライブラリの「データの登録」フォームにはメールアドレスなどの
確実な連絡手段の掲載が義務付けられていないため、掲載物に不具合が
見つかっても確実に報告ができないのが現状です。



[ ]
RE:38448 ライブラリ作者への連絡についてNo.38449
秀まるお2 さん 20/10/06 09:10 [ コメントを投稿する ]
   ここのサポート会議室に入会するのにメールアドレスが必要で、そのメールアドレスは僕(というか、フォーラム管理者)には分かります。

 そのメールアドレスで一回連絡してみます。

 進捗があったらまたお返事させていただきます。
[ ]
RE:38449 ライブラリ作者への連絡についてNo.38450
fzok4234 さん 20/10/06 09:14 [ コメントを投稿する ]
  御社での対応ありがとうございます。
[ ]
RE:38450 ライブラリ作者への連絡についてNo.38451
秀まるお2 さん 20/10/07 14:22 [ コメントを投稿する ]
   今のところお返事が無いのですが、作者のこみやんまさんはgithubにアカウントを持っておられるようです。

   https://github.com/komiyamma

 GitHub経由で連絡する手段があるのかもしれませんが、難しいみたいな話です。

 参照:https://qastack.jp/webapps/29197/any-way-to-contact-a-user-on-github

 GitHubにソースコードも上がってるようなので、ご自身でビルドしてデバッグするって手もあるかなぁとは思いますけども。ハードル高いかもしれませんが。
[ ]
RE:38451 ライブラリ作者への連絡についてNo.38452
fzok4234 さん 20/10/07 15:34 [ コメントを投稿する ]
  > GitHubにソースコードも上がってるようなので、ご自身でビルドしてデバッグするって手もあるかなぁとは思いますけども。ハードル高いかもしれませんが。

ソースコードを少し拝見しましたが、C#だけで書かれた純粋な.NETアプリではなくて
C/C++によるWin32アプリであったため、これを自力で修正するにはかなり
Win32プログラミングに精通している必要があるため、.NETプログラミングしか
やっていない自分にとっては非常にハードルが高いでしょうね。

[ ]
RE:38452 ライブラリ作者への連絡についてNo.38454
秀まるお2 さん 20/10/08 15:11 [ コメントを投稿する ]
   C++でマネージドコードを使ってるので僕もまったく経験無いんですが、ビルドしてトレースして例外発生箇所を特定して、ネット検索していろいろ試行錯誤してうまく動くように出来たと思います。

 HmNET.cppの98行目付近にある

        MethodInfo^ m = t->GetMethod(method_name);

 とある所を以下のように直せばうまく動くと思います。

        MethodInfo^ m;
        try {
            m = t->GetMethod(method_name);
        }
        catch (Exception^ e) {
            List<Type^>^ tt = gcnew List<Type^>();
            int i;
            for (i = 0; i < args->Count; i++) {
                tt->Add(args[i]->GetType());
            }
            m = t->GetMethod(method_name, tt->ToArray());
        }

 どうでしょうか。

 Visual Studio 2019にソリューションを読み込んで、変換とかが入りましたが、うまくビルドは出来ました。ソリューションの中「hm.NET」の上でマウス右ボタンメニューを出して「ビルド」とすると、hmNET.dllがビルドできると思います。普通に「ビルド」メニューからビルドするとdllのビルドにならず、static-libraryのビルドになってしまいました。
[ ]
RE:38454 ライブラリ作者への連絡についてNo.38455
fzok4234 さん 20/10/09 06:11 [ コメントを投稿する ]
  わざわざソースコードの修正方法の考案ありがとうございます !!

当面はこの修正を行った「サイトー企画版hm.NET」でしのげることができると
思います。あとは、本家こみやんま氏がこの修正に準じた新バージョンを
リリースするのを待つだけです。

[ ]
RE:38455 ライブラリ作者への連絡についてNo.38471
秀まるお2 さん 20/10/12 17:28 [ コメントを投稿する ]
   Issuesって所に書き込むことが出来たと思います。

https://github.com/komiyamma/hidemaru-net/issues

 これ見てくれるといいですが。
[ ]
RE:38471 ライブラリ作者への連絡についてNo.38474
fzok4234 さん 20/10/12 19:53 [ コメントを投稿する ]
  GitHubにも意見などの書き込みができるのですね。

一応こちらからも、こみやんま氏のTwitterアカウントのプライベートメッセージに
10月2日付けで不具合報告の書き込みは行っていますが、まだ返事がありません。

[ ]
RE:38471 ライブラリ作者への連絡についてNo.38500
fzok4234 さん 20/10/21 10:54 [ コメントを投稿する ]
  最初の投稿からもうすぐ1ヵ月経とうとしているのに、こみやんま氏の方からの連絡は一向に
ありませんね。GitHubとTwitterの方も同様です。

このような状況から思ったことがあるのですが、ライブラリへの登録で、著作権をサイトー企画に
譲渡する形でビルド/バグフィックス/アップデートなどの管理をサイトー企画に全て任せる
オプションを設ける、という案はどうでしょうか?

マクロや強調表示などのライブラリをざっと眺めていると、強調表示の対応言語バージョンが
古かったり、DLL形式のマクロでは64bitビルドが行われず32bit版秀丸エディタのみ対応と
なっていたり、アップロードされている書庫形式がセキュリティ上問題のあるLHA形式だったりなど、
アップデートなどが全く行われずに管理放棄された状態の物が散見されます。もちろん、
ライブラリの開発者に悪気があるわけではありません。しかし、数百KBにも及ぶ強調表示や
DLLにビルドされたマクロ等、もはやれっきとした「アプリ」としての性格を持ったライブラリは
きちんと管理などのサポートがなされている事が望ましいと感じます。

とりわけ、今回のhm.NETに関しては、マクロと.NETのマネージドコードとの連携を行う上で
無くてはならない存在のため、サイトー企画側でも管理がされていればと思うばかりであります。
通常、秀丸マクロとの連携に対応している別プログラムは原則としてC/C++言語を用いてWin32 APIを
バリバリ使用する「ネイティブコード」に限定されています。しかし、ネイティブプログラミングと
いうのは現状、生のポインターを扱うためバッファーオーバーフローなどの回避のため最善の限りを
尽くさねばならないこと、ヒープ領域に書き込んだデータは手動で開放しなければならないこと、
それらのスキルを身に着けた上で複雑怪奇で危険なWin32 APIを触らねばならないこと等、今時の
.NETやJavaやPython等の生ポインターが無くガベージコレクション等の便利な機能のそろった
オブジェクト指向なマネージドプログラミングしか行っていない人にとっては極めて敷居が高い
物となっています。そのような中で、もし秀丸マクロと.NETやJavaやPython等の「マネージドコード」との
連携を実現させるDLLが存在するならば、それは正に夢のような「魔法のDLL」であり、現在主流の
マネージドプログラマーにとって無くてはならない存在となります。

今後秀丸エディタが生き残るうえで、マクロとの連携プログラムが敷居が高くかつ危険なアンマネージド
コードでしか作ることが出来ないという事は、マネージドコードが主流の昨今の情勢下では大きな
痛手になっていると私は感じています。理想としては、マクロとマネージドコードとの連携機能が
「秀丸エディタの生き残りを賭けて」初めから秀丸エディタに実装されいることが望ましいと
私は思いますがいかがでしょうか?

[ ]
RE:38500 ライブラリ作者への連絡についてNo.38503
秀まるお2 さん 20/10/21 16:12 [ コメントを投稿する ]
   いろいろ問題があるようですが、うちの会社的にいくらでも対応できる訳でもないので、なかなか難しい所ではあります。

 とりあえず、ライブラリにアップロードしていただく時に、著作権や改変について申告してもらうというのは1つのアイデアとしていいかなぁと思います。

 □ 第三者による改変と、改変されたバージョンの公開を許可する
   (ただし改変元が何であるかの表示は必要とする)

 □ サイトー企画による改変と、改変されたバージョンの公開を許可する
   (ただし改変元が何であるかの表示は必要とする)

 の2つのチェックマークを付けたらいいかなぁと思います。

 マクロなら僕の方で直すのは対応できると思いますが、今回のようなC++言語やその他の言語で書かれた物は、直せない可能性もあるし、そもそもソースコードが公開または添付されてなければ直しようが無いですけども。

 マネージドコードで作成されたDLLを秀丸マクロから呼び出すことについてのニーズはちょっと僕も分からないのですが、しいてサイトー企画で対応するとしたら、こみやんまさんがすでに作成された物があるので、それをサイトー企画で改変メンテナンスさせてもらう形が一番いいかなぁと思います。ゼロから作るのはちょっと無理がありそうな気がします。

 とりあえず、ライブラリの登録フォームの改良だけ一回トライしてみます。
[ ]
RE:38503 ライブラリ作者への連絡についてNo.38505
fzok4234 さん 20/10/21 17:13 [ コメントを投稿する ]
  ご検討のほうありがとうございます。

> とりあえず、ライブラリにアップロードしていただく時に、著作権や改変について
> 申告してもらうというのは1つのアイデアとしていいかなぁと思います。
>
> □ 第三者による改変と、改変されたバージョンの公開を許可する
>   (ただし改変元が何であるかの表示は必要とする)
>
> □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>   (ただし改変元が何であるかの表示は必要とする)
>
> の2つのチェックマークを付けたらいいかなぁと思います。
>
> マクロなら僕の方で直すのは対応できると思いますが、今回のようなC++言語や
> その他の言語で書かれた物は、直せない可能性もあるし、そもそもソースコードが
> 公開または添付されてなければ直しようが無いですけども。

このオプションを選択するときには、ソースコードおよびビルド方法の説明の
公開/添付を義務付けしたほうが良いでしょう。また、バイナリの掲載については、
サイトー企画側でビルドおよびデジタル署名の埋め込みを行ったものを掲載する
という方針にした方が良いと思います。これは、ウイルス混入を防止するための
「審査」を兼ねてのことです。

> マネージドコードで作成されたDLLを秀丸マクロから呼び出すことについてのニーズは
> ちょっと僕も分からないのですが、しいてサイトー企画で対応するとしたら、
> こみやんまさんがすでに作成された物があるので、それをサイトー企画で改変メンテナンスさせて
> もらう形が一番いいかなぁと思います。ゼロから作るのはちょっと無理がありそうな気がします。

約1ヵ月も連絡が無いという事は、縁起の悪い話ですがこみやんま氏本人が
他界されたのではと疑ってしまいます。こみやんま氏は.NETのほかにJavaや
Python等とマクロとの橋渡しDLLをオープンソースで公開しています。もしもの
時も考慮して、こみやんま氏本人に無許諾でこれらのDLLの管理をサイトー企画側で
行うのも良いかもしれません。


[ ]
RE:38503 ライブラリ作者への連絡についてNo.38506
Iranoan さん 20/10/21 17:22 [ コメントを投稿する ]
  秀まるおさんこんにちは Iranoan です
>  とりあえず、ライブラリにアップロードしていただく時に、著作権や改変について申告してもらうというのは1つのアイデアとしていいかなぁと思います。
そういえば、ライセンスについて明示していないケースも有りそうですね

>  □ 第三者による改変と、改変されたバージョンの公開を許可する
>    (ただし改変元が何であるかの表示は必要とする)

>  □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>    (ただし改変元が何であるかの表示は必要とする)

>  の2つのチェックマークを付けたらいいかなぁと思います。
これに加えて、
□ その他 [                ]
を用意して、既存のライセンスを書き込めるようにしてはどうでしょう?
PDS, GPL, BSD, Apache License などを書き込めるようにしておくわけです
[ ]
RE:38506 ライブラリ作者への連絡についてNo.38507
秀まるお2 さん 20/10/21 17:35 [ コメントを投稿する ]
   ライブラリの仕組みを今からいろいろいじるのはちょっと大変なので、やっぱり、

>  □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>    (ただし改変元が何であるかの表示は必要とする)

 だけ追加して、その情報はあくまでサイトー企画にだけ分かるようにしようかなぁと思います。

 あと、連絡先のメールアドレスを入れていただく欄も無いので、それも追加しないといけないです。(前々から思ってたことではありますが)

 この辺の改変は、ライブラリの登録フォームをいじる+アルファ程度で出来そうな気がするので。

> □ その他 [                ]
> を用意して、既存のライセンスを書き込めるようにしてはどうでしょう?
> PDS, GPL, BSD, Apache License などを書き込めるようにしておくわけです

 ライブラリにこの辺の表示をする機能を追加するのはちょっと大変なので、やっぱりこの辺はやめとこうと思います。

 ぼちぼち暇を見て対応しようと思います。
[ ]
RE:38505 ライブラリ作者への連絡についてNo.38508
秀まるお2 さん 20/10/21 17:37 [ コメントを投稿する ]
   こみやんまさんくらいの能力のある方だと何か他の仕事されてるんじゃないかという気もしますけども・・・。日本にいないかもしれないし。

> こみやんま氏は.NETのほかにJavaや
> Python等とマクロとの橋渡しDLLをオープンソースで公開しています。もしもの
> 時も考慮して、こみやんま氏本人に無許諾でこれらのDLLの管理をサイトー企画側で
> 行うのも良いかもしれません。

 GitHubに公開されてる物の改変および改変物の公開とかのルールがどこかにあって、もしも僕が勝手に改変して公開してもいいってことなら対応してもいいですが・・・。

 あんまり余計なことをして問題になるのもいやなので、とりあえずはやめとこうと思います。
[ ]
RE:38508 ライブラリ作者への連絡についてNo.38509
でるもんたいいじま さん 20/10/21 18:27 [ コメントを投稿する ]
  でるもんた・いいじまです。

> > もしもの時も考慮して、こみやんま氏本人に無許諾でこれらのDLLの
> > 管理をサイトー企画側で行うのも良いかもしれません。

> GitHubに公開されてる物の改変および改変物の公開とかのルールが
> どこかにあって、もしも僕が勝手に改変して公開してもいいって
> ことなら対応してもいいですが・・・。

GitHubとしての統一ルールはないようですが、hm.NETに関しては「MITライセンス」と明記されています。

なので、誰でも自由に修正・改良できますし、そうやって手を入れたバージョンを再配布するのも自由です。

#GitHubの当該フォルダに LICENSE.txt というファイルがあって、
#そこに英語でライセンスの内容が書いてあります。
#MITライセンスの日本語訳は、ここの目次ページへリンクしておくのがいいでしょう:
https://licenses.opensource.jp/

その一方で、修正履歴(リポジトリ上の「History」をクリック)を見ると概ね1年間隔で大きな修正に取り組んでいるようで、こみやんま氏は単純に多忙という可能性が高そうです。

☆ ☆ ☆

なので落としどころとしては、このあたりだと思います:

@当分のあいだ、今回の修正を入れたDLLをhide.maruo.co.jpあたりで配布する。
 ※hm.NETの具体的な使い方はそちらには記載せず、必要に応じて
  詳しいサイトへの誘導を行う。
 ※今回の修正内容をdiffファイルか何かにして、DLLと同様に配布する。
  ソースコード全部を再配布する必要はない。

Aこみやんま氏と連絡が取れ次第、公式版に今回の修正内容を反映して
 いただく。

Bその後の扱いについては別途検討。

☆ ☆ ☆

以下、余計なお節介かとは思いますが、今回の修正内容のdiffを添付します。
ファイルの文字コードはShift_JISになっていますね。

--- hmNET.cpp.orig      2020-10-21 18:18:17.014423000 +0900
+++ hmNET.cpp   2020-10-21 18:20:09.654593400 +0900
@@ -95,7 +95,20 @@
                        TraceMethodInfo( assm_path, class_name, method_name);
                        return nullptr;
                }
-               MethodInfo^ m = t->GetMethod(method_name);
+
+               MethodInfo^ m;
+               try {
+                       m = t->GetMethod(method_name);
+               }
+               catch (Exception^ e) {
+                       List<Type^>^ tt = gcnew List<Type^>();
+                       int i;
+                       for (i = 0; i < args->Count; i++) {
+                               tt->Add(args[i]->GetType());
+                       }
+                       m = t->GetMethod(method_name, tt->ToArray());
+               }
+
                Object^ o = nullptr;
                try {
                        // デタッチ関数の時に、引数が無いパターンを許す
[ ]
RE:38500 ライブラリ作者への連絡についてNo.38510
でるもんたいいじま さん 20/10/21 19:51 [ コメントを投稿する ]
  でるもんた・いいじまです。順番が前後しますが…。

> このような状況から思ったことがあるのですが、ライブラリへの登録で、
> 著作権をサイトー企画に譲渡する形でビルド/バグフィックス/アップデート
> などの管理をサイトー企画に全て任せるオプションを設ける、という案は
> どうでしょうか?

秀まるおさんからコメントが付きましたが…

コミュニティによっては、すべての参加者が特定のライセンス条項に従うよう
求めているところがありますね。
Mozilla Firefox/Thunderbird の開発コミュニティなどが典型的ですが、
OS界隈でもLinux陣営は極力GPL適合のコードだけでまとめようとしていて
(GPLなものがなければわざわざ作り直してしまうこともあります。
 OpenSSLの代替としてGnuTLSが開発されたとか)、逆にFreeBSD界隈では
GPLを強制するコードをシステムの中核からは排除しようとしているとか。

> マクロや強調表示などのライブラリをざっと眺めていると、
...
> アップデートなどが全く行われずに管理放棄された状態の物が散見されます。
> もちろん、ライブラリの開発者に悪気があるわけではありません。

これは今のライブラリの仕組みを継続する限り、難しいですね。
今から作り直すとしてもGitあたりの劣化コピーになっちゃうでしょうし、
かといってGitやSubversionといった既存のツールは高機能すぎて敷居が高い。

☆ ☆ ☆

それと、後半のネイティブコード(アンマネージドコード)とマネージド
コードの比較ですが、これは完全に神学論争だと思います。

マネージドバイナリを自作して使いたいという需要があることは何となく
理解できましたが、私の交際範囲にはマネージドコードを日常的に書いて
いる人が誰も思い当たらないので、正直言って実感がわかないのです。

なので、マネージドな開発環境が今は主流だというご主張についても、
「それは、どういう母集団での話ですか?」
というのが私個人の率直な感想です。

☆ ☆ ☆

もう一つ、秀丸はいまだに Windows 98 もサポート対象にしています。
工作機械の制御用などでいまだに需要があるからです。
(たぶん、いまWindows 98で動いているマシンが物理的に壊れたら、
 Windows XPかWindows 7あたりでリプレースされるでしょう。)

このへんも気になりますし、上記のように「どれだけ需要があるのか」
という疑問もありますので、今のところは秀丸本体には組み込まずに、
独立したDLLのままにしておいてほしいです。
(一緒に配布するだけなら特に問題はないと考えますが。)
[ ]
RE:38507 ライブラリ作者への連絡についてNo.38511
h-tom さん 20/10/21 22:53 [ コメントを投稿する ]
  h-tom です。

> ライブラリの仕組みを今からいろいろいじるのはちょっと大変なので、やっぱり、
>
>>  □ サイトー企画による改変と、改変されたバージョンの公開を許可する
>>    (ただし改変元が何であるかの表示は必要とする)
>
> だけ追加して、その情報はあくまでサイトー企画にだけ分かるようにしようかなぁ
>と思います。
改変するかもしれない理由を書いておいた方がいいのでは?
・マクロの場合、秀丸エディタのバージョンアップに伴い、動作しなくなった場合
・強調表示の場合、言語のバージョンパップに伴う変更
など。

しかし、個人的には「サイトー企画」さんがそこまで頑張らなくてもいいのでは、
と思いますけどね。
[ ]
RE:38511 ライブラリ作者への連絡についてNo.38512
石田 さん 20/10/22 00:52 [ コメントを投稿する ]
  私も初歩的なマクロをライブラリに登録させてもらっていますが、マクロ本体の他に、使用説明書に利用者さんからの問い合わせ用に、作者連絡先のメールアドレスを明記しています。

>こみやんま氏本人に無許諾でこれらのDLLの管理をサイトー企画側で行うのも良いかもしれません。
 利用者さんの問い合わせに返答しない作者さんの問題で、一々「サイトー企画さん」が面倒を見る性格じゃないと思います。これをやり始めたら、「サイトー企画」の本業が成り立たなくなると思います。

>しかし、個人的には「サイトー企画」さんがそこまで頑張らなくてもいいのでは、と思いますけどね。
 同感です。マクロを公開している以上、利用者からの問い合わせに応じるためにメールアドレスを明記するのが作者の道義だと思います。マクロ作者--利用者間の「無言の関係性」みたいなのがあると思います。

# 開発放棄して、返答したくないなら別ですが…………。
[ ]
RE:38510 ライブラリ作者への連絡についてNo.38513
fzok4234 さん 20/10/22 07:51 [ コメントを投稿する ]
  > マネージドバイナリを自作して使いたいという需要があることは何となく
> 理解できましたが、私の交際範囲にはマネージドコードを日常的に書いて
> いる人が誰も思い当たらないので、正直言って実感がわかないのです。

> なので、マネージドな開発環境が今は主流だというご主張についても、
> 「それは、どういう母集団での話ですか?」
> というのが私個人の率直な感想です。

Stack Overflowによる2019年の使用言語ランキング
https://insights.stackoverflow.com/survey/2019#technology-_-programming-scripting-and-markup-languages
では確かに、JavaScript/Python/Java/C#がそれぞれ1位/4位/5位/7位であるのに対して、
C++とCがそれぞれ9位と11位となっており、マネージド言語がアンマネージド言語を追い抜いて
いる結果となっています。一方、国内の日経xTechの2020年の調査
https://xtech.nikkei.com/atcl/nxt/column/18/01068/111100001/
では、1位にC/C++が来ているものの、2位/3位/5位/6位にそれぞれPython/JavaScript/C#/Javaが
迫ってきており、マネージド言語はもはやマイナーな存在ではないといえます。しかも、この
日経xTechの記事には「C/C++は組み込み機器や処理速度が求められるシステムに利用される
ことが多い」とのことで、よほど処理速度にこだわらなければ秀丸マクロの連携プログラム
(もちろんデスクトップアプリであり組み込み機器の制御コードでないのは自明)がC/C++で
なければならないことはない思います。

> もう一つ、秀丸はいまだに Windows 98 もサポート対象にしています。
> 工作機械の制御用などでいまだに需要があるからです。
> (たぶん、いまWindows 98で動いているマシンが物理的に壊れたら、
>  Windows XPかWindows 7あたりでリプレースされるでしょう。)

> このへんも気になりますし、上記のように「どれだけ需要があるのか」
> という疑問もありますので、今のところは秀丸本体には組み込まずに、
> 独立したDLLのままにしておいてほしいです。
> (一緒に配布するだけなら特に問題はないと考えますが。)

もちろん、hidemaru.exe自体にマネージドコード連携機能を追加するのはそれこそ「大改造」であり、
旧来の環境との互換性の問題が生じる危険性があります。そこで、マネージドコード連携機能は
別DLLにして同梱配布し、使用時はこれをloaddll()/freedll/dllfuncw()/dllfuncstrw()する形が
良いと思います。hm.NETはこのようにして使いますし、秀丸エディタのファイルマネージャー枠と
アウトプット枠もそれぞれHmExplorerPane.dllとHmOutputPane.dllという別DLLになっていて、マクロから
の使用時はこれをloaddll()/dllfunc()する形をとっています。


[ ]
RE:38512 ライブラリ作者への連絡についてNo.38514
秀まるお2 さん 20/10/22 08:50 [ コメントを投稿する ]
   とりあえず、チェックマークを用意しておいてサイトー企画の権利を確保しておくだけはやっておくという話でして、実際にマクロのメンテナンスをうちでやるかどうかは状況次第でという風にしようと思います。
[ ]
RE:38509 ライブラリ作者への連絡についてNo.38515
秀まるお2 さん 20/10/22 08:55 [ コメントを投稿する ]
   ライセンス関係に詳しくないので教えていただき助かりました。とりあえず僕が勝手に改変して公開しても問題なさそうということで・・・

 今の所は様子見させていただきつつ、このままずっとこみやんまさんと連絡が取れない場合は何か対策を考えてみます。
[ ]
RE:38514 ライブラリ作者への連絡についてNo.38518
秀まるお2 さん 20/10/22 14:31 [ コメントを投稿する ]
   アップロードする用のフォームに、

 □ 作者が音信不通になった場合にサイトー企画での修正および修正版の公開を承諾します 

 ってチェックボックスを付けるようにしました。ここのON/OFF状態は僕の所に届くだけですけども。
[ ]
RE:38513 ライブラリ作者への連絡についてNo.38519
秀まるお2 さん 20/10/22 14:36 [ コメントを投稿する ]
   僕もあまり詳しくないのでコメントが難しいのですが、とりあえず、テキストエディタのマクロ言語でそんなに大それたことはしないだろうし、あんまり本格的でなくてもいいんじゃないかという思いが根底にあったりしている所ではあります。

 一応、秀丸マクロから呼び出す用の何かをC#で作成するってことだけであれば、COMコンポーネントにしてもらう作戦もあるにはあると思います。
[ ]
RE:38519 ライブラリ作者への連絡についてNo.38521
fzok4234 さん 20/10/22 23:19 [ コメントを投稿する ]
  > テキストエディタのマクロ言語でそんなに大それたことはしないだろうし、あんまり
> 本格的でなくてもいいんじゃないかという思いが根底にあったりしている所ではあります。

実際、テキストファイルを扱うマクロ操作で、マクロの文や関数だけでは出来ない操作を
同時に行わなければいけない場面によく出くわします。例えば、フォルダー内のテキスト
ファイルのパスを再帰的に列挙したり、編集しようとしているファイルの属性やACLや監査設定を
変更したり等です。

これらの操作を行うためにはどうしても外部プログラムと連携しなければいけなくなりますが、
問題はこの外部プログラムの記述の難易度が高くなってはならないことです。現状ではこれを
アンマネージドコードのDLLにしなければならないため、マクロのみの記述に比べて極めて
ハードルが高くなってしまいます。C/C++のコンパイルのためにVisual Studioをインストール
しなければいけないですし、先に申した通りアンマネージドなWin32プログラミング自体が他の
マネージドプログラミングと比較して難易度が大幅に高いです。

それに比べてC#の場合、Windows 10に元からインストールされている.NET Framework 4.8に
csc.exeというC#コンパイラーが付属しているし、記述の難易度も秀丸マクロよりは難しいものの
アンマネージドコードに比べるとずっと低いです。あとは、誰かがhm.NETのような橋渡しDLLを
用意してくれればマクロ+αのやや高度な処理が比較的楽に行えるようになるわけです。


> 一応、秀丸マクロから呼び出す用の何かをC#で作成するってことだけであれば、
> COMコンポーネントにしてもらう作戦もあるにはあると思います。

ここで質問があるのですが、C#のCOMコンポーネント側から
https://help.maruo.co.jp/hidemac/html/200_Dll_Api.html
にある関数およびメッセージを実行することは可能でしょうか?

秀丸マクロからCOMコンポーネントへの一方通行の呼び出しではなく、COMコンポーネントから
秀丸エディタの機能を使う双方向の呼び出しが出来てこそ、外部プログラムを利用する価値が
あると思います。


[ ]
RE:38521 ライブラリ作者への連絡についてNo.38522
秀丸担当 さん 20/10/23 15:11 [ コメントを投稿する ]
 
COMコンポーネント側から秀丸エディタの関数呼び出しは、loaddllのDLLと同じ位置づけとなる、同じプロセス内のDLLであれば可能だと思います。

.netをあまり作ったことが無いのですが、Google検索してやり方を調べてみて、.netのクラスライブラリのDLLをCOMとして登録して呼び出す例を作ってみました。
Hidemaru_GetCurrentWindowHandle関数の32bit値を渡すだけの最もシンプルなものです。

●.net側の例
//クラスライブラリでプロジェクト設定 「アセンブリをCOM参照可能にする」「COM相互運用の機能の登録」が必要。
//管理者で「regasm ClassLibrary1.dll /tlb:ClassLibrary1.tlb」が必要。32bitと64bitで違うので注意。
using System;
using System.Net;
using System.Runtime.InteropServices;

namespace ClassLibrary1
{
    [Guid("0F3B0368-61E4-4E2D-BB3C-86ADC8DFD602")] //guidgenで生成する適当な別の値にしてください
    public class Test1
    {
        [DllImport("kernel32.dll")]
        public static extern IntPtr GetModuleHandle(string lpFileName);
        [DllImport("kernel32.dll")]
        public static extern IntPtr GetProcAddress(IntPtr hModule, string lpProcName);
        
        public delegate IntPtr HIDEMARU_GETCURRENTWINDOWHANDLE();
        
        public int TestMethod()
        {
            IntPtr hmod = GetModuleHandle(null); //hidemaru.exe自身
            IntPtr pfn = GetProcAddress(hmod, "Hidemaru_GetCurrentWindowHandle");
            HIDEMARU_GETCURRENTWINDOWHANDLE Hidemaru_GetCurrentWindowHandle = (HIDEMARU_GETCURRENTWINDOWHANDLE)Marshal.GetDelegateForFunctionPointer(pfn, typeof(HIDEMARU_GETCURRENTWINDOWHANDLE));
            int hidemaruhandle = 0;
            if( Hidemaru_GetCurrentWindowHandle != null ) {
             hidemaruhandle = (int)Hidemaru_GetCurrentWindowHandle();
            }

            return hidemaruhandle; //マクロのCOM呼びだしはIntPtrでなくてintで、ウィンドウハンドルは32bit値に収まる
        }
    }
}

●マクロ側の例
#obj=createobject("ClassLibrary1.Test1");
if(getresultex(10)!=0) {
    message "マクロのhidemaruhandle:\n"
        + str(hidemaruhandle(0))+"\n\n"
        +".netのDLLで呼んだHidemaru_GetCurrentWindowHandle:\n"
        + str(member(#obj,"TestMethod"));
} else {
    message "createobject失敗";
}
endmacro;




Hidemaru_*の関数は、ポインタで受け取るものやHGLOBALを扱うものがあるので、これらを扱う場合はkernel32のGlobalAllocやGlobalLock等を使う必要があるので、もうちょっと手間になると思います。
一通り試してみてヘルプの説明ページを作ったほうがいいかもしれません。
[ ]
RE:38522 ライブラリ作者への連絡についてNo.38523
fzok4234 さん 20/10/23 16:57 [ コメントを投稿する ]
  わざわざ.NETのクラスライブラリのCOMコンポーネント化のサンプルの御提示ありがとう
ございます !!

COMコンポーネントでもP/Invokeによる秀丸エディタの関数とメッセージが利用可能なのですね。

ただ、問題なのはRegAsm.exeでのCOMコンポーネントの登録を管理者が行わないといけない
ことです。つまり、制限ユーザーが秀丸マクロの.macファイルと同じ感覚でマクロのデフォルト
フォルダーの
%AppData%\Hidemaruo\Hidemaru\Macro
にCOMコンポーネントの.dllファイルを保存して、.macファイルから自由にロードするといったことが
出来ないということです。マクロ関数のcreateobject()はレジストリに登録済みのProgIDを
指定することになっており、COMコンポーネントのファイルパスは受け付けません。RegAsm.exeや
Windows標準アプリのregsvr32.exeでの登録無しで直にCOMコンポーネントのファイルをパス文字列で
ロードするマクロ関数/文があれば良いと思うのですが... 。


[ ]
RE:38523 ライブラリ作者への連絡についてNo.38524
秀丸担当 さん 20/10/23 17:38 [ コメントを投稿する ]
 
登録なしでCOMオブジェクトを作成するのは、自分でもどうにかならないかと思っています。
たぶんですが、例えば
#obj = crateobject("c:\\x\\y.dll","{XXXX-XXX...}");
といったように、ファイル名とCLSIDを同時に書いて、CLSIDがわかればそれを使う方式にすればできる可能性はあると思います。
.netで作成されたものに通用するかどうかわからないですが、試してみようと思います。
[ ]
RE:38523 ライブラリ作者への連絡についてNo.38525
秀丸担当 さん 20/10/26 15:07 [ コメントを投稿する ]
 
COMを登録せずにやるのを試してみたのですが、.netでなく外部EXEでもないDLLであればファイル名とGUIDで一応可能でした。(メソッド等も登録に依存していなければ)
.netの場合はだいぶん仕組みが違うみたいで、同じ方式は使えずちょっと厄介なようでした。
可能か不可能かでいえば可能だと思いますが、とりあえずは普通のDLLを対応してからまた検討したいと思います。
[ ]
RE:38523 ライブラリ作者への連絡についてNo.38526
秀丸担当 さん 20/11/04 09:59 [ コメントを投稿する ]
 
V8.96β1を公開して、.netのほうもできるように対応しています。
.netの場合はCLSIDではなく以下のような感じで記述できます。
#obj = crateobject("c:\\x\\y.dll","ClassX.TestX");

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
https://hide.maruo.co.jp/software/hidemaru.html
[ ]
RE:38526 ライブラリ作者への連絡についてNo.38527
fzok4234 さん 20/11/04 12:12 [ コメントを投稿する ]
  早速の対応ありがとうございます !!
[ ]
RE:38527 ライブラリ作者への連絡についてNo.38607
こみやんま さん 20/12/17 18:04 [ コメントを投稿する ]
  こみやんまです。
(相変わらずハンドル名が違うかもしれません、変更しても変更されない...orz)

こちら メソッドのオーバーロード呼び出しを v1.711 としてアップしました。(自サイトのみ)

https://xn--pckzexbx21r8q9b.net/?page=nobu_tool_hm_dotnet

秀まるおさん、fzok4234さんをはじめ、皆さんに色々とお手数をかけていただき申し訳ないです。(ありがとうございます)


[ ]
RE:38607 ライブラリ作者への連絡についてNo.38608
fzok4234 さん 20/12/17 22:31 [ コメントを投稿する ]
  更新ありがとうございます !!

[ ]

[ 新規に投稿する ]