Author Topic: News from the front line  (Read 6609 times)

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 26
  • Posts: 529
    • View Profile
Re: News from the front line
« Reply #15 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

Alex Taylor

  • Full Member
  • ***
  • Thank You
  • -Given: 10
  • -Receive: 14
  • Posts: 218
    • View Profile
Re: News from the front line
« Reply #16 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.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 246
  • -Receive: 46
  • Posts: 1648
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: News from the front line
« Reply #17 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
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Andreas Schnellbacher

  • Full Member
  • ***
  • Thank You
  • -Given: 1
  • -Receive: 14
  • Posts: 236
    • View Profile
Re: News from the front line
« Reply #18 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.

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 632
    • View Profile
Re: News from the front line
« Reply #19 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.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 87
  • Posts: 1098
    • View Profile
Re: News from the front line
« Reply #20 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).

Joop

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 30
  • Posts: 405
    • View Profile
Re: News from the front line
« Reply #21 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

OS4User

  • Full Member
  • ***
  • Thank You
  • -Given: 5
  • -Receive: 4
  • Posts: 120
    • View Profile
Re: News from the front line
« Reply #22 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

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 7
  • -Receive: 87
  • Posts: 1098
    • View Profile
Re: News from the front line
« Reply #23 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.