>>105801086 (OP)
32 bit doesn't mean wrong or even obsolete. There are still new 16 bit applications being made.
A 32 bit application doesn't even mean it'll quit working in 2038, this is another piece of FUD just like what happened during Y2K when people were convinced nuclear weapons would launch themselves. But of course /techlet/ won't get it.

>>105801099
They're limited to 4GB of RAM, though. You keep saying they're still good but not explaining why.
This thread is pure shit.

>>105801086 (OP)
For use in non-native and non-bare metal environments
There's a lot of software out there that sandboxes, isolates, emulates or otherwise loves to go in-between your application and your operating system. And some of them just work better with 32-bit binaries over 64-bit ones.

>>105801147
>They're limited to 4GB of RAM, though.
And?

>>105801147
>oy vey, you must let us use all of your ram, goyim
>we wouldnt want to leave any speed on the table, would we?

>>105801086 (OP)
It shows you're retarded and know nothing about computers.
>most applications don't require more than 4GB of mem
>32bit applications consume less memory than 64bit due to pointers being 32bit long instead of 64
>the OS already bundles with libs for running 32bit apps
>if built with the correct tools it can be automatically backwards compatible with older versions of windows

>>105801086 (OP)
>does the same thing
>compatible with x86 and x64 systems
>somewhat smaller binary size and memory footprint

>>105801185
And writing 32-bit applications comes with some caveats.
>>105801197
>mouthbreather fuckup starts foaming at the mouth about sheenies when called out for his stupidity.
Go take your riatlin, mongo.

>>105801210
>smaller binary size and memory footprint
This is in the kilobyte range. It doesn't matter.

I kinda miss when my pointers were only 4 bytes.

not everything has a 64 bit word length, most devices have 32 in fact

>>105801099
why not utilize the full 64 bit ISA which has more & better instructions? every consumer PC is 64 bit these days.

>>105801204
>he called op retarded
>he thinks the only difference between 64bit & 32bit ISA is how much memory they can address
ironic

>>105801171
the only actual good answer

>>105801086 (OP)
Why not? They run just fine on 64-bit machines.

>>105802163
the 64 bit instruction set is better
the argument used to be compatibility with old machines but these days literally everyone has 64 bit machines

>>105802056
of course its way more than that you nigger, but for practical purposes it's just that

>>105801086 (OP)
Why do people still post this frog?

>>105801147
Linux with PAE extension, can address more ram. It's not a actual limit..

>>105802181
You are not everyone. Fedora recently tried to drop 32bit and received massive objections.
But yeah compatibility to old devices is being dropped in general.

>>105802837
The application has to be built with PAE in mind, negating any advantage it might have over a 64 bit application. Additionally, the Linux colonel has been dropping support for 32 bit in general for a while now.
What weird, convoluted, demented hill to die on.

>>105802864
Not really, your attempted troll rant.. comes of as demented.

>>105802864
Wat?
It’s been like this from the beginning.
It’s 64-bit they should be dropping—if anything.

We should have dropped little-endian support decades ago. Now we’ve got little home pee cee users up in our shit.

>>105802837
>Why do people still post this frog?
maybe because it originated from here? and everyone think its funny, except for trannies & libtards who are offended by it for some odd reason i never quite figured out

>>105802906
>nonononono stupid shut up nonono moooooom
Pathetic.

>>105801086 (OP)
I seriously think backwards compatibility is holding back software. Apparently most saarScript stupid logic with types is because it allows for older websites to keep running, if we could somehow purge them we could have the perfect scripting language,

>>105801147
>They're limited to 4GB of RAM, though.
Good.

>>105801086 (OP)
8 bits is all you need.

>>105801211
if i'm not using even a tenth of that amount of ram, it's not a caveat :) :) :) :) :) :) :)

>>105801147
theres nothing wrong with that at all
as long as 32-bits guarantees functionality of the software, if it works it works

>>105801086 (OP)
There's actually a really simple reason. 32-bit DLLs don't work with 64-bit programs. So if you use any existing library which hasn't been rewritten and recompiled for 64-bit, your entire program has to be 32-bit. And if you have inline assembly in your C/C++ code, which isn't too rare for game engines or multimedia programs, you probably have to rewrite the ASM because the ABI has changed even though the instructions are still compatible from 32-bit to 64-bit CPUs. It has nothing to do with efficiency or memory usage.

