wierd_w wrote on 2026-09-23, 16:23:

Classic/openshell ftw

Well... I used it since vista, when I updated to win8 the first time I didn't even notice the "square thing"

. You should use ut even on win11,

Seems absolutely obvious to me. Albeit startallback does a way more complete service to win11, I usually disable its start menu (which isn't bad at all), leaving to classic shell the liberty to manage the start button, while keeping all other startallback goodies still available

I use explorer patcher myself, I used to use Startallback but they had a period where their updates would keep breaking things so I switched.

The Solutor wrote on 2026-09-23, 13:44:

They took a shortcut, they could have enforced PAE test on the WHQL certification, but they preferred to throw the baby out with the bathwater, pushing the x64 thing that was (and mostly still is) detrimental rather than an improvement for most users.

That is, not the dirtiest MS move ever, but still dirty enough.

Which users is x64 more detrimental than useful for?

X64 is way better for anything that uses values higher than the 32-bit limit in math type functions.

It is better for gaming. It is better for CAD. It is better for precision.

Sure you can use large number libraries with 32-bit only, but that adds a slowdown compared to native x64.

Also, hopefully soon there will be a way to run native x64 code in DOS (part of one of my side-projects)

cyclone3d wrote on 2026-09-24, 02:15:

Which users is x64 more detrimental than useful for? […]
Show full quote

The Solutor wrote on 2026-09-23, 13:44:

They took a shortcut, they could have enforced PAE test on the WHQL certification, but they preferred to throw the baby out with the bathwater, pushing the x64 thing that was (and mostly still is) detrimental rather than an improvement for most users.

That is, not the dirtiest MS move ever, but still dirty enough.

Which users is x64 more detrimental than useful for?

X64 is way better for anything that uses values higher than the 32-bit limit in math type functions.

It is better for gaming. It is better for CAD. It is better for precision.

Sure you can use large number libraries with 32-bit only, but that adds a slowdown compared to native x64.

Also, hopefully soon there will be a way to run native x64 code in DOS (part of one of my side-projects)

Is there a native X64 Version of DOS? or is it more complex than that ?

Trashbytes wrote on 2026-09-24, 02:18:

cyclone3d wrote on 2026-09-24, 02:15:

Which users is x64 more detrimental than useful for? […]
Show full quote

The Solutor wrote on 2026-09-23, 13:44:

They took a shortcut, they could have enforced PAE test on the WHQL certification, but they preferred to throw the baby out with the bathwater, pushing the x64 thing that was (and mostly still is) detrimental rather than an improvement for most users.

That is, not the dirtiest MS move ever, but still dirty enough.

Which users is x64 more detrimental than useful for?

X64 is way better for anything that uses values higher than the 32-bit limit in math type functions.

It is better for gaming. It is better for CAD. It is better for precision.

Sure you can use large number libraries with 32-bit only, but that adds a slowdown compared to native x64.

Also, hopefully soon there will be a way to run native x64 code in DOS (part of one of my side-projects)

Is there a native X64 Version of DOS? or is it more complex than that ?

In a way, it is simpler than having to worry about a kernel supporting 8-bit - x64.

When I have more time to mess with it and test it and get some code actually working with it, it will be revealed.

cyclone3d wrote on 2026-09-24, 02:20:

Trashbytes wrote on 2026-09-24, 02:18:

cyclone3d wrote on 2026-09-24, 02:15:

Which users is x64 more detrimental than useful for? […]
Show full quote

Which users is x64 more detrimental than useful for?

X64 is way better for anything that uses values higher than the 32-bit limit in math type functions.

It is better for gaming. It is better for CAD. It is better for precision.

Sure you can use large number libraries with 32-bit only, but that adds a slowdown compared to native x64.

Also, hopefully soon there will be a way to run native x64 code in DOS (part of one of my side-projects)

Is there a native X64 Version of DOS? or is it more complex than that ?

In a way, it is simpler than having to worry about a kernel supporting 8-bit - x64.

When I have more time to mess with it and test it and get some code actually working with it, it will be revealed.

likely far more simple than trying to program in X64 assembly ...having looked at it, it looks like a nightmare.

cyclone3d wrote on 2026-09-24, 02:15:

Which users is x64 more detrimental than useful for?

Speed on "normal" tasks, storage used (as I already explained not important just on old HW, but also on VDI infrastructure), 16 bit compatibility, direct official upgrade path from older windows, and so on.

It is better for gaming. It is better for CAD. It is better for precision

As I wrote there are niches where x64 matters, even shines. But are niches.

As for gaming, generally not true, but even when it is, it's just because on relatively recent games, x86 received less love from the coders than x64.

A consequence of the forced migration, not one of the causes.

The Solutor wrote on 2026-09-24, 02:23:

cyclone3d wrote on 2026-09-24, 02:15:

Which users is x64 more detrimental than useful for?

Speed on "normal" tasks, storage used (as I already explained not important just on old HW, but also on VDI infrastructure), 16 bit compatibility, direct official upgrade path from older windows, and so on.

If you are still running a 32-bit OS on some random piece of hardware and want to upgrade to x64, then you are around 15 years behind the curve.

I moved everything over to x64 soon after I started my previous job around 15 years ago.

The IT people claimed that it would be too difficult and I had the whole office, including servers moved to x64 within a couple of months.

The biggest "hurdle" was having to replace the drivers on the print server with x64 versions... oh noes.

Some users were also using Excel for some of their data plotting and moving to 64-bit Office made those calculations way faster.

Then we had huge datasets and I had them purchase a piece of software that was meant for that and it brought down plotting of those huge datasets from days to minutes.

I was ready for x64 way before it went mainstream. Moved to Windows XP x64 as soon as I could.

I've never once felt that 32-bit was better in any way compared to x64.

cyclone3d wrote on 2026-09-24, 02:34:

If you are still running a 32-bit OS on some random piece of hardware and want to upgrade to x64, then you are around 15 years behind the curve.

I moved everything over to x64 soon after I started my previous job around 15 years ago.

Listen, when I was young and stupid, I was a very early x64 adopter, I assembled a x64 machine well before x64 Linux was mature, let alone XP64 and 2003 x64, which at the time were practically in alpha status, with an huge string of broken things , with no working themes and alike.

I used to be (almost) a x64 fanboy, and I published a bunch of drivers meant to help other x64 users to make useable their machines usable.

So no I'm not a retrograde "by design", I made my first data connection via cellular network, in 1991, when there was no digital network, no GSM, no SIM no WEB. And when most Americans (Steve Jobs included) had yet see a cellphone even on a SF movie. So no, not a blind lover of the past.

But yes, I'm someone that has pretty clear the difference between innovation and progress, I look for the latter, current generations look for the former.

Sometimes progress and innovation comes together, more often than not they are different things.

Now x64 is more an excuse to keep the capitalism's wheel spinning than something that makes the life of the users better.

How stupid can be to die for notepad++ or outlook in x64 variant, like most kids do today?

How stupid can be to waste 60% of storage, RAM, electricity, just because a single x64 codec is a bit faster than his x86 cousin?

I think that boils down to programmers not knowing how to or caring to have well optimized code and much less to do with 32-bit vs x64.

cyclone3d wrote on 2026-09-24, 03:13:

I think that boils down to programmers not knowing how to or caring to have well optimized code and much less to do with 32-bit vs x64.

One might blame poor optimisation on the glut of cheap fast large capacity memory, if you have an excess of one thing then the drive to reduce its use becomes ...tertiary to everything else. With memory now having become a reduced stupidly priced commodity due to AI we are finding out which developers still have the drive and knowhow to reduce their memory usage and which publishers will allow them to do so.

cyclone3d wrote on 2026-09-24, 03:13:

I think that boils down to programmers not knowing how to or caring to have well optimized code and much less to do with 32-bit vs x64.

That may work in Linux and Apple things, where nobody gives a crap with compatibility with the past, but windows has to have all 32bit libraries and executables installed (or would stop to be windows), more or less the same is applicable to x86 CPUs, which means larger x64 programs, larger ISOs, larger memory transfers, perceivably slower loading times, especially on slower storage lager backups, vhds and so on.

Then, sure x64 sometimes is the only choice. I'm typing from a x64 machine right now. But that is due AMD stopped to publish VGA drivers very early, MS didn't bother to share a 32 bit WSL version or deduplication, VMware removed the x86 support in v12 (albeit the program itself was x86 until the current year) and so on.

Artificial reasons that nothing have to do with the x64 superiority, which I repeat is a real thing in corner cases.

Trashbytes wrote on 2026-09-23, 23:28:

I use explorer patcher myself, I used to use Startallback but they had a period where their updates would keep breaking things so I switched.

Break things in what way?

You seem to be talking about something you don't like rather than something that is broken, but I'm not sure which is why I asked.

The Solutor wrote on 2026-09-24, 03:30:

That may work in Linux and Apple things, where nobody gives a crap with compatibility with the past, but windows has to have al […]
Show full quote

cyclone3d wrote on 2026-09-24, 03:13:

I think that boils down to programmers not knowing how to or caring to have well optimized code and much less to do with 32-bit vs x64.

That may work in Linux and Apple things, where nobody gives a crap with compatibility with the past, but windows has to have all 32bit libraries and executables installed (or would stop to be windows), more or less the same is applicable to x86 CPUs, which means larger x64 programs, larger ISOs, larger memory transfers, perceivably slower loading times, especially on slower storage lager backups, vhds and so on.

Then, sure x64 sometimes is the only choice. I'm typing from a x64 machine right now. But that is due AMD stopped to publish VGA drivers very early, MS didn't bother to share a 32 bit WSL version or deduplication, VMware removed the x86 support in v12 (albeit the program itself was x86 until the current year) and so on.

Artificial reasons that nothing have to do with the x64 superiority, which I repeat is a real thing in corner cases.

Yeah, Windows will be a larger install because of the 32-bit libraries... But programs don't have to use them.

Windows also doesn't have to load them until a program calls for them to be loaded.

And just because you are writing an x64 program doesn't mean you have to make everything use 64-bit values. Doing so would be extremely stupid. You only use 64-bit values when needed.

And if you needed those 64-bit values and were only able to compile for 32-bit, that would require a large number library which would make the program larger and slower.

Trashbytes wrote on 2026-09-23, 23:28:

I use explorer patcher myself, I used to use Startallback but they had a period where their updates would keep breaking things so I switched.

I can't say, I use mostly Win11 / and Server "2024" build 25398.x (which doesn't exist "in nature") I built them myself, and updates from WU tend to break them (obviusly).

