Shade が9.1.0 にアップしたところで、1点不具合らしい点を1つ。
といっても、新しい不具合か前からの不具合かは不明です。
コールバック関数 plugin_interface::shapes_modified()
が、形状がポリゴンの時(他の形状は未確認)頂点を削除しても
呼ばれない。(頂点追加は呼ばれる。)
まさか、仕様ですってことはないですよね。でないと使い道がない。
　この関数は、以前は取り消しで形状が変わった場合は呼ばれないというばかばかしいものでしたが・・・

画像投稿機さんコメントへの意見と以降発見した Shade9 の不具合に付いて報告します。まず、不具合
１．window_interface プラグインを plugins フォルダの子フォルダに置くと、Shade が異常終了する。
(他のプラグイン(常駐型も含む)では、問題は起こりません。(これは、既に 9.0.1 で報告されていましたが、直ってないようです。)
２．形状が、line,surface_part,sphere 等でcreate_shape_saver_interface(); を呼び出すと
Shade が異常終了する。(今のところ、polygon_mesh のみは大丈夫のようです。)

引用：
主旨は、理解できます。し、しかし、コールバック関数の引数で、NULLポインタを渡さなくても・・・
まあ、出来る限りチェックをするようにソース修正に励んでます。
ところで、interface 型のデータは、非常駐型のプラグインの場合、継承型なので設計時にいい感じで使えるのですが、
常駐型の場合、いまいち美しく使えません。
もう、そろそろ shade_interface とscene_interface は、shade_class と scene_class を用意して欲しいです。
メモリ的にもあまり問題ないでしょうし、scene が複数になったのだから、shape_class と同様に使える
scene_class の方が、スマートのような・・・
get_number_of_scenes()
get_scenes( scene_class * )
みたいな感じですね。

コールバック関数の不具合の可能性もあるので調査が必要ですが、

Shadeのプラグインのコールバック関数の引数は、基本的に
値が存在しない可能性がある場合は、ポインタ型で、
値が存在することが保証されている場合は、参照型で渡されるようになっています。

引数にポインタ型で渡される場合は、NULLが渡される可能性があり、
多くの場合、NULLポイントのチェックを行う必要があります。
scene_interfaceの場合には、Shadeは起動しているがシーンを存在しない場合にNULLになります。

Shade 6以前のWindows版ではシングルドキュメントだったため、シーンを閉じるとShadeも終了されますが、
Shade 7以降ではMac版と同様に複数のシーンを同時に開くことができるようになり、
Win, Macどちらの環境においても、Shade起動後にシーンがない場合がありうるようになっています。

追加の情報をアップします。
私にとっての鬼門は、
コールバック関数、active_scene_changed()
ですが、それよりむしろ根本的には、scene_interface
そのもののようです。
これは、Shade9 の問題というより、Shade9.0.2の問題かな
と思います。（それまで、全然こんな現象ありませんでしたから）
それは、Shadeを閉じるときに、
最後に active_scene_changed が呼ばれるのですが、
何と 値がNULLで呼ばれるのです。
ですから、そのscene_interface で何か処理を行うと完璧な
例外発生します。
（これは、plugin がバグで途中で何らかの変な処理をした場合
だけに限るかもしれませんが。)
一応情報として。

私のプラグインがShade9 になって妙に異常終了が頻繁に起こるようになった点に付いて、果たしてこれが原因かどうかわかりませんが、一見解を。
というのは、怪しそうな部分には、try{} chatch(...){}
で囲っているのですが、その中で起こる例外が、うまくトラップされず、windowシステムに渡されてしまうことが結構あります。
今回Visual studio 5 に環境を変えたんですが、Shade9 もそうだと思います。気になったので、例外処理のドキュメントを一読した感じでは、セキュリティ強化の面でユーザ側で例外を全てトラップせずに、自分で判断できるものだけにするようにのコメントを見かけました。もしかしたら ５ で、try{} chatch(...) {} での例外トラップで提供される処理系が変更されて弱められているのではないのではないかと勘ぐってます。いかがでしょうか？

MASA_です。
回答ありがとうございます。
しかしながら、私の環境は SP1 があててありました。
不思議なことに、同じことをしているのに、あるプラグインの
場合はほぼ100%起こり、あるプラグインの場合は、全然起こらないといった感じです。
結局 .NET 2005 にアップグレードしてしまいました。
さらSDK9に移行することにしました。
一つ気になる点は、SDK8からSDK9になって create_stream_interface の
引数が uuid_class & 一つ分増えて５つになっているのに、その配置位置が同一な点です。ですから Shade9側で、4つ目の
uuid_class & を取得するとき sdk8製プラグインの void * aux をアクセスしているのではと、思ったのですが・・・
今は、ソースを全てSDK9化中ですので確認は暫く後になります。
そのため、逆に今は SDK9側の問題が幾つか出てますので、
そちらのスレッドを参照願います。

