OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Neil Waldhauer on December 27, 2013, 07:20:12 pm

Title: Closed source parts of eComStation
Post by: Neil Waldhauer on December 27, 2013, 07:20:12 pm
I'm wondering how much work there is left to leave the IBM parts of eComStation behind and going to an unencumbered product?

OS/2 Kernel
MPTS
MMOS2
Presentation Manager
WorkPlace Shell
GRADD Graphics subsystem

I'm sure I forgot a few, and there are lots of little bits that haven't ever been replaced (look inside the OS2 directory tree, but those are the big subsystems.

File and Print is largely replaced by SAMBA and CUPS.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on December 27, 2013, 08:17:17 pm
Hi Neil.

I tried to talk a little bit about this on the earlier posts of my blog: http://openwarp.blogspot.com

Since I'm not very sharp on this subject I tried to understand the components from "Top to down". So I think that the three components that are almost the "face" of OS/2 are:
- Workplace Shell Classes - which are based in SOM
- SOM - which depends on PM
- PM - which is the GUI library.

I think that any efforts to start with any of this three components are good... no matter how little the effort is, like replacing some PM's DLL or making a single  WPS Class.

The stuff in the backend I don't understand it well yet, I will really like to create a more detailed graphic about it. Like understanding the relation between the Kernel, Loader, Drivers and the "Control Program", "GPI" , "REXX library", etc. I'm still now sure what the "Control Program" is, or where does the "GPI" stuff goes.

I tried to create a very high level graphic of the main OS/2 architectural components.

(http://4.bp.blogspot.com/-zYeRhXwB620/UaY-58CbCDI/AAAAAAAAEYo/kNPot3NkrxA/s1600/OS2+Architecture+Graphics+v3.png)
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on December 27, 2013, 09:15:28 pm
Here it is the ODG (openoffice) file for the architecture graphics.

Everybody is welcome to go wild and create their own versions.
Title: Re: Closed source parts of eComStation
Post by: ivan on December 27, 2013, 11:43:53 pm
Neil, if you can get SAMBA and/or CUPS to print over the network to a NAS based print server that requires a username and password to log in I would love to know the necessary incantations and what must be sacrificed to do so.
Title: Re: Closed source parts of eComStation
Post by: Roderick Klein on December 28, 2013, 12:48:58 am
I'm wondering how much work there is left to leave the IBM parts of eComStation behind and going to an unencumbered product?

OS/2 Kernel
MPTS
MMOS2
Presentation Manager
WorkPlace Shell
GRADD Graphics subsystem

I'm sure I forgot a few, and there are lots of little bits that haven't ever been replaced (look inside the OS2 directory tree, but those are the big subsystems.

File and Print is largely replaced by SAMBA and CUPS.


MOre work then you want to wish for. Its realy the question if you need certain of eCS in a new OS.
For example GRADD. If you do start from scratch you could just as well desugn something new or use something from Linux.

As to reimplementing the OS2KRNL. WHat features would you like to have of the kernel ?
You would need to set much more fin gradined targets. Looking how far the voyager priject came of Netlabs.
Its certainly not going to move forward fast without a big chunk of money.

Roderick
Title: Re: Closed source parts of eComStation
Post by: Paul Smedley on December 28, 2013, 12:52:27 am
Neil, if you can get SAMBA and/or CUPS to print over the network to a NAS based print server that requires a username and password to log in I would love to know the necessary incantations and what must be sacrificed to do so.

To be honest - I thought this was possible with cups - I would expect specifying the printer queue as smb://username:Password@ip_address in CUPS would do this (but I could be wrong)
Title: Re: Closed source parts of eComStation
Post by: ivan on December 28, 2013, 02:47:27 pm
Thanks Paul.  I will give that a try on Monday when I go into work although I seem to remember trying something like that before and getting no response.

Is there any thing special I should be looking for?  Since all the printers are HP CLG 3500 I have your hplip installed with CUPS on my test machine.  Now all I have to do is work out what to do.
Title: Re: Closed source parts of eComStation
Post by: Boris on January 14, 2014, 02:14:30 am
As to reimplementing the OS2KRNL. WHat features would you like to have of the kernel ?

Roderick

For sure, the very huge and very important part that really needs to be reimplemented is the stuff that do memory management.
Memmanagement is known to be very poor (two arenas, continous troubles with shrmem) on OS/2. Also the 4 GiB for all the processes limit surely should be overcamed.
With the latest development of Phoenix team -- PAE ramdrive, you can use up to 64 GiB of memory on OS/2 (with any kernel, any version of OS/2 from Warp 3 to eCS *nextVersion), but even with swapfile placed on the ramdrive, the limit of 4 GiB/all processes still remains.

This will not remove the limit of 4 GiB per ONE process, but for sure will be a great move forward for OS/2, because you, of course, can just "write another videodriver", but the 4 GiB of RAM limitation for all the system is now a fundamental barrier, which SHOULD be overcamed as soon as possible.



Another big trouble, a bottleneck of Operating System/2, is the graphics subsystem and some parts of WPS.
While the most annoying defect of WPS -- instability -- really needs attention, the Presentation Manager and the graphics subsystem itself inhibits the development of eComStation very much.

PM and the graphics subsystem is a huge bunch of code, and its reverse-engineering and (preferably) opensourcing should became the next long-term goal of the whole eComStation community in general and Mensys in particular.
While WPS improvement (making it usable as a light filemanager -- copy/move dialog replacement, file open container (opensource it!), etc) may be performed relatively easy, in view of XWP, which is a very good start (or even the half of a distance), PM and the graphics subsystem need a lot more work, and should became the primary target.
Its defects are: inability of on-the-fly resolution change, no support of multidisplay configurations (one stretched desktop (!) on many monitors with different resolutions (!!) connected to a number (!!!) of different (!!!!) videocards ran by different videodrivers (!!!!!) -- this is fully possible on Microsoft Windows and impossible on OS/2), and no support of transparency (=>non-square windows, shadows).
Consider, that Windows, GNU/Linux, Mac OS X do support all these features.



Also, if I started to whine here, I am also gonna note a few problems, no one of which are also encountered on other OSes, and which are easy to fix.

First. USBCOM driver. It just is not suitable for anything. USBCOM devices should be plug and playable (no need to preconfigure the amount of usbcom devices in the config.sys), three or five more chips support should be added.
Ubuntu 12 supports USBCOM hardware very well -- I've tryied three devices which didn't work with OS/2, on Ubuntu -- worked well out-of-the-box, no additional drivers needed.
The problem may be easily fixed (look at the usbserial module sources of the linux kernel).
There is no attention paid to this problem.

Second. USBMSD with SCSI-Transparent command set support should be implemented. Chris Wohlgemut once did this, but his driver does not work for my device, the driver's source code is not opensourced.
Windows XP with no service packs support these hardware w/o any additional drivers needed, out-of-the-box.
The problem may be easily fixed (look at the usbmsd module sources of the linux kernel).
There is no attention paid to this problem.



I suppose, that's all :)
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 14, 2014, 10:10:12 am
Quote
the 4 GiB of RAM limitation for all the system is now a fundamental barrier

Could you please name one OS/2 application or one use case where we need more than 4 GB RAM?

Of course it would be nice to have but there is no priority for this from a point of a user. I understand that people buying windows machines and then wonder if they eCS work on it. But for me as an real user (I'm working 8h each day with eCS) there are about 100 things more important than >4GB RAM. As the fairy said: don't waste wishes if you have only three. ;)

I agree to get things solved like shared memory problem or USB-issues.
Title: Re: Closed source parts of eComStation
Post by: Michael Holzapfel on January 14, 2014, 12:42:45 pm
Could you please name one OS/2 application or one use case where we need more than 4 GB RAM?
Well, darktable and rawtherapee would be my candidates. Using eCS on daily base becomes more and more difficult to meet the requirements of digital photography.

Furthermore storing large video files (4K) for NAS-services like mediatomb is a real pain with the 2TB fize limitation for file systems.

The foregoing discussion increasingly resembles that of the transition from 16 to 32 bit operating systems. For a long time Microsoft had denied the need of 32 bit systems. We as eCS-users don't even have the possibility to use tools like dos-extenders to utilize all the available memory on our hardware.

BR
Michael
Title: Re: Closed source parts of eComStation
Post by: Boris on January 14, 2014, 04:39:51 pm
Could you please name one OS/2 application or one use case where we need more than 4 GB RAM?
I run virtual machines and console java applications on a server with two CPUs and 4 GiB of RAM running OS/2.
Firefox could easily take more than 4 GiB of RAM (if not the crashes).
I would like to run virtual machines on my main PC (eComStation 2.1) and don't look on the memory indicator.

Quote
Of course it would be nice to have but there is no priority for this from a point of a user. I understand that people buying windows machines and then wonder if they eCS work on it. But for me as an real user (I'm working 8h each day with eCS) there are about 100 things more important than >4GB RAM. As the fairy said: don't waste wishes if you have only three. ;)
As far as you can see, I am a real OS/2 user. There are about four machines at my home that run OS/2. I am writing you from my laptop that runs eCS 2.1. I think I use OS/2 for about six (or more on weekand/holidays) hours per day.
I have participated in OS/4 kernel testing with success.
Also I've ported two small Qt utilities to OS/2.


For the *ucks sake, the "OS/2 does not need that" tactic IS A BAD TACTIC.
That's why we don't have skype, for example.

4 GiB per all processes is a fundamental barrier not because it is the most annoying defect, (maybe you need to reread me, huh?) it's because in 2020 you can write another video or audio driver, port another videoplayer or write USB 5.0 host controller driver, but the 4 GiB limitation still remains, and that's the limtation that prevents OS/2 from running on current, big servers. Symmetric multiprocessing support is good enough. Multitasking is good enough too. But nobody will even think to run OS/2 on a server with 64 GiB of RAM.

Don't wait 'til the 4 GiB limit will be the most annoying one, because it needs a lot of work, and we need to start as soon as possible.
If we are rewriting the memory manager, it will be too silly not to remove the 4 GiB/all processes limit.
Title: Re: Closed source parts of eComStation
Post by: Boris on January 14, 2014, 04:45:28 pm
We as eCS-users don't even have the possibility to use tools like dos-extenders to utilize all the available memory on our hardware.

Actually we do have the possibility.
The PAE ramdrive acts just like a dos-extender.
The hd4disk.add driver first turns off normal paging, then sets PAE paging, reads/writes from the upper memory, then turns off PAE and restores the normal paging.

For example, you can use the latest Windows XP 32-bit with no PAE support to access all the memory by putting the swapper file on a ramdrive, that supports PAE. And that really do work.

While on OS/2 it won't work, because of very poor memory manager.
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 14, 2014, 09:37:13 pm
Boris,

no reason to get angry. I don't talk about tactic. We have very small capacities of developers. So I'm talking about priorities.

To say os2 don't needs above 4GB RAM is no tactic - it is a fact. Because we don't have applications that use such an amount of RAM. Maybe it can be a problem in future. But today there are loads of things more important and that drops me back to high priorities.

And when you talk about running loads of virtual machines with more RAM: its a bad tactic to design a system, to perfectly run other systems - while the own identity is going down (and btw other systems do the visualization even better right now). So at first priority you need unique software and special use cases. If you want to sell a OS like eCS for 270 bucks  you need a unique reason. Something special. One of the good points of eCS or OS/2 is that it runs very smooth one small hardware. Its a very powerful system with very small system requirements.

So when we talk about "fundamental barriers" the first point should be to find a reason why to use this system and not another one.
Then the price is a "fundamental barrier" for new users. Then we come to installation and communication. E.g. it should be no problem to share data with USB sticks. It should be no need to fire up dfsee to make an USB stick running (if youre lucky enough). ACPI and basic drivers. And then we come to lack of standard software, which is a real fundamental barrier. We don't have real working video player nor a full featured bitmap editor nor a really good and stable office suite. To use your words: "ffs" Mensys doesn't even have reference system.

And, and, and ... and then after maybe we really need more than 4 GB.

Atm eCS lives because some people have been arranged with the situation, using old software and workarounds, or use the system in a very basic way.

@Michael
When you talk about bitmap and video manipulation - stop me if I'm wrong but we don't have these applications  for OS2. I would be fine when I'm wrong. We don't even have decent working version of gimp. 4 GB limit might be a small part of the whole problem. When we get 100 GB RAM we don't solve this situation.
Title: Re: Closed source parts of eComStation
Post by: Boris on January 14, 2014, 10:19:03 pm
Boris,

no reason to get angry. I don't talk about tactic. We have very small capacities of developers. So I'm talking about priorities.

To say os2 don't needs above 4GB RAM is no tactic - it is a fact. Because we don't have applications that use such an amount of RAM. Maybe it can be a problem in future. But today there are loads of things more important and that drops me back to high priorities.

And when you talk about running loads of virtual machines with more RAM: its a bad tactic to design a system, to perfectly run other systems - while the own identity is going down (and btw other systems do the visualization even better right now). So at first priority you need unique software and special use cases. If you want to sell a OS like eCS for 270 bucks  you need a unique reason. Something special. One of the good points of eCS or OS/2 is that it runs very smooth one small hardware. Its a very powerful system with very small system requirements.

So when we talk about "fundamental barriers" the first point should be to find a reason why to use this system and not another one.
Then the price is a "fundamental barrier" for new users. Then we come to installation and communication. E.g. it should be no problem to share data with USB sticks. It should be no need to fire up dfsee to make an USB stick running (if youre lucky enough). ACPI and basic drivers. And then we come to lack of standard software, which is a real fundamental barrier. We don't have real working video player nor a full featured bitmap editor nor a really good and stable office suite. To use your words: "ffs" Mensys doesn't even have reference system.

And, and, and ... and then after maybe we really need more than 4 GB.

Atm eCS lives because some people have been arranged with the situation, using old software and workarounds, or use the system in a very basic way.

@Michael
When you talk about bitmap and video manipulation - stop me if I'm wrong but we don't have these applications  for OS2. I would be fine when I'm wrong. We don't even have decent working version of gimp. 4 GB limit might be a small part of the whole problem. When we get 100 GB RAM we don't solve this situation.

Stop for a minute. And follow the thread.
Roderick:
Quote
As to reimplementing the OS2KRNL. WHat features would you like to have of the kernel ?

Roderick
Then me, talking about the 4 GiB limit. So, that's not offtopic. For example, talking about GIMP in the what-do-you-need-in-os2-kernel thread, would be offtopic.

While we have enough developers to solve the 4 GiB problem, we need to do this.

Because you can edit bitmaps in a virtual machine on OS/2, but you can't use virtual machine to allocate more than 4 GiB memory.
You can now transfer data from USB sticks, but you can't use more than 4 GiB of address space.
That's what I call a fundamental barrier.

You can rearrange priorities, and more, fixing a fundamental problem may have a lower priority than fixing the USB widget to write DLAT *: at a usb stick connect, but, sooner or later, you will end up with not enough virtual memory and perfectly working USB sticks, and no way to fix that, because there'll be no developers that are able to rewrite memory management.
Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 15, 2014, 05:38:42 am
Quote
While we have enough developers to solve the 4 GiB problem, we need to do this.

Well, I think you are being  bit optimistic. We don't even have enough developers to get a Wireless NIC working (although that seems to be on the short list).

Personally, I now have 4 systems with 4 GB of memory (one is not currently used with eCS). I could load up every program that I have installed, and I wouldn't fill up all of that memory (unless I made some large virtual memory systems, in VBox). At the moment, the 4 GB (actually something closer to 3.3 GB) addressing limit is not a limiting factor. More limiting is the 500 meg memory space for each program (which includes shared memory space).

Very recently, the QSINIT project has demonstrated that using memory above the 32 bit addressing limit is possible. That is currently restricted to using it as a RAMDISK, but it has been demonstrated that it does work. More serious work is required to be able to use that memory more productively, and it is likely that programs would need to be modified to use it. Note that this is NOT the ideal solution, but, at the moment, it is the ONLY game in town.

Quote
That's what I call a fundamental barrier.

It is, BUT, there are many other barriers, that are much more limiting, and require a lot less resources to fix. If the manpower is redirected to fixing the 4 GB barrier, the other, more important, problems will not be addressed. If they are not addressed, there will be no point in having more than 4 GB of usable memory. Then, there is the question about which programs you will need, that will actually use that much memory, and where are they going to come from?

I don't mind people asking for a way to get to the next solar system, as long as they don't insist that we stop all other development to accomplish it. We have enough problems, without shooting ourselves in the foot. In due time, eCS will either die, or it will continue to try to keep up with the rest of the world. As I have said before, the only way that eCS is likely to accomplish any goals, beyond that, is to accumulate enough money to do the job. That means that all of you who seem to think that Mensys owes you free goodies, without buying into the project, had better wake up, and contribute to the project, or, somebody needs to win a HUGE lottery, and donate a good portion of it to the project (through Mensys, or in other ways). You can wish all you want, but insisting that we need to be able to do something that is clearly not possible (in today's world), is just going to kill eCS (OS/2). faster.

Now, if Mensys can just get eCS 2.2 out the door, so they can get to work on Multimac support for wireless devices, it will be the first step to getting some of this done. Meanwhile, nobody has stepped up to use the wired Multimac templates, to produce more support for wired NICs. It has always been the plan that Mensys would develop a few NIC drivers, which they did (Intel, Realtek, and NVIDIA), and then let others follow the lead, and make more (Broadcom, Ralink, etc.). Mensys did their part, now we, the OS/2 community, need to step up and do our part. Sitting back, and waiting for someone else to do it, is not an option, and Mensys can't afford to do much more than what they already do.

The ball is in your court...
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 15, 2014, 10:01:07 am
Thanks Doug this is exactly what I think.
To demand is always easy - to fulfill is not. We should eat humble pie and, be realistic and focus on the things we really need in this moment.

For things like several virtual machines on one computer there are much better platforms than os2, with better hardware support, better supported virtualization software and better memory management. And as this topic is a moving target eCS will never compete with these systems. We are a handful of people. Most of the new ported applications are completely untested. The eCS core features are reliability, WPS, Rexx, special and unique programs, small requirements. Thats it what I would try to support and to expose.

You can say 4GB limit is a bug, you can also says it is great that eCS needs only 2 GB. Its a feature. It is a damn good thing that eCS don't wastes your RAM. It really good that we don't have this helix with more hardware requirements with each version and reciprocal upgrades in hard and software (news OS needs new hardware, new hardware needs new os, endless loop while we doing still the same with our computers without any significant changes) we hate on Windows so much.

Btw im writing this on a computer with 512 MB RAM
Title: Re: Closed source parts of eComStation
Post by: Boris on January 15, 2014, 07:10:48 pm
Quote
The ball is in your court...
I won't argue anymore, but I'm gonna fix some mistakes.

Quote
Well, I think you are being  bit optimistic. We don't even have enough developers to get a Wireless NIC working (although that seems to be on the short list).
Four developers work on OS/4 kernel for years. Although removing the limit may cost some, because it is a lot of work, it can be accomplished.

Quote
Btw im writing this on a computer with 512 MB RAM
Me too. Although, that's how much memory in my laptop is installed right now, I'm gonna upgrade to 2 GiB (the maximum).

Quote
Very recently, the QSINIT project has demonstrated that using memory above the 32 bit addressing limit is possible. That is currently restricted to using it as a RAMDISK, but it has been demonstrated that it does work. More serious work is required to be able to use that memory more productively, and it is likely that programs would need to be modified to use it. Note that this is NOT the ideal solution, but, at the moment, it is the ONLY game in town.
It was obvious that using memory above the 32 bit addressing limit is possible, because you can use more than 4 GiB of memory on Windows 32-bit using ramdrive with PAE support by placing the swapfile on it.

Then, the first thing to do was to write a PAE supporting ramdrive, the hd4disk.add driver (which is acutally a standalone project, and it can be used without the Tetris bootloader).

Then, finally, to overcome the 4 GiB limit in the memory manager.

That is a very small cost comparing to rewriting the whole system on 64-bit, or comparing to implementing PAE directly in the memmanager, which would affect the drivers.

Quote
More limiting is the 500 meg memory space for each program (which includes shared memory space).
What limit?

Anyway, the memory management subsystem should be rewritten, and removing the 4 GiB barrier should be one of this task's subtargets.
Title: Re: Closed source parts of eComStation
Post by: Boris on January 15, 2014, 07:18:39 pm
I've tried to be as polite, as I could, and, I hope, the argument is settled.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 15, 2014, 09:23:56 pm
There are a lot of things the eCS-OS2 is missing and it is hard to get a priority list since this priority change according the subject's needs.

One thread goes by there are people that think that eCS-OS2 is fine and we only need more drivers and keep patching it. Do not fix what it is not broken.

The other thread (me included) is try to clone as much of OS/2 as open source, even the components that are working. What it is working today will stop working tomorrow, and if we do not have the source code it is going to be harder to fix.

But,  no matter on which thread are you, the questions that we should ask are:
- Can you pull it off?
- Can you code the driver or the close source replacement?
- Can you hire someone that can do the development?
- Do you need help? What do you need?
- Can we pull it off to make a community raise fund for an specific driver or component?

The statement should be "I want to help" and "I can help with this or that".

So, who wants to do it? what do you require? I want to help any open source effort on this platform.
Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 15, 2014, 10:37:30 pm
Quote
I won't argue anymore, but I'm gonna fix some mistakes.

That was not a challenge to you, specifically (and I am not arguing). It was challenge to the whole OS/2 community, to start helping out on some of these basic projects. It doesn't matter if you fix the 4GB problem (which is a non issue at this time anyway, even in 32 bit windows - it is only the server versions that use PAE, unless Win8 has started using it). It will take years for anybody to port enough software to use it, and new development seems to be a thing of the past.

More important, are things like support for the majority of NICs that exist today, and in the future. Without communication (especially wireless), nobody will be able to continue using eCS. It just won't do the job. It can't always do the job today, without wireless communications. There are keyboard problems, there are video problems, there are printer problems. Somebody had better start fixing all of them, or eCS will be as dead as IBM, and Microsoft, wishes it was.

Quote
Four developers work on OS/4 kernel for years.

Yes, and they are 4 developers who are wasting their time, if the more basic problems are not fixed soon. I don't want to discourage you, but these other, more basic, problems are going to kill the whole thing, before you get finished with what you are doing. Trying to get users back, after they go through the pain of going somewhere else, is not an easy job, as the current eCS project demonstrates. It is possible that we have already lost the critical mass to be able to maintain eCS as a viable project, and fixing the 4 GB barrier, today, would not prevent users from leaving, simply to get their WiFi adapter to work. Other things are going to become more important, in the next year, or two (USB 3.0, Bluetooth, WLAN), which haven't even been addressed, yet, although USB 3.0 is planned. You could have 64 GB of memory, that is usable, but that is not as useful as WiFi support, for the average power user, who would rarely, if ever, actually use 3 GB of memory, never mind 64 GB of memory. Personally, I find that I never use 2 GB of memory, unless I start a VBox, with a large memory assigned. That means that having a RAMDISK for the swap file, that will never be used, is not really going to help much.

What I am trying to get at, is that your 4 programmers could accomplish a lot more by working on other projects, that the average user will find useful, than to spend time messing around with breaking the 4 GB barrier, which won't do anybody any good, until a lot of other things get fixed (compilers, linkers). Those things are badly broken today, which limits porting, and new programming. anyway, and that discourages users from remaining in the OS/2 user group.

Quote
So, who wants to do it? what do you require? I want to help any open source effort on this platform.

It doesn't matter if these things are open source, or not. If they don't happen, eCS becomes less, and less, usable, and that means that more, and more, users must go elsewhere so they can do what needs to be done. Why would they even consider coming back? Sure, open source is desirable, but those who do the job need to make a living. We don't have corporate support, like Linux does, and most development is being done on a volunteer basis (even Linux is not 100% open source). Mensys has stepped up, and they have paid to get some necessary things done, but they don't have unlimited funds either. Mensys has committed to open sourcing what they pay for, and AFAIK, they have done that. What they haven't done, is make binaries available to those who don't pay for eCS. To me, that is a really good compromise. They do need to have a reason for users to buy eCS, and pay for Software Subscription, which pays for the development, as well as the wages of a couple of people who are doing a great job of holding it all together. I am pretty sure, that eCS is a non profit project, for Mensys, and they spend as much as possible on development, without running the company into bankruptcy. Is it enough? Probably not, and that is where the users need to step up, and do more to help out, if they want to keep eCS going.

The main problem is that there is not enough money, or people, to do any more than what is being done today. That is not enough to even keep up with the important stuff, never mind make advances that are not necessary, even though they may become necessary, eventually. Like it, or not, Mensys is the focal point, and if they find that they cannot cover their costs, eCS will be gone. That would leave OS/2, in all of it's forms, with no option but to pass into history.
Title: Re: Closed source parts of eComStation
Post by: Boris on January 15, 2014, 11:07:49 pm
Yes, and they are 4 developers who are wasting their time, if the more basic problems are not fixed soon.
Ok, that's enough for me. Didn't read more.
Title: Re: Closed source parts of eComStation
Post by: Dave Yeo on January 15, 2014, 11:38:55 pm
As far as I know, the 4 GB barrier is built into X86. We use 32 bit pointers which are limited to 4Gbs and while most CPU's are now capable of using 64 bit pointers the CPU has to be put into a different state where 16 bit code no longer works and OS/2 still has too much 16 bit code to ignore, especially as much of the 16 bit code is device drivers.
All 64 bit capable CPUs also do PAE and as has recently been shown, os2ldr can be rewritten to access that extra 60GBs but it is kinda like bank switching (actually if I understand it, it's back to segments). You can access different 4 GBs banks or segments, great for a ramdisk but not really extending the address space visible to a program. Perhaps it is possible to give different programs their own address space so eg Firefox has access to 4GBs of real ram minus whatever the kernel needs along with what the hardware needs and this would be an improvement. How hard this would be I don't know. I do know that MS gave up on the idea for client versions of Windows as too many device drivers were not happy with it.
As far as I know the swap file is also limited by 32 bit types, probably signed so limited to 2 GBs which means putting the swap file on the ram disk can only help so far.
If someone is really dealing with large bitmaps, video files etc, they really have to move to a 64 bit operating system and purchase more memory
Title: Re: Closed source parts of eComStation
Post by: Boris on January 16, 2014, 01:17:53 am
As far as I know, the 4 GB barrier is built into X86. We use 32 bit pointers which are limited to 4Gbs and while most CPU's are now capable of using 64 bit pointers the CPU has to be put into a different state where 16 bit code no longer works and OS/2 still has too much 16 bit code to ignore, especially as much of the 16 bit code is device drivers.
All 64 bit capable CPUs also do PAE and as has recently been shown, os2ldr can be rewritten to access that extra 60GBs but it is kinda like bank switching (actually if I understand it, it's back to segments). You can access different 4 GBs banks or segments, great for a ramdisk but not really extending the address space visible to a program. Perhaps it is possible to give different programs their own address space so eg Firefox has access to 4GBs of real ram minus whatever the kernel needs along with what the hardware needs and this would be an improvement. How hard this would be I don't know. I do know that MS gave up on the idea for client versions of Windows as too many device drivers were not happy with it.
As far as I know the swap file is also limited by 32 bit types, probably signed so limited to 2 GBs which means putting the swap file on the ram disk can only help so far.
If someone is really dealing with large bitmaps, video files etc, they really have to move to a 64 bit operating system and purchase more memory

The whole address space, on OS/2, that you can use with A LOT of processes (programs), is limited to 4 GiB.
So, even if you have the swapping feature enabled and large enough hard disk, you cannot run 500 programs to allocate 500 GiB (one GiB per process).

While on Windows 32-bit, one program still cannot allocate more than 4 GiB, but you can swap on your hard disk and allocate 500 GiB with a lot of processes.

So, the trick is to put the swapfile not on the harddisk, but on the ramdrive, which would be able to map the memory above the 4 GiB limit using PAE without affecting the rest of the system.

So, that is the limit I am talking about. It could be overcomed by reimplementing the memory management subsystem in the OS/2 kernel.



By the way, the hd4disk.add driver, which actually jumps into PAE and provides the ramdrive (not the loader or, especially, QSINIT), works pretty fast (with the words of the developer) -- you can test it by yourself, or ask me to measure the r/w speed and report the results.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 16, 2014, 03:08:02 am

More important, are things like support for the majority of NICs that exist today, and in the future. Without communication (especially wireless), nobody will be able to continue using eCS. It just won't do the job. It can't always do the job today, without wireless communications. There are keyboard problems, there are video problems, there are printer problems. Somebody had better start fixing all of them, or eCS will be as dead as IBM, and Microsoft, wishes it was.

Doug, let's do something about it.

Do you know any NICs developer we can hire, or can set a quote to create a Wireless open source driver? on which drivers should we start? Can you talk to him and try to set a fund, bounty, whatever to help out?
Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 16, 2014, 06:28:05 am
Quote
Doug, let's do something about it.

Do you know any NICs developer we can hire, or can set a quote to create a Wireless open source driver? on which drivers should we start? Can you talk to him and try to set a fund, bounty, whatever to help out?

I would love to have the time to mess with that. Do you know any place where I can get some 48 hour days?   :(

The only qualified programmers, that I know about, are all working overtime, trying to get eCS 2.2 out the door, or get Firefox updated. There are probably many others who could do the job, if they were interested.

I have heard that it is not all that difficult to find an appropriate Linux driver, and plug it into the template that Mensys has provided. I started to look into doing it (wired NICs) myself, more than once, but never had the time to follow up (I do work on other projects, I do have a life, and I already don't get enough sleep without taking on more projects).

David A. is apparently scheduled to start on Intel wireless NICs, once eCS 2.2 is finished. He will probably follow that with Realtek wireless NICs (although he may not be interested after his bad experiences with Realtek wired NICs). After that, it is likely to be up to the users to provide drivers for the rest of the hardware that is out there. Somebody, with a little knowledge of software, and hardware, could make a nice hobby of making the drivers, once they figure out how to do it (apparently documented, in some detail). Of course, we can't expect anyone to run out and buy all of the possible devices (which is likely not possible anyway), so others need to provide testing, and semi-intelligent feedback, when something works, or doesn't work.
Title: Re: Closed source parts of eComStation
Post by: Michael Holzapfel on January 16, 2014, 07:31:34 am
After that, it is likely to be up to the users to provide drivers for the rest of the hardware that is out there. Somebody, with a little knowledge of software, and hardware, could make a nice hobby of making the drivers, once they figure out how to do it (apparently documented, in some detail).
Most probably these volunteers need access to the DDK, which is not available online. So it is hard for "hobby-programmers" to provide code for device drivers or even experiment with the existing code.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 16, 2014, 01:28:09 pm
Most probably these volunteers need access to the DDK, which is not available online. So it is hard for "hobby-programmers" to provide code for device drivers or even experiment with the existing code.

You are right, but it is also good to remember that anybody that has eCS has the Developer Kit on the CD#2.

About the "IBM Device Driver Development Kit 2004" (different kit), I got permission from IBM to repost all the documentation on the EDM/2 (http://www.edm2.com/index.php/IBM) (sorry but I still do not finish that migration). The sad thing is the license that the Device Driver Developer Kit has. It has a license that does not allow open source derivative work. But there is also a good thing, we have a lot of open source drivers (http://www.os2world.com/wiki/index.php/Category:Open_Source_Software#Drivers) that can be used as a templates.

It will be a good thing if someone can pin point me to the programs that are required to create drivers that came from the "Device Driver Developer kit" CD and have no replacement.
Do we still require the old Microsoft C to compile drivers? any thoughts?
Title: Re: Closed source parts of eComStation
Post by: Michael Holzapfel on January 16, 2014, 01:49:15 pm
Do we still require the old Microsoft C to compile drivers? any thoughts?
The recent device drivers require openwatcom compiler (e.q. os2ahci), but of course are still depending on DDK and Toolkit.
Title: Re: Closed source parts of eComStation
Post by: Pete on January 16, 2014, 04:16:33 pm
Hi All

Just to emphasize Dougs point about connectivity problems.

I recently purchased a 2nd user Dell E5500 laptop.

I installed eCS 2.2 beta 2 on it.

Bad move as I then found that there was no chance of getting the touchpad to work - who wants to carry an extra mouse around with them? - and even less chance of getting the wired or wireless nic work.

The wired nic is a broadcom netxtreme gigabit device that is too new to work with ye ancient b57.os2 nic driver and I could not, despite a lot of help from Doug and others, get genmac to work with the Windows 2K/XP drivers available.

The comments about trying genmac apply to the wireless nic, a Dell 1510 Wireless-N (made by Broadcom), as well as the wired nic.

I did email Broadcom and politely ask if there was any chance of them releasing the source code for the b57.os2 driver as it would be a good starting point in creating a native os/2 driver for current broadcom wired nics. Their response was a simple reply: "No support os/2". Thank You, Broadcom - I'll add you to my "hardware to be avoided" list.

So, I have a nice laptop with an eCS 2.2 install, no touchpad and no connectivity.

Solution options:-

1] Keep laptop and forget using eCS on it; Not an option as I bought a laptop so that I can carry on working if my wife wants to go to bed - our home office takes up a little bedroom space....

2] Sell laptop for close to what I paid for it and find an alternative laptop that *may* work.

3] However, I do not plan on spending lots of time buying and selling laptops in order to find something that works - and I'd rather have something reasonably current rather than a 10 year old laptop.

As you can guess from the fact that I asked broadcom for the b57.os2 source code I could have been interested in developing a wired nic driver.

What I find totally off putting is the amount of time I would need to spend getting to grips with the tools required for such development. It seems that I would not only have to relearn "c" - not a huge task in itself as my usual programming language is pascal which is closely related to "c" - but I would also have to discover what compiler and toolset is required and learn how to use them.

Most off putting.

Why do drivers need to be written in "c"?

What compiler is required?

What toolset is required?

How long will it take to get to grips with this development system bearing in mind that I'd probably only have, at most, 2 hours a day for 3 or 4 days in the week? - I suspect that by the time I got a working driver built the hardware would be obsolete...


I really could not see any obvious answers to the questions in 3] so have opted for 2]

If I was actually earning by building a nic driver I would be able to spend a little more time on the project but would still only manage between 16 to 20 hours a week - I just have too many other things going on in my life  :-)


Regards

Pete






Title: Re: Closed source parts of eComStation
Post by: Eugene Gorbunoff on January 16, 2014, 04:57:45 pm
To Pete
* touchpad - did you tried disable and enable it again using Fn keys?
* WiFi - the users of Thinkpad apply patched BIOS to remove White list and insert supported Intel 4965AGN adapter.
Title: Re: Closed source parts of eComStation
Post by: Pete on January 16, 2014, 06:30:23 pm
To Eugene

1] The touchpad does not work because the laptop has a shared ps/2 port and that is not coded for in OS/2. All I can really tell you about the touchpad is that Windows7 "sees" it as a *standard* ps/2 connected mouse and uses *standard* Windows7 ps/2 drivers: i8042prt.sys and mouclass.sys.

2] Not sure if you are suggesting "patching" the Dell E5500 BIOS. If you are you are definitely talking to the wrong person as I would not know where to start - and doubt that it would be of any use. The Dell supplied Windows2k/XP drivers do not work with genmac - nor do any from Broadcom - and I doubt "patching" the BIOS will help.

I'm not really interested in trying possible fixes for this laptop any more. I've spent far too much time on it already so it is up for sale.

Maybe I'll replace it with a Thinkpad...


Thanks for your interest though.


Regards

Pete
Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 16, 2014, 06:51:38 pm
Quote
there was no chance of getting the touchpad to work - who wants to carry an extra mouse around with them?

I have a Lenovo ThinkPad T510. That one has a BIOS setting to enable/disable the TouchPad. I disable it because I HATE those things, but it does work with eCS. The stickmouse works well, and I don't mind using it (for short periods), but I do carry a real, wireless mouse, to use for longer sessions.

I also have a newer Lenovo ThinkPad L530. The stickmouse, and Touchpad, both work. Unfortunately, there is no way to turn off that ANNOYING TouchPad (the windows driver has a way to do it). All that I was able to do, is cover it with a piece of heavy cardboard, to keep my paws off of it. I also have a real mouse tor that one. FWIW, I also installed PCLinuxOS on it. Neither one of those devices will work with that (I haven't tried too hard), so I need to use the real mouse.
Title: Re: Closed source parts of eComStation
Post by: Fahrvenugen on January 16, 2014, 08:05:11 pm
More important, are things like support for the majority of NICs that exist today, and in the future. Without communication (especially wireless), nobody will be able to continue using eCS. It just won't do the job. It can't always do the job today, without wireless communications. There are keyboard problems, there are video problems, there are printer problems. Somebody had better start fixing all of them, or eCS will be as dead as IBM, and Microsoft, wishes it was.

I have to agree, especially on the wireless and wired network drivers I'd put higher priority on this then I would on the 4GB barrier.

Just as a real-use example, not long ago I set up a customized desktop machine.  The machine needed to run a specific task 24x7 where it grabs information off the web and then feeds it to some old DOS-based apps which then feed the data to some custom hardware.  The system also needed the ability for someone to push specific information to it in place of the web-based data.  Originally the setup involved multiple computers (one computer receiving the data over a network and pushing it out a COM port and the DOS comptuer(s) running their apps receiving the data over the COM port and then processing the data to the custom hardware).  With OS/2 I was able to consolidate it all into a single computer - running a few DOS boxes for the DOS apps, OS/2 apps for the network stuff, and a custom REXX script to sort everything else out.  In testing it all worked out better then the original setup.

The biggest challenge I ran into was networking.  Where this computer has to be located there is no direct ethernet connection but there is stable secure Wifi.

What I ended up doing is I set up the OS/2 computer to use a standard Ethernet card that has drivers.  I then used a D-Link DIR-615 (cost of around $20) router and installed DD-WRT on it. I then set up the DD-WRT box to log into the Wifi signal and I have regular Ethernet cable connecting the 615 to the OS/2 box.  It works like a charm.

Admittedly part of my challenge was that I decided to use a spare OS/2 Warp Connect license that I had unused sitting on my shelf for this test setup.  I have no expectation to ever get Wifi working on Warp Connect, so this might seem like an insignificant example to use as an argument for good Wifi and NIC drivers.  However in this case networking and being able to find a way to connect to a Wifi network was absolutely necessary for the setup.  The 4 GB limit played no role in my decision to set up an OS/2 system.

Title: Re: Closed source parts of eComStation
Post by: Boris on January 16, 2014, 08:28:36 pm
I have to agree, especially on the wireless and wired network drivers I'd put higher priority on this then I would on the 4GB barrier.

<...>

Admittedly part of my challenge was that I decided to use a spare OS/2 Warp Connect license that I had unused sitting on my shelf for this test setup.  I have no expectation to ever get Wifi working on Warp Connect, so this might seem like an insignificant example to use as an argument for good Wifi and NIC drivers.  However in this case networking and being able to find a way to connect to a Wifi network was absolutely necessary for the setup.  The 4 GB limit played no role in my decision to set up an OS/2 system.
Okay, if we're posting our (IM)NSHOpinons here, then I will share my experience.

I had never had a networking trouble with OS/2 that I could not resolve.

I'm putting the 4 GiB barrier resolving task the upper priority than the NIC drivers thingy, because the lack of the drivers for the newest NICs never had played a role in my decision to set up OS/2 systems.



To explain this I'll say that if we cannot substantively argue on the tasks' priorities, and we rollback to the stinky democracy, I will just give my vote to the 4 GiB task, and see what'll happen.
Title: Re: Closed source parts of eComStation
Post by: Dave Yeo on January 16, 2014, 10:13:38 pm

The whole address space, on OS/2, that you can use with A LOT of processes (programs), is limited to 4 GiB.
So, even if you have the swapping feature enabled and large enough hard disk, you cannot run 500 programs to allocate 500 GiB (one GiB per process).

You could if the swapfile wasn't limited in size and you could put up with the thrashing. In theory the limit is 64 TB minus kernel and hardware space. In practice I think the limit to the swap file is 2 or 4 GB.
Quote
While on Windows 32-bit, one program still cannot allocate more than 4 GiB, but you can swap on your hard disk and allocate 500 GiB with a lot of processes.

Generally Win32 can only use 2GB (3GB with the /3 switch) whereas  OS/2 before Ver4.5 could only use 512MB (drivers such as HPFS386 cache could use higher memory) while v4.5+ can use the 512MB low area (minus shared s really like 300MB) plus memory above 1 GB which depending on the VirtualAddressLimit setting and hardware can be another 2.5GBs. Not every program can use the high memory and 16 bit programs are limited to the lower memory.
In real life we could still link the Mozilla xul.dll while Windows first needed the /3 switch then had to go to the 64bit version to map out a full 4GBs.
See http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html for a decent overview.
Quote
So, the trick is to put the swapfile not on the harddisk, but on the ramdrive, which would be able to map the memory above the 4 GiB limit using PAE without affecting the rest of the system.

So, that is the limit I am talking about. It could be overcomed by reimplementing the memory management subsystem in the OS/2 kernel.

I tried allocatting 4.5 GBs here but with only 1.5GB of real memory I gave up after an hour and half of disk churning. It would be interesting to test on a system with 4GBs of memory and also to test with the swapper on a PAE ram disk.
Not being much of a programmer I simply modified allocmem to use high memory and not exit right away. Here it would allocate 900 MBs per instance and I tried launching 5 instances. Warp V4 froze pretty quick while eCS 2.1 thrashed for 1.5 hours before I reset the computer. So if testing be prepared for a crash. Here is the program.
Title: Re: Closed source parts of eComStation
Post by: Pete on January 17, 2014, 12:59:23 am
Hi Boris

I had never had a networking trouble with OS/2 that I could not resolve.


We can soon change that: purchase my Dell E5500 and see if you can get either wired or wireless nic working. Of course, getting both working would be ideal - but just 1, either wired or wireless, would be very good  :-)

This is the 1st system that I have failed to get eCS (OS/2) networking to work on but it is also the most modern laptop that I've tried to install eCS on.

Yes, it would be nice to be able to use 4Gb or more of RAM - not sure what for though. I have a minimum swapfile of 2Mb and that never gets used so having a large ramdrive for a swapfile would currently be an exercise in futility.

I'd rather have connectivity and the 3.5Gb (or thereabouts) RAM limit if I had to chose.


Regards

Pete


Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 17, 2014, 03:03:55 am
Maybe the most interesting driver to port is the "iwlwifi" project for people with Intel Wifi NIC:

http://wireless.kernel.org/en/users/Drivers/iwlwifi (http://wireless.kernel.org/en/users/Drivers/iwlwifi)
Intel® Wireless 7265 (3.13)
Intel® Wireless 7260 (3.10)
Intel® Wireless 3160 (3.10)
Intel® Centrino® Advanced-N 6235 (3.2)
Intel® Centrino® Wireless-N 2230 (3.2)
Intel® Centrino® Wireless-N 2200 (3.2)
Intel® Centrino® Wireless-N 105 (3.2)
Intel® Centrino® Wireless-N 135 (3.2)
Intel® Centrino® Wireless-N 100 (2.6.37)
Intel® Centrino® Wireless-N 130 (2.6.37)
Intel® Centrino® Advanced-N 6230 (2.6.36)
Intel® Centrino® Wireless-N 1030 (2.6.36)
Intel® Centrino® Advanced-N 6205 (2.6.35)
Intel® Centrino® Wireless-N + WiMAX 6150 (2.6.30)
Intel® Centrino® Advanced-N + WiMAX 6250 (2.6.30)
Intel® Centrino® Ultimate-N 6300 (2.6.30)
Intel® Centrino® Advanced-N 6200 (2.6.30)
Intel® Centrino® Wireless-N 1000 (2.6.30)
Intel® Wireless WiFi 5150AGN (2.6.29)
Intel® Wireless WiFi 5100AGN, 5300AGN, and 5350AGN (2.6.27)
Title: Re: Closed source parts of eComStation
Post by: Mick Head on January 17, 2014, 04:02:19 am
I'd rather have connectivity and the 3.5Gb (or thereabouts) RAM limit if I had to chose.

Agreement on this point. I consider these to be critical functionality.

Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 17, 2014, 10:28:15 am
Well about strategy - the following idea is not new - we talking about 10 years about this:

If you develop or maintenance a niche system, with I'll guess less than 10.000 users world wide (maybe much, much less) which has absolutely no relevance for any hardware manufacturers, you can't do the "universal thing" anymore. This OS can't run on any hardware. A first step would be to face it!

Trying to make the Universal OS is part of the problem and not the solution.

The solution is to focus on a small set of systems. Make eCS right for a couple of systems. One system, for each class, like

1 or 2 desktop PCs
1 or 2 notebooks
1 server

As the OS vendor you have than
- great reference systems to show whats possible
- easier support
- much less development efforts
- easier installation (in fact you don't need to install, you can clone the whole thing)
- a chance to sell hardware with pre-installed software and make some additional money with hardware

To be honest this idea is not mine it comes from Apple while they played in a niche, a niche multiple times bigger than ours.
Title: Re: Closed source parts of eComStation
Post by: Boris on January 17, 2014, 12:19:56 pm
(in fact you don't need to install, you can clone the whole thing)

Actually it's not a problem to unrar and sysinstx any OS/2 version.
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 17, 2014, 01:14:22 pm
Actually it's not a problem to unrar and sysinstx any OS/2 version.

Yes sure and with similar hardware you don't get in trouble with periphery, switches, kernels,  drivers, paths etc .pp... and it is even more easy.

Title: Re: Closed source parts of eComStation
Post by: Alex Taylor on January 17, 2014, 04:37:18 pm
The problem is that the hardware cycle is really too short for that to work.  Apple could do it because they controlled the hardware specifications (which they were influential enough to do even at their weakest).

The turnaround time for a particular system model is AFAIK on the order of 3-6 months.  That's just not enough time to develop the driver support, QA it and release before the system is obsoleted by the next model.
Title: Re: Closed source parts of eComStation
Post by: Andreas Schnellbacher on January 17, 2014, 07:00:06 pm
The problem is that the hardware cycle is really too short for that to work.

The turnaround time for a particular system model is AFAIK on the order of 3-6 months.  That's just not enough time to develop the driver support, QA it and release before the system is obsoleted by the next model.

Alex, I think you're misinterpreting the proposal. The idea is to pick at least one model and develop all the essential drivers for it. It has nothing to do with the life cycle of that hardware. We all use really outdated hardware and know where to buy it, so that won't change then.
Title: Re: Closed source parts of eComStation
Post by: Paul Smedley on January 17, 2014, 09:08:04 pm
Quote
Four developers work on OS/4 kernel for years.

Yes, and they are 4 developers who are wasting their time,

IMHO those 4 developers can spend their time working on whatever they choose to and are interested in. They're doing what they're doing for free.

Same situation with me, I work on what interests me. Yes - if someone asks for a port it will be considered, but at the end of the day, it's my time.....
Title: Re: Closed source parts of eComStation
Post by: Paul Smedley on January 17, 2014, 09:32:25 pm
Maybe the most interesting driver to port is the "iwlwifi" project for people with Intel Wifi NIC:

http://wireless.kernel.org/en/users/Drivers/iwlwifi (http://wireless.kernel.org/en/users/Drivers/iwlwifi)

Maybe it is, but I've created a new thread at http://www.os2world.com/forum/index.php?topic=312.msg2515#msg2515 for users to post the networking chipsets they require support for, in order to better understand the demand.

Not committing to work on multimac, but I'll admit to being curious on how difficult it would be to port a NIC driver.

Cheers,

Paul
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 19, 2014, 12:19:57 pm
Quote
Four developers work on OS/4 kernel for years.

Yes, and they are 4 developers who are wasting their time,

IMHO those 4 developers can spend their time working on whatever they choose to and are interested in. They're doing what they're doing for free.


True! Nobody can be forced to do anything in his spare time. And nobody should blame them for what they doing. There is no reason to be angry or rude. But it doesn't change the fact that >4GB RAM doesn't solve any single issue as long as we have no software that uses this amount of RAM and as long we have tons of cheaper basic problems. 4GB RAM limit is at the moment a theoretic problem. But we (people doing work with eCS and don't use it as a playground beside 2 other systems) have problems in practice here and now. To name these problems it not to blame these 4 developers but maybe to change the mind of people who are responsible for eCS development. The basic question is: should eCS be a system for 'i need always latest high end hardware' junkies or for users and productivity.

Quote from: Alex Taylor
The problem is that the hardware cycle is really too short for that to work.  Apple could do it because they controlled the hardware specifications (which they were influential enough to do even at their weakest).

The turnaround time for a particular system model is AFAIK on the order of 3-6 months.  That's just not enough time to develop the driver support, QA it and release before the system is obsoleted by the next model.

That's true! But you have exactly the same problem when you try to make it fit to all (or to a wide range) of hardware. Of course it would be easier to focus on less hardware. ' latest hardware' junkies will be switch to other systems anyway which course we take.

And there is always hardware which is available for longer time. E.g. I'm using at work a board from 2010 which is still available.




Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 19, 2014, 10:03:01 pm
Quote
IMHO those 4 developers can spend their time working on whatever they choose to and are interested in.

True, but I still think they are wasting their time. Breaking the 4 GB barrier is not the thing that will save eCS (OS/2).

ECS must be usable, today, with the limited software that is already available. It is very quickly becoming unusable because far too many basic things are not working (modern WiFi, Bluetooth, disks larger than 2 TB, WLAN, USB 3,0). If a user needs one, or more, of those features, they must go elsewhere. Once they do that, it is highly unlikely that they will ever come back. 4 knowledgeable programmers could make a huge difference, if they worked on the immediate problems, and put things like breaking the 4 GB barrier on the back burner for a while. If they don't do that, by the time they get the 4GB thing worked out (including making some software that might actually use it), there  won't be enough eCS users left to care.

Quote
And there is always hardware which is available for longer time. E.g. I'm using at work a board from 2010 which is still available.

The problem with that approach, is that it is impossible to tell what hardware will stay around for a while (the manufacturers would never tell, and if you happen to pick something that has problems, you are stuck with it). It is also not going to help to bring back those who left, or encourage anybody to switch from some other OS. It is bad enough that they have to PAY for eCS, when Linux is free, never mind have to buy an obsolete computer (all computer equipment is obsolete by the time it hits the store shelves), with, possibly, difficult to find peripherals, just to be able to run this expensive option. The main advantage to using a small "supported" hardware base, is that those who really care, can usually spot clearance sales for those devices that actually work.

The only possible way to make a small number of "supported" hardware actually workable, would be to buy a couple of hundred identical systems, put them on the shelf until everything works, then try to sell them preloaded with eCS. That would be financial suicide for anybody who wanted to try it. Apple gets away with it because they buy parts by the thousands, and they have a big team of programmers to get the parts working in a timely manner, so the systems don't sit there for a couple of months, before they can be sold. Most knowledgeable eCS users are very careful about what they buy anyway, but it is usually impossible to determine what does work, and what doesn't work, until you try it. After you try it, it can be difficult, if not impossible, to exchange the device, or return it, so then you need to make the decision about what to do next. Sometimes problems get fixed in short order, but more often, it takes at least 6 months (more typically a year) to get problems fixed. I have noted that problems that don't get fixed within a year, hardly ever get fixed, although it does happen when enough people beat on Mensys.

Virtual machines are also touted as being an option. True, they are, but then the user is presented with the problem of deciding which OS to use for each program. There are a few OS/2 only programs that are cherished by many users, but something like Firefox will be available in the host system, usually more up to date, and with fewer problems, than using Firefox in OS/2. All of those programs that have been ported from the host system, will also work better in the host system. Suddenly, OS/2 becomes a small part of the big picture, and as the user learns more about the host system, they find newer programs that work just as well, so they switch, simply because it is easier than trying to keep a virtual machine going.

IMO, the only answer is to put as many resources as possible, into keeping eCS up to date, and working on as much new hardware as possible. Doing that will prolong the life of the product, but it certainly will not stop it from dying, eventually (all good things come to an end, when something better comes along). If eCS is not kept up to date, it will die faster, simply because it won't be usable. The trick is to make priorities, and don't worry about those things that are not needed immediately. Things like the 4 GB barrier will eventually work their way to the top of the list, if OS/2 survives that long, but ignoring things like modern WiFi, will kill it faster, and that will make working on the 4 GB barrier (and other things like that) entertaining, but a total waste of time.

The only other option, that I can think of, would be for somebody to win a BIG lottery, and turn most of the money over to OS/2 development. Even then, it is unlikely that IBM, or Microsoft, would take on the job, and it would likely take one of them to get it done in a timely manner (not to mention that about half of the money would need to be used for legal fees, to be sure that the job gets done properly).
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 20, 2014, 05:32:16 pm
Doug,

I don't agree. 5 systems are less than all systems. Less hardware combinations to support is less work than to support all. Thats pretty easy.  When you support all you also support these 5 I would like to support. So all problems to support only 5 systems are at all systems inclusive. All arguments against a support of a small set of hardware are still there when you develop for all or a wide range of hardware.

To support less systems but right would be much better than support a a lot of systems half.

Another point: I talked with the ACPI developer some months ago and asked him if it helps when he had the hardware he develops for close to him at his working place. I suggested that we send him a computer and then he could make ACPI working really great and full featured on this computer. He agreed!  (we didn't send the computer but that's another story...)

To support a special hardware a company could invest 300 bucks for the computer and the driver developer gets this machine. He can test his work with direct access. Any doubts that that would be very helpful?

But for now if you ask Mensys about a working hardware you might not get an answer.

Btw I don't say this solves all problems and brings all old os2 users back. This wont happen. Maybe it could save the status quo.

Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 20, 2014, 06:32:02 pm
Quote
I don't agree. 5 systems are less than all systems. Less hardware combinations to support is less work than to support all. Thats pretty easy.

I think we will need to disagree.  :)

You can say "5 systems", but those 5 systems may not be available everywhere, so then you need to substitute the nearest 5 systems that may be available in the US, Europe, and Asia. So, now you have 15 machines to support. It is probably true that they will all be similar, but you don't know that until you test them all (if you can get all of them to the developer). So, you spend a month collecting, and analyzing them, and developing the code for them (it will likely be closer to two months). Then, you need to do some serious testing, to be sure that every one of them works properly. Okay, now you are at least 2 (probably 3) months into the project, you decide that those are the machines to use, so you publicize what the user needs to get. They delay for a month, to decide what to do. By that time, most, if not all, of those machines will not be available (if the user is lucky, they will be on clearance sales). Now what do you do? Well, you start over, and the same thing happens again. There is no guarantee that the next model released by the manufacturers will even be similar to the old model, never mind the same.

Limiting the number of supported systems is a self defeating project, and as you do agree, it will not encourage new users, and it will not encourage old users to return. It may be necessary, eventually, to go that way, but I suspect that it will just encourage more users to look at other alternatives.

I don't know what the answer is. There are not enough active developers left to do what needs to be done, and not enough users are participating in what is being done. Your idea to send the developer a machine, is a good one, but I suspect that there are legal complications to doing that, if the machine needs to cross borders. It is also only one machine, which may open the door to making many more machines work, or whatever gets developed may apply only to that machine. You don't know that, until it is released for further testing. You probably don't even know that all of the parts in any 5 machines will be the same. So, you send one to the developer, he gets it working perfectly, then you find out that the other 4 have something different. Now what?

It all comes down to two problems:
1) There are not enough developers working on the problems.
2) There is not enough money to pay other developers to work on the problems.

To get back on topic: Worrying about getting open source replacements for bits of OS/2 that are not causing serious trouble today (the kernel), or will take a huge amount of development time (WPS), simply distracts from the immediate problem (OS/2 is quickly becoming unusable, for the average user). Most of the missing parts are probably not that hard to develop (USB 3.0, Bluetooth, etc.), if somebody has the time to do it. Each one of them is another nail in the coffin, and they can be open sourced, if the developer wishes to do it that way, but they must be done soon.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 20, 2014, 08:57:41 pm
...what it is going to save OS2-eCS?

I don't know for sure, but I still insist that open source is the only path I know to save it.

We need to became first open source. Any driver, DLL, exe, documentation, WPS classs, that is open source will add up to that path. We need to be independent from IBM, Serenity and Mensys. Once we reach the independence for the platform, we can start building an ecosystem with individuals/companies selling support, software and services. Instead of what we see today, individuals/companies trying to squeeze the last cents of this community/market with more close source software.   

That why, no matter if it takes us 10 or 20 years, open source should be the path.

Open source it is not salvation, it is only the path, but the we, the community, on a group effort, are the only ones that can save this platform. We need to grow the community and walk the open source path for the benefit of the group.

Don't expect miracles from IBM, Serenity, Mensys or XUE. We are the only ones left.
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 22, 2014, 09:59:57 am
Open Source is fine - you are doing a nice job here to collect the code.

But more important are the people behind. Software can also be successful as closed source as along as the software has not been abandoned. If software can't be Open Source (e.g. maybe the Sundial applications) it would be really nice if it could be maintained as closed source by a group of people.

There are several examples where a single developer or a group keeps / kept  things running. A good example was the ProNews development taking over a closed source program in supported charity ware. An annoying example is PMMail which binds the license on a membership on a club.

Also on Open Source usually only few people (or one man) are working. That's the situation today.
 
And of course you need users doing tests and report bugs. Actually we have a lot of ports which are completely untested.

To have both, people at development and user side we need to keep the basic things running like standard software and basic hardware at first. If users and developers leave then the system dies and we have a big graveyard of open source software.
Title: Re: Closed source parts of eComStation
Post by: Dave Yeo on January 22, 2014, 04:36:33 pm
Other potential problems with some open source licenses such as the GPL is when the source does get lost. Suddenly can have a nice working binary which can not be distributed. I've come across this situation a couple of times, once did get the author to re-license.
There is also the problem with the GPL not being compatible with so many other open source licenses. I used to build and distribute glinks. Thought everything was good as all the libraries were open source with the source code available on Hobbes, where I was uploading. Turned out I had been breaking the GPL as I was linking OpenSSL to the binary. There are a lot of licenses which while open, are not compatible with the GPL, especially v2 and many a developer uses GPL without thought besides the fact that everyone is using it.
One solution is multiple licenses such as Mozilla uses, GPL, LGPL and MPL, take your pick.
Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 22, 2014, 06:40:25 pm
Quote
An annoying example is PMMail which binds the license on a membership on a club.

This needs to be clarified. OS2VOICE is dedicated to supporting OS/2, in all of it's forms. OS2VOICE bought the OS/2 source, for PMMail, and has taken on the job of rebuilding it (100% volunteer). There is a ONE TIME charge (equivalent to one, one year membership in OS2VOICE) that is charged by having the OS2VOICE member (you do need to be a member) pay an extra yearly membership (that was done to simplify accounting, and avoid having to pay for another way to collect the money). OS2VOICE also needs to have perks to entice users to pay yearly memberships, however, the PMMail license is a one time, lifetime, thing. If a user fails to renew their membership, the license is still good. Oh yeah, the purchase of the program source, included a restriction that OS2VOICE has 100% ownership of the OS/2 version of PMMail, however, they have no rights to port it to other platforms. That does mean that it cannot be licensed using anything like GPL. The license is fixed by the purchase restrictions.

Currently, there is ONE programmer working on it, part time, with a couple of others who sometimes make contributions. It has proven to be an enormous, time consuming, task. Any programmers who might be interested are invited to apply.

Now, you also need to realize, that OS2VOICE is a non-profit organization. Membership fees (including what is paid for PMMail), is used to support the OS2VOICE infrastructure (servers etc.). Any left over funds (apparently considerable) are donated to various OS/2 projects (obviously not advertized enough).

It is another case of too few people, and too much work, but it is being done. It is also another case where a good program (which never should have worked, in the first place - apparently, the code was horrible) has been saved from the dust heap of history. The source is not exactly "open source", but it has been preserved, and could be open sourced, if the purchase license can be changed to allow it. Meanwhile, funds from PMMail are supporting other OS/2 projects.
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 22, 2014, 08:17:24 pm
Well we had this discussion about the PMMail license 2 or 3 times last years and to be honest I'm tired to repeat it. Just one point or a summary: they could sell a license as it is just like a license without a membership to whatever. There should be no need to subscribe to something else no matter how holy or great it is. So I'm still using PMMail 2.2 and here and then a demo of v3 to test some things. I just write this that hopefully I never see that kind of license again on my life.  ;)

