Firefox 45.9.0 can no longer play Youtube movies ?

[ivan]

Open Arcview-2.2 - I think it came with eCS 2 - and the readme gives the needed information and where to find the necessary programs.

Saved you the trouble and attached the readme.

[Dave Yeo]

Try this package. EMX based IIRC.

[xynixme]

Try this package. EMX based IIRC.

As such the UNRPM.CMD file doesn't seem to do anything, but a simplified and customized CMD file to extract does:

Code: [Select]

set HOME=m:\ramddiskdir
set TMP_DRV=m:
set TMP_DIR_NAME=ramdiskdir

echo Extracting files with directories
rpm2cpio %1|cpio -id --preserve-modification-time --verbose
SM sometimes seems to be quite slow with the #%!&# SSE2 DLLs, without me being that biased, but I haven't tried the i686 ones yet. Connecting to websites often seems to take longer than usual. For now let's blame this week's internet.

[xynixme]

Arcview-2.2 - I think it came with eCS 2 - and the readme gives the needed information and where to find the necessary programs.

It's not a no-brainer to upgrade eCS 1.2's OS component ArcView to eCS2.x's, if you want it to be an "ArcView FixPak for eCS 1.x". Alex Taylor has documented once what's required for such an upgrade.

I do prefer a FixPak-approach to not end up with several installed copies (now, and/or after an OS upgrade), and to be able to talk about exactly the same file(s). Unfortunately often that comes down to DIY or misunderstandings, for example due to assuming that something is a generic OS component.

[Dave Yeo]

Try this package. EMX based IIRC.

As such the UNRPM.CMD file doesn't seem to do anything, but a simplified and customized CMD file to extract does:

Code: [Select]

set HOME=m:\ramddiskdir
set TMP_DRV=m:
set TMP_DIR_NAME=ramdiskdir

echo Extracting files with directories
rpm2cpio %1|cpio -id --preserve-modification-time --verbose

The second zip I posted worked fine for me.

SM sometimes seems to be quite slow with the #%!&# SSE2 DLLs, without me being that biased, but I haven't tried the i686 ones yet. Connecting to websites often seems to take longer than usual. For now let's blame this week's internet.

The Netburst (P4) architecture liked quite different instruction ordering compared to all other i386 compatible chips to take advantage of its pipelining, which was why it was so slow compared to the PIII running unoptimized software or software optimized for other CPU's. Quite likely that is why you are seeing crappy performance.  Personally I've stuck with i686 as it is basically the ancestor of all other Intel CPU's and AMD isn't too different as well. While supporting Netburst might have made sense some years ago when P4's were still common, it seems not to be anymore. The Pentium M, which is basically a PIII with SSE2 seems to be the minimum that others (Linux, Windows, Mozilla) have chosen for a minimal SSE2 CPU.

[xynixme]

The second zip I posted worked fine for me.

Personally I've stuck with i686 as it is basically the ancestor of all other Intel CPU's and AMD isn't too different as well.

made sense some years ago when P4's were still common, it seems not to be anymore.

Thank you. Here, with CMD.EXE, it didn't even print the ECHO-line. Deleting the rest and inserting explicit SETs was easier than figuring out why. I've got all files, after finding out I was using a *DEVEL*.RPM file.

I'm using your i686 F/SM builds, for one because old BIOSes are causing disk full-errors even without several large, nearly identical files (one per targetted CPU), and it works as good as it gets in the range i686 - IBM ThinkPad T42p.

