つれづれなるままに...
ずっと放置していたgsrvが落ちるバグを修正
ハイレゾで壁紙設定する時に「BOOSTモードでも」一瞬GUIが固まる事案が…
色変換に結構な時間がかかるみたいでサイズが大きい場合はbg処理するようにしました。
また壁紙設定アプリが一度ハイレゾで壁紙を指定するとメモリ不足で変更できない問題も対処しました。
ソース
ハイレゾモードで右端にマウスカーソルをもっていくとはみ出た部分が左からでてくる事案が発生しました。
たぶん前からだと思いますがいままで気付かなかったよ…orz
ソースのアーカイブが面倒なので差分のみ置いておきます。
XM6gどんどん良くなっていっていいですね。
あと地味にcoさんも復帰したりして嬉しいぞい！
私はなんというかアレな状況なので、気が向いた時に見つけたバグを修正する位の感じになってます。
よっしゃ復活！…あれ？… gsrv -16 が落ちる…orz
そういうわけで修正しました。
ソース
個人的にはめちゃくちゃ残念で余計な事した手合を恨めしく思うわけですが
基本的にこういう活動は「自分が楽しいからやる」もので、負担になったら続ける意味が無い事はよくわかるので
ここは涙をのんで「お疲れ様でした」の言葉を贈りたいと思います。
いままでありがとうございました。
偶然ねこで98のエロい人をネット上で生存確認！？
某プロにはお世話になったなー。
PIさんとこの御方がネットから消えて寂しく思っていたので嬉しい驚きでした。
私は…去年の秋口から最低最悪なずんどこ状態で復旧のみ込みなしです。
今回はプログラムの更新もありません。
FDC割り込み発生時のSENSE INTERRUPT STATUS発行有無の判定に付いてGIMONSさんが呟いてくれたおかげで解決できました！
実際は他にもバグが有り一筋縄ではいかなかったのですが「ここは正しい」という基準点ができたおかげでどうにか…感謝です。
正直、肩の荷が下りました(^^;
ソース
メニューが効かなくなってたり、せっかくのハイレゾに壁紙が設定できなかったりしたので修正しました。
フロッピーには1024x848(24bit)なbmpが容量的に入らないので小さい画像を画面いっぱいに拡大して表示する形になります。
逆に大きい画像は縮小しますがほとんど意味は無いですね。
あとリサイズはとっても遅いのであしからず。
FDC割り込み発生時のSENSE INTERRUPT STATUS発行有無の判定がわからない
insideに書いてあるDIOビットだけだと上手くいかなくて無条件発行してるためエラーログが大変なことに…
ソース
ネットの色々な所でXM6gはインターレースハイレゾに対応しているらしい記述を発見したので対応してみました。
さすがにこれ以上実行ファイルを増やすのはアレなので gsrv.x ＋コマンドラインオプションとして再構築しましが、疲れた…orz
-1 -4 -16 -1x -4x のどれかを選択する事でモードを指定します、指定無しの場合のデフォルトは -4 (4bitカラー)です。
あと -f オプションを追加するとキーボードフォーカスがマウスクリックによる切り替えでなく、マウスフォーカスが乗っているウインドウになります。
あと、ついでにGUIアプリに共通オプションを実装しました。
-wx -wy -ww -wh で左上座標とサイズを指定します。
左上座標はクライアント領域の座標でウインドウフレーム（タイトルバー等）のぶんズレるので注意してください。
あと指定/無指定の組み合わせに色々制限が有ったりします。
さて、ここまで書いておいてなんですが。右下のクロック表示が24kHzにならず15kHzになります…orz
IOCSを実行した場合はちゃんと24kHzになるし、その時の設定値をダンプして設定してるんだけどなぁ…アレコレ調べても解決しなかったので、とりあえず放流。
ソース
案の定エンバグしてました。
パイプとリダイレクトが死んでいたので修正版です。
またサブシステム周りがごちゃごちゃしてきたなぁ…はぁ。
最近、某動画サイトでMSXユーザー等が荒ぶっているのを見て、羨ましく悔しく複雑な気分になりました。
別な動画サイトで今更amigaのメガデモを見て驚いたり、刺激は多いのに色々付いていかないのが悲しい。
エミュレーター(XM6g/XM6i)だけが最後の希望です。
ソース
このウェブページを開いてからまる8年経ちました、開発を始めてからだと12年以上です。
万事三日坊主の自分にしては本当に長くやってきたなと…よく続いたなぁ。
しかしリリース内容はバグ修正なのでした。
以前から懸案になっていたジョブ終了時の後始末…登録したデバイスの削除と開いたファイルをクローズする処理を作りました。
前回の「仕様！」って奴がGUIを終わらせた後にgtermが作った仮想デバイスが残る事だったんですが、それに対応する事と懸案だったファイルクローズが基本的に同じ処理だったので、いっしょに作業しました。
結構な修正だったのでエンバグを仕込んだ可能性が大きいです。
エンバグと言えばモノクロサーバー作成時にバグを仕込んでしまって、それも修正しました…orz
ソース
いつものごとくバグ修正など。
例のバグはエネルギー不足で放置状態。
ソース
ちょっとだけ復活したので主に動作速度の改善目当てで1bitモノクロモードのGUIサーバー(gsrv1.x)を作りました、しかしちっとも速くありません！
fillrectとコンソールのスクロールだけですかね…速さが体感できるのは（※ビットシフト不要です）、他は全然…orz
さらに白状すると、それでも遅いのでコンソールは4行づつスクロールするようにしました。
まあせっかくなんでアップしますが切ない。
ちなみに初GUI時の比較スクショはこんな感じになります
実はgsrv終了時にgtermが作った仮想デバイスの残骸が残るバグを修正しようとしたらバグ（プログラムミス）じゃなく仕様（設計ミス）で対応が難しく放置したとか言えない。
気分転換にこっちをやったら、これはこれでドハマリして力尽きたとか言えない。
ソース
既に色々限界に近づいているので前回の更新を最後に放置するつもりだったのですが、XM6gのバージョンアップに伴いブートしなくなってしまいました。
コメントによるとFDD/FDC周りを大幅に修正した模様、実機テストしてない（できない）のって駄目ですね…orz
そんなわけで対応にも時間がかかってしまいました。
FDC周りはXM6gとWinX68k高速版で挙動が違う事が多いので悩みましたが「まだ一応」両方で動きます。
本当はSASI対応とかwindrv対応とか興味は尽きないのですが気力・体力がズタボロで回復する見込みも無いので、たぶん放置モードになります。
ソース
コピペのバグを修正しました。
wallpaper.xで上手く動作しなかったのが修正されています。
最近余力が無いので今回はこれだけです。
更新分
エディットコントロールにカット＆ペーストを実装しました。
かなり無理やりな効率の悪い実装ですがとりあえず機能はするようです。
操作はSHIFT+カーソルキー,マウス操作＆メニューもしくはCTRL+C,X,Vで。
他にもネタを仕込んでみたのですが日の目を見るのはまだ先になりそう。
ソース
gsrv16のディザを１階調分増やしたり、ナナメ線の描画を調整したりとちょこちょこ修正。
前回いじったCRTCもXM6gが調整中らしいので一旦元にもどしました。
さーてどうしたもんかな…
ソース
XM6gがDirectXに対応しました！
うれしくていじっているうちにバグを見つけてしまったので修正します…orz
１点はGUIで'_'が入力できない事
もう１点はGUI(512x512)の表示が右に偏る事です。
１個目は普通にバグ、２個目は…Inside/X68000ママなんだけどな？…とりあえず目分量で数値をいじって中央に表示するようにしました。
しかしいいですねXM6g
細かい点は置いといて、不足しているのってwindrv.sys位じゃないでしょうか。
実際には存在しない高速なMC68000を使ったX68000の後継環境として申し分ないです。
現状EX68以外のwindrv.sysが安定しないので、実質的にXM6とWinX68kを完全に置き換えてしまいました。
他のエミュレータが停滞しているなか作者さんはヤル気満々のようで嬉しいかぎりです。
ソース変更分
GUI上でアクションゲームが動いたらな…以前から思っていたのですが既に遅いのであきらめていました。
ですがここにきて「最新のX68K環境（XM6gのエコモード）で遊べればいいや」と開き直り、簡単なゲームを作る事にしました。
内容は「押し合いっこ」
自コマ（青）をカーソルキーで操作して敵（赤）を全て黒エリアに押し出せば勝ちです。
最初はもうちょっと凝った物を考えていたのですが色々面倒なので止めました。
ゲーム製作部（仮）的にはタイトルを○○○○にすべきか迷いましたが恥ずいのでパス。
やってみると機能が足りない。
あとやはり「できるだけ」速く動くように努力したいのでGUIの機能拡張をしました。
結論から言えば実機速度ではとても遊べません、WinX68k高速版の43MHzでなんとか（スローになる）程度。
基本思想が違うので仕方の無い面もありますが9fiveが10MHzでサクサク動くko-windowの偉大さをまざまざと見せ付けられる結果となりました。
ソース
デバッグ作業で疲れきっていたのですが、ふと新しい壁紙を作ってみたらマッハバンドが出る事に気付きました。
X68Kは15bitカラーなので滑らかなグラデーション部分ではどうしても色不足になるのですが、「gsrv16でもディザリングしたらどうだろ？」と思いつきまして…
色数が多くなるためgsrv4と同じ方式では無理が有るので極シンプルにやってみようと。
結果、「当たり」でした。
gsrv4よりは単純な方法なので、理論上は18bitカラー相当なのですが悪く無い結果を得られました。
さらにWinX68k高速版の場合はアンチエイリアシングが効いてる為、一瞬24bitカラーかと見紛うほどです。
そういう理由で浮かれてHPも更新です。
ソースをアーカイブし直すのが面倒なので変更したファイルのみ置いておきます。
更新ファイル
結局、前回版では直っていませんでした＞バグ。
で、この１ヶ月ひたすた追っかけていたのですが、まだ直っていないっぽいです…orz
それでもかなりの修正を繰り返して安定度は上がっているはずなので１度リリースします。
なによりせっかくXM6gでヴィヴィ言わせようと思ったらGUIがコケまくるのが悲しくて。
今度はそれなりに追い詰めない限りはがんぱってくれると信じています…信じてるよ？…信じてるんだからね！
ソース
仕事とかで疲れて中途半場にいじったまま放置してたのですが驚愕のニュースが！
XM6ファミリーのニューフェースが登場です。
その名もXM6g…グラフィック強化が目標とあるではないですか！
さらに地味に追加されているエコモードが私のツボを突きまくりで一発奮起してしまいました。
まぁ修正したのはgsrvバグの修正とアイコンの追加。
ドキュメント化すらしてないデモプログラムを１個っといったところなんですが…
しかもgsrvのバグは本当に直っているのかわかりません（爆）
一応
の３つの現象が確認されていて、それらを起こしかねない不具合は修正したのですが、確実な再現方法が無いため確証を得てません。
あと副作用でウインドウフレームの描画中はマウスが固まるようになってしまいました。
もっとなんとかしてから公開と思っていたのですが、興奮の冷めないうちにやっとけと公開に踏み切った次第です。
…勢いで公開しとかないとフェードアウトでお蔵入りする危険も有るので…
しかしCPUフルスピード+エコモードは最高ですね。
出来の悪いプログラムでもヌルヌル動いて、しかも熱く（ファンがうるさく）ならない。（おい
一区切りしたのでソースを放流。
10年以上続けた結果、かなり満足してしまいました。
ゴールはまだまだなのですが、さて何が残っているのだろう…？と
なんか箇条書きに収まっちゃいました。
開発環境とかは「一応」リストアップしただけで最初から諦めてますし、無限に思えた山々が何時の間にか数えられる位に。
実用的に使おうと思えばハードディスクや漢字入力は必須ですがおもちゃと割り切ればまぁ…
そもそもX68000を対象にして、しかも普及してないOSって時点で実用もへったくれもありませんし、なるほど満足感が大きいわけだと納得です。
昔と比べて気力・体力の衰えも激しく、正直この先に進むかどうかはわかりません。
ただ仕事としてのプログラミングに追われるなか、これは「娯楽としての」プログラミングなのでライフワークのように細々と続けられればいいなぁと思っています。
前回リリース版をWinX68K高速版+XVIのIPLROM.DATの組み合わせで使うとGUIが動作しない事が発覚しました。
「IPLなんか使ってないよ！何で？」…結果は単純なバグによりNULLアドレス近辺をアクセスしていたためだったのですが見つけるのに手こずったこと…orz
今回は公式にダウンロードできるIPL４種類と高速版＆XM6の全組み合わせで試したので大丈夫ですが、妙な理由でバグは隠れ、妙な理由でバグは発現するなぁとつくづく思い知りました。
あ、あとgeditの縦スクロールをちょっとだけ速くしました。
ずっとWinX68K高速版を使っていたのですが久しぶりにXM6で動かしたら上手く動きません…orz
とりあえずrootmenuとファイル選択ダイアログが落ちるのを修正して再アップです。
でもまだなんかの拍子に固まるんですよね＞GUI
あと動作が忠実な分、遅さも忠実でWinX68K高速版よりも動作が重くて重くて…orz
画面表示やキー入力の不具合、動作速度設定等の細々した使いかっての良さからWinX68kをメインに使っているのですがデバッグの事を考えると積極的にXM6を使わないとダメみたいですね。
しかし改めて重い…orz
CPUフルスピード時にSTOP命令が効いてくれれば（ホストCPUを食いつぶさなければ）いいのになぁ。
ツールキットの仕組み及び基本的なツールを作りました。
今回のサンプルは簡易テキストエディタとwallpaper.xのGUI化です。
ところが思わぬ落とし穴が…なんとディスク１枚に収まらなくなってしまいました。
まさかここまでプログラムが増えるとは思ってなかったなぁ…
しかたないので一部プログラムとbmp.xdfとあわせてsub.xdfに移動しました。
めんどうなのでreadme_sys.txtの内容はそのままです。
しかし遅いなぁ…WinX68k高速版の43MHz≒68030でも超モッサリで悲しい。
デスクトップを右クリックするとアプリケーションランチャーメニューが表示されるようになりました。
Windowsで言う所のスタートメニューですね。
前回と今回のVerUpで、まだボタン等のGUIパーツが無いにもかかわらずかなりGUIっぽくなった気がしてホクホクです。
なおGUIの終了のしかたが「LOGINターミナルを終了する」から「デスクトップメニューでGUI終了を選ぶ」に変わったので悪しからず。
この時にGUIアプリがエラーを吐くのですが・・・今後の課題にしときます。
ネット上で見つけた某リンクを辿り"萌えＯＳ"なるモノを見つけたわけですが。
「壁紙etcを変えただけでオリジナルOSって…」と思ったわけですよ。
ただその時「そういえば壁紙機能が無かったな」と思い至りひよってみましたｗ
画像の入手先はこちらです。
水田ムーン氏の著作である事を明示すれば非商用利用が可能との事なのでスクリーンショットに使いましたが24bit非圧縮BMPにしか対応してないので壁紙１枚でFDが埋まってしまうｗ
これだけでなくアイコンの自動整列やポップアップメニューツールの作成とそれを利用したアプリケーションメニューの実装。
テストケースとしてライフゲームも追加しています。
※メニューを持つアプリはタイトルバーの右クリックでメニューがポップアップします（今はライフゲームだけです）。
もちろん潜在バグ修正もたくさん有りました…orz。
GUIのバグをちょこっと修正しました。
あとgc.aを複数の.oファイルの集合にしてリンクサイズを減らすとか。
次のステップに向けての整理なわけですが疲れて頭が働きません。
次は何時更新できる事やら…
同じファイルを複数のタスクからオープンできるようにしました。
「だからどうした」と言った内容ですが地味に気になってた点が１つ解決です。
あとはCTRL+Cが使えるようにしたいのですが…難しいので絶賛放置中。
一区切りしたのでソースを放流。
はなから実用性が無いのは承知しているので、ついミニゲームや小物ばかり作ってしまいます。
なんだかビー玉やミニカー等を詰め込んだ子供の頃の宝箱の様相です。
そして何か作るたびに遭遇するシステムのバグ…orz
作るために作っている物だからいいんですけどね。
gterm.xとスケジューラーを修正しました。
ウインドウシステムを使ってマルチタスクをガシガシ使ってみると色々粗が見えてきたりして…
簡易TSSは良い塩梅になりませんね、最大の欠陥は遅すぎる事なわけですが。
本当はツールキットが気になってるのですが、考えがまとまりません。
色々疲れ気味だったり他に興味が移っていたり、まぁいつも通りマイペースでいきます。
GUIのマニュアルを追加。
また諸事情によりサーバーのデフォルトプライオリティをBGからTSに格上げ。
サービスコールのマニュアルを追加。
ソースを放流。
gterm.x と gclock.x のバグを修正しただけです。
gterm.x が多少まともになったので更新、スクロールと他のウインドウにクリップされた時の遅さは以前のままですが。
そろそろソースを整理して出したいところだけど忙しくて疲れ気味なんでちょっとお休み。
バグを取ったり最適化したり、また地味な作業に舞い戻り。
最適化と仕様を妥協した事により多少速くなったのですが、gterm.xが駄目駄目です。
作業中に妙に懐かしい気分になり、考えてみたらWindows3.0が出た時に似ているんですね。
PC-9801(V30)でノロノロと描画されるウインドウを操作したり、ソリティアで遊んでいるだけでワクワクしていた気持ちが再現されている感じ。
当時はウィンドウシステムというだけで興奮していたわけですが、今じゃすっかり慣れて当然の時代に。
けれど自分で作った事で同じ興奮を再び味えるとは…ちょっとビックリ。
誘惑に負けて派手な機能を作成。
快調と思いきや、潜在バグが大量に見つかり半泣きに。
さらに出来上がってみたら推奨スペックが X68000(100MHz) とか有りえないって… orz（※それでも遅い）
見た目はクラシック MAC のマネっこです、TWM とかシンプルでカッコイイやつが好きなので。
「色いっぱい」と「広い画面」にこだわった結果、２種類のバイナリーを作る事になりました。
| gsrv16.x | 32768色 | 横長ピクセル |
| gsrv4.x | 15色 ※ソフトウェアディザリングにより486色(笑) | 正方ピクセル |
| gsrv16.x |
| 32768色 |
| 横長ピクセル |
| gsrv4.x |
| 15色 ※ソフトウェアディザリングにより486色(笑) |
| 正方ピクセル |
むちゃくちゃ遅いし、たまに落ちたり固まったりするしで実用性は皆無ですが、元々実用性を論ずる事自体がナンセンスなプロジェクトなのでこれで良し。
オーバークロックしたエミュレーターでマインスイーパーを遊んでニマニマするのでした。
うちは VISTA BUSINESS だからマインスイーパーが付いてない(^^;
作業継続。
思う所有ってメモリー保護（所有権の管理とアドレスチェック）を始めとするセキュリティを意識したコードをバッサリ削りました。
結局、今の自分には持て余すだけのゴミコードだったので一度スッキリしようかと。
ハンドル処理の改良や上記関連の削除で多少軽くなったけどまだ重い。
RPC やシステムコールはもちろん、ファイル I/O が遅すぎる…どうにかならんかね。
カーネルコールも含めて色々変更したからドキュメントの修正が大変すぎ…
sc のドキュメントも作りかけだけど、どうせ変えるだろうし放置決定。
地味に /proc を作ったり放置箇所を潰したりしてますが道のりは遠いなぁ。
派手な機能も欲しいけど、それ以前に不足や半端が多い。
パワー不足、軽量化に意識が寄ってコードサイズが気になる。
まぁ俺様プロジェクトなんでテキトーにやる(orやらない)わけですが。
とか言っといてなんですが、XM6の開発が再開しないですかね。
np2(PC9801エミュ)とか、この辺のプロジェクトが軒並み停止してしまったのはファンとして寂しいです。
MKEditor復活バンザイ！
ソース
整理したつもりだったのに…むしろ層が増えて複雑＆重くなった。orz
まだ区切りが悪いけどチト疲れた。
PC が壊れたので VISTA マシンを購入したら WINDRV.SYS が安定しない。
まさかの EX68 が大復活！
1 年が速い…
パイプとリダイレクトを実装しました。
コード整理のつもりが、アドホックな機能追加に走ってしまった。
関連して ^D にも対応しましたが、これも（略。
プログラムの実行に時間が掛かりすぎだし、フィルターがほとんど無いしで役立たずな訳ですが、まぁ楽しいから。
more のキー入力が特殊な事をやってそうな事に初めて気付きました。
パイプから入力する場合、標準入力はデータの受け口だからキー入力は別口が必要でしょ？
…あっ、でも途中に more を挟んだ時はキー待ちしないよね（無意味だけど）。
どうやって処理してるんだろう？
FILE* を排他制御するように変更しました。
元々 "同じ FILE* を複数のタスクで平行操作する必要なんてないし、必要なら自分で排他処理すべきでしょ" と思っていたのですが、
そうすると printf を複数のタスクから呼ぶだけで誤動作すると "今頃" 気付いて修正と相成りました。
TLS にも手を出したのですが、困った問題が出て放置中です。
また kc を rpc を中心に仕様変更しました。
kc と libc の中間層はゴッソリ入れ替えたし、他にも変えたい点が出てきたので、この先も色々変えそうです。
あとはバグ修正を色々。
致命的なのも有って凹むなぁ。
他にも沢山有ったけど細かいのは覚えてないや。
DIR のバグは「タイムゾーンが反映されない」事が原因だったのですが、以下の要素が絡み合った結果です。
間違いが有るかも知れませんが、こんな感じです。
単純ミスだと思っていたら OS の由来まで遡ってしまいました。
自分でやって解かる事の多いこと、ささいな事にも理由が有るんだと痛感します。
ドライブ１が使えるようになり、かつドライブ０／１共にディスク交換が可能になりました。
起動ディスクを抜いても基本的なファイル操作ができるようにシェル組み込みコマンドも大増量です。
ディスク交換には mount/umount コマンドが必要で、抜き差しだけでは駄目なので注意してください。
ドライバから libc まで手直しして微妙に速度アップしました。
cat の表示や XM6(10MHz) でのキー取りこぼしが改善しています。
今回のバグ修正は範囲が広くて大変でした。
しばらく触ってなかったカーネルにバグを見つけたり、libc のテキストモード出力のバグ＆間抜けさが発覚したり。
libc のバッファド I/O は色々いじったからかえってエンバグしてるかも。
また今回の修正も含め、サブシステム周りは特にズタズタです。
ヤッツケ仕事とハリボテの塊だから再構築したいけど…色々足りない。
久しぶりにコードを見ていたら、ゾロゾロとバグが出てきやがりました。
ラインバッファリングが効いてないとか、more が TAB や全角割れに対応してないとか…んで虫取り大会。
強敵と戦うには知恵と元気が足りないから、とりあえずこんな所で。
それにつけても HIOCS.X は速いね！
五目並べとオセロゲームを追加しました。
これらのゲームは 15 年位前に当時 BASIC オンリーだった私が C 言語を勉強するために作った物なのですが、
今見返すと余りもの汚さに失神しそうになります。
というか、きちんと理解せずに勢いだけで書いてあるから今のコンパイラじゃ通らないし…。
コンパイルを通すためと、あからさまなバグだけは修正しましたが、あとは放置です。
コードの質はともかく、この程度のプログラムが普通に動作するようになった事は感慨深いものがあります。
コンテクストスイッチすら書けず妄想逞しくしていた頃は、ここまで来れるとは思っていませんでした。
作り始めてから 7 年近く経ったわけですが、苔の一念とはよく言ったものです。
実数の四則演算ができるようになり、libc の残りも埋まったので更新。
…と言いながら実数の四則演算は自力で作れませんでした（爆）。
いゃ、アセンブラ得意じゃないし、作ってもバギーで遅いだけだろうし…。
結局、資料を求めて彷徨っている時に見つけた f2hs.x のコードを使わせてもらいました。
作者の人に感謝です。
さて、とえあえず埋まった libc ですが使う度にバグが出ます。
コンパイルだけ通して放置しているコードも多いので、まだまだ出てくるでしょう。
libc 以外にもバグ修正や改良をしましたが、まぁ地味な内容です。
今回は実数演算記念としてマンデルブロ集合を描かせてみました。
エミュレーターは XM6改です。
重い処理のため 'MPU のみノーウェイト動作' で実行しても、かなりの時間が掛かりました。
ちなみにコマンドは 'mandel -0.758 -0.068 0.0025 10000 3' です。
ソースコード
という事で、誰も見てないだろうな〜と思いつつソースを晒して見るテスト。
やりかけのコードを晒すのは便所の扉を開け放つようで恥ずかしい…。
でも終わりは見えないし、色々尽きてきたし。
なし崩しで闇に葬るのも惜しい気がするから、とりあえずね。
前々から気になったまま保留しておいた問題が、libc の開発で浮上してきました。
アプリケーションで保持している HTSK 等のハンドルが他のタスクによる「資源解放→新たな資源確保（ハンドルが再利用される）」の手順を経て気付かぬ内に別な内容を指すようになり、誤動作する問題です。
※類似ケースとして「使用中のハンドルを勝手に削除されてしまう」も有りますが、これはまた違ったレベルの問題だと認識しています。
MPL の場合は管理データ領域のアドレスがそのままハンドルになっているので、再利用は頻繁に発生するわけで…
libc の「マルチスレッド非対応」の１つはこれが原因で、対応できないでいます。
案としては
等が考えられますが、
1. の方法は本質的な解決ではなく、またハンドルの検索（正当性チェック）に今以上の時間とメモリーを消費するので気が進まず、
2. と 3. の方法は API が複雑になりすぎる気がします。
4. は無理だと思っているのですが…。
やはり勉強不足か。
ちゃんと標準的なアルゴリズムを勉強しなきゃかも。
つまみ食いした本のどっかに書いてあるかなぁ。
3年以上前に作りかけたまま放置していたコードを引っ張り出してきました。
X68000/libc や GNU/libc を移植するのは大変そうだし、ライセンスも不安だし、libc 自体にも興味が有るから…と勉強がてらに作り始めたわけですが、7割位？コードを書きなぐって放置…そして３年半。
当時「ヘッダーファイルが複雑すぎて、どれが標準の定義で、どれが内部実装や拡張定義なのか分からん」と不満を感じたので、ANSI C言語大辞典を睨みつつ、極力余計な定義を見せないように作っていたのですが、さて、どんなもんか…
ファイル分割がイマイチなので、ほぼ全体をリンクしてしまう困ったちゃんですが、無いよりマシと言う事で。
「MPL って Mozilla Public License の事でしょう？」
もちろん偶然です。
そもそも、これは仮名だったんです。
単純にカッコよさげな名前（フェニックスとかクリスタルとか...）は既に使われていたし、
英単語の頭文字によるネーミングも、なかなかしっくりくるのが無いし。
散々頭を捻って考えたのが Multi Programming Layer だったわけですが、これだとアルフェベット読み以外できないので、
何か別のを考えたいなと。
一時は「漢字で神秘的な名前が良い」と言う理由から「真名 (mana)」にしたのですが、
mona を見つけて呆気なく撃沈、
「もう面倒だし、メジャーにはならないから問題なんざ起きないでしょ。」と MPL で落ち着きました。
良い案を思い付けば換えるかもしれないけど、
ユーザーランドも巻き込んで、一部の関数名や定数等を置き換えるのが面倒だなぁ。
無いですねぇ。
対象プラットホームは失われつつあるし、実機で動作確認できてないし、
基本機能すら満足に無いし、実用性は皆無です。
仮に基本機能をそろえた上で PC-AT 互換機を対象にしても、
今有る OS に対して何のアドバンテージも無いし、
そもそも汎用 OS はアプリが乗って（≒普及して）ナンボなので、
やはりガラクタに変わりありません。
「好奇心と自己満足」、これに尽きます。
楽です《きっぱり》。
windrv のおかげで、Windows 上のソースを弄りつつ、エミュレータ上でビルド→実行ができ、
FD を焼き直す手間や、コンピュータを何度もリブートさせる手間が省けて大助かりです。
XM6 のデバッガーを使えば ICE まで揃ってしまいます。
そして何より、事故った時のダメージが少ないから、安心して無茶ができます。
実機で開発していたら、面倒で投げてましたね、私は。
えぇ面倒臭がりですとも。
ひさしぶりに火を入れたら、実機の（たぶん）モニターが死んでました...
for X680x0 の可能性が完全に消えてしまった。
開発を始める時に文字コードやコメントをどうするか悩みました。
普段使いの SJIS か、 SJIS はダサいから EUC や UTF-8 にするか、
いっそ ASCII 文字のみがいいのか...。
でも結局、「完全にポータブルなテキストファイルは作れない」との結論になり、普段使いの SJIS にしました。
多バイト文字以前に改行コードが統一されてないんですよね。
全てを ASCII 文字にしてさえ、ポータブルにはならないとは...なんだかなぁ。
まぁ、SJIS 以外を選択すると、エディターやコンパイラーの問題があるし、日本人だからコメントは日本語で書きたいし。
良く考えれば、始めから選択の余地は無かったんですが、
風呂敷だけは大きかったんです。
なんで普通にコード吐いてくれないんだよぉ〜。
いや、ポータビリティーを上げるためだとは解りますが、
既存のライブラリーを外していったら除算ができなくなったので。
結局の所、演算子 / と % を使うために libgnu.a は必須です。
また FLOAT ドライバー相当のコードが無いので、float や double の演算ができない...
こう言うのも OS の範疇なのかなぁ。（遠い目）
そういえば 386 の頃の PC-UNIX も「浮動小数点演算ユニットが必須です」とか言ってたし、
NetBSD/X68k もそうだったっけ。
「デバイス（浮動小数点演算ユニット）を管理する」と言う観点からすれば、確かに OS の仕事かも。
ソフトウェアでの演算は眼中に無いってか...
ネットを徘徊している時、OS 作成を夢見る人に他の人がアドバイスしている場面に、何度か出くわしました。
「テキストメッセージを表示するプログラムを IPL から動作させて、それに肉付けしていく。」
と言う内容が多かったようですが、私の作業順序は逆です。
IPL から起動するようになったのは、割と最近の事で、それ以前は human68k から起動する .x ファイルとして作成していました。
...と言うか、今でもデバックに多用してます。
クラッシュしなければ ビルド→テスト の繰り返しが楽なので悪く無いんですが、この状態じゃ OS とは呼べないからイマイチですかね。
MPL OS は一見するとマイクロカーネル方式のリアルタイムＯＳっぽいですが、これは違います。
最初 (2000年当時) は息巻いていたんですけどね。
「マイクロカーネルでリアルタイムＯＳで小さくて速くて頑健で etc, etc...」
で、結局出来上がった物は能力相応で野望には程遠い物だったわけですが。
ちょっと悔しいんで、うんちく垂れてみます。
リアルタイムＯＳの定義って、はっきり知らないんですが、私はこんな風に理解しています。
無保証を旨とするフリーソフトの時点で 4. の要件を満たせませんし、
3. を満たすのも現実的には難しいです。
X68000 ならまだしも、最新の CPU を乗せた AT 互換機の場合、ハードウェアのバリエーション・コンパイラの動作・CPU の内部状態等を考慮し算出する事は絶望的に思えます。
よって世に有る多くのリアルタイムＯＳは、厳密な意味での証明はせずに、
「十分高速だから貴方の要求は満たせますよ」と妥協しているのだと邪推してます。
そして、これでは余りに厳しいので、要件 3. と 4. を除いた物が、俗に言う「ソフトリアルタイム」だと考えています。
では MPL OS はソフトリアルタイムで動作するのか...残念ながら、これも駄目です。
メモリー管理や優先度の継承周りは状況により際限なく時間を食います。
これらはカーネル内部でも利用されているので直接的な利用状況は無関係です。
そもそもカーネルコールの引数チェックで「検索処理」をしていますし、他にも多くの問題コードを含んでいます。
よって要件 2. は満たしていません。
「リアルタイム処理でメモリ確保等の動的な資源管理をするのが間違いだ」
という考え方も有り、私はこの考え方を支持します。
しかし MPL OS の場合は、それでも要件を満たしません。
要件 1. も満たしていません。
MPL OS はカーネルコールの実行中は割り込みを禁止しています。
なのでメモリー管理等の処理時間が予測不能なカーネルコールの実行中に割り込みが入った場合、
その処理ルーチンが呼び出されるのが何時になるのかは「神のみぞ知る」です。
要件 5. は辛うじて満たしていますが、これだけでリアルタイムＯＳを名乗るのは抵抗があります。
マイクロカーネルの定義はもっと解りません。
「カーネルは最小限の機能のみを提供し、ファイルシステムやデバイスドライバー等はカーネル外に追い出す」
と言うのが一般的な説明だと思いますが、なにが最小限で何が外なのかが解りません。
で、たぶん一般的だと思う要件は
ただし、私は 2. と 3. は不要だと思ってます。
保護とかプロセスとかは関係なく、サブシステムやドライバーのカーネルに対する位置付けがアプリケーションと同等で有れば良いと。
「サブシステムやドライバーがカーネルを呼び出す手段と、アプリケーションがカーネルを呼び出す手段が同じである」
と言うあたりがポイントかな？
例えばアプリケーションはトラップ命令経由でカーネルの機能を呼び出すのに、ドライバーは直接、関数呼び出しするのはアウト。
組み込みＯＳ等で、ドライバーもアプリケーションも（同じ関数を）関数呼び出しでカーネル機能を呼び出すのはセーフ。
といった感じです。
で、MPL OS の場合ですが、一般的と思われる解釈の場合はアウト。
個人的な解釈ならセーフです。
でもプロセス管理が追い出せてないので...やっぱりアウトかな？
もっともマイクロカーネルだったとして、べつにメリットは無いです。
今更めずらしくもないし「だからどうした」ってなもんで、
むしろマイクロカーネルとモノシリックカーネルの "悪い所取り" な内容をどうにかしろと自己突っ込みが入るだけだったりして。
開発者の立場としては、「I/O 待ち等の OS 内部のスケジュール処理をマルチタスクを使って簡単に書けた」と言うメリットが有りました。
追加：Real-Time Mach NTT Release 2 の 論文や解説記事 の項で、日本語の解説記事が読めるようです。