Ideas

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 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:
 * TiMidity MCD for OS/2 (midi)
 * MMAudio Pak 2 for OS/2 (MP3, Vorbis, FLAC)
 * 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: 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 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 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 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 emerge 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)

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

Note: Don't think we must replace Icon rendering. But adding MMPM IO procs for PNG and SVG is good idea.
 * 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: 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:


 * 1) move PMCTLS.DLL to PMOLDCTL.DLL
 * 2) write new PMCTLS.DLL with forwarders to PMOLDCTL.DLL
 * 3) 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
to USB2.0 with PCMCIA cards.
 * PCMCIA driver for USB2.0 cards for laptops. Right now, laptops with USB1.0 built in cannot be upgraded


 * 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

 * 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 ). 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 ? 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: 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! 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" 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


 * 1) Open Source Project / free license GNU GPL.
 * 2) 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.