OS2 World Community Forum

Public Discussions => General Discussion => Topic started by: Joachim on July 06, 2015, 06:15:20 pm

Title: News from the front line
Post by: Joachim on July 06, 2015, 06:15:20 pm
Since early 2015 I am working fulltime on eComStation for XEU.com. Since that time we have been doing a lot of stuff in the background, for example updating the chinese build of eComStation (largely based on the excellent work of Alex Taylor of course) and for some weeks I've now been cleaning up the bugtracker. Some bugs recently set to resolved include:

3077: Patched TPCIP32.DLL needs to installed to prevent crashes in Mozilla apps on SMP systems.
3511: New ACPI and VMware
3409: USB keyboard and mouse not working

These have been fixed mainly by integrating newer level of drivers in eComStation, which has been done earlier, but it's still worth mentioning there is progress. In the coming weeks we will continue to clean up the bugtracker and work towards the release of eComStation 2.2.

Best regards,
Joachim Benjamins
Title: Re: News from the front line
Post by: Pete on July 06, 2015, 08:13:17 pm
Hi Joachim

Good to hear there is progress with eCS2.2 - I , amongst others, look forward to the release.


Regards

Pete
Title: Re: News from the front line
Post by: dbanet on July 06, 2015, 09:56:11 pm
Please open the bug tracker for users without an eComStation license to watch the progress (so that one can see what he/she will pay for: support) and fill bug reports (you ain't no gonna reject free bug reports, are you? Any software company has got testers, which don't work for free).

