■掲示板に戻る■ 全部 1- 最新50
SHIORIとSAORIのDLL開発者スレ
- 1 ：うにゅう：04/11/04 02:13 ID:XrdXDjGI
- SHIORI(AI)やSAORI(AI用プラグイン)のDLLモジュール開発者向けの話題。
仕様書
SHIORI仕様書 http://futaba.sakura.st/index_develop.html
Disc-2 http://disc2.s56.xrea.com/
CROW・SSPリファレンス http://crow.aqrs.jp/reference/all/
SAORI仕様書 http://www.boreas.dti.ne.jp/~sdn/saori.html
天地の狭間 http://www2.wbs.ne.jp/~dskoba/database/index.htm
駄でべろぱの仕様Wiki http://ssp.shillest.net/specwiki/
ゴースト開発者向けの話題は各SHIORIスレやSAORIスレ等へどうぞ。
- 2 ：うにゅう：04/11/04 02:15 ID:XrdXDjGI
- 現在入手可能な各種SHIORI(*はSAORI対応)
華和梨(*) http://kawari.sourceforge.net/
文(*) http://members.jcom.home.ne.jp/umeici/
里々(*) http://www.geocities.co.jp/SiliconValley-Cupertino/8536/
YUHNA(*) http://star.ruru.jp/r/yuhna/index.asp
忍(*) http://www10.plala.or.jp/sryu/
Scheme栞 http://reangaya.hp.infoseek.co.jp/
Perl栞 http://www.mikage.to/PerlShiori/
Lisp栞-for-win32 - うぁー http://da.pekori.to/wiki/?Lisp%DB%D9-for-win32
- 3 ：うにゅう：04/11/04 02:17 ID:XrdXDjGI
- (参考)SHIORI/3.0 非対応のSHIORI
梨野 http://www.junkyard.jp/nasino/index.shtml
ひとみ。 http://fetish-jp.org/sakura/hitomi-dll.shtml
ese-shiori http://www.globetown.net/~tmizu/ese.html
Psyche System http://www.aa.alpha-net.ne.jp/shinra08/ghost/
- 4 ：うにゅう：04/11/04 08:33 ID:evjAaJC6
- もしかしてninix-aya用のモジュールや偽林檎用のじゃーはスレ違いですか？
- 5 ：◆mvPzKpI.fw ：04/11/04 23:06 ID:9h6B2rWE
- >>2
|_・）里珠(なゆき)はSAORI使えるよ〜
- 6 ：うにゅう：04/11/04 23:17 ID:XrdXDjGI
- 厳密に言っちゃうとスレ違いだけどどうしようか。
以前は 「何か」互換環境総合スレッドってのが立ってたし。
でも人少ないし、とりあえずここでも良さそうな気がする。
盛り上がってくるようなことがあれば分けることを考えるのはどう？
- 7 ：うにゅう：04/11/04 23:21 ID:XrdXDjGI
- >>5
あれ、ホントだ。
ごめん。
- 8 ：うにゅう：04/11/04 23:36 ID:XrdXDjGI
- これも抜けてた…。駄目ジャン orz
SAORI/2.0 (案)
http://salt.sherry.jp/~mikage/saori/saori.html
- 9 ：うにゅう：04/11/06 16:51 ID:sDy5xIJc
- materia、CROW、SSPの各プラットフォームで
挙動の違いに焦点を当てて解説したページってありませんか？
- 10 ：うにゅう：04/11/06 17:33 ID:AU7Ci5ws
- 焦点とはちょっと違うが、Disc-2の資料でいいんじゃないかな。
各種イベントや命令がどれに対応してるってのがわかりやすいし。
困ったときや調べるときはあそこは重宝させてもらってる。
ありがたやありがたや。
- 11 ：さとー ◆wtNnKAwArI ：04/11/06 17:34 ID:V+sgB2eo
- >>9
現存するものでは、umeiciさんのまとめられた「tips meme」が詳しいです。
http://members.jcom.home.ne.jp/umeici/misc/tipsmemo.html
また「CROW・SSPリファレンス」「DISC-2」などでも、どのプラットフォームに
どの機能があるかについて、分かりやすくまとめてあります。
もう1つ、旧もどき開発板には『「何か」互換環境総合スレッド(1024324305)』
というスレッドがあって、プラットフォームごとの動作の違いの情報が集積
されていました。もどき板トップから旧ログをダウンロードして、発掘すれば
見ることが出来ます。
この辺で参考になればいいのですが。
- 12 ：9：04/11/06 20:49 ID:sDy5xIJc
- >>10
>>11
レスありがとうございます。
今schemeをスクリプトとして使用するSHIORIを作成していまして、
CROW、SSPではとりあえず立ち上がってリクエストを処理できるところ
までは行ったのですが、materiaでは
Fatal Script Violation - was derelict to Essential Scripting.
Shell is Invisible, but it is Correct.
ってメッセージが出てシェルが表示されないんです。
しおログでいくつかのゴーストのログをとってみても
違いがわからなかったもので。
直接解決できそうな情報なのかはまだわかりませんが、
有用な情報ありがとうございます。
- 13 ：さとー ◆wtNnKAwArI ：04/11/06 21:57 ID:V+sgB2eo
- >>12
なるほど、そのエラーですか。
それでしたら、OnFirstBoot、OnBoot、OnGhostChanged、OnWindowsateRestore
イベントで\0と\1のシェル番号を指定していないからではないかと思います。
MATERIAは、これら「最初に表示されるイベント」ではシェル指定を必要とし、
指定しないと上記のエラーが出ます。
ダミーでも良いので、「\0\s[0]\1\s[10]」などを戻り値しておくと
エラー表示を回避できるでしょう。
- 14 ：9：04/11/06 22:28 ID:sDy5xIJc
- >>13
それをやってみたらあっさりと起動しました。
今までもSHIORIを作ったりしてたんですけど
どうしてもエラーが出る原因がわからなくてお蔵入りにしてました。
なんか自分がとっても馬鹿みたいです。
これでもう少し先に進めます。
どうもありがとうございました！
- 15 ：うにゅう：06/05/04 21:08 ID:dL2HiJvc
- prolog栞かhaskell栞のどっちかを作るとしたら、どっちが需要あるだろうか。
- 16 ：うにゅう：06/05/06 19:06 ID:VYDtfS9U
- >>15
haskell。
- 17 ：うにゅう：06/05/06 23:03 ID:1jZmw7Zg
- どうせならMIND栞というネタ
- 18 ：15：06/05/07 01:24 ID:Bm6dB0R2
- やっぱhaskellか…
流行を考えれば断然haskellなのですが、prologのルールベースという仕組みが
栞と非常に相性が良いため悩んでいたり。
以下のように、ソースがほとんどそのまんま辞書になります。
----------------------------------
talk :-
きのうghost-nameがさぁ…
.
ghost-name :- 夜姫.
ghost-name :- ヴィイ.
----------------------------------
（全角文字およびsakura script文字は
「応答バッファに一文字書き出す」という副作用を持った述語
として解釈されます。全→全、全→半、半→全角の区切りはカンマ省略可）
haskellだったら関数定義と辞書を別ファイルに分離するとかかなぁ。
- 19 ：15：06/05/07 01:28 ID:Bm6dB0R2
- >17
マジレスするとなんか読んでて疲れそうなので遠慮しときます…
里々が全角文字だけなのは記号を沢山使ってるからな訳で。
- 20 ：うにゅう：06/05/07 07:54 ID:7IZ6gTUk
- My products )
http://www.foreclosedhome.boom.ru
http://www.bestrivercruises.boom.ru
http://www.adaggiostring.boom.ru
http://www.nursingbra.boom.ru
http://www.infantclothes.boom.ru
- 21 ：Clonazepam：06/06/20 17:00 ID:QfS0xfkg
- Nice! Usefull information and all is good arranged.
http://clonn.blox.pl/resource/apoclonazepam.html
http://clonn.blox.pl/resource/buyclonazepam.html
http://clonn.blox.pl/resource/buyclonazepamonline.html
http://clonn.blox.pl/resource/clonazepam.html
http://clonn.blox.pl/resource/clonazepamabuse.html
http://clonn.blox.pl/resource/clonazepamaddiction.html
http://clonn.blox.pl/resource/clonazepamanxiety.html
http://clonn.blox.pl/resource/clonazepamdosage.html
http://clonn.blox.pl/resource/clonazepamdrug.html
http://clonn.blox.pl/resource/clonazepamdruginformation.html
http://clonn.blox.pl/resource/clonazepaminformation.html
http://clonn.blox.pl/resource/clonazepamorder.html
http://clonn.blox.pl/resource/clonazepamoverdose.html
http://clonn.blox.pl/resource/clonazepampicture.html
http://clonn.blox.pl/resource/clonazepamsideeffects.html
http://clonn.blox.pl/resource/clonazepamwithdrawal.html
http://clonn.blox.pl/resource/clonazepamwithdrawalsymptom.html
http://clonn.blox.pl/resource/klonopinclonazepam.html
http://clonn.blox.pl/resource/onlineclonazepam.html
http://clonn.blox.pl/resource/pmsclonazepam.html
http://clonn.blox.pl/resource/rivotrilclonazepam.html
http://clonn.blox.pl/resource/snortclonazepam.html
- 22 ：摂理：06/06/23 07:33 ID:dCDBXP/M
- さおり(dllと読み換えても良い)に関してなのですが、
SSPやDAEなど、ゴーストを複数起動できるベースウェア上で、
2つ以上の栞から同時に同じさおりが使用される場合を考慮し、
loadなどのさおりAPIが呼ばれたら、その呼び出し元を識別したいと思っています。
しかし、GetCurrentThreadIdやGetCurrentProcessIdを試したところ、
同じ値になってしまい区別することができません。
何かしらの識別方法をご存知の方、いらっしゃいましたらお知恵をお貸しください。
- 23 ：うにゅう：06/06/23 23:38 ID:aexU2bu+
- >>22
呼び出し元の何が知りたいのか書いてくれ。
ウィンドウハンドルとか?
あと、いまいちワケワカメなんだが。
ゴーストAがunyu.dllを持ってて、他のゴーストBがunyu.dllを持ってたとして
>2つ以上の栞から同時に同じさおりが使用される場合を考慮し、
っつーのは、ゴーストAが自分のunyu.dllを呼んで、ゴーストBがゴーストAのunyu.dllを呼び出す
ってことでオーケイ?
- 24 ：摂理：06/06/24 01:41 ID:2hwVBLsE
- >>23
説明が拙く申し訳ございません。
使用例はゴーストAとゴーストBとして23氏が示された通りです。
前提条件:
呼び出し元ごとにデータを管理し、スレッドセーフ（ゴーストセーフ？）である。
動作仕様:
load時: (mallocやnewで)新しい領域を確保。[識別子]を得て、確保した領域のラベルにする。
request時: [識別子]を得て、load時に作った[識別子]というラベルの領域とデータをやり取りする。
unload時: [識別子]を得て、[識別子]というラベルの領域を解放する。
識別子について:
この時[識別子]は呼び出し元ごとに異なるものであれば文字列でもIDでもハンドルでも良い。
呼び出し元が同じであれば、[識別子]は同じである。（栞がリロードされた場合は変わって良い）
現在抱えている問題点:
[識別子]を得る方法がわからない。
ウィンドウハンドルとなると、FMOから取得するか、requestで送ってもらうという方法しか
私には思いつかないのですが、前者では区別がつかない気がする、後者ではload時にはわからない。
というのが現在の私のわかる範囲で考えたところなのですが、他に方法はありますでしょうか。
宜しければ、引き続き相談に乗っていただけるとありがたく思います。
- 25 ：摂理：06/06/24 01:44 ID:2hwVBLsE
- >>23
説明が拙く申し訳ございません。
使用例はゴーストAとゴーストBとして23氏が示された通りです。
前提条件:
呼び出し元ごとにデータを管理し、スレッドセーフ（ゴーストセーフ？）である。
動作仕様:
load時: (mallocやnewで)新しい領域を確保。[識別子]を得て、確保した領域のラベルにする。
request時: [識別子]を得て、load時に作った[識別子]というラベルの領域とデータをやり取りする。
unload時: [識別子]を得て、[識別子]というラベルの領域を解放する。
識別子について:
この時[識別子]は呼び出し元ごとに異なるものであれば文字列でもIDでもハンドルでも良い。
呼び出し元が同じであれば、[識別子]は同じである。（栞がリロードされた場合は変わって良い）
現在抱えている問題点:
[識別子]を得る方法がわからない。
ウィンドウハンドルとなると、FMOから取得するか、requestで送ってもらうという方法しか
私には思いつかないのですが、前者では区別がつかない気がする。後者ではload時にはわからない。
というのが現在の私のわかる範囲で考えたところです。他に方法はありますでしょうか。
宜しければ、引き続き相談に乗っていただけるとありがたく思います。
- 26 ：摂理：06/06/24 01:51 ID:2hwVBLsE
- ソヌで再取得しても表示されないのに二重書き込みになってしまいました。
失礼いたしました。
余談。
ゴーストAの栞ghostA.dllをゴーストAからsaoriとして呼ぶことができればいいなあ。
と考え始めたのが発端だった気がします。気にしないで下さい。
- 27 ：うにゅう：06/06/24 17:30 ID:I/lDBkoI
- DLLにとっては「同じ本体」であってゴーストは関係ないわけで、
本体側で何か情報を渡してあげないと区別はつけようが無い気がする。
で、loadの仕様だと何も情報の渡しようが無いので、loadの時に区別付けるのは無理じゃないかな
requestの時にゴースト側から自分の名前でもHWNDでも渡すようにするしかないかと
mallocしたいだけであれば別にloadでやってもrequestでやっても同じじゃない？
- 28 ：うにゅう：06/06/25 03:24 ID:nWZBxBPU
- 23です。
>>22
>ゴーストAが自分のunyu.dllを呼んで、ゴーストBがゴーストAのunyu.dllを呼び出
自分で書いておいてなんだけど、この状態が想像できない。
HandのフォルダのI「HandUtil.dll」を、小夜がロードするってことだよね?
それはともかく、>>27の方法が現実的だと思う。
呼び出したExeの情報を取得するのなら
心当たり在るんでちょっと探してるけど、期待しないで。
- 29 ：摂理：06/06/25 17:52 ID:jS1MVDAs
- 所用で返答が遅れてしまいました。質問の途中で申し訳ございません。
SSPやDAEは、栞（ゴースト）ごとにスレッドを作る仕様だと思っておりましたので、
スレッド情報を辿ることができれば呼び出された側（さおり側）で区別がつくのではないかと
試行し始めたものの、私が試した方法では区別できなかったのですが、
SSPやDAEについて改めて検索してみましたところ、栞ごとにスレッドを作っているというソースが
見つからず、この点で区別がつく方法があるのではないかと考えていたのは、
もしかすると勘違いだったのかもしれません。
- 30 ：摂理：06/06/25 17:52 ID:jS1MVDAs
- requestだけでやり取りするという方法には、いくつか採用しづらい理由があります。
まずこの方法では、使う側はrequestの度に識別子を付加することになると思われます。
しかし、「ユーザが識別子の存在を意識しない仕様」というのも重要な点なのです。
私の意図では、「『一つの起動中の栞』は『一意な識別子』を持つ」という1対1の関係が前提にあり、
さおり側は、そのように仮定した上で、栞ごとにデータを独立して管理しようと試みるものですので、
ユーザが意識的/無意識的に変えてしまえる識別子をrequest中に付加することを許可しますと、
一つの栞が複数の識別子を持つ可能性が出てきたり、他の栞が同じ識別子を使い、
データを共有してしまう事態（データの独立性の破壊）が起こりえたりします。
そうなりますと、意図した動作と異なった結果を引き起こしてしまう可能性があるのであります。
この点につきまして、説明が不足していたことをお詫びします。
また、requestでmallocした場合、解放もrequestを通して指示しなければ
メモリリークを引き起こす可能性があるのではないかということも、理由の一つです。
mallocされる回数は可変であるため、確保した領域は、構造体連結リストで管理するのが一般的かと思います。
STLを使えるのでしたら、識別子をキーとしたmapで管理するのが楽でしょう。
しかし、いずれにしましても、unloadの際には識別子情報を渡せないということになりますので、
さおり側では不要になった領域がどこなのかわからない、ということになると思われます。
そうしますと、メモリリークを防ぐためにはユーザ自らrequestで解放を要求しなければならない
ということになり、大きな負担となってしまいます。
と考え付く問題点をあげてみましたが、一部には私の設計思想的な理由もありますし、無知による
誤りもあるかもしれませんので、問題にならないとお考えになる方もいらっしゃるかもしれません。
もし誤りにお気づきの方がいらっしゃいましたら、ご指摘ください。
- 31 ：摂理：06/06/25 17:53 ID:jS1MVDAs
- >>27
呼び出し側から情報を送らずに、呼び出し元を知ることが困難というのは残念ですが、
参考になりました。丁寧に解説していただきありがとうございました。
>>28
私事のためにわざわざ検索する時間を割いていただいただき、感謝いたします。
もし何かおわかりになりましたら、よろしくお願いいたします。
＞HandのフォルダのI「HandUtil.dll」を、小夜がロードするってことだよね?
そのままではなぜHandのフォルダ内のdllを使用する必要性があるのか不明でしょうけれど、
呼び出し例ということでは、そのようになるでしょうか。
あなたはSSPでHandと小夜を同時に立たせており、
HandがHandUtil.dllを使用しているにも関わらず、小夜もHandのフォルダ内のHandUtil.dllをロードして、
リクエストを送りはじめました。
このような時に、データの独立性を保持しながら動作させたいのです。
- 32 ：えんいー：えんいー
- えんいー
- 33 ：えんいー：えんいー
- えんいー
- 34 ：えんいー：えんいー
- えんいー
- 35 ：えんいー：えんいー
- えんいー
- 36 ：えんいー：えんいー
- えんいー
- 37 ：えんいー：えんいー
- えんいー
- 38 ：えんいー：えんいー
- えんいー
- 39 ：うにゅう：06/07/02 13:32 ID:DZ/KqD6U
23です
>>31
すまん。「任意のDLLをロード中のexeを探す」のしか見つからなかった。
アプリケーションがどのタイミングで、どこのソース内で
SAORIをロードしたかなんて知るのは不可能だと思うから
実現は無理だと思う。
何かしら妥協してはどうですか?
どうしても、って言うならベースウェアを解析したうえで
APIフックとかしか思いつかない。
- 40 ：摂理：06/07/02 22:40 ID:Zz1a+Fo2
- >>39
長期にわたり気にかけて頂いてしまったようで、こちらこそ忝く存じます。
私の方はその後、chksol（ソリティアさおり）がhwndを独自に拾えるらしい情報を得て
調べてみたのですが、複数起動した状態では残念ながら思わしくない様子でした。
また、ご報告頂いたAPIフックについて検索しましたところ、
私の知らぬ知識を得られ大変勉強になりました。
個人的な展望として、一つの栞上に複数のインスタンスを作り
複数ゴーストを別個に動作させるような仕様も考えておりましたため、
それに繋がるような方法に固執していたということもあったのですが、
APIフックを行うという方法は私の能力では大変な労を要しそうに感じました。
よって、解決策を伺ったことを覆すようで心苦しいのですが、
ご提案頂いたように、当面は何かしらの妥協策を選択することにいたします。
本件にあたり、相談に乗っていただきありがとうございました。
また、他のお答えくださった方々にも重ねてお礼申し上げます。
- 41 ：unko：2006/07/05(水) 17:44:33 ID:e90RA2ds
- DLL をスタティックリンクできたらなあ。
- 42 ：うにゅう：2006/07/22(土) 02:58:04 ID:xuQZep8M
- >>40
質問の前提からちょっと見直してみる。
「ゴーストBがゴーストAのunyu.dllを呼び出す」この前提は正しいか？
ゴーストAとゴーストBに「たまたま同じ」
unyu.dllって「SAORI」が入ってて、
ゴーストAはゴーストA配下の「unyu.dll」、
ゴーストBはゴーストB配下の「unyu.dll」、
をそれぞれ呼び出している。
そのとき、それぞれのunyu.dllはゴーストの識別ができるか、
って話じゃないのか？
そもそも原則として、SHIORIは自分の配下のSAORIを
呼び出すわけで、違うゴーストのSAORIを呼んじゃいけないよな。
で、「たまたま同じ」SAORIが呼び出されている前提なら、
SAORI::load関数にはSAORIが配置されているディレクトリpathが
入るんだから、その文字列でゴースト識別できるんじゃないかと思う。
たとえバイナリ的に同じSAORI(DLL)でも、配置ディレクトリが違う別物の
ファイルである以上、インスタンスも別々になるはずだから識別できる
‥‥はずだよな？（弱気
- 43 ：摂理：2006/07/22(土) 18:21:08 ID:oCOkhIjE
- >>42
ゴーストAがA下の、ゴーストBがB下のdllをロードする場合は、
全く同じバイナリでも普通は問題にならないという事は、
同栞のゴーストが複数起動できることからも心得ております。
ここではあくまでAディレクトリ下にあるSAORIを、Bも使う状況です。
もちろん仰る通り、そういった使い方は想定されていないということは承知しております。
しかし論理的にはどこから呼んでも同じことですから、
そうすることで面白いことができるならばそんなゴーストもありだと個人的には思います。
他のゴーストの栞を使うゴースト、既に有りますしね。
- 44 ：摂理：2006/07/22(土) 18:32:20 ID:oCOkhIjE
- 上とはあまり関係のない話です。
OnTranslateもありますし、栞自体が高機能な現在、MAKOTOの使い道とは何かを考えていましたが、
MAKOTOの作りようによっては、追加シェルからSAORIを呼び出すこともできるんですね。
もちろんSAORI以外でもいいのですけど。
恐らく、文と理珠はスクリプトさえ書けばDLLは無改造でいけるのではないでしょうか。他の栞はわかりませんが。
ただ栞をMAKOTOとして使っても、現在のMAKOTO/2.0だと、Stringしかないので大した事はできませんが、
MAKOTO/3.0などとして、IDに直前のSHIORIリクエストのID、
Reference0をトランスレートすべき文字列とする、
もしくは、Stringを変換すべき文字列、Referenceを栞に送ったものと同じReferenceとすれば幅は広がりそうです。
最も最近のシェルでMAKOTOを使っているものを知りませんし、
果たしてそんな高機能なMAKOTOを使った追加シェルを作る人がいるのかどうかもわかりませんが。
ゴーストとシェルを分離するという思想からは完全に外れております。
- 45 ：うにゅう：2006/07/23(日) 12:03:00 ID:FLn010HY
- >>43
まあ、そうだろうと思ってるんだけどさ。
（でなければ元々の質問自体が意味を失うから）
何でそれ（別のゴースト下のSAORIを複数ゴーストで使う）をやりたいのか、
全く思いつかないんだけど、何で？
- 46 ：摂理：2006/07/23(日) 21:25:41 ID:lSx0C416
- >>45
例とすれば、自分ではSAORIを持たず、他のゴーストのSAORIを
検出して使うようなゴーストも私は面白いと思います。
直接SAORIを呼ぶ例ではありませんが、
栞を介すれば、SAORIも呼ばれますので、
栞ジャックする場合、SAORIも複数ゴーストで使っている事になります。
また、最初から複数に呼ばれることを前提に作る
シェアドゴーストというものも考えられます。
ただ、最初の質問の仕方と例が悪かったと反省しておりますが、
具体的には何をやるというより、伺かのプラグインモジュールは、
複数から呼ばれる可能性があるという危惧があり、
その裏として複数から呼ぶことができるという期待がありましたので、
上手く独立させて制御する手段はないかということで訊ねました。
私の設計思想として、データは共有する必要がなければ、
独立していた方が安全だからというところによります。
逆に共有している点を利用した遊び方もありそうですね。
- 47 ：うにゅう：2006/07/30(日) 21:39:51 ID:l8Bh/q/6
- すまん。
質問というか、ひょっとしたら独り言なんだが。
Win9ｘ系のサポート終わっちゃったし、
これからは堂々とWin9x系未サポートの関数とか使っても良いや。
200xやXPで動けば良いよ。他はどうなろうと知らね。
って考える俺はダメポなのかな?
SHIORI・SAORI作りの人や使いの人の意見とか聞きたいっす。
- 48 ：うにゅう：2006/07/31(月) 16:19:41 ID:xw9NtyJ+
- >>47
考え方次第。
「残された１０％のユーザにリーチする」
か、
「醜いコードの原因となる過去の遺産を切り捨てて生産効率を上げ、
新機能も遠慮なく使って９０％のユーザにアプローチする」
か。
好きにすればよい。
１つ言えるのは、
いま、「Windows3.1にも対応します！ 過去のユーザを切り捨てません！」
と言ってもギャグにしかならんということだ。
- 49 ：47：2006/08/04(金) 00:15:55 ID:Bvey5Zo+
- さんきゅ。好きにするよ。
役立たずなSAORIをもっと作ろっと。
- 50 ：任意たん＠開発中：2007/05/21(月) 20:16:10 ID:4aaFqcPA0
- SAORI-basicから、siori（使ってるのは里々）やproxy.dllに値を返す時に文字数制限ってあるの？
返り値が長くなるとsaori-basic側がハングしてる感じなって強制終了すると、途中までの返り値が
返されるんだが。
21KB
新着レスの表示
掲示板に戻る 全部 前100 次100 最新50