| |
でるもんた・いいじまです。
各論。
> 調べてみると、Windows 98/Me/NT4.0で動作するバイナリをコンパイルできる
> C/C++コンパイラの最後のバージョンがVisual C++ 2005とのこと
「設定をいじらずに」コンパイルできる最後のバージョンが2005ですね。
あとはランタイムライブラリのDLL次第ですか。
> B. 把握しているが修正困難な不具合が存在しており、
> いつ顕在化してもおかしくない「時限爆弾」となっている。
具体的には？
> C. モダンなテキストエディタに求められる最新技術を実装できない。例えば、
> ・Language Server Protocolなどの言語パーサ呼び出しを用いた強調表示や
> 単語補完など。
> ・よく使う定型句を自動入力するコードスニペット機能。
> などといった機能を実現できず、
そんなものはVisual C++のバージョンとは無関係ですが？
極論、MinGW派の人は自前でそういうライブラリを用意して対応しているわけです。
LSPもスニペットも確かに有用ですが、今まで秀丸を使ってきた人たちの感覚からす
れば「辞書の類はパブリックなものがあると大いに助かるが、書式についてはマクロ
で自分の好みにカスタマイズできなければ論外どころか有害」です。
私なんか、Excelのマクロを書いていてもいちいちエラーのモーダルダイアログが出
るのが我慢ならないのですよ。
あるいはLSPでいうと、閉鎖された環境でアプリが勝手に外部と通信をされては困る
ケースも多々あるわけです。機密保持のためコーディング用のPCは特定のサイトを除
きWebブラウジング禁止、なんていう運用のオフィスも結構あるわけで。
> ライバルのエディタに差をつけられてしまう。
その話は解決済。
> D. 一般的なアプリで近年行われている機能/仕様のモダン化ができない。
「一般的なアプリ」の定義は？
「近年」とは具体的に何年から？
漠然と「自分の脳内常識は世界全体の公理」という態度で議論を吹っ掛けてくること
に対して我慢がならないのですよ。（ちょっとここのところ色々とあるので…。）
> ・特にx64版秀丸エディタにおいて内部で扱う整数値やメモリ容量の64bit化。
Windows自体がそもそも32bitアプリのために無茶をしています。
UNIX系OSでは「32bitバイナリのみで提供されるアプリ・ライブラリ以外はすべて64b
itでビルドしなおす」という方向に走りましたけど、Windowsでそれはできません。
OSがギリギリまで互換性を確保し続けようとしている時点で、そちらと折り合いをつ
けていくことが最優先です。
＃というか、35年前のバイナリの動作が条件付きながらも今のOSの
＃カーネルでサポートされている、という時点で、Microsoftの
＃基本的な姿勢は「互換性を重視し、需要が十分少なくなって
＃移行先が確定したものを切り捨てる」です。
> ・各種バッファにおいて、固定長配列やmalloc()したヒープ領域への
> ポインタ加算によるアクセスを廃止してstd::vectorなどに置き換えて、
まず、性能の件はそんなに問題にはならないということを前提にしますね。仮に問題
になるとすれば、重い部分の内側だけを生ポインタでゴリゴリ最適化して、その計算
を関数なり演算子なりの形でカプセル化してしまうだけのことですから。
でも、「データの内部構造を完全に新しくする」ということがどれだけハイリスクだ
かわかっていますか？コードを書き換えて、コンパイラの型チェックでエラーもウ
ォーニングも出なかったからはい安心、とはいきませんよ。
> バッファオーバーフローのリスクを無くすとともに
> 固定長バッファを可変長バッファに改善する。
それは「これから新規の機能を追加する場合」「どこかで何かが問題になった場合」
の話。
それと、たとえば何かの文字列データをchar[]（あるいはWCHAR[]）ではなくstd::st
ringで保存したからハイ安心、という発想は秀丸にはありません。マクロでもDLLで
も何でもいいですが、意図的にこの変数にGB単位の巨大データを突っ込んで、アプリ
側で完全にその可能性をノーチェックだったとすれば、アプリのハングアップ、DoS
アタックのリスクを背負います。
char[]とstd::stringとどちらが効果的か、というのはケースバイケースで決める話
です。
> ・各種設定ファイルの形式にXMLやJSONといった階層ツリー構造で
> 各種処理系で操作可能な規格を採用する。
> などを実行できない。
これも実現すること自体はコンパイラとは関係ありません。
もしコンパイラの標準ライブラリにその機能がなければフリーのものを持ってくるだ
けです。
問題は「既に内部構造として固定長バッファやハードコードの構造体などが使われて
いるものが多数あり、それらを無防備にJSONへ置き換えるのは無理」という話です。
先日ご要望があった「レジストリに保管されている内容を編集したい」ということだ
けであれば、既存の秀丸のパッケージにバンドルする形で「レジストリに入っている
データ」「設定バックアップで書き出したレジストリ形式のデータ」「手作業で編集
可能なJSON等のデータ」の相互変換ツールを別途作ってもらえばそれで済む話です。
その話であれば、いったんfzok4234さんが現状のレジストリの仕様を担当さん（秀ま
るおさん？）から開示してもらって、その仕様を前提にした変換ツールを実際にfzok
4234さんが作ってみてはいかがですか？そのバイナリを「ベータ版」として一般公開
してみて、好評であればサイトー企画さんのほうでWindows 9x/NT対応のための最低
限の修正を入れてもらってサイトー企画名義で公開、と。
> E. コードのリファクタリングなどが進まず開発体制における
> 時代遅れなアンチパターンを放置している。
これは完全にfzok4234さんの邪推ですよね？
> F. レガシーな関数/APIやデータ書式しか使えない状態で時代の変化に伴う
> 秀丸エディタのモダン化を行うために、
まあ、これは事実です。
> ・レガシー関数/APIだけで無理やり新機能を実装したため歪なコーディング
> となりコードの可読性や保守性が悪くなった。
あの…「ラッパー」という概念をご存じない？
たとえばマクロのmessage文、最近の環境であれば表示すべき文字列はUTF-16LEに変
換されて、MessageBoxW() で処理されるはずです。一方で、Windows98であれば、Uni
code文字を '?' などに潰した上で MessageBoxA() を呼ぶはずです。
この時どうするかというと、賢い人はこんな関数を用意するわけです：
DWORD hmMessageBoxT(char *msg, 以下略)
{
if (fpMessageBoxW)
{
UTF-16に変換 // もちろんそういう関数は別途存在する
return fpMessageBoxW(略)
}
else
{
Unicode文字を潰す関数で処理 // この関数も別途存在する
return ::MessageBoxA(略)
}
}
秀丸の内部にはおそらく、こういうラッパーが大量に用意されているはずですよ。
> ・内部データ書式をShift-JISエンコードなどの既存のレガシー書式を
> 無理やり拡張した独自書式にしたため、
これは歴史的に仕方のないことです。何度も指摘していますが、一度決めた内部構造
を途中で変えることがどれだけ大変なのか、全く分かっていないように思えます。
> UTF-16エンコードなどの規格化されたモダン書式と違って
> フレームワークやOSによるサポートがないために、
「フレームワーク」が一体何を示すのか分からないのでそれは置いておくとして、OS
によるサポート。
もし「UTF-16になってさえいればOSの機能が使える」ということなら、堂々と使えば
いいだけのことです。でも使わないのは、「特定の時期以降のOSでないと使えない機
能を標準で要求するのは望ましくない」という考えがあるからだと私は考えています。
> この書式のパーサを自前で実装したものの不具合が頻発して
> 「四角い車輪の再発明」状態となった。
自前がダメなら、フリーなライブラリをカスタマイズして使えばいいだけのことです
ね。
それに、既存の車輪が欠陥品でないという保証だってどこにもありませんよ。
実際、秀丸の内部には「OSやそのモジュールの不具合に対応するためのトリック」が
優に100件くらいは組み込まれているはずです。
☆ ☆ ☆
ここのところ連日のfzok4234さんの要求を拝見していると、「全く同じ外見、同じ動
作、同じ安定性で、ただし内部構造の全く違うものをスクラッチから、しかもタダで
作れ」という無茶振りをしているようにしか思えません。
|
|