When my (single core, eCS) P4s stop working, none is perfect, a logical next step may be a - possibly surprising - CPU downgrade. You tend to use the best hardware, but one day even here P4s will become less common. Due to a "forced" switch to PIII( Mobile)s and PIIs for Mozilla-based browsing (won't work with PIIIs, last time I checked). It's that, or letting Microsoft torture new disks. Unless there's a good, "fully" functional ArcaOS NLV release for > 1 core.

[Dave Yeo]

I'm using your i686 F/SM builds, for one because old BIOSes are causing disk full-errors even without several large, nearly identical files (one per targetted CPU), and it works as good as it gets in the range i686 - IBM ThinkPad T42p.

Seems weird that the BIOS would even be aware of what files you have on the drive.
My T42 has a Pentium M and runs the Pentium M builds fine, even plays Youtube videos without much skipping.

When my (single core, eCS) P4s stop working, none is perfect, a logical next step may be a - possibly surprising - CPU downgrade. You tend to use the best hardware, but one day even here P4s will become less common. Due to a "forced" switch to PIII( Mobile)s and PIIs for Mozilla-based browsing (won't work with PIIIs, last time I checked). It's that, or letting Microsoft torture new disks. Unless there's a good, "fully" functional ArcaOS NLV release for > 1 core.

I can't imagine why a PIII wouldn't run the i686 version, a PIII is basically the same as a PII or i686 with more cache and MMX and SSE units added as well as other minor improvements and is the direct ancestor of the Pentium M, which itself is the direct ancestor of the C2D.
As for P4's, I had one, a 2.8Ghz P4D, made a great space heater along with jacking up the hydro bill. I ended up swapping the CPU for a 1.86Ghz C2D and not only did it use half the power, but it compiled Mozilla almost twice as fast. I was then donated a Core Extreme at 2.8Ghz and that flew, shame when the MB gave up the ghost.

[xynixme]

Seems weird that the BIOS would even be aware of what files you have on the drive.

I can't imagine why a PIII wouldn't run the i686 version

It's the maximum supported disk capacity, and the worst eCS-hardware (i.e. no OS/2 Warp 4 80486 test device) score counts. Plenty of free space when I grab a T42p, so I can test a specific optimized build, but free space of lesser hardware (including irrelevant backup media), per device, is about 170 MiB (160 MiB reserved for maintenance), 40 MiB, about 30 MiB (reserved for data), and about minus 60 MiB (smallest backup device). I haven't tried YouTube with the i686 build yet, other than selecting a video to obtain the URL for a downloader, for one because of a rather specific problem with a possible dangerous fix (a.o. https://forum.thinkpads.com/viewtopic.php?t=57021).

My P4 IBM A30 desktop, slower than a T42p, has a 2.x GHz CPOU which is a little bit to slow for videos with W7 (Microsoft couldn't be bothered to aupport the Intel chipset). The same reason why I once upgraded my T42p CPU. Regarding FF/SM and PIIIs, it's a know problem that a PII works better than one may expect (startup time) and it's usable (obviouslyvideo will kill the radio start). A PIII Mobile (ThinkPad T23) works as expected. With a 500 MHz PIII the performance is the worst by far (startup time, verything takes "minutes"). I'll test that again, because I probably haven't started SM there since the latest i686 build.

[Doug Clark]

Dave,

I have installed Mozturbo.  Firefox 45 crashes pretty regularly - especially when replying to posts on this site. Seems to be related to attaching files as part of the reply. I have attached a trap from this morning.

[Dave Yeo]

Unluckily, without the debug package, the trp doesn't tell much.
I'd suggest updating to my build. You could even install it over the RPM package you have (don't forget to copy firefox.exe to \usr\bin). Also unload mozturbo first, mark the DLLs high afterwards and reinstall mozturbo.
I rebuilt SM here and it seems to crash a lot more, I suspect that changes in libc may be to blame.

[Dariusz Piatkowski]

Dave, everyone...

...mark the DLLs high afterwards and reinstall mozturbo...

We often talk about this approach, which I am using here successfully by all accounts. However, I honestly never know if I should be marking the DLL as:

1) code only
2) data only
3) both

Right now I have them all marked as 'code only' since in the past I have read various posts suggesting that not all data objects may be compatible with the load high option, especially when it comes to the kind of software that FF is, meaning: numerous DLLs being invoked, therefore large amounts of data movement, etc.

But is there a better explanation than that?

[xynixme]

...

[Dave Yeo]

There has been versions of FF where loading both code and data high worked fine here though IIRC, loading the data high made the 45ESR versions crashy, you can always test.
I believe the problem is that simply any 16 bit code in the system that needs to access the data will fail as 16 bit code just can't deal with addresses above 1 GB.
It's the same with mallocing memory above 1 GB, have to be careful not to use any 16bit API, which is the purpose of os2safe.h.
I'll note that looking at the xul.dll map file, the data group (segments) is relatively small,

Code: [Select]

CGROUP                          0001:00000000        03aab000
DGROUP                          0002:00000000        0009fb00


[xynixme]

Recently I had to unload MOZTURBO and SMTUBRO before a shutdown (eCS, eCenter, INI files close to being corrupted), to make a moved desktop icon stick. FWIW and FTR.

That may be a false claim, based on one clear case which suggested a link. With several other systems this move had to be done step-by-step too. One of the steps still is unloading the turbo's, to make sure the system (xCenter not installed) will shutdown as clean and regular as possible, but apparently there's no link. I haven't tried to make the move stick without unloading the turbo's, because making the move stick was a PITA, but it's too unlikely that many INI files are close to being fatally corrupted.

[OS4User]

There has been versions of FF where loading both code and data high worked fine here

The same is here. I always mark  data and code of FF to be loaded into HiMem  - so far it works ok.