orange @[email protected]

既存のフレームワークを利用しないで書く太古の(？)GUIも(というか最低限のGUIフレームワーク自作みたいな感じの時も)、わりとそういう風に書くのが普通かも？＞＜(じゃないと操作不能になりやすいし＞＜)

なのでプロセス内でも、スレッドもだけど構造自体適切に分割してって・・・・＞＜；

場合にはよるけど、そうかも＞＜；

ダメもとでもリソース解放する処理を実行するか？とかの話をとりあえず横においておくと、
つまりGUIアプリとそれ以外のアプリ(？)では、よほどの事がない限り実行を続けなければならないとされる部分の内包度？が違うってことになるのかも？＞＜；

うん＞＜；
あと、そもそも少なくともWindowsの場合は実際の処理はよほど軽量で単純なもの以外はGUIスレッドで動かすのはお行儀悪いって事になってるし、(古典的な実装では)場合によっては処理するスレッド作り直しかも＞＜；

ファイル読み込んだら問題なく使えたって話も、ちゃんと内部で初期化するように作ってるので(というか一旦破棄して作り直すので)、再起動した時とほぼ変わらず動かせるって事かも＞＜

オレンジのアプリの書き方だとそれが内部で分割されてて、アプリ単位よりも部分ごとに止められるってだけかも＞＜
「その部分(/アプリ)はバグってるんだから実行しない方がいい」って意味なら、アプリ終了(またはクラッシュ)させたあともう一回実行するのも同じでしょ？＞＜

いや、無事だって主張してるんじゃなくアプリは終了せずに処理は中止して「ダメだった！＞＜」ってユーザーに伝えてるんだけど・・・＞＜

それはよくわからないけど、GUIを持つアプリはGUIが全く操作不能になることだけは絶対に避けなければならない(最悪でもいかなるときにも終了ボタンは機能しなければならない)って発想で作ってた＞＜(GUIアプリをCとかで書くのが辺り前だった頃の古い本ならわりと近いことが書いてあったかも＞＜)