Whither FreePM?
Jonathan de Boyne Pollard
supposedly working on?
piesse
> So ... what happened to the FreePM project that the OSFree people were
> supposedly working on?
There is some information on the osfree site
http://www.osfree.org/wiki/doku.php/en:docs:pm:index
piersante
Jonathan de Boyne Pollard
>> were supposedly working on?
>>
> There is some information on the osfree site
> http://www.osfree.org/wiki/doku.php/en:docs:pm:index
>
happening, if anything is indeed happening at all, to the project.
Jonathan de Boyne Pollard
>> were supposedly working on?
>>
> worked on it anymore (just to save the code).
>
> I don't think anyone have done anything to that code since. It is
> available as all osFree code is, on http://osfree.sf.net
>
That's what I suspected: It's dead and barely even a skeleton outline.
That's unfortunate. I was hoping that that would provide something useful.
Allan
Well, you (and anyone else) are very welcome to try to restart that project :-)
osFree suffers - like all other OS/2 projects - from manpower these days.
It will not get anywhere, unless more developers try to help a bit in their spare
time.
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Ilya Zakharevich
>> I don't think anyone have done anything to that code since. It is
>> available as all osFree code is, on http://osfree.sf.net
>>
> That's what I suspected: It's dead and barely even a skeleton outline.
> That's unfortunate. I was hoping that that would provide something useful.
Why?! PM was, I expect, of order of magnitude of hundred of man-years
to implement; and it was still man-years from completion when it was
frozen. Why would anyone expect things to be implementable by a tiny
team of volunteers I fail to grasp...
Ilya
Lars Erdmann
I wish these guys would step in and already start working on a USB 3.0 driver.
The specs are freely available from Intel and we have the USBEHCD.SYS
source code as a starting point (USB 3.0 is similar to USB 2.0 with some added
features) ...
Lars
Jonathan de Boyne Pollard
>>>> were supposedly working on?
>>>>
>>> FreePM was merged into the osFree project last summer, because no
>>> one worked on it anymore (just to save the code).
>>>
>>> I don't think anyone have done anything to that code since. It is
>>> available as all osFree code is, on http://osfree.sf.net
>>>
>> That's what I suspected: It's dead and barely even a skeleton
>> outline. That's unfortunate. I was hoping that that would provide
>> something useful.
>>
> Well, you (and anyone else) are very welcome to try to restart that
> project :-)
>
I was hoping that I wouldn't have to. It's why I asked. I was hoping
that someone else could provide Presentation Manager. I'd like to see
someone else provide a binary-compatible SOM, too.
> osFree suffers - like all other OS/2 projects - from manpower these days.
>
I disagree. A single person *can* handle such a project.
Jonathan de Boyne Pollard
>>> available as all osFree code is, on http://osfree.sf.net
>>>
>> That's what I suspected: It's dead and barely even a skeleton
>> outline. That's unfortunate. I was hoping that that would provide
>> something useful.
>>
> Why?!
>
Because I wanted to use it.
> Why would anyone expect things to be implementable by a tiny team of
> volunteers I fail to grasp...
>
In quite a few cases they *are* implementable.
Jonathan de Boyne Pollard
> driver.
>
I'd like them to have made a usable Presentation Manager replacement.
(-: Or a binary-compatible SOM replacement.
I shall have to continue making do with a TUI for now.
Peter Flass
At least it would be easier now than in the old days, since the hardware
has improved, and there is also a lot of open-source code that could at
least help get started. Unfortunately a lot of PM is poorly documented,
so you'd first have to determine what has to be implemented.
It might be a bit much for one person, but maybe it could be broken up
into manageable chunks and done piecemeal by a small team rather than
trying to do everything at once.
(unfortunately, no, I don't have the time to work on it, although I'd
love to.)
Peter Flass
>> I wish these guys would step in and already start working on a USB 3.0
>> driver.
>>
>
> I'd like them to have made a usable Presentation Manager replacement.
> (-: Or a binary-compatible SOM replacement.
I don't have the OpenWatcom docs handy, don't they have a SOM compiler?
Will Honea
If this gets started, I should be able to supply some resources for it - I
have (had?) a good bit of documentation and some of the source code for SOM
3 before that died. It will take some digging.
The better plan for building would be to use VACPP 3 rather than Watcom
until you get a build environment and working code base. I never had much
luck with Watcom - or VACPP 4 for that matter - and kept falling back to
VACPP 3.
Talk about old/moldy: those archives appear to date from 1999 - 2002! I
still think PM/WPS/SOM was best model I ever worked with. Even DSOM was more
usable than most current desktop systems.
--
Will Honea
Jonathan de Boyne Pollard
>> replacement. (-: Or a binary-compatible SOM replacement.
>>
> I don't have the OpenWatcom docs handy, don't they have a SOM compiler?
>
Not the compiler. The actual runtime itself. I wonder what came of
Esther Schindler's suggestion a few years ago.
Ilya Zakharevich
Given that I do not know you are "they" and what are "cases", I can't
comment on that. Either you have PM, or not - I do not see a point in
implementing a subsystem (but maybe I'm missing something?).
Ilya
Allan
> Jonathan de Boyne Pollard wrote:
>
> >>>> I don't think anyone have done anything to that code since. It is
> >>>> available as all osFree code is, on http://osfree.sf.net
> >>>>
> >>> That's what I suspected: It's dead and barely even a skeleton
> >>> outline. That's unfortunate. I was hoping that that would provide
> >>> something useful.
> >>>
> >> Why?!
> >>
> >
> > Because I wanted to use it.
> >
> >> Why would anyone expect things to be implementable by a tiny team of
> >> volunteers I fail to grasp...
> >>
> >
> > In quite a few cases they *are* implementable.
>
> If this gets started, I should be able to supply some resources for it
It started 10 years ago, I guess :-)
It pauses, when 'current' developers have no more time....
... it restarts, when anyone (you?) starts to give it some attention !
Grab what is in SVN, and see if you can help us.
> have (had?) a good bit of documentation and some of the source code for SOM
> 3 before that died. It will take some digging.
Netlabs started their Voyager project many years ago. At least in the beginning,
it was supposed to be a clone of SOM (called NOM).
There must be some sources available on Netlabs, that can be helpfull
in creating PM/SOM.
Jonathan de Boyne Pollard
>>>>> available as all osFree code is, on http://osfree.sf.net
>>>>>
>>>> That's what I suspected: It's dead and barely even a skeleton
>>>> outline. That's unfortunate. I was hoping that that would provide
>>>> something useful.
>>>>
>>> Why?!
>>>
>> Because I wanted to use it.
>>
>>> Why would anyone expect things to be implementable by a tiny team of
>>> volunteers I fail to grasp...
>>>
>> In quite a few cases they *are* implementable.
>>
> Given that I do not know you are "they" and what are "cases", I can't
> comment on that.
>
Next you'll be telling us that you don't know what you meant when you
yourself wrote "things", the clear antecedent of the pronoun "they".
> Either you have PM, or not - I do not see a point in implementing a
> subsystem (but maybe I'm missing something?).
>
Well you are missing the fairly basic point that if it isn't
implemented, it doesn't exist and cannot be used. Whereas if someone
implements it, it does exist and can be used.
Jonathan de Boyne Pollard
> hardware has improved, and there is also a lot of open-source code
> that could at least help get started.
>
Starting from FreePM, which made the design choices that I'm interested
in, was the idea.
> Unfortunately a lot of PM is poorly documented, so you'd first have to
> determine what has to be implemented.
>
As someone who has written a few PM programs, I disagree again. (-: I
found a couple of things over the years that were not apparent from the
documentation. One was a quirk of the fact that in OS/2 version 2 the
32-bit PM was actually thunked to 16-bit PM under the covers. But
otherwise I've found PM to be well documented.
> It might be a bit much for one person, but maybe it could be broken up
> into manageable chunks and done piecemeal by a small team rather than
> trying to do everything at once.
>
Ironically, someone on one of these let's-write-our-own projects (I
forget which. It was a wiki somewhere.) once put forward that very
idea, simply with a larger granularity and a wider overall scope. One
person/group develops Presentation Manager. One provides a command-line
interpreter and ancillary command line utilities. One provides a
Workplace Shell. One provides an installer. One provides a kernel. ...
That person pointed out that I'd done the second task, and had even made
the kernel implementor's task easier by making my programs purely
32-bit. (-:
Jonathan de Boyne Pollard
> - I have (had?) a good bit of documentation and some of the source
> code for SOM 3 before that died. It will take some digging.
>
You have IBM's actual source code for the SOM Runtime? That's
impressive. It's also valuable. I've read that even IBM doesn't have
the source code any more. Keep hold of that! Don't throw it away.
> The better plan for building would be to use VACPP 3 rather than
> Watcom until you get a build environment and working code base.
>
I still use MetaWare High C/C++ for OS/2 primarily. The problem with
switching to Watcom C/C++ is that my code base requires several things
that Watcom C/C++ doesn't have:
* anybase numeric literals (e.g. 0x2x0010_0100_1101_1001)
* local functions
* for() iterators that use local functions
* DirectToSOM C++
> Talk about old/moldy: those archives appear to date from 1999 - 2002!
> I still think PM/WPS/SOM was best model I ever worked with. Even DSOM
> was more usable than most current desktop systems.
>
Which brings us back to the discussion of realistic short-term goals
from elsewhere in this thread. The whole DSOM mechanism isn't necessary
to start with. Just enough of a runtime for an ordinary DirectToSOM
C/C++ program to work would be enough.
Jonathan de Boyne Pollard
> beginning, it was supposed to be a clone of SOM (called NOM).
>
They chose not to be binary compatible, though. That design decision is
a major problem.
Ilya Zakharevich
>> It might be a bit much for one person, but maybe it could be broken up
>> into manageable chunks and done piecemeal by a small team rather than
>> trying to do everything at once.
>
> Ironically, someone on one of these let's-write-our-own projects (I
> forget which. It was a wiki somewhere.) once put forward that very
> idea, simply with a larger granularity and a wider overall scope. One
> person/group develops Presentation Manager. One provides a command-line
> interpreter and ancillary command line utilities. One provides a
> Workplace Shell. One provides an installer. One provides a kernel. ...
Given that PM is about 2 orders of magnitude more work-intensive than
a shell, I would consider such a "project" a sheer lunacy.
Kernel - I do not know. In principle, I might believe that it is
doable by a one man team (but I would need a lot of convincing) - but
probably not doable by a one man old fart team.
Ilya
Will Honea
>> If this gets started, I should be able to supply some resources for it
>> - I have (had?) a good bit of documentation and some of the source
>> code for SOM 3 before that died. It will take some digging.
>>
>
> You have IBM's actual source code for the SOM Runtime? That's
> impressive. It's also valuable. I've read that even IBM doesn't have
> the source code any more. Keep hold of that! Don't throw it away.
The operative term here is "some" - I doing OS/2 support back when MCI was
using it so there was some leverage - but most of what I got my hands on was
specific pieces to isolate problems as they popped up. Basically, I had
enough to debug the problems we had. I didn't give much thought about the
extent of the code base then as the whole arrangement was just to speed up
our development.
>> The better plan for building would be to use VACPP 3 rather than
>> Watcom until you get a build environment and working code base.
>>
>
> I still use MetaWare High C/C++ for OS/2 primarily. The problem with
> switching to Watcom C/C++ is that my code base requires several things
> that Watcom C/C++ doesn't have:
>
> * anybase numeric literals (e.g. 0x2x0010_0100_1101_1001)
>
> * local functions
>
> * for() iterators that use local functions
>
> * DirectToSOM C++
The reason I brought up Visual Age C++ was simply that it was what IBM was
using at the time. I fought the VACPP -> Watcom battles enough to know that
you wound up doing pretty much a total port of the code. Even going from
the old (circa 1990) CSet compiler to Visual Age was a fight!
>> Talk about old/moldy: those archives appear to date from 1999 - 2002!
>> I still think PM/WPS/SOM was best model I ever worked with. Even DSOM
>> was more usable than most current desktop systems.
>>
>
> Which brings us back to the discussion of realistic short-term goals
> from elsewhere in this thread. The whole DSOM mechanism isn't necessary
> to start with. Just enough of a runtime for an ordinary DirectToSOM
> C/C++ program to work would be enough.
I don't recall if the later versions of Watcom still had the DirectToSOM
functionality or not. I have an earlier version around that has it but I
have this nagging notion that SOM disappeared in the later versions of
Watcom. To me, DSOM was important because 1. the company wanted to use it
and had it incorporated in some of the DB/2 related programs and 2. DSOM
identified and caused a lot of SOM2.x bugs to get fixed.
--
Will Honea
Jonathan de Boyne Pollard
>>> DSOM was more usable than most current desktop systems.
>>>
>> Which brings us back to the discussion of realistic short-term goals
>> from elsewhere in this thread. The whole DSOM mechanism isn't
>>
> I don't recall if the later versions of Watcom still had the
> DirectToSOM functionality or not. I have an earlier version around
> that has it but I have this nagging notion that SOM disappeared in the
> later versions of Watcom. To me, DSOM was important because 1. the
> company wanted to use it and had it incorporated in some of the DB/2
> related programs and 2. DSOM identified and caused a lot of SOM2.x
> bugs to get fixed.
>
Watcom C/C++ has never had DirectToSOM C++ in any version as far as I am
aware. DSOM is usually Distributed SOM, by the way, not DirectToSOM.
You were originally talking about Distributed SOM, weren't you?
Supporting Distributed SOM and supporting DirectToSOM C++ programs are
two different animals. Supporting Distributed SOM requires a whole load
of infrastructure, from marshalling through IPC interfaces to repository
support. Supporting simple DirectToSOM C++ programs requires just the
basic SOM runtime support, in particular the method lookups that are
used by compiled DirectToSOM C++ code, the basic SOMObject and SOMClass
classes, object memory management, and a few other bits and pieces.
Will Honea
> Watcom C/C++ has never had DirectToSOM C++ in any version as far as I am
> aware. DSOM is usually Distributed SOM, by the way, not DirectToSOM.
> You were originally talking about Distributed SOM, weren't you?
Confusion factor ;-) We were using DSOM (Distributed SOM) on that one
contract and I was looking to use it on another project for a different
contract so I bought some version of Watcom that made a big deal out of
DirectToSOM. I'd have to go digging through the CD stack to find the
version that had it but that would take a while - I'm a packrat when it
comes to keeping old software around so the CD stack is (literally) several
feet high.
My point was really that DSOM implementation drove a lot of improvement in
the base SOM code hence the access we had to code.
> Supporting Distributed SOM and supporting DirectToSOM C++ programs are
> two different animals. Supporting Distributed SOM requires a whole load
> of infrastructure, from marshalling through IPC interfaces to repository
> support. Supporting simple DirectToSOM C++ programs requires just the
> basic SOM runtime support, in particular the method lookups that are
> used by compiled DirectToSOM C++ code, the basic SOMObject and SOMClass
> classes, object memory management, and a few other bits and pieces.
You've got my curiosity up now. I'll look and see if I can sort out the
various Watcom releases. I know the DirectToSOM functionality disappeared
before the openWatcom era, likely because of license issues, but I'm fairly
certain that at least one Watcom release included it because I tried to use
it - with less than stellar results.
To give you a feeling for the search task: my office here at home has nearly
50 feet of shelves containing just commercial software releases. I even
keep a couple of 8" floppy drives hooked up to read some of it. One old
machine has 8", 5.25", and 3.5" floppy drives installed plus a punch card
reader. I keep saying that I'm going to copy all that over to DVD but....
--
Will Honea
Peter Flass
Wow, my wife is giving me grief about a bookshelf...
Will Honea
> Wow, my wife is giving me grief about a bookshelf...
LOL. My wife never sticks here head in here - says that between the pipe
and the cigars she couldn't see anything anyway. And I'm fortunate that 2
walls are reinforced concrete basement sections. I once decided that I
needed to paint the room - until I started moving books and stuff off the
shelves. That convinced me that what was really needed was more shelves to
hide the walls that needed paint.
Seriously, until I formally "retired" about 10 years ago I did most of my
work right here rather than in an office so reference material just kept
accumulating. Anymore, about all I do is a few odd jobs on older systems
that I once supported and some volunteer work if it interests me. I know
all too well how a COBOL programmer must feel, but at least it's my choice
now.
--
Will Honea
Paul S. Person
wrote:
>You've got my curiosity up now. I'll look and see if I can sort out the
>various Watcom releases. I know the DirectToSOM functionality disappeared
>before the openWatcom era, likely because of license issues, but I'm fairly
>certain that at least one Watcom release included it because I tried to use
>it - with less than stellar results.
The contents list on the back of the CD-case insert for Watcom 10.5
lists "IBM SOM toolkit v2.0", which may or may not be what you mean.
Examining the 11.0 disk suggests that it has the same item. Examining
the Infobase CD (you pretty much have to disassemble the CD case to
get to it -- but the insert snaps right back in) shows nothing.
>To give you a feeling for the search task: my office here at home has nearly
>50 feet of shelves containing just commercial software releases. I even
>keep a couple of 8" floppy drives hooked up to read some of it. One old
>machine has 8", 5.25", and 3.5" floppy drives installed plus a punch card
>reader. I keep saying that I'm going to copy all that over to DVD but....
You do this so we don't have to, and we thank you for it!
--
"'If God foreknew that this would happen,
it will happen.'"
Jonathan de Boyne Pollard
>>> up into manageable chunks and done piecemeal by a small team rather
>>> than trying to do everything at once.
>>>
>> Ironically, someone on one of these let's-write-our-own projects (I
>> forget which. It was a wiki somewhere.) once put forward that very
>> idea, simply with a larger granularity and a wider overall scope. One
>> person/group develops Presentation Manager. One provides a
>> command-line interpreter and ancillary command line utilities. One
>> provides a Workplace Shell. One provides an installer. One provides a
>> kernel. ...
>>
> Given that PM is about 2 orders of magnitude more work-intensive than
> a shell, I would consider such a "project" a sheer lunacy.
>
You haven't actually measured how work-intensive it would be to
implement, though, have you? Your order of magnitude is just a guess.
Will Honea
> You do this so we don't have to, and we thank you for it!
So far, V10.0 and 10.0a have emerged but 10.5 still eludes me - we may have
to join forces to get to the bottom of this. I'll throw a copy on a Warp 4
VM when I get a chance and see what's there - that will be quicker than
finding the correct documentation for each. Now, where the heck did I stash
the V10.5 CD?????
I'm probably biased but I preferred the IBM VisualAge suite myself. The
only real use I made of Watcom was for cross-platform development. For OS/2
specific projects, the IBM debugger (once they fixed a whole slew of bugs)
made the choice a no-brainer for the work I was doing at the time. I
suspect that the openWatcom product with library sources would have been a
good choice but that came toward the end of my active development life and I
never got into it beyond a few half-hearted stabs.
--
Will Honea
Ilya Zakharevich
Sure - as anything else in programming, it is just a guess. But
education pays.
Ilya
Jonathan de Boyne Pollard
>> the various Watcom releases. I know the DirectToSOM functionality
>> disappeared before the openWatcom era, likely because of license
>> issues, but I'm fairly certain that at least one Watcom release
>> included it because I tried to use it - with less than stellar results.
>>
> The contents list on the back of the CD-case insert for Watcom 10.5
> lists "IBM SOM toolkit v2.0", which may or may not be what you mean.
>
The toolkit is the IDL compiler and related knick-knacks. DirectToSOM
C++ is the ability to write a SOM class just as if it were a C++ class.
As far as I know, no version of Watcom C/C++ has ever had that
capability. It would be good if OpenWatcom C/C++ were to gain it, but
it's not something that it has ever had, at least in any version that
I've ever used.