차례

  1. 일러두기
  2. SHIORI/3.x 프로토콜
    1. 본체와의 통신
    2. Request/Respond의 원형
      1. request의 원형
      2. respond의 원형
    3. ID 종류
      1. 이벤트계
      2. 자원(문자열 리소스)계
      3. 본체 정보계
  3. 참고
    1. Owned SSTP
    2. Purge Test
    3. Limiter (Protector)
    4. 관련 링크

일러두기

SHIORI/3.x 프로토콜

본체와의 통신

SHIORI/2.x와 마찬가지로 다음 3가지 함수로 통신한다. 

extern "C" __declspec(dllexport) BOOL __cdecl load(HGLOBAL h, long len); - C/C++
function load(h: hglobal; len: longint): boolean; cdecl; - Pascal

extern "C" __declspec(dllexport) BOOL __cdecl unload(); - C/C++
function unload: boolean; cdecl; - Pascal

extern "C" __declspec(dllexport) HGLOBAL __cdecl request(HGLOBAL h, long *len);
function request(h: hglobal; var len: longint): hglobal; cdecl; export;

Request/Respond의 원형

request의 원형

[리퀘스트 방식] SHIORI/3.0
ID: [ID의 종류]
{Reference0: [레퍼런스 값 0번]}
....

{{{예: GET SHIORI/3.0 ID: OnAnchorSelect Reference0: hoge }}}

respond의 원형

SHIORI/2.x와 동일한 듯.

ID 종류

이벤트계

자원(문자열 리소스)계

본체 정보계

참고

Owned SSTP

특수한 헤더 ID 가 부여된 SSTP 의 Send 리퀘스트는 Owned SSTP 가 되어 무한 권한으로 처리된다 (곧, 어디서 날아오는 SSTP든지 ID헤더만 맞으면 고스트 자체의 스크립트와 동일하게 대접받는다). 특징은 다음과 같다.

ID 는 날조 되기 어려운 캐릭터 라인으로 SHIORI 로드시에 NOTIFY 에 의해 통지된다. 

SEND SSTP/1. 0
ID: bdf45602c68c26e4e8ed3de82225aaba
Sender: test
Script: \![vanishbymyself]

Purge Test

purge test

백스크롤 시키고 싶다고 생각하는 한 표시 가능행수의 한계는 돌파할 수 없다. 백스크롤조차 없으면 무한행수로 할 수 있다
120 행정도로 표시 가능행수의 한계를 넘지만, 넘어도 특히 행업등은 하지 않는다
SSTP 를 받은 뒤 재생하지 않고 자 버리는 것은 가장 졸린 상태 때
자고 있는 동안 트레이 아이콘으로부터 pop-up menu를 꺼낼 수 없는 것은 정상

wm_copydata 의 핸들링중에 다른 윈도우에 wm_copydata 를 보내는(Direct SSTP)와 win9x 는 떨어진 것 같은 생각이 든다. 즉 반치가 있어 떨어질지, 반치가 없어서 떨어지지 않는가 어느 쪽인가. 에도 불구하고 최근까지 보낼 수 있고 있던 것 같은 것이 불가사의. 더욱(또한) NT 에는 이러한 문제는 없다

이제 와서 쓰는 것도 아닙니다만 first.dll 를 이른바 「범용」으로 하는 것은 불가능. 프로그램적으로 말하면 first.dll 는 오히려 아희여 「범용」인 것 (분)편이 상당히 위대

mahoro 는 저것 이후 다수의 착상 변경이 베풀어져 현상 slayer 에서는 materia 는 기동할 수 없는 상태. slayer 의 (분)편이 빠른 것은 틀림없지만, 자신 이외에서는 책임이 잡히지 않는 것 같은 적당변경이 빈번하게 발생하기 위해, 아무래도 부탁하기 힘들다

메쉬 형상의 화상은 region 생성에 매우 긴 시간을 필요로 한다. 또 그렇게 해서 완성한 region 는 GDI 자원의 소비가 크다. 의 것인지도. 어느 쪽이든 ULW 에서는 이 문제는 일어나지 않는다

모든 상황으로 항상 ULW 가 최고 속도라고는 할 수 없다. ULW 에는 몇개인가 치명적인 결점이 있다

