web6047 - 2025年 7月

特別な記事へのリンク

ゲームコーナー　

その他 単発のアプリ

2025年7月10日

最近の…

…買い物

Amazon で、「はじめの一歩」の第 1 話 ~ 第 38 話までを収録した DVD-BOX（中古）と、Mr.Children のアルバム（新品）を購入しました。

『はじめの一歩』は、

• いじめられっ子の幕の内一歩が、ボクシング新人王の鷹村と出会い、「強いってどんな気持ちですか？」、「僕もプロボクサーになりたい！」という想いを胸に、時には相手の強さを恐れリング上で逃げ出したい気持ちに襲われたり、打ちのめされてダウンして「まだだ！まだすべてを出し切っていない！」と言って立ち上がる様子、そういう強さへの挑戦みたいなところに引き付けられました。
• 闘いの中での駆け引きが RPG 開発の戦闘画面の参考になると思いました。

そんな理由で購入。

『Mr.Children』は、私が 15 才の頃だったかな。兄から「お前はミスチル聴いたほうが良い」と勧められたのに、180 度異なる中島みゆきを聴き始めた思い出があり、今思えば兄の言うことを聞いてミスチルでも良かったんじゃないか、、とちょっと思ったので買ってみました。

ヤフオクで、「Borland Turbo C++ 4.0J for DOS （PC-9801 & DOS/V用）」を落札しました。

「アップグレード」となっていますが、私はすでに「Borland Turbo C++ 1.01」を持っているので、そこからアップグレードできるでしょう。

でも当時は「アップグレード」と書いてあっても、旧バージョンが無くてもインストールできる場合が多かったのでその辺は心配ないかもしれません。

1.01 は Intel 8086 CPU と Intel 286 CPU 向けのコンパイルしかできませんが、 4.0 は Intel 386 CPU 向けのコンパイルが出来ます。

▼Borland Turbo C++ 1.01

▼1.01 は Intel 8086 CPU と Intel 286 CPU

また、1.01 は「Turbo Debugger」がありませんが、4.0 には付属しています。そこが主な目的です。

Turbo C++ は当時、海外でも販売されていましたが、海外では 3.0 までで、4.0 を発売したのは日本だけです。

しかし、4.0 には深刻なバグがあるという話をちょっと聞きました。

https://oshiete.goo.ne.jp/qa/455191.html（2025年9月17日(水)以降リンク切れする予定）

それでもヤフオクで選んだのは、

• 書かれている通り64キロバイトを超えるときはバグ回避すれば良い。
• 同梱されている「Turbo Debugger」は良いソフトウェアだと評価されている。
  https://en-m-wikipedia-org.translate.goog/wiki/Borland_Turbo_Debugger（Google Web翻訳）
  

  BYTE誌は1989年1月、Turbo DebuggerをBYTE Awardsの「Distinction」受賞製品の一つとして選出しました。

  同誌は、その使いやすさとTurbo PascalおよびTurbo Cとの統合性を高く評価し、「プログラマーの万能ツール」と評しました。 [ 5 ]

  また、1989年2月号のCコンパイラ最適化に関する概説記事では、「最高のソースデバッガ」と評しました。 [ 6 ]

…私の身体

先月 6/1 に「そけい部ヘルニア（脱腸）」で1 週間入院しましたが、今は直っていつも通りの生活に戻っています。

でもときどき痛むので「何かあるな」と思っています。

それとは別件で、視力がこの1カ月、2カ月でグッと落ちました。

おなかの調子も正露丸を年に2～3ビンくらい「空ける」みたいな。

もともとの性格で、そういう調子が悪いところはどうとも思っていなくて、悲観の文字が無いかも。

…私の仕事

今やっているクォータニオンのプログラムは、事業の一環としてやっています。

（下図は画像です）

画像の右上にはファイル名が表示されていて「web6047document-22.html」となっています。

前にも説明しましたが、「人体 3DCG モデル」のプログラムのために、もう 22 回目の作り直しをやっているという意味になっています。

作り直しを決めるたびに心が一瞬折れそうになるんですが、そう簡単にはくじけません。

そろそろ完成が見えてきたところです。

「人体 3DCG モデル」のために事業として設定している他のいろいろな活動を「止めている」ので早く完成してほしいんだけど、今年の秋くらいまでかかるだろうな。

この状況、事業としてやっているって言ったって、はたから見れば、私の今までの「プログラミングに明け暮れた生活」とあまり違いが無いんだよな…

いっぽう、イラスト投稿サイトの「イラストAC」でのイラストの売れ行きは、

こんな感じ。2024年10月までは好調だったんですが、その月を境にパッタリ。

