poke01
Diamond Member
No American company can cause Intel/AMD don’t license x86.I'm done with this topic until Apple release a x86 cpu. Meaning... I'm done.
I agree let’s drop it.
No American company can cause Intel/AMD don’t license x86.I'm done with this topic until Apple release a x86 cpu. Meaning... I'm done.
It's small potatoes legacy stuff - it's already been done, no new changes are made, no way this increases complexity by more than 1%, which is fine cost to maintain 100% backwards compatibility rather than anything less.You're seriously underestimating the cost of desgin and more the one of validation, and the impacts on how you can let an ISA progress with such dead 50 years old weight.
It's never done, believe me 🙂 Any change to anything that is shared by obsolete paths and more modern paths will require validation. These things don't live in complete isolation from the rest of the CPU; a trivial example is the sharing of the memory hierarchy.It's small potatoes legacy stuff - it's already been done, no new changes are made, no way this increases complexity by more than 1%, which is fine cost to maintain 100% backwards compatibility rather than anything less.
Awww. The good old days!It's never done, believe me 🙂 Any change to anything that is shared by obsolete paths and more modern paths will require validation. These things don't live in complete isolation from the rest of the CPU; a trivial example is the sharing of the memory hierarchy.
Out of curiosity, do you really run 16-bit code?
I agree that killing 32-bit is premature. My point is that the much praised compatibility is an illusion. As I previously wrote trying to run >20 yo 32-bit programs is much easier by using simulation rather than trying to tweak a modern Windows and finding the needed DLL that might fail to work completely anyway. It took me less than an hour to build from scratch a 86Box that could run a game that required Glide (for 3dfx Voodoo), and I had never used 86Box before that. When I used to have a Windows machine with Windows 7 I never succeeded at that (of course that might be me, but I couldn't find any relevant help to get around my issues).I doubt that 16bit is needed; however, 32 bit is a VERY different story as are a number of extensions.
Backwards compatibility is definitely a real thing in PC's.
Most are 32bit AFAIKAre all current Windows app 64-bit now?
no they ain't.Most are 32bit AFAIK
Mmm surprising, I really thought most apps were stupidly compiled (to push it : 386 target 🤣).no they ain't.
You'll struggle to find non-amd64 builds anywhere now (outside of older video games. Curse you Total War Attila).
Well, we have customer where one production line is controlled by max. 75MHz Pentium (and DOS of course). Faster than 75MHz and good old Pascal compiled code goes grazy 😅Mmm surprising, I really thought most apps were stupidly compiled (to push it : 386 target 🤣).
That’s good news.
We’re still obligated to use 32 bit version off 365 ´cos a stupidly old work-related app is based on Access with compiled module. Impossible to run it with 64 bit Access.
Yes, that’s prehistoric (both Access and 32bit).
IMO a lot of specific software like used in industries and certainly those used in school (industry sections)are so old they both require 32bit and Win 7 so not to be broken. I tend to laugh but it really isn’t that funny …
I think 16-bit usermode has been deprecated since Zen1, it's only supported for legacy boot stuff.It's never done, believe me 🙂 Any change to anything that is shared by obsolete paths and more modern paths will require validation. These things don't live in complete isolation from the rest of the CPU; a trivial example is the sharing of the memory hierarchy.
Out of curiosity, do you really run 16-bit code?
The big problem for 16-bit was InstallShield. It's a proprietary install packager that half the world used for most of the 32-bit windows generation, because it was cheap, unobtrusive and worked well. It's mostly 32-bit, but installers created with old versions of it start with a 16-bit loader that checks whether you are running in 32-bit mode, and if not, exit with an error message that tells you that 32-bit OS is needed. This was a huge problem when 16-bit support was dropped, because no-one was updating their installer creator program, and so like half of all 32-bit software could not be installed because of this. Microsoft fixed this before 64-bit Windows became common by binary patching any InstallShield installers it could detect to jump over the 16-bit code.Haven't seen or used it for maybe 20 years. I doubt that 16bit is needed; however, 32 bit is a VERY different story as are a number of extensions.
Meanwhile this is what it takes to get the windows version of Sim City 2000 to run modern day.So now every copy of windows running everywhere has a database of some 90's and early 00's programs, and entry points to jump into to skip over the 16-bit parts. That's the cost of compatibility.
Well, no, APX was a golden opportunity.
Alas, Intel exists.
I agree that killing 32-bit is premature. My point is that the much praised compatibility is an illusion. As I previously wrote trying to run >20 yo 32-bit programs is much easier by using simulation rather than trying to tweak a modern Windows and finding the needed DLL that might fail to work completely anyway. It took me less than an hour to build from scratch a 86Box that could run a game that required Glide (for 3dfx Voodoo), and I had never used 86Box before that. When I used to have a Windows machine with Windows 7 I never succeeded at that (of course that might be me, but I couldn't find any relevant help to get around my issues).
Are all current Windows app 64-bit now?
This is getting way off-topic and the rest of my thoughts belong more to the iBOT thread 🙂
Not recently, and not writing it either since DOS/4GW was out! 😉Out of curiosity, do you really run 16-bit code?
32 bit will never be killed in x86, zero chance - ever.I agree that killing 32-bit is premature
of course 32-bit wont die, that would disrupt a lot of industries and software.32 bit will never be killed in x86, zero chance - ever.
And get killed in reviews that will point out that classics like Borderlands 2 run slower? There is just very little to gain doing such non-trivial things, and a lot to lose. There is plenty of modern 32-bit code around, Steam only recently got 64 bit version, and this is like 20 years since amd64 was out!But could be translated? Of course it can. That’s the future of computing. It’s foolish keep to 32-bit support forever natively.