Given that 64-bit Windows has been shipping for so long, you would
think most Windows software, particularly Microsoft’s own software,
would have made the transition from 32-bit long ago. After all, on a
typical 64-bit Linux system, everything is 64-bit, and has been that
way since the early days.

So I was mildly surprised to discover that Visual Studio only became
64-bit in November 2021. And today I am even more surprised to discover
that the change broke its own Windows Forms framework, and a fix is
still not available to this day
<https://devclass.com/2024/02/26/microsoft-struggles-to-address-fallout-from-windows-forms-designer-failure-in-64-bit-visual-studio/>.

On 2024-02-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> Given that 64-bit Windows has been shipping for so long, you would
> think most Windows software, particularly Microsoft’s own software,
> would have made the transition from 32-bit long ago. After all, on a
> typical 64-bit Linux system, everything is 64-bit, and has been that
> way since the early days.
>
> So I was mildly surprised to discover that Visual Studio only became
> 64-bit in November 2021. And today I am even more surprised to discover
> that the change broke its own Windows Forms framework, and a fix is
> still not available to this day
><https://devclass.com/2024/02/26/microsoft-struggles-to-address-fallout-from-windows-forms-designer-failure-in-64-bit-visual-studio/>.

I'm not super surprised given the focus on backwards compatibility
Windows has.
--
user <candycane> is generated from /dev/urandom

On Tue, 27 Feb 2024 20:19:06 -0000 (UTC), Lawrence D'Oliveiro wrote:

> Given that 64-bit Windows has been shipping for so long, you would
> think most Windows software, particularly Microsoft’s own software,
> would have made the transition from 32-bit long ago.
>

Microslop aims for backward compatibility because the average Microslop
user, its total bread and butter, couldn't tell 32-bit from 64-bit from
their asshole from a hole in the ground.

GNU/Linux is very strict in this regard. Either adapt your software
to 64-bit or it won't execute.

Some distros allow a mixed 64/32-bit environment but that is abysmally
stupid.

I've had to convert source code from 32-bit to 64-bit and it is not
that difficult. All that I can say is "screw the holdouts!"

The advantages of 64-bit are extreme.

On Tue, 27 Feb 2024 21:15:47 +0000, Farley Flud wrote:

> The advantages of 64-bit are extreme.

In many cases the 'extreme' part is memory usage.

On Tue, 27 Feb 2024 21:15:47 +0000, Farley Flud <ff@linux.rocks> wrote in
<17b7d4c9e6813f4b$44012$2730048$802601b3@news.usenetexpress.com>:

> GNU/Linux is very strict in this regard. Either
> adapt your software to 64-bit or it won't execute.

> Some distros allow a mixed 64/32-bit environment
> but that is abysmally stupid.

The base Linux Steam executable is 32-bit, but forks
off and fires off 64-bit apps.

So if a platform has Steam...but I'm not talking
to you anymore, because Gentoo is (apparently) "Pure".

I used to be acquainted with a vegan. Only, he wasn't
just a "vegan", but an "animal abolitionist". (We don't talk
anymore.) You are more extremist than he ever was.

--
-v

On 2/27/2024 4:15 PM, Farley Flud wrote:

> The advantages of 64-bit are extreme.

memory mainly. And the miracle OS Linux can use nearly all of it just
installing one package:

"After installing xserver-xgl the memory usage immediately went up to
17179869180.0 GB for several packages."

#28 at
http://ubuntuforums.org/showthread.php?t=587905

That's 17 exabytes - for one package - just shy of the 18.4 exabytes a
64-bit CPU can address.

MS is doomed.

On Tue, 27 Feb 2024 20:30:09 -0000 (UTC), candycanearter07 wrote:

> I'm not super surprised given the focus on backwards compatibility
> Windows has.

32-bit executables still run. But recompiling code to use AMD64
instructions will take advantage of the greater number of registers
available, which makes the code more efficient.

So why is there still so much 32-bit Windows code around?

On 2/27/2024 5:41 PM, Lawrence D'Oliveiro wrote:
> On Tue, 27 Feb 2024 20:30:09 -0000 (UTC), candycanearter07 wrote:
>
>> I'm not super surprised given the focus on backwards compatibility
>> Windows has.
>
> 32-bit executables still run. But recompiling code to use AMD64
> instructions will take advantage of the greater number of registers
> available, which makes the code more efficient.
>
> So why is there still so much 32-bit Windows code around?

Likely because of the MASSIVE Windows installed base.

On Tue, 27 Feb 2024 22:25:11 -0000 (UTC), vallor wrote:

>
> The base Linux Steam executable is 32-bit, but forks
> off and fires off 64-bit apps.
>

