22年前からbcc55、2年前からbcc102を使っており、自作ツールと共に素人プログラマーが学習や趣味でプログラミングをするには十分な能力と実用性があると思いますが、一つ愚痴を言わせていただければデバッグ環境は余り大したことが無い、ということです。
１．素人プログラマーに好ましい、優しいデバッグ環境
これは基本的にソースコードレベルで、エラーや不具合の現象のみならず原因を（WYSWYGというか視覚的に直観できるよう）指摘してくれるデバッガーでしょう。例えば昔MicrosoftのVisual Basicを使ったことがありますが、あれがまさにそれですね。例えば0で割ったり（以下↓例参照）、誤って保護領域をコールしてしまい、例外状況になった場合、問題となるソースの行を赤反転させて実行を停止してくれます。
例： C = A / B Error: Division by zero
デバッギングの玄人さんであれば、ブレークポイント迄とかステップ毎とかで実行させ、都度レジスター内容や変数（スタック）の内容を確認してトレースできるのでしょうが、それも関数アドレスや変数などのシンボルが無いと可也り「バイナリー側の人間(注）」でないと無理です。
注：8 bitのZ80でコンピュータープログラミングを始めた頃はアッセンブラーもなく、巷の好き者はZ80のニーモニック（LD、ADD、SUBとかJPとかの 機械語）はおろか、直接バイナリーコード（例：JP 5000H→C3 00 50：アドレス16進法の5000Hにジャンプせよ、の意味でアドレスがひっくり返っているのはリトルエンディアンだから。）でプログラムを組める「人間アッセンブラー」もいましたね。
２．Turbo Debugger
2000年からフリーで公開されたbcc55セットは、更におまけでTorbo Debuggerが付いてきましたが、基本的にTurbo DebuggerはMS-DOSのコンソールベースのアプリであり、且つウィンドウズのようなイベント割り込み処理ベースのシステムではソースを示すことができない為、結局はソースベースにではデバッギングできませんでした。
１例として先般紹介したBCC2ECCをTurboDebuggerにかけたイメージを紹介しますが、短いBCC2ECC.cppだけ逐次実行を表す「〇」付の行を示すだけで他のソースは表示しません。
３．Visual StudioのWinDbg
一方ご本家はVisual Studioではもちろん、またWindows SDK Kitsをダウンロードすれば利用できるウィンドウベースのデバッガーを提供しています。（OSが不正終了した場合に解析情報をMicrosoftへ送る使い魔でもあるようです。）以下に同じくBCC2ECCのソースとexeファイルを読み込ませた状態のイメージを示しますが、やはり20年の時間の差を感じさせるモダンでスマートなものです。
しかし、矢張り残念なことにbccで開発したソフトは（コンパイルの際に-vスイッチを付けてシンボルを追加できるようですが、勿論互換性はなく）バイナリーデータ以外は情報が無いためにソースベースでのディバッギングは不可能です。Microsoftはデバッグ用にpdb（program database）ファイルというものをコンパイラーに排出させ、これを読んだWinDbgが多様なシンボルを使ってソースレベルでバッギングができるようです。まぁ、残念ですがBCCSkeltonやECCSkeltonの開発ではこのような環境は使えませんね。
４．結語
先般の不具合騒動の際に、何か利用できるデバッガーはないか、提供元のEmbarcaderoは勿論、色々と探した挙句矢張りソースレベルではプログラムの中に「罠」を仕掛けてデバッグするしかない（注）、ことを思い知らされました。まぁ、そういう環境でプログラミングをすることにより、幅広い雑知識をため込んで鋭敏なアンテナを張り巡らし、洞察力を養うトレーニングになるのですが．．．
注：実行時に不法なメモリーの浸蝕をするような不具合（Aの場所で犯したコードエラーがBの場所で不具合を発生させるようなエラー）には役に立たないことが分かりましたが．．．
まぁ、それで飯を食っているわけでもなく、単に趣味（というかボケ防止）の為の暇プロには、（ストレスは大きいですが）デバッギングすらも楽しみとしなければならないのですが。