4: 2004-04-16 (金) 19:11:45  |
5: 2004-05-04 (火) 10:02:13 |
| | -[[［0005］:http://wiki.osask.jp/?Is_OSASK_bad#qa0005]] なぜOSASKは（というかKは）、ユーザの意見を聞かないんだ。受け入れないんだ。公式に採用しないんだ。 | | -[[［0005］:http://wiki.osask.jp/?Is_OSASK_bad#qa0005]] なぜOSASKは（というかKは）、ユーザの意見を聞かないんだ。受け入れないんだ。公式に採用しないんだ。 |
| | -[[［0006］:http://wiki.osask.jp/?Is_OSASK_bad#qa0006]] OSASKはモノリシックカーネルなのか？ シェルやドライバなどに分かれていないのか？ | | -[[［0006］:http://wiki.osask.jp/?Is_OSASK_bad#qa0006]] OSASKはモノリシックカーネルなのか？ シェルやドライバなどに分かれていないのか？ |
| | + | -[[［0007］:http://wiki.osask.jp/?Is_OSASK_bad#qa0007]] ぐいぐい00で文字コード別に処理ルーチンがあるのは設計が悪いんじゃないか？ |
| | + | -[[［0008］:http://wiki.osask.jp/?Is_OSASK_bad#qa0008]] ぐいぐい00は関数の引数が多すぎて設計悪いんじゃないの？ |
| | + | -[[［0009］:http://wiki.osask.jp/?Is_OSASK_bad#qa0009]] ぐいぐい00の関数名がlib_で始まっているのはダサいよ。 |
| | + | -[[［0010］:http://wiki.osask.jp/?Is_OSASK_bad#qa0010]] OSASKのファイルサイズで圧縮した数字を使うのはずるい。 |
| | + | -[[［0011］:http://wiki.osask.jp/?Is_OSASK_bad#qa0011]] OSASKの実行ファイルヘッダは拡張性がない。○○もできない。 |
| | | | |
| | * 回答集 | | * 回答集 |
| - | -日付はこのページの項目作成日です。 | + | -日付はこのページでの項目作成日です。 |
| | | | |
| | &aname(qa0001); | | &aname(qa0001); |
| | -[0006](2004.04.15) OSASKはモノリシックカーネルなのか。シェルやドライバなどに分かれていないのか。 | | -[0006](2004.04.15) OSASKはモノリシックカーネルなのか。シェルやドライバなどに分かれていないのか。 |
| | --→[[「OSASKへの意見と回答」(2001.06.05):http://osask.jp/osask_oa.html]] | | --→[[「OSASKへの意見と回答」(2001.06.05):http://osask.jp/osask_oa.html]] |
| | + | |
| | + | &aname(qa0007); |
| | + | -[0007](2004.05.04) ぐいぐい00で文字コード別に処理ルーチンがあるのは設計が悪いんじゃないか？ 他のOSはこんなにタコじゃないぞ。 |
| | + | --普通のOSの場合、特定の文字コードをAPIの標準にしています。日本語DOSはシフトJISですし、日本語WindowsはシフトJISとUnicodeです。OSASKでは複数の言語を混在表示したいという思想から、まずシフトJISの採用は候補から消えました。また将来的には超漢字級の文字種を扱わなければいけないという要請から（これはエミュレータOSである以上、避けられないことです。特定のOSのアプリ（超漢字のアプリ）を容易にはエミュレーションできないような設計は、エミュレータOSとしては失格でしょう）、Unicodeで満足するわけにもいきませんでした。OSASKは文字（厳密にはフォント片）を32bitの整数で表現します。 |
| | + | --ここで普通のOS設計者のセンスだと、自分が考えた文字コード体系を押し付けて、それでプログラムを記述しろというのでしょう。自分の文字コード体系によほどの自信があるならそれでもいいですが、ぐいぐい00はそこまで自信過剰ではありません。また、実際問題としてたいていの日本語はシフトJISで書くと少ないバイト数で書けますし、現存する多くのテキストはシフトJISで書かれているでしょう。韓国語はEUCで書かれることが一般的です。これらからの文字コード変換を簡単に扱えるAPIをあらかじめ用意しておくことは、現実問題として理にかなっていると考えます。 |
| | + | --なおCのライブラリ関数を見るとなにやらシフトJISの文字列表示APIがあるように錯覚するかもしれませんが、あれはstaticライブラリで、中身は文字コード変換API＋汎用文字表示APIを呼んでいるだけです。ASCIIの文字表示ルーチンがあるように見えるのも錯覚で、これも中身は汎用文字表示APIの呼び出しです。 |
| | + | |
| | + | &aname(qa0008); |
| | + | -[0008](2004.05.04) ぐいぐい00は関数の引数が多すぎて設計悪いんじゃないの？ |
| | + | --[[［OSASK 2158］>OSASK:2158]]をまず読んでください。 |
| | + | --で補足したいことは、つまり引数の数はうまくマクロを書けばどうにでもできるということです。これは結局C言語上の問題であって、APIそのものの問題ではありません。しかしそれでも、とにかく「現状では」使いにくいかもしれません。KのようなC言語のセンスのない者ではなく、センス良い人が<guigui00.h>に代わるものを作ってくれればと思っています。 |
| | + | |
| | + | &aname(qa0009); |
| | + | -[0009](2004.05.04) ぐいぐい00の関数名がlib_で始まっているのはダサいよ。構造体名はLIB_で始まる上にtypedefされてないし。これをやめるだけでもソースがすっきりするのに。 |
| | + | --OSASKは完成したOSではなく今後APIが増えていくことが容易に予想されます。そこで考えていただきたいのですが、新しくできたAPI関数名が既存のアプリの関数名と衝突してしまうと、そのアプリのソースはわざわざ古い<guigui00.h>を持ち出してこないとmakeできなくなります。ということでそれを避けるために、関数名はlib_～にして、さらに構造体名はLIB_～にしてあるわけです。typedefしていないのは、どうせなら各自が自分のお気に入りのヘッダファイルを作り、そこでもっと使いやすい名前にtypedefしてほしいかなと。 |
| | + | /* "mylib.h" */ |
| | + | #include <guigui00.h> |
| | + | #define lib_openwintitle(size, window) \ |
| | + | lib_opentextbox(0x1000, 0, 0, size, 0, 0, 0, window, 0x00c0, 0) |
| | + | typedef struct LIB_TEXTBOX TBOX; |
| | + | |
| | + | &aname(qa0010); |
| | + | -[0010](2004.05.04) OSASKのファイルサイズで圧縮した数字を使うのはずるい。それならこっちはlzhやzipで圧縮したものと比較して当然だ。 |
| | + | --最初に言っておくと、これは一理あると思います。そういう比較でやり直すのもありです。 |
| | + | --もう一方の見解として、やはりOSASKは圧縮をかけた状態で比較するべきだという考えも同時に持っています。一応紹介しておきます。 |
| | + | --OSASKでは圧縮がかかったままで利用可能にするということを非常に重視しています。すなわち圧縮率よりも展開速度重視です。だからlzhとくらべて比較したらたぶんOSASKが不利でしょう。もしlzh圧縮した状態でもOSのデフォルトで実行可能なら、lzh圧縮での比較も意味があると思いますが、そうでないのならただ自分の都合の良い数字を出したいだけのような気もちょっとします（ただバイナリの複雑さの比較として圧縮後のサイズを使って比較することもあるので、その観点ではあえて圧縮して比較するのも意味があります。その場合は公平を期するために同じ圧縮アルゴリズムを使うといいでしょう）。 |
| | + | --こんなふうに圧縮を意識してOSを設計している以上、圧縮した状態で比較するほうが現実的だと思います。特にOSASKの場合は圧縮するほうが一般的ですし。 |
| | + | |
| | + | &aname(qa0011); |
| | + | -[0011](2004.05.04) OSASKの実行ファイルヘッダは拡張性がない。だから小さくて当然だ。（もしくは）ファイルヘッダから想像するとOSASKの実行ファイルは○○ができないはずだ、云々。 |
| | + | --そんなことはいえないと思います。OSASKの実行ファイルヘッダの考えは、まず非常に拡張性のある形式を考えて、その中で現状では使えなかったりなくてもそれほど困らない情報をカットした「圧縮形式」です。最初のシグネチャが圧縮形式であることを示すようになっています。まあヘッダのタイプが何種類かあると考えていただいてもいいです。 |
| | + | --複数の種類があるなんてずるいというかもしれませんが、たいていの場合で短い形式で済むのなら、そういう形式をわざわざ用意しておくのはむしろ合理的に思います。複数の形式を扱うせいで苦労するのはOSであって、その分OSがでかくなっているでしょう。ですからこの点を非難するならOSのサイズを非難するべきです。 |
| | | | |
| | * こめんと欄 | | * こめんと欄 |