Steam? Ha, ha, ha, ha, ha, ha, ha, ha, ha!

Games are for little retarded boys. Is that what you are?

Ha, ha, ha, ha, ha, ha, ha, ha, ha!

Dumb question.

The REAL MEN of computing have been using 64-bit GNU/Linux
for the past twenty years or so -- but whose counting?

Ha, ha, ha, ha, ha, ha, ha, ha, ha!

Now get back to your rocket ship, little boy, and shoot those
space aliens.

Ha, ha, ha, ha, ha, ha, ha, ha, ha!

On Tue, 27 Feb 2024 17:48:58 -0500, DFS wrote:

> On 2/27/2024 5:41 PM, Lawrence D'Oliveiro wrote:
>> On Tue, 27 Feb 2024 20:30:09 -0000 (UTC), candycanearter07 wrote:
>>
>>> I'm not super surprised given the focus on backwards compatibility
>>> Windows has.
>>
>> 32-bit executables still run. But recompiling code to use AMD64
>> instructions will take advantage of the greater number of registers
>> available, which makes the code more efficient.
>>
>> So why is there still so much 32-bit Windows code around?
>
> Likely because of the MASSIVE Windows installed base.

No new versions of that old code?

On 2/27/2024 5:54 PM, Licentious Larry wrote:

> On Tue, 27 Feb 2024 22:25:11 -0000 (UTC), vallor wrote:

> The REAL MEN of computing have been using 64-bit GNU/Linux
> for the past twenty years or so --

And look where it's gotten you: to comp.os.linux.advocaca.

Congrats.

> but whose counting?

whose? Stay in remedial Engrish class, bozo.

> Ha, ha, ha, ha, ha, ha, ha, ha, ha!
>
> Now get back to your rocket ship, little boy, and shoot those
> space aliens.

And space marines and The Strogg. Reduce 'em to gibs!

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 27 Feb 2024 20:30:09 -0000 (UTC), candycanearter07 wrote:
>
>> I'm not super surprised given the focus on backwards compatibility
>> Windows has.
>
>32-bit executables still run. But recompiling code to use AMD64
>instructions will take advantage of the greater number of registers
>available, which makes the code more efficient.
>
>So why is there still so much 32-bit Windows code around?

It's to use less RAM, and support 32-bit systems and VMs.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Tue, 27 Feb 2024 16:01:32 -0800 (Seattle), Relf wrote:

> On Tue, 27 Feb 2024 23:45:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> > > So why is there still so much 32-bit Windows code around?
>
> Because the original authors have moved on ?

You mean the code is now obsolete and unsupported?

Are there Windows users still entrusting mission-critical business
functions to such code?

On Tue, 27 Feb 2024 19:09:44 -0500, Joel wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>So why is there still so much 32-bit Windows code around?
>
> It's to use less RAM, and support 32-bit systems and VMs.

Does it really make that much difference to RAM? As compared to the
greater efficiency of compiling for 64-bit?

And those still running 32-bit systems are not a significant revenue
source any more, so it seems a waste to continue investing in them.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>>>So why is there still so much 32-bit Windows code around?
>>
>> It's to use less RAM, and support 32-bit systems and VMs.
>
>Does it really make that much difference to RAM? As compared to the
>greater efficiency of compiling for 64-bit?
>
>And those still running 32-bit systems are not a significant revenue
>source any more, so it seems a waste to continue investing in them.

I suspect it has as much to do with running apps in VMs as anything
else. But with Win10's passing, 32-bit OS platform will as well.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Tue, 27 Feb 2024 22:54:55 +0000, Farley Flud <ff@linux.rocks> wrote in
<17b7da32e6a5ddce$147$1404981$802601b3@news.usenetexpress.com>:

> On Tue, 27 Feb 2024 22:25:11 -0000 (UTC), vallor wrote:
>
>
>> The base Linux Steam executable is 32-bit, but forks off and fires off
>> 64-bit apps.
>>
>>
> Steam? Ha, ha, ha, ha, ha, ha, ha, ha, ha!
>
> Games are for little retarded boys. Is that what you are?

Don't be stupid: "games" are a medium. Like books.
Like movies.

Do you watch movies, you soft-headed, projecting
little boy?

The gaming industry is bigger than the movie-making
industry, and that's before counting games of
chance. (Think: casinos.)

(You wouldn't be allowed in a casino -- they are for
grown-ups who shower and dress themselves properly.)

Meanwhile: to be a successful desktop operating
system, Linux needs to support gaming. And it does.

And you've shown evidence that your Linux system
is too underpowered for anything but trivial
games, as can be seen by the Gentoo packages
you've repeatedly shown you have installed.