Btw, nothing against the developer.
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 22, 2014, 08:19:05 pm
Good point Dave!


One solution is multiple licenses such as Mozilla uses, GPL, LGPL and MPL, take your pick.

Or just the good old PUBLIC DOMAIN.
Title: Re: Closed source parts of eComStation
Post by: Doug Bissett on January 22, 2014, 10:10:30 pm
Quote
So I'm still using PMMail 2.2 and here and then a demo of v3 to test some things. I just write this that hopefully I never see that kind of license again on my life.

Your loss. PMMail (for OS/2 - the previous owner still owns the windows version) is owned by OS2VOICE and is made available as a bonus for their members. If you don't want to be a member of OS2VOICE, you cannot buy PMMail. It has nothing, at all, to do with the license for PMMail, it is simply the method that OS2VOICE uses to regain what they paid for it, and to be able to support PMMail, and other OS/2 projects, as well as provide a bonus for members (who paid for the source in the first place). In other words, PMMail is a commercial product, that is for sale to those who support OS/2 by being a member of OS2VOICE.

I would note, that this is one of the few ways that users can financially support OS/2, and you may see a similar license, if OS2VOICE does the same thing with another program (not currently planned, AFAIK). I will mention again, that this was the only way to obtain the source for PMMail, and the source came with restrictions that prohibit making it open source, or porting it to other platforms. If OS2VOICE had not done that, PMMail 2.x would still be as usable as it has ever been (which is becoming less, and less, as new server features show up, not to mention that it could no longer be purchased), however OS2VOICE has added performance, reliability, and features to support new servers. It is well worth the cost (even if you do need to buy a membership), and you should remember that  the old PMMail was also a "pay for it", closed source, program. So nothing has changed, except who gets the money, and where that money ends up.