SHIORI 는 「SHIORI 프로토콜로 표준 GUI(본체)와 connection 치고 있을 뿐으로 통신해, 임의의 native code를 실행할 수 있는 독립한 프로그램」이라고 정의 할 수 있다. 그것이 Windows 플랫폼에서는 우연히 DLL 였다고 말할 뿐

OnMouseMove 는, 어쨌든 어루만지고 등밖에 사용되지 않으면, 당 판정 영역내에서 마우스가 움직였을 때 마셔 보낸다고 하는 방법도 있다. 오델로등에도 영향이 나오지만, surface 전면에 해당되어 판정을 설정하면 종래 대로 이벤트가 오므로, 아마 굉장한 문제는 없다

SHIORI/2.x 는 http 를 본뜨고 있는 탓으로 해석에 파서가 필요해, 무겁다. 그러나, 이것이 문제가 되는 만큼 고밀도인 콜백은 SHIORI 가 스스로 , 와 같이 생각하면, 특히 문제는 없다고 말할 수 있다

가장 무거운(고밀도에 콜된다) 이벤트는 OnMouseMove. 차점으로써 OnSurfaceChange

커멘드 태그의 명명 규칙에는 고개를 갸웃하지 않을 수 없는 것이 많다

현재 SHIORI 의 리퀘스트 헤더가 http 리퀘스트와 같이 「내용을 나타내는 명칭」이 되어 있어, 리퀘스트에 의해 뿔뿔이 흩어지지만, 차라리 모두 ReferenceX 형식으로 하는 것을 심플해 알기 쉬운 생각이 든다

사일런트 이벤트는 이유로서는 GET Sentence 는 아니고 NOTIFY 이지만…

\_v 는 개발 환경에서는 왠지 정상 동작하고 있다

네트워크 갱신으로 zip 를 다운로드하면(자) 자동적으로 복원한다. 복원 후 zip 는 delete

region 모드에서의 GDI 자원 소비량은 region 의 사이즈와 complex system에 의존

null 가 되는 Reference 는 헤더 자체가 오지 않는 경우가 있다

오른쪽 버튼의 OnMouseClick 에 대해서 스크립트를 돌려주면 시스템 의존의 pop-up menu는 나오지 않게 된다

현재의 애니메이션 엔진은 delay 값의 취급이 이상

투과색에 rgb(0,0,0)를 이용하면(자), ULW 모드시에 흑으로 다시 바르는 처리가 스킵되어 얼마 안되는 무늬 read가 빨라진다

Limiter (Protector)

「무언가 MATERIA-B period 534」/「동 540」/「동 549」에는, 새롭게 확장된 기능을 제한하는 프로텍트가 존재합니다. 

이 프로텍트는, 다음 순서를 실시했을 때에 해제됩니다. 

 1. 기동하는 고스트가 ghost/first 디렉토리에 들어가 있다 
 2. SHIORI의 패스가 ghost/first/ghost/master/first.dll 
 3. 디폴트 고스트의 DLL이 load되고 있다 
 4. GET Version에 디폴트 고우스트의 DLL가 대답해, ID2를 돌려주고 있다 

-----------------------
3. 의 프로텍트가 해제된 상태에서는, 4. 의 GET Version가 「Date:」헤더 첨부로 리퀘스트됩니다. 

load의 반환값을 디폴트 고스트 DLL와 같은 4609로 한 것 만으로는 재현되지 않는 것부터, 디폴트 고우스트 load시에 어떠한 비공개 펑션에 의해 본체와 네고시에이션 하고 있는 것이라고 생각됩니다. 

이 비공개 펑션을 알지 못하는 한 호환 SHIORI만으로 확장 기능을 사용하는 것은 어렵습니다만, 디폴트 고우스트 DLL과 호환 SHIORI, 2개의 DLL를 읽어들여, GET Version까지는 디폴트 고스트 DLL의 반환값을 돌려주어, 이후는 호환 SHIORI를 동작시키는, 특수한 대리 SHIORI(MOD 시오리)를 작성하는 것으로 회피 할 수 있습니다. 

다만, MOD 시오리 사용시에도 프로텍트 1. , 2. 를 만족해야 유효하기 때문에, 확장 기능을 유효하게 한 서드 파티의 고스트를 인스톨 하기 위해서는, 디폴트 고스트를 삭제하지 않으면 안됩니다.

관련 링크

Nanika: SpecShioriProtocol3 (2008-08-10 19:56:17에 localhost가(이) 마지막으로 수정)