NikiWiki - User contributions [en]

Ideas

2020-01-04T04:46:08Z

Ak120: /* WPS (Workplace Shell) */

[[Category: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...

There is also the wiki version of the [[The Warp Wishlist]].

* 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 achieve 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 source 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 doesn't 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 storage 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)

==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 complexity. 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.

YD: found some other references to engines:
* Another search system is [http://www.glscube.org/ GLS3], uses Lucene and PostgreSQL, but I see it uses FUSE to create a virtual file system, so probably not good for porting.
* One search system with a wide list of plugins is [http://beagle-project.org/ Beagle], this is written using C# and Mono, requires Lucene and SQLite.
* There is also [http://www.gnome.org/projects/tracker/ Tracker]: this one is written in C and uses an embedded MySQL engine; it seems that it has only a small set of plugins (growing) and no support for realtime indexing (not sure). It supports FreeDesktop metadata handling. This one seems easier to port :-)
* [http://www.recoll.org/ Recoll] is another engine, supports natively a lot of file types, has a GUI written with QT3, uses Xapian for language analysis. interesting.
* [http://pinot.berlios.de/ Pinot], requires xapian and sqlite.
* [http://www.vandenoever.info/software/strigi/ Strigi], requires CLucene as backend, uses QT4.

==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...

Martini: Thats not the case of GNU/Linux. There is a lot of proprietary software running under Linux OS. But there are other good open source licenses on the [[http://www.opensource.org/licenses Open Source Initiative]] page. I think that if a replacement kernel is created for OS/2 it should be open source, since it will gain vendor independence, and will have more probabilities to be maintained in the future.

==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.

==Documentation==

Create os/2 executables project as companion to config.sys documentation project. The goal would be to at least know the purpose of every installed executable and dll.

Ideas

2020-01-04T04:43:15Z

Ak120: /* MultiMedia Improvements */

[[Category: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...

There is also the wiki version of the [[The Warp Wishlist]].

* 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 achieve 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 source 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 doesn't 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 storage 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.

YD: found some other references to engines:
* Another search system is [http://www.glscube.org/ GLS3], uses Lucene and PostgreSQL, but I see it uses FUSE to create a virtual file system, so probably not good for porting.
* One search system with a wide list of plugins is [http://beagle-project.org/ Beagle], this is written using C# and Mono, requires Lucene and SQLite.
* There is also [http://www.gnome.org/projects/tracker/ Tracker]: this one is written in C and uses an embedded MySQL engine; it seems that it has only a small set of plugins (growing) and no support for realtime indexing (not sure). It supports FreeDesktop metadata handling. This one seems easier to port :-)
* [http://www.recoll.org/ Recoll] is another engine, supports natively a lot of file types, has a GUI written with QT3, uses Xapian for language analysis. interesting.
* [http://pinot.berlios.de/ Pinot], requires xapian and sqlite.
* [http://www.vandenoever.info/software/strigi/ Strigi], requires CLucene as backend, uses QT4.

==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...

Martini: Thats not the case of GNU/Linux. There is a lot of proprietary software running under Linux OS. But there are other good open source licenses on the [[http://www.opensource.org/licenses Open Source Initiative]] page. I think that if a replacement kernel is created for OS/2 it should be open source, since it will gain vendor independence, and will have more probabilities to be maintained in the future.

==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.

==Documentation==

Create os/2 executables project as companion to config.sys documentation project. The goal would be to at least know the purpose of every installed executable and dll.

MMOS2 Related Projects

2020-01-04T01:23:43Z

Ak120: /* Video Codecs */

==Introduction==
This page make a little description of the MMOS2 related projects.

==MMIO Subsystem==
===Video Codecs===
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|QuickMotion
|Plays MOV files (QuickTime 2.0) and some QuickTime VR's
|2.0.0
|[http://sourceforge.net/projects/qmos2/files/qm20.zip/download Binary]
|[http://sourceforge.net/projects/qmos2/ Open Source - GNU GPL]
|Practice / Tom Harding
|-
|AnPoMSVC||Video1||1.2.2||rowspan=3|AnPoCODEC 6 [http://hobbes.nmsu.edu/download/pub/os2/apps/mmedia/codec/apcodec6.zip Demo]||rowspan=3|Commercial||rowspan=3|Andreas Portele
|-
|AnPoCVID||Cinepak||2.0.0
|-
|AnPoMSVCRLE||RLE||1.1.0
|-
|mainCODEC/2||Decodes RGB, Run Length Encoding, Microsoft Video 1 and Cinepak CODECs||1.1.0||[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/mcodc100.zip mcodc100.zip]||Free - Included on MainActor package||Main Concept
|-
|Xine MCD||MPEG-1 and MPEG-2 Video||RC2 0.99.2||xinerc2.zip, xinerc2src.zip||GNU GPL||Darwin O'Connor
|-
|SR-MJPEG Codec||AVI Motion JPEG decoding and encoding support||1.1.0||[http://hobbes.nmsu.edu/download/pub/os2/apps/mmedia/codec/srmjpg11.zip srmjpg11.zip]||Shareware||Sergej Grogoriev
|}

===Audio Codecs===
====TiMidity MCD for OS/2====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|Timidity MCD||Plays MIDI and Module (.MOD) files||2.10.4||timiditymcd_2104.zip, timidity_2104_os2_src.zip||GNU GPL||Darwin O'Connor
|}

====[http://r6.ca/MMAudioPak/ MMAudio Pak 2 for OS/2]====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|MMIOMP3||MP3||0.4.3||rowspan=3|[http://r6.ca/MMAudioPak/MMAudioPak.zip Binary and Source]||GNU GPL||rowspan=3|Russell O’Connor
|-
|MMIOVorbis||Vorbis||0.3.2||Copyright (c) 2001, Xiphophorus
|-
|MMIOFLAC||FLAC||0.3.0||GNU GPL
|}

====True Midi Format====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|True MIDI Format Multimedia I/O Service||Plays MIDI Files||1.0.0||[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/tmdproc.zip Binary]|| ||Team MMOS/2 Tokyo
|}

====PCM/RAW Audio Format====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|PCM/RAW Audio Format MMIO Service [R/W]||PCM / RAW Audio||1.0.1||[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/pcm-raw.zip Binary]||(C) TM2LABO||Team MMOS/2 Tokyo
|}

====MPEG Audio-1 Layer 1/2/3 Multimedia I/O Service====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|MPEG Audio-1 Layer 1/2/3 Multimedia I/O Service||MPEG Audio-1 Layer 1/2/3||1.0.1||[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/mmmpa.zip Binary]||Freeware||Team MMOS/2 Tokyo
|-
|MPEG Audio-1 Layer 1/2/3 Multimedia I/O Service Extra Entry||MPEG Audio-1 Layer 1/2/3||1.0.1||[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/mmmpa.zip Binary]||Freeware||Team MMOS/2 Tokyo
|-
|RIFF Wave MPEG Audio-1 Layer 1/2/3 Multimedia I/O Services||RIFF Wave MPEG Audio-1 Layer 1/2/3||1.0.1||[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/mmmpa.zip Binary]||Freeware||Team MMOS/2 Tokyo
|}

====Digital Wave Effect Multimedia I/O Extender====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|MMEffect Free Effects
|DELAY,ECHO,WDSX,NOIZE,VOLUME Effects are Freeware
|1.6.0 (2001-05-19)
|[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/mmeffect.zip Binary]
|Shareware
|Team MMOS/2 Tokyo
|}

====MMCDDA Compact Disc Digital Transmit Multimedia I/O Extender====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|MMCDDA CD-DA Digital Transmit MMIO Ex
|
|1.4.1 (1999-11-10)
|[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/mmcdda.zip Binary]
|Shareware
|Team MMOS/2 Tokyo
|}

====WAVE MIX Multimedia I/O Service====
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|WAVE MIX Multimedia I/O Service
|
|1.1.0 (2000-10-26)
|[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/wavemix.zip Binary and Source]
|Freeware
|Team MMOS/2 Tokyo
|}

===GRAPHIC CODECS===
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|JPEG-IO procedure
|Replacement for the JPEG procedure that comes with MMOS/2
|0.1.0
|[http://www.os2world.com/cdwriting/jpgio/jpg-io-procedure-0_1_0.zip Binary and Source]
|Freeware (BSD) Copyright Chris Wohlgemuth
|Chris Wohlgemuth
|-
|LGO File Format Procedure
|OS/2 boot logo files
|2005.6.27
|[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/lgoproc.zip Binary], [http://kannegieser.net/~veit/quelle/lgoproc_src.arj Source]
|Open Source (No License Defined)
|Veit Kannegieser
|-
|XGA File Format Procedure
|Phoenix BIOS suspend graphic files
|2005.6.27
|[http://hobbes.nmsu.edu/pub/os2/apps/mmedia/codec/xgaproc.zip Binary], [http://kannegieser.net/~veit/quelle/xgaproc_src.arj Source]
|Open Source (No License Defined)
|Veit Kannegieser
|-
|MMImage pak
|Replacement for the JPEG, PNG, BMP, GIF, TIFF and other procedures that comes with MMOS/2. Part of eSchemes Deluxe.
|3.0
|[http://www.ecomstation.ru]
|Shareware Copyright Yuri Prokushev
|Yuri Prokushev
|-
|PNG MMIO Procedure
|PNG Graphic support (readonly) for MMOS2
|0.7.0 Beta
|[http://hobbes.nmsu.edu/pub/os2/apps/graphics/viewer/mmiogpng.zip Binary]
|Freeware
|Giorgio Costa
|}

==Multimedia Classes==
===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.
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|CWMM Classes
|A replacement for the multimedia classes that comes with MMOS2
|0.2.7
|
|Open Source - GNU GPL / BSD 3-Clauses
|Chris Wohlgemuth
|-
|eSchemes Deluxe
|Preview of browsed images
|3.0
|[http://www.ecomstation.ru]
|Shareware
|Yuri Prokushev, eCo Software
|}

==Tools==
{|class="wikitable"
!Name||Description||Version||Download||License||Author/Port
|-
|Normal Player
|A Multimedia Player bases on MMOS2
|2002-02-05
|nplay.zip
|GNU GPL
|Darwin O'Connor
|-
|Image
|Simple, fast image viewer that works with MMPM/2
|0.02
|[https://hobbes.nmsu.edu/download/pub/os2/apps/graphics/viewer/mk_image0_02.zip mk_image0_02.zip] [http://hobbes.nmsu.edu/download/pub/os2/apps/graphics/viewer/mk_image0_02src.zip mk_image0_02src.zip]
|GNU GPL
|Mark Kimes, Steven H. Levine
|}

MMOS2 Related Projects

2020-01-04T01:19:10Z

Ak120: /* Multimedia Classes */

2005-05-18T21:06:51Z

Ak120:

== Czech Warpstock 2005 ==

17.07.2005-19.07.2005 Liberec, CZ

[[Image:Warpstock05.gif|thumb]]

[http://felis.kky.vslib.cz/czech_warpstock_2005/en.htm English Information]

Czech Warpstock 2005

2005-05-18T21:05:19Z

Ak120:

== Czech Warpstock 2005 ==

17.07.2005-19.07.2005 Liberec, CZ

[[Image:Warpstock05.gif|thumb|]

[http://felis.kky.vslib.cz/czech_warpstock_2005/en.htm English Information]

File:Warpstock05.gif

2005-05-18T21:04:25Z

Ak120:

Czech Warpstock 2005

2005-05-18T21:00:20Z

Ak120:

== Czech Warpstock 2005 ==

17.07.2005-19.07.2005 Liberec, CZ

[http://felis.kky.vslib.cz/czech_warpstock_2005/en.htm English Information]

Current events

2005-05-18T20:56:37Z

Ak120:

[[Developers_Workshop_2005|09 July - 10 July 2005       OS/2 and eComStation Developers Workshop 2005       Dresden, Germany]]

[[Czech_Warpstock_2005|17 July - 19 July 2005       Czech Warpstock 2005       Liberec, Czech Republic]]