How to programmatically fight with WPS

By [[]]

• DESCRIPTION
• TOOLS
• .CLASSINFO, 90 sec delay, DEFAULTVIEW
• PMWP entries in POPUPLOG.OS2
• Lost/broken desktop or broken Templates or Startup
• URL objects
• WPObjData and "Hammer and ..." icons
• WPVault, x:/NOWHERE, NOTVISIBLE, SHOWALLINTREEVIEW
• .HLP not shown in view.exe
• Drag & Drop of .dev and printers
• Start a VIO window with a changed font size
• Desktop background
• Properties of the root directory
• PM_Workplace:Location
• PM_Workplace:Templates
• CREDITS

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 of 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.