idle内でのcreate_stream_interfaceの問題ですが、
compointerテンプレートを使用した場合に
Visual C++ .NET 2003 と Visual C++ 2005で
互換性に問題がでているようです。

こちらで検証した限りでは Visual C++ .NET 2003 Service Pack 1 では、
エラーが発生しなくなったので、まだService Pack 1をあてていないようでしたら、
Visual C++ .NET 2003 Service Pack 1でお試しください。

Visual C++ .NET 2003 Service Pack 1は以下のサイトよりダウンロードできます。
Microsoft Visual Studio .NET 2003 Service Pack 1
http://www.microsoft.com/downloads/details.aspx?FamilyId=69D2219F-CE82-46A5-8AEC-072BD4BB955E&displaylang=ja

Visual C++ 2005 SP1でビルドした場合にはShade 8 SDK、Shade 9 SDKどちらにおいてもエラーは発生しませんでした。
Shade 9 SDKではフリー版のVisual C++ 2005 Express Editionもサポートしていますので、Shade 9ではVisual C++ 2005をおすすめしています。

コールバック関数に関しては次のアップデータで修正の予定となっております。
いろいろとお手数をおかけしましたが、よろしくお願いします。

MASA_です。 idle から行っている理由ですが、
Shade9になってから、自作プラグインが妙に不安定になり、
コールバック関数、active_scene_changed() や scene_opened()
や、active_shapes_changed や browser_updated() やshapes_being_deleted() 毎に
それに相当する処理を行うと、不必要に何度も同じ処理を繰り返したり、
シーンが開かれたときに、行う処理の前に active_scene_changed() が呼ばれてしまい
処理の前後が逆になってしまったり、active_scene_changed() 内でset_client_size()
を呼ぶと異常になったりするので、これらのエントリーでは、各種のフラグのみ立て、
idle でその処理を後追いするようにしたからです。
それにさらにカウンタを設定することで、不要なオーバーヘッドも減らすことができます。
以前は、そんなに気にしてなかったんですが、Shade9は妙に
コールバック関数内での処理が不安定になったので苦肉の策です。
なお、create_attribute_stream_with_uuid()はSDK9にすると
うまくいくかも知れない・・・と思われる点がありますので
.net 2005 にアップして確認して見るつもりです。

shape_class::get/create_attribute_stream_with_uuidで取得した
stream_interfaceに対するread/writeで不正な処理が発生することを確認しました。
現時点で回避方法はわかりませんが報告をあげておきます。

window_interface::idle()から行っているとありますが、
どういった目的でidle内でストリームの読み書きを行っているのでしょうか？

更なる問題を報告します。
これは、解決策が分かりませんので、是非回答もしくは回避策を期待したいところです。
shape_class::create_attribute_stream_interface_with_uuid()
が非常に不安定。もしくは実行後正しく中身が読み取れない。
この現象は、うまく出来るときは何の問題もなく出来るが、
出来ないときは、まったくうまくいかない。
テスト用に、作って直ぐ読み出すことをしてみたが、読み出し時
に例外発生した。読み出し、エントリーはwindow_interface::idle() から行っている。
SDKは8.1.1 で使用shadeは9.0.2 で異常になる。
同じプラグインを shade8.5.2 で実行するとうまく動作する。
原因は？
SDK9を利用すると解決する？
生成後暫く待つ？
但し、ストリームの生成に結構時間が掛かっている。一連のshape にアトリビュートを
書き込んでいくと最初は早いのに異様にどんどん遅くなっていく(書いているのは int 一個のみ)
別エントリーで読み出すと中身が全然異なるデータ。
２日掛かったが原因追及できないので移植は一時中断。

