見積もりを知ろう その1

みなさん、こんにちは。Dr.テトランです。

半年ぶりのエントリとなりましたが、4月に入って建設業にも多くの新入社員が入社し、見積もり業務に携わることになり、「見積もりって何だ?」と思わる方もいるかと思います。

そこで今回から趣向を代えて、弊社の新人S君に見積もりについてレクチャーを行いますので、みなさんも一緒に理解を深めていただけたら幸いです。

 

 

自己紹介:新人S君 今春入社した期待のホープ。趣味はゲーム

 

 

「どもっ、新人Sです」

 

「やあ。初々しいね。ところで、S君、和田特機は何のソフトウェア作っているか知っているかい?」

「見積もり業務と聞いています」

 

「そう。見積もりだね。では、見積もりと言ったら何を思い浮かべる?」

 

「そうですねえ・・・この就職を期に引っ越しをしたのですが、その前に業者から見積もりをとりました」

 

「うん、そうだね。引っ越しなどのサービス、車などのモノを購入する前には見積もりをとったりするよね。要は売買契約する前に、金額を算出することを見積と言って、それを書面化したものを見積書と言うんだ」

 

「はい」

 

「見積書には金額だけでなく、数量や期間、行動も書面化して、最終的に売買の合意を形成するための証となるんだよ」

 

「はい」

 

「ここでクイズだ!建設業の見積もりと車のようなモノの見積もりと大きく違う点があるんだ。それは何かわかるかい?」

 