Is it "perfect"? Of course not. You cannot make that many changes, to fix things, without breaking things along the way. At least they usually get fixed, when the problem is identified, reported, and possible to fix. There are a number of problems still outstanding, waiting for a couple of major updates, that haven't got to the top of the list yet. Again, we see time, and personnel, restrictions on what can be done.
Title: Re: Closed source parts of eComStation
Post by: Fr4nk on January 22, 2014, 10:28:22 pm
I know Doug - that is exactly what I said (or at least meant - maybe my english is too bad). I know very good how this license works. The membership bundle is a decision by VOICE - and it sucks!

There is no reason to sell PMMail with a club membership. It could be sold by VOICE without a membership just like any other commercial software.

Maybe you got me wrong. I have no problem with commercial software. I would buy it but I wont apply to a club to get an email application. My loss like you said. I think this needs no further discussion.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 23, 2014, 02:28:06 am
I don't disagree that there is good close source software. But I prefer open source software because:
1) When the main developer goes out of business, anybody that cares can continue the development.
2) When the main developer quits the product and move to other direction, anybody that cares can continue the development.
3) When the main developer passes away, anybody that cares can continue the development.
4) When the main developer goes crazy and tries to lead to you to a wrong direcction, anybody can fork the project and continue in other direction.
5) When the main developer don't want to do an improvement, anybody that cares can collaborate can help to improve the project.