何が起こったのかというと、私の主力イラストの「ノートパソコン」に「マイクロソフトのウィンドウズマークが入っている」というのが問題になって、そのマークを訂正したんです。（自分でもちょっと気づかなかったですm(_ _)m）

訂正すると「投稿し直し」となってしまい、それが原因で、検索結果の上位だったものが下位に落ちてしまい、人々の目に入らなくなってしまった。。。ということかなと思っています。

残念と言えば残念だけど、まいっかと思っています。

事業としてやっているので、１つの商品についていちいち一喜一憂するという感覚はありません。

もともと性格がクールなので、、というのもあるかな。

あと生成 AI による画像提供があるから、「イラストAC」ってこの先もやっていけるのかなとちょっと疑問です。

でも生成 AI のイラストって、どこか血が通っていない感じがするというか、安っぽいというか、人の心に届かないというか…、あまり良い絵ではありませんよね。

だから大丈夫、、、大丈夫か大丈夫でないか、難しいところかな。

…作曲

この前、作曲を始めてましたけど、今は止まっています。

買ったキーボード（鍵盤）全然触ってない。

クォータニオン（人体 3DCG モデル）に付きっ切りって感じです。

キーボードに触るとプログラミングのスピードが落ちると思って。

あと、作業（毎日15分でも鍵盤の練習をすれば上達する）ということで鍵盤に触るのはつまらないと思って。

落ち着いてから普通に触りたいです。

2025年7月12日

プログラミング　TC4.0J のバグは本当？

1. Turbo C++ 4.0J を購入した。
2. しかし、大きなバグのウワサ話を聞いた。
3. そのバグの真相を探る。
4. その結果。

1. Turbo C++ 4.0J を購入した。

もともと Turbo C++ 1.01 を持っていましたが、将来使うだろうと考えて Turbo C++ 4.0J をヤフオクで購入しました。

３０年以上も前の品物なのに「未使用新品」で、落札価格は 15,000円。

届いてみると、フロッピーディスクはラッピングされたまま封を切っていない状態でした。

▼USB FDD ドライブで Win 11 に取り込み、エミュ上でインスト＆起動。

2. しかし、大きなバグのウワサ話を聞いた。

https://oshiete.goo.ne.jp/qa/455191.html（2025年9月17日(水)以降リンク切れする予定）

今だったら、速攻でアップデートが配信されるだけのことですが、当時はお店でディスクを買ってネット無しでインストールして…だったのでこういうバグはそう簡単には修正されません。

それでも「パッチ」（修正ソフトウェア）がパソコン通信や郵便で提供されることはありました。

だからインターネットでそういうパッチがどこかに無いかと探しましたが見つけられませんでした。

3. そのバグの真相を探る。

「強烈なバグ」と言うほどなので、どんなもんかと思って再現させてみることにしました。

…で、いろいろやってみたんですが、当時の開発環境というのは「メモリモデル」を６個の中から選択するもので、その挙動がいろいろなので調べていて収拾がつかなくなり、何がバグで何が正当な仕様なのか分からなくなりました。

▼ヘルプにメモリモデルについての説明があります。

▼Oｵﾌﾟｼｮﾝ>C:コンパイラ＞C:コード生成　で…

▼画面左上にメモリモデルの選択があります。

そこで、とりあえず自分で調査用のプログラムを組んで、「事実」を並べてみることにしました。

ヘルプを読んでもその内容が間違っている場合があるし、読んでる私が誤解して読む場合もあり得ます。

それなら、目の前で起こっている「事実」を並べたほうが確かな情報であり、問題を浮き彫りにするのに役立つと思います。

まず前提として、

当時のメモリのしくみは、諸般の事情により、「セグメント：オフセット」という方式が採用されていた。

１つのセグメントは 64KB の容量を持ち、その 64KB 内のアドレスは：の右側の「オフセット」部分で表される。

オフセットは 0000 ～ FFFF で表され、これは 256 x 256 = 65,536、つまり容量 64KB を意味する。

そして調査した結果（事実）として（６点）、

事実1. いずれのメモリモデルでも、配列の「要素数」の上限は 65,535 個までだった。

たとえば、

char a[ 65535 ];

これが上限です。

65536 とか指定して、これを超えると、

Array size too large in function main.

というエラーが出ます。

事実2. いずれのメモリモデルでも、配列の「容量」の上限は 64KB（65,536KB）だった。

たとえば、

char 配列（要素１つが 1 byte）なら「要素数」65,535個までで、「容量」64KB。

int 配列（要素１つが 2 byte）なら「要素数」32,767個までで、「容量」64KB。

どういう形にせよ、容量 64KB を超えないようになっています。

超えると、

Array size too large in function main.

というエラーが出ます。