That also means anything using GPU acceleration,
such as generative AI text-to-image, either won't
run on your system, or will run so slow you won't
bother.

Are you...jealous?

Bwaah!

--
-v

On Wed, 28 Feb 2024 00:09:52 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <urltkg$3fq8i$2@dont-email.me>:

> On Tue, 27 Feb 2024 16:01:32 -0800 (Seattle), Relf wrote:
>
>> On Tue, 27 Feb 2024 23:45:29 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>> > > So why is there still so much 32-bit Windows code around?
>>
>> Because the original authors have moved on ?
>
> You mean the code is now obsolete and unsupported?
>
> Are there Windows users still entrusting mission-critical business
> functions to such code?

DFS is apparently running code a few decades old.

Word 2003 was it?

--
-v

On Tue, 27 Feb 2024 20:27:01 -0500, Joel wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>>>So why is there still so much 32-bit Windows code around?
>>>
>>> It's to use less RAM, and support 32-bit systems and VMs.
>>
>>Does it really make that much difference to RAM? As compared to the
>>greater efficiency of compiling for 64-bit?
>>
>>And those still running 32-bit systems are not a significant revenue
>>source any more, so it seems a waste to continue investing in them.
>
> I suspect it has as much to do with running apps in VMs as anything
> else.

Whether they are running apps in VMs or not, is anybody still buying new
32-bit software?

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>>>>>So why is there still so much 32-bit Windows code around?
>>>>
>>>> It's to use less RAM, and support 32-bit systems and VMs.
>>>
>>>Does it really make that much difference to RAM? As compared to the
>>>greater efficiency of compiling for 64-bit?
>>>
>>>And those still running 32-bit systems are not a significant revenue
>>>source any more, so it seems a waste to continue investing in them.
>>
>> I suspect it has as much to do with running apps in VMs as anything
>> else.
>
>Whether they are running apps in VMs or not, is anybody still buying new
>32-bit software?

I don't believe that I was aware of whether it was 32-bit or 64-bit,
when purchasing commercial Winblows software.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Tue, 27 Feb 2024 20:54:11 -0500, Joel <joelcrump@gmail.com> wrote in
<le4tti1fijh2inuqef5qpi6q3k83qit63q@4ax.com>:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>>>>>So why is there still so much 32-bit Windows code around?
>>>>>
>>>>> It's to use less RAM, and support 32-bit systems and VMs.
>>>>
>>>>Does it really make that much difference to RAM? As compared to the
>>>>greater efficiency of compiling for 64-bit?
>>>>
>>>>And those still running 32-bit systems are not a significant revenue
>>>>source any more, so it seems a waste to continue investing in them.
>>>
>>> I suspect it has as much to do with running apps in VMs as anything
>>> else.
>>
>>Whether they are running apps in VMs or not, is anybody still buying new
>>32-bit software?
>
>
> I don't believe that I was aware of whether it was 32-bit or 64-bit,
> when purchasing commercial Winblows software.

All the Windows software I buy is 64-bit -- and they have
to be, because they are large, complex, and high-performance.

e.g.:
$ file Starfield.exe
Starfield.exe: PE32+ executable (GUI) x86-64, for MS Windows

(I run them on Linux with proton-ge, as you know.)

I'll bet there's a gcc tool (objdump?) that can look at an
application and determine what special processor features
it uses for x86-64. Anyone know?

(And thanks to DXVK, they might even run faster on Linux.)

--
-v

On Tue, 27 Feb 2024 18:51:49 -0500, DFS <nospam@dfs.com> wrote in
<lAuDN.606620$p%Mb.315367@fx15.iad>:

> On 2/27/2024 5:54 PM, Licentious Larry wrote:
>> Now get back to your rocket ship, little boy, and shoot those space
>> aliens.
>
> And space marines and The Strogg. Reduce 'em to gibs!

You know there are more sophisticated games out than
Quake, right?

There are no on-foot Thargoids in the flesh in Elite
Dangerous Odyssey. (Yet?) Maybe Frontier is too chicken
to roll them out as a feature, as they might be rather
disappointing.

Elite is first and foremost a starship simulator. Everything
else is an excuse to fly starships, engineer starships,
and battle other starships (potentially, other players, if you
so choose).

The release of Odyssey took some of that focus away
by adding on-foot gameplay ("space legs"). One can be
a stealth stainless-steel rat and pilfer materials and data
from bases to engineer weapons and suits. If I'm doing
that, I avoid killing the NPC's.

There are also pitched battles for factions
in conflict, if you want more pew-pew without gaining
notoriety or bounties.

What I'm trying to say is Quake II, while fun, is kid's stuff
compared to what's out now. (Heck, it's kid's stuff compared
to Half-Life, and that is ancient.)

