I don't think it's the OOP stuff myself, but licensing.

Hi Andrew and All,

. . Linux doesn't have the object oriented underpinnings to fully support the WPS, so it can be only imperfectly implemented.

I don't think that's the issue myself. The OOP stuff of the WPS is in PMWP.DLL, I think. It's only 935421 bytes on my Warp 3 Connect system. Its entry point are listed [link|http://home.clara.net/orac/os2/pmwp.htm|here]. IBM documented an awful lot of the WPS programming issues. See, e.g., this review of [link|http://www.edm2.com/0402/codesmith.html|OS/2 Warp Workplace Shell API] by Carsten Whimster in EDM/2. Someone who understood this well enough, maybe like Kurt Westerfeld (author of Object Desktop for OS/2), could port a PMWP.DLL-like interface to Linux.

I suspect that there are some licensing issues with the code, or IBM doesn't have enough people who understand the WPS code to make it releasable, or IBM thinks the code is more valuable kept internally, or IBM simply isn't interested releasing it is the reason the WPS code hasn't been released. Not some limitation in Linux.

But I have no inside information - the above is just my take.

[link|http://www.pandemonium.de/Linux/Warp/|Here's] a page on getting the OS/2 WPS look on Linux. It doesn't address all of the wonderful OO-features of the shell though.

Cheers,
Scott.

WPS needs support for attributes in the underlying file system. Shell objects' attributes can be stored in a file as they are in WPS, but the files and such that poke thru the shell interface need somewhere to store their attributes. I think OS/2's solution for filesystems like FAT is a attributes file in each directory that needs one (Actually it appears to be more [link|http://www.tavi.co.uk/os2pages/eadata.html|complicated] than that). I believe MacOS X does something similar to file shares. A *n*x port would need to use a EA capable filesystem or a scheme like those listed above. Something like the later would also be needed for foriegn file systems (ie: NFS mounts). However, this brings up the next problem.

Where do you put attributes for a folder to which you don't have write permissions? Should every user have to share all of the attributes of a file? Just some of them? None of them? One possible solution to this (and the other problem too I suppose) is to keep these attributes in the same file (or another similar cache file) as the shell objects.

After playing with WPS recently, I was suprised to see how much of a self contained 'shell' over the exisitng drive letter/directory structure it really is. If one didn't care about the intermixing of (non-shadow) file system objects and shell objects, one could envision a the desktop folders and objects live in their own virtual world (ie: inside a DB file) and filesystem files are only viewed and accessed (say to create a shadow in the desktop) from file system browsers. Make the user understand there is a sepration of the two structures. But then that starts to sound like the Win3.X interface with the Program Manager let out of its window onto the desktop.

Welcome to IWETHEY!