そーいえば、ウィンドゥの扱いがちょっと変化したのでapi_openwin関数をちょっと改良しないといけないなぁ・・・

えっと。現在は

• EDX = 5
  
• EBX = ウィンドゥのバッファ
  
• ESI = ウィンドゥのX方向の大きさ
  
• EDI = ウィンドゥのY方向の大きさ
  
• EAX = 透明色
  
• ECX = ウィンドゥの名前
  

・・・ふむ・・・こんな感じだよね？
う〜む・・・レジスタが足りない・・・
おっし。じゃ、EBPを属性として、ビットごとにっていうことにしよっか。（つーかそれしかないでしょこれじゃ）

• EDX = 5
  
• EBX = ウィンドゥのバッファ
  
• ESI = ウィンドゥのX方向の大きさ
  
• EDI = ウィンドゥのY方向の大きさ
  
• EAX = 透明色
  
• ECX = ウィンドゥの名前
  
• EBP = ウィンドゥの属性
  

• bit0: 0ならウィンドウじゃない。1ならウィンドゥ
  
• bit1: 0ならタイトルバーを持たない。
  
• bit2: 0ならフレームを持たない。
  
• bit3: 0ならフットバーを持たない。
  
• bit4: 0なら固定ウィンンドゥ。1なら可変
  
• bit5: 以下リザーブ（将来のために）
  

・・・こんなところかな・・・
おぉ！　リザーブだって！　なんかカコイイ！！　　←バカ

・・・あ"〜・・・そっかぁ。バッファの扱いかぁ・・・・
現在の状況だと、新しいmake_window関数はシステムとしてバッファのメモリを確保しちゃうんだ。
こりゃまずいよなぁ。アプリはあくまでもアプリ用のメモリ内でバッファを確保せんといかんわけで・・・
うーん・・・どーしよう・・・・

田んぼチャージャー・・・・　（ボソっ）

えっとぉ〜。ちょーっと問題が出てしまったでゴンス。

今のBBLはシートの重ね順がはりぼてと違う（つーか、追加されてる）
そのための除外処理が甘かったようだなぁ。

    sht_mouse    ←なにがどうなっても最上位にいないといけない

    sht_menu     ←なにがどうなってもこの位置に

    sht_tbar     ←       〃



    さまざまなシート



    sht_back    ←なにがどうなっても最下位にいないといけない

しかし、今の状態だと新しいアプリを起動したりした時（新しいシートというかウィンドゥが加わった時）この順列が狂ってしまう。
bballがsht_menuの上に来たりしてはいけないのでする！

えーっと・・・そうなると・・・

まず、はりぼてだと、構造体SHTCTL内に256個のsheets・sheets0があるよね。
shtctl_initで初期値を設定している。256個のsheets0に「未使用だよ」とマークし、さらにtopを-1としている。これがシートが一枚もないという状態。
sheet_allocで未使用のsheets0を探して使用中だよとマークして確保する。
しかしまだこの状態だと、この確保したsheets0の高さは-1。つまり非表示の状態。それだけしかやっていない。裏を返すと使用中にシートが何枚あろうと、表示していない限りはtopは-1のまんま。
出来上がったsiheets0を、sheet_updown関数に通すことで始めて表示が行われる。sheet_updown関数は高さの変更だけではなく、表示・非表示の制御も行っているのだ。
top変数もまた、この関数内で制御される。

・・・っということは・・・・・
マウスやメニュー等、一度設定したらもう二度と高さが変更されないシート。これらが設定される前と後でtop変数の扱いを変えたらどうだろう？？


・・・いや。これはこれで。
それより、アプリ関係（つまりシステム以外）のウィンドゥの高さを専門にあつかう関数を新設してみた。どんなもんじゃろ・・・？

いけた〜♪。

WindowsやMACみたいに、窓の下の可変ポイントをつまむと
びよ〜ん！

ウィンドゥの大きさが変えられる〜！！！！

・・・ような感じに見えるだけです・・・・・orz

まだ心臓部をまったく搭載していないんですよ。

つか、こんな「見た目」だけでもオイラのようなタコにはきつかった〜。

試行錯誤の連続であやうくソースがごっちゃごちゃになりかけました。（いや〜。SVNって偉大だなぁ（＾＾；

いよいよ、実際にウィンドゥが伸縮できるようなエンジンに手をつけます。・・・つか、早く完成させないと・・・そろそろ飽きてきた・・・・

ちょっと思ったのだが、現在のはりぼての設計だと、ウィンドゥを作ったりする場合の数字があいまいだと感じ始めた。

・・・っというのは、たとえばオイラが100x100のウィンドゥを作りたくて命令を書いたとする。その場合、100x100の、オイラが自由にできる領域が出来上がるよね？

でも、その場合、タイトルバーやウィンドゥの枠、フッター等がこの100x100に入り込んではいけない・・・というか、まずいと。

