◀ANSI版開発トップへ
  • 4746 Unicodeの枠組み
    • 4747 Re:Unicodeの枠組み
      • 4750 Re2:Unicodeの枠組み
        • 4751 Re3:Unicodeの枠組み
          • 4753 Re4:Unicodeの枠組み
            • 4754 Re5:Unicodeの枠組み
            • 4755 Re5:Unicodeの枠組み
              • 4756 Re6:Unicodeの枠組み

  • [4746] Unicodeの枠組み げんた 2007年03月15日 02:03

    恥ずかしながらPlatform SDKを見ていて初めて初めて気付いたのですが，
    TextOut, ExtTextOut, GetTextExtentPoint , MessageBox等はWin95でもWide版が使えるのですね．

    Unicode版と聞くとすべてのAPIをWide版に切り替えなくてはならないと思っていましたが，文字列処理はUnicodeで作って，プログラム本体は今まで通りANSI版でコンパイルという選択肢も可能なんでしょうかね．

    しかし，文書の内容以外にもANSI版だと日本語版以外のOSでメニュー等が文字化けしたり，Unicodeのファイル名が扱えなかったりという制限もありますので，後々禍根を残す中途半端な方法は止めた方が良いのかも．

    • [4747] Re:Unicodeの枠組み ラスティブ 2007年03月15日 11:04

      ▼ げんたさん
      > TextOut, ExtTextOut, GetTextExtentPoint , MessageBox等はWin95でもWide版が使えるのですね．

      　上に挙げられている関数だと、API関数 ::TextOut() と ::MessageBox() の Unicode 版は、
      例外的に、API 関数 ::TextOut() だけは Win95 から Unicode 版が
      標準で搭載されているらしいです。その他のものは、
      いつか知らんの過去ログにも掲載されていますように、
      以下の変換レイヤーでエミュレートされるとの事です。

      Microsoft Layer for Unicode on Windows Me/98/95 Systems (MSUL)
      http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_on_windows_
      95_98_me_systems.asp

      > 文字列処理はUnicodeで作って，プログラム本体は今まで通りANSI版でコンパイルという選択肢

      　掲示板の過去ログを眺める限り、サクラエディタの Unicode 化の背景には、
      こういう事情があるんじゃないかなと勝手に想像しています（^^;）

      １．Unicode 版と ANSI 版のバイナリを分けたくない。
      ２．Unicode サポート済みのプラットフォームでは、API 関数の機能をフルに引き出したい。
      ３．コアの部分は、単体バイナリで動かしたい。

      そうだとすると、１．の条件で、TCHAR の使用はできなくなり・・・
      ２．の条件で、Unicode 版と ANSI 版それぞれの関数テーブルを用意しておき、
      ＯＳのバージョンを確認次第、起動時に切り替えることが要求されます。
      ３．の条件で、MSUL の導入に躊躇します。

      　これらを踏まえると、選択肢として残ってくるのは、
      _MBCS を無視して、自作の関数テーブルで対応する…うぅ、みたいな？

      • [4750] Re2:Unicodeの枠組み げんた 2007年03月16日 00:20

        >> 文字列処理はUnicodeで作って，プログラム本体は今まで通りANSI版でコンパイルという選択肢
        >１．の条件で、TCHAR の使用はできなくなり・・・
        >２．の条件で、Unicode 版と ANSI 版それぞれの関数テーブルを用意しておき、
        AとWでは文字列を含む引数の型が異なることを考えると，完全にWide版APIを使ったら同一バイナリは無理じゃないでしょうか．無理に入れてもほとんど実行されないコードが増えるだけになりそう．バイナリサイズも抑えたい，

        >３．コアの部分は、単体バイナリで動かしたい。
        >３．の条件で、MSUL の導入に躊躇します。
        DLLを添付するのはたしかに格好悪いのですが，Ansi版を独立にテストしなくて良い方法はこれしかないような気もします．
        今時Win 95/98でエディタを使う人が必要としている機能はもう十分に備えているからANSIは開発停止だけど，MSLUで一応救済…になってるかなぁ．

        • [4751] Re3:Unicodeの枠組み ryoji 2007年03月16日 02:09

          ▼ げんたさん
          > ANSIは開発停止だけど，MSLUで一応救済…になってるかなぁ．
          『Advanced Windows 改訂第４版』によるとWindows9xのW系関数にはいろいろバグがあるそうです。
          特定フォントでは動かないとか、ヒープ破壊するとか、プリンタドライバがクラッシュするとか。
          MSLU使うとどうなのかはわかんないですが、テストもどれだけできるやら。。。
          何にせよ内部Unicode化に伴うWin9xでのテストは十分にはできないんじゃないでしょうか？
          苦労してそこそこ両対応（のつもり）で作っても、9x系では恩恵も少なく不安要素抱えてるんじゃ、現行版を使い続けるほうがお勧め (>_<)
          てことになっちゃいませんかね…

          • [4753] Re4:Unicodeの枠組み ラスティブ 2007年03月16日 12:42

            ▼ げんたさん
            > > 無理に入れてもほとんど実行されないコードが増えるだけになりそう．
            ▼ ryojiさん
            > 何にせよ内部Unicode化に伴うWin9xでのテストは十分にはできないんじゃないでしょうか？

            　言われてみると、そうですね。緑色（コメント色）の残骸が目に浮かびます（x_x;）
            すると、時代の要請（！？）による内部 Unicode 化を実施するにあたり、
            以下の理由のため ANSI 版の開発を停止する流れになるんですね…（しょんぼり）
            （これでいいんでしょうか？　＞皆さん）

            　・今時Win 95/98でエディタを使う人が必要としている機能は十分に備えている
            　・内部Unicode化に伴うWin9xでのテストは十分にできない

            　ANSI 版の開発が停止すれば、会社などで、諸般の事情のため、
            Win9x 系のプラットフォームを仕方なくつかっている方には痛手になりそうですけれど、
            一方で Unicode版 が生まれることで、
            内部 Unicode 化による大幅な変更の可能性を秘めていた部分に変更を加えることが、
            気兼ねすることなく出来るようにはなりそう・・・な予感です。

            • [4754] Re5:Unicodeの枠組み hideto 2007年03月16日 14:11

              ▼ ラスティブさん
              > 　・今時Win 95/98でエディタを使う人が必要としている機能は十分に備えている

              私はSEで、企業によってWin98を一部使用している場面もちらほら見かけますが、Grep結果からの複数ファイルにまたがる置換機能があったらいいなあとは思うものの、正直現状の機能で必要十分な気がします。
              そもそも、Win98をまだ使ってるシステムの人は根性があり、今のサクラエディタに不満があっても、それすらものともしない開発者だ！というのは言いすぎですか（＾＾；

              （ただし、今可能な限りの安定版を作成してからの移行を望みますが）

              んな訳で、一般掲示板、または、特設ページで、「Win95/98切っちゃってもいいですか？」アンケートを実施するのがいいと思いますが如何でしょうか？

            • [4755] Re5:Unicodeの枠組み げんた 2007年03月16日 21:59

              開発停止後1年経って，ANSI版は相変わらず放置かつUnicodeもできあがる気配無しになる危険性も考えるといきなり放棄するのもちょっと怖い．という移行の問題に対するMSの解決策がTCHAR & UNICODE定義なわけでして...単純に型をTCHARに変更できる物と，SJISの特性に大きく依存する物をまずは分離(できる限り関数化)し，ANSI版とUnicode版は1ファイルくらい差し替えるとできあがりというのが理想的かとは思います．
              あまりに至極まっとうな結論になってしまいましたが...

              と，いいつつ私も相変わらずchar*を量産しているので，必要なライブラリとガイドラインを揃えてからTCHAR*化を行うのが先決かなと思います．この部分はANSI版を残すかどうかとは無関係にWide版で必要な変更だと思いますので．
              あ，Wide版でTCHARなのはAPIに渡す部分だけなので，単にchar*をTCHARにすればよいという物では無いのですよね．

              いずれにしても，SJISの処理を残すかどうかはそこで改めて考えれば良いと思います．

              • [4756] Re6:Unicodeの枠組み ラスティブ 2007年03月17日 20:15

                ▼ げんたさん
                > 開発停止後1年経って，ANSI版は相変わらず放置かつUnicodeもできあがる気配無しになる危険性も
                > 考えるといきなり放棄するのもちょっと怖い．
                > ・・・（中略）・・・
                > 必要なライブラリとガイドラインを揃えてからTCHAR*化を行うのが先決かなと思います．

                結論としては・・・

                ・Unicode 版と、ANSI 版の２つのバイナリを１つのソースから
                　コンパイルできるよう作業を進める。
                ・内部コードは SJIS または UTF-16 とする。

                てことですね。

                余談ですけれど、インクリメンタルサーチに使う C/Migemo は
                すげ替えが必要なんじゃないか、と思いましたが、
                よく調べてみるとそうでもなさそうでした・・・（お恥ずかしい）

                > あ，Wide版でTCHARなのはAPIに渡す部分だけなので，単にchar*をTCHARにすれば
                > よいという物では無いのですよね．

                ですね。。。
                template< class TChar > class CMemText { /*...*/ };