BREW(Binary Runtime Environment for Wireless)
850 :
デフォルトの名無しさん:04/01/05 21:35
>>774 将来はJavaのようなセキュリティチェック機構が搭載されるのか?
BREWの将来のバージョンで搭載する予定、と
以前どこぞの記事に出ていた気がする。
まあ実際に保護機構があっても、CPの出すアプリには
ある程度の検証が行われるだろうし、所謂勝手アプリが
解禁になるかどうかはau次第。
前にどっかで、 文字列定数は使えないって読んだ気がするんだけど、
リソースエディタが生成するヘッダファイルに、
#define MYAPP_RES_FILE "myapp.bar"
てなカンジに定義されてるやつって、みんな知らん振りして使ってない??大丈夫なのか?
>>852 文字列定数は使えます。
日本語文字列とかをソースの中に埋め込むのは
(他国語対応の観点から)おすすめしません。
...という程度の意味だったかと。
854 :
デフォルトの名無しさん:04/01/08 18:57
test
>>852 BREWの場合、全て文字定数が駄目というわけではなく、単純に固定アドレスを必要とする
コードがコンパイル通らないだけな気がする。なのでグローバル変数も×。
A5304Tとかだと一発起動を使って二つの異なるアプリを起動できるけど、Winと違って仮想
メモリ空間とか持ってない(と思う)からアドレスずれる可能性あるからじゃないか、と予想。
既出だったらゴメンナサイ(´・ω・`)
グローバル変数なんかがダメな理由は、ELFからMODに変換がかかる時点で
所謂BSSセクションが削られてしまうので、そこに配置されるものは使えない、
という事だと思う。
アドレスずれる、とかいう事に関しては変数だろうと定数だろうと同じだし、
相対アドレッシングとか使えばいいだけなので大丈夫じゃないかと。
#実際MODってベタのARMのコードっぽいしな。
なんだかややこしいのね。こんなことプログラマが意識しなきゃいけないなんて
だめじゃない?
858 :
デフォルトの名無しさん:04/01/11 12:22
>>857 自分で全部管理するならともかく、ある一定の規約に従って
プログラムを作る以上は仕方ないかと。
そうでなければ、javaのように100%お任せしてしまうようなシステムを
使うしかないわな。
http://www.qualcomm.com/brew/ja/developer/resources/news/dev_news.html BREW 3.0のリリース
最新のBREW クライアントソフトウェアでは、リムーバル・ストレージ・メディアと
シリアル・インタフェースのサポートを加えることで、携帯端末のマルチメディア機能が拡張されています。
シリアル・インタフェースを使用することで、ユーザーはBREW対応端末をキーボードやパソコンなどに簡単に接続できます。
マルチメディアの拡張に加えて、BREW 3.0 クライアントソフトウェアはグループ管理機能を提供しますが、
これによって、キャリアはビジネスユーザーおよび企業を含め、加入者をセグメントに分類し、
各セグメントに合わせてカスタマイズしたワイヤレスアプリケーションのポートフォリオを配信できます。
BREW 3.0 ソフトウェアには、ディベロッパーがセカンダリ・ディスプレイへのアクセス機能を活用できるというメリットもあります。
BREW 3.0 API 機能
セカンダリディスプレイへのアクセス機能
BREW 3.0は、アプリケーションが端末上の複数のOEM定義のディスプレイ領域にアクセスできるようにします。
1つのアプリケーションで複数のディスプレイを同時にアクセスできます。
また、異なるアプリケーションが同時に異なるディスプレイ領域を互いに独立に使用することもできます。
アプリケーションによるMMC/SD共有ディレクトリへのアクセス
BREW 3.0では、アプリケーションはBREWディレクトリパスマクロを使用してコンテンツや
ファイルをリムーバブルメディアカードに保存、アクセス、管理することができます。
アプリケーションは、端末の永続フラッシュ部分にあるBREW共有ディレクトリと同様に、
SD/MMCメモリ空間と相互作用することができます。
BREWアプリケーション(MIFまたはMOD)は、メディアカードに保存できません。
このディレクトリパスは、キャリアがメディアカードを使用してアプリケーションを制御し、
端末からコンテンツを除去できるようにするためにBREW特権によって保護されています。
汎用シリアルインタフェース
アプリケーションが端末のI/Oポートにアクセスできるようにするために新しいインタフェース(IPort) が追加されました。
この汎用ポートは、シリアルケーブル、USBケーブル、赤外線無線接続、Bluetooth無線接続のいずれにも使用できます。
インタフェースでは、アプリケーションが端末を検出するためにプラグアンドプレー動作がサポートされています。
このインタフェースは、キャリアが端末間のシリアル通信を提供するアプリケーションを制御できるようにBREW特権によって保護されています。
アドレス帳カテゴリへのアクセスの強化
BREW 3.0.0では、IAddrBook_GetCategoryName()とIAddrBook_GetFieldName()関数が追加され、
アプリケーションがOEM定義のアドレス帳のカテゴリとフィールドのテキスト名を取得できるようになりました。
BREW SDK 3.0 機能
BREW SDK 3.0は、より使いやすく、より効率的なアプリケーションの開発、
テスト、ローカリゼーション、およびカスタマイズを 可能にします。
新機能には次のようなものがあります。
BREWシミュレータ
端末固有シミュレーション
BREWシミュレータは、端末固有機能をより正確にシミュレートできるようになりました。
このシミュレーションは、「デバイスパック」としてパッケージされている真の端末データに基づいて行われます。
認定BREWディベロッパーの方は、これらのパックが利用可能になり次第、アクセスできます。
端末情報の表示
端末特有動作をシミュレートするために使用するデータが、シミュレータのオプションウィンドウに表示されるようになりました。
ユーザーインタフェースの更新
BREWシミュレータのユーザーインタフェースが使いやすさの観点から更新されて、
頻繁に使用される機能にアクセスしやすくなりました。
さらに、ユーザーインタフェースを使用して、ヒープサイズやソケットの最大数といった
端末データフィールドを変更することができるようになりました。
APIリファレンスガイドの強化
APIリファレンスガイドが強化され、各インタフェースや関数を最初に説明する際に
それぞれのBREWバージョンが記述されるようになりました。
BREW 3.0機能のシミュレーション
BREW SDKは、MMC、シリアル接続、および複数ディスプレイといったBREW 3.0機能のシミュレーションをサポートします。
BREWリソースおよびMIFエディタ
新しい入力ファイル形式
リソースエディタとMIFエディタは、入力としてXMLベースファイル形式(それぞれBRXとMFX)を受け入れるようになりました。
テキストベースの入力形式の使用によって、アプリケーションのテスト、カスタマイズ、およびローカリゼーションがしやすくなります。
コマンドラインコンパイラ
MIFとBARファイルのコマンドラインコンパイルのサポートによって、
上級BREWディベロッパーは相当な開発時間を節約できます。
ユーザーインタフェースの更新
リソースエディタとMIFエディタのユーザーインタフェースは共に、使いやすさの観点から更新されました。
863 :
デフォルトの名無しさん:04/01/14 11:40
SDK
864 :
デフォルトの名無しさん:04/01/15 02:11
.
865 :
デフォルトの名無しさん:04/01/16 11:02
BREWで3Dのゲーム作ろうと思うが、情報が少ないので
なかなか進まん(´・ω・`)ショボーン
>>865 情報っていうか、ライブラリも含めてフル自分実装
では?
867 :
デフォルトの名無しさん:04/01/16 11:55
それを言ったらミもフタもない
868 :
デフォルトの名無しさん:04/01/16 12:06
869 :
デフォルトの名無しさん:04/01/16 13:00
SDKを落としてみたいんですが、ユーザー登録の「社名」ってどう書けばいいんでしょうか?
解決しました。スマソ
.dllとくらべて、.modファイルってどれくらいのサイズになる?
いま、dllが144k、elfが331k、で、modがなんと37k。
いくらなんでも小さすぎやしないか、と。
どっか間違えてるんだろうか。。。
873 :
デフォルトの名無しさん:04/01/19 12:41
ガンガレ
DLLが約95KB MODが約60KB ELFが約615KB
ちなみにMODはほぼ素のバイナリのようだが、DLLはリンクするための
情報とかも入ってるんで、その分は大きいはず。
ELFやDebug版DLLはデバッグ情報も入るんでさらに大きくなるはず。
>>874 やっぱ僕のmodは小さすぎぽい。。。
874と比較すると、ELFの時点で既に小さすぎる気がするなぁ。。
gccでやってみようかとおもったのだがやり方がわからん。
.mak 中の armcc を armcppにしたんだが、まずいかなぁ。。。
規模の小さいアプリは相当小さくなるぞ>MOD
BREWアプリカタログ、寂しすぎる!
とりあえずおまえらがんばれ!いやまじで!
とりあえず一番がんばらないといけないのは
auのアプリ検証屋(の中の人)だな。
とりあえずがんばれ!いやまじで!
880 :
Metallica:04/01/20 02:33
auってjava VMを提供する気ないのかなー。
brew開発ができなくても、java VMが動くなら、そっちで
作ろうかと思ったんだけど。
でも、いざ提供されることになっても、auの審査を通過してない
ファイルは駄目、ってなるのかな、、、、
このまま、ソフトのラインナップが増えなかったら、
対応策として、javaの勝手アプリに対応するかもね。
881 :
デフォルトの名無しさん:04/01/20 08:48
A5501T使ってるけど、マジデBREWはアプリ少なすぎ。
何本か出ているゲームは確かに出来がいい。
けど、実用アプリは皆無に近い。
java動くようにするか、アプリ増やすかしてよ、auさん・・・・ ・゚・(ノД`)・゚・
ハイハイ
携帯板に帰れ
883 :
デフォルトの名無しさん:04/01/20 09:24
↑
BREW促販担当(リストラ寸前)
884 :
デフォルトの名無しさん:04/01/20 10:46
885 :
デフォルトの名無しさん:04/01/20 21:31
Brewで勝手アプリ作りたいんだけど結局携帯で動かせないのでしょうか。
ボーダフォンみたいに個人でアプリアップできるサイトとか無いの?
886 :
デフォルトの名無しさん:04/01/20 22:27
誰でもいいからimona移植してください!
>>855 s-cradle の helloworld.c で わざわざ
AECHAR text[] = {'H','e','l','l','o',' ','W','o', 'r', 'l', 'd', '\0'};
こんなことしてあるんだけど、これって、
AECHAR text[]="Hello,World";
ってしちゃっていいの?
889 :
デフォルトの名無しさん:04/01/21 08:45
test
>>888 AECHARはuint16なのでcharな文字列リテラルとは互換性がない。
VC++では
AECHAR text[]=L"Hello,World";
という書式でwchar_t(=unsigned short)な文字列リテラルを使うことが
できるが、ARMのコンパイラでこれが通るかは未確認。
あと日本語はUNICODEになりそうなので、この手も使えなさそう。
あとで試してみるわ
>>890 横レスで、しかも違う質問ゴメソ
AECHARはそうかも知れんが""の文字列データ
はmodのどこに配置されるの?
文字列リテラル使えるならグローバル変数が使え
ない理由がよくわかんないっす漏れ
>>891 「変数」はだめ。
「定数」はOK。
たとえば、
int const noname[] = { 0, 1, 2, 3 };
なら通る。
この場合{ 0, 1, 2, 3 }はMOD中に埋め込まれる。
>>892 サンスコ・・・いままで全部文字列や初期化コード
消してました(´Д⊂
無駄な努力だったんですね・・・
# 全部スタックで・・
とりあえずWin32でいったら
.rdataセクションはOKだけど.dataセクションは
駄目ってこと?
そもそも.textセクション以外は認めないっと思って
勘違いしていたんだが・・・
それとも、VCでいったら/merge:.rdata=.textみたいに
.rdataセクション(みたいなの)を.textセクション(みたいなの)
にマージしてんのかな?
それなら納得なんだが
元々Win屋さんなので例えがこんなのですみません
たびたび質問ゴメソ
char *p = "hoge"; // pはauto変数、hogeは初期化済みエリアなのでOK?
みたいに定数がOKなら浮動小数点のリテラルも
OKなの?
わざわざ文字列からヘルパー関数使ってやって
たんだけど・・
それとも浮動小数点はリテラルも変なライブラリ
がリンクされちゃうから駄目とか
ARMの環境無い検討段階なので教えてもらえると
うれしいです・・(´Д⊂
>>893 自己レス
VCでも文字列リテラルは.rdataでは無く.data
でした・・・
塵カキコ(アンドスレ違い)スマソ
896 :
デフォルトの名無しさん:04/01/21 22:28
カタカタ
>>890 日本の端末では、2バイトアラインメントのShift_JISになります。
(半角文字は上位に0x00がパディングされる)。
UNICODEではないです。
>>894 > みたいに定数がOKなら浮動小数点のリテラルも
> OKなの?
> わざわざ文字列からヘルパー関数使ってやって
> たんだけど・・
> それとも浮動小数点はリテラルも変なライブラリ
> がリンクされちゃうから駄目とか
浮動小数点リテラルはつらいかも。
(FASSIGN_INITなんつー代入用の関数もあるぐらいなので)
...と思ったらコンパイラ通ったー!!?
今試してみたら、
const double gData = 3.123;
なんてコードが問題なくコンパイル&リンクできました。
>>897 > 日本の端末では、2バイトアラインメントのShift_JISになります。
>(半角文字は上位に0x00がパディングされる)。
はAECHARのことだよね。
それじゃなくてwchar_tリテラルの時の話>UNICODEになる
>>898 いや、それだったら、ARMのコンパイラが文字コードの変換なんて
してくれるわけないです...。
あのですねー、ARMのコンパイラ、S-JISに対する配慮なくて、
0x5cを含む文字をソースに書いちゃうとコンパイラがエラーを起こすですよ。
/*〜*/ の形のコメント部であれば問題ないんだけど、
// 表示用ルーチン
とか書くと一発でアウト!
当然、
char * pszString = "表示する";
とかも駄目ね。
おかげで漏れコメントは英語で書くようになったよ。
>>899 ARMのコンパイラが日本語処理してくれないのはすっかり忘れていた。
まあ机上でこねくり回してても仕方がないので実験してみた。
AECHAR test[] = L"This is a pen. 日本語得意あるよ。";
という行をソース中に入れてコンパイルすると、VC++では
CONSTSEGMENT
??_C@_1DC@JHKI@?$AAT?$AAh?$AAi?$AAs?$AA?5?$AAi?$AAs?$AA?5?$AAa?$AA?5?$AAp?$AAe?$AAn?$AA?4?$AA?5e?eg?0?$IK?$JO_?$JHa?$AP@ DB 'T'
DB00H, 'h', 00H, 'i', 00H, 's', 00H, ' ', 00H, 'i', 00H, 's', 00H
DB' ', 00H, 'a', 00H, ' ', 00H, 'p', 00H, 'e', 00H, 'n', 00H, '.'
DB00H, ' ', 00H, 0e5H, 'e,g', 09eH, 08aH, 097H, '_', 0fH, 'aB0', 08bH
DB'0', 088H, '0', 02H, '0', 00H, 00H; `string'
というように、日本語部分はUNICODEに変換されて格納されていた。
(続く)
一方、ADSでは
||.constdata$1||
DCB 0x54,0x00,0x68,0x00
DCB 0x69,0x00,0x73,0x00
DCB 0x20,0x00,0x69,0x00
DCB 0x73,0x00,0x20,0x00
DCB 0x61,0x00,0x20,0x00
DCB 0x70,0x00,0x65,0x00
DCB 0x6e,0x00,0x2e,0x00
DCB 0x20,0x00,0x93,0x00
DCB 0xfa,0x00,0x96,0x00
DCB 0x7b,0x00,0x8c,0x00
DCB 0xea,0x00,0x93,0x00
DCB 0xbe,0x00,0x88,0x00
DCB 0xd3,0x00,0x82,0x00
DCB 0xa0,0x00,0x82,0x00
DCB 0xe9,0x00,0x82,0x00
DCB 0xe6,0x00,0x81,0x00
DCB 0x42,0x00,0x00,0x00
というように、単純に1バイトをuint16に突っ込んだだけの形式になった。
まあwchar_tリテラル使った方法では日本語は使えない、という事で。
あと、
// 表示用ルーチン
はエラーにならない。(実験済)
>>897 >浮動小数点リテラルはつらいかも。
>(FASSIGN_INITなんつー代入用の関数もあるぐらいなので)
>
>...と思ったらコンパイラ通ったー!!?
マジで?やっぱりリテラルは全部OKなのか・・・
文字列と不動小数点のリテラルは同じ理由で
駄目だと思ってたので、やっぱりそうですか・・
# 書き直しかよぉ〜(´Д⊂
サンスコです。
Qualcommのデベロッパーページ見るのやめ
ようかな・・・余計混乱するし、事実と違うこと
書いてある気がする
なんにせよ、情報足りないポ
>>899 >// 表示用ルーチン
>
>とか書くと一発でアウト!
なんですと!既に大量に書いているので
/* */に整形し直すか・・・
ARMからこんなメールが届きますた
【日本語マニュアルにRealViewデバッガオンラインヘルプが追加】
好評のマニュアルダウンロードに新たに下記が追加になりました。
・RealViewデバッガオンラインヘルプ
・RealVeiwデバッガ v1.6.1 コマンドライン リファレンスガイド
・RealVeiwデバッガ ライセンス管理ガイド
http://www.jp.arm.com/kk/kk_download.html
>>901 > あと、
> // 表示用ルーチン
> はエラーにならない。(実験済)
あれ? そうでしたっけ?
コメント部の最後に0x5cを含む文字があると...だったかも。
(この場合後続の改行コードがエスケープされて次の行も
コメントとみなされる...と思う。大抵エラーになる。)
>>902 >
>>897 > Qualcommのデベロッパーページ見るのやめ
> ようかな・・・余計混乱するし、事実と違うこと
> 書いてある気がする
> なんにせよ、情報足りないポ
「グローバル変数」が使えないとあるので一応嘘ではない。
「文字列が使えない」とは書いてない、「使うな」と書いてある...。
まあ、明らかな嘘もいくつかあって、「スタックサイズは500バイトまで」
なんつーのは初代BREW端末のスタックが2000バイトしかなかった頃の
ガイドラインなので、今は数KB程度なら問題なく使える。
認定ディベロッパになればKDDIのサイトにもーちょっと情報あるけどね、
ニワトリ卵かな。
>>904 コメントも実験してみた。
行末に\が来るパターン(たとえば // 畳表 とか)だと、
Warning: C2821W: trailing '\' continues comment
の警告のとおり、次の行もコメント扱いになる。
#注意したいのが、次の行がコメント扱いになるからといって
#必ずしもコンパイルエラーが発生するとは限らない、という事
VC++では当然日本語の誤認識は発生しない。
これについては、コメントの最後に必ずSJISでない文字(スペースとか.とか)
を付けることで対処できないことはないが、要注意といったところか。
あと今思いついたが、これを使うとVC++(シミュレータ環境)とADS(実機)で
処理分けとか出来そう……だがバグの温床にもなりそうだな(笑)
0x5cの問題って、ARMコンパイラに限らず昔からありますよね。
PSやPS2とかの開発でもやっぱりあって(最新の環境では知りませんが)、
コメントの行末には必ず半角スペースを入れる癖がつきました。
これで無問題。
コード上に文字列定数を置きたい場合も、
それ自体があまりよろしくないとは思いますが
(一時的なデバッグ出力用とかだとまた別ですが…)
char * pszString = "表示する";
は
char * pszString = "表\示する";
とすれば行けませんかね?
BREW SDKをDLしようとすると,しばらく待たされた後に
「BREW SDK ACCESS ERROR 」
というページが出て,DLが出来ないのですが・・・これは私の環境がまずいのでしょうか?
日本語版2.1.1や英語版2.1.0,3.0でも同じ症状です・・・。
困った・・・(-_-;)
909 :
デフォルトの名無しさん:04/01/25 13:07
>>909 申し訳ありません・・・読んでいませんでした。
無事にDLすることが出来ました。
ありがとうございますm(__)m
911 :
デフォルトの名無しさん:04/01/26 00:55
915 :
デフォルトの名無しさん:04/01/30 23:09
>>915 FIQ でも IRQ でもない、ただのコールバック。
917 :
デフォルトの名無しさん:04/01/31 03:39
IMedia関連、同時再生に関する話なんだけど、
リファレンスによると、ハード周り以外の制限はなしで、
MSM5100チップの場合、一つのMIDI/QCPをBG再生、四つのQCPってなってるけど、
MIDPのPhrasePlayerみたく、SMAFでBGM鳴らしながらPhraseでSEって出来た人いる?
やっぱ、SMAFでBGM再生するならMP3なりQCPなりでSE鳴らせってことなんだろうか?
ところで、BREW新インターフェースのP135のPhrase用のCLSID誤植だな…。
Phraseなら4音同時再生できるので、BGM/SEともにPhraseで用意すれば
BGM1音+SE3音で鳴らせる。
最初これに関する情報がさっぱりでえらい難儀した。
>>915 > あと、コールバック関数の処理が行われている間に別の非同期処理に割り込まれることってある?
ない。
>>918 おお、同時発色出来たよ。サンクス。
一週間の悩みが解消した…
うう…
社名をとうろくしなおしできないのかのう…
>>916,919
サンクスコ。
これで安心できる。
BREW 3.0(まだ端末なし)からだよね。スレッドサポートするの
だとするとコールバック関係も色々かわんのかね?
アルファチャネル…などとゼイタクいっちゃいけないんですよね?
>>924 PNGのアルファチャネルはサポートされてないね。
その他、透過に関する処理も全部0/1だったと思う。
>>925 ありがと。明滅処理、どうしましょうかね。
オブジェクトのパレット直接書き変える…?
パレット書き変えてどうするよ。と自己ツッこみ
後ろに何もなければ明滅にはなることにはなるけど
928 :
デフォルトの名無しさん:04/02/03 17:19
goto文、使っちゃっても大丈夫ですよね?
>>929 遅くなったけどありがと。
最近の機種のエミュレータの定義ファイル、KDDIと契約してないとこは
自作するしかないのかな…めんどう
まあ基本的には見た目だけだから(550x系はちょっと違うが)、適当な
写真使ってそれっぽく自作するのがいいかも。
どうせKDDI提供の定義ファイルもたいした出来じゃないし。
実画面サイズ=表示画面サイズになるように作り直すのメンドイ…
>>931 俺は標準の画像使って画面だけQVGAとかにしてますが?
ものすげーバランス悪いけどどうせそれでデモとかするわけじゃなし。
933 :
デフォルトの名無しさん:04/02/08 19:49
>927
BMP使ってみては?
GZIPで圧縮すれば、PNGほどではないが小さくなるべ。
ワーイ
やっと検証通ったYO!
>>934 感想とか注意点とかあれば書いてください・・
お願い・・・
934じゃないが
「日中は電話機の前から離れるな」
と言うのはどうよ
>935
最初の1回目は大変だけど、2回目からは楽勝だな
>>935 ・
>>936も書いているけど、検証開始したら電話での問い合わせが
ちょくちょくあるので、対処できるくらいのスケジュールにしておくのが吉。
あとbrew-supportのページもこまめにチェックしておいたほうがよい。
・仕様書についてはなるべく詳しく、判りやすく書いておくこと。
記入漏れとか、解釈の違いによる矛盾とかちょっとでもあると問い合わせが
来るので。ただ、仕様書関係はNGにあまり影響しないが。
・特に問題出やすいのがサスペンド・レジューム部分なので、重点的にチェック
しておいたほうがよい。
とにかく心臓によくないイベントではあるな。これが通ってしまえばあとは
プログラム担当の仕事はほとんどないわけだが。
sdkおとさせてよ…
940 :
デフォルトの名無しさん:04/02/11 21:32
>>939 >>668読みました?
あと、JavaVMの安全性を「中」以下にしとかないとうまくいかないみたいでつ。
>>940 読ませてもらってたけど。
非常に恥ずかしいけど
社名って1度適当に入れて登録したら
変えられないのでしょうか?
>>942 変えられません...。
新しいメアドで正しい会社名入力してください。
944 :
デフォルトの名無しさん:04/02/12 11:51
BREW Forum 日本語版まだぁ〜?
945 :
デフォルトの名無しさん:04/02/12 20:41
まだぁ?
ARMの日本語ドキュメントが追加されますた
今度はコアのドキュメント・・うれしすぎる・・・
・ARM9EJ-Sテクニカルリファレンスマニュアル
・ARM946E-Sテクニカルリファレンスマニュアル
・ARM7TDMIテクニカルリファレンスマニュアル
ダウンロードトップページ
http://www.jp.arm.com/manual/
947 :
デフォルトの名無しさん:04/02/13 21:53
どりゃ
ところでおまえらは無事でしたか?
漏れはと言えば、金曜だと言うのに、
なんだかバタバタした一日でした。