それはOS側が一括で管理し、統一できないとまずいような気がしてきた。

そんなわけで、そういう部分にちょっと手を入れてみよう。

いやなに、そんな御大層なことじゃない。単に「100x100のウィンドゥをくれ！」と命令すると自動的にタイトルバー等を付加した状態の窓ができあがると、そんなところ。

・・・ウィンドゥサイズの可変化・・・

してみて〜！！！

・・・でもかなりハードルが高そうというか大掛かりになってしまいそうだなぁ・・・

とりあえずここいら辺りでゴニョゴニョしてみるか。

リビジョン106と107の差。いらない関数を省いたので当然カーネルの大きさが違う。

106が54,583バイト。107が53,311バイト。当然使用しているクラスタ（セクタ）の数が違う。106は107セクタ。107は105セクタ。

えーっと。まず。ディスクからはこれ、ちゃんと読まれているかな？
ipl09.nasの現在の状態だと、18*2*9-1。すなわち288セクタが起動時に読み込まれている。288セクタだから・・・147,456バイト・・・。
うむ。確実にカーネルは読み込まれているはずだね。

次。メモリへの転送。

・・・・あれえぇぇ？

いろいろとコード追ってみたけど、ちょっとはみだしって感じじゃないような気がしてきた・・・

なんだろう？　これ？？？

1. なぜか320x200モード時、タスクバーの文字が書かれない
   
2. 起動直後、他のウィンドゥもアクティブ状態になる
   
3. タスクバーにはウィンドゥがかからないようにすべきでは？
   
4. タスクバーをクリックすると他の窓が非アクティブになる
   
5. コンソールだけど、画面の広さに応じて対応してくれないかな
   
6. 日本語フォントをFDから読むか、もしくはカーネルに内臓したい
   

さーて。コンソールの大きさの自動調整はこれでいいかな？



・・・おんやぁあぁぁぁぁぁ？？？？

fd.cやconsole.c内のいらない関数を削ってメイクしたら、320x200モードでもちゃんとタスクバーの文字が出るじゃん！？？？

こういうのって、大抵、なにかがどこかにはみ出している時の症状なんだよなぁ。

うむむむ・・・ヒントが出てきたぞ！　カーネルのサイズやメモリマップのもう一度よく精査してみよう！！

うーむ。もう一つどうにかしたいことが・・・

1. なぜか320x200モード時、タスクバーの文字が書かれない
   
2. 起動直後、他のウィンドゥもアクティブ状態になる
   
3. タスクバーにはウィンドゥがかからないようにすべきでは？
   
4. タスクバーをクリックすると他の窓が非アクティブになる
   
5. コンソールだけど、画面の広さに応じて対応してくれないかな
   
6. 日本語フォントをFDから読むか、もしくはカーネルに内臓したい
   

うむうむ。だいぶ悪いクセも片付いてきましたなぁ（＾＾

ところでちょっと思ったこと。

今のはりぼての仕組みだと、コマンドの引数は丸ごと（コマンド名まで含めて）渡されるよね？。で、内部で自分で引数を分解処理しないといけない。

これ、面倒になってきました・・・(´・ω・｀)

今あるAPIはそのままにして、これとは別に自動で引数を分解した状態で渡してくれるようなAPIを搭載してみようかなと・・・

1. VESA対応機にて高解像度にならず落ちてしまう
   
2. なぜか320x200モード時、タスクバーの文字が書かれない
   
3. コマンド実行後、カーソルが点滅しなくなる
   
4. 起動直後、他のウィンドゥもアクティブ状態になる
   
5. タスクバーにはウィンドゥがかからないようにすべきでは？
   
6. タスクバーをクリックすると他の窓が非アクティブになる
   
7. dir2コマンドが古い
   
8. type3はもういらないのでは？
   
9. apiでseekが搭載されていない
   
10. memdumpコマンドが絶対番地に対応していない
    
11. FDアクセスで、4e等古いAPIが残っている
    
12. vesaコマンドが実機ではStackのエラー？を起こす
    

1. VESA対応機にて高解像度にならず落ちてしまう
   
2. なぜか320x200モード時、タスクバーの文字が書かれない
   
3. コマンド実行後、カーソルが点滅しなくなる
   
4. 起動直後、他のウィンドゥもアクティブ状態になる
   
5. タスクバーにはウィンドゥがかからないようにすべきでは？
   
6. タスクバーをクリックすると他の窓が非アクティブになる
   
7. dir2コマンドが古い
   
8. type3はもういらないのでは？
   
9. apiでseekが搭載されていない
   
10. memdumpコマンドが絶対番地に対応していない
    
11. FDアクセスで、4e等古いAPIが残っている
    
12. vesaコマンドが実機ではStackのエラー？を起こす