「わかりません(キリッ」

 

「コラッ!即答でわかりませんじゃない!もうちょっと考えなさい」

 

「は~い」

 

「ったく・・・」

 

「う~ん、扱う金額が大きい・・・ですか?」

 

「うん、それもあるね。それと、一般消費材は定価というものが存在して、定価に対する見積金額だけど、建設業が作る建物は一物一価といって、該当する敷地の中にどんな大きさの建物を建てるのか?によって金額が異なるんだ」

 

「なるほど、同じ敷地面積に、同じ目的のビルを建てることは無いですものね」

 

「そうなんだ。だからまず始めに、条件にもとづいた設計図を作成し、それを元に建物や設備の工事の価格を算出するんだ」

 

「はい」

 

「さらにややこしいのは大きく分けて、設計図、施工図、竣工図という図面があるんだ」

 

「でも設計図をみて見積もればいいんでしょ?」

 

「設計図にはすべての部位に"寸法"が入ってない!施工図で全ての部位に対して"寸法"が入るんだ」

 

「ヒェー!"寸法"なしで、見積もるのですか?」

 

「設計図は、設計者がお客様のニーズに合わせる基本計画に基づいて、法令を順守しつつ確認申請を受け、デザインや仕様を決めるための図面なんだ。で、施工図は実際に設計図では描ききれない内容を、工事をする人が理解できるように作成される図面の事をいうんだ」

 

「じゃあ、施工図も見て見積もればいいんですね!」

 

「うん。ただね、工種によっても違って、 建築工事では設計段階で細部まで詳細な図面を作図しておらず、施工段階で施工図を作図するんだ。で、設備工事では、設計図を元に作られた設計図書(実施設計図(意匠に関する情報)、構造図(構造計算の情報)、設備図(電気設備、空調設備、衛生設備の情報)を 見て、見積書を作成するんだ」

 

「もう訳がわかりませ~ん」

 

「さらに、もう一つ問題が出てくる。実は、最初に見積もった金額と完成した建物にかかった金額が必ずしも一致しないんだ」

 

「???ちょっと何言っているかわかんないッス」

 

「コラッ!ボケなくてもいい!」

 

(ショボーン)

 

「建物を建てるのは年単位の仕事なんだ。その間に資材が高騰したり、設計図の不備で、余計な工事が発生したりと、想定しえない事象で工事金額が膨らんだりするんだ。仮にS君が車を購入して、納車されるまでに当初決定した購入金額が上がったらどうだろう?」

 

「そんなの嫌ですよ」

 

「そうだろう。建物が完成してみたら金額が増えましたと言ったところで、おいそれと依頼主が払ってくれるわけではない。だから、いろんなことを想定しつつ、いかに正確で赤字とならない見積金額を算出するかが見積業務に携わる人々にとっての至上命題なんだ」

 

「大変そう~」

 

「我々はそのお手伝いをするソフトウェア作っているんだよ」

 

 

今回のまとめ

1.見積の目的 

(1)見積りとは(何の為に見積るのか?)

  • 金額・量・期間・行動を前もって概算して、それらを書面にしたものを見積書と呼ぶ。
  • 建設業においての見積書は、「設計図(仕様書)に記された建物や設備の工事を正しく行うための価格を算出する」ことをいう。

(2)見積書の意味合い!

  • 契約において、その工事をするためにどれくらいの価格、期間になるかを計上して、依頼主に提出。
  • 依頼する側は「見積を取る」、依頼される側は「見積を出す」と表現。発注する側は予算を準備する必要があり、適正な相場で購入する為には市場価格の指針も必要。
  • その為、契約の前に工事業者へ価格を算出させ、検討の資料としたり、発注の判断を下すために必要なものが見積書である。

(3)建設業における見積業務!

  • 仕入値に利益を上乗せするだけの見積もあるが、建設業においては見積作成に膨大な労力を伴う。
  • 見積作成業務そのものの対価(中規模の案件でも数百万掛かる)は、依頼者に請求できない場合が多い。
  • 見積書はあくまでも実際に仕事を請ける前の段階での価格であるため、仕事を遂行する上で価格が変動することもありうるため、請求書の金額は必ずしも一 致しない。

合成品の階層構造について

みなさん、こんにちは。Dr.テトランです。

前回の「簡易複合単価機能」は、如何でしたでしょうか。

この間、インサイド・オブ・テトラの追加記事を、微力ながら書き続けてはいるのですが、なかなかリリースには程遠い状態です。

そこで、その中の一つである「合成品の階層構造について」を、リークしたいと思います。

≪ はじめに ≫
当初、合成品は「9階層目の工事フォルダ」として導入されました。
但し、工事フォルダと異なって、内訳明細行と混在可能なように、終端行を持ちます。
つまり、工事フォルダから見ると、閉じた合成品フォルダは、明細行と同じです。
しかしながら、違いもあります。
一行の明細行には、各種分類値が一つづつですが、合成品では違います。
この違いは、計算式中の、分類に依存する値に、複雑な影響を及ぼします。
最新のTetra21システムでは、この合成品に階層構造を持ち込み、更に複雑化を増しています。
(階層とは、合成品内訳の要素として、別の合成品を許すことです。)
こうして生成された階層化合成品を、どの様に扱っているか、見てみましょう。

この序文以下、三つの章から成ります。

1.工事フォルダと合成品フォルダの違い

2.合成品の表示法

3.旧バージョンとの互換性

 

興味の有る方は、ここをクリックしてください。

【続】簡易複合単価による見積書の作成について

みなさん、こんにちは。Dr.テトランです。

前回の投稿から、一年余りが過ぎてしまいました。前回の「複合単価を作成する」コマンドの一般化も進み、資料もほぼ完成したので、改めてリリースしたいと思います。基本的には、事後に行う按分処理の章を加えただけですが、齟齬があるといけないので、更新ではなく改めて発表します。

前回と同様に、この資料(PDF)は、Tetra21にある「複合単価を作成する」コマンドを内側から明かすことで、Tetra21をお使いの皆様(ユーザー)に正しい使い方を促す為のものです。また、これから、「Tetra21の簡易複合単価機能を使ってみようか?」と検討されているお客様においても、本コマンドを利用する価値があるか否かの判断にご活用ください。 なお、ドキュメントは、つぎの6つの項に分けて記載してあります。 (1と2は前回のまま、3は若干添削、4以降は追加した章です。)

1.理論的根拠
2.Tetra21での旧来の取り組み(モード0~3)
3.Tetra21での新しい取り組み(モード8~15)
4.手動による按分指示(モード8・9)
5.各行の按分指示による(モード10~15)
6.今後の課題

興味の有る方は、ここをクリックしてください。

簡易複合単価による見積書の作成について

みなさん、こんにちは。Dr.テトランです。

この資料(PDF)は、Tetra21にある「複合単価を作成する」コマンドを内側から明かすことで、Tetra21をお使いの皆様(ユーザー)に正しい使い方を促す為のものです。

また、これから、「Tetra21の簡易複合単価機能を使ってみようか?」と検討されているお客様においても、本コマンドを利用する価値があるか否かの判断にご活用ください。

なお、ドキュメントは、つぎの4つの項に分けて記載してあります。

 

1.理論的根拠

2.Tetra21での旧来の取り組み

3.Tetra21での新しい取り組み

4.今後の課題

 

興味の有る方は、ここをクリックしてください。

SDIについて

皆さん、こんにちは。Dr.テトランです。
前回のエントリからすっかり間が空いてしまいましたが、暑さも和らいだことですし、また、Tetra21について述べてみたいと思います。

 

前々回のエントリ(MDIについて)で、Tetra21はMDIアプリケーションであると述べましたが、Single Document Interfaceも備えています。但し、Windowsでは、メインフレームウィンドウは一つという協約(守っていないアプリも時々見受けます)がありますので、SDIフレームウィンドウは先のメインフレームウィンドウをオーナーにしています(注意:子ウィンドウではありません)。こうすることで、前回のエントリ(帳票MDIのしくみ)の「フレームウィンドウ一つで全体を云々」が覆ることはありません。

このSDIフレームは「表一括編集」を受け持っています。クラス構成は三階層4クラスになっています。基本クラスから掛率拡張クラスを派生し、それから仮想合計付クラスと複数行編集クラスを派生しています。(次回エントリ予定の「ドック&ビューアーキテクチャ」も参照してください)

では、何故MDIにしなかったのでしょうか?
一番の理由は、「行プロパティシート」に対して、前作のDACE-Ⅲの様な全体編集のUIを持ち込みたかったからです。当初はモーダルにする予定でしたが、行数が多いことからモードレスの方が有用であると判断し、唯一のフレームに制限しつつそのように実装しました。また、MDI同士は対等のイメージが有りますが、「表一括編集」はあくまでも一時的な編集のためのUIと言うイメージです。実は、前節の帳票ウィンドウも同じような立場にあったのですが、複数の帳票を平行して扱う必要性からMDI子ウィンドウにしておきました。(仕組みは違うが、表一括編集SDIは主目的が編集、帳票MDIは表示が主目的と言える)「表一括編集」SDIクラスは、種々のデータを統一したUIで操作する目的で導入しました。

現時点では、基礎データの「表一括編集」を基底クラスに、見積書用の「表一括編集」クラスを派生し、更に金額検討表用の「表一括編集」クラスと「見積書二行編集」クラスを派生しています。将来の方向としては、接続するドキュメントに合わせた派生クラスを利用することで、編集機能をよりマッチしたものに向上させるよう、計画しています。

 

帳票MDIのしくみ

皆さん、こんにちは。Dr.テトランです。

前回の「MDIについて」において、帳票ウィンドウは別扱いのような記述をしましたが、今回帳票ウィンドウについて少し詳しく述べてみたいと思います。

一般の表ブラウザウィンドウと同様に、帳票ウィンドウもTDBをブラウズ(&修正)するためのUIですが、大きく異なる点があります。このMDIが最終資料を提示する目的で作られているためです。

 

■表示様式(書式)をユーザが指定できます
表ブラウザでは、表示項目の選択とその配置、レコードの選別とソーティングぐらいですが、帳票ウィンドウでは、予め導入されたオブジェクト(ページ、矩形、表)に限定されはしますが、 TDB上のデータを任意に関連付けることが可能です。(但し表は一種類のみ)とは言っても、目的の表を設計することは至難の業になりますので、Tetra21ではドキュメントの種類に応じて、 幾つかの表(ID)を予め用意し、ユーザはそれをカスタマイズすることになります。

例えば、ドキュメントが見積書シートならば、「工事総括表」や「見積明細書」「工事原価台帳」等々です。 後は、表示したい列項目をそのプロパティと共に定義し、必要に応じて矩形項目を配置すれば、概ね目標だった帳票が形式的にできると思います。 プロパティの中には、ページに依存するものや特殊な指示を書き込むための矩形もありますが、基本的にはページには依存せず、全頁同じことを繰り返します。但し、このことや表が一種類のみという制限が、特殊な帳票への対応を難しくしているのも事実です。

■加工して表示できます
表ブラウザが、TDBの指定した部分を、ほぼそのまま表示しているのに対して、帳票ウィンドウでは目的に応じた補正を施すことができます。 これは、行方向に顕著で、同じ種類のレコードを合計して纏めたり、不要なレコードを排除したり、逆にレコードを付け足したりします。 この加減を設定するのがスタイルシートです。

 

では、いよいよ「しくみ」について述べたいと思います。既に述べたことですが、表ブラウザの場合は、UI等を司る基底クラスからそれぞれのドキュメント固有の特性に対応するための派生クラスを作っています。 つまり、ドキュメントの種類だけクラスがあります。しかし、帳票ウィンドウでは一種類だけです。帳票ウィンドウクラスは、帳票(ビュー)の書式(パラメータ)とそれを設計するUIだけを持っています。 つまり表示するべき中身の性質には一切触れません。そういった意味では、表ブラウザの基底クラスと同様です。しかし、表ID毎に派生クラスを作るのではなく、データソースとなる表ブラウザとリンクして、その任に当らせます。

一番の理由は、単純に派生させようとすれば、追加するメソッドが膨大になってしまったためです。 多重継承と言う手もありますが、MFCがそのように仕組まれていないのと、動作時の仕組みとの整合性から、リンクしてそのドキュメントクラスから、描画時のセルデータを逐一もらうことにしました。

そのデータを準備させるために、帳票ウィンドウクラスはリンク確定(ソースドキュメントからの起動も含む)時と、「最新情報に更新」、「スタイルの変更」両コマンドを受けた時点で、表IDや必要パラメータを伴って、ソースドキュメントの専用初期化メソッドを呼び出しています。 つまり、「スタイルの変更」は帳票ウィンドウのコマンドですが、UIを提供してそのスタイルのデータを準備しているのは、データソースとなる表ブラウザ側なのです。その結果、帳票ウィンドウ接続中にデータを修正しても、リアルタイムで帳票側が変わる場合とそうでない場合が起きます。それは、この初期化によって作られたデータか否(こちらがリアルタイム)かによります。

 

MDIについて

皆さん、こんにちは。Dr.テトランです。2013年が新たに始まり、すでに一か月が経過していますが、本年もよろしくお願いいたします。

さて、暫くサーバとサブシステムの話が続きましたが、ここいらでクライアントプログラムに移ります。 最近、新たにリリースされたプログラムでMDIを採用するものが少なくなったように思われますが、WordやExcelは相変わらずMDIを採用しています。(尤も、最近のものはかなり異なったビュースタイルになっているので、下記の文はTetra21のイメージです)Tetra21クライアントも採用している、このMDIについて少し述べてみたいと思います。此処からは、暫くTetra21デザインに直接かかわるような内容は余りでてきませんが、システムを理解する上で重要ですので是非読んでください。

 

正式にはMultiple Document Interfaceとして、Windows 3.0でAPIサポートするようになったUIで、見かけ上はメインのフレームウィンドウ内に複数のMDI子ウィンドウを設け、個々のドキュメントを結びつけることで、1プロセス内で複数のドキュメントを同時に操作できるUIです。フレームウィンドウを最大化してデスクトップに見立てると、複数のウィンドウズプロセスがあるように見えますが、その名が示す通り子ウィンドウなのでメニューバーはフレーム側についています。そして、子ウィンドウのアクティビティが変わるに連れてそのメニューバーも変わります。ちょっと昔のMAC風です。見かけ上は複数のプロセスでも、実際はシングルプロセスなのでMDI子ウィンドウ間でのデータ交換はストレス無く行えます。Tetra21クライアントがデータ交換やリンクの設定にD&Dを利用している背景にはこのような事情があるわけです。因みに、別プロセスのTetra21クライアント間では、D&Dは不可能です。従って編集目的ならば同じプロセス内で行うと便利です。この外にも、フレームウィンドウ一つで全体を一括して扱える利点が有ります。例えば、タスクチェンジや終了等、個々に行う必要は有りません。何故利用するアプリケーションが減りつつあるのか不思議です。

 

助言:データからTetra21クライアントを開く場合、同じプロセスで行うには、関連付けUIでDDEメッセージを [open("%1")] に設定してください。(私は、dc4とtpfをそうしています)

 

Tetra21クライアントでは、帳票ウィンドウを除いてMDI子ウィンドウでの操作性を統一するために、UIを含め基本的な機能を持つ基底クラスを作成し、各々のドキュメントはその派生クラスでまかなっています。 基本クラスには、左ペーンにツリービューを持つものとそうでないものが有ります。右側はリストビューに似た純正のビューがあり、こちらはダイナミックスプリッタ付で、全ての基本UIを提供しています。派生クラスでは、そのドキュメントに相応しい処理を追加及びオーバーライドしています。 こうすることでプログラムをコンパクトにすると共に、共通の操作性を提供しています。帳票ウィンドウも基底クラスと二つの派生クラスでできています。見積書表紙とそれ以外の一般帳票がそれです。但し、パラメータをより一般化することで、差異がなくなってしまったので、表紙クラスは、過去の帳票ファイル(*.hys)のためだけに残されています。この単一の帳票クラスで多様な帳票をまかなう仕組みのヒントは、2節「リソース消費量を決めるパラメータとパフォーマンス」の「⑥帳票パラメータについて」に有りますが、節を改めて解説します。

 

注釈:「見かけ上は云々」とあるのは、実際のウィンドウ構成とその連携はもっと複雑だからです。興味のある人は、先ずSDKを参照してください。

 

ドキュメント/ビュー アーキテクチャ

皆さん、こんにちは。Dr.テトランです。

さて、ここらでTetra21クライアントの根幹を成すDocument/View Architecture(ドキュメント/ビュー アーキテクチャ)について簡単に説明します。

 

ウィンドウズプログラムは、表示したいデータをスクリーンに書き込めば良いコンソールプログラムと違い、システムの要求に答えていつでもすばやくビューを再描画する必要が有ります。

そこで、ウィンドウオブジェクトを構成するのに、データを保持し必要な処理を施すドキュメントクラスとそれを表示するためのビュークラスに分けたものが、ドック&ビューアーキテクチャです。

実は、ウィンドウズと複数形の表現で解るようにビューは複数ありえるわけですから、それを入れる(親になる)フレームウィンドウクラス(複数可)も必要です。

更に、MDIの場合はこのMDIフレームが複数になるのが普通です。

前節まで、表ブラウザ基底クラスだの見積書クラスだの帳票クラスだのと簡略して言ってきましたが、正確にはそれぞれがドキュメント・ビュー・フレームの各クラス群で構成されています。

 

Tetra21クライアントのクラス継承図を付録として添付してありますので参考にしてください。

勿論、圧倒的多数を占めるそれ以外のクラス(その殆どがダイアログUI)は除いています。

 

普通のアプリケーションでは、個々のドキュメントインスタンスは独立していますが、Tetra21ではサーバを通して間接的に、あるいは先の帳票ドキュメントの様に直接関与(リンク)しています。

直接関与しているものには、他に見積書と検討表、工種組換シートがあります。

こうした関連性から、Tetra21クライアントのMDIは相互作用を前提にした動作になっています。

先ほど「表示するためのビュークラス」と簡単に述べましたが、このビュークラスのコーディング1つでプログラムの応答性能(機能ではありません)が決まってしまいます。

別に、マウスやキーボードインターフェースが必要であること(こちらも大事な実装ですが)を指している訳ではありません。

実はウィンドウズシステムは、再描画が必要なウィンドウに対しては、描画域に合わせた描画マスクを用意した上で、外郭の矩形情報を伴って描画メッセージを送ります。

受け取ったビューは、描画に関与するドキュメントだけを処理対象として、マスク内で背景とデータの描画を行うようにします。

 

また、自身が再描画要因を作る場合もあります。

 

例えばサイズの変更や、データ変更をビューに反映させる時がそうです。

この場合、再描画領域が最小になる工夫と、「ちらつき」を防ぐために、背景を温存させるような配慮が大切です。(何れも関連メソッドのオーバーライドが必要)

 

Tetra21クライアントでは、場合によってはイレースバックグラウンドメッセージを無視して背景を書かずに、データと同時に書くことで、文字の「ちらつき」にも配慮しています。

 

 

このために、ディスプレイコンテキスト(画面)に直接書かずに、その部分と等価なメモリコンテキスト(メモリ)を作成し、そこに完全な描画を行った後に、一気にディスプレイコンテキスト(画面)にビットブリット(コピー)することもあります。

しかしながら、メニューバーやキャプション、MFCオブジェクトがそうなっていない(相変わらずイレースしてから書き込んでいる)のは残念です。

そう言う訳で、Tetra21ではビューやフレームウィンドウにMFCが用意した登録済みクラスは使っておりません。

(MFCフレームワークは、はっきり言って初心者向けです)

4GB限界とサーバプログラムの対応

皆さん、こんにちは。Dr.テトランです。今年もあとわずかですね。少し間が空いてしまいましたが、今回は4GB限界とサーバプログラムと題して述べてみたいと思います。

セグメントを固定したi386が提供できるアドレス空間は、32ビットオフセットだけなので、4GBが限度です。これを先に述べたようにOSと分け合うので、実際にアプリケーションが使用するのは2GB迄です。(3GB迄拡張できるツールもある) 一般のアプリケーションならばこれで十分な広さでしょうが、メモリーマップドファイルを使うDBMSにとっては、問題になってくる場合があります。Tetra21サーバでも、レコードパラメータに制約が出てきます。(これは、管理しているデータ全体のことではありません。全体の制限はメディアサイズやPCの能力で決まります。)

勿論、仮想メモリへのマップはスレッド共通で、しかも動的に行っており、仮想とはいえ無駄にメモリ空間を占拠しないような構成になっています。(通常は、スレッド単位に仮想アドレスを取得するので、益々2GB限界に当たり易い)しかし、それでもインデックスサイズの増大と共に32ビット限界が見えつつあります。この問題をプログラムで解決する方法は二つ考えられます。
 

一つは、インデックスを項目別に分けてレコード長を短くするか、インデックス全体をビューにマップせずに、特定のサイズに分けてマップしながら使う方法です

全て既知の方法で対処可能ですが、実空間の拡張が望めないので、パフォーマンスが犠牲になります。特に、「一部をビューにマップする」場合は、本来のマップオフセット(64ビット)を、i386のセグメントアーキテクチャのようにして、小分けして32ビットオフセットで操作することになり、管理が複雑になってしまいます。
Tetra21サーバの場合、レコード数が大きくレコード長も長くなりそうなテーブルに、「物件概要」があります。リビジョン77以降のサーバであれば、現在の最大レコード長を知らせる能力(DB情報UIを参照)があるので、その値を基に再構成すると良いでしょう。

 

もう一つは、DBMSの64ビット化です

既に2GB以上の実メモリが当たり前になった現状では、こちらの方が高いパフォーマンスを実現できます。但し、64ビットの開発環境とソースプログラムの手直し(RPCIF部及びデータ構造を32ビット型で残しつつ、スタブや内部ポインタ関連の64ビット化)を行う必要があり、かなりの工数が見込まれます。勿論複数のプロジェクトにするつもりは無いので、32ビット環境でビルトする場合はこれまでと同じ実行コードが得られなければなりません。(当分32ビット版も必要)

(このモデルケースとして、弊社で無償提供しているプレイヤーアプリ(WFP4Exp.exe)を、上記の基準を満足するように64ビット化してみました。結果的には、想定以上の工数と困難さが伴いそうです。)

また、動作環境もそれに見合ったものが必要です。(CPU処理速度&物理メモリサイズ)残念ながら、どちらも現在のところ開発計画には至っていないので、DBパラメータの設定で問題を回避してください。実メモリが2GBあるとして、マスタファイルの4つのTDB合計サイズが1GB程度なら、実用的なパフォーマンスを持てると思います。(レコード長の無駄を切り詰めることが重要です)

プロセスとスレッド~後編

皆さん、こんにちは。Dr.テトランです。

前回のプロセスとスレッド~前編を踏まえた上で、そろそろ現実のOSの話を始めたいと思います。

Version3.1xまでの古いWindowsと異なって、それ以降のOSは各実行モジュール単位に独立したプロセスを割り当てています。具体的なCPUを想定する必要がありますので、以降はインテルのi386以降とします。i386はセグメントアーキテクチャを駆使することで64TBの仮想空間を扱えますが、MSでは(1セグメントに固定の)フラットメモリモデルにして、4GBの仮想メモリをプロセスに割り付けます。

これは、OSをインテルアーキテクチャに特化することなく、他のCPUも考えた結果でもありますが、この4GBの制限はそろそろ問題になりつつあります。アプリケーション実行に割り付けれられた4GBの仮想空間は、OSとアプリケーションで二分して、使います。このときNT系と9x系ではOS側の使い方に決定的な違いがあります。NT系では、その部分にはWin32Subsystemが載るだけで、肝心のOS本体は保護された別プロセスで動作しています。そして、Win32サブシステムはLPCを使ってWindows NT Executiveを呼び出しています。

今、あるファイルを複数のプロセスで共有することを考えます。別の節でも述べたようにファイルにアクセスするには多くのニーモニックを使いますので、その間他のプロセスからのアクセスを全てカットしておく必要があります。

例えば、アクセスする度に、排他オープン/クローズを繰り返します。しかし、ファイルを変更する場合は、先ず読み取っておいてから、処理した結果を書き込むのが普通ですから、その間排他オープンされたままですので、無関係なレコードへのアクセスもブロックされてしまいます。また、関連するファイルが複数の場合はさらに面倒を引き起こしてしまいます。そうでなくても、排他オープンしたプロセスがトラブったり、ネットワークに問題が生じた場合に他のプロセスが影響を受けてしまい、データの安全性も危うくなってしまいます。

これが、1台のコンピュータで複数のプロセスであれば、ミューテックスのようなプロセス間同期オブジェクトを利用することで、もっとスマートな解決法がありますが、そもそも異なるコンピュ-タの場合は、そのような訳にはいきません。一番の解決策は、各々のプロセスを二つに分けて、ファイルを操作する部分を、そのファイルが在るコンピュータに持ってくることです。更に、それらのプロセスを一つのプロセスにまとめてDBMSにしてしまえば、プロセス間の同期も必要ありません。但し、元々別のプロセスであったものは、それぞれの片割れと通信する必要があるわけですから、個々に仮想CPUを割り振る必要があります。

それがスレッドです。部分プログラムの実行単位と思ってください(実はその下にファイバーがあります)。このようにすれば、同期オブジェクトもプロセス内であるため、オーバーヘッドを小さくすることができます。手荷物の授受も簡単です。勿論、二分したプロセス間の通信機能が必要で、Tetra21ではRPCを使っています。こちらの実現法は既に述べたとおりです。