>>105801147
>They're limited to 4GB of RAM
A single instance of software should not use more than 4GB
Hell, I think you just made me realize that computing when wrong with the mass adoption of 64-bit

>>105801086 (OP)
Nearly always because some company who buys a lot of stuff still wants it, or wants the option to use it. In the early days of 64 bit PCs with small memories and caches, 32 bit programs were often faster because data structures and code were more dense, and more of each could fit into cache, and if you have 4GB, you have more capacity with 32 bit code because of this density. Once the center of PC mass became 8GB, though, this all changed.

>>105801086 (OP)
32 bit Windows 6 is the new DOS. If you target it then it will run everywhere, even Linux.

>>105801086 (OP)
is 32bit window stuff because it runs better in wine for linux?

>>105804057
>Windows 6
Vista?

>>105801086 (OP)
uses less RAM

>>105805009
JUST BUY A NEW MACHINE

>>105801147
that is beyond enough for most applications

>>105805025
learn to write software

>>105805374
>image
The original quote is by Henry Petroski.

>>105805487
so what. the reply isnt wrong.

>>105801086 (OP)
32-bit addresses suffice for most software
99% of all sign extensions end up overwriting zeros with zeros

>>105801086 (OP)
embedded computers in factories/crappy sales terminals or price scanning systems

>>105805656
The thing I hope happens with the "AI Revolution" is that new OS and apps come bloated as well with llms and forces companies to throw away all of this e-waste

64bit is bloat

>>105801086 (OP)
Companies wanted to be able to use old stuff, gamers wanted to play old games, people wanted to keep using old apps. Which is why Microsoft bends over ass-backwards to maintain compatibility. They know they'd get fucked if they didn't.

>>105805667
>I want software to become MORE bloated than it already is, and I want this for the EXPRESS purpose of making perfectly serviceable devices inoperable

>>105805872
> "Perfectly servicable"
This is no different than someone who hoards junk in their house. At some point we must accept that things must be let go off after they complete their role.

>>105806109
>ESL
opinion discarded

>>105806171
As if a retard amermutt will have a better opinion over a high iq european.

>>105801219
32bit is significantly more dense than 64bits. This is most notable for function calls. 64bits has significant overhead in function calls. For one thing, push takes significantly fewer bytes than mov. Often within functions on 64bit arguments will need to be saved, whilst on 32bits they are already saved in memory. A lot more small functions are inlined on 64bits due to the overhead of function calls. Also 64bits has those unwind tables which take a massive amount of space.

>>105805723
They don't though, a lot of 9x/XP era software and games doesn't run unless you use some sort of fork or VM.

Even some mid-2000s stuff just doesn't run on 10 or 11.

>>105806109
NPC goyim spotted.

>>105806240
> push takes significantly fewer bytes than mov
64 bit x86 has twice as many registers.
So less pushing.

>>105801086 (OP)
with tech every advancement and update is using 80%, or more, of the previous iteration. and over time you end up with parts that are decades old, hasn't been touched since the guy who wrote it left the place, yet it is integral

>>105806722
I am talking about using push for function arguments.
push is 1 byte for register, 2 bytes for small constant
mov is 2/3 bytes for register, 5/6 bytes for constants
The prologs of 64bit functions are also significantly more expensive that 32bit. Often arguments need to be immediately spilled, whilst in 32bit they are already on the stack so don't need to be spilled again.

>>105801086 (OP)
32-bit ARM is a thing
Maybe also RISCV

>>105802837
>Linux with PAE extension, can address more ram
The kernel can, meaning it is able to host multiple processes that each consume close to 4GB RAM.
Each process is still limited to 4GB.

>>105803339
>backwards compatibility is holding back software
Tell this to the Perl guys, they still rock it like it's 1995. Every language improvement since then is gated behind an opt-in pragma, with predictable outcomes.

>>105806950
Prototypes were a mistake and Signatures were too late to the party and aren't even useful. You are saving one line of code literally. You can just make list assignment from @_ in one line and for consistency always use refs for lists and hashes. There is no performance penalty like with signatures and the code is obvious. First line of the sub is a "signature" and I even tried it with some LSP and it understood arguments to the sub without even POD. Alternatively use hash as named arguments pattern.

