・sakura_core\sakura_rc.rc 「2 TEXTINCLUDE」に#include "String_define.h"追加 DISCARDABLE削除
・sakura_lang_en_US\sakura_lang_rc.rc 「1 TEXTINCLUDE」sakura_rc.h→sakura_lang.hに変更 「2 TEXTINCLUDE」#include "funccode_define.h"削除 DISCARDABLE削除
掲示板で発言していたばぼです。 対策パッチを作ってみました。
対策パッチを当てたあとに、編集→保存→元に戻す→保存した状態のrcです。 vs2005pro JPNを使いました。
最終目標は「VS2013/2015が出力するリソースをほぼそのままコミットできるような状態のrcにしたい」であってるでしょうか。 それとも「エラーや切り替えなど必要な機能が動かなくなる範囲だけ直す」でしょうか。
windresがご機嫌斜めです。 sakura_rc.rc2をShift_JISにしたら、エラーは減りましたが、正規「表」現が引っかかってエラーが残ったままです。 rc2もmrc2grcを通す必要があって、includeするファイル名も変更できるようにして、makefileもその辺を改造する必要がありそうです。 あとpatchが当たらないUTF-16とかのファイルはメンテナンスに支障があるので混ぜたくないです。 英語版リソースと通常リソースのテキストに不必要に差分があるのも、英語版の修正作業・未修正箇所を探すのが大変になるので避けたいです。 注文が多くてすみません。
やってみた範囲では英語版のほうはIDEで編集するのはどうにもならない感じです。 普通にやったら日本語の部分が文字化けしました。 includeしてる .hの警告もでます。
VS2013に寄せるんなら、既存の50個位あるパッチの内リソースをいじってるパッチを修正する必要があって、正直躊躇してしまいます。
レスどうもです。 レス書いたらありえない長文になりました。
最終目標は「VS2013/2015が出力するリソースをほぼそのままコミットできるような状態のrcにしたい」であってるでしょうか。
厳密な最終目標は、 プロジェクト公式ツールが出力するリソースをそのままコミットできるようにする 、と考えています。
公式ツールはVS2005なので、VS2005基準になるかと思います。 VS2008以降を採用するにはwin2kサポートを切る必要があるため、 ver2系の公式ツールを変更する選択はないと考えています。
完全に正しい状態にもっていくには膨大な変更が必要になりますので、 途中段階として、VC++6→VS2005の非互換だけを修正するパッチを作りました。 「この辺は非互換だから変えますよ～」って周知したあとに、 メジャー変更で一気に適用する戦略をとれば間違いが出ない、と思います。 累積パッチは、自動生成版を作る前に取り込んでしまう寸法で。
修正内容の説明をしていませんでした。
TEXTINCLUDEの修正の他には、 DISCARDABLEの削除 DS_SETFONTスタイルの追加 FONTステートメントへの拡張属性の追加 を行っています。
パッチを適用しただけだと、 ダイアログコントロールの改行位置で修正が走ったり 文字列リソースの並べ替えが発生したりしますが、 宣言から定義が消えるような変更はなくなるようにしてあります。
RC2の文字コードがUTF-16なのはVCの出力をそのまま使っているためです。 VC++の仕様的には、このファイルがUTF-16である必然はなかったと思います。 RC2を入れるのが不都合ならば、TEXTINCLUDEに無理やり当て込む、ってのも 1つの選択肢になるかと思います。
windresがご機嫌斜めです。
--codepage 932をコマンドラインに追加してみてはいかがでしょうか。 対応していればダメ文字があってもビルドできるようになるはずです。 MinGW環境でのビルドは考慮の外だったので申し訳ないです。 非正規ビルド環境までを考慮するなら、RC2は使わないほうがよいですね。
やってみた範囲では英語版のほうはIDEで編集するのはどうにもならない感じです。
sakura_lang_rc.rcは日本語VC++で編集されたファイルじゃありません。
日本語VC++で編集していいファイルではないので 今回のタイミングでパッチを作成すべきじゃないです。
VC++ ENGを持っていない限りは、 今後もVC++で編集すべきじゃないです。
もっとも、「英語VC++で編集されている」には若干ツッコミどころがあるんです。。。
・現状のsakura_lang_rc.rc コードページはja-JP(932) 英語リソースのヘッダ・フッタに「English resources」
・sakura_lang_rc.rcを日本語VC++で編集した場合 コードページはen-US(1252)になる 英語リソースのヘッダ・フッタに「英語(米国) resources」と出力される
日本語版の出力から英語版VC++で編集したら、 コードページはen-US(1252)になる 英語リソースのヘッダ・フッタに「English(US) resources」と出力される が想定されるわけですが、現状と違うのは何故でしょう？というツッコミ。
プロジェクトの多言語化にはいろんなセオリーがありますが、 sakuraの英語DLLは完全な独自方式を採用しているようです。 英語版は放置でいい、ってわけじゃないですが、 ある程度切り離して考えるべきだと思います。
TEXTINCLUDEに無理やり当て込む話、無理でした...orz
windresは、昔からShift_JIS→Unicode変換はできますが、なぜかダメ文字処理に未対応のままなのです。 コードページ指定とかも関係ない模様です。 本来はwindresにパッチを当てるべきなのですが、そうもいかないので、サクラでは独自ツールのmrc2grcを通しています。
はい。英語版は後でいいので、コードをある程度揃えられればいいかと思います。 (たぶん手作業でしょうけれど。) おそらく、英語版リソースの作成もIDEではなく手作業でやったと思われます。 実際、普段のパッチ作業では作業的にも、日本語版の差分をコピペしてくるのが一番早いので、 英語版は今後も同じ方針ということにしましょう。
あと、最低環境は普段は特に検証とかはしていませんが実はVC2003です。 ANSIビルドでWin95向けバイナリが生成できる「ことになって」います。
windresでのエラーを修正したパッチを添付します。 sakura_rc.rcは3 INCLUDETEXTのrc2を#ifndef/#endifで切り替えるようにしました。 sakura_rc.rc2はSJISにしただけです。 vc2003.slnの対応と、makefileのwindresを修正しました。
前向きに検討していただいて、個人的には満足しました。 最終判断はプロジェクトメンバの方々におまかせします。
Log in to post a comment.
掲示板で発言していたばぼです。
対策パッチを作ってみました。
対策パッチを当てたあとに、編集→保存→元に戻す→保存した状態のrcです。
vs2005pro JPNを使いました。
最終目標は「VS2013/2015が出力するリソースをほぼそのままコミットできるような状態のrcにしたい」であってるでしょうか。
それとも「エラーや切り替えなど必要な機能が動かなくなる範囲だけ直す」でしょうか。
windresがご機嫌斜めです。
sakura_rc.rc2をShift_JISにしたら、エラーは減りましたが、正規「表」現が引っかかってエラーが残ったままです。
rc2もmrc2grcを通す必要があって、includeするファイル名も変更できるようにして、makefileもその辺を改造する必要がありそうです。
あとpatchが当たらないUTF-16とかのファイルはメンテナンスに支障があるので混ぜたくないです。
英語版リソースと通常リソースのテキストに不必要に差分があるのも、英語版の修正作業・未修正箇所を探すのが大変になるので避けたいです。
注文が多くてすみません。
やってみた範囲では英語版のほうはIDEで編集するのはどうにもならない感じです。
普通にやったら日本語の部分が文字化けしました。
includeしてる .hの警告もでます。
VS2013に寄せるんなら、既存の50個位あるパッチの内リソースをいじってるパッチを修正する必要があって、正直躊躇してしまいます。
レスどうもです。
レス書いたらありえない長文になりました。
厳密な最終目標は、
プロジェクト公式ツールが出力するリソースをそのままコミットできるようにする
、と考えています。
公式ツールはVS2005なので、VS2005基準になるかと思います。
VS2008以降を採用するにはwin2kサポートを切る必要があるため、
ver2系の公式ツールを変更する選択はないと考えています。
完全に正しい状態にもっていくには膨大な変更が必要になりますので、
途中段階として、VC++6→VS2005の非互換だけを修正するパッチを作りました。
「この辺は非互換だから変えますよ～」って周知したあとに、
メジャー変更で一気に適用する戦略をとれば間違いが出ない、と思います。
累積パッチは、自動生成版を作る前に取り込んでしまう寸法で。
修正内容の説明をしていませんでした。
TEXTINCLUDEの修正の他には、
DISCARDABLEの削除
DS_SETFONTスタイルの追加
FONTステートメントへの拡張属性の追加
を行っています。
パッチを適用しただけだと、
ダイアログコントロールの改行位置で修正が走ったり
文字列リソースの並べ替えが発生したりしますが、
宣言から定義が消えるような変更はなくなるようにしてあります。
RC2の文字コードがUTF-16なのはVCの出力をそのまま使っているためです。
VC++の仕様的には、このファイルがUTF-16である必然はなかったと思います。
RC2を入れるのが不都合ならば、TEXTINCLUDEに無理やり当て込む、ってのも
1つの選択肢になるかと思います。
--codepage 932をコマンドラインに追加してみてはいかがでしょうか。
対応していればダメ文字があってもビルドできるようになるはずです。
MinGW環境でのビルドは考慮の外だったので申し訳ないです。
非正規ビルド環境までを考慮するなら、RC2は使わないほうがよいですね。
sakura_lang_rc.rcは日本語VC++で編集されたファイルじゃありません。
日本語VC++で編集していいファイルではないので
今回のタイミングでパッチを作成すべきじゃないです。
VC++ ENGを持っていない限りは、
今後もVC++で編集すべきじゃないです。
もっとも、「英語VC++で編集されている」には若干ツッコミどころがあるんです。。。
・現状のsakura_lang_rc.rc
コードページはja-JP(932)
英語リソースのヘッダ・フッタに「English resources」
・sakura_lang_rc.rcを日本語VC++で編集した場合
コードページはen-US(1252)になる
英語リソースのヘッダ・フッタに「英語(米国) resources」と出力される
日本語版の出力から英語版VC++で編集したら、
コードページはen-US(1252)になる
英語リソースのヘッダ・フッタに「English(US) resources」と出力される
が想定されるわけですが、現状と違うのは何故でしょう？というツッコミ。
プロジェクトの多言語化にはいろんなセオリーがありますが、
sakuraの英語DLLは完全な独自方式を採用しているようです。
英語版は放置でいい、ってわけじゃないですが、
ある程度切り離して考えるべきだと思います。
TEXTINCLUDEに無理やり当て込む話、無理でした...orz
windresは、昔からShift_JIS→Unicode変換はできますが、なぜかダメ文字処理に未対応のままなのです。
コードページ指定とかも関係ない模様です。
本来はwindresにパッチを当てるべきなのですが、そうもいかないので、サクラでは独自ツールのmrc2grcを通しています。
はい。英語版は後でいいので、コードをある程度揃えられればいいかと思います。
(たぶん手作業でしょうけれど。)
おそらく、英語版リソースの作成もIDEではなく手作業でやったと思われます。
実際、普段のパッチ作業では作業的にも、日本語版の差分をコピペしてくるのが一番早いので、
英語版は今後も同じ方針ということにしましょう。
あと、最低環境は普段は特に検証とかはしていませんが実はVC2003です。
ANSIビルドでWin95向けバイナリが生成できる「ことになって」います。
windresでのエラーを修正したパッチを添付します。
sakura_rc.rcは3 INCLUDETEXTのrc2を#ifndef/#endifで切り替えるようにしました。
sakura_rc.rc2はSJISにしただけです。
vc2003.slnの対応と、makefileのwindresを修正しました。
前向きに検討していただいて、個人的には満足しました。
最終判断はプロジェクトメンバの方々におまかせします。