How to programmatically fight with WPS:Description: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
<center><noinclude> -- [[How to programmatically fight with WPS|Index]] -- [[How to programmatically fight with WPS: | <center><noinclude> -- [[How to programmatically fight with WPS|Index]] -- [[How to programmatically fight with WPS:Tools|Tools]] >></noinclude></center> | ||
Programmatic access to WPS is complicated due to several reasons: | Programmatic access to WPS is complicated due to several reasons: | ||
| Line 6: | Line 6: | ||
* The current implementation of DSOM lacks run-time method-dispatch-by-name, thus one needs to use CORBA (DII) to make arbitrary method calls from scripts. AFAIK, there is no scripting solution which uses DII for its operation. | * The current implementation of DSOM lacks run-time method-dispatch-by-name, thus one needs to use CORBA (DII) to make arbitrary method calls from scripts. AFAIK, there is no scripting solution which uses DII for its operation. | ||
* Even with this hard-to-reach API, there is no API to fetch the data which allows reconstruction of the object state (serialization/deserialization, marshalling etc). Thus one needs to use undocumented ways to fetch the object state. | * Even with this hard-to-reach API, there is no API to fetch the data which allows reconstruction of the object state (serialization/deserialization, marshalling etc). Thus one needs to use undocumented ways to fetch the object state. | ||
* There is a small subset of API (Win*Object* (C) and Sys*Object* (REXX) API) usable from outside | * There is a small subset of API (Win*Object* (C) and Sys*Object* (REXX) API) usable from outside the WPS process. However, the control provided by this API is very restricted. | ||
However, some stuff can be done even with such low-grade stuff as plain REXX. | However, some stuff can be done even with such low-grade stuff as plain REXX. | ||
[[Category:How to programmatically fight with WPS]] | |||
Latest revision as of 20:36, 23 September 2022
Programmatic access to WPS is complicated due to several reasons:
- Most APIs are accessible only from inside the WPS process (the second copy of PMSHELL.EXE), or via DSOM/CORBA via remote method call.
- To call things from inside the WPS process one needs to "inject" a WPS class into the system; possible bugs in the object will jeopardize the WPS integrity, thus the usability of the computer. This makes WPS classes much harder to design than "ordinary" applications.
- The current implementation of DSOM lacks run-time method-dispatch-by-name, thus one needs to use CORBA (DII) to make arbitrary method calls from scripts. AFAIK, there is no scripting solution which uses DII for its operation.
- Even with this hard-to-reach API, there is no API to fetch the data which allows reconstruction of the object state (serialization/deserialization, marshalling etc). Thus one needs to use undocumented ways to fetch the object state.
- There is a small subset of API (Win*Object* (C) and Sys*Object* (REXX) API) usable from outside the WPS process. However, the control provided by this API is very restricted.
However, some stuff can be done even with such low-grade stuff as plain REXX.