前回の報告以後の判明点を報告します。
１．surface_saver_class が SDK8 以降なくなっているので、これを使う、SDK7 製のプラグインは全て動作しない。
２．何故か、自由曲面パート内の線形状のshape_class で shape_saver_interface を生成するとが例外が発生する。
undo 処理を実現するためには一々チェックが必要になる。
３．コールバック関数 active_shapes_changed 内で set_client_size() を呼び出すと頻繁にデットロックする。
これは、どうもShade9 以降でマルチスレッド制御関係が変化したのが理由ではないかと思います。
これでどうやら、自作の point_edit8 がまともに動きだしました。他のプラグインも全部修正しないと・・・
但し、Shade9 では妙にプラグインの動作に対して脆弱になったようで、もう少し動作チェックが必要です。
(以上は、私のCPUがAMDのデュアルコアであるのが一因しているかも？）

本件に付いて、少し原因が判って来たので中間報告です。
どうも常駐型のプラグインで起動時でのコールバック関数
の読み出し順が変わったことが原因のようです。
というのは、window_interface のプラグインで
プラグイン本体が生成された後に、initialize 読み出し
前に、なんと shapes_being_deleted が呼ばれていました。
その後で initialize が呼ばれ、さらに shapes_being_deleted
がもう一度呼ばれ、次に、active_scene_chainged が呼ばれます。この時点では、Shade のシーン構築が完成してなく、
is_shown() や形状へのアクセスを実行すると例外が発生します。
まさか、shapes_being_deleted がこんなところで呼ばれるとは
考えてなかったので、例外が発生し、後々の処理で異常になるようです。シーンが安定した判断をどうすれば良いか検討して、
全てのプラグインを見直さないと。(常駐型全てでチェック必要です。）

9.0.1 での動作確認です。
まず第一に、表示メニューには現れ、ウインドウが開くことは
確認できました。
しかし、実際の動作は非常に不安定です。何処が、どうおかしい
と特定できない位不安定です。
私の場合、Bancho殿が 9.0.0で言っていた終了時の不正終了と
同じエラーメッセージが、２回起こります。最初が、特定の
winodw_interface の dll 次が ntdll.dll で起こってます。
使っているうちに、Shade が反応しなくなってデットロック
になる場合、（このときは、ShadeのCPU使用率は0％)
不正エラーで終了。
その他、Shade自体の動作が何か変(具体的には、スキンが掛かった形状がジョイントを動かしても動かない等、一部が動くのが不可解。)になったりです。
どうも、Shade9は当分利用できそうもないです。
その上、Shade8に戻ったところ、そちらでも不正終了！
何か変!!!

こっちも9.0.1(win)を早速入れて動かしてみました。

・手持ちのプラグインだと、MASA_殿の「ポイント編集」とファウスト殿の「産毛」では「Plugin」フォルダ内のサブフォルダに入った状態で実行すると起動時に不正終了が出ました。
(サブフォルダを作らない状態で実行すれば回避)
・「ポイント編集」で、「適用」「移動」を押すと不正終了が発生しました。
・「産毛」に関しては正常動作したものの(正確には面の表裏の処理が正反対だが、ブラウザで弄れば済む程度)、最新バージョンで対処された筈の「レジストコードの再入力」が発生しました…

ちなみに、9.0.0での「プラグイン導入時に終了後の不正終了」は無くなっていたようです。

早急なSDKの発表を望みたいところですが…

MASA_です。
Shade９が9.0.1 にアップデートされました！
今回は、随分早いです。
インストールはしましたが、まだ動作確認はしてません。
これで動いてくれれば一安心。

的外れでしたらごめんなさいですが、
私のFaustCadの7.5対応は9でメニューに表示されず、
8.1対応のものは9でメニューに表示されています。
（＃動作がちょっと変で目的の動作をしてないようですがf^_^;）

SDK的な観点からその原因を考えた場合、
プラグインIDの管理が、
Shade 7までの int (16進数8桁)だったものが、
Shade 8.1以降では　uuid_class (16進数32桁)に変更されてます。
SDK 7.1.2のままだとその設定がされてないので、
認識されないのではないでしょうか？
それとそのままのソースだと、
SDK 8以降ではuuid関係のビルドエラーが発生すると思いますが。
ただし、プラグインの種類によってはエラーが発生しなかったりするので、
私もよくわからないところであります。

MASA_ です。
おお、私のプラグインユーザさんからの支援
心強いです。window_interface のプラグインって他の人は殆ど作ってないですからね。
私も、サポートにメールを出したんですが、全然反応がなかったので、このフォーラムに投稿した次第です。
アップデータですか。まず問題を認識して貰えただけでもいいとしますか。
さて、エラーメッセージですが、異常になったところで危ないと
思って殆ど使い込まなかったのでよく覚えてないです。
確か、終了時にWIndowsの回復不可能のエラーが発生しました。いないな...というダイアログがでていたようです。
果たして、何時まで待たされることになるか。

MASA殿、どうもです。

こちらも貴殿のプラグイン「ポイント編集」で上記症状を確認したので、サポートに報告したところ
「アップデータで修正する」
という事でした。

それと、プラグイン導入時に終了後、不正終了(エラー署名：「AppName:shade 9.exe AppVer:9.0.0.723 Modname:ntdll.dll ModVer:5.12.2600.2180 Offset:00018fea」)が出てきましたが、そちらではどうでしょうか？
(ちなみに、プラグインマネージャの「プラグインが推奨しないShadeバージョンでも利用可能にする」をチェックしたら出てきませんでした)

MASA_です。
Shade9 をインストールしてみたところ自作のWindow_interfaceプラグイン(コントロールバー組み込みを除く)が一切表示メニューに表示されないという現象を発見しました。
これでは、まったく使うことが出来ません。一体どうなったんでしょうか。試しに8のSDKのサンプル simple_window で確認しましたが、同様でした。これらのプラグインは全て 8.5 で動いてました。但し、SDKは7.1.2です。(敢えて８にする理由がないもので)
その関係か、インストールすると終了時異常終了します。
OSはWindowsXP SP2 です。
CPUはAthlonX2 64bit メモリ3G　GPUは NVIDIA GeForce 6600
です。
今は Shade9 はインストールしたままで Shade8.5 を使ってます。