> On 12-05-2016, at 2:51 AM, Bert Freudenberg <
[hidden email]> wrote:
>
> The other option would be to actually have a registry in the plugin and only hand indices to the image instead of leaking raw window handles. That way the handles would be completely opaque, and couldn’t be forged by the image. Index 1 would be pre-allocated to the main window. But I agree that the added complexity in the plugin is not worth that effort.
That is the original design requirement; the plugin is supposed to only give the image an opaque (smallinteger) value. If your OS has window descriptor structures that can be used that way (ie fixed addresses below the SI limit, actual opaque handles of its own) then feel free to use them. Other wise use a trivial linked list of the actual OS structures. There’s a well tested example in sqRPCWindows.c and a similarly grey-bearded version in sqMacHostWindow.c
There’s no special technical reason for not handing back OS structures in ByteArrays (like we do with file descriptors) or even using Aliens these days; the practical reason when we originally wrote this stuff was that we knew people would attempt obscene things if they knew the value was a pointer of struct.
The size passed in to open or resize a window *must* be the user area, ignoring the Hosts wrappers; we don’t know what they will be like, how big, if they might appear and disappear or morph… so don’t count them. Yes, this may mean having to compensate for the wrapper sizes in the vm code, in which case blame the damned idiot OS makers. We specified flags to set which bits of wrapper should be created where possible - partly to allow for us making our own pseudo-wrapper in a plain envelope.
tim
--
tim Rowledge;
[hidden email];
http://www.rowledge.org/timStrange OpCodes: FCE: Fill Core with Epoxy
Locked