Build 25398 is the last that runs on old CPUs like Athlon 64s, core2 duo, P4, Turions and alike. Since 26xxx W11 / 2025 are compiled in a way that makes impossible to run on those old CPU, not the usual lame way that MS use to prevent W11 to be installed on "old" systems, which can be workarounded in a number of ways (the easiest of which, is deploying the system rather than using the, old school, setup.exe)

In short one more reason to keep WU disabled.

That said usually thily (the author of startisback, oldnewexplorer, explorer7 and alike), in my experience was usually quick to keep up with the breakages coming from MS' "wise".

ElectroSoldier wrote on 2026-09-24, 03:44:

Trashbytes wrote on 2026-09-23, 23:28:

I use explorer patcher myself, I used to use Startallback but they had a period where their updates would keep breaking things so I switched.

Break things in what way?

You seem to be talking about something you don't like rather than something that is broken, but I'm not sure which is why I asked.

I bought and used Startallback for a good number of years, but there was about 6 months in early Win11 where MS would update then Startallback would update shortly after and break explorer and the start menu, this could only be fixed by uninstalling Startallback and reinstalling it from a fresh download, eventually I just got sick of it and switched to Explorer Patcher which so far has not had one single issue.

I don't hate Startallback, its odd you would jump to that conclusion, its more that I find Explorer Patcher to be better for my use case and find it to be far easier to unfuck when MS eventually fucks things up.

