Live data from Hacker News

Windows 11 will happily execute a binary compiled 30 years ago

twitter.com

241–250 of 424 posts

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

#241
post #102
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…

Sadly a consequence of how NTFS plugin architecture works. Using Windows 11 the answer is ReFS.

Do you still have to pay for a Workstation license to get that on your local machine?

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

#242

Earlier quoted context omitted.

Your evidence is an article from 24 years ago about behavior that happened 32 year ago? And it's not even about them breaking competitors applications, it's about them refusing to run on a competing OS (in a bit of a sleezy way). Do you have more evidence of your claimed behavior? I dislike MSFT, a lot, but that's a _very_ big claim and needs to be backed up with evidence.

My claim is that Microsoft operating system was silently detecting competitors software and changing behavior to break compatibility. That is proven. The war on WordPerfect was equally shady. Did Microsoft clean its act at some point and stopped doing so? They force Edge at every opportunity, so even the behavior that almost got them forcefully partitioned is back. I don’t think we have caught them outright sabotagin…

> My claim is that Microsoft operating system was silently detecting competitors software and changing behavior to break compatibility. That is proven

That's a false claim. That code was in a beta and never shipped. You're just spreading FUD..

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

#243
post #221

Earlier quoted context omitted.

This is mostly caused by the anti-malware scanning. Exclude your sources folder from real-time scanning.

Windows 11 is soon getting a new feature called Dev Drive, which uses an entirely different FS (ReFS) and reduced malware scanning, specifically designed for source code.

90% of the speed up is from not scanning the files. ReFS isn’t much faster than NTFS.

The “drive” part of dev drive is a clever hack to bypass corporate anti malware policy settings.

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

#244
post #148
post #120

Someone’s gonna come and say that linux has that too, and while technically true it’s quite hard in practice. The kernel abi is stable, everything else is pure chaos, and this is mostly due to how applications are usually packaged in linux: your app could load (as long as it’s not in a.out format) but then would fail at loading most libraries. So effectively you need a whole chroot with the reference linux distro (or…

It works in Linux the same way it works on Windows: If you don't have the dynamic libraries and configuration you need, it won't work. Why this is a mark against Linux and not Windows is beyond me.

Microsoft keeps maintaining all those libraries, and keeps them in the OS by default. That may not be the case with Linux.

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

#245

Earlier quoted context omitted.

You're sitting on the point of view of a software developer. Microsoft's point of view is that the underlying software doesn't matter. The user's software _has_ to run. The Application Compatibility Database ( https://learn.microsoft.com/en-us/windows/win32/devnotes/app... ) is, overall, a relatively small component, and all it does is apply some shims if your executable is in that list. Performance issues in Windows…

> Performance issues in Windows do not stem from anywhere near the kernel. I remember Windows uses a O(N^2) scheduler so the system slows down when it has a few thousand processes. Would that count as a performance issue in the kernel?

As far as I know, Windows uses a multilevel feedback queue, so O(n²) would be surprising. The one issue that pops up with the Windows scheduler is when you have plenty of processes doing tiny little bits of IO instead of one huge slab of it.

Could you count it as a performance issue in the kernel ? Maybe. But really, you're mostly hitting an issue in what it's built to do. Windows really likes two things:

* don't spawn subprocesses

* please do your I/O in one huge batch and thank you.

The average Windows machine will barely have 100 processes running. I have 184 right now, and I run a lot of crap. This goes directly contrary to the philosophy of many UNIX programs: create a shitload of processes, fork everywhere, and write tiny files all the time.

I wouldn't complain about a hammer not working well if I'm using the handle to nail things. Sure, it would be nice if it also worked there, but it's not exactly made for that either, and for good reason. POSIX fork() being such a can of worms is half the reason that WSL1 was abandoned. Windows does not have the internal machinery to do that, because it wasn't built for that.

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

#246
post #19

A fun side-effect of the "general" stability of Windows APIs is that Win32/DX has become a very stable and reliable "universal" API for Linux (and other OSes) via the massive amount of work put into Wine/Proton. I keep seeing games drop their Linux-native releases in favor of just shipping for proton.

Yes. Someone blogged about this last year and it generated a lot of discussion here as well.

https://sporks.space/2022/02/27/win32-is-the-stable-linux-us...

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

#247
post #221

Earlier quoted context omitted.

Windows 11 is soon getting a new feature called Dev Drive, which uses an entirely different FS (ReFS) and reduced malware scanning, specifically designed for source code.

90% of the speed up is from not scanning the files. ReFS isn’t much faster than NTFS. The “drive” part of dev drive is a clever hack to bypass corporate anti malware policy settings.

It's not "not scanning" completely, it has less aggressive scanning by default. You can turn it off fully if you want, but then, you can do that with folder based exclusions on NTFS folders too.

So, I'm not sure the perf increase can just be attributed to malware scanning. ReFS has some features that NTFS doesn't have like copy-on-write which might help in read-only I/O perf.

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

#249

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…

From where I'm sitting this looks like an excellent argument for breaking backwards compatibility. All those bullshit hacks are a maintenance and debugging burden for someone and a tax on the whole rest of the operating system -- and I'd argue that it really shows.

The issue is at that time updates for most shrink wrapped software were almost non existent and distribution even worse. Windows had an update facility and I bet you sim city for dos did not. So, either windows yielded and patched it’s behavior to run sim city or sim city users couldn’t run it under windows full stop until maxis distributed a new distribution on media.

In todays world it looks like a ludicrous solution to the problem. The game vendor needs to HTFU and distribute a patch via steam or whatever and that’s a totally reasonable stance for microsoft or apple to take, because the infrastructure for patch distribution is pervasive and robust now.

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

#250

Earlier quoted context omitted.

It's a bit surprising that there isn't a project that takes the old Windows "shell replacement" (LiteStep, etc) idea a bit further and replaces the majority of the Windows userland. That's probably more challenging now than it was in the XP-Vista-7 days but should still be doable.

An "alternative OS" built on top of the NT kernel would certainly be interesting. It would take a decade to a thousand-person team, but it would be interesting

> It would take a decade to a thousand-person team

By the standard conversion rate, I think that means 4 people could knock it out in 6 weeks.

Post reply on HN