IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Porting the WPS
[link|http://z.iwethey.org/forums/render/content/show?contentid=66858|Here] deSitter asks about porting the WPS. It's a topic that's been on peoples' wishlist for years. Recall that IBM once said that it was going to be the UI for all their OSes and they even had an effort to do a DOS port. A WPS for Win3 was produced, but it wasn't a perfect work-alike.

Peter Moylan covers some of the issues in porting the WPS [link|http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=slrna08i7q.2eg.root%40eepjm.newcastle.edu.au&rnum=9&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26q%3Dworkplace%2Bshell%2Blinux%2BWPS%26sa%3DN%26tab%3Dwg|here]:

And WPS is probably the hardest of all. PM = Presentation Manager,
which is where the basic screen support goes. WPS = Workplace
Shell, which is the GUI shell that sits on top of PM. What makes WPS
hard is that you have to get all the design concepts right in the first
place to support the object-oriented nature of WPS objects, and then
you have to put it all together in such a way that the different bits
of the design don't conflict with one another. This is the level at
which the programmers start introducing deadlocks and unexpected
dependencies and so on. You don't have to be particularly expert to
design a kernel that works and never crashes. Writing a GUI that
never crashes is a couple of orders of magnitude harder. And writing
an object-oriented GUI that works is probably another couple of
orders of magnitude.

The one positive aspect is that WPS is a shell on top of the operating
system, therefore it can be designed almost as if it were an
applications program, i.e. it can be built on top of the existing operating
system support. In principle you could even port the WPS to a
different OS such as Linux or Windows. In practice I don't think anyone's
going to do that, because of the size of the job.


My impression is roughly equivalent to that given by Peter. The WPS needs the SOM (System Object Model) or DSOM (Distributed SOM) framework (which is tied in with CORBA) and until something like that exists on Linux, then a port isn't feasible.

FWIW.

Cheers,
Scott.
New Re: Porting the WPS
Qt's "parts" architecture could probably be sufficiently mapped to SOM and DSOM - it's mapped to COM and COM+ on Windows after all.
-drl
New Yes, that's what I've heard all along . .
Linux simply doesn't provide the object capable underpinings necessary to support a sophisticated object oriented structure like PM/WPS. Its core design is over 30 years old, after all.
[link|http://www.aaxnet.com|AAx]
New More likely
..it's because a lot of WPS is written in assembler.

SOM and DSOM were better then OLE and NetOLE, and that was the motivation for COM and DCOM, and finally COM+. But, the underpinning should be sufficient. In any case, a boatload of OS/2 coders would happily deal with whatever problems were at hand.
-drl
Expand Edited by deSitter Dec. 5, 2002, 01:45:06 PM EST
New the PM layer could be completely replaced
..by an X interface - in fact the best way would be to add an X extension called WPS!
-drl
New OINE
...or do a PM layer over Xlib like Wine does for the Windows API. And the API wouldn't be a moving target.
--
Chris Altmann
New Re: OINE
Hardcore :) - but that would just be OS/2 as is, not reborn - PM has fonts issues. You would want to take advantage of X modules, esp. render and 3D. IOW it's the function and not the representation, so use a better representation.


-drl
New PM's not the problem. At least not the biggest problem.
In fact, you wouldn't want to build a WPS port on a port of PM, IMO. PM has a lot of problems - e.g. if it dies or gets corrupted, it can't be restarted (a reboot is required); and it uses different coordinates from the Win GDI so porting between them is more difficult than it should be (I don't know what X uses).

Any new WPS port shouldn't be built on top of PM, IMO, whether one wants to use X or not. Few OS/2 apps would ever get moved over, so backward compatibility isn't a concern.

The biggest problem is the object model - somebody has to take the [link|http://www-3.ibm.com/software/ad/som/som30readme.html|SOM3] AIX tools and port them to Linux and then implement the [link|http://www.markcrocker.com/rexxtipsntricks/rxtt28.2.0299.html|WPS Class Heirarchy] and then do the work to implement the WPS (or something very similar).

There's already X tools for OS/2, but they have limitations. There is [link|http://ais.gmd.de/~veit/os2/xf86os2.html|XFree86 (v3.3.6) for OS/2] courtesy of Holger Veit [link|http://www.os2ezine.com/v1n6/xfree.html|(interview)]. It's a full port of XFree86, but only runs full-screen. Holger had to do a lot of hacking to get it working on OS/2. There's the [link|http://everblue.netlabs.org/|Everblue] project at Netlabs.org which is an attempt to bring local X apps to the OS/2 desktop. These efforts could (potentially) be of use in going the other way. There are commercial tools to put X (even remote apps) on the OS/2 desktop as well (I think one comes with eCS).

Maybe some of the existing Linux toolkits could be used to implement the WPS on Linux with little work. But since IBM's SOM3 has been out since 1996, it seems that there's something that's preventing someone from jumping in and doing the port. I don't know enough about the nitty-gritty programming issues to say with authority what those issues are.

You'd make lots (a few thousand anyway!) of current and former OS/2 users happy if you could port the WPS to Linux. Care to give it a go? ;-)

Cheers,
Scott.
New Reimplementing the WPS
Reimplementing would be a better approach than trying to port it. SOM3 was never finished, so that's a wash... which is too bad, because that was the one that was going to allow developers to move WPS applications to their own processes while still retaining wps communication with the second instance of pmshell.exe (which is the one that runs the WPS). The current implementation of the WPS uses SOM2, which means that if you want to write a WPS application you will write a .dll file which gets hooked into pmshell.exe and runs as a thread. This makes debugging a bastard and also means that if you load bad pointers you can scribble all over the inside of pmshell.

Hmmm... just occurred to me some of you might not be too aware of how it works in OS/2 land. PM handles the graphics primitives, low level device management, and memory management, while WPS handles the objects. They are both implemented in a program called pmshell.exe. The first time it runs (this is controlled by the PROTSHELL= statement in the config.sys it checks if another copy is running, sees that one isn't, and initiates Presentation Manager. The second time it runs (controlled by the RUNWORKPLACE= line in the config.sys) it checks, sees another instance is running, and uses its services to set up the desktop. When you're booting an OS/2 system, you'll see the screen flip into graphics mode, and a smooth blue background appear. That's PM starting. Then, you'll hear the destop startup sound, and the desktop will open up. That's the second instance starting the WPS.

Anyway... X could probably make a good framework for such a reimplementation. However, it would take a LOT of work to get it right. It would first be necessary to create the object framework, and then to write an application that could use it to create a desktop, using Xs services to do so. In order to really get something that would work well, I think you'd have to have a good threading kernel. Linux is starting to take some real strides in this direction, but until its at a production quality, trying to do this will result in something that will be slooooow. I have to admit I was very disappointed by KDE and Gnome. I hoped that one of these projects would create a worthy WPS successor, at which point I'd have been quite happy to head on over. However, neither of them even come close. I think that the people that like to develop such things could do a lot worse than spend a few months messing around with a well set up OS/2 system to soak up the ambience. Unfortunately, it mostly looks like they spent their time rehashing the broken version of a desktop implementation marketed by that company in Redmond.
--\n-------------------------------------------------------------------\n* Jack Troughton                            jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca]                   [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Laval Qu\ufffdbec Canada                   [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
New Re: Reimplementing the WPS
This is almost all true, but KDE is worthy because it proves that Qt and its "parts" are up to the task of hosting an environment - it also manages to exist in Windows with its threads and in X. Think of Qt as the PM level X interface for the port.

You don't need to port the code, you need to port the functionality.

What about the GNUStep environment? I know nothing. Would that be a hospitable place for WPS?

-drl
New GNUStep? Maybe
[link|http://www.gnustep.org/resources/documentation/manual_6.html|http://www.gnustep.o...ion/manual_6.html] could be the basis for the inter-process object APIs needed for such a thing.

--
Chris Altmann
     Porting the WPS - (Another Scott) - (10)
         Re: Porting the WPS - (deSitter)
         Yes, that's what I've heard all along . . - (Andrew Grygus) - (5)
             More likely - (deSitter)
             the PM layer could be completely replaced - (deSitter) - (3)
                 OINE - (altmann) - (1)
                     Re: OINE - (deSitter)
                 PM's not the problem. At least not the biggest problem. - (Another Scott)
         Reimplementing the WPS - (jake123) - (2)
             Re: Reimplementing the WPS - (deSitter) - (1)
                 GNUStep? Maybe - (altmann)

Dvorak-keyboard powered!
74 ms