NikiWiki - User contributions [en]

Voyager FAQ

2005-12-13T11:39:57Z

Cris: /* How is this related to MacOS X? */

=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement WPS on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX or MP3 (available soon)
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possiblities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfuly motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

===This project is too big, you will fail===

Maybe. But honestly without trying you wont know...

==Development==
===Under what license will Voyager be released?===
The license will be liberal so using Voyager will not be restricted. On the other hand it will assure that Voyager remains open source. It will not be GPL.

===Where can I download sourcecode?===
Once the license is defined there will be a subversion tree on netlabs.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Voyager FAQ

2005-12-13T11:38:39Z

Cris: /* How is this releated to OS/2 and eCS? */

=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement WPS on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX or MP3 (available soon)
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some some of the ideas and concepts here the reasons for which are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possiblities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfuly motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

===This project is too big, you will fail===

Maybe. But honestly without trying you wont know...

==Development==
===Under what license will Voyager be released?===
The license will be liberal so using Voyager will not be restricted. On the other hand it will assure that Voyager remains open source. It will not be GPL.

===Where can I download sourcecode?===
Once the license is defined there will be a subversion tree on netlabs.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Main Page

2005-11-30T09:34:30Z

Cris: New PM controls from the main menu

__NOTOC__

Welcome to the Wiki at netlabs.org. You will find a lot of interesting information about OS/2 and [http://www.ecomstation.com eCS] on this page. 
If you are interested in joining the '''community mailinglist''' please have a look [[Mailinglists | here]]!

== Roadmap ==
Where are we now and where could we go. Open for discussions.

*[[Ideas]] - This is so far a random collection of ideas and stuff we have in our heads and which probably is worth creating a project for.
** [[Ideas#New_PM_Controls|New PM Controls]]

* [[Community]] - Discussions about the netlabs.org community, website, and so on. Complain here :)

*[[Fundraising campaign]] - Projects that could be realized, support your favourite one!

*[[XWorkplace]] - XWorkplace Future Plans and Ideas

*[[DOSBox Port]] - DOSBox Port for OS/2-eCS Project

*[[Odin]] - ODIN Project todo and Ideas

*[[eSchemes]] - eComStation WPS-based look & feel system

*[[Mr2ice]] - MR/2 ICE is a full featured OS/2 native mail and news client.

== Shop ==
We do have a shop for shirts and more ... [http://shop.netlabs.org shop.netlabs.org]! Prices include a small extra to support netlabs.org's future... (Does anyone know how to add an image here :-P ?)

== New Logo and Redesign ==
* [[Redesign]] - The new logo is choosen and a first and hopefully final draft for the new site layout has been created - check it out ;)

== Development ==

NOTE: This section should not be extended anymore. We reloaded the [http://www.edm2.com EDM/2 magazine] and we recommend to put all developer stuff in there. This wiki is a mess at the moment and we will clean that up one day and migrate the stuff that makes sense to EDM/2. Thanks!

This section contains hints and tricks and descriptions of undocumented
stuff. Undocumented means there's no official documentation or the
documentation (for example included on DevCon CDs) isn't available to
the public anymore. But DON'T JUST COPY any documentation you may have into the Wiki. Keep in mind it's copyrighted!

* [[Undocumented stuff]]
* [[Mozilla]] - some stuff regarding building Mozilla on OS/2
* [http://www.edm2.com/index.php/SDL SDL] - some tips & tricks about how to port applications using SDL to OS/2
* [http://www.edm2.com/index.php/How_to_program_for_the_WPS WPS] - how to program for the [http://en.wikipedia.org/wiki/Workplace_Shell WPS]. Note: the german Wikipedia may have more information about the WPS. Go [http://de.wikipedia.org/wiki/Workplace_Shell here].

==OS/2 and eCS resources==
===Drivers===
*Visit http://www.os2warp.be if you want to know if your hardware is supported.
*See a [http://www.ecomstation.it/pido2/home/mircomir/fixpak.php?lang=en driver list] generated from eCSoft/2 database.

===Software===
For software have a look here:

* http://hobbes.nmsu.edu
* http://en.ecomstation.ru/apecs.php
* http://www.ecomstation.it/ecsoft2/
* http://www.unixos2.org - ported *nix tools. A little bit cumbersome to find stuff there but nevertheless worth the effort

===Programs===
How to use specific programs, HowTos, FAQs etc.

MR/2 ICE [[mr2ice]] is a full featured OS/2 native mail and news client.

==netlabs.org Servers==
===ToDo's & History===
This is the list of tasks for netlabs.org Webservers and the history of what I (ktk) did
*[[netlabs.org]]

===Mail account===
Some information for those who own a mailbox at netlabs.org
*[[netlabs.org Mailing]]
===Admin Guide===
So far it's more or less just me who does all the work on netlabs.org webpages and this somewhat sucks because like this a lot of stuff depends on my lazyness. The following document explains the tasks necessary to create a new project at netlabs.org, including setting up CVS repositories, creating webpages and so on. I hope that I will find some volunteers one day who help me on doing that.
*[[Admin Guide]]

Ideas

2005-11-30T09:17:52Z

Cris: New PM native controls for frequently used functions

Note: This page is extremely unorganized like most of my todo-lists I do at home. Feel free to add your ideas here. We hopefuly organize that a bit better one day...

* eComStation is very nice in my opinion (ktk speaking here :-) but updating it is still a major pain in the ass. We need a easy and stupid proof way updating it. And *please* in a non-GUI version too!

==MultiMedia Improvements==

There seems to be two ways to achive Multimedia Improvements

===Enhancing the native MMOS2 Infrastructure===

There should be goals like:
* Complete Open Source Replacement of all the MMOS2 files
* Create a Bundle package of all Open souce CODECs
* Re-energize the [http://www.reamined.on.ca/doconnor/mmos2/ OS2 Multimedia Infrastructure Project]
* Write an IO Storage procedure for proper streaming support, so the CWMM classes could handle more than just Icecast streams (the current one fails because it doesn't get the expected header which prepends the stream)
* Add Storage IOProc support to Format IOProcedures which doesnt' supports them (like JPEG I/O, PNG I/O, MP3 I/O, OGG I/O, Vorbis I/O, etc.). ??? Every format I/O proc supports storage I/O procs out of the box. Otherwise you couldn't use them because the access to the filesystem is implemented using a sorage I/O proc. Strictly spoken the format I/O proc isn't aware of storage. MMOS2 handles the stuff. !!! Not every FIOProc uses SIOProc. Above IOProcs uses direct file access instead of SIOProc. FIOProc MUST be written with SIOProc support in mind.

The projects that can be integrated are:
* [http://www.reamined.on.ca/doconnor/timidity.html TiMidity MCD for OS/2] (midi)
* [http://r6.ca/MMAudioPak/ MMAudio Pak 2 for OS/2] (MP3, Vorbis, FLAC)
* [http://www.os2world.com/cdwriting/mmclasses/mmclassesmain.htm CW-Multimedia classes] ''(Prokushev) Unfortunately, CWMM Classes are not open source. As result, can't be extended. Another problem is no IDL files for CWMM Classes or MMOS/2 Classes. As result, classes can't be extended. Only solution is restore IDL files from IR or using class information from MMPARTS.DLLs. Or ask Chris to open source his classes or, at least, to publish IDL files''
* Quickmotion (Quickmotion's Tom Harding told there there could be a change to open source it if we find an developer for it

Check also the [[MMOS2 Related Projects]]

===Enhancing NON MMOS2 related Multimedia (like WarpVision) ===

This seems something that Vladest might tackle with WarpVision: [http://www.videolan.org/vlc/ VLC media player]

==UnixOS2==
There is a ports-like system for UnixOS2 in the works at the moment but I'm not really happy with that one and I doubt that we will be enough people for maintaining all that stuff ourself (dependencies and so on...).

When I use Linux I often work on Gentoo, which has really the best source-based ports system I've ever seen (and I know BSD too so it's not the only ports-system I know ;).

At the moment the ports system is quite Linux oriented but at the moment there is a complete rewrite of the portage-system in progress. They call it [http://www.gentoo.org/proj/en/portage/portage-ng/systemspec.xml portage-ng]. One of the targets is cross-platform support for stuff like BSD or MacOS so I really vote for OS/2 support as well :). It's too early at the moment to really have a look at it but we should definitely do that as soon as possible.

The discussion about portage-ng is [http://news.gmane.org/gmane.linux.gentoo.portage.devel here]

Update September 04: I talked to the guys who work on portage-ng. It looks like portage-ng is not really dead but at least progressing very slowly. Meanwhile, a group of MacOS X users created a [http://www.metadistribution.org/macos/ portage for MacOS X] so it looks like it does work on BSD-like systems too. So that changes the todo list a bit:

TODO:
* set up a basic package with latest GCC and Innotek LIBC. The basic package contains all tools and libraries needed to compile Python with Innotek LIBC.
* as soon as Python compiles we need to wrap together <tt>emerge</tt> on OS/2. This might get a bit tricky because it also heavily relies on shell scripts. So whatever shell we gonna use, it must be as close as possible to bash (if not bash anyway, it looks like the stuff is not that portable to other shells).
* once we get portage to work properly we need to create ebuilds for the basic libraries. At the first stage there is no rsync server needed to do this but it will definitely get handy sooner or later (shouldn't be a problem but needs to be set up).
* implement more and more ebuilds for all kind of packages
* and in a later stage create a bootstrap-package that also compiles GCC and all other tools (that won't be an easy task :)

==PM==
We need to port some toolkits or finish the current ports:
* qt - more soon, looks good
* GTK2: Samm proposed to work on it, will give an estimate of time soon
* wxWindows: Port quite up to date but the PM parts in it are definitely not yet done or very buggy -> fix (probably dmik)
* SWT: will be done when Eclipse is done -> dmik
* An Everblue-based X11 server might be interesting(?) as a replacement for HOBlink which seems to get increasingly outdated; at least I'm seeing more and more crashes in newer programs...

Also, it would be nice to have updated public PM controls. This should be done with one DLL subclassing these public controls, and extending and/or fixing their behaviour. Things to fix/implement should be:
* Remove 64K limits in some of the controls
* Create extended MLE control (understanding HTML tags maybe?)
* Automatically drop-down list of combobox, when clicked (like DragText does)

==[http://www.edm2.com/index.php/SOM WPS] (Workplace Shell)==
* replace background image dialog, it should be possible to point that to another directory than \os2\bitmap
Note: This is already possible and a lot of software to make things like
slideshows out of it exists also. - lp

* replace the file dialog, Gnome 2.6 does that '''very''' nicely (screenshot will follow).
* replace the Icon rendering, should be able to handle stuff like PNG as well and in best case also SVG
Note: Don't think we must replace Icon rendering. But adding MMPM IO procs for PNG and SVG is good idea.

Note: most probably PNG IOProc will be included in next eCS version -prokushev

Note: File dialog is not a WPS issue. But it can be implemented via WPS class. I consider it is good idea to move to object world. - prokushev.
Can you describe that a bit with more details prokushev? - ktk

Yes. File dialog placed in PMCTLS.DLL. We can do such trick:

# move PMCTLS.DLL to PMOLDCTL.DLL
# write new PMCTLS.DLL with forwarders to PMOLDCTL.DLL
# In WinFileDlg (new PMCTLS.DLL) we must check, is WPS exist? If exist, then just create WPS object (with name like WPOpenFileFolder or something like this) and monitor it (wait result from it). As result our open file object can be replaced and/or extended by standard SOM features. If no WPS exists then call or old WinFileDlg or our own implementation of open file dialog (for systems without WPS)

WPOpenFileFolder is subclass of WPFolder with changed reaction on open objects in it. If object is folder then go deep. If object then close WPOpenFileFolder and notify our new WinFileDlg. Comment: You can't do that with a WPFolder subclass because it expects every inserted object to be an existing object. So you will end with copies of each object. You have to create something different or override *a lot of methods* in your WPFolder subclass to get this done properly. And a lot of probably means every method introduced by WPFolder.

(Cornelis): One more problem with that method: An application can call WinFileDlg providing an own dialog resource and handling the dialog messages in its own way! I cannot see how this case could be handled with the WPS method. The only "solution" I can imagine at the moment: Also check for custom resources or custom dialog function and if they exist, do not call the WPS file dialog. I don't know how many applications use these features - but I am afraid that quite a lot do it...(!??)

Something like this.

And yes, it can be part of XWP.

BTW, how about move Doodle Screen Saver to XWP? ;)

BTW 2 : Why dont add also LSwitcher to XWP ?

Cinc: I oppose the idea to add every single utility in the world to XWP. Maintaining the XWP code is difficult enough right now because of complexitiy. Adding Utilities to XWP means they are not available for people not using XWP (for whatever reason).

=== What about Backup / Restore / Portability of WPS objects !?? ===

(Cornelis): One serious disadvantage of the WPS gets even worse with all new and derived classes: There is no way to save the WPS with its "objects" in an open format in order to port them to another system or to a new installation! I know there are programs like Open Desktop and other WPS backup and restore tools, but they all only work with a set of "normal" objects, like folder objects, program objects etc., ask their properties and store them somehow. But neither would these tools find any newly defined objects (like already the "Workframe" objects of VAC/C++ 3.0), nor would they save any extended features (like the content of the "Environment" settings page of XWP extended "program objects").

This is a conceptual problem, because in an "object oriented world" any saving/restoring program should not have to know anything about the properties of the WPS objects, but just have to call a standard function that has to be defined for each and every object: "getAllProperties" or such. And then restore it with the corresponding "setAllProperties" call. While all derived classes would have to implement versions of these functions.

Without knowing any internal details of the WPS I assume that such functions do not exist, so their introduction would not be easy. Would it be possible at all? Did anybody ever think about such an issue?

Cinc: No there isn't such a function. Nevertheless it's possible to emulate it by overriding wpSave*() methods in one base class and telling the class to save the internal variables by calling wpSaveImmediately(). In the wpSave*() override you can catch the information. Restoring the data on recreation is more difficult, though, but there may be a similar way.

djmutex: XWorkplace has a framework in place to allow for retrieving the complete setup string for each object, and I also started implementing a recursive function that will walk thru folders and collect object data to create a REXX script that will recreate these objects somewhere. However, the code isn't quite finished. Check fdrCreateObjectScript in src/filesys/object.c, which has roughly working code. This needs some polishing and bugfixing only, which I no longer have time to do.

===Desktop Search Engine===
I recently found a nice application on MacOS X which provides some form of desktop search engine. You can index all kind of documents and then you can easily search for it on the desktop. The cool thing is that it is plugin based so everyone can write an extension for new document types or something alike.

A friend of mine does something like that in Java right now and as search engine core he is using [http://lucene.apache.org/ Lucene].

Cris: I'd love to have something like this on OS/2 too. On hobbes I have found a recent port of Swish-e (http://swish-e.org/). If I understand it correctly, this is exactly what we want. We have to create a user interface, and add a couple filters to exploit OS/2's features (e.g. extended attributes).
I have been dreaming about this for a while, but never had time to start working on it.

==Porting Windows 32 Applications with ODIN Tutorial==
It would be nice if there is a tutorial on how to use odin to port open source win32 apps to OS/2.

==Drivers Development Skeleton==

A skeleton driver that can be used for writing drivers. More importantly, a hands on/hand holding tutorial for writing drivers. Writing drivers is a daunting project, but is necessary for OS/2 to survive in the long run.

==USB Drivers==
[[USB_Todo%27s]]

==External list==
* [http://www.os2bbs.com/os2news/OS2Wishlist.html The Warp Wishlist] maintained by [[Kris Lake]].

==Open Source OS/2 Strategy and Follow up of Open Components==

An strategy with the final goal to have OS/2 open sourced. 
More than a development project it had to be an integration project of open source software for OS/2, like an information site to follow up all the open source replacement for OS/2 closed components. On this site we will list the open source project available for OS/2 and the closed component that is replacement.
 
Ex: 
* Newview.exe -> replaces View.exe -> License GNU GPL
* XWorkplace
* HandyFTP
* Doodles Screen Saver
* lSwitcher
* etc, etc

Plan to make replacement for:
* command line programs like "xcopy.exe, attrib.exe, etc" (some tools already exists as part oof osFree project)
* Enhanced and replacements of CMD commands (some tools already exists as part of osFree project)
* Replace of some closed DLLs (some DLLs already exists as part of osFree project)
=== Open Source OS/2 Distribution ===

Build a OS/2 distribution with open source replacements on it. Of course that many people says it is too hard, but we need to start with something. It can start creating an OS/2 distribution that is focused in Open Source components, and bundle on it, dssaver,xworplace,lswitcher, xfree, emx, warpin, usbres, etc. (bitmaps, icons and drivers too)

To don't start it as a too complex project it can be something similar to the UpdCD project, that requires license of Warp 4.52 or eCS to build an updated image. 
We can ask help from UpdCD project to create an install image (that will require the OS/2 CD) that contains open source software on it replacing the closed components. And keep evolving this project and replacing components until in some years it can work without licensing OS/2 from IBM.

One may think about an open source distribution you simply install over an existing installed system

=== osFree project ===

I want to remember to all about existing of osFree project (site at [http://www.osfree.org]). At the present time it is collection of open-source replacement of closed OS/2 components. It includes:

* Customized 4OS2 as cmd.exe replacement (mostly integration to common build system and moving 'not must have' commands to stand-alone executibles)

Remark (Cornelis): But 4OS2 is not Open Source!?? It's Freeware AFAIK!(?) Otherwise: Why not consider the 32-bit Command Line, together with the "OS/2 command line utilities" by Jonathan de Boyne Pollard [http://homepages.tesco.net/~J.deBoynePollard/Softwares/] ? These aren't Open Source either (also Freeware), but very solid and mainly focused on extending the CMD.EXE functionality and make it fully 32-bit. Extensions are the tools. (Why 32 bit? Well, I use it together with make, which "feeds" the command line interpreter sometimes with commands of several thousand charecters - much more than CMD.EXE would ever digest!) Furthermore: 4OS2 is just "set free abandonware", while there is still a person behind the 32-bit Command Line Interpreter...

Remark (LightElf): 4OS2 IS Open Source (GPL as far as I remember). Now it hosted at Scitech.

(Cornelis:) This is what I find at Scitech: [ftp://www.scitechsoft.com/devel/4os2/4os2304f.zip] But that contains just binaries! This is not to contradict you; I only didn't ever hear about an Open Sourced 4OS2, and still I cannot find it where you say it is!? But please correct me! For the rest: Open Source or not - I would still point out to not forget the "32 bit command line interpreter"! (Maybe the status could even change if there is a good point being made by the right person at the right time??)

(Prokushev): 32-bit comandline interpreter depends on 32-bit vio/kbd API. If no 32-bit API then no 32-bit CMD ;) If vio/kbd will be implemented then just recompilation of 16-bit CMD.EXE will move CMD.EXE to 32bit world ;) Nothing hard here.

(Cornelis): The "32-bit commandline interpreter" and the "OS/2 commandline utilities" are '''existing''' freeware products, running on '''existing''' OS/2 or eCS systems, so it's even easier! The only "problem": it's freeware, not open source.

(Prokushev): And "32-bit commandline interpreter" is actually just uses CONAPI which just wrapper around old 16-bit API. Don't see any differents with stnadard 16-bit CMD.

(Cornelis): There are '''a lot''' of advantages! Please go and '''LOOK AT IT''' and '''READ THE DESCRIPTIONS''' before you make your statements! [http://homepages.tesco.net/~J.deBoynePollard/Softwares/cmd.html] Actually besides all advantages for the user (like no more limitations in command line length etc., while maintaining the most possible compatibility with CMD.EXE) it indeeds is NOT a wrapper around the old 16-bit API, but it uses the "32-bit Unicode Console API" [http://homepages.tesco.net/~J.deBoynePollard/Softwares/conapi.html] which replaces completely the old 16-bit API functions you mention.

(Prokushev): "32-bit Unicode Console API" is wrapper around old 16-bit API. It closed source. 32-bit CMD is also closed source. And uses 16-bit wrapper. Actually, CONAPI.DLL uses CON3216.DLL which IS wrapper.

(Cornelis): For me this "discussion" is getting a bit irrational now: I never intended to engage in such a stupid "faith war" for a piece of software!

But ok, if it's so important: Several levels "further down" from the 32-bit command interpreter you do indeed still hit 16-bit functions. But what's the problem with that? As long as there are 16-bit drivers this will always be the case! The important points for me are:

1. The 32-bit CMD offers a full 32-bit interface for programmers, which is designed after a later abandoned 32-bit interface by IBM. So if any programmer would use that interface, all options are open to later replace the 16-bit code two levels "further down" later on, no changes being necessary to the software.

2. The user doesn't suffer from any old size limits any more either, like a limited command line length.

3. The command syntax is very closely compatible with the CMD.EXE syntax, and where it is changed in order to make it more consistent, these extensions can be optionally turned off.

For these three reasons the 32-bit command interpreter is more future oriented than a thing like 4OS2: That one has nice extras, but is much less compatible with CMD.EXE, which generates problems in certain cases. A high degree of compatibility even in details has many advantages, because software developers or script writers etc. can rely on a specific surrounding. Keep in mind all the troubles we have already with the two REXX "flavors" on current OS/2 systems: A developer can NOT rely on an existing "classic REXX" or "Object REXX" surrounding! This would be the same with 4OS2 becoming part of a "new OS/2 standard".

Concerning the source license: 32-bit command interpreter is freeware, not open source. 4OS2 was claimed to be open source above, but nobody could until now give us an URL of the sourcecode, so this looks at least dubious: It seems that 4OS2 is also just "freeware", not open ource.
Cinc: as LightElf already pointed out 4OS2 is open source. There're even different versions floating around made by people who grabbed the source and fixed some bugs. No I don't have the URL handy. Google should help there.

And only for that reason I asked to consider also the 32-bit command interpreter, besides of course also 4OS2.

(Cristiano): 4OS2 definitely '''IS''' open-source. If you search on hobbes, you'll even find two different and somewhat incompatible code branches. One is the "official" Scitech branch, the other is a branch made by some private individual, starting from the original JPSoft source code (i.e. not building on Scitech code). If you want to know better, ask Michal Necasek (SP?) of Scitech. He'll tell you what's the current state of 4OS2 code, where you can get the source, and more.

* ReginaREXX as REXX replacemend (still missed 16-bit wrappers). Subject to change to Open Object REXX.
* Replacement of many command-line tools (like attrib, ansi, chkdsk, etc.). Mostly without error handling.
* THE as TEDIT replacement
* Some forwarder DLL's (like VIOCALLS, MOUCALLS, etc.)
* FreePM sources (because FREPM seems to be discontinued)
* other things.

CVS controlled by ktk, so anyone free to contact with him to have access. osFree site can be used for above things. To do it just contact me (prokushev here).
But another general thing is it's time to make one general open-source components repository with common build environment with general goal to create open-source OS/2.
And, again, osFree can be good place for it. osFree not limit in languages (except common build environment). C, C++, Fortran & Pascal currently in use. Perl is coming (REXX compatible API for Perl, if possible, is planned).

Really, main goal of osFree subsection is to point above project already exists.

Insted of talking HOW OS/2 must be open-sourced (from the kernel to WPS or from WPS to the kernel) I propose (prokushev here) just start collect already existent things. Thing happen if try to do them.

=== Kernel Free (OS/2 Kernel with License GPL) ===

To release to the kernel of the system on the part of IBM and other companies.

Cinc: why GPL?

BTW using a GPL kernel wont allow to create *any* closed source software because you're not allowed to link it to GPL code dynamically. So much for the GPL hype...

==WarpModem==

The general idea will be to make a commun interphase (like Windows 95) for analog modems on your OS/2 system called "Warp Modem". Programs that uses the modem will had comunicate to "Warp Modem" to get the configuration of the modem and it status. This will be useful for OS/2 user, because he will not configure the modem on each OS/2 application that uses the modem.
 
What will be good is to have a "Modems" icons inside the OS/2 System Setup folder.

http://www.os2world.com/pictures/articles/SystemSetup.jpg

This program will show us the modems that are configured on our system. If the systems has two ore more modems it will shows us all modems that we had configure.

To make this configuration we can start using the Doug Bissett's modem configuration list (http://www.os2warp.be/modems/modem.lst)

On this menu we can see the "Add...", "Properties...", "Delete..." and "Test..."

http://www.os2world.com/pictures/articles/Warp%20Modem%20GUI.jpg

Add button will show us the instruccions to add a new modem

http://www.os2world.com/pictures/articles/Modem%20Config.jpg

(picture taken from ATT Dialer)

The "Test..." button will be a tool to test it is working. A good idea is the one from ATT dialer too.
http://www.os2world.com/pictures/articles/Modem%20Tester.jpg

(picture taken also from Att Dialer)

"Properties..." will show us something similar to the "Add" window to change the modem configuration.

I think "ADD" should support "Installing" the modem using the windows "drivers" i.e. the inf-files which contain the AT seq. used for certain operations which an application can then query or call via an published API.

"Remove..." will ask us for confimartion to delete that modem

And the app should seperate the physical modem from multiple configurations one could have.
i.E. a Modem has a max speed of 36.000 baud but I should be able to create a fax configuration with would setup the modem to lets say 14.400 etc.

Other tools

So, what kind of software will be good to integrate with Warp modem ?

All programs that used a analog modem can take advante of this. Developers of Phone dialers, Fax, Internet Dialers, Voice Phone, RAS, BBS software..etc..etc..

http://www.os2world.com/pictures/articles/Modem%20Selector.jpg

Documentation

This project will need a good documentation so developers that wants to uses the OS/2 Warp Modem configuration can access it easily for their phone/fax/modem applications.

Wish list

# Open Source Project / free license GNU GPL.
# C++ or Java development.

This is just a development idea, there is nothing coded on this direction. The pictures in some cases are just fake to explain the posibilities of this project.

== Port of coLinux ==

I would like to see the 'Session' capabilities of OS/2 expanded upon. While a port of coLinux ( http://www.colinux.org/ ) wouldn't be a true session, this could be a step toward this goal. Especially if an IFS driver could be written to allow the disk image to be mounted.

== Netlabs runtime distribution ==

Create a set of runtime libraries filling the voids of OS/2. For example including an additional Rexx utility DLL with much needed functions, a set of standard window classes for use in programs (see also PM and open source distribution above). The following classes should be easily implementable (Cinc: I've got already some code for them):

* Progress bar
* Separator
* URL control (control which shows a URL and starts the browser on click)
* ...

Everything should be extremly hassle free to install. So in the end every user has it on the system and developers can be sure to find that. If not they may just write in the readme: "Prerequisite: Netlabs runtime Distribution".

It's not necessary every developer reinvents the wheel again and again. A good starting point is the WPS toolkit IMHO: http://wpstk.netlabs.org/
(don't be fooled by the term WPS in the name, it contains also general purpose functions). The following general purpose functions should be added to WPSTK:

* Query function to get the common OS/2 directories (e.g. ?:\OS2\DLL)
* Function to get the users home directory
* General purpose about box using a predefined look
* Function to start the default OS/2 browser
* ...

There is also quite a lot of helper stuff in xwphelpers from XWorkplace. At the moment it's quite difficult to use them because you have to compile it in your own application so probably we should use parts of it and put it into WPSToolkit as well. We would have to check the licensing issues however because xwphelpers are GPLed and WPSToolkit will most probably be based on BSD or MPL or something alike (more liberal than GPL).
If xwphelpers are using GPL (and not LGPL) they are useless for this project anyway. Nobody will (and should) use a GPLed library.

There should be some general libraries in there as well like:
* libxml
* rexxml (REXX interfaces for libxml)
* libpng (proposal by nickk IIRC)

(prokushev:) Don't think libpng is a required lib. PNG support planned to be included in next eCS version. Native solution is better in comparation of ported tools.
Cinc: this library is meant for porting stuff to OS/2 and it's available *now*.
prokushev: pngioproc available *now*.

We should add some functions extending PM/GPI to deal with unicode/locales. For example a unicode/locale/whatever aware WinDrawText() function. Maybe we even should patch WinDrawText() and friends to be unicode aware by default.

==New PM Controls==

PM lacks a number of controls which are common to the other platform and GUI toolkits.

A few examples are:
* toolbars
* status bars
* enhanced MLE (huge texts, syntax highlighting, multiple fonts/colors, etc.)
* ...

Every developer that has to face with the necessity of creating and using such controls reinvents the wheel.

We have multiple, often open source, implementations of these controls, but every implementation is in the form of source code that needs to be integrated in your application, or in some proprietary (e.g. VX-Rexx) format.

A really good project IMHO would be to scan the available implementations, take the code of choice (how to choose? a poll?) and implement a standard PM custom control to be distributed in a DLL. An even better choice would be to group all the new controls in a single DLL to be distributed as a new system DLL (-> with eComStation 2?)

I am starting here with a few helpful resources:
* toolbars ([http://es.os2.ru/cell.html Cell Toolkit] - [http://hobbes.nmsu.edu/pub/os2/dev/pascal/celltpas.zip Pascal interface to cell toolkit])
* status bars (same as above?)
* enhanced MLE
** there is the EMLE of EPM
** a (not complete) rich text control is included in the source code of XWP
** [http://scintilla.sourceforge.net/index.html Scintilla] (needs to be ported)
* ...

Yes, we have a few native toolkits ([http://dwindows.netlabs.org/ e.g. Dynamic Windows]) and a few ported toolkits (e.g. QT3, [http://www.wxwindows.org/ wxWidgets]) that include these types of controls and more.

These toolkits are great resources for developers, but I feel there are a few problems for more general use:
* there are a few controls that are by now considered standard, and that should be included in the OS rather than in a huge do-it-all toolkit
* if not included in the OS, these controls should at least be available through a small, easily available, stable runtime library, instead of the huge rtls of some of these toolkits, which are subject to frequent updates
* these tooklits are often too much oriented to a single language (especially C++)
* they are often overkill if you just need a toolbar or a split window

Moreover, if the base OS included an updated library of controls (well integrated, well debugged ans stable) the ported tookits could build upon the native controls instead of reimplementing them.

Help:Contents

2005-10-19T06:51:36Z

Cris: Removed spam

Main Page

2005-10-19T06:49:31Z

Cris: Removed spam

__NOTOC__

Welcome to the Wiki at netlabs.org. You will find a lot of interesting information about OS/2 and [http://www.ecomstation.com eCS] on this page. 
If you are interested in joining the '''community mailinglist''' please have a look [[Mailinglists | here]]!

== Roadmap ==
Where are we now and where could we go. Open for discussions.

*[[Ideas]] - This is so far a random collection of ideas and stuff we have in our heads and which probably is worth creating a project for.

* [[Community]] - Discussions about the netlabs.org community, website, and so on. Complain here :)

*[[Fundraising campaign]] - Projects that could be realized, support your favourite one!

*[[XWorkplace]] - XWorkplace Future Plans and Ideas

*[[DOSBox Port]] - DOSBox Port for OS/2-eCS Project

*[[Odin]] - ODIN Project todo and Ideas

*[[eSchemes]] - eComStation WPS-based look&feel system

*[[Mr2ice]] - MR/2 ICE is a full featured OS/2 native mail and news client.

== Shop ==
We do have a shop for shirts and more ... [http://shop.netlabs.org shop.netlabs.org]! Prices include a small extra to support netlabs.org's future... (Does anyone know how to add an image here :-P ?)

== New Logo and Redesign ==
* [[Redesign]] - The new logo is choosen and a first and hopefully final draft for the new site layout has been created - check it out ;)

== Development ==

NOTE: This section should not be extended anymore. We reloaded the [http://www.edm2.com EDM/2 magazine] and we recommend to put all developer stuff in there. This wiki is a mess at the moment and we will clean that up one day and migrate the stuff that makes sense to EDM/2. Thanks!

This section contains hints and tricks and descriptions of undocumented
stuff. Undocumented means there's no official documentation or the
documentation (for example included on DevCon CDs) isn't available to
the public anymore. But DON'T JUST COPY any documentation you may have into the Wiki. Keep in mind it's copyrighted!

* [[Undocumented stuff]]
* [[Mozilla]] - some stuff regarding building Mozilla on OS/2
* [http://www.edm2.com/index.php/SDL SDL] - some tips & tricks about how to port applications using SDL to OS/2
* [http://www.edm2.com/index.php/How_to_program_for_the_WPS WPS] - how to program for the [http://en.wikipedia.org/wiki/Workplace_Shell WPS]. Note: the german Wikipedia may have more information about the WPS. Go [http://de.wikipedia.org/wiki/Workplace_Shell here].

==netlabs.org Community==
===Resources===
* [http://www.netlabs.org netlabs.org] itself, the main page :-)
* [[IRC server settings]] - chat with netlabs.org coders
* [[Mailinglists]] - support for our projects per mailinglist or news-reader

===Developers===
We also hire a developer at the moment, to show you what he does we provide a small weekly list of his progress on various projects.
*[[Vladest]]
*[[Samm]]

===Publicity===
* [[Presentations]] about netlabs.org (prepared for Warpstock Europe)
* [[Logos]] in different resolutions, free to use

==OS/2 and eCS resources==
===Drivers===
*Visit http://www.os2warp.be if you want to know if your hardware is supported.
*See a [http://www.ecomstation.it/pido2/home/mircomir/fixpak.php?lang=en driver list] generated from eCSoft/2 database.

===Software===
For software have a look here:

* http://hobbes.nmsu.edu
* http://en.ecomstation.ru/apecs.php
* http://www.ecomstation.it/ecsoft2/
* http://www.unixos2.org - ported *nix tools. A little bit cumbersome to find stuff there but nevertheless worth the effort

===Programs===
How to use specific programs, HowTos, FAQs etc.

MR/2 ICE [[mr2ice]] is a full featured OS/2 native mail and news client.

==netlabs.org Servers==
===ToDo's & History===
This is the list of tasks for netlabs.org Webservers & the history of what I (ktk) did
*[[netlabs.org]]

===Mail account===
Some information for those who own a mailbox at netlabs.org
*[[netlabs.org Mailing]]
===Admin Guide===
So far it's more or less just me who does all the work on netlabs.org webpages and this somewhat sucks because like this a lot of stuff depends on my lazyness. The following document explains the tasks necessary to create a new project at netlabs.org, including setting up CVS repositories, creating webpages and so on. I hope that I will find some volunteers one day who help me on doing that.
*[[Admin Guide]]

== What is a Wiki ==
*If you don't know the concept of a Wiki yet we recommend you to have a look at the [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide MediaWiki User's Guide].
*If you just want to add some content without much reading read the [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide:_Editing_overview#The_wiki_markup Markup Overview].
*If you have no clue about Wiki you might first check [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page how to edit a page].

Ideas

2005-10-13T13:48:22Z

Cris: /* Desktop Search Engine: Swish-e */

ESchemes

2005-05-19T12:00:31Z

Cris: /* OS Skinning/Schemeing */

== OS Skinning/Schemeing ==

(Files for the eSchemes project can now be found at the [http://betazone.ecomstation.com eComstation Betazone])

While I think that the look is not very imporant in an OS design, we have to recognize that the desire/need to change the interface to match the user's taste have had a major role in the design of recent GUIs.

Recent eComstation releases (1.1 and 1.2) are getting better at handling this, with the possibility to change the standard icons, change some of the GUI controls (system box, max/min/hide/close buttons), change the titlebar, change the pushbuttons, check-boxes and radio-buttons.

All in all, it is a pretty comprehensive list of possible interface changes, but we're still far from the competition.
Adding some third-party tools, we can get rid of the standard gray color, add some transparency, change window borders, etc.

So, where's the problem?
* We need FAR TOO MANY different pieces of software to change the interface
* Every piece of software does its own thing, and many times there are conflicts
* Different pieces of sotware choose to do the same things in different ways
* You have to reboot to activate most of the changes
* We have no means of using non-square windows

Let's see how many pieces of software one may need in order to change the interface in a way that at least resembles the capabilities of other platforms:

* The standard scheme palette. This is pretty limited. It can't change all the colors, and you can't add more schemes to the palette. ''(Cinc: You may create new sheme palettes to overcome the limitation.)''
* SysColors (http://os2.ru/articles/dev/prog/syscolors/index.phtml.ru) This can change more system colors, but has no support for saving schemes. BTW, the source is available.
* eStyler or Styler/2. While Styler/2 should support a superset of eStyler functions, there are things that eStyler does (such as replacing buttons) but Styler/2 don't. But Styler/2 supports on-the-fly changing of title-bar controls, while eStyler doesn't. So one can't trade eStyler for Styler/2 (or the other way around) without losing some functionality.
* ColourManager/2. This one supports changing of all (but the most hidden ones) colors in the interface, and (once again) changing title-bar controls and other buttons. This one requires a reboot, too. And uses a different format for the resources from eStyler. Fortunately, CoulourManager/2 is now available in source-code to eCS developers.
* CandyBarz (Netlabs). This is the most advanced skinning application for OS/2, but it is less stable than his counterparts, it is somewhat buggy and it's not developed anymore. It is opensource though, so anyone can in theory restart development. I'm under the impression that eStyler's (or ColourManager/2) way of changing controls is more stable and less error-prone ''(comment by Cinc: eStyler does the control changing the same way CandyBarZ does it AFAIK)'', but it may only be that CandyBarZ is quite old now. Can do most of the things that the other pieces of sotware do and more, and it does it on-the-fly.
''Cinc: CandyBarZ is/was work in progress with *a lot of* experimental stuff. So no wonder it's not too stable ;-). As a kind of testbed it showed how some things are better not done for such a theming engine. Well, I know what I'm speaking about here. I was one of the main coders. Transparency, custom controls, bitmaps in frames and controls are my childs.''
* Icon themes. Changes all of the standard icons of the OS. It is evolving in the direction of being a full replacement for Stardock's Icon Schemes, which was more powerful but it is closed-source and development has stopped. Another problem is replacing native term ''scheme'' by windows term ''theme''. We need common treminology.
* Window Themes. Changes title-bar controls (like eStyler) after a reboot. Changes radio-buttons and check-boxes, but NOT pushbuttons (you need eStyler or CandyBarZ for this). And also have term ''theme'' instead of ''scheme''.
* CandyFolders (Netlabs) to add some transparency to folder backrounds.
* NPSWPS to add drop shadows to windows, and animation effects.

See? If one wants to change everything that could be changeable he needs 9 pieces of software, with many overlapped functionalities. And in the end, some pieces of customization are still missing.

Given this situation it is impossible to develop/distribute comprehensive themes/skins for our OS, and give the user a hassle-free, auto-installing package.

What we need is ONE program capable of changing ALL of the resources, or at least the sum of those that are presently changeable with all the diverse software pieces. If it can't be done without rebooting, this software should at least have a very good previewing function.

To sum it up:

* Change ALL the colors (like ColourManager/2, SysColors)
* Change title-bar controls (eStyler and CandyBarZ)
* Change pushbuttons (eStyler and CandyBarZ)
* Change check-boxes and radio-buttons (Window Themes, ColourManager/2, CandyBarZ)
* Change (indipendently, or remove some of the) window borders (CandyBarz)
* Change icons (Icon themes)
* Change titlebars (eStyler, Styler/2, ColourManager/2, CandyBarZ)
* Globally change desktop/folder backgrounds (ColourManager/2) ''(Cinc: this one I don't understand. Please clarify.)''
* Transparency (CandyBarZ + CandyFolders)
* Animation and drop-shadows (NPSWPS)
* Subclassing/substituting the remaining controls (scroll bars, etc) (CandyBarZ)
* WISH: different title-bar controls for active/inactive windows ''(Cinc: CandyBarZ or are you speaking about titlebar buttons? -- Cris: yes, I'm speaking about buttons)''
* WISH: non-rectangular windows. There are at least two different libraries for this:
** ShapeWindow (LGPL - http://www.sra.co.jp/people/akira/os2/arch/shpwn200.zip)
** TileWindow (LGPL - http://hp.vector.co.jp/authors/VA001398/os2/softwares/libraries/twtk1_1_4bld14.zip)
''Cinc: these are awfully slow. Won't be possible without diving deep into PM (if possible at all)''

''Cris: don't think so, at least not if it isn't overused. With recent HW, the shape-window extensions are quite fast; moreover, if one uses it only to have rounded borders on windows (like WinXP or many Linux distros default scheme) the number of PM windows created is not boosted very much.''
* WISH: Ability to save everything as one scheme, easily distributable (''Cinc: CandyBarZ did this to some extent)''

Any taker? ;-)

''(Cinc: I've got some time this weekend, just wait till monday ;-D)''

''(more comments below)''
----

I (prokushev here) want to say I am already working in this area (since summer 2004. I recieved ColourManager/2 sources in june or july, don't remember now ;)). Project consist of different pieces:

# Command-line tool which will apply scheme. Goal is to establish scheme file format and create core of software.
# WPS classes for scheme file and schemes preview folder. Uses commandline tool.
# PM scheme editor (as replacement of standard Scheme editor) with preview function.
# PM classes for "without rebooting" controls change.

Cinc: is this source available somewhere? What's the license?

Prokushev: No. Closed source, most probably, because project aimed by eCoSoftware. Most probably sources will be available to MenSys also (this is not under my control). Actually, I looked closely to CandyBarZ and most of things already there ;). May be the product will be based on it (as result it will be under GPL). Only thing I'd like to see - closer integration with WPS.

Cinc: CandyBarZ *IS NOT* licensed under the GPL! and it will not, otherwise I'll pull all my code from it which will not leave too much of a product...).

Prokushev: CandyBarZ already contains GPLed code. As a result the whole package become GPLed. You can't do anything with it.

Most problematic part is PMMERGE.DLL fixing (we need to fix 2 functions: WinSetControlColors and WinQueryControlColors). I have no idea how to do this (ColourManager/2 method of control colors fixing doesn't solve the problem because it breaks the original logic and drops a lot of features).

Cinc: why do we need to fix these functions? Please elaborate.

Prokushev: Ok. Let's play the game. Any control (in original PM logic) must get color in following order:
# PresParam; if none then
# Local Contol Colors table (via winqurycontrolcolors); if none then
# Global Control Colors table (via winqurycontrolcolors); if none then
# SysColor; if none then
# Hardcoded color.

Actually, to allow user to have control on colors step 5 must never be performed. This is as everything should work. If such logic is right, then the standard Scheme editor would allow users to change any color via system colors. If no such logic then the user would need to edit EVERY controls' color. LOTS of colors.

But things doesn't work, because WinSetControlColors can't change some color values. Ideally, WinSetContolColors should allow to set ANY value to a SYSCLR_* constant. Actually, some colors can be set to SYSCLR_* values, some can only be set to RGB_* values, and some can't be changed at all (hardcoded). As a result we can't control ALL colors, only a subset. ColourManager/2 partally solves the problem by setting CCI table to RGB_* values. But... If you use CM/2 then you have no d'n'd sopport in scheme palette, and you need to reboot the system to set ALL colors to new values. Also you have lot of small color problems with application.

We need a complex solution of this problem. Actually, the scheme must be changed on the fly, without any reboot. To do this, we need WC which allows us to set control bitmaps on the fly (like eStyler/2 does), we need to restore original Control Colors Table logic (replace PMMERGE functions) and lot of other small steps.

And, main thing, we must remember about the WPS. At the present time eCS includes various utils which replaces WPS functionality and, as result, we have different 'Properties dialogs' from various programs (as example, eClock has such problem) (''Cris: isn't this due to the fact that eClock is created with Syibil? Sibyl controls are not real PM controls... they are only lookalikes. Prokushev: No. It's because no original WPClock class was replaced to call eClock config tool. As minimum. As maximum eClock configuration must be done via WPS class at all. As example. If I'll replace standard Scheme editor by my own (which written on Sibyl) then I need replace original SchemeEditor class to call my editor. So all thing will be done ok. Any program which will call SchemeEditor class will actually call new Scheme Editor)''. If we replace WPS classes by PM utils then 'WPS wrapper' must be created, at least.

Regarding the 'Icon Theme' tool: actually, we need something more complex, to allow us to change ANY attribute of WPS objects, not only Icons.

Personally I'm not interesting to work on this project 'totally for free' because I have interest in other areas.

Cris: I would be interested in helping with some money, if Adrian considered this to be added to the "funding" made by Netlabs.

Prokushev: Project started. Search alpha versions at eComStation Betazone. Help I actually need:
# I need some approach to patch PMMERGE.DLL to fix/replace 4 functions.
# Testers ;)

Cris: I am interested in being a beta tester. I'll download the alphas ASAP.

Regarding how to patch PMMERGE: you can use the approach used to apply caching to the flushing of user and system INIs. That is: you rename the original PMMERGE to something else (internally also); then you build a DLL called PMMERGE, which intercepts ALL of the original PMMERGE functions and redirects them to the original (renamed) DLL, but for the 4 functions you want to replace/fix. Once you've done your things in those 4 functions, you have the choice to return to the caller (replace) or to forward the call to the original PMMERGE DLL (fix).

Prokushev: Actually, this approach will not work for internal function. As result, Until ALL controls will be replaced, no correct scheme colors.

Cris: I am having some problems with the alpha of eSchemes. I wrote a couple messages on the forum, but got no reply till now. Could you please monitor the forum, Prokushev? I know the forum still isn't in the forums list, but you can access it directly via the link in the docs.

Prokushev: Monitoring already ;)

Ideas

2005-05-18T09:52:34Z

Cris: /* OS Skinning/Schemeing */

Note: This page is extremely unorganized like most of my todo-lists I do at home. Feel free to add your ideas here. We hopefuly organize that a bit better one day...

* eComStation is very nice in my opinion (ktk speaking here :-) but updating it is still a major pain in the ass. We need a easy and stupid proof way updating it. And *please* in a non-GUI version too!

==MultiMedia Improvements==

There seems to be two ways to achive Multimedia Improvements

===Enhancing the native MMOS2 Infrastructure===

There should be goals like:
* Complete Open Source Replacement of all the MMOS2 files
* Create a Bundle package of all Open souce CODECs
* Re-energize the [http://www.reamined.on.ca/doconnor/mmos2/ OS2 Multimedia Infrastructure Project]
* Write an IO Storage procedure for proper streaming support, so the CWMM classes could handle more than just Icecast streams (the current one fails because it doesn't get the expected header which prepends the stream)
* Add Storage IOProc support to Format IOProcedures which doesnt' supports them (like JPEG I/O, PNG I/O, MP3 I/O, OGG I/O, Vorbis I/O, etc.). ??? Every format I/O proc supports storage I/O procs out of the box. Otherwise you couldn't use them because the access to the filesystem is implemented using a sorage I/O proc. Strictly spoken the format I/O proc isn't aware of storage. MMOS2 handles the stuff. !!! Not every FIOProc uses SIOProc. Above IOProcs uses direct file access instead of SIOProc. FIOProc MUST be written with SIOProc support in mind.

The projects that can be integrated are:
* [http://www.reamined.on.ca/doconnor/timidity.html TiMidity MCD for OS/2] (midi)
* [http://r6.ca/MMAudioPak/ MMAudio Pak 2 for OS/2] (MP3, Vorbis, FLAC)
* [http://www.os2world.com/cdwriting/mmclasses/mmclassesmain.htm CW-Multimedia classes] ''(Prokushev) Unfortunately, CWMM Classes not open source. As result, can't be extended. Another problem is no IDL files for CWMM Classes or MMOS/2 Classes. As result, classes can't be extended. Only solution is restore IDL files from IR or using class information from MMPARTS.DLLs. Or ask Chris to open source his classes or, at least, to publish IDL files''
* Quickmotion (Quickmotion's Tom Harding told there there could be a change to open source it if we find an developer for it

===Enhancing NON MMOS2 related Multimedia (like WarpVision) ===

This seems something that Vladest might tackle with WarpVision: [http://www.videolan.org/vlc/ VLC media player]

==UnixOS2==
There is a ports-like system for UnixOS2 in the works at the moment but I'm not really happy with that one and I doubt that we will be enough people for maintaining all that stuff ourself (dependencies and so on...).

When I use Linux I often work on Gentoo, which has really the best source-based ports system I've ever seen (and I know BSD too so it's not the only ports-system I know ;).

At the moment the ports system is quite Linux oriented but at the moment there is a complete rewrite of the portage-system in progress. They call it [http://www.gentoo.org/proj/en/portage/portage-ng/systemspec.xml portage-ng]. One of the targets is cross-platform support for stuff like BSD or MacOS so I really vote for OS/2 support as well :). It's too early at the moment to really have a look at it but we should definitely do that as soon as possible.

The discussion about portage-ng is [http://news.gmane.org/gmane.linux.gentoo.portage.devel here]

Update September 04: I talked to the guys who work on portage-ng. It looks like portage-ng is not really dead but at least progressing very slowly. Meanwhile, a group of MacOS X users created a [http://www.metadistribution.org/macos/ portage for MacOS X] so it looks like it does work on BSD-like systems too. So that changes the todo list a bit:

TODO:
* set up a basic package with latest GCC and Innotek LIBC. The basic package contains all tools and libraries needed to compile Python with Innotek LIBC.
* as soon as Python compiles we need to wrap together <tt>emerge</tt> on OS/2. This might get a bit tricky because it also heavily relies on shell scripts. So whatever shell we gonna use, it must be as close as possible to bash (if not bash anyway, it looks like the stuff is not that portable to other shells).
* once we get portage to work properly we need to create ebuilds for the basic libraries. At the first stage there is no rsync server needed to do this but it will definitely get handy sooner or later (shouldn't be a problem but needs to be set up).
* implement more and more ebuilds for all kind of packages
* and in a later stage create a bootstrap-package that also compiles GCC and all other tools (that won't be an easy task :)

==PM==
We need to port some toolkits or finish the current ports:
* qt - more soon, looks good
* GTK2: Samm proposed to work on it, will give an estimate of time soon
* wxWindows: Port quite up to date but the PM parts in it are definitely not yet done or very buggy -> fix (probably dmik)
* SWT: will be done when Eclipse is done -> dmik

Also, it would be nice to have updated public PM controls. This should be done with one DLL subclassing these public controls, and extending and/or fixing their behaviour. Things to fix/implement should be:
* Remove 64K limits in some of the controls
* Create extended MLE control (understanding HTML tags maybe?)
* Automatically drop-down list of combobox, when clicked (like DragText does)

==[http://www.edm2.com/index.php/SOM WPS] (Workplace Shell)==
* replace background image dialog, it should be possible to point that to another directory than \os2\bitmap
Note: This is already possible and a lot of software to make things like
slideshows out of it exists also. - lp

* replace the file dialog, Gnome 2.6 does that '''very''' nicely (screenshot will follow).
* replace the Icon rendering, should be able to handle stuff like PNG as well and in best case also SVG
Note: Don't think we must replace Icon rendering. But adding MMPM IO procs for PNG and SVG is good idea.

Note: most probably PNG IOProc will be included in next eCS version -prokushev

Note: File dialog is not a WPS issue. But it can be implemented via WPS class. I consider it is good idea to move to object world. - prokushev.
Can you describe that a bit with more details prokushev? - ktk

Yes. File dialog placed in PMCTLS.DLL. We can do such trick:

# move PMCTLS.DLL to PMOLDCTL.DLL
# write new PMCTLS.DLL with forwarders to PMOLDCTL.DLL
# In WinFileDlg (new PMCTLS.DLL) we must check, is WPS exist? If exist, then just create WPS object (with name like WPOpenFileFolder or something like this) and monitor it (wait result from it). As result our open file object can be replaced and/or extended by standard SOM features. If no WPS exists then call or old WinFileDlg or our own implementation of open file dialog (for systems without WPS)

WPOpenFileFolder is subclass of WPFolder with changed reaction on open objects in it. If object is folder then go deep. If object then close WPOpenFileFolder and notify our new WinFileDlg. Comment: You can't do that with a WPFolder subclass because it expects every inserted object to be an existing object. So you will end with copies of each object. You have to create something different or override *a lot of methods* in your WPFolder subclass to get this done properly. And a lot of probably means every method introduced by WPFolder.

(Cornelis): One more problem with that method: An application can call WinFileDlg providing an own dialog resource and handling the dialog messages in its own way! I cannot see how this case could be handled with the WPS method. The only "solution" I can imagine at the moment: Also check for custom resources or custom dialog function and if they exist, do not call the WPS file dialog. I don't know how many applications use these features - but I am afraid that quite a lot do it...(!??)

Something like this.

And yes, it can be part of XWP.

BTW, how about move Doodle Screen Saver to XWP? ;)

BTW 2 : Why dont add also LSwitcher to XWP ?

Cinc: I oppose the idea to add every single utility in the world to XWP. Maintaining the XWP code is difficult enough right now because of complexitiy. Adding Utilities to XWP means they are not available for people not using XWP (for whatever reason).

=== What about Backup / Restore / Portability of WPS objects !?? ===

(Cornelis): One serious disadvantage of the WPS gets even worse with all new and derived classes: There is no way to save the WPS with its "objects" in an open format in order to port them to another system or to a new installation! I know there are programs like Open Desktop and other WPS backup and restore tools, but they all only work with a set of "normal" objects, like folder objects, program objects etc., ask their properties and store them somehow. But neither would these tools find any newly defined objects (like already the "Workframe" objects of VAC/C++ 3.0), nor would they save any extended features (like the content of the "Environment" settings page of XWP extended "program objects").

This is a conceptual problem, because in an "object oriented world" any saving/restoring program should not have to know anything about the properties of the WPS objects, but just have to call a standard function that has to be defined for each and every object: "getAllProperties" or such. And then restore it with the corresponding "setAllProperties" call. While all derived classes would have to implement versions of these functions.

Without knowing any internal details of the WPS I assume that such functions do not exist, so their introduction would not be easy. Would it be possible at all? Did anybody ever think about such an issue?

Cinc: No there isn't such a function. Nevertheless it's possible to emulate it by overriding wpSave*() methods in one base class and telling the class to save the internal variables by calling wpSaveImmediately(). In the wpSave*() override you can catch the information. Restoring the data on recreation is more difficult, though, but there may be a similar way.

==Porting Windows 32 Applications with ODIN Tutorial==
It would be nice if there is a tutorial on how to use odin to port open source win32 apps to OS/2.

==Drivers Development Skeleton==

A skeleton driver that can be used for writing drivers. More importantly, a hands on/hand holding tutorial for writing drivers. Writing drivers is a daunting project, but is necessary for OS/2 to survive in the long run.

==USB Drivers==

*PCMCIA driver for USB2.0 cards for laptops. Right now, laptops with USB1.0 built in cannot be upgraded
to USB2.0 with PCMCIA cards.

*USB driver for enabling RSJ to talk to external CDRW drives.

Note: It is better to make some changes in OS2CDROM.DMD code, so that it will allow to issue SCSI commands without need to open device. I made some checks, and found that it is possible to get CDROM Id control, open/close tray via OS2CDROM SCSI interface, but drive must have loaded media for the first to obtain device handle.

==External list==
* [http://www.os2bbs.com/os2news/OS2Wishlist.html The Warp Wishlist] maintained by [[Kris Lake]].

==Open Source OS/2 Strategy and Follow up of Open Components==

An strategy with the final goal to have OS/2 open sourced. 
More than a development project it had to be an integration project of open source software for OS/2, like an information site to follow up all the open source replacement for OS/2 closed components. On this site we will list the open source project available for OS/2 and the closed component that is replacement.
 
Ex: 
* Newview.exe -> replaces View.exe -> License GNU GPL
* XWorplace
* HandyFTP
* Doodles Screen Saver
* lSwitcher
* etc, etc

Plan to make replacement for:
* command line programs like "xcopy.exe, attrib.exe, etc" (some tools already exists as part oof osFree project)
* Enhanced and replacements of CMD commands (some tools already exists as part of osFree project)
* Replace of some closed DLLs (some DLLs already exists as part oof osFree project)
=== Open Source OS/2 Distribution ===

Build a OS/2 distribution with open source replacements on it. Of course that many people says it is too hard, but we need to start with something. It can start creating an OS/2 distribution that is focused in Open Source components, and bundle on it, dssaver,xworplace,lswitcher, xfree, emx, warpin, usbres, etc. (bitmaps, icons and drivers too)

To don't start it as a too complex project it can be something similar to the UpdCD project, that requires license of Warp 4.52 or eCS to build an updated image. 
We can ask help from UpdCD project to create an install image (that will require the OS/2 CD) that contains open source software on it replacing the closed components. And keep evolving this project and replacing components until in some years it can work without licensing OS/2 from IBM.

One may think about an open source distribution you simply install over an existing installed system

=== osFree project ===

I want to remember to all about existing of osFree project (site at [http://www.osfree.org]). At the present time it is collection of open-source replacement of closed OS/2 components. It includes:

* Customized 4OS2 as cmd.exe replacement (mostly integration to common build system and moving 'not must have' commands to stand-alone executibles)

Remark (Cornelis): But 4OS2 is not Open Source!?? It's Freeware AFAIK!(?) Otherwise: Why not consider the 32-bit Command Line, together with the "OS/2 command line utilities" by Jonathan de Boyne Pollard [http://homepages.tesco.net/~J.deBoynePollard/Softwares/] ? These aren't Open Source either (also Freeware), but very solid and mainly focused on extending the CMD.EXE functionality and make it fully 32-bit. Extensions are the tools. (Why 32 bit? Well, I use it together with make, which "feeds" the command line interpreter sometimes with commands of several thousand charecters - much more than CMD.EXE would ever digest!) Furthermore: 4OS2 is just "set free abandonware", while there is still a person behind the 32-bit Command Line Interpreter...

Remark (LightElf): 4OS2 IS Open Source (GPL as far as I remember). Now it hosted at Scitech.

(Cornelis:) This is what I find at Scitech: [ftp://www.scitechsoft.com/devel/4os2/4os2304f.zip] But that contains just binaries! This is not to contradict you; I only didn't ever hear about an Open Sourced 4OS2, and still I cannot find it where you say it is!? But please correct me! For the rest: Open Source or not - I would still point out to not forget the "32 bit command line interpreter"! (Maybe the status could even change if there is a good point being made by the right person at the right time??)

(Prokushev): 32-bit comandline interpreter depends on 32-bit vio/kbd API. If no 32-bit API then no 32-bit CMD ;) If vio/kbd will be implemented then just recompilation of 16-bit CMD.EXE will move CMD.EXE to 32bit world ;) Nothing hard here.

(Cornelis): The "32-bit commandline interpreter" and the "OS/2 commandline utilities" are '''existing''' freeware products, running on '''existing''' OS/2 or eCS systems, so it's even easier! The only "problem": it's freeware, not open source.

(Prokushev): And "32-bit commandline interpreter" is actually just uses CONAPI which just wrapper around old 16-bit API. Don't see any differents with stnadard 16-bit CMD.

(Cornelis): There are '''a lot''' of advantages! Please go and '''LOOK AT IT''' and '''READ THE DESCRIPTIONS''' before you make your statements! [http://homepages.tesco.net/~J.deBoynePollard/Softwares/cmd.html] Actually besides all advantages for the user (like no more limitations in command line length etc., while maintaining the most possible compatibility with CMD.EXE) it indeeds is NOT a wrapper around the old 16-bit API, but it uses the "32-bit Unicode Console API" [http://homepages.tesco.net/~J.deBoynePollard/Softwares/conapi.html] which replaces completely the old 16-bit API functions you mention.

(Prokushev): "32-bit Unicode Console API" is wrapper around old 16-bit API. It closed source. 32-bit CMD is also closed source. And uses 16-bit wrapper. Actually, CONAPI.DLL uses CON3216.DLL which IS wrapper.

(Cornelis): For me this "discussion" is getting a bit irrational now: I never intended to engage in such a stupid "faith war" for a piece of software!

But ok, if it's so important: Several levels "further down" from the 32-bit command interpreter you do indeed still hit 16-bit functions. But what's the problem with that? As long as there are 16-bit drivers this will always be the case! The important points for me are:

1. The 32-bit CMD offers a full 32-bit interface for programmers, which is designed after a later abandoned 32-bit interface by IBM. So if any programmer would use that interface, all options are open to later replace the 16-bit code two levels "further down" later on, no changes being necessary to the software.

2. The user doesn't suffer from any old size limits any more either, like a limited command line length.

3. The command syntax is very closely compatible with the CMD.EXE syntax, and where it is changed in order to make it more consistent, these extensions can be optionally turned off.

For these three reasons the 32-bit command interpreter is more future oriented than a thing like 4OS2: That one has nice extras, but is much less compatible with CMD.EXE, which generates problems in certain cases. A high degree of compatibility even in details has many advantages, because software developers or script writers etc. can rely on a specific surrounding. Keep in mind all the troubles we have already with the two REXX "flavors" on current OS/2 systems: A developer can NOT rely on an existing "classic REXX" or "Object REXX" surrounding! This would be the same with 4OS2 becoming part of a "new OS/2 standard".

Concerning the source license: 32-bit command interpreter is freeware, not open source. 4OS2 was claimed to be open source above, but nobody could until now give us an URL of the sourcecode, so this looks at least dubious: It seems that 4OS2 is also just "freeware", not open ource.
Cinc: as LightElf already pointed out 4OS2 is open source. There're even different versions floating around made by people who grabbed the source and fixed some bugs. No I don't have the URL handy. Google should help there.

And only for that reason I asked to consider also the 32-bit command interpreter, besides of course also 4OS2.

(Cristiano): 4OS2 definitely '''IS''' open-source. If you search on hobbes, you'll even find two different and somewhat incompatible code branches. One is the "official" Scitech branch, the other is a branch made by some private individual, starting from the original JPSoft source code (i.e. not building on Scitech code). If you want to know better, ask Michal Necasek (SP?) of Scitech. He'll tell you what's the current state of 4OS2 code, where you can get the source, and more.

* ReginaREXX as REXX replacemend (still missed 16-bit wrappers). Subject to change to Open Object REXX.
* Replacement of many command-line tools (like attrib, ansi, chkdsk, etc.). Mostly without error handling.
* THE as TEDIT replacement
* Some forwarder DLL's (like VIOCALLS, MOUCALLS, etc.)
* FreePM sources (because FREPM seems to be discontinued)
* other things.

CVS controlled by ktk, so anyone free to contact with him to have access. osFree site can be used for above things. To do it just contact me (prokushev here).
But another general thing is it's time to make one general open-source components repository with common build environment with general goal to create open-source OS/2.
And, again, osFree can be good place for it. osFree not limit in languages (except common build environment). C, C++, Fortran & Pascal currently in use. Perl is coming (REXX compatible API for Perl, if possible, is planned).

Really, main goal of osFree subsection is to point above project already exists.

Insted of talking HOW OS/2 must be open-sourced (from the kernel to WPS or from WPS to the kernel) I propose (prokushev here) just start collect already existent things. Thing happen if try to do them.

=== Kernel Free (OS/2 Kernel with License GPL) ===

To release to the kernel of the system on the part of IBM and other companies.

Cinc: why GPL?

BTW using a GPL kernel wont allow to create *any* closed source software because you're not allowed to link it to GPL code dynamically. So much for the GPL hype...

==WarpModem==

The general idea will be to make a commun interphase (like Windows 95) for analog modems on your OS/2 system called "Warp Modem". Programs that uses the modem will had comunicate to "Warp Modem" to get the configuration of the modem and it status. This will be useful for OS/2 user, because he will not configure the modem on each OS/2 application that uses the modem.
 
What will be good is to have a "Modems" icons inside the OS/2 System Setup folder.

http://www.os2world.com/pictures/articles/SystemSetup.jpg

This program will show us the modems that are configured on our system. If the systems has two ore more modems it will shows us all modems that we had configure.

To make this configuration we can start using the Doug Bissett's modem configuration list (http://www.os2warp.be/modems/modem.lst)

On this menu we can see the "Add...", "Properties...", "Delete..." and "Test..."

http://www.os2world.com/pictures/articles/Warp%20Modem%20GUI.jpg

Add button will show us the instruccions to add a new modem

http://www.os2world.com/pictures/articles/Modem%20Config.jpg

(picture taken from ATT Dialer)

The "Test..." button will be a tool to test it is working. A good idea is the one from ATT dialer too.
http://www.os2world.com/pictures/articles/Modem%20Tester.jpg

(picture taken also from Att Dialer)

"Properties..." will show us something similar to the "Add" window to change the modem configuration.

I think "ADD" should support "Installing" the modem using the windows "drivers" i.e. the inf-files which contain the AT seq. used for certain operations which an application can then query or call via an published API.

"Remove..." will ask us for confimartion to delete that modem

And the app should seperate the physical modem from multiple configurations one could have.
i.E. a Modem has a max speed of 36.000 baud but I should be able to create a fax configuration with would setup the modem to lets say 14.400 etc.

Other tools

So, what kind of software will be good to integrate with Warp modem ?

All programs that used a analog modem can take advante of this. Developers of Phone dialers, Fax, Internet Dialers, Voice Phone, RAS, BBS software..etc..etc..

http://www.os2world.com/pictures/articles/Modem%20Selector.jpg

Documentation

This project will need a good documentation so developers that wants to uses the OS/2 Warp Modem configuration can access it easily for their phone/fax/modem applications.

Wish list

# Open Source Project / free license GNU GPL.
# C++ or Java development.

This is just a development idea, there is nothing coded on this direction. The pictures in some cases are just fake to explain the posibilities of this project.

== OS Skinning/Schemeing ==

Project files can be found at eComstation Betazone.

While I think that the look is not very imporant in an OS design, we have to recognize that the desire/need to change the interface to match the user's taste have had a major role in the design of recent GUIs.

Recent eComstation releases (1.1 and 1.2) are getting better at handling this, with the possibility to change the standard icons, change some of the GUI controls (system box, max/min/hide/close buttons), change the titlebar, change the pushbuttons, check-boxes and radio-buttons.

All in all, it is a pretty comprehensive list of possible interface changes, but we're still far from the competition.
Adding some third-party tools, we can get rid of the standard gray color, add some transparency, change window borders, etc.

So, where's the problem?
* We need FAR TOO MANY different pieces of software to change the interface
* Every piece of software does its own thing, and many times there are conflicts
* Different pieces of sotware choose to do the same things in different ways
* You have to reboot to activate most of the changes
* We have no means of using non-square windows

Let's see how many pieces of software one may need in order to change the interface in a way that at least resembles the capabilities of other platforms:

* The standard scheme palette. This is pretty limited. It can't change all the colors, and you can't add more schemes to the palette. ''(Cinc: You may create new sheme palettes to overcome the limitation.)''
* SysColors (http://os2.ru/articles/dev/prog/syscolors/index.phtml.ru) This can change more system colors, but has no support for saving schemes. BTW, the source is available.
* eStyler or Styler/2. While Styler/2 should support a superset of eStyler functions, there are things that eStyler does (such as replacing buttons) but Styler/2 don't. But Styler/2 supports on-the-fly changing of title-bar controls, while eStyler doesn't. So one can't trade eStyler for Styler/2 (or the other way around) without losing some functionality.
* ColourManager/2. This one supports changing of all (but the most hidden ones) colors in the interface, and (once again) changing title-bar controls and other buttons. This one requires a reboot, too. And uses a different format for the resources from eStyler. Fortunately, CoulourManager/2 is now available in source-code to eCS developers.
* CandyBarz (Netlabs). This is the most advanced skinning application for OS/2, but it is less stable than his counterparts, it is somewhat buggy and it's not developed anymore. It is opensource though, so anyone can in theory restart development. I'm under the impression that eStyler's (or ColourManager/2) way of changing controls is more stable and less error-prone ''(comment by Cinc: eStyler does the control changing the same way CandyBarZ does it AFAIK)'', but it may only be that CandyBarZ is quite old now. Can do most of the things that the other pieces of sotware do and more, and it does it on-the-fly.
''Cinc: CandyBarZ is/was work in progress with *a lot of* experimental stuff. So no wonder it's not too stable ;-). As a kind of testbed it showed how some things are better not done for such a theming engine. Well, I know what I'm speaking about here. I was one of the main coders. Transparency, custom controls, bitmaps in frames and controls are my childs.''
* Icon themes. Changes all of the standard icons of the OS. It is evolving in the direction of being a full replacement for Stardock's Icon Schemes, which was more powerful but it is closed-source and development has stopped. Another problem is replacing native term ''scheme'' by windows term ''theme''. We need common treminology.
* Window Themes. Changes title-bar controls (like eStyler) after a reboot. Changes radio-buttons and check-boxes, but NOT pushbuttons (you need eStyler or CandyBarZ for this). And also have term ''theme'' instead of ''scheme''.
* CandyFolders (Netlabs) to add some transparency to folder backrounds.
* NPSWPS to add drop shadows to windows, and animation effects.

See? If one wants to change everything that could be changeable he needs 9 pieces of software, with many overlapped functionalities. And in the end, some pieces of customization are still missing.

Given this situation it is impossible to develop/distribute comprehensive themes/skins for our OS, and give the user a hassle-free, auto-installing package.

What we need is ONE program capable of changing ALL of the resources, or at least the sum of those that are presently changeable with all the diverse software pieces. If it can't be done without rebooting, this software should at least have a very good previewing function.

To sum it up:

* Change ALL the colors (like ColourManager/2, SysColors)
* Change title-bar controls (eStyler and CandyBarZ)
* Change pushbuttons (eStyler and CandyBarZ)
* Change check-boxes and radio-buttons (Window Themes, ColourManager/2, CandyBarZ)
* Change (indipendently, or remove some of the) window borders (CandyBarz)
* Change icons (Icon themes)
* Change titlebars (eStyler, Styler/2, ColourManager/2, CandyBarZ)
* Globally change desktop/folder backgrounds (ColourManager/2) ''(Cinc: this one I don't understand. Please clarify.)''
* Transparency (CandyBarZ + CandyFolders)
* Animation and drop-shadows (NPSWPS)
* Subclassing/substituting the remaining controls (scroll bars, etc) (CandyBarZ)
* WISH: different title-bar controls for active/inactive windows ''(Cinc: CandyBarZ or are you speaking about titlebar buttons? -- Cris: yes, I'm speaking about buttons)''
* WISH: non-rectangular windows. There are at least two different libraries for this:
** ShapeWindow (LGPL - http://www.sra.co.jp/people/akira/os2/arch/shpwn200.zip)
** TileWindow (LGPL - http://hp.vector.co.jp/authors/VA001398/os2/softwares/libraries/twtk1_1_4bld14.zip)
''Cinc: these are awfully slow. Won't be possible without diving deep into PM (if possible at all)''

''Cris: don't think so, at least not if it isn't overused. With recent HW, the shape-window extensions are quite fast; moreover, if one uses it only to have rounded borders on windows (like WinXP or many Linux distros default scheme) the number of PM windows created is not boosted very much.''
* WISH: Ability to save everything as one scheme, easily distributable (''Cinc: CandyBarZ did this to some extent)''

Any taker? ;-)

''(Cinc: I've got some time this weekend, just wait till monday ;-D)''

''(more comments below)''
----

I (prokushev here) want to say I am already working in this area (since summer 2004. I recieved ColourManager/2 sources in june or july, don't remember now ;)). Project consist of different pieces:

# Command-line tool which will apply scheme. Goal is to establish scheme file format and create core of software.
# WPS classes for scheme file and schemes preview folder. Uses commandline tool.
# PM scheme editor (as replacement of standard Scheme editor) with preview function.
# PM classes for "without rebooting" controls change.

Cinc: is this source available somewhere? What's the license?

Prokushev: No. Closed source, most probably, because project aimed by eCoSoftware. Most probably sources will be available to MenSys also (this is not under my control). Actually, I looked closely to CandyBarZ and most of things already there ;). May be the product will be based on it (as result it will be under GPL). Only thing I'd like to see - closer integration with WPS.

Cinc: CandyBarZ *IS NOT* licensed under the GPL! and it will not, otherwise I'll pull all my code from it which will not leave too much of a product...).

Prokushev: CandyBarZ already contains GPLed code. As a result the whole package become GPLed. You can't do anything with it.

Most problematic part is PMMERGE.DLL fixing (we need to fix 2 functions: WinSetControlColors and WinQueryControlColors). I have no idea how to do this (ColourManager/2 method of control colors fixing doesn't solve the problem because it breaks the original logic and drops a lot of features).

Cinc: why do we need to fix these functions? Please elaborate.

Prokushev: Ok. Let's play the game. Any control (in original PM logic) must get color in following order:
# PresParam; if none then
# Local Contol Colors table (via winqurycontrolcolors); if none then
# Global Control Colors table (via winqurycontrolcolors); if none then
# SysColor; if none then
# Hardcoded color.

Actually, to allow user to have control on colors step 5 must never be performed. This is as everything should work. If such logic is right, then the standard Scheme editor would allow users to change any color via system colors. If no such logic then the user would need to edit EVERY controls' color. LOTS of colors.

But things doesn't work, because WinSetControlColors can't change some color values. Ideally, WinSetContolColors should allow to set ANY value to a SYSCLR_* constant. Actually, some colors can be set to SYSCLR_* values, some can only be set to RGB_* values, and some can't be changed at all (hardcoded). As a result we can't control ALL colors, only a subset. ColourManager/2 partally solves the problem by setting CCI table to RGB_* values. But... If you use CM/2 then you have no d'n'd sopport in scheme palette, and you need to reboot the system to set ALL colors to new values. Also you have lot of small color problems with application.

We need a complex solution of this problem. Actually, the scheme must be changed on the fly, without any reboot. To do this, we need WC which allows us to set control bitmaps on the fly (like eStyler/2 does), we need to restore original Control Colors Table logic (replace PMMERGE functions) and lot of other small steps.

And, main thing, we must remember about the WPS. At the present time eCS includes various utils which replaces WPS functionality and, as result, we have different 'Properties dialogs' from various programs (as example, eClock has such problem) (''Cris: isn't this due to the fact that eClock is created with Syibil? Sibyl controls are not real PM controls... they are only lookalikes. Prokushev: No. It's because no original WPClock class was replaced to call eClock config tool. As minimum. As maximum eClock configuration must be done via WPS class at all. As example. If I'll replace standard Scheme editor by my own (which written on Sibyl) then I need replace original SchemeEditor class to call my editor. So all thing will be done ok. Any program which will call SchemeEditor class will actually call new Scheme Editor)''. If we replace WPS classes by PM utils then 'WPS wrapper' must be created, at least.

Regarding the 'Icon Theme' tool: actually, we need something more complex, to allow us to change ANY attribute of WPS objects, not only Icons.

Personally I'm not interesting to work on this project 'totally for free' because I have interest in other areas.

Cris: I would be interested in helping with some money, if Adrian considered this to be added to the "funding" made by Netlabs.

Prokushev: Project started. Search alpha versions at eComStation Betazone. Help I actually need:
# I need some approach to patch PMMERGE.DLL to fix/replace 4 functions.
# Testers ;)

Cris: I am interested in being a beta tester. I'll download the alphas ASAP.

Regarding how to patch PMMERGE: you can use the approach used to apply caching to the flushing of user and system INIs. That is: you rename the original PMMERGE to something else (internally also); then you build a DLL called PMMERGE, which intercepts ALL of the original PMMERGE functions and redirects them to the original (renamed) DLL, but for the 4 functions you want to replace/fix. Once you've done your things in those 4 functions, you have the choice to return to the caller (replace) or to forward the call to the original PMMERGE DLL (fix).

Cris: I am having some problems with the alpha of eSchemes. I wrote a couple messages on the forum, but got no reply till now. Could you please monitor the forum, Prokushev? I know the forum still isn't in the forums list, but you can access it directly via the link in the docs.

== Port of coLinux ==

I would like to see the 'Session' capabilities of OS/2 expanded upon. While a port of coLinux ( http://www.colinux.org/ ) wouldn't be a true session, this could be a step toward this goal. Especially if an IFS driver could be written to allow the disk image to be mounted.

== Netlabs runtime distribution ==

Create a set of runtime libraries filling the voids of OS/2. For example including an additional Rexx utility DLL with much needed functions, a set of standard window classes for use in programs (see also PM and open source distribution above). The following classes should be easily implementable (Cinc: I've got already some code for them):

* Progress bar
* Separator
* URL control (control which shows a URL and starts the browser on click)
* ...

Everything should be extremly hassle free to install. So in the end every user has it on the system and developers can be sure to find that. If not they may just write in the readme: "Prerequisite: Netlabs runtime Distribution".

It's not necessary every developer reinvents the wheel again and again. A good starting point is the WPS toolkit IMHO: http://wpstk.netlabs.org/
(don't be fooled by the term WPS in the name, it contains also general purpose functions). The following general purpose functions should be added to WPSTK:

* Query function to get the common OS/2 directories (e.g. ?:\OS2\DLL)
* Function to get the users home directory
* General purpose about box using a predefined look
* Function to start the default OS/2 browser
* ...

There is also quite a lot of helper stuff in xwphelpers from XWorkplace. At the moment it's quite difficult to use them because you have to compile it in your own application so probably we should use parts of it and put it into WPSToolkit as well. We would have to check the licensing issues however because xwphelpers are GPLed and WPSToolkit will most probably be based on BSD or MPL or something alike (more liberal than GPL).
If xwphelpers are using GPL (and not LGPL) they are useless for this project anyway. Nobody will (and should) use a GPLed library.

There should be some general libraries in there as well like:
* libxml
* rexxml (REXX interfaces for libxml)
* libpng (proposal by nickk IIRC)

(prokushev:) Don't think libpng is a required lib. PNG support planned to be included in next eCS version. Native solution is better in comparation of ported tools.
Cinc: this library is meant for porting stuff to OS/2 and it's available *now*.
prokushev: pngioproc available *now*.

We should add some functions extending PM/GPI to deal with unicode/locales. For example a unicode/locale/whatever aware WinDrawText() function. Maybe we even should patch WinDrawText() and friends to be unicode aware by default.

Ideas

2005-02-23T13:02:49Z

Cris: /* OS Skinning/Themeing */

Ideas

2005-02-22T15:59:47Z

Cris: