Firefox 10.09ESR

[Dave Yeo]

Firefox 10.09esr has been uploaded to Netlabs.
This is another security fix update and all users of the 10 branch are
urged to update
Dave

[Dave Yeo]

SeaMonkey also uploaded.
Dave

[Steve Wendt]

On 10/13/12 10:23 am, Dave Yeo wrote:

> SeaMonkey also uploaded.

Thanks Dave!

[Carl Gehr]

I just installed the new SM and was looking at the Release Notes -
specifically the:
"Security Advisories for SeaMonkey"
There are a number of issues listed as "Critical" and that have been
fixed in a number of levels far higher than the 2.7.2 level for the SM
that was just released. Specifically, there are two critical items
"Fixed in SeaMonkey 2.13.1"

Why are the OS/2 levels so far behind? There are no dates on these
levels so there is no way to put a time frame around these newer levels.
--
TIA
Carl

[Dave Yeo]

Strictly speaking, this should be called 2.7.9 as it is built upon
Mozilla 10.0.9, the extended support tree. As SeaMonkey doesn't
officially support the ESR branch I've left the default of 2.7.2.
Security fixes are here,
https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html.
Thunderbird has also had a couple of mail related security updates which
also apply to SeaMonkey.
The OS/2 builds are so far behind due to lack of developers. I can build
newer versions but they crash if there are any add-ons, often breaking
the profile as well. I'm no good at debugging the complicated JavaScript
code and have spent close to a year trying to trace where things broke.
Unluckily this has not been simple as the development tree branches of
frequently then merges back in and I'm not always motivated so I'll
spend some weeks testing revisions which is tedious, then spend some
weeks not doing anything related to Mozilla.
I'm doing this volunteerly as I also like an up to date browser and it
can be interesting but the rapid release schedule really calls for full
time developer(s).
Dave

[Dave Yeo]

I should note that I skipped the 10.0.8 release as only 5 days passed
between the 0.8 and 0.9 releases
Dave

[Dariusz Piatkowski]

Hi Dave!

Just deployed it a couple of hours ago...very little runtime so far, but appears
to be running fine.

Thanks again!

-Dariusz

[Doug Bissett]

On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave....@gmail.com>
wrote:

> I'm doing this volunteerly as I also like an up to date browser and it
> can be interesting but the rapid release schedule really calls for full
> time developer(s).
> Dave

Without volunteers, eCS is toast. Unfortunately, we just don't have
enough developers, full time or otherwise, but you are doing a
reasonably good job of sorting out the basics. Thanks, for everything
that you do.

Personally, I see no good reason for the rapid releases, other than to
add security fixes (and to try to look like they are keeping up with
Internet Explorer, which is a silly thing to do). I think the ESR path
makes a lot more sense, but, eventually, we will need to jump to
something newer. Hopefully, you can get some help.

I do, however, question the advisability of maintaining programs that
effectively duplicate each other. Firefox, and Thunderbird, do what
SeaMonkey does, and they are more "officially" supported. I know that
there are many users who seem to prefer SeaMonkey, but if it is taking
significant time away from the other two, it may be wise to drop it.
Some will say that it is Firefox, and Thunderbird, that should be
dropped, but there is much less "official" support for SeaMonkey, so
it would make sense to drop that. On the other hand, if SeaMonkey is
not taking a significant amount of time, I have no problem if you wish
to continue the project. I just throw this thought out as a way to cut
down on the amount of work to be done.

--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

[Felix Miata]

On 2012-10-14 00:31 (GMT-0500) Doug Bissett composed:

> I do, however, question the advisability of maintaining programs that
> effectively duplicate each other. Firefox, and Thunderbird, do what
> SeaMonkey does,

Twice. They don't share what SeaMonkey need not share, so unless you only
require web or email but not both, you're wasting precious low memory by
redundant loading.

I just moved off eCS for web apps last month, and on Linux run 2 SeaMonkeys
and 3 Firefoxes 24/7 with no crashing, no RAM shortage, and no 100% CPU
periods. On eCS before I switched, SM needed daily restarts to reclaim lost
shared RAM even without using it for news or CZ.

Now using SM on eCS only for CZ I'm lucky if I get 3 days out of it before it
dies. Leaving SM open much more than a day using it only for web and CZ it
crashes even with only 1/3 the number of open tabs I usually use.

Currently FC/2 is showing 2,145,906,688 total RAM, 1,666,961,408 free with
only CZ, 2 DOS apps and FC/2 running. Closing the CZ window brought free RAM
up to 2,033,229,824, meaning CZ was using 366,268,416 all by itself.
Reopening SM browser only with the same 12 tabs open when last closed brought
free RAM down by 192,917,504. Opening CZ with my default set of 15 tabs
brought free RAM down by 23,822,336, but after closing browser free RAM only
went back up to 1,827,016,704, meaning freshly opened CZ is nevertheless
using 206,213,120. Imagine how much would be used by opening TB plus FF with
the same 30-40 tabs I typically have open in SM on eCS plus the 100+ tabs I
have open in Linux, or that plus CZ? I'd be out of shared RAM right out of
the gate, if I even got out of the gate.

FF + TB = no thanks.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[Dariusz Piatkowski]

Hi Dave!

On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave....@gmail.com> wrote:

> > Why are the OS/2 levels so far behind? There are no dates on these
> > levels so there is no way to put a time frame around these newer levels.
>

> The OS/2 builds are so far behind due to lack of developers. I can build

> newer versions but they crash...
> Dave


So how the heck do the rest of us get involved? I had previously asked this
question, received some pointers...spent some time looking into the project and
quite frankly, was completely lost!!!

The code complexity is one thing, but the overall OS/2 framework, what resources
such as compiler, libraries, tools to use is nothing but a major brick wall. Is
there not a document somewhere which spells out, one by one, how a given OS/2
machine needs to be set up? Is there not a downloadable environment that could
be utilized which is already pre-configured?

In my case, I have my daily use machine (which is SMP configured and is very
fast for just about everything I ask it to do). I also have my old hardware
still kicking around with a complete OS/2 environment setup that could be used
as a spare box to do work with. Effectively, that means as a developer (I'm an
IS professional by trade and spent a few years wearing exactly those shoes) I
have my build & test boxes readily available to me.

Given the rather steep climb on the Firefox project I have now started looking
at the QT framework in hopes of compiling the new version of PSI IM client. Will
it work? ....no idea...but you've got to try to know.

I would much rather devote my time to something like Firefox, but again, much
help is needed to get started...

[Steve Wendt]

On 10/13/12 10:31 pm, Doug Bissett wrote:

> Personally, I see no good reason for the rapid releases, other than to
> add security fixes (and to try to look like they are keeping up with
> Internet Explorer

I suppose you mean Chrome. IE is always way behind.

> Some will say that it is Firefox, and Thunderbird, that should be
> dropped, but there is much less "official" support for SeaMonkey

Thunderbird has been "dropped" multiple times by Mozilla.

[Steve Wendt]

On 10/14/12 06:57 am, Dariusz Piatkowski wrote:

> The code complexity is one thing, but the overall OS/2 framework, what resources
> such as compiler, libraries, tools to use is nothing but a major brick wall. Is
> there not a document somewhere which spells out, one by one, how a given OS/2
> machine needs to be set up?

Apologies if you have already seen this; I don't know how out of date it is:
http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites

[Dave Yeo]

Doug Bissett wrote:
[...]

>
> Personally, I see no good reason for the rapid releases, other than to
> add security fixes (and to try to look like they are keeping up with
> Internet Explorer, which is a silly thing to do). I think the ESR path
> makes a lot more sense, but, eventually, we will need to jump to
> something newer. Hopefully, you can get some help.

It's Chrome that they're competing with. Unluckily they're also adding
features that we're missing out on, It won't be too bad if we can jump
to 17ESR by next year but if not then we'll fall further behind with a
browser that doesn't support things like the new audio codec, new spdy
http protocol and various HTML 5 features that have been added lately.
As well at some point things like Google will refuse to work.

>
> I do, however, question the advisability of maintaining programs that
> effectively duplicate each other. Firefox, and Thunderbird, do what
> SeaMonkey does, and they are more "officially" supported. I know that
> there are many users who seem to prefer SeaMonkey, but if it is taking
> significant time away from the other two, it may be wise to drop it.
> Some will say that it is Firefox, and Thunderbird, that should be
> dropped, but there is much less "official" support for SeaMonkey, so
> it would make sense to drop that. On the other hand, if SeaMonkey is
> not taking a significant amount of time, I have no problem if you wish
> to continue the project. I just throw this thought out as a way to cut
> down on the amount of work to be done.
>

Once Firefox is building, it is trivial to build SeaMonkey and
Thunderbird as they're basically built on top of Firefox.
As I use SeaMonkey and Thunderbird much more then Firefox I'll keep
building them.
Dave

[Doug Bissett]

On Sun, 14 Oct 2012 10:01:00 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> On 2012-10-14 00:31 (GMT-0500) Doug Bissett composed:
>
> > I do, however, question the advisability of maintaining programs that
> > effectively duplicate each other. Firefox, and Thunderbird, do what
> > SeaMonkey does,
>
> Twice. They don't share what SeaMonkey need not share, so unless you only
> require web or email but not both, you're wasting precious low memory by
> redundant loading.

I don't want to argue, but i would like to ask a couple of questions,
make a few comments, and point out some numbers that I see <below>.

> I just moved off eCS for web apps last month, and on Linux run 2 SeaMonkeys
> and 3 Firefoxes 24/7 with no crashing, no RAM shortage, and no 100% CPU
> periods. On eCS before I switched, SM needed daily restarts to reclaim lost
> shared RAM even without using it for news or CZ.

What makes you think that it is SM (or FF or TB) that is causing the
problem? I will agree that they probably trigger a problem, but I have
seen similar problems without using FF (which is what I use, most of
the time - I use PMMail for e-mail, and ProNews/2 for news groups).
FWIW, I have never seen the 100% CPU problem. I also don't seem to be
running out of RAM (shared or otherwise), but that is possibly because
of the way I set up, and use, my machine. I do see problems after a
couple of days, whether FF runs, or not. I do need to use the machine
for other things, to see problems. It will run, unused, for many days.

> Now using SM on eCS only for CZ I'm lucky if I get 3 days out of it before it
> dies. Leaving SM open much more than a day using it only for web and CZ it
> crashes even with only 1/3 the number of open tabs I usually use.
>
> Currently FC/2 is showing 2,145,906,688 total RAM, 1,666,961,408 free with
> only CZ, 2 DOS apps and FC/2 running. Closing the CZ window brought free RAM
> up to 2,033,229,824, meaning CZ was using 366,268,416 all by itself.
> Reopening SM browser only with the same 12 tabs open when last closed brought
> free RAM down by 192,917,504. Opening CZ with my default set of 15 tabs
> brought free RAM down by 23,822,336, but after closing browser free RAM only
> went back up to 1,827,016,704, meaning freshly opened CZ is nevertheless
> using 206,213,120. Imagine how much would be used by opening TB plus FF with
> the same 30-40 tabs I typically have open in SM on eCS plus the 100+ tabs I
> have open in Linux, or that plus CZ? I'd be out of shared RAM right out of
> the gate, if I even got out of the gate.

I would like to post some numbers, as produced by the Above512
program:

Shortly after boot:
current free virtual address space in kB (private / shared):
365824 / 284480 below 512MB line, 917504 / 816652 above 512MB line

After starting Firefox (10.0.9), with a simple home page:
current free virtual address space in kB (private / shared):
340288 / 254656 below 512MB line, 917504 / 816588 above 512MB line

After opening 4 tabs, with the most complicated web pages that I
normally use, and opening ProNews/2, I see:
current free virtual address space in kB (private / shared):
333952 / 246016 below 512MB line, 917504 / 816588 above 512MB line

Throw in TB, and I see:
current free virtual address space in kB (private / shared):
304448 / 213696 below 512MB line, 917504 / 814856 above 512MB line

To me, this does not seem to be excessive memory use, and there is
certainly no shortage of shared memory available (real memory is
irrelevant because the swap mechanism will make up for that, until it
runs out of disk space). It is not possible to separate usage by
program, using Above512, but Theseus seems to show little memory
leakage for FF, over the short term (a couple of hours). FF does use
large amounts of memory (only a problem on a small real memory setup),
and running it does cause web pages to be cached in memory (as well as
on disk), which may appear to be memory leakage, but it isn't really a
leakage, it is simply using more memory. On my 2 GB system, I never
see it go much over 850 MB used (unless I open a virtual machine),
even after leaving FF open all day long (without using it heavily,
because I don't use it that much). Closing FF does leave some DLLs
loaded, which may also appear to be a leakage, but it is not.

I should also point out that I use Rich Walsh's RUN! to start FF and
TB. I also close FF (and almost everything else) over night, so it
doesn't interfere with my nightly backup (RSync to a USB disk drive).

I saw sombody (perhaps Rich Walsh) post that FF, TB, and probably SM,
no longer use large amounts of shared memory space, so I am wondering
if you are blaming your trouble on a problem that no longer exists,
when the real problem is something else (possibly in SM, but more
likey in a part of OS/2 itself). If somebody can identfy the actual
cause of the problem, it can probably be fixed (likely a work around
of some sort).

This also begs the question: Why would you use more than 4 or 5 open
tabs? It must take longer to find an open tab, than to open a new one,
and close it when you are finished with it (just trying to understand
the logic of opening 50, or more, tabs, never mind having multiple SM,
and FF, programs open).

> FF + TB = no thanks.

Actually, I agree. I use FF, PMMail, and ProNews/2. I have tried SM,
and there is something about it that just doesn't seem right, to me
(personal preference). I do use TB, every once in a while (perhaps
once per month), just to compare to what PMMail does with an
individual message, otherwise, I probably wouldn't even bother
installing it.

[Dave Yeo]

Felix Miata wrote:
> I just moved off eCS for web apps last month, and on Linux run 2
> SeaMonkeys and 3 Firefoxes 24/7 with no crashing, no RAM shortage, and
> no 100% CPU periods. On eCS before I switched, SM needed daily restarts
> to reclaim lost shared RAM even without using it for news or CZ.
>
> Now using SM on eCS only for CZ I'm lucky if I get 3 days out of it
> before it dies. Leaving SM open much more than a day using it only for
> web and CZ it crashes even with only 1/3 the number of open tabs I
> usually use.

I haven't had problems with shared memory for a long time, I don't
really use CZ but sometimes I do have a hundred tabs open spread over a
couple of Windows as well as using Thunderbird for mail and often having
Firefox also open with perhaps a dozen tabs. What I do run into is
excess swapping as I only have 1 GB of memory. SeaMonkey will run for
days without needing shut down though I do shut it down about once a day
to back up everything as after about a week (less with eCS) the system
will hang forcing a reboot and due to bandwidth limits it is faster to
restore a backup and use session restore then to redownload a hundred tabs.
There is a bug somewhere that causes 100% CPU if I subscribe to too many
newsgroups but as long as I don't I just about never hit 100% CPU usage
on Warp V4. eCS seems worse for CPU.
Currently with about 70 tabs over 2 windows, mailnews open and a minimal
CZ window open and also Thunderbird also open I have 48 MBs of free ram
+ 80 MBs of swap usage.
Dave

[Dave Yeo]

This is close to accurate. Python needs to be newer and also include
Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some
versions of Make correctly support the right features.
Dave

[Alfredo Fernández Díaz]

Dave Yeo escribió:
> Steve Wendt wrote:
...

>> Apologies if you have already seen this; I don't know how out of date it
>> is:
>> http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
>
> This is close to accurate. Python needs to be newer and also include
> Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some
> versions of Make correctly support the right features.
> Dave

Perhaps it would be wise to update that page (or whatever others!) with
accurate and up-to-date information. That way anyone who would eventually want
to join in would have an easier time. If I ever get to try, I certainly won't
aim to compile anything older than this 10.0.9esr.

Best regards,

[Dariusz Piatkowski]

Yes, the page Steve posted was the original information I had looked at. Now
given the input you provided Dave what can be done to allow additional folks
like myself to come in an contribute?

I want to get up to speed quickly and require as little as possible of the
constant hand-holding. Some help will obviously be needed to start off with
(such as this discussion), but the sooner a new developer gets up to speed, the
better.

Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
a Netlabs like project site?) that could take on the process to re-fresh the
'involvement roadmap'? I would be happy/thrilled to work with this person as the
lab rat! ;-)

[Alfredo Fernández Díaz]

Dariusz Piatkowski escribió:

> On Sun, 14 Oct 2012 18:21:26 UTC, Dave Yeo<dave....@gmail.com> wrote:
>
>> Steve Wendt wrote:
>>> On 10/14/12 06:57 am, Dariusz Piatkowski wrote:

...

> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> a Netlabs like project site?) that could take on the process to re-fresh the
> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> lab rat! ;-)

I can't do application code now, but I'm willing to test anything, from new
builds to packaging to build environments. If that's of any use for you,
contact me.

Best regards,

[Dave Yeo]

Dariusz Piatkowski wrote:
> On Sun, 14 Oct 2012 18:21:26 UTC, Dave Yeo<dave....@gmail.com> wrote:
>
>> Steve Wendt wrote:
>>> On 10/14/12 06:57 am, Dariusz Piatkowski wrote:
>>>
>>>> The code complexity is one thing, but the overall OS/2 framework, what
>>>> resources
>>>> such as compiler, libraries, tools to use is nothing but a major brick
>>>> wall. Is
>>>> there not a document somewhere which spells out, one by one, how a
>>>> given OS/2
>>>> machine needs to be set up?
>>>
>>> Apologies if you have already seen this; I don't know how out of date it
>>> is:
>>> http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites
>>
>> This is close to accurate. Python needs to be newer and also include
>> Mercurial. GCC also needs to be recent. Ksh instead of Ash and only some
>> versions of Make correctly support the right features.
>> Dave
>
>
> Yes, the page Steve posted was the original information I had looked at. Now
> given the input you provided Dave what can be done to allow additional folks
> like myself to come in an contribute?

We've fallen far behind and probably need a couple of months of
developer time to get caught up.

>
> I want to get up to speed quickly and require as little as possible of the
> constant hand-holding. Some help will obviously be needed to start off with
> (such as this discussion), but the sooner a new developer gets up to speed, the
> better.

I'll try to get together a howto on building 10esr which is a good
start. One problem is I've lost track of exactly which versions of the
tools I'm using. Python for example, I use one of Pauls builds for
compiling but IIRC not the newest. For Mercurial I use the Python
installed by RPM, but once again the newest doesn't work.
I only took up building Mozilla to have the latest with no plans to get
heavily involved in development, just pointing out build breaks and such
to the more knowledgeable people. Eventually I became one of the few
people who could build so I started uploading my builds. Unluckily I
never kept notes about my environment which has evolved quite a bit over
the years.
Before libc065 was released things were also getting quite hairy as many
of the libc tools needed patching which complicated things.
We're right at the edge of what our ancient system is capable of

>
> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> a Netlabs like project site?) that could take on the process to re-fresh the
> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> lab rat! ;-)
>
>

Currently I'm all there is in the way of a Firefox team. No project site
or anything else currently
Dave

[Dave Yeo]

I was hoping to get around to trying to setup a RPM/YUM environment to
simplify things but never got around to it. Before libc065 things also
were getting complicated as many tools needed updating, things like emxomf.
Unluckily I haven't really kept notes on what versions of various tools
I'm currently using and being bandwidth challenged it is hard to test.
I'll try to find time to write a howto and update the build requirements
pages but to be honest, motivation comes and goes.
Dave

[Alfredo Fernández Díaz]

First of all, a million thanks for providing reasonably up-to-date builds, Dave!

Dave Yeo escribió:
...

> Strictly speaking, this should be called 2.7.9 as it is built upon Mozilla
> 10.0.9, the extended support tree. As SeaMonkey doesn't officially support the
> ESR branch I've left the default of 2.7.2. Security fixes are here,
> https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html.

Maybe it would be better to keep in synch with SM numbering in the future. The
ESR name tail should be a hint anyway, and that would prevent issues with
overly sensitive addons (language packs come to mind).

[...]

> I'm doing this volunteerly as I also like an up to date browser and it can be
> interesting but the rapid release schedule really calls for full time
> developer(s).

Certainly. As you said in another branch of the thread below, I'm planning to
take up building Mozilla with no plans to get heavily involved in development,
just pointing out build breaks and such to the more knowledgeable people, etc.
but I'm afraid this won't keep the boat floating much longer...

[Dariusz Piatkowski]

On Sun, 14 Oct 2012 20:58:25 UTC, Dave Yeo <dave....@gmail.com> wrote:

> Dariusz Piatkowski wrote:
> > Yes, the page Steve posted was the original information I had looked at. Now
> > given the input you provided Dave what can be done to allow additional folks
> > like myself to come in an contribute?
>
> We've fallen far behind and probably need a couple of months of
> developer time to get caught up.

Point out what I/we (others interested in this, Al F. comes to mind as he's
responding to the thread) can help out with...even the simplest of things...

> > Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
> > a Netlabs like project site?) that could take on the process to re-fresh the
> > 'involvement roadmap'? I would be happy/thrilled to work with this person as the
> > lab rat! ;-)
>
> Currently I'm all there is in the way of a Firefox team. No project site
> or anything else currently
> Dave

OK, so would it be possible to move the project to something like Netlabs? I
only suggest that b/c there seems to be a 'nice' interface to it. I know nothing
about Netlabs beyond this, I know nothing about any of the internal politics
(are there any???), etc, etc... My hope is that a central OS/2 repository will
make it easier for others to join the project.

Either way, given all the work you are doing...you need help. So if we can split
up the task into multiple ones (yeah, I understand not all the tasks can be
divided up like that) hopefully the final goal of keeping Firefox in sync can
get easier.

In general, what is the best starting place for the developer willing to take a
crack at the Firefox application? I'm assuming there is a lot of non-platform
specific stuff out there to digest first before really getting into out platform
specific details.

[Felix Miata]

On 2012-10-14 12:58 (GMT-0500) Doug Bissett composed:

> What makes you think that it is SM (or FF or TB) that is causing the
> problem?

Other than PMView, which is only ever open while I'm actually using it, the
only "native" apps (I don't count FC/2 as a "native" app, while XFile is
tiny, inactive most of the time, and as prerequisite to critical WPS
functionality, I don't count it either) I've opened on eCS in the last half
decade are the Geckos. eCS is my all-important DOS, and until last month, it
was my primary/preferred access to the web.

After boot and opening the essentials (FC/2 & XFile via startup folder, 2 DOS
apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688 free. Once a
Gecko (normally SM 2.x, as I typically go weeks or even months without
opening any FF on eCS) have dropped free below 1,500,000,000, I can expect a
it/them to die in short order.

SM 1.1.x would crash in the same free RAM area, but could go up to 8 days up
before dropping free RAM below the critical 1,500,000,000 level and dying. I
got in the habit of restarting at 6 day intervals to avoid history data loss
from crashing. Session restore allows me to much more conveniently restart
SM2 daily to avoid most crashes.

I've not seen the 20,971,520 byte swap grown post-boot in several years, and
have no idea whether it's been used at all. Its time stamp only changes at
boot time.

> This also begs the question: Why would you use more than 4 or 5 open
> tabs? It must take longer to find an open tab, than to open a new one,
> and close it when you are finished with it (just trying to understand
> the logic of opening 50, or more, tabs, never mind having multiple SM,
> and FF, programs open).

It's easier to find what I want time and time and time again in open tabs
than it is in bookmarks or history. Each window has its own group of tab
content types, rather like using pager or virtual desktops, keeping most easy
enough to locate. Plus, in a tab, there's no waiting unless I restart or care
for a reload, which frequently is exactly what I don't want to happen. Only
one profile/Gecko installation is allowed access to Flash content, minimizing
the possibility of crashes due to that abominable usability impediment.

> I use FF, PMMail, and ProNews/2

I use SM because:

1-it offers the same advantages of an integrated web suite that Netscape did
2-it's cross-platform, enabling me to support it for users of operating
systems installed on their puters when they bought them, which in turn
3-reduces slightly the number of people polluting the web via Outhouse and
Outbreak Excess

Once upon a time I used ProNews/2, but only because of
https://bugzilla.mozilla.org/show_bug.cgi?id=60981

[Dave Yeo]

Dariusz Piatkowski wrote:
> On Sun, 14 Oct 2012 20:58:25 UTC, Dave Yeo<dave....@gmail.com> wrote:
>
>> Dariusz Piatkowski wrote:
>>> Yes, the page Steve posted was the original information I had looked at. Now
>>> given the input you provided Dave what can be done to allow additional folks
>>> like myself to come in an contribute?
>>
>> We've fallen far behind and probably need a couple of months of
>> developer time to get caught up.
>
>
> Point out what I/we (others interested in this, Al F. comes to mind as he's
> responding to the thread) can help out with...even the simplest of things...
>
>
>>> Sooo....is there anyone in the OS/2 Firefox team (who is the team btw?, is there
>>> a Netlabs like project site?) that could take on the process to re-fresh the
>>> 'involvement roadmap'? I would be happy/thrilled to work with this person as the
>>> lab rat! ;-)
>>
>> Currently I'm all there is in the way of a Firefox team. No project site
>> or anything else currently
>> Dave
>
>
> OK, so would it be possible to move the project to something like Netlabs? I
> only suggest that b/c there seems to be a 'nice' interface to it. I know nothing
> about Netlabs beyond this, I know nothing about any of the internal politics
> (are there any???), etc, etc... My hope is that a central OS/2 repository will
> make it easier for others to join the project.

As long as it is Firefox, we should keep using their mercurial server.
For the ESR branch it is,
http://hg.mozilla.org/releases/mozilla-esr10
Netlabs is limited to SVN while Mercurial (and Git) are much more
powerful. Many of the projects currently hosted at netlabs are thinking
of moving to github.
If we split off, I'd use bitbucket as it supports Mercurial. I already
have the mzfntcfgft repository there,
https://bitbucket.org/dryeo/mzfntcfgft. (readme needs updating for tip,
we're currently using Gecko_10_release. If you want to build it, clone
then hg update -r Gecko_10_Release)

>
> Either way, given all the work you are doing...you need help. So if we can split
> up the task into multiple ones (yeah, I understand not all the tasks can be
> divided up like that) hopefully the final goal of keeping Firefox in sync can
> get easier.
>
> In general, what is the best starting place for the developer willing to take a
> crack at the Firefox application? I'm assuming there is a lot of non-platform
> specific stuff out there to digest first before really getting into out platform
> specific details.
>

To start would be learning about Mercurial.
https://developer.mozilla.org/en-US/docs/Mercurial_basics
https://developer.mozilla.org/en-US/docs/Mercurial_Queues
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ

I'll get documentation together on building the ESR branch which is a
good start.
Dave

[Dave Yeo]

Felix Miata wrote:
> After boot and opening the essentials (FC/2 & XFile via startup folder,
> 2 DOS apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688
> free. Once a Gecko (normally SM 2.x, as I typically go weeks or even
> months without opening any FF on eCS) have dropped free below
> 1,500,000,000, I can expect a it/them to die in short order.

There's something wrong here. SeaMonkey shouldn't have problems when
only using 500MBs. My SeaMonkey is currently using 628MBs and usually
uses more. Of that most of the shared memory is in the high arena.
Perhaps the lack of programs that you're running is allowing SeaMonkey
to run in low memory instead of high memory. You could look with Theseus
or try to start something like Firefox first to allocate low memory.
There is an application that does this but I don't remember the name.
What's your virtualaddresslimit set to?
Dave

[Doug Bissett]

On Mon, 15 Oct 2012 00:07:11 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> On 2012-10-14 12:58 (GMT-0500) Doug Bissett composed:
>
> > What makes you think that it is SM (or FF or TB) that is causing the
> > problem?
>
> Other than PMView, which is only ever open while I'm actually using it, the
> only "native" apps (I don't count FC/2 as a "native" app, while XFile is
> tiny, inactive most of the time, and as prerequisite to critical WPS
> functionality, I don't count it either) I've opened on eCS in the last half
> decade are the Geckos. eCS is my all-important DOS, and until last month, it
> was my primary/preferred access to the web.
>
> After boot and opening the essentials (FC/2 & XFile via startup folder, 2 DOS
> apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688 free. Once a
> Gecko (normally SM 2.x, as I typically go weeks or even months without
> opening any FF on eCS) have dropped free below 1,500,000,000, I can expect a
> it/them to die in short order.

Now that is really strange. My 2 GB system usually has about 1.2 GB
free, and almost always no more than 1.5 GB free, even without FF
running. Of course, that has little bearing on how much shared memory
is available. My guess would be, that you have something else that is
using a lot of (probably low) shared memory, or, you have disabled, or
restricted, upper shared memory, somehow.

> SM 1.1.x would crash in the same free RAM area, but could go up to 8 days up
> before dropping free RAM below the critical 1,500,000,000 level and dying. I
> got in the habit of restarting at 6 day intervals to avoid history data loss
> from crashing. Session restore allows me to much more conveniently restart
> SM2 daily to avoid most crashes.

SM 1.x would probably use less memory, so it would take longer to get
to your threshold (not sure why there would be one). Personally, I
find Session Restore to be more of a pain, than useful, but that is
probably because of the way that I use FF.

> I've not seen the 20,971,520 byte swap grown post-boot in several years, and
> have no idea whether it's been used at all. Its time stamp only changes at
> boot time.

My Swap file is 2 megs, and I never see it used. I also have a laptop
with 1.5 GB of memory, and it never gets near to using the swap file.
You would need to fill up real memory, before it would attempt to use
the swap file.

> > This also begs the question: Why would you use more than 4 or 5 open
> > tabs? It must take longer to find an open tab, than to open a new one,
> > and close it when you are finished with it (just trying to understand
> > the logic of opening 50, or more, tabs, never mind having multiple SM,
> > and FF, programs open).
>
> It's easier to find what I want time and time and time again in open tabs
> than it is in bookmarks or history. Each window has its own group of tab
> content types, rather like using pager or virtual desktops, keeping most easy
> enough to locate. Plus, in a tab, there's no waiting unless I restart or care
> for a reload, which frequently is exactly what I don't want to happen. Only
> one profile/Gecko installation is allowed access to Flash content, minimizing
> the possibility of crashes due to that abominable usability impediment.

I can't even imagine what you do with all of them, but I guess you
have figured out what works for you.

> > I use FF, PMMail, and ProNews/2
>
> I use SM because:
>
> 1-it offers the same advantages of an integrated web suite that Netscape did

Personally, I never did understand why Netscape was done that way. A
separerate browser, news, and mail program, makes more sense to me,
and that is one of the main reasons why I jumped onto the FF amd TB
bandwagon early in the game. I see no advantage, at all, to using a
single program for three different functions. In fact, I quickly
abandoned TB too, simply because I like PMMail and ProNews/2 a lot
better.

The biggest Mozilla "problem" is the DLL incompatibility, which RUN!
looks after, with no messing around.

> 2-it's cross-platform, enabling me to support it for users of operating
> systems installed on their puters when they bought them, which in turn
> 3-reduces slightly the number of people polluting the web via Outhouse and
> Outbreak Excess

Well, 3 is a no brainer (I like to call it "Lookout Express"). I do a
little of 2 myself, but if users want to use something else, that is
up to them, and I make it clear that I don't know anything about what
they want to use, so they are on their own. So far, only one guy has
refused to change to FF, and TB (and he is the biggest problem that I
have).

> Once upon a time I used ProNews/2, but only because of
> https://bugzilla.mozilla.org/show_bug.cgi?id=60981


--

[Felix Miata]

On 2012-10-14 18:01 (GMT-0700) Dave Yeo composed:

> Felix Miata wrote:

>> After boot and opening the essentials (FC/2 & XFile via startup folder,
>> 2 DOS apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688
>> free. Once a Gecko (normally SM 2.x, as I typically go weeks or even
>> months without opening any FF on eCS) have dropped free below
>> 1,500,000,000, I can expect a it/them to die in short order.

> There's something wrong here. SeaMonkey shouldn't have problems when
> only using 500MBs. My SeaMonkey is currently using 628MBs and usually
> uses more. Of that most of the shared memory is in the high arena.

I really don't pay much attention to RAM. I just see what FC/2 says
occasionally, and have my suspicions whether it really has any idea what's
going on in upper RAM space. I've never seen it report as low as
1,399,999,999 free, and infrequently seen it very far below 1,500,000,000
before SM dies.

IIRC its author migrated to Linux at least a half decade ago, which may mean
he does little with it specific to OS/2, focusing more on keeping it building
on OS/2 while working the feature set based on personal use on Linux and
feedback from more Windows users than the others it's built for.

> Perhaps the lack of programs that you're running is allowing SeaMonkey
> to run in low memory instead of high memory. You could look with Theseus
> or try to start something like Firefox first to allocate low memory.
> There is an application that does this but I don't remember the name.

Right now on Linux I have SM 2.13.1, SM 2.14bX, FF 2.0.0.20, FF 3.6.28 & FF
16.0.1 combined running well over 100 tabs, not including CZ in one SM and
mailnews in the other, in addition to KPDF, Konq, File Commander, and several
VC, Konsole & MC sessions. RAM used by basesystem, KDE and apps is about half
of 4G, with the rest about evenly split between free and cache. Though I do
have swap space on disk, I have it disabled. Linux isn't inept at using a lot
of RAM. Its apps in those uncommon cases where crashing occurs, don't drive
CPU to 100% or prevent access to uncrashed apps. The WPS has some nice
features either exclusive or poorly shared by other desktops, but they've
ceased to be worth the pain of having it be a primary or exclusive desktop
environment. Linux sure isn't perfect, but it's easier, and less expensive,
to live with. RAM utilization is a big reason why. Geckos being noticeably
faster and non-crashing are other biggies. I keep using eCS now mostly
because of its bulletproof, speedy and easy SVGA text DOS.

> What's your virtualaddresslimit set to?

Current is 1024, but I don't remember seeing any impact compared to 2048 or
1536. This discussion does make me curious how behavior might change if I
pulled the pair of 1024 sticks and put back the original pair of 256s.

[Doug Bissett]

On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> I really don't pay much attention to RAM. I just see what FC/2 says
> occasionally, and have my suspicions whether it really has any idea what's
> going on in upper RAM space.

My guess is that FC/2 doesn't even know about upper shared memory
space. In fact. it may even be possible that it blocks using upper
shared memory space. Try running without it. At least get the version
from 2011 at Hobbes (if you don't already have it):

> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip

Whether it fixes anything, or not, I don't know. I think that version
simply makes the program available as freeware, but there is some
indication that there are updates.

If you use eCenter (XCenter), use the Sentinal Memory Watcher widget
to monitor memory usage. It doesn't split out shared, or upper, memory
usage, it just gives you the total available, what is currently being
used, and how big the swap file is. That would seem to be slightly
more information than what FC/2 gives you. You can also try Above512:

> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip

but it is not a dynamic thing. It may indicate whether FC/2 is
interfering with the upper shared memory space though.

[Doug Bissett]

On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> Current is 1024, but I don't remember seeing any impact compared to 2048 or
> 1536.

For the record: It is suggested that 1536 is optimum, for most users.
If you don't know any reason to use anything else, 1536 is probably
the best for that setting. I suspect that it won't make any difference
to your immediate problem though.

[Felix Miata]

On 2012-10-15 12:13 (GMT-0500) Doug Bissett composed:

> On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata wrote:

>> I really don't pay much attention to RAM. I just see what FC/2 says
>> occasionally, and have my suspicions whether it really has any idea what's
>> going on in upper RAM space.

> My guess is that FC/2 doesn't even know about upper shared memory

That seems to be what I wrote, which I CC'd to its author separately.

> space. In fact. it may even be possible that it blocks using upper
> shared memory space. Try running without it. At least get the version

I can't get anything done without it. Any system without at least one running
OFM to me is all but useless.

> from 2011 at Hobbes (if you don't already have it):

>> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip

Mine is probably newer, 2.41-dev. I chose latest stable devel from
http://silk.apana.org.au/fc2development.html long ago. On Linux I'm at 2.40
because the repos don't seem to have either devel option available.

> If you use eCenter (XCenter), use the Sentinal Memory Watcher widget

I only use WarpCenter set to show activity.

> to monitor memory usage. It doesn't split out shared, or upper, memory
> usage, it just gives you the total available, what is currently being
> used, and how big the swap file is. That would seem to be slightly
> more information than what FC/2 gives you. You can also try Above512:

>> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip

With only the CZ component of SM running since my last thread post, FC/2
shows 1,807,663,104 free of 2,145,906,688. Above512, with or without the -b
option, says:

ABOVE512.exe LX format 32bit DLL module 'loading above 512MB' marking utility,
version 0.01b (internal/experimental use only)
...

current free virtual address space in kB (private / shared):

310720 / 185728 below 512MB line, 454464 / 192072 above 512MB line

Subsequently opening browser window to same 12 tab group as when last closed
brings FC/2 report down to 1,749,024,768, and last lines of above512 to:

current free virtual address space in kB (private / shared):

310720 / 185600 below 512MB line, 454464 / 145252 above 512MB line

Then I downloaded and unzipped
http://silk.apana.org.au/pub/fc2/fc2_250-dev.zip, copied the old fc.ini file
to the unpacked location, closed FC/2, opened a command prompt window, and
started 2.50-dev in that window. Free now shows 1,720,237,184, and above512:

current free virtual address space in kB (private / shared):

310720 / 186112 below 512MB line, 454464 / 145252 above 512MB line

[mozilla_test]

On 14.10.12 02.49, Dave Yeo wrote:

hello dave,

> The OS/2 builds are so far behind due to lack of developers. I can build

> newer versions but they crash if there are any add-ons, often breaking

maybe there should be a big note somewhere that these build are ESR
build from the long time stable branch. They wont add new features but
will get security updates like the other builds.

> I'm doing this volunteerly as I also like an up to date browser and it
> can be interesting but the rapid release schedule really calls for full
> time developer(s).

agreed. Its nice that you were building all these ESR versions as these
rapid release versions are quite too quickly released. It will add new
features and problems that can't be fixed quickly before it will get
replaces by again a newer version. The goal should be the next ESR
branch that is based on the 17.xx code level.


--
cheers
mozilla_test

[Steve Wendt]

On 10/15/2012 1:16 PM, mozilla_test wrote:

> maybe there should be a big note somewhere that these build are ESR
> build from the long time stable branch. They wont add new features but
> will get security updates like the other builds.

Where do you see the announcements for these where it does not say that
already?

[Doug Bissett]

On Mon, 15 Oct 2012 19:20:55 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> On 2012-10-15 12:13 (GMT-0500) Doug Bissett composed:
>
> > On Mon, 15 Oct 2012 06:09:02 UTC, Felix Miata wrote:
>
> >> I really don't pay much attention to RAM. I just see what FC/2 says
> >> occasionally, and have my suspicions whether it really has any idea what's
> >> going on in upper RAM space.
>
> > My guess is that FC/2 doesn't even know about upper shared memory
>
> That seems to be what I wrote, which I CC'd to its author separately.
>
> > space. In fact. it may even be possible that it blocks using upper
> > shared memory space. Try running without it. At least get the version
>
> I can't get anything done without it. Any system without at least one running
> OFM to me is all but useless.
>
> > from 2011 at Hobbes (if you don't already have it):
>
> >> http://hobbes.nmsu.edu/download/pub/os2/util/shell/fc2_240.zip
>
> Mine is probably newer, 2.41-dev. I chose latest stable devel from
> http://silk.apana.org.au/fc2development.html long ago. On Linux I'm at 2.40
> because the repos don't seem to have either devel option available.

Okay. It was just a thought...

> > If you use eCenter (XCenter), use the Sentinal Memory Watcher widget
>
> I only use WarpCenter set to show activity.

You do realize, that WarpCenter (apparently) has some bugs that can
cause problems like you describe? (Hangs, and crashes). I have never
heard of any free, or used, memory related problems (but that doesn't
mean they don't exist).

> > to monitor memory usage. It doesn't split out shared, or upper, memory
> > usage, it just gives you the total available, what is currently being
> > used, and how big the swap file is. That would seem to be slightly
> > more information than what FC/2 gives you. You can also try Above512:
>
> >> http://hobbes.nmsu.edu/download/pub/os2/dev/util/above512_001b.zip
>
> With only the CZ component of SM running since my last thread post, FC/2
> shows 1,807,663,104 free of 2,145,906,688. Above512, with or without the -b
> option, says:
>
> ABOVE512.exe LX format 32bit DLL module 'loading above 512MB' marking utility,
> version 0.01b (internal/experimental use only)
> ...
> current free virtual address space in kB (private / shared):
> 310720 / 185728 below 512MB line, 454464 / 192072 above 512MB line
>
> Subsequently opening browser window to same 12 tab group as when last closed
> brings FC/2 report down to 1,749,024,768, and last lines of above512 to:
>
> current free virtual address space in kB (private / shared):
> 310720 / 185600 below 512MB line, 454464 / 145252 above 512MB line
>
> Then I downloaded and unzipped
> http://silk.apana.org.au/pub/fc2/fc2_250-dev.zip, copied the old fc.ini file
> to the unpacked location, closed FC/2, opened a command prompt window, and
> started 2.50-dev in that window. Free now shows 1,720,237,184, and above512:
>
> current free virtual address space in kB (private / shared):
> 310720 / 186112 below 512MB line, 454464 / 145252 above 512MB line

Hmmm. That indicates that there is plenty of memory available. I guess
you would need to try Above512 when you are near the critical 1.5 GB
free, to see what changes, if anything. If nothing significant comes
from that, I think you need to look in a different direction.
Something else must be causing the problem (which would not surprise
me, at all). The big question is "what can do that?"

BTW, I downloaded FC2 240, and had a quick look. It doesn't seem to
cause any problems, but I only looked briefly. I doubt if the free
memory indication might be an indicator of pending problems, but I
will need to play with it a lot more before saying yes or no. The free
memory number seems to be just a number that is easily derived by
asking the system how much free memory it has (there would be no other
meaning). How that could possibly indicate a pending problem, I don't
know. I suspect that it is a side effect of the real problem, or
coincidence.

Would you consider sending me a copy of your CONFIG.SYS (remove any
passwords, or other sensitive stuff, that may be in it)? I wrote, and
maintain, LCSS (Logical Config.SYS Sort - at HOBBES), and I suspect
that your CONFIG.SYS may contain some things that I am missing in my
database. I may also be able to spot something that might cause a
problem.

Which version of eCS or OS/2, and FP level, are you using?

[Steve Wendt]

On 10/15/2012 2:47 PM, Doug Bissett wrote:

> You do realize, that WarpCenter (apparently) has some bugs that can
> cause problems like you describe? (Hangs, and crashes).

First I've heard of such a thing... I don't have any problems like that.

[Dariusz Piatkowski]

OK, lots of good reading...thank you...I've started on this...will be looking
for further FYIs regarding the udpated OS/2 docs.

Thank you Dave!

[Dave Yeo]

Dariusz Piatkowski wrote:
> I'll get documentation together on building the ESR branch which is a
>> good start.

I've uploaded gecko10_09_patches.zip to netlabs. Includes everything
needed besides the source I hope including a quick build.txt. Forgive my
crappy writing skills :)
One thing I did forget to mention is the patches have to have Unix line
endings to apply, IIRC unzip by default will add cr to the line endings.
Of course the REXX scripts do need DOS line endings and there are a
couple in the source that may need converting.
Dave

[mozilla_test]

On 15.10.12 21.30, Steve Wendt wrote:

> Where do you see the announcements for these where it does not say that
> already?

hello,
more inside the application.. despite the zip file naming people wont
notice, e.g. only the about dialog in firefox will tell ESR but not in
seamonkey and thunderbird.

--
cheers
mozilla_test

[Steve Wendt]

On 10/16/2012 1:56 PM, mozilla_test wrote:

> more inside the application.. despite the zip file naming people wont
> notice, e.g. only the about dialog in firefox will tell ESR but not in
> seamonkey and thunderbird.

SeaMonkey doesn't support ESR; not sure why Thunderbird doesn't indicate it.

[Andy]

On Tue, 16 Oct 2012 04:43:58 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Which HG are you using? I have been trying to pull again and blast if
I am not having troubles with Mercurial once more. CVS just worked,
SVN just works but I see nothing but hassles from Mercurial.
Andy

--

[Dave Yeo]

I've used Andy's build, Paul's 2.6.2 and currently use one installed by
RPM, python-2.6.5-3.oc00.i386.rpm with matching library and
mercurial-1.6.3-2.oc00.i386.
I use the newer due to it working for pushing to a https repo and once
using it you can't go back though I can't remember exactly why now.
Dave

[Doug Bissett]

For the record. It seems that FM is still using excphead.sys, which
was deprecated years ago. He is also running eCS 1.1, and he is still
using CLKBASIC, which is known to have problems. I don't know if
either one could cause the described problems though. He also had the
SMSTART.EXE line in CONFIG.SYS. Again, I don't know if that can cause
such problems, but it is generally advisable to REM that line.

I guess we wait to see what the results are...

[Steve Wendt]

On 10/16/2012 8:40 PM, Doug Bissett wrote:

> excphead.sys, which was deprecated years ago

Is that the hack that prevents SIO2K from trapping?

[mozilla_test]

On 16.10.12 22.01, Steve Wendt wrote:
>
> SeaMonkey doesn't support ESR; not sure why Thunderbird doesn't indicate
> it.

true, theres no official ESR for the seamonkey project, because of that
its nice that dave releases them as well for OS/2 as I mainly use seamonkey.

--
cheers
mozilla_test

[Felix Miata]

On 2012-10-16 22:40 (GMT-0500) Doug Bissett composed:

> For the record. It seems that FM is still using excphead.sys, which
> was deprecated years ago. He is also running eCS 1.1, and he is still

To say that without more is misleading:
Directory of F:\

8-11-05 11:50a 849,262 54 ashr OS2KRNL
8-11-05 11:50a 849,262 54 ashr OS2KRNL.14104a

F:\OS2\INSTALL\SYSLEVEL.BDD
IBM OS/2 Base Device Drivers
Version 4.52 Component ID 5639A6101
Type 0C
Current CSD level: XR0D003
Prior CSD level: XR04503

F:\OS2\INSTALL\SYSLEVEL.ECS
eComStation Operating System 1.1
Version 1.10 Component ID 5639A6101
Type 0C
Current CSD level: XR0C004
Prior CSD level: XR04502

F:\OS2\INSTALL\SYSLEVEL.FPK
OS/2 Convenience Package Service Level
Version 1.00 Component ID 566933010
Type Fixpak
Current CSD level: XR0C004
Prior CSD level: XR0C004

F:\OS2\INSTALL\SYSLEVEL.OS2
Convenience Package - OS/2 Warp 4 Base Operating System
Version 4.52 Component ID 5639A6101
Type 0C
Current CSD level: XR0C004
Prior CSD level: XR04503

The way I remember at the time I got my 1.2 package, there really wasn't
enough difference between 1.2 and what I call mine, 1.14, to justify a fresh
installation of 1.2. 2.0 was rather more inviting, but I just never got the
urge. I quit renewing the subscription a year before 2.0 release.

> using CLKBASIC, which is known to have problems. I don't know if
> either one could cause the described problems though. He also had the
> SMSTART.EXE line in CONFIG.SYS. Again, I don't know if that can cause
> such problems, but it is generally advisable to REM that line.

> I guess we wait to see what the results are...

Too early to tell much yet since only about 22 hours since reboot with these
CONFIG.SYS changes:

-device=F:\os2\boot\excphead.sys
+REM device=F:\os2\boot\excphead.sys
-RUN=F:\OS2\SMSTART.EXE
+REM RUN=F:\OS2\SMSTART.EXE
-CALL=F:\OS2\CACHEF32.EXE /L:OFF /F
+REM CALL=F:\OS2\CACHEF32.EXE /L:OFF /F

[Doug Bissett]

On Wed, 17 Oct 2012 17:27:15 UTC, Steve Wendt <spa...@forgetit.org>
wrote:

> On 10/16/2012 8:40 PM, Doug Bissett wrote:
>
> > excphead.sys, which was deprecated years ago
>
> Is that the hack that prevents SIO2K from trapping?

It might have been for that. I know that later kernels have the fix.
Everybody should be using 14.104a, or better, by now.

[Doug Bissett]

Actually, There is one more change that you should make: Add the line
DLLBASING=OFF
near the top of your CONFIG.SYS. That slows the system (it might be
noticable on a 386 SX processor), but allows it to make better use of
the shared memory space. Of course, that won't take effect until you
reboot.

[Silvan Scherrer]

Dariusz,

just to let you know, i have a psi 0.15 build almost done. So don't
waste time on it :)

regards
Silvan

Dariusz Piatkowski wrote:
> Hi Dave!
>
>
> On Sun, 14 Oct 2012 01:49:37 UTC, Dave Yeo <dave....@gmail.com> wrote:
>
>
>>>Why are the OS/2 levels so far behind? There are no dates on these
>>>levels so there is no way to put a time frame around these newer levels.

>>
>>The OS/2 builds are so far behind due to lack of developers. I can build

>>newer versions but they crash...
>>Dave
>
>
>
> So how the heck do the rest of us get involved? I had previously asked this
> question, received some pointers...spent some time looking into the project and
> quite frankly, was completely lost!!!
>
> The code complexity is one thing, but the overall OS/2 framework, what resources
> such as compiler, libraries, tools to use is nothing but a major brick wall. Is
> there not a document somewhere which spells out, one by one, how a given OS/2
> machine needs to be set up? Is there not a downloadable environment that could
> be utilized which is already pre-configured?
>
> In my case, I have my daily use machine (which is SMP configured and is very
> fast for just about everything I ask it to do). I also have my old hardware
> still kicking around with a complete OS/2 environment setup that could be used
> as a spare box to do work with. Effectively, that means as a developer (I'm an
> IS professional by trade and spent a few years wearing exactly those shoes) I
> have my build & test boxes readily available to me.
>
> Given the rather steep climb on the Firefox project I have now started looking
> at the QT framework in hopes of compiling the new version of PSI IM client. Will
> it work? ....no idea...but you've got to try to know.
>
> I would much rather devote my time to something like Firefox, but again, much
> help is needed to get started...

[Paul Ratcliffe]

On Thu, 18 Oct 2012 00:12:15 -0500, Doug Bissett <dougb007!SP...@telus.net>
wrote:

> Actually, There is one more change that you should make: Add the line
> DLLBASING=OFF
> near the top of your CONFIG.SYS.

Shouldn't that be "SET DLLBASING=OFF"

<runs away guffawing>

[Doug Bissett]

Showing your ignorance again Paul?

To be clear, and prevent confusion, NO it does NOT use SET.

[Felix Miata]

On 2012-10-18 00:12 (GMT-0500) Doug Bissett composed:

> Actually, There is one more change that you should make: Add the line
> DLLBASING=OFF
> near the top of your CONFIG.SYS. That slows the system (it might be
> noticable on a 386 SX processor), but allows it to make better use of
> the shared memory space. Of course, that won't take effect until you
> reboot.

SM crashed at about 40 hours even though I never did anything in the browser
window and did very little in the CZ window. Now I've booted with
DLLBASING=OFF to try again.

[Felix Miata]

On 2012-10-18 00:12 (GMT-0500) Doug Bissett composed:

> Actually, There is one more change that you should make: Add the line
> DLLBASING=OFF
> near the top of your CONFIG.SYS. That slows the system (it might be
> noticable on a 386 SX processor), but allows it to make better use of
> the shared memory space. Of course, that won't take effect until you
> reboot.

SM crashed at about 40 hours even though I never did anything in the browser
window and did very little in the CZ window. Now I've booted with
DLLBASING=OFF to try again.

[Steve Wendt]

On 10/18/2012 1:33 PM, Felix Miata wrote:

> SM crashed at about 40 hours

Do you have exceptq? Is there a trap file?

[Felix Miata]

On 2012-10-18 14:00 (GMT-0700) Steve Wendt composed:

> Felix Miata wrote:

>> SM crashed at about 40 hours

> Do you have exceptq? Is there a trap file?

http://fm.no-ip.com/Tmp/005b_01trp.txt ?
http://fm.no-ip.com/Tmp/popuplog-e-965os2.txt ?

[Steve Wendt]

On 10/18/2012 2:37 PM, Felix Miata wrote:

>> Do you have exceptq? Is there a trap file?
>
> http://fm.no-ip.com/Tmp/005b_01trp.txt ?

That tells me libc065 is crashing due to some font code. Do you have
Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
the cause.

[Felix Miata]

On 2012-10-18 14:59 (GMT-0700) Steve Wendt composed:

> Felix Miata wrote:

>> http://fm.no-ip.com/Tmp/005b_01trp.txt ?

> That tells me libc065 is crashing due to some font code. Do you have
> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
> the cause.

It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

[Steve Wendt]

On 10/18/2012 3:04 PM, Felix Miata wrote:

>> That tells me libc065 is crashing due to some font code. Do you have
>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>> the cause.
>
> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

Is it version 2.4 or 2.6b? I know they have mentioned "known problems"
using it for PMShell, but I don't know details. Version 2.6b seems more
stable to me, but it requires some beta version of libc06 (b4?) and I
don't use it for PMShell myself.

[Felix Miata]

On 2012-10-18 16:10 (GMT-0700) Steve Wendt composed:

> Is it version 2.4 or 2.6b? I know they have mentioned "known problems"
> using it for PMShell, but I don't know details. Version 2.6b seems more
> stable to me, but it requires some beta version of libc06 (b4?) and I
> don't use it for PMShell myself.

I had no luck figuring out what zip it came from. I'm pretty sure it's 2.6b.

Directory of F:\os2\dll
2-01-05 1:15p 421,348 0 a--- ft2lib.dll
Directory of F:\emx\dll
7-25-03 6:13p 204,950 54 a--- libc01.dll
8-19-03 2:13p 207,153 0 a--- libc02.dll
9-12-03 2:59p 208,753 0 a--- libc03.dll
10-27-03 5:13p 230,785 0 a--- libc04.dll
4-14-04 4:37p 356,330 0 a--- libc05.dll
3-23-12 4:32a 48,142 0 a--- libc06.dll
3-23-12 4:32a 48,142 0 a--- libc061.dll
3-23-12 4:32a 157,124 0 a--- libc062.dll
3-23-12 4:32a 157,124 0 a--- libc063.dll
3-23-12 4:32a 157,176 0 a--- libc064.dll
8-11-08 5:53a 1,353,252 0 a--- libc064x.dll
3-23-12 4:32a 1,353,208 0 a--- libc065.dll
3-15-05 11:26a 562,712 65 a--- libc06b4.dll

[Paul Ratcliffe]

On Thu, 18 Oct 2012 10:38:51 -0500, Doug Bissett <dougb007!SP...@telus.net>

wrote:

>> > Actually, There is one more change that you should make: Add the line
>> > DLLBASING=OFF
>> > near the top of your CONFIG.SYS.
>>
>> Shouldn't that be "SET DLLBASING=OFF"
>>
>> <runs away guffawing>
>
> Showing your ignorance again Paul?

No, just teasing you unmercilessly. I guess it went over your head.
"Whoosh" as they say.

[Dave Yeo]

Felix Miata wrote:
> On 2012-10-18 14:59 (GMT-0700) Steve Wendt composed:
>
>> Felix Miata wrote:
>
>>> http://fm.no-ip.com/Tmp/005b_01trp.txt ?
>
>> That tells me libc065 is crashing due to some font code. Do you have
>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>> the cause.
>
> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

Disable it. Especially for newer Mozilla apps which have their own
anti-aliasing.

Dave

[Felix Miata]

On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:

>>> That tells me libc065 is crashing due to some font code. Do you have
>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>> the cause.

>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe & pmshell.exe.

> Disable it. Especially for newer Mozilla apps which have their own
> anti-aliasing.

For which? Only one on that list has been opened in the past 6 months, and it
isn't any Mozilla.

[Dave Yeo]

Felix Miata wrote:
> On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:
>
>>>> That tells me libc065 is crashing due to some font code. Do you have
>>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>>> the cause.
>
>>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe &
>>> pmshell.exe.
>
>> Disable it. Especially for newer Mozilla apps which have their own
>> anti-aliasing.
>
> For which? Only one on that list has been opened in the past 6 months,
> and it isn't any Mozilla.

Try renaming ft2lib.dll (you'll need to unlock it).
Your crashes in nspr4 seem to be in PR_MD_WAIT_CV so those sys3170's
seems to be crashing while waiting for a thread.
Would be interesting to see the trap with libc065.xqs which can be
created by downloading the exceptq71-dev package (Hobbes) and running
mzpxqs on the libc065 map file. All the libc functions in your trp file
seem to be related to [de]allocating high memory with it being called by
Freetype.
One guess is that you have a font installed that is stressing out
freetype in a way that no-one else has experienced. Another guess is
that you have a lot of fonts installed and something is overflowing as
the font list is rebuilt over and over.
Dave

[Felix Miata]

On 2012-10-18 20:25 (GMT-0700) Dave Yeo composed:

> Felix Miata wrote:

>> On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:

>>>>> That tells me libc065 is crashing due to some font code. Do you have
>>>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>>>> the cause.

>>>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe &
>>>> pmshell.exe.

>>> Disable it. Especially for newer Mozilla apps which have their own
>>> anti-aliasing.

>> For which? Only one on that list has been opened in the past 6 months,
>> and it isn't any Mozilla.

> Try renaming ft2lib.dll (you'll need to unlock it).
> Your crashes in nspr4 seem to be in PR_MD_WAIT_CV so those sys3170's
> seems to be crashing while waiting for a thread.
> Would be interesting to see the trap with libc065.xqs which can be
> created by downloading the exceptq71-dev package (Hobbes) and running
> mzpxqs on the libc065 map file. All the libc functions in your trp file
> seem to be related to [de]allocating high memory with it being called by
> Freetype.

I'm not going to change anything else before the current session has had a
chance to crash. :-p

> One guess is that you have a font installed that is stressing out
> freetype in a way that no-one else has experienced. Another guess is
> that you have a lot of fonts installed and something is overflowing as
> the font list is rebuilt over and over.

Maybe "no one else" because I'm the only one left with Smartsuite and its
fonts installed, or the multimegabyte monotype sans and times new roman TTF
files ? This is my list of what's installed:
http://fm.no-ip.com/Tmp/psfontlist.txt

Maybe just removing those two big files is worth a shot all by itself? US
English is all I need.

System font is Trebuchet 10pt.

Also I wonder if it's possible DPI could be playing any part. Devs tend to
run at 96. I don't.

[Dave Yeo]

Felix Miata wrote:
> On 2012-10-18 20:25 (GMT-0700) Dave Yeo composed:
>
>> Felix Miata wrote:
>
>>> On 2012-10-18 18:01 (GMT-0700) Dave Yeo composed:
>
>>>>>> That tells me libc065 is crashing due to some font code. Do you have
>>>>>> Innotek's FT2LIB enabled for SeaMonkey? If so, that could possibly be
>>>>>> the cause.
>
>>>>> It's enabled for nosuchapp.exe, seamonkey1.exe, firefox2.exe &
>>>>> pmshell.exe.
>
>>>> Disable it. Especially for newer Mozilla apps which have their own
>>>> anti-aliasing.
>
>>> For which? Only one on that list has been opened in the past 6 months,
>>> and it isn't any Mozilla.
>
>> Try renaming ft2lib.dll (you'll need to unlock it).
>> Your crashes in nspr4 seem to be in PR_MD_WAIT_CV so those sys3170's
>> seems to be crashing while waiting for a thread.
>> Would be interesting to see the trap with libc065.xqs which can be
>> created by downloading the exceptq71-dev package (Hobbes) and running
>> mzpxqs on the libc065 map file. All the libc functions in your trp file
>> seem to be related to [de]allocating high memory with it being called by
>> Freetype.
>
> I'm not going to change anything else before the current session has had
> a chance to crash. :-p

If you unlock and rename it, it won't take effect until you reboot (or
restart the WPS) as it'll still be in memory.

>
>> One guess is that you have a font installed that is stressing out
>> freetype in a way that no-one else has experienced. Another guess is
>> that you have a lot of fonts installed and something is overflowing as
>> the font list is rebuilt over and over.
>
> Maybe "no one else" because I'm the only one left with Smartsuite and
> its fonts installed,

Seems to be truetype font related and smartsuite is all postscript fonts.

> or the multimegabyte monotype sans and times new
> roman TTF files ?

Those are both on my eCS 2.1 partition and my Warp partition has the
other Times New Roman font that is even bigger.

> This is my list of what's installed:
> http://fm.no-ip.com/Tmp/psfontlist.txt

Doesn't seem too many fonts, I've got more I believe. There are quite a
few I haven't heard of and possibly one of those is broken in some
subtle way.

>
> Maybe just removing those two big files is worth a shot all by itself?
> US English is all I need.

I don't think those are the problem. Really I guess we need a program
that can validate TTF fonts for not having errors.

>
> System font is Trebuchet 10pt.
>
> Also I wonder if it's possible DPI could be playing any part. Devs tend
> to run at 96. I don't.

I'm not knowledgeable about how the DPI is taken care off to comment
though it is a good question
Dave
ps You could also try removing your FCCACHE.INI files from %HOME%,
%TEMP% and perhaps the program directory.

[Dave Yeo]

Dave Yeo wrote:
> I don't think those are the problem. Really I guess we need a program
> that can validate TTF fonts for not having errors.

There's fontforge and TTX/Fonttools. Both would probably be simpler to
install in Linux and mount your OS/2 partition or copy your fonts to it
and test your fonts. Seems to be a few ways a bad font can allocate too
much memory and with fontforge you can even rebuild them to remove
errors. You'll have to read the documentation
Dave

[Doug Bissett]

I hope you were looking in the mirror when you typed that. "Whoosh"
would describe it, as you say.

Posting nonsense such as you did can result in users being very
confused. In the future, please use that lump of meat on top of your
shoulders for something other than to hold your hat.

[Steve Wendt]

On 10/18/12 04:55 pm, Felix Miata wrote:

> I had no luck figuring out what zip it came from. I'm pretty sure it's
> 2.6b.
>
> Directory of F:\os2\dll
> 2-01-05 1:15p 421,348 0 a--- ft2lib.dll

Looks like 2.6b to me.

[Dariusz Piatkowski]

Silvan!!!

Excellent news indeed then...thank you so much! I am happy to test for you...LOL

Still, there are a pile of other QT apps that hold my interest, so I'll probably
dabble with this a little bit, there is always something there to learn. The
difference now is that Firefox will get a lot more attention.

Oh, btw, the 0.10 version of PSI tends to lock-up (soft lock) my system once in
a while, usually also tossing the CPU spike into the mix, so maybe a library
issue???...I am guessing 0.15 is sufficiently different...any chance you might
have come across anything that directly addresses this?

-Dariusz


On Thu, 18 Oct 2012 10:05:52 UTC, Silvan Scherrer <silvan....@aroa.ch>
wrote:

--

[Paul Ratcliffe]

On Thu, 18 Oct 2012 23:53:45 -0500, Doug Bissett <dougb007!SP...@telus.net>

wrote:

>> >> > Actually, There is one more change that you should make: Add the line
>> >> > DLLBASING=OFF
>> >> > near the top of your CONFIG.SYS.
>> >>
>> >> Shouldn't that be "SET DLLBASING=OFF"
>> >>
>> >> <runs away guffawing>
>> >
>> > Showing your ignorance again Paul?
>>
>> No, just teasing you unmercilessly. I guess it went over your head.
>> "Whoosh" as they say.
>
> I hope you were looking in the mirror when you typed that. "Whoosh"
> would describe it, as you say.

No, I was perfectly aware of what I was writing and what the correct
statements are and aren't.
The fact that you had to question me shows it had gone way over your
head. The "whoosh" is definitely with you - I thought about calling
air traffic control to warn them.

> Posting nonsense such as you did can result in users being very
> confused.

Indeed. It has never stopped you though. Do you get it yet?
I expect not.

[Dave Yeo]

Dave Yeo wrote:
> Dave Yeo wrote:
>> Firefox 10.09esr has been uploaded to Netlabs.
>> This is another security fix update and all users of the 10 branch are
>> urged to update
>> Dave
>
> SeaMonkey also uploaded.
>

And Thunderbird
Dave

[Doug Bissett]

On Fri, 19 Oct 2012 21:25:00 UTC, Paul Ratcliffe
<ab...@orac12.clara34.co56.uk78> wrote:

> No, I was perfectly aware of what I was writing and what the correct
> statements are and aren't.
> The fact that you had to question me shows it had gone way over your
> head. The "whoosh" is definitely with you - I thought about calling
> air traffic control to warn them.

This is off topic, and definitely not appropriate for this news group.
FYI, I got what you said. You did not read what I said.

End of discussion...

[Bob]

New this month, fc250

Felix Miata wrote:
> On 2012-10-14 18:01 (GMT-0700) Dave Yeo composed:
>
>> Felix Miata wrote:
>
>>> After boot and opening the essentials (FC/2 & XFile via startup folder,
>>> 2 DOS apps manually), FC/2 says I have 2,074,263,552 of 2,145,906,688
>>> free. Once a Gecko (normally SM 2.x, as I typically go weeks or even
>>> months without opening any FF on eCS) have dropped free below
>>> 1,500,000,000, I can expect a it/them to die in short order.
>
>> There's something wrong here. SeaMonkey shouldn't have problems when
>> only using 500MBs. My SeaMonkey is currently using 628MBs and usually
>> uses more. Of that most of the shared memory is in the high arena.
>
> I really don't pay much attention to RAM. I just see what FC/2 says
> occasionally, and have my suspicions whether it really has any idea
> what's going on in upper RAM space. I've never seen it report as low as
> 1,399,999,999 free, and infrequently seen it very far below
> 1,500,000,000 before SM dies.
>
> IIRC its author migrated to Linux at least a half decade ago, which may
> mean he does little with it specific to OS/2, focusing more on keeping
> it building on OS/2 while working the feature set based on personal use
> on Linux and feedback from more Windows users than the others it's built
> for.
>
>> Perhaps the lack of programs that you're running is allowing SeaMonkey
>> to run in low memory instead of high memory. You could look with Theseus
>> or try to start something like Firefox first to allocate low memory.
>> There is an application that does this but I don't remember the name.
>
> Right now on Linux I have SM 2.13.1, SM 2.14bX, FF 2.0.0.20, FF 3.6.28 &
> FF 16.0.1 combined running well over 100 tabs, not including CZ in one
> SM and mailnews in the other, in addition to KPDF, Konq, File Commander,
> and several VC, Konsole & MC sessions. RAM used by basesystem, KDE and
> apps is about half of 4G, with the rest about evenly split between free
> and cache. Though I do have swap space on disk, I have it disabled.
> Linux isn't inept at using a lot of RAM. Its apps in those uncommon
> cases where crashing occurs, don't drive CPU to 100% or prevent access
> to uncrashed apps. The WPS has some nice features either exclusive or
> poorly shared by other desktops, but they've ceased to be worth the pain
> of having it be a primary or exclusive desktop environment. Linux sure
> isn't perfect, but it's easier, and less expensive, to live with. RAM
> utilization is a big reason why. Geckos being noticeably faster and
> non-crashing are other biggies. I keep using eCS now mostly because of
> its bulletproof, speedy and easy SVGA text DOS.
>
>> What's your virtualaddresslimit set to?
>
> Current is 1024, but I don't remember seeing any impact compared to 2048
> or 1536. This discussion does make me curious how behavior might change
> if I pulled the pair of 1024 sticks and put back the original pair of 256s.

[Felix Miata]

On 2012-10-19 00:44 (GMT-0400) Dave Yeo composed:

I installed both. Only Fontforge shows in KDE menu. Fonttools has no man page
and has no executable named fonttools in the path, or any instructions what
binary starts it.

Validation -> Validate in FontForge "Element" menu:
AHEM.TTF: pass
AndaleMo.TTF: Self Intersecting; multiple Missing Points at Extrema; locks
up/cannot close, just kill -9 to exit
AriBlk.TTF: multiple Flipped References
CAPITALS.TTF: multiple Wrong Direction; multiple Missing Points at Extrema;
multiple Self Intersecting
Charcoal.TTF: multiple Wrong Direction; multiple Missing Points at Extrema;
multiple Self Intersecting
Chicago.TTF: multiple Missing Points at Extrema; multiple Self Intersecting
Code2001.TTF: massive number of Missing Points at Extrema
DejaVuSans-Bold.ttf: massive number of Missing Points at Extrema
DejaVuSans-BoldOblique.ttf: massive number of Missing Points at Extrema
DejaVuSans-ExtraLight.ttf: large number of Missing Points at Extrema
DejaVuSans-Oblique.ttf: massive number of Missing Points at Extrema
DejaVuSans.ttf: massive number of Missing Points at Extrema
DejaVuSans-Condensed-Bold.ttf: massive number of Missing Points at Extrema;
multiple Wrong Direction; Self Intersecting
DejaVuSans-Condensed-BoldOblique.ttf: massive number of Missing Points at Extrema
DejaVuSans-Condensed-Oblique.ttf: massive number of Missing Points at Extrema
DejaVuSansMono-BoldOblique.ttf: (skipped validate) but as with all others
opened to validate, simply opening the font opens a message window with the
following:

Attempt to read script data beyond end of GSUB table
The glyph named mu is mapped to U+00B5.
But its name indicates it should be mapped to U+03BC.
The glyph named Delta is mapped to U+2206.
But its name indicates it should be mapped to U+0394.

What am I doing wrong to get so many errors?

[Felix Miata]

On 2012-10-18 16:33 (GMT-0400) Felix Miata composed:

> SM crashed at about 40 hours even though I never did anything in the browser
> window and did very little in the CZ window. Now I've booted with
> DLLBASING=OFF to try again.

SM lasted about 4 days before crashing this time.
http://fm.no-ip.com/Tmp/005a_01.trp

For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
@@ -45,8 +46,8 @@
REM VIRTUALADDRESSLIMIT=2048
-REM VIRTUALADDRESSLIMIT=1536
-VIRTUALADDRESSLIMIT=1024
+VIRTUALADDRESSLIMIT=1536
+REM VIRTUALADDRESSLIMIT=1024
EARLYMEMINIT=TRUE

[Dave Yeo]

Felix Miata wrote:
> On 2012-10-19 00:44 (GMT-0400) Dave Yeo composed:
>
>> Dave Yeo wrote:
>
>>> I don't think those are the problem. Really I guess we need a program
>>> that can validate TTF fonts for not having errors.
>
>> There's fontforge and TTX/Fonttools. Both would probably be simpler to
>> install in Linux and mount your OS/2 partition or copy your fonts to it
>> and test your fonts. Seems to be a few ways a bad font can allocate too
>> much memory and with fontforge you can even rebuild them to remove
>> errors. You'll have to read the documentation
>
> I installed both. Only Fontforge shows in KDE menu. Fonttools has no man
> page and has no executable named fonttools in the path, or any
> instructions what binary starts it.

It's a Python extension so I'd guess that somewhere on your system are
some scripts that use it. You'll have to examine the package or look at
the package log somewhere in /var

>
> Validation -> Validate in FontForge "Element" menu:
> AHEM.TTF: pass
> AndaleMo.TTF: Self Intersecting; multiple Missing Points at Extrema;
> locks up/cannot close, just kill -9 to exit

For AndaleMo.TTF I get
The following table(s) in the font have been ignored by FontForge
Ignoring 'DSIG' digital signature table
The glyph named macron is mapped to U+02C9.
But its name indicates it should be mapped to U+00AF.
Validation AndaleMono ...Failed
Self Intersecting Glyph
Missing Points at Extrema

no crash though. Possibly a different version of AndaleMono, It's dated
05/18/2003 and 105468 bytes.

> AriBlk.TTF: multiple Flipped References

The following table(s) in the font have been ignored by FontForge
Ignoring 'DSIG' digital signature table
Ignoring 'LTSH' linear threshold table
Ignoring 'hdmx' horizontal device metrics table
Glyph 2 is called ".notdef", a singularly inept choice of name (only glyph 0
may be called .notdef)
FontForge will rename it.
The glyph named pi1 is mapped to U+F006.
But its name indicates it should be mapped to U+03D6.
The glyph named periodcentered is mapped to U+2219.
But its name indicates it should be mapped to U+00B7.
The glyph named macron is mapped to U+02C9.
But its name indicates it should be mapped to U+00AF.
The glyph named foursuperior is mapped to U+F003.
But its name indicates it should be mapped to U+2074.
The glyph named fivesuperior is mapped to U+F007.
But its name indicates it should be mapped to U+2075.
The glyph named sevensuperior is mapped to U+F008.
But its name indicates it should be mapped to U+2077.
The glyph named eightsuperior is mapped to U+F009.
But its name indicates it should be mapped to U+2078.
Validation Arial-Black ...Failed
Self Intersecting Glyph
Wrong Direction
Flipped Reference

> CAPITALS.TTF: multiple Wrong Direction; multiple Missing Points at
> Extrema; multiple Self Intersecting
> Charcoal.TTF: multiple Wrong Direction; multiple Missing Points at
> Extrema; multiple Self Intersecting
> Chicago.TTF: multiple Missing Points at Extrema; multiple Self Intersecting
> Code2001.TTF: massive number of Missing Points at Extrema
> DejaVuSans-Bold.ttf: massive number of Missing Points at Extrema
> DejaVuSans-BoldOblique.ttf: massive number of Missing Points at Extrema
> DejaVuSans-ExtraLight.ttf: large number of Missing Points at Extrema
> DejaVuSans-Oblique.ttf: massive number of Missing Points at Extrema
> DejaVuSans.ttf: massive number of Missing Points at Extrema

Here with the DejaVu installed by eCS 2.1,
This font contains both a 'kern' table and a 'GPOS' table.
The 'kern' table will only be read if there is no 'kern' feature in
'GPOS'.
A point in GID 88 is outside the glyph bounding box
A point in GID 243 is outside the glyph bounding box
Use-my-metrics flag set on at least two components in glyph 685
A point in GID 689 is outside the glyph bounding box
A point in GID 690 is outside the glyph bounding box
A point in GID 691 is outside the glyph bounding box
A point in GID 696 is outside the glyph bounding box
A point in GID 697 is outside the glyph bounding box
A point in GID 701 is outside the glyph bounding box
A point in GID 2894 is outside the glyph bounding box
A point in GID 2895 is outside the glyph bounding box
A point in GID 4720 is outside the glyph bounding box
A point in GID 5439 is outside the glyph bounding box

The glyph named mu is mapped to U+00B5.
But its name indicates it should be mapped to U+03BC.
The glyph named Delta is mapped to U+2206.
But its name indicates it should be mapped to U+0394.

Killed by SIGFPE
pid=0x5fd1 ppid=0x004f tid=0x0001 slot=0x00bb pri=0x0200 mc=0x0001
I:\USR\SRC\FONTFORGE-20120731-B\FONTFORGE\FONTFORGE.EXE
FONTFORG 0:0002f374
cs:eip=005b:0003f374 ss:esp=0053:0058f0e0 ebp=0058f138
ds=0053 es=0053 fs=150b gs=0000 efl=00010206
eax=00cb4120 ebx=0136aae0 ecx=00cb22d0 edx=0136ab40 edi=0136aba0
esi=00000001
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

lots of other fonts are causing a similar crash which I'll try to track
down later.

> DejaVuSans-Condensed-Bold.ttf: massive number of Missing Points at
> Extrema; multiple Wrong Direction; Self Intersecting
> DejaVuSans-Condensed-BoldOblique.ttf: massive number of Missing Points
> at Extrema
> DejaVuSans-Condensed-Oblique.ttf: massive number of Missing Points at
> Extrema
> DejaVuSansMono-BoldOblique.ttf: (skipped validate) but as with all
> others opened to validate, simply opening the font opens a message
> window with the following:
>
> Attempt to read script data beyond end of GSUB table
> The glyph named mu is mapped to U+00B5.
> But its name indicates it should be mapped to U+03BC.
> The glyph named Delta is mapped to U+2206.
> But its name indicates it should be mapped to U+0394.
>
> What am I doing wrong to get so many errors?

I really don't know enough about it but it seems fontforge really does
consider them errors. There is a lot of documentation which never the
less seems incomplete.
I ran fontlint for the above output.
Dave

[Dave Yeo]

Felix Miata wrote:
> On 2012-10-18 16:33 (GMT-0400) Felix Miata composed:
>
>> SM crashed at about 40 hours even though I never did anything in the
>> browser
>> window and did very little in the CZ window. Now I've booted with
>> DLLBASING=OFF to try again.
>
> SM lasted about 4 days before crashing this time.
> http://fm.no-ip.com/Tmp/005a_01.trp

Much the same as the other crash. I'd have to restart SeaMonkey before 4
days due to excessive swapping, I have a lot of tabs open :)

>
> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
> @@ -45,8 +46,8 @@
> REM VIRTUALADDRESSLIMIT=2048
> -REM VIRTUALADDRESSLIMIT=1536
> -VIRTUALADDRESSLIMIT=1024
> +VIRTUALADDRESSLIMIT=1536
> +REM VIRTUALADDRESSLIMIT=1024
> EARLYMEMINIT=TRUE

Dave

[Joop Nijenhuis]

Op 13-10-12 04:32, Dave Yeo schreef:

> Firefox 10.09esr has been uploaded to Netlabs.
> This is another security fix update and all users of the 10 branch are
> urged to update
> Dave

Thanks Dave, but I found a bug. I print my invoices from XS4ALL (my port
to www) with FF because they are online. The first is alright, its a pdf
as it should be. The second and up are garbage. Don't know what's going
wrong. I had to go all the way down to version 6.02 which does the job
right. Sorry for late information, I only print it once half a year. I
don't have versions in between, deleted it because it takes space and
maintenance on the hard drive.
Joop

[Dave Yeo]

Yes, it's a known problem.
Dave

[Felix Miata]

On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
> @@ -45,8 +46,8 @@
> REM VIRTUALADDRESSLIMIT=2048
> -REM VIRTUALADDRESSLIMIT=1536
> -VIRTUALADDRESSLIMIT=1024
> +VIRTUALADDRESSLIMIT=1536
> +REM VIRTUALADDRESSLIMIT=1024
> EARLYMEMINIT=TRUE

10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
using no more than about 12M RAM.

[Felix Miata]

On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:

> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>> @@ -45,8 +46,8 @@
>> REM VIRTUALADDRESSLIMIT=2048
>> -REM VIRTUALADDRESSLIMIT=1536
>> -VIRTUALADDRESSLIMIT=1024
>> +VIRTUALADDRESSLIMIT=1536
>> +REM VIRTUALADDRESSLIMIT=1024
>> EARLYMEMINIT=TRUE

> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
> using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
> using no more than about 12M RAM.

13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

[Doug Bissett]

On Mon, 5 Nov 2012 16:50:11 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:
>
> > On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:
>
> >> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
> >> @@ -45,8 +46,8 @@
> >> REM VIRTUALADDRESSLIMIT=2048
> >> -REM VIRTUALADDRESSLIMIT=1536
> >> -VIRTUALADDRESSLIMIT=1024
> >> +VIRTUALADDRESSLIMIT=1536
> >> +REM VIRTUALADDRESSLIMIT=1024
> >> EARLYMEMINIT=TRUE
>
> > 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
> > using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
> > using no more than about 12M RAM.
>
> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

I don't think that "free RAM" has anything to do with your problem. It
is more likely "free SHARED RAM" that is causing the problem. With the
changes that you made, SHARED RAM should be used more efficiently. Of
course, there may be a limit to that improvement, if there is
something that is using it up, without releasing it again.

[Felix Miata]

On 2012-11-05 12:40 (GMT-0600) Doug Bissett composed:

> Felix Miata wrote:

>> > 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
>> > using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
>> > using no more than about 12M RAM.

>> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

> I don't think that "free RAM" has anything to do with your problem. It
> is more likely "free SHARED RAM" that is causing the problem. With the
> changes that you made, SHARED RAM should be used more efficiently. Of
> course, there may be a limit to that improvement, if there is
> something that is using it up, without releasing it again.

Whether free or shared or how much of either isn't why I posted. I noted
previously that once the number dropped below 1,500,000,000, it would only be
a short time until SM crashed. IOW, one of those two changes I made to
CONFIG.SYS changed or eliminated the crash threshhold. ISTR changing
VIRTUALADDRESSLIMIT in the past had no effect, so I have to think eliminating
PMSHELL's use of ft2lib.dll would be the responsible change.

[Steve Wendt]

On 11/5/2012 4:16 PM, Felix Miata wrote:

> eliminating PMSHELL's use of ft2lib.dll would be the responsible
> change.

I'm sure that's true - your crashes were in font code.

[Felix Miata]

On 2012-11-05 17:03 (GMT-0800) Steve Wendt composed:

> Felix Miata wrote:

>> eliminating PMSHELL's use of ft2lib.dll would be the responsible
>> change.

> I'm sure that's true - your crashes were in font code.

That was the upthread consensus as I read it, but why if it was supposed to
be limited to PMSHELL would it cause SM to crash? I know PMSHELL can't be
entirely divorced from PM apps. But, it seems to me Gecko & PM ought to be
able to play nicer together. NAICT, PM itself is only using one font family
in apps' UIs. Isn't Gecko doing its own font rendering within the viewport?
Maybe the overall Gecko slowness I see compared to Linux & M$ is because both
are doing something with available font files that only one or the other
should be doing, and this presents the opportunity to crash with blame on ft2lib?

[Dave Yeo]

On 11/05/12 05:57 pm, Felix Miata wrote:
> On 2012-11-05 17:03 (GMT-0800) Steve Wendt composed:
>
>> Felix Miata wrote:
>
>>> eliminating PMSHELL's use of ft2lib.dll would be the responsible
>>> change.
>
>> I'm sure that's true - your crashes were in font code.
>
> That was the upthread consensus as I read it, but why if it was supposed
> to be limited to PMSHELL would it cause SM to crash? I know PMSHELL
> can't be entirely divorced from PM apps. But, it seems to me Gecko & PM
> ought to be able to play nicer together. NAICT, PM itself is only using
> one font family in apps' UIs. Isn't Gecko doing its own font rendering
> within the viewport? Maybe the overall Gecko slowness I see compared to
> Linux & M$ is because both are doing something with available font files
> that only one or the other should be doing, and this presents the
> opportunity to crash with blame on ft2lib?

FT2LIB was never really finished and IIRC Innotek advised against using
it for the PMSHELL itself.
Dave

[Felix Miata]

On 2012-11-05 11:50 (GMT-0500) Felix Miata composed:

> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:

>> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

>>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>>> @@ -45,8 +46,8 @@
>>> REM VIRTUALADDRESSLIMIT=2048
>>> -REM VIRTUALADDRESSLIMIT=1536
>>> -VIRTUALADDRESSLIMIT=1024
>>> +VIRTUALADDRESSLIMIT=1536
>>> +REM VIRTUALADDRESSLIMIT=1024
>>> EARLYMEMINIT=TRUE

>> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
>> using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
>> using no more than about 12M RAM.

> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

The crashing may have stopped, but it's obviously not happy. I actually tried
to open new tabs and pages in the browser beyond the 12 that have been
auto-opening in recent weeks and left alone, and just about any activity in a
new tab pegs the CPU for quite a while, as does closing those new ones.

It needs rebooting anyway for the clock change. Not means filesystem async
between Peer & Linux on the LAN.

[Andy]

On Tue, 6 Nov 2012 00:16:02 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

> On 2012-11-05 12:40 (GMT-0600) Doug Bissett composed:
>
> > Felix Miata wrote:
>
> >> > 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
> >> > using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
> >> > using no more than about 12M RAM.
>
> >> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.
>
> > I don't think that "free RAM" has anything to do with your problem. It
> > is more likely "free SHARED RAM" that is causing the problem. With the
> > changes that you made, SHARED RAM should be used more efficiently. Of
> > course, there may be a limit to that improvement, if there is
> > something that is using it up, without releasing it again.
>
> Whether free or shared or how much of either isn't why I posted. I noted
> previously that once the number dropped below 1,500,000,000, it would only be
> a short time until SM crashed. IOW, one of those two changes I made to
> CONFIG.SYS changed or eliminated the crash threshhold. ISTR changing
> VIRTUALADDRESSLIMIT in the past had no effect, so I have to think eliminating
> PMSHELL's use of ft2lib.dll would be the responsible change.

Changing the VIRTUALADDRESSLIMIT may or may not help depending on the
circumstances.
I have just been doing some testing with it and found the following:
Using VPC as my test application:
with VIRTUALADDRESSLIMIT (VAL) set to 1536 I could give VPC 825M of
memory before it started shrinking the size of the shared memory area.
It shrunk the Shared Memory area about 25M for each 50M above 825M up
to nearly 200M by the time I reached 1024M.
Changing the VAL to 1792 I was then able to set the memory on VPC to
1024M without shrinking the Shared Memory space.
From what I have been able to glean, the entire amount given to VAL is
not available to applications and will begin growing into lower
memory, thus shrinking the free shared memory pool (though not being
shared memory itself). By increasing the size of the VAL I was able
to load the entire 1024M into high memory and thus not use the lower
memory area.
This would hit someone sooner with VAL set (or defaulted) to 1024M
where Seamonkey/Firefox would have to use something over 500M before
it would start growing into the lower memory area but over time that
could be an issue. I am guessing on the 500M mark as I have not
tested but am making a guess based on the 825M with a VAL of 1536M.
It could be somewhat lower or higher in practice but the idea being
that the VAL has to be considerably larger than the amount to place
there (at least what I consider considerably).
For some more concrete information:
http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html
Andy
--

[Felix Miata]

On 2012-11-05 23:26 (GMT-0500) Felix Miata composed:

> On 2012-11-05 11:50 (GMT-0500) Felix Miata composed:

>> On 2012-11-02 00:14 (GMT-0500) Felix Miata composed:

>>> On 2012-10-22 21:12 (GMT-0400) Felix Miata composed:

>>>> For current boot I renamed ft2lib.dll to ft2libdll and in CONFIG.SYS:
>>>> @@ -45,8 +46,8 @@
>>>> REM VIRTUALADDRESSLIMIT=2048
>>>> -REM VIRTUALADDRESSLIMIT=1536
>>>> -VIRTUALADDRESSLIMIT=1024
>>>> +VIRTUALADDRESSLIMIT=1536
>>>> +REM VIRTUALADDRESSLIMIT=1024
>>>> EARLYMEMINIT=TRUE

>>> 10 days up. Free RAM down to 1,493,438,434. But, SM is mostly idling. CZ is
>>> using most SM cycles. Most of the time FS SVGA DOS has focus, and likely
>>> using no more than about 12M RAM.

>> 13.7 days up. Free RAM is 1,393,860,608, the lowest I've ever seen it.

> The crashing may have stopped, but it's obviously not happy. I actually tried
> to open new tabs and pages in the browser beyond the 12 that have been
> auto-opening in recent weeks and left alone, and just about any activity in a
> new tab pegs the CPU for quite a while, as does closing those new ones.

> It needs rebooting anyway for the clock change. Not means filesystem async
> between Peer & Linux on the LAN.

Two crashes less than 48 hours apart, both without doing anything at the
time, and without having done more than type a few lines in CZ since opening.
Fullscreen DOS had focus each time. :-(

http://fm.no-ip.com/Tmp/006c_01.trp.txt
http://fm.no-ip.com/Tmp/007c_02.trp.txt

[Dave Yeo]

Interesting that the second one was a crash in exceptq. First one is
once again in the font code
Dave

[Steven Levine]

On Fri, 16 Nov 2012 22:12:52 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

Hi Felix,

> Two crashes less than 48 hours apart, both without doing anything at the
> time, and without having done more than type a few lines in CZ since opening.
> Fullscreen DOS had focus each time. :-(

Hard to say if this is relevant. The thing is that the browsers are
always doing something, even when the the browser windows do not have
focus.

FWIW, 006c_01.trp implies heap corruption because

Filename: F:\EMX\DLL\LIBC065.DLL
Address: 005B:1DF0A4C7 (0001:0000A4C7)

decodes to

32 Bit Symbol <_um_lump_unlink_bucket> Address 1:a498
32 Bit Symbol <_um_lump_unlink_heap> Address 1:a4cc

I recommend you install the libc065.xqs available at

http://home.earthlink.net/~steve53/betas/

This way exceptq can do the symbol lookups.

I'm not sure what's going on with 007c_02.trp. Given the really odd
exceptq ouput I have to suspect memory corruption of some sort.

You have xul.xqs installed, so the exception address

Address: 005B:178AB083 (0001:012BB083)

should have decoded to

0001:012BB7E0 nsCycleCollector::Collect
0001:012BBA20 nsCycleCollector_collect

This is one of those background activities that I mentioned.

Steven


--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------

[Steven Levine]

On Sat, 17 Nov 2012 04:27:00 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi Dave,

> Interesting that the second one was a crash in exceptq. First one is
> once again in the font code

I would not try to read anything into the second exception report in
007c_02.trp. Something went terribly wrong with exceptq.

The report that the exception is in nsCycleCollector::Collect is
probably valid. The rest, not so much.

[Felix Miata]

On 2012-11-17 10:09 (GMT-0600) Steven Levine composed:

> Felix Miata wrote:

>> Two crashes less than 48 hours apart, both without doing anything at the
>> time, and without having done more than type a few lines in CZ since opening.
>> Fullscreen DOS had focus each time. :-(

> Hard to say if this is relevant. The thing is that the browsers are
> always doing something, even when the the browser windows do not have
> focus.

Likely mine does little, with noscript by default disallowing all scripts.
Most of what it does and requires has to be in CZ's inefficient <table>
output. CZ is a pig, but otherwise very convenient.

> I recommend you install the libc065.xqs available at

> http://home.earthlink.net/~steve53/betas/

Where does it go? App dir?? DLL dir???

[Dave Yeo]

Felix Miata wrote:
>> I recommend you install the libc065.xqs available at
>
>> http://home.earthlink.net/~steve53/betas/
>
> Where does it go? App dir?? DLL dir???

Same place as libc065.dll is installed
Dave

[Steven Levine]

On Sat, 17 Nov 2012 17:27:33 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

Hi,

> > http://home.earthlink.net/~steve53/betas/
>
> Where does it go? App dir?? DLL dir???

To add a bit to Dave's reply, here's a paraphrase of what is covered
in the exceptq user docs. As Dave stated, the xqs files must be in
the same directory as the excutables.

Exceptq can use either sym or xqs files or HLL debug data. The HLL
debug data be attached to the excutables or in separate dbg files.
For the Mozilla apps, xqs files are preferred. HLL debug data is
actually better, but this would make the distribution even bulkier
than it already is. The benefit of HLL debug data is the exceptq
reports will conain line number detail.

It might be worthwhile to distribute the dbg files as a separate zip
file, but generating the dbg files would require changes to the build
process.

[Felix Miata]

On 2012-11-18 01:18 (GMT-0600) Steven Levine composed:

> the xqs files must be in the same directory as the excutables.

Which executables? This sounds like the DLL DIR is the wrong place.

> Exceptq can use either sym or xqs files or HLL debug data. The HLL
> debug data be attached to the excutables or in separate dbg files.
> For the Mozilla apps, xqs files are preferred. HLL debug data is
> actually better, but this would make the distribution even bulkier
> than it already is. The benefit of HLL debug data is the exceptq
> reports will conain line number detail.

I remember nothing about the Exceptq installation process. All I know is
where to find the logs from SM crashes, and where I put non-system DLLs given
any choice of location.

[Dave Yeo]

On 11/17/12 11:18 pm, Steven Levine wrote:
> Exceptq can use either sym or xqs files or HLL debug data. The HLL
> debug data be attached to the excutables or in separate dbg files.
> For the Mozilla apps, xqs files are preferred. HLL debug data is
> actually better, but this would make the distribution even bulkier
> than it already is. The benefit of HLL debug data is the exceptq
> reports will conain line number detail.
>
> It might be worthwhile to distribute the dbg files as a separate zip
> file, but generating the dbg files would require changes to the build
> process.

Actually debug builds fail. Usually with rc.exe complaining about too
many page entries and using wrc, a crash on startup. This goes back to
when the build process used static libs where emxomfar would fail due to
too many page entries. Seems we've run into the limit of our object
format, only 64 kbs of page entries.
How does attaching the hll dbg data to separate files work?
Dave

[Steven Levine]

On Sun, 18 Nov 2012 07:28:01 UTC, Felix Miata
<UgaddaBkidd...@dev.nul> wrote:

Hi Felix,

> > the xqs files must be in the same directory as the excutables.
>
> Which executables? This sounds like the DLL DIR is the wrong place.

DLLs are executables. If licbo65.dll is in the \ecs\dll directory,
that's where the xul.xqs would go.

[Steven Levine]

On Sun, 18 Nov 2012 08:39:00 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi,

> Actually debug builds fail. Usually with rc.exe complaining about too
> many page entries and using wrc, a crash on startup.

We may be talking about different debug builds. What I am talking
about are builds done with the gcc -g option, not those built with a
-dDEBUG macro that enabled additional debug code in the excutables.

If you mean the former, rc.exe might be showing it's age. Wrc can
probably be fixed. If you can generate a process dump of the failure,
I will take a look at it. I've been known to correct OpenWatcom
defects now and then.

>This goes back to
> when the build process used static libs where emxomfar would fail due to
> too many page entries. Seems we've run into the limit of our object
> format, only 64 kbs of page entries.

The 65K page limit should not affect debug data. HLL debug data is
appended the the executable

> How does attaching the hll dbg data to separate files work?

Do you mean splitting the debug data to separate files. Exceptq
supports dbg files. I'm pretty sure OpenWatcom's wstrip can handle
the HLL format. The legacy exceptq includes a copydbg utility that
can create the dbg file, but does not modify the executable.

[Dave Yeo]

On 11/18/12 10:59 am, Steven Levine wrote:
> On Sun, 18 Nov 2012 08:39:00 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi,
>
>> Actually debug builds fail. Usually with rc.exe complaining about too
>> many page entries and using wrc, a crash on startup.
>
> We may be talking about different debug builds. What I am talking
> about are builds done with the gcc -g option, not those built with a
> -dDEBUG macro that enabled additional debug code in the excutables.

I'm talking about the default, which is now to include debug symbols,
even with --disable-debug. For quite a while we also need
--disable-debug-symbols for the build to succeed.
Doing a test just now, -g is added to the compile line but now linking
has a -s added and starting the binary in a debugger gives nothing but
assembly.
Does wlink need something like -g?

Dave

[Felix Miata]

On 2012-11-17 10:09 (GMT-0600) Steven Levine composed:

> I recommend you install the libc065.xqs available at

> http://home.earthlink.net/~steve53/betas/

> This way exceptq can do the symbol lookups.

First "crash" since installing libc065.xqs produced only black where windows
belong on return from SVGA fullscreen DOS, "infinitely" pegged CPU, no *.TRP,
only speaker beep from clicking on shutdown icon, and CAD only recourse to
get system control back.