From yesterdays meeting log ... "another week or so and will start looking at switching from aus2 to aus5"

What's 'aus2' and/or 'aus5'?? Are they something we users need to know about??

(adding two and two together and getting .......) Also from yesterdays meeting log, njsg mentions someone posting to E-S test group using a WOW64 build.

That could have been me as I DO post to E-S.test (Daniel70 at the moment) and this (2nd hand in 2009) Laptop came with WINDOWS 7WOW64 pre-installed.

I've since Dual-boot Installed the Win7WOW64 with various 64 bit Linux OS's but kept the WIN 7WOW64 updated as much as possible, certainly Anti-Virus, .... you know, just in case the Linux falls over.

If you guys do give up support for 32bit, I guess I'll just have to blow-away my WIN 7WOW64 installation!! ;-P

If you don't mind me asking, why are you using a 32-bit build of SeaMonkey?

Or, perhaps if you prefer the rewording, why aren't you using the 64-bit build instead?

njsg: 32 bit SM on Win7 WOW64 because I was told it was a 64bit OS that had been fiddled with so it could run 32bit programs.

I've never actually thought of downloading a 64 bit SeaMonkey to try running it !!

Prehaps my understanding of what WOW64 means is stuffed up!! ;-P

Perhaps that stems from my (long time) previous Internet aaccount being very, very limited in how much I could download, so didn't experiment much.

roughly speaking, WOW64 is the name for the ability to run 32-bit applications on a 64-bit Windows OS

Ah!! So I had it arse about!! Boo Hiss

Seeing WOW64 in the unmodified UA string of a Windows user means that it's a 32-bit build on an OS capable of running a 64-bit build (because the OS itself is 64-bit)

Thus if your install says WOW64, the advice would be to use the 64-bit build, unless you have a reason not to.

(There might be such reasons, it's just that asking this question might go straight to the point of understanding whether there is a need for the 32-bit build or not)

Having had a little bit of experience programing for 8085/Z80/6809 8bit CPUs, I though all the instructions/data (a.k.a. the 'word' width) for a 64bit CPU had to be, well, 64bits wide .... so what would a 32bit OS do with the other 32bit?? ;-P

The biggest issue one can run into that may still be an issue is if 64bit on windows doesn't like your gpu driver .. 32bit can seem not to poke the driver in the same way and all can be fine..

but that has become increasingly a rare condition as crappy intel/nvida hybrid craptops age out plus code improvmenets

fortunately Broadcom doesn't make laptop GPUs... or do they?

the only other things that may want warrent 32bit vs 64bit on windows are binary xpcom extensions (which are crippled) and npapi plugins (which i think are just gone) so yeah not much reason

njsg: lol

yeah, plugins did occur to me, and that used to be a thing in the Adobe Flash days, didn't it? I think I recall something about Adobe not providing binaries for Windows amd64?

adobe got conned into believeing google would let them play in the marketplace

but you know how long the adobe cdm lasted

nsITobin under Windows the latest 32 bit drivers are all crap. And I tried Intel AMD and Nvidia laptops.

well yeah for new cards

but older hardware the 64bit gfx drivers tend to not always mix well with gecko

but 32bit version would work perfectly

nsITobin nope. NVS140 Nvidia 3.42.01 Intel pre HD 4000 and AMD Pre 7700 are all good for the trash.

Nvidia needs 400.xx or up.

so why did they have to bust old working drivers

?

god i love php

especially building off my evolving anti-framework

nsITobin They use(d) more hardware acceleration. I usually see black widgets and redraw problems. Also media playback errors or crashes.

well even if seamonkey fully reenabled binary xpcom extensions I'd still say drop 32bit

frg_Away: unless you wanna focus on e10s before you HAVE to I just don't see a xul program and half a dozen webapp tabs fitting within the artifical 4gb restriction

without otherwise chugging

and isn't bigint not possible on 32bit cause the int is too big?

nsITobin Coincidence. Jjust ripped out the last remnants of binary-component in 2.53. Even something mozilla overlooked so far in the manifest parser. Unlike TB we never set the variable and there was no processing left anyway so I don't expect anything to complain about it.

except me

;)

There was nothing but the statement left: gitlab.com/frg/seamonkey-253-patche…733b96aa8a2d63132b432c5adfd839c3d08

so what we don't have binary xpcom components at all now? its static loaded?

Was defunct even in 52.

The xpts still work fine. Just not DLLs or so files embedded. The last use was Lightning but even defunct before 52.

well it means something like minimize to tray is not possible

frg_Away: which do you think would be more work getting vs2022 or just switching to clang-only on windows?

VS2022 needs some ipc changes then it would work. Easy would be to use the VS2019 compiler in VS2022. Did this for 2.49.5. If you state VS2019 it picks the VS2017 component there.

0930|22:06:28 <+nsITobin> and isn't bigint not possible on 32bit cause the int is too big? <-- if this is an issue, I have... questions about bigint. Signed, Lisp coder.

WG9s my WIP x86 build just completed in 18 minutes but with tests disabled. I can enable tests and retry. So far it was pretty normal.