....and with all that possibilities, you can also make money (check out how RedHat had made money with Linux and is GNU GPL and open source) but you had to switch from selling licenses to offer services/support.

Open source reduces the risk and helps to maintain the continuity of the platform. Sure, we need developers, but open source is the legal path that helps developers to create derivative works.

Or just the good old PUBLIC DOMAIN.

I like public domain, but remember that this license means that any derivative work can be open source or close source, plus you do not necessary give credits to the original author.  On very liberal cases I also like the BSD 3 Clauses (http://opensource.org/licenses/BSD-3-Clause) which gives credit to the authors, it gives no responsibility to malfunction (AS IS) and easy to read.

Corporations like Apache or the eclipse licenses one that allows to create derivative works as close source, so they can give you a basic core as open source, and a full product as close source.

But I started to like the GNU GPL which is a copyleft license. It forces the developer of any derivative works to make the source code under the same conditions (GNU GPL). At the end that is what allowed Linux to snowball and keep growing.  If your focus is the community, ensure that the software will be open in the future, and don't care about future corporative benefits,  GNU GPL is a good choice.

But I'm ok with any OSI approved license (http://opensource.org/licenses).
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 23, 2014, 02:41:08 am
..and focusing in my crazy idea to start cloning OS/2 from "Top to Down", over eCS or Warp 4.52,  I think we need to evolve this three projects to turn it into full replacements.

1) Presentation Manager Clone - FreePM (http://frepm.sourceforge.net/) - BSD License
2) System Object Model (SOM) - SOMFree (http://sourceforge.net/projects/somfree/) - GNU GPL and LGPL V3
3) Workplace Shell  - XWorkplace (http://xworkplace.netlabs.org/en/site/index.xml) - GNU GPL V2 and other WPS software (http://www.os2world.com/wiki/index.php/Workplace_Shell_based_Applications)

Sadly, none of this projects are active enough to evolve into a complete replacement, but at least they will work a the base to walk on this direction.

Today I also found out that there is an initiative in  KickStarter (http://www.kickstarter.com/projects/thorium/thorium-core-cloud-desktop) to create a cloud "distro" of ReactOS. I'm just amazed to see how ReactOS has cloned Windows 32bits, anybody may complain that it is not perfect clone, but you had to acknowledge how far they have reached being a community without a strong technology sponsor.
Title: Re: Closed source parts of eComStation
Post by: Dave Yeo on January 23, 2014, 05:27:41 am

Or just the good old PUBLIC DOMAIN.

The problems with Public Domain are that some countries do not allow licencing as public domain and there has been cases of organizations copyrighting public domain stuff and closing it. To a lesser degree there has also been problems with people re-licencing BSD stuff as GPL and restricting the active branch.
One thing about licences such as BSD, it's great if you want something to be a standard. Examples include the TCP/IP stack which allowed the Internet to flourish and zlib where compression is standardized across platforms.
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on January 23, 2014, 09:28:45 pm
To a lesser degree there has also been problems with people re-licencing BSD stuff as GPL and restricting the active branch.

I don't think there is a problem creating derivate work from BSD license and making it GPL.  Maybe is a specific BSD license that can not be derived into GNU GPL... any other source is welcome.

http://en.wikipedia.org/wiki/GPL#Compatibility_and_multi-licensing (http://en.wikipedia.org/wiki/GPL#Compatibility_and_multi-licensing)
Title: Re: Closed source parts of eComStation
Post by: Dave Yeo on January 24, 2014, 02:16:26 am
It's perfectly legal, just that the BSD developers can't use the GPL licensed patches and shouldn't even look at them at risk of being accused of plagiarizing.
Generally it is good if fixes are pushed upstream so everyone can benefit but  guess some are worried about the wrong people benefiting. There's too much politics in the licensing department.
Title: Re: Closed source parts of eComStation
Post by: Olafur Gunnlaugsson on March 28, 2014, 07:21:02 pm
Regarding the multimedia subsystem, as far as the audio portion goes it would basically be better to start from anew since the OS/2 MM implementation was the first modern MM subsystem and is starting to show its age. In 1999 or 2000 Bob from Serenity systems said that the sourece code for the MM subsystem was available for those that wanted to work on it although it was not possible to open source it, does anyone know if the source was ever made available ?

I vaguely recall sending someone a mail about it at the time and not getting an answer ....
Title: Re: Closed source parts of eComStation
Post by: Martin Iturbide on March 28, 2014, 10:14:25 pm
Hi Olafur.

It is the first time I hear about that. (the the source code of MM subsystem was available for private use).

I don't know much about it, but maybe it can be also interesting to try to reuse some of Triton for trying to clone/improve MMOS2: http://trac.netlabs.org/v_triton

I know it is not complete, but maybe it can be useful for something.

Regards.