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

101–110 of 424 posts

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

#101

Post by roneythomas6 »

nelsondev wrote: post #88
veec_cas_tant wrote: post #81

Earlier quoted context omitted.

Sure. Apple is also giant and (probably?) fits those descriptors as well. Why is Mac so solid under similar circumstances?

Apple employs “Release Managers”, where a single person is ultimately responsible for deciding which features ship in new projects. Apple also, due to the hardware business, adheres to a release schedule where features must all be consolidated onto single branches (“convergence”), rather than letting individual teams ship incrementally.

Not to mention Apple only has to support a limited number of hardware and they regularly drop support for older hardware with each new major release.

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

#102

Post by pjmlp »

e40 wrote: post #76
jmkni wrote: post #63

What I find so frustrating is that Windows, under the hood, is so solid. It's just the UI with Bing/Ads/telemetrics/etc integration is so crap, like they've ruined a solid OS with crappy surface level stuff.

Really? Filesystem performance on Windows is absolutely horrible compared to Linux. It blows me away how, even using SSDs, the performance of git over large repos is at least 10x slower than a Linux box with the same CPU. It is the bane of my existence. It's not just git. rsync of a large directory takes >10x as long. This is with Server 2016 (and 2012 r2). My 2012 r2 machine had spinning disks and when I tested on 2…

Sadly a consequence of how NTFS plugin architecture works.

Using Windows 11 the answer is ReFS.

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

#103

Post by amlib »

adzm wrote: post #79
e40 wrote: post #76

Earlier quoted context omitted.

Really? Filesystem performance on Windows is absolutely horrible compared to Linux. It blows me away how, even using SSDs, the performance of git over large repos is at least 10x slower than a Linux box with the same CPU. It is the bane of my existence. It's not just git. rsync of a large directory takes >10x as long. This is with Server 2016 (and 2012 r2). My 2012 r2 machine had spinning disks and when I tested on 2…

This is true. I'm not sure what the obstacle is, and I know a lot of smart people have worked on it, but opening a ton of files and traversing a bunch of them in directories is very slow. Once the file is open, IO is just as fast though.

Unless you have antivirus software and god knows what analyzing the files, then IO is actually slower...

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

#104

Post by housemusicfan »

paxys wrote: post #51

I'm going to go ahead and say operating systems that don't work this way are the exception. Running a 30 year old binary isn't all that big a deal. Pretty much every mainstream system does so every day in its day to day operation.

macOS won't let me run binaries from 5 years ago, let alone 30.

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

#105

Post by martinald »

adzm wrote: post #79
e40 wrote: post #76

Earlier quoted context omitted.

Really? Filesystem performance on Windows is absolutely horrible compared to Linux. It blows me away how, even using SSDs, the performance of git over large repos is at least 10x slower than a Linux box with the same CPU. It is the bane of my existence. It's not just git. rsync of a large directory takes >10x as long. This is with Server 2016 (and 2012 r2). My 2012 r2 machine had spinning disks and when I tested on 2…

This is true. I'm not sure what the obstacle is, and I know a lot of smart people have worked on it, but opening a ton of files and traversing a bunch of them in directories is very slow. Once the file is open, IO is just as fast though.

My guess is ACLs, which are enabled by default on NTFS but not (afiak) on most linux distros using ext4.

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

#106

Post by pjmlp »

Sohcahtoa82 wrote: post #80
baal80spam wrote: post #7

And that's why Microsoft will dominate corporate PC market for the foreseeable future.

I dunno, based on my anecdata of my last two jobs, Mac is starting to take over. Shit, at my current job, we're developing software that runs solely on x86-64 Linux (And our output is an entire VM image, not just an executable), yet we're running on M1 Macs. TBH, it's quite painful and I wish I understood what the hell the engineering department is thinking, since you can't run x86-64 VMs on M1 hardware. But for game…

I bet you're located on North America.

Across the rest of the world macOS numbers aren't that high, still better than "Desktop Linux" though.

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

#107

Post by fredoralive »

doublepg23 wrote: post #77
no_time wrote: post #57

So much so that even only linux, the most stable API arguably is win32 through wine. Atleast for desktop related tasks.

Are the compatibility issues on Linux really an API issue or having incompatible, newer versions of libraries? The effect is the same, your old program doesn’t run, but the cause is very different.

Incompatible, newer versions of libraries is an API issue? An OS is more than a kernel, and on Windows if you link to the standard set of libraries provided with the Windows, Microsoft tries not to break them.

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

#108

Post by failuser »

knallfrosch wrote: post #20

See also https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Win…

Counter-example: Soldier of Fortune is broken on modern windows because of a misapplied compatibility hack. Rename the binary and it works with no problems.

This is an awful way to implement backwards compatibility. Opaque and ad-hoc. They have been using similar toolset to break competitors applications.

The choice of what old version of windows to run the program on is typically to try them one by one.

Linux is no better with no stable ABI. Mac is a mixed bag of excellent Rosetta and breaking apps for no reason. Who did it better? FreeBSD? Some extinct “grown-up” OS like VMS?

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

#109

Post by WorldMaker »

adzm wrote: post #79
e40 wrote: post #76

Earlier quoted context omitted.

Really? Filesystem performance on Windows is absolutely horrible compared to Linux. It blows me away how, even using SSDs, the performance of git over large repos is at least 10x slower than a Linux box with the same CPU. It is the bane of my existence. It's not just git. rsync of a large directory takes >10x as long. This is with Server 2016 (and 2012 r2). My 2012 r2 machine had spinning disks and when I tested on 2…

This is true. I'm not sure what the obstacle is, and I know a lot of smart people have worked on it, but opening a ton of files and traversing a bunch of them in directories is very slow. Once the file is open, IO is just as fast though.

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 different performance trade-offs.

Also Windows' filesystem supports an entire plugin stack including user-space plugins, to support things like anti-virus scanners and virtual filesystems and all sorts of other things. Not all of Windows' "slow" filesystem is first-party problems, a lot of it can be third-party drivers and tools that are installed.

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

#110

Post by pjmlp »

blibble wrote: post #12

yes it can run things that don't use much of the API surface (just using libc? probably fine) however try running a game from the Windows 95/98 days and you've got a maybe 50/50 chance of it working e.g. they changed the return code from BitBlt from 95/98 -> XP, they used to return the number of scanlines but switched it to a boolean same with the heap management functions, directory traversal functions, etc

Those issues only apply to Windows 9x linage.

Current Windows versions trace back to Windows NT 3.51/2000 linage.

Naturally 9X => XP don't work flawlessly, they are two different OS stacks.

Post reply on HN