That second instance of the mouse driver is caused by my poor PB fix.
On the original Boxsoft versions of the extension, a PB command had to be typed to initialise the driver.
The extension was loaded but left ineffective until passing the "PB" string(Paintbox) to the extension.
Paintbox and EGI do this internally but it had to be typed to work in Basic so, when I removed the checking inside the extension, it worked straight on Basic but not on the apps.
Then I re-fixed it, allowing the execution of the PB command only if the extension was installed but not linked. Also I added the extension to the initialization chain, loading c register with an 8 at return, but only if not initialized, to protect EGI reinitialisation. A mix of two worlds. At last it seemed to work.
To test if the mouse driver was linked I tried to open a channel, but forgot to close it. Then sometimes, a mouse channel is opened just before a new instance of the extension is loaded and linked. It seems that the channel survives the process...
------------------------------
On the other side, this has been the only weird way to open a mouse channel on WP, while on the others apps tested, the normal way worked.
------------------------
Now I know a little more about EXOS, and I can use other methods to test if the mouse driver has been linked but,
how can an extension be refused to load if exist the same one already linked?