If Microslop would just leave the damn explorer and start menu alone things would be perfect but they seem to have this obsession with changing the damn thing all the time, its truly irritating that I even need a program to return it to the Win10 start menu and explorer.

cyclone3d wrote on 2026-09-24, 04:09:

Yeah, Windows will be a larger install because of the 32-bit libraries... But programs don't have to use them. […]
Show full quote

The Solutor wrote on 2026-09-24, 03:30:

That may work in Linux and Apple things, where nobody gives a crap with compatibility with the past, but windows has to have al […]
Show full quote

cyclone3d wrote on 2026-09-24, 03:13:

I think that boils down to programmers not knowing how to or caring to have well optimized code and much less to do with 32-bit vs x64.

That may work in Linux and Apple things, where nobody gives a crap with compatibility with the past, but windows has to have all 32bit libraries and executables installed (or would stop to be windows), more or less the same is applicable to x86 CPUs, which means larger x64 programs, larger ISOs, larger memory transfers, perceivably slower loading times, especially on slower storage lager backups, vhds and so on.

Then, sure x64 sometimes is the only choice. I'm typing from a x64 machine right now. But that is due AMD stopped to publish VGA drivers very early, MS didn't bother to share a 32 bit WSL version or deduplication, VMware removed the x86 support in v12 (albeit the program itself was x86 until the current year) and so on.