つまり、事実1、事実2 により、Turbo C++ 4.0J では、配列は、

• 要素数 65535 個まで、
• 容量 64KB まで、

という仕様で固定のようです。

事実3. いずれのメモリモデルでも、malloc() で確保できる容量の上限は 64KB（65,536KB）だった。

たとえば、いずれのメモリモデルでも malloc() を使って 128KB を確保することはできませんでした。

事実4. 上位のメモリモデル Compact, Large, Huge では、malloc() で「容量」64KB を「複数」確保できた。

上位のメモリモデル Compact, Large, Huge では、malloc() で確保できる容量の上限は 64KB（65,536KB）であることには変わりがないが、malloc() で「容量」64KB を「複数」確保できました。

上位のメモリモデルは、データセグメントが 1MB なので、その容量を超えさえしなければ、複数確保可能ということらしいです。

※ コードセグメント（メモリ領域）にプログラムを置き、データセグメント（メモリ領域）に変数などのデータを置きます。これは現在の Windows でも同じ方式を取っています。

事実5. 上位のメモリモデル Compact, Large, Huge では、farmalloc() で64KB 以上の容量を確保できた。

malloc() では 64KB まででしたが、farmalloc() を使うと 128KB など自由な容量で確保できました。

事実6. 配列と、「malloc() で確保されたデータ領域」では、オフセットが上限を超えると「ラップアラウンド」した。

セグメントは固定で、オフセットは上限の FFFF を超えると、セグメントはそのままに、オフセットが 0000 に戻ってしまっていた。

そのとき、配列の先頭の要素と、後方の要素が同じアドレスを指していた。

これは「ラップアラウンド」と呼ばれる仕様？のようです。

その結果。

ウワサの「強烈なバグ」、

＞プログラムが64キロバイトを超える配列を使っている場合、64キロバイトの境界線を越える要素のアドレス計算が間違っている。

これは、「配列」と言っていて、「64KB」を問題にしており、「アドレス計算がおかしい」と言っています。

これはまさに、

”配列の要素のアドレスの「オフセット部分」が FFFF を超えると 0000 にもどってしまい、メモリ領域（セグメント）の先頭とメモリ割り当てがかぶってしまう”、

…「ラップアラウンド」のことを言っているように思えます。

しかし、「64キロバイトを超える配列」というのは例えば、

char a[ 65536 * 2 - 1 ]; // 128K

のような宣言だと思いますが、そもそもそういう 64K を超える宣言は事実2 のとおりエラーになるはずなんですよね。

だからこのウワサは配列のことではなく、事実5 の farmalloc() で確保したメモリのことを言っているのかなと思えます。

64KB 以上を確保できるのは、farmalloc() しかありませんからね。

そこで、「farmalloc() を使って 64KB 以上の領域を作成して、その領域をポインタを使って配列みたいにアクセスし、64KB の境界を超えたところでアドレス計算を間違えている」かどうか、試してみたところ…

▼64K の境界付近にカウンタ変数 i の値をそのまま置く。	▼i 番目にはちゃんと i の値が格納されているし、それを読めている。

うーん、まったく問題ないですねぇ。。

やはりウワサは間違いだったのかなぁ。

でも、もちろん私の調査は完ぺきではなくて、

• 調査はリアルモードだけで行っているが、プロテクトモード（現在の Windows のアプリはどれもプロテクトモード）ではどうなのか。プロテクトモードは基本的に広いメモリを扱える環境です。
• 調査は main() のローカル変数だけで行っているが、main() の外側のグローバル変数ではどうなのか。

…というところは今回調査していません。

でもまぁ、そこまで調べなくても、たぶん、ウワサは「ラップアラウンド」の動きを見てバグだと思い込んだ、と見ていいんじゃないか、という気がしています。

ということで、安心して Turbo C++ 4.0J を使える感じで、めでたしめでたし、ということです。

以上ですが、

その他、補足事項を書いておきます。

▼ヘルプの Huge についての説明

「静的データ」って何のことを言っているんだろう…。

「静的データ」の対義語は「動的データ」で、動的データとは malloc() で確保したメモリのことだと思います。

だから「静的データ」とは配列のことかなと思います。

＞静的データは 64K に限定されています

確かに配列は 64KB までの容量までしか使えませんでした。（事実2）

＞が、ヒュージメモリモデルではその制限がなくなり，64K バイトを超える静的データを使用することができます。

Huge モデルなら 64KB 以上の配列を使用できる？？

下図の通り、できなかったんだけど… orz

▼メモリモデルに Huge を選んで、	▼64K バイトを超える静的データを宣言して、エラー！

このヘルプのあいまいさ（または間違い？）が、強烈なバグのウワサの発端になったんじゃないか、、という気もします。