>>105801086 (OP)
Because I have to support 32-bit software and can't be fucked to change my dev environment.

>>105806267
Yeah, but compare with OS X. You're lucky if anything runs after a few years unless it's being constsntly updated, whereas on Windows you at least have a chance of making your 20+ year old vidya run. Warcraft 3 from 2001 just works on my machine. Even on the cases that your ancient piece of nostalgia just doesn't work, there's always a solution online. Go to any other OS, and it becomes far more painful. If making that stuff work on Windows is already hard, then trying to use it on Linux or Mac is even worse.

That being said, by this point I hate Windows so much that if it wasn't for the fact that emulating engineering programs is unholy, (these pieces of shit will chug and crash even on a beefy PC, emulating them makes them unusable) I'd have already made the jump to something else. Gaming emulation is rapidly improving, and I mostly play simple older vidya that won't be heavy to emulate, so. It's just work that prevents me.

>>105801147
Would steam be as bad as epics if they went 64 bits ?

>>105801086 (OP)
for poorfags who can't afford apple

>>105808932
>Buys a $30k+ yearly SCADA subscription packagemultiple factories
> Software is 32-bit because it costs a fuck tonne to recert system to please a chud
> NooOooOooOo!! You're poor!!!!
Apple fabs probably run on 32-bit

>>105808932
Engineering companions will happily give their employees 10-15k$ workstations for their jobs but will still not buy anything from Apple because none of their software runs on MacOS, though.

>>105801086 (OP)
64 bits means you have 64 bits to store ascii thats 1 byte long, you can see how certain applications will be faster in 32 bit

>>105809118
also, they are not faggy itoddlers

>>105809343
>64 bits to store ascii thats 1 byte long
How many variables of exactly 1 char do you think are in any program?
Hint: it's a tiny, irrelevant quantity.

>>105807152
>Prototypes and Signatures
do not forget the cherry on the cake: smartmatch

>>105801099
>There are still new 16 bit applications being made.
Name them

>>105801147
The utter state of webshits

>>105806830
I'm not sure about the exact reasons, but I'm sure they have a good reason to use mov instead of push by default. It definitely simplifies the alignment of the stack, which is a requirement.
mov into a register is also faster than push. And you pass 4 arguments in registers in x64. While you might have to spill them, this allows for other optimizations. You might not have to touch the memory at all.
I'm not certain about things being more expensive at the end of the day.

>>105810397
webshit lives rent-free in your head

>>105806830
64 bit PIC code is more efficient in time and space than 32 bit PIC code
Code size is insignificant, pointers being twice as large on 64 bit is much more significant for memory usage

>>105801086 (OP)
some people are just based i guess

>>105805872
first time talking to a commie? finding things that work and destroying them with the excuse that they don't find them good enough is their fundamental MO

and eventually you have to understand that the purpose of a system is what it does

>>105801086 (OP)
because if your program is simple, doesn't use more than 2GB of ram, and non performance critical, there is NO reason to ever bother compiling for 64 bit and dealing with releasing 2 builds of your code.
>inb4 release 64 bit only
Then you can't run it on windows XP, and your file size is bigger.
No advantages, only downsides.

>>105805374
>using a 363 KB imahe to convey a ~250 character message about ridiculous waste negating astonishing technological improvements.

>>105810295
Josh, Rebecca and Jeremy.

>>105804003
Why not? Video editing and complex 3d require more to work smoothly.

>>105812714

>>105812634
>Then you can't run it on windows XP, and your file size is bigger.
Well, you can't run it on Windows XP anyway if you use a modern version of Visual Studio.

>>105813108
It doesn't matter. You can easily shim out those incompatible APIs and projects exist to do so (I think it's called one core API). Vista has extended kernel. For windows 7 you use vxkex. One click, at least with vxkex that I'm using on my pc, and whatever "incompatible" apps are working.
But if you compile for a different CPU architecture then it's game over.

>>105803880
>>105804003
Can't use vmap on a large file.

>>105813259
Mmap*, mistyped

>16bits
(∀)