Artificial reasons that nothing have to do with the x64 superiority, which I repeat is a real thing in corner cases.

Yeah, Windows will be a larger install because of the 32-bit libraries... But programs don't have to use them.

Windows also doesn't have to load them until a program calls for them to be loaded.

And just because you are writing an x64 program doesn't mean you have to make everything use 64-bit values. Doing so would be extremely stupid. You only use 64-bit values when needed.

And if you needed those 64-bit values and were only able to compile for 32-bit, that would require a large number library which would make the program larger and slower.

It's about theory v.s. real world. In win server you can remove the x86 libraries, (you gain almost no storage, given most of the windows installation is made by hard links to the component store, which is what takes most of the space), and tell me how much you can keep that configuration, even with no 3rd party SW involved.

Anyway 32 bit libraries or not, everything is larger in x64 form, maybe not by the usual 1.6x factor, but still larger

Say shell32.dll 21.856KB v.s. 19332KB and here the large part are resources, icons and alike rather than code

amdocl64.dll 66.891 v.s. amdocl 55.195KB

And so on, check by yourself.

Trashbytes wrote on 2026-09-24, 04:22:

its odd you would jump to that conclusion

No conclusion at all 😉 just shared my experience.

If Microslop would just leave the damn explorer and start menu alone things would be perfect but they seem to have this obsession with changing the damn thing all the time, its truly irritating that I even need a program to return it to the Win10 start menu and explorer.

Yeah, the win95 gui was so brilliant that had really little room to be perfected. Surely the cross breading between KDE 1/2/3 and XP/7 brought some worth refinements, but after that most supposed GUI improvement proved to be a downgrade in UX, sadly not just a MS thing.

KDE is the shadow of himself (thanks god TDE is still a thing) gnome became an idiotic copy of masOC, which itself is the shadow of himself.

As idiotic as masOC is Snow Leopard was hugely better than any recent release

The Solutor wrote on 2026-09-24, 04:42:

No conclusion at all ;) just shared my experience. […]
Show full quote

Trashbytes wrote on 2026-09-24, 04:22:

its odd you would jump to that conclusion

No conclusion at all 😉 just shared my experience.

If Microslop would just leave the damn explorer and start menu alone things would be perfect but they seem to have this obsession with changing the damn thing all the time, its truly irritating that I even need a program to return it to the Win10 start menu and explorer.

Yeah, the win95 gui was so brilliant that had really little room to be perfected. Surely the cross breading between KDE 1/2/3 and XP/7 brought some worth refinements, but after that most supposed GUI improvement proved to be a downgrade in UX, sadly not just a MS thing.

KDE is the shadow of himself (thanks god TDE is still a thing) gnome became an idiotic copy of masOC, which itself is the shadow of himself.

As idiotic as masOC is Snow Leopard was hugely better than any recent release

I liked the Win7 Start Menu and Explorer quite a lot, same for the Win10 version.

Trashbytes wrote on 2026-09-24, 04:55:

I liked the Win7 Start Menu and Explorer quite a lot,

Yes especially the (apparently) identical one from classic shell, which adds a ton of cusomizability

same for the Win10 version.

Absolutely hideous, just unusable with the mouse.

The only way to do something quickly is to type in the searchbox, but if I had to type to do things I would stay with a 1997 Linux distro.

What I use since it was released is classic shell with the midnight theme. It doesn't look baroque like Vista/7's menus, while not being useless like W8/10/11 ones.