***本記事にはプロモーションが含まれています。***

なのだそうです。MSのKBに書いてあった。
そうでないと、WSAConnectがWSAEINVALを返すそうな…。道理でつながらないわけだ。ノンブロッキング動作には、socket()関数ではなくて、WSASocket()関数でソケットを作らないといけないということですね。
実際にconnectで調べてみると、最初はWSAEWOULDBLOCKが返って、次はWSAEINVALになる。やっぱりconnectを2回呼び出してはいけないみたい。あまり関係ないのかなあ。
これは、Winsock FAQに書いてあってもいい情報だと思うけど。
overlapped structure やcompletion functionをNULLにしておけば、ブロッキングと同じ動作にすることができるのだそうです。でも、CreateFileのところには、Overlapped動作のときはNULLにしてはいけないと書いてあったと思う。なんか複雑。
http://support.microsoft.com/kb/179942/EN-US/
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q181611

***本記事にはプロモーションが含まれています。***

アプリケーションのお話でした。ごにょごにょしておきました。
やっと、読み終えることができました。
ウィンドウシステムのところから少しついていけなくて、思った以上に時間がかかってしまいました。途中何度も中断があったのですが、とりあえず最後まで読み通せてよかった。読み通してみて、少しはプログラムを作る力がついたならいいのですけど。どうでしょう。
取り上げられていないOSの話題としては、ページングを使ったメモリ管理、プロセス管理、ファイルシステム、ネットワークなど、いろいろありますよね。６４ビットに関するものには興味があるので、いずれそれに関するプログラムができたらいいのですけど。
中級者向けの、もう少し違った書き方をした本が読みたいなと思います。

***本記事にはプロモーションが含まれています。***

LDTと日本語表示の話でした。
なんかやさしく感じた。LDTとかは、少し知っていることだったからかな。日本語表示も、実際に自分で実装しようとしたら苦労するだろうなと思った。
あと少しになりました。

***本記事にはプロモーションが含まれています。***

コンソールとウィンドウの話でした。ちょっと時間が空いてしまい、だんだん忘れかけているという…。
OSみたいな大きなプログラムを作ろうと思ったら、ある程度記憶力が無いとだめなような気がしてきた。記憶しておくといっても普通の人には限度がありますよね。忘れないことより、思い出しやすいということを心がけるしかないのかもしれませんね。よく理解したコーディングを積み重なることしかないのかな。

***本記事にはプロモーションが含まれています。***

グラフィックとウィンドウの話だった。
正直言ってよくわからなかった。ウィンドウを作るうえで、基礎的なことは何でしょう。必要なことは何でしょう。注意することはどういうことなのでしょう。
ウィンドウシステムは、ハードウェアを扱うものとは違ってソフトウェアの自由度が大きいのでしょうけど、基本になることって何でしょうか。

***本記事にはプロモーションが含まれています。***

マルチブート用にAcronis OS Selectorを使っているのですが、デフラグしたらハードディスクから立ち上がらなくなってしまいました。CD-ROMも壊れていて、なす術がなく、新しいDVDドライブを買ってきました。BuffaloのDVSM-XL516FBなのですが、CD-ROMが回るとちょっと音がうるさくてがっくり。仕方ないけど。壊れたDVDドライブもGSA-4082Bなのですが、CD-ROMだけ読めないとい壊れ方で、マルチドライブも意外な欠点があるのね。
フリーのブートマネージャもあるのですが、以前パーティションが壊れたとき、System Selectorの復旧ツールが役になったことがあって、なるべく安い市販のツールを使うようにしているのでした。でも、デフラグで立ち上がらなくなるのもなー。
立ち消えになっていた、Windows XP x64のインストールやるぞー。

***本記事にはプロモーションが含まれています。***

RedHatのサイトより。gdbでマルチスレッドのプログラムをブレークポイントで止めたときは、すべてのスレッドが止まるって。シングルステップさせたときは、他のスレッドはどこで止まるかわからないんだって。
だから、他のスレッドのブレークポイントに引っかかるとそっちで止まるんだって。
ホストOSのスケジューラをロックできるOSもあって、
(gdb) set scheduler-locking on
で、他のスレッドを実行させないこともできるそうだけど、Windowsは当然できないよね。
(gdb) info threads
で、スレッドの表示。
(gdb) thread threadno
で、threadnoに番号を入れるとスレッドの切り替え。
(gdb) break linespec thread threadno
で、linespecにソースの行番号、threadnoに番号を入れると、そのスレッドがソースの位置に来たときに止まるんだって。
Windowsで、_beginthreadexを使ってスレッドを作ると、なかなかinfo threadsに表示されないです。すぐには実行されないようです。
WaitForSingleObjectで終了待ちをするとやっとスレッドが開始されたりしています。
ところが、本質的にスレッドはプログラム中のどこでスイッチしてもいいわけで。スレッドを複数作ってみると、実行の順序が反対になったりします。

***本記事にはプロモーションが含まれています。***

-mthreadsオプションを加えないといけないみたい。mingwm10.dllが使われるんだって。
-mthreadsを使うと、_MTというマクロがdefineされた状態になって、getc,putcなどがインライン関数でなくてライブラリにあるものが使われるようになる。
コンパイルとリンクを別々にやるときは、コンパイル時に-D_MTをつけないといけないか。
その他にも、ヘッダーのgthreadかな、の中にも書いてあるけどわけわからなかったり。
Cのプログラムを作って、依存関係を調べてみると、mingwm10.dllは必要なかった。C++のプログラムの場合は、リンクしたライブラリがDLLを必要とするようです。

***本記事にはプロモーションが含まれています。***

OSを守るという話と、C言語でアプリケーションを作るという話。
特権レベルを切り替えるとOSの保護ができますというわけ。ソフトウェア割り込みでも、特権レベルの切り替えが起こればスタックの切り替えも起こるのでした。
コンソールタスクのままアプリケーションをその延長上で動かしているという感じなので、タスクの切り替えが起こっていない気がする。
TSSに必要なEIPなどを設定して、別タスクとして起動したほうが自然な気もしますけどね。
Cのプログラムでmainが終わると終了するようになっているのは、ライブラリがapi_endのような終了処理をやっているからだよね。
アプリケーションとOSがつながった気がした。
今は、アプリケーションとOSを両方作っているからあまり気にならないけど、別々に作った場合、どこまでOSが面倒を見るのかって使い勝手の点で大切なんだろうな。

***本記事にはプロモーションが含まれています。***

アプリケーションとAPIの話でした。
ファイルを見つけると、メモリにロードしてセグメントを設定して実行してしまうという話。特権レベルが変わっていないせいか、ソースコードだけを見ているとOSとアプリケーションの区別がつかない気がした。
アプリケーションからOSの機能を呼び出すのは、ソフトウェア割り込みが一般的なんですかね。そういえばLinuxもint 0x80だし。その他、コールゲートというのがあるのは知っているけれど、他にはあるのかな。