I cannot think of any reasons not to do that.
Title: Re: News from the front line
Post by: dbanet on July 06, 2015, 10:04:21 pm
Do you guys cooperate with Arca Noae (http://arcanoae.com/[/url)? They make quite some good progress and have people working on hardware drivers employed.

Does XEU have anything to do with Mensys?

What is the general plan for OS/2? Are you gonna keep the same thing: packing a distro with updates from community and rarely updating hardware drivers? Or something worthful?



Don't really hope for answers. Companies dealing with OS/2 behave so strange with the community.

(neither can't see how's that "front line", assuming so little progress. The front line is at another place)
Title: Re: News from the front line
Post by: ivan on July 06, 2015, 11:40:42 pm
Joachim said In the coming weeks we will continue to clean up the bugtracker and work towards the release of eComStation 2.2.

Is this like it was in 2013, then 2014 and now more than half way through 2015? 

Somehow I don't believe it will happen.  I would like to be proved wrong but past experience shows otherwise.

The items mentioned by Joachim are rather minor and have been addressed already by other people.  If they are the types of things on the bugtracker I can see why they will never open that to general view - it appears to be rather pathetic.

Now, if they were working on updated drivers to work with new hardware and updated SNAP Graphics, again to allow use with new graphic cards then it would indeed be news.  As it stands this 'announcement' is rather meaningless.
 
Title: Re: News from the front line
Post by: Martin Iturbide on July 06, 2015, 11:56:45 pm
Hi

I agreed that XEU deserves the heat after two years of no real news and no single software release, but I also noticed a boycott campaign by someone calling OS/2 community members one by one to tell to do not help XEU at all.

At OS2World I'm not going to be in the middle of "commercial strategies" or "hatred revenges". I hope I can assist anybody that wants to help this community and give something back to the platform as open source, so we do not repeat the history we had with IBM.

I really hope that XEU get up on his feet and show us something.

Regards
Title: Re: News from the front line
Post by: Sigurd Fastenrath on July 07, 2015, 08:32:47 am
Now, if they were working on updated drivers to work with new hardware and updated SNAP Graphics, again to allow use with new graphic cards then it would indeed be news. 

I have got an SSS at Mensys (now XEU I guess) and one from Arca Noae. When I look at them in a impartial/neutral way:

- Arca Noae: All the latest available main drivers are at hand, changes and progress are reported

- Mensys/XEU: Allmost nothing happend during the last years, no reports, no progress

If I remember correctly what I have heard at Warpstock Europe and what is written at Arca Noae http://www.arcanoae.com/arca-noae-a-new-name-but-with-familiar-faces/ (http://www.arcanoae.com/arca-noae-a-new-name-but-with-familiar-faces/) almost all "important" developers of drivers and system parts (A lot of the good software parts come from bitwise like Firefox, Java etc.) are in some way linked to Arca Noae.

As one can read from the changes of the 3.22.08 ACPI Readme David removed the checks that one need eCS to use this. So one can install it on Warp 4.51/2 i.e. (with latest free availiable kernel), so it seems to me that I am able to update my Warp 4.52 clone in a legal way and do personally do not have a need for eCS at all anymore.

I asked Joachim at Warpstock if it would be possible to say at least something about eCS - as it was a good chance to do so I thought - but I was not able to get any information. He said they would say something on Sunday but I already left on Saturday evening as I told him. I heard from another attendee that there has been something said when the micros have been turned off.

So it seems to me that there will be no eCS release (at least with the latest drivers availiable) as long as XEU does not have an agreement with Arca Noae or the Developers.

For me it would be interesting to know what kind of "License" one need to use the 106SMP kernel - is there a need to have an eCS license? Fortunately ACPI does work with Kernel 104SMP as well.

.. but I also noticed a boycott campaign by someone calling OS/2 community members one by one to tell to do not help XEU at all.

That really throws some light to some phonecalls I had, thanks for this information, Martin!






Title: Re: News from the front line
Post by: Dave Yeo on July 07, 2015, 08:47:12 am

For me it would be interesting to know what kind of "License" one need to use the 106SMP kernel - is there a need to have an eCS license? Fortunately ACPI does work with Kernel 104SMP as well.

That would be interesting to know, as well as its pedigree. Hearsay says it has been patched to fix issues with loading DLLs high. Has it also been patched to show 106SMP as well? And has IBM fixed anything since 2006?
Title: Re: News from the front line
Post by: Jan-Erik Lärka on July 07, 2015, 09:58:10 am
We look forward to the new eCS v2.2 and I'm glad to hear that there is progress.

Regards,
//Jan-Erik
Title: Re: News from the front line
Post by: Andreas Schnellbacher on July 07, 2015, 09:32:26 pm
And has IBM fixed anything since 2006?
The kernel 14.106 is a patched version of the last IBM kernel. It was done be Steve Levine, most likely initiated by Mensys.
Title: Re: News from the front line
Post by: Martin Iturbide on July 08, 2015, 02:55:38 am
And has IBM fixed anything since 2006?
The kernel 14.106 is a patched version of the last IBM kernel. It was done be Steve Levine, most likely initiated by Mensys.

Andreas, do you have any evidence/information/link of that?

As far as I know version 14.106 was part of IBM's XR_C006 fixpack (http://www.os2world.com/wiki/index.php/Updating_OS/2_Warp_4.52) released around Feb of 2007.  This is the last one that I know that IBM coded for OS/2. I don't know if there is any other kind of kernel patch or release from that version. (beside OS/4 which is a different kind of project)

By the way, I tried to documented the last things released by IBM for Warp 4.52 on this wiki page (http://www.os2world.com/wiki/index.php/Updating_OS/2_Warp_4.52), if I'm missing something please let me know.  And by the way, it is sad that I was never able to get my hands on the latest "APARs" patches that was not included on any fixpacks.

Regards
Title: Re: News from the front line
Post by: Fahrvenugen on July 08, 2015, 03:27:11 am
Hi

...but I also noticed a boycott campaign by someone calling OS/2 community members one by one to tell to do not help XEU at all.

Hi,

One thing that we all need to keep in mind is that regardless of the fact that 2.2 has been promised for several years and has not been released, we still need XEU around - if only for the fact that it is the only way to easily get new eCS / OS/2 licenses.  If a boycott were to take place then it is entirely possible that XEU's revenue on the product would drop to nothing, which could eventually lead to a the product being withdrawn.  For that reason, I can't see any benefit to such a campaign.

Without XEU, then there is no way to license a new copy of OS/2 / eCS (and I'm not talking about used ebay copies that you have to apply a bunch of fixes to)

Title: Re: News from the front line
Post by: Dave Yeo on July 08, 2015, 06:42:02 am
And has IBM fixed anything since 2006?
The kernel 14.106 is a patched version of the last IBM kernel. It was done be Steve Levine, most likely initiated by Mensys.

Andreas, do you have any evidence/information/link of that?

As far as I know version 14.106 was part of IBM's XR_C006 fixpack (http://www.os2world.com/wiki/index.php/Updating_OS/2_Warp_4.52) released around Feb of 2007.  This is the last one that I know that IBM coded for OS/2. I don't know if there is any other kind of kernel patch or release from that version. (beside OS/4 which is a different kind of project)


XR_C006 was build level was 14.105, which I believe was shipped with eCS 2.1. and dated October 18, 2006, according to README.1ST The 14.106SMP kernel is only available on the 2.2 beta releases (at least I got it from 2.2b2).
Looking at README2, there are only 10 APARs fixed with XR_C006, and that includes a fix for a TRAP 0 when connecting a ZIP drive to a parallel port. Most of the others were important including support for 2TB drives.
Title: Re: News from the front line
Post by: Martin Iturbide on July 08, 2015, 03:06:15 pm
XR_C006 was build level was 14.105, which I believe was shipped with eCS 2.1. and dated October 18, 2006, according to README.1ST The 14.106SMP kernel is only available on the 2.2 beta releases (at least I got it from 2.2b2).
Looking at README2, there are only 10 APARs fixed with XR_C006, and that includes a fix for a TRAP 0 when connecting a ZIP drive to a parallel port. Most of the others were important including support for 2TB drives.

Hi Dave.

I can confirm you, I have a VM OS/2 Warp 4.52 machine with XR_C006.
It has the 14.106W4 kernel (849283 bytes. Feb/13/2007 9:33am), checked with bldlevel.  I just checked it right now.

But I don't know where 14.106SMP comes from (IBM or Mensys). I don't have it installed.

Regards
Title: Re: News from the front line
Post by: mike on July 09, 2015, 11:22:09 pm

.. but I also noticed a boycott campaign by someone calling OS/2 community members one by one to tell to do not help XEU at all.

That really throws some light to some phone calls I had, thanks for this information, Martin!

Interesting fact that people got mad to do something like this... unpaid people from the old company? In general people should decide on their  own. XEU was announced over a year now. Not much has happened since..  XEU needs new updates for eCS or they will just try to sell what they just have - the time will tell.

Title: Re: News from the front line
Post by: Pete on July 09, 2015, 11:44:28 pm
Hi Martin

I just unzipped the kernel files, os2krnl*.___, fromxrc006 as I do not remember 14.106 being available back then.

Here is what I see after unpacking the W4 kernel:-

[S:\BACKUPS\G\DOWNLOAD.ECS\XR_C006\FIX\OS2.5]unpack os2krnl.___
os2krnl.___
- OS2KRNL
       0 file(s) copied.
       1 file(s) unpacked.

[S:\BACKUPS\G\DOWNLOAD.ECS\XR_C006\FIX\OS2.5]bldlevel os2krnl
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:14.105#@_W4  IBM OS/2 Kernel
Vendor:          IBM
Revision:        14.105
File Version:    14.105
Description:     _W4  IBM OS/2 Kernel

[S:\BACKUPS\G\DOWNLOAD.ECS\XR_C006\FIX\OS2.5]


The smp and uni kernels are also reported as build 14.105

Looks like it was kernel 14.105 supplied with xrc006 - at least for eCS users.

I did notice that the readme gives the xrc006 fixpack a buildlevel of 14.106 - could that be causing confusion?


Regards

Pete
Title: Re: News from the front line
Post by: Alex Taylor on July 10, 2015, 04:54:30 am
14.106 is certainly an official IBM release. Several people have told me that it came with XR_C006. However, I seem to recall that the XR_C006 that was leaked publicly was a beta version. Perhaps the final, official version of XR_C006(which AFAIK was only available to IBM customers and presumably OEM partners like Mensys) contained 14.106.
Title: Re: News from the front line
Post by: Martin Iturbide on July 10, 2015, 05:59:21 pm
Hi

I have XR_C006 and XR_C006-B which was a pre-release. I will check later which kernel is on XR_C006-B.

Regards
Title: Re: News from the front line
Post by: Andreas Schnellbacher on July 10, 2015, 08:35:44 pm
Note that the eCS kernel contains patches from Holger Veith to avoid traps on unloading DLLs marked as high. Without it we can't use OS/2 anymore to  have a Mozilla app and OpenOffoce simultaneously open.
Title: Re: News from the front line
Post by: ivan on July 10, 2015, 09:15:28 pm
Is that because both of those programs rely heavily on ODIN code?

You also realise, I hope, that by using uncertified patches on an IBM kernel means that that kernel can't be used where system certification is required.  This was one of the arguments that was used against the OS/4 kernel project.  Obviously what goes round comes round.
Title: Re: News from the front line
Post by: Dave Yeo on July 11, 2015, 01:15:45 am
Is that because both of those programs rely heavily on ODIN code?


Mozilla doesn't use any Odin code and is native (actually xul that pretends to be native on all platforms) and I think that the recent versions of OpenOffice are pure native as well. Plugins such as Flash and Java do use Odin.
The problem is just the size of the code (and data). For Mozilla, xul.dll by itself is over 32MBs after using lxlite and I just fired up SeaMonkey and it has allocated 255 MBs of shared memory of which about half is committed. Certain web sites will raise that a lot. I only have about 300 MBs of free low shared memory after booting so load a few JavaScript heavy pages and the system will get unstable, SeaMonkey will crash and the system itself might not recover unless using high memory. I assume that OO is similar and running both together becomes impossible without resorting to high memory.
Our operating system was designed originally in the '80's and the 32 bit part was designed in the early '90's with only 512MBs per process address space, which was a lot 20 years ago but now programs have grown, the average computer has 2-8GBs of memory and everyone is moving to 64bit operating systems to get over the 2-3GB per process limit.
I'll note that we can build a debug version of xul.dll which 32 bit Windows can't (with only 2GBs of memory here, linking the debug xul.dll sees my swap file grow and the system will thrash if I have Mozilla running).
Title: Re: News from the front line
Post by: Joop on July 11, 2015, 01:23:47 pm
Why must XUL.DLL in shared memory? If next releases demand 300Mb than the game is over for me. I'm running now 24.8.1and have 206Mb left for use. Or do we have more systems which rely on XUL.DLL, but if this is an older package then we might end up in the known dll war.

I posted a bug about 24.8.1, the one that download nr 3 will crash the program, but I get the stupid reply to move on to a higher version. Are they that stupid that they don't understand that not everyone had ADHD in developing?  Where can I put the bug so we get a working system next level?

Regards
Title: Re: News from the front line
Post by: OS4User on July 11, 2015, 05:44:43 pm
I'm running now 24.8.1and have 206Mb left for use.

try to mark dlls so they are loaded  into high mem
Title: Re: News from the front line
Post by: Dave Yeo on July 11, 2015, 06:34:03 pm
Why must XUL.DLL in shared memory? If next releases demand 300Mb than the game is over for me. I'm running now 24.8.1and have 206Mb left for use. Or do we have more systems which rely on XUL.DLL, but if this is an older package then we might end up in the known dll war.

It is the design of OS/2 (Windows too) that puts shared libraries into shared memory. I had a lot of tabs open which is one reason that I was using so much shared memory. Actually I had forgotten to mark the DLLs high on this build and I had SeaMonkey, Thunderbird and Firefox open when I realized that I only had 64MBs low shared free. So as long as you're not opening too many tabs and such, not marking the DLLs high does work. Note that Mozilla tries to allocate high memory as well which helps.
All Mozilla apps (Firefox, Thunderbird and SeaMonkey) use slightly different and incompatible xul.dlls, that is why we have LIBPATHSTRICT and the frontend RUN!, to keep the incompatible DLLs separate.
Quote
I posted a bug about 24.8.1, the one that download nr 3 will crash the program, but I get the stupid reply to move on to a higher version. Are they that stupid that they don't understand that not everyone had ADHD in developing?  Where can I put the bug so we get a working system next level?

The problem is Mozilla and their insane quick release schedule (which they're now planning on speeding up) and the fact that the browser is the component of the operating system that is exposed to the most malicious stuff. So security fixes are important, even on our platform, as we don't want a malicious script spying on the next tab and getting your credit card info or even attempting to install something malicious and crashing the browser.
Luckily Mozilla does have the ESR (extended support release) branch which is fairly stable, mostly only getting security updates so we don't have to update every 6 weeks. But the reality is that for security reasons and also to load the latest content, we have to update every year. With only one person working on our main Mozilla port and also working on other stuff (Java update planned for example), bug reports have to be against the latest. Judging by some of the fixes that have gone into the new (not yet released) version, your download crash might already be fixed.
If you still have the issue with the new release (next week?), open an issue at the Bitwise github account.