Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows 11 will happily execute a binary compiled 30 years ago

twitter.com

Post reply on HN
Print view View original

391–400 of 424 posts

Re: Windows 11 will happily execute a binary compiled 30 years ago

#391

Post by WorldMaker »

godshatter wrote: post #187
WorldMaker wrote: post #109

Earlier quoted context omitted.

Filesystems are a database and have to deal with CAP Theorem trade-offs like everything else. Windows and NTFS both took a heavy focus on Consistency/(lack of) Partitions over Availability. Most POSIX operating systems and their filesystems took a heavy focus on Availability at the expense of Eventual Consistency and Sometimes Partitions. Neither approach is wrong, they are just very different approaches with very di…

I remember hearing that allocating space on NTFS on Windows takes a long time for a large amount of files and/or disk space compared to ext4 and the like on linux. Presumably they are built to write out 0's or something when they do that whereas in linux you're just updating inodes or whatever. I remember this was in reference to Steam allocating file system space for game files before downloading them. I don't know…

That's my understanding: Windows doesn't want the security problems of people allocating disk space and trying to read back garbage deleted files left behind by other programs in the hopes of finding user secrets, so if you explicitly ask it to allocate a file of a certain size, it (slowly) fills it with 0s first.

But also, Steam's allocation step seems an interesting relic of Windows 9X design patterns, smaller hard drives, worse cache/temp folder options, and (much) slower download speeds. It probably isn't necessary and they could maybe design something simpler and better from scratch today. (But it's probably a "not broke don't fix it" thing at this point.)

Re: Windows 11 will happily execute a binary compiled 30 years ago

#392

Post by nani8ot »

matheusmoreira wrote: post #385
psychphysic wrote: post #204

Earlier quoted context omitted.

Drivers being kernel specific is really annoying

All they have to do is upstream their drivers into the kernel instead of shipping proprietary blobs. Why is this so hard?

Because the Linux kernel has stringent guidelines how a driver should be written and work. Companies don't want to put in the work (i.e. pay someone with experience) to upstream their drivers. Whether this makes sense monetarily isn't really relevant to many decision makers. At least that's how I explain why Nvidia and Broadcom don't upstream their drivers.

Re: Windows 11 will happily execute a binary compiled 30 years ago

#393

Post by darklycan51 »

Dalewyn wrote: post #323
darklycan51 wrote: post #295

Earlier quoted context omitted.

Might be the case now (Note, I'm talking about Nightly), this was a few years back, I noticed that first it warned that a new version was working and then mysteriously bricked the browser after, complained and they told me that I "shouldn't be using nightly if I don't wanna have the latest updates"... which I do, but I don't wanna be forced into a restart unless it actually breaks?

Firefox Nightly is a branch specifically for testing and evaluating the newest updates. If you want reliability and consistency out of Nightly, the problem is you. You will get what you want out of the regular branch, and even more out of the Extended Support Release branch. As for Windows rebooting out of nowhere: Get a Professional or Enterprise license and turn autoupdates off via Group Policy and your problems ar…

And this is exactly the comment I was talking about.

Anyways for any sensible people, yes, Nightly is a branch specifically for testing and evaluating, doesn't mean you have to brick peoples browsers after some time when you push an update (again, back when I used it that was the behavior, according to a different comment it might be different now), to force a restart.

"As for Windows rebooting out of nowhere: Get a Professional or Enterprise license and turn autoupdates off via Group Policy and your problems are solved.", yes, I already addressed this and mentioned this solution, but again, that doesn't change the fact that it's wrong in the first place, maybe actually read the comment you are replying to?

Re: Windows 11 will happily execute a binary compiled 30 years ago

#394

Post by saagarjha »

FirmwareBurner wrote: post #373
saagarjha wrote: post #255

Earlier quoted context omitted.

My dude I literally quoted what you said, at least before you edited your comment to remove it.

>My dude I literally quoted what you said You quoted what I said then turned it into this strawman for a snarky jab: "Surely you aren't making the argument that Microsoft is generous enough to let you remove their bloatware?" >at least before you edited your comment to remove it. I removed more points because the comment was getting huge.

You posted a comment that seems to have a thesis of “Windows isn’t actually as bad as you think it is”. Is that correct? If not, what were you trying to convey? If you had posted your statement in isolation or in a different context it might have a different meaning but I’m not seeing many interpretations here besides “yeah it’s actually super easy to remove this junk so it’s not a big deal”. The question is why it’s there in the first place?

Re: Windows 11 will happily execute a binary compiled 30 years ago

#396

Post by ankurdhama »

bombcar wrote: post #256
armchairhacker wrote: post #166

Does Linux have this backwards compatibility? What about macOS? I know instruction sets changed from PowerPC to Intel to ARM, so probably not macOS at least. But this is a CLI and I doubt old system calls changed

MacOS is actively hostile ( I still remember when they dropped cocoa or carbon or whatever it was, many apps died that day ). Linux isn’t hostile and if you ONLY use the kernel ABI or statically compile everything, it will work quite a long time. But if you use dynamic libraries, you gonna have a hard time unless you have source.

> MacOS is actively hostile ( I still remember when they dropped cocoa or carbon or whatever it was, many apps died that day ).

These changes are not like they announce something and the next day the libraries/APIs are gone. There is always a transition period that is long enough for the apps to be updated.

Re: Windows 11 will happily execute a binary compiled 30 years ago

#397

Post by 59nadir »

memefrog wrote: post #268
eternityforest wrote: post #111

Earlier quoted context omitted.

Try running something from only ONE year ago on Linux and it very often won't work, unless it's an Appimage or Flatpak, or you're on Nix, They might not break userland but Qt and GTK do the breaking for you. Python joined the party recently. Random DBus daemons might be missing, etc.

You can run binaries from decades ago on Linux too. This is about a DOS binary. Well, a command line program that just uses system calls is fine too.

Linux is absolutely terrible with this, it sits on the "extremely unlikely" end whereas Windows sits on the other in terms of backwards compatibility. It's not surprising either because the entire ecosystem runs on the myth that shared libraries are desirable when any serious look into them shows that almost no space is saved, almost none of them are actually shared by a meaningful amount of apps, almost no actual security issues are avoided by using them.

Anyone who has ever been interested in having someone else be able to run their program has figured out a long time ago that you have to ship your dependencies for them to be able to do so.

Re: Windows 11 will happily execute a binary compiled 30 years ago

#398

Post by Etherlord87 »

tinus_hn wrote: post #355
Dah00n wrote: post #328

Earlier quoted context omitted.

Is the lack of an app a good thing?

It can be because it’s an incentive to create a new, up-to-date app.

This is basically the defense of bad deeds: bad deeds inspire others to do good deeds.

Re: Windows 11 will happily execute a binary compiled 30 years ago

#399

Post by Etherlord87 »

darklycan51 wrote: post #188
ClumsyPilot wrote: post #158

Earlier quoted context omitted.

> All those bullshit hacks are a maintenance and debugging burden for someone That’s why that someone is getting paid -it’s their job. If you want software to power important things in society, like transport and energy, you need to have a certain level of responsibility for reliability. As this post demonstrates, Right now we have immature children who are used to breaking things for the sake of a new fad, in charge…

This really bothers me and I'm young, I am TIRED of applications FORCING restarts, and other garbage as a software culture. You are doing something? Oh sorry our developer team thought it would be smart to crash your whatever task you are doing by force to give you a 2 line changelog. Typing a dm on discord or talking to people? boom random restart to force update, using firefox nightly? sorry you cannot use it as yo…

Restarting exists, because it's the simplest way to maintain a program. Do you expect a car mechanic to repair your car while you're still driving? It could be possible, but it would cost so much more, that no one even thinks to do it.

Discord is a great example, because it's very far from being optimal in so many regards. It could be written in C++ and be so much faster, use so much less memory, it could be more reliable in many aspects… But because most people don't care, what Discord creators do is roughly the most meta-efficient (money efficient?) thing to do.

Re: Windows 11 will happily execute a binary compiled 30 years ago

#400

Post by anthk »

Too wrote: post #382
stjohnswarts wrote: post #363

Earlier quoted context omitted.

30 yo source code?

Better bring a 30y old compiler too. The amount of UB that was assumed to work in code from that era will turn into bugs due to more liberal optimizations or fail with compiler warnings thanks to stricter checking.

There's always a flag to override that, usually the compiler will warn you on how to fix it.
Post reply on HN