EDO doesn't have gibs. It does have interactive fiction,
much more immersive than watching a video.

--
-v

vallor <vallor@cultnix.org> wrote:
>On Tue, 27 Feb 2024 20:54:11 -0500, Joel <joelcrump@gmail.com> wrote in
><le4tti1fijh2inuqef5qpi6q3k83qit63q@4ax.com>:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>>is anybody still buying new
>>>32-bit software?
>>
>> I don't believe that I was aware of whether it was 32-bit or 64-bit,
>> when purchasing commercial Winblows software.
>
>All the Windows software I buy is 64-bit -- and they have
>to be, because they are large, complex, and high-performance.
>
>e.g.:
>$ file Starfield.exe
>Starfield.exe: PE32+ executable (GUI) x86-64, for MS Windows
>
>(I run them on Linux with proton-ge, as you know.)
>
>I'll bet there's a gcc tool (objdump?) that can look at an
>application and determine what special processor features
>it uses for x86-64. Anyone know?
>
>(And thanks to DXVK, they might even run faster on Linux.)

Photoshop was probably 64-bit, I guess, it never occurred to me to
check that in Process Explorer. It wasn't worth what I paid for it.
GIMP is just as good, nearly.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Tue, 27 Feb 2024 22:11:28 -0500, Joel <joelcrump@gmail.com> wrote in
<mt8ttilgd9igv1vd76rl4h1evpfucma3a7@4ax.com>:

> vallor <vallor@cultnix.org> wrote:
>>On Tue, 27 Feb 2024 20:54:11 -0500, Joel <joelcrump@gmail.com> wrote in
>><le4tti1fijh2inuqef5qpi6q3k83qit63q@4ax.com>:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>>is anybody still buying new 32-bit software?
>>>
>>> I don't believe that I was aware of whether it was 32-bit or 64-bit,
>>> when purchasing commercial Winblows software.
>>
>>All the Windows software I buy is 64-bit -- and they have to be, because
>>they are large, complex, and high-performance.
>>
>>e.g.:
>>$ file Starfield.exe Starfield.exe: PE32+ executable (GUI) x86-64, for
>>MS Windows
>>
>>(I run them on Linux with proton-ge, as you know.)
>>
>>I'll bet there's a gcc tool (objdump?) that can look at an application
>>and determine what special processor features it uses for x86-64.
>>Anyone know?
>>
>>(And thanks to DXVK, they might even run faster on Linux.)
>
>
> Photoshop was probably 64-bit, I guess, it never occurred to me to check
> that in Process Explorer. It wasn't worth what I paid for it.
> GIMP is just as good, nearly.

I haven't had to do any image editing that GIMP couldn't handle.

For video, there's Black Magic's DaVinci Resolve as a native
Linux application, with a very generous free license for
hobby work. I use kdenlive though.

--
-v

On Tue, 27 Feb 2024 22:41:40 -0000 (UTC), Lawrence D'Oliveiro wrote:

> On Tue, 27 Feb 2024 20:30:09 -0000 (UTC), candycanearter07 wrote:
>
>> I'm not super surprised given the focus on backwards compatibility
>> Windows has.
>
> 32-bit executables still run. But recompiling code to use AMD64
> instructions will take advantage of the greater number of registers
> available, which makes the code more efficient.
>
> So why is there still so much 32-bit Windows code around?

Third party libraries in some cases. One example I'm familiar with is
Esri. Up through 10.8.2, ArcObjects was COM based and the SDK was
originally C++/VB although they expanded to .NET. They ate their own
dogfood so ArcGIS Desktop was also 32bit.

With 11.0+ they went to 64bit and introduced ArcGIS Pro as the replacement
for Desktop and a couple of new SDKs that don't really match up to the old
ArcObjects. 10.x will be going out of support.

Here's the rub. GIS departments have been using Desktop for close to 15
years and have developed workflows and scripts using ArcObjects. Pro is
quite a bit different and really is aimed at ArcGIS Online and cloud based
solutions. the change over involves a certain degree of pain and the users
will eventually get dragged there kicking and screaming.

That's only one example. Like old soldiers legacy code never dies and it
fades away very, very slowly. If you have a 32bit product that works and
accomplishes what it's meant to do there is very little advantage to
rebuilding it for 64bit.

vallor <vallor@cultnix.org> wrote:

>> Photoshop was probably 64-bit, I guess, it never occurred to me to check
>> that in Process Explorer. It wasn't worth what I paid for it.
>> GIMP is just as good, nearly.
>
>I haven't had to do any image editing that GIMP couldn't handle.

paint.net was nice, under Winblows, but GIMP under Linux means I don't
have to cling to M$.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.