Microsoft says Windows 7 isn't fit for modern hardware and security

[directhex]

I'm an engineer at Microsoft, do I get to invoke "argument to authority" and declare whatever I say is right?

[HavoCnMe]

The one thing that made me hate Wa-Wa-Windows 10 was it could see my GTX 1070 in windows update and download the driver but would fail to install. So then I went and downloaded the driver from Nvidia and Windows 10 wouldn't detect the card when trying to install the driver. So I had to go and get the stupid Windows Creation Tool and force it to update the driver. Talk about a royal pain in the ass. Windows 7 and 8.1 had no issues installing a simple video card driver either through windows update or manually from Nvidia. Windows 10 failed at such an easy task.

[Corky34]

That's exactly what's been done with a bunch of Kernel APIs, it's a new version. You are complaining about the exact thing they are doing.

Just because it's a new version doesn't mean the fundamental design flaws have been fixed, it just means they've added, changed, removed, or whatever enough of an existing design to warrant a new number being stuck on the end, and they (not just Microsoft afaik) have been doing that for over 23 years.

As for DLL Hell. Oh boy did they solve it, by arguably making worse! Side by Side... DLL Hell isn't a design flaw, it's a feature. That's the horrible thing about the problem, how many times has it been (badly) solved? Look at NPM 2 vs 3, look at dpkg. Heck look at NuGet graph theory makes for fun times with a filesystem.

I guess my idea of solve is different than yours, what you see as solved i see as workarounds, sticking plasters, kluges, call it what you will but to me something is solved when it no longer causes excessive problems that require constant fixing, if it keeps causing problems that need fixing it should be replace for a more reliable solution, that we (in the collective sense) aren't forced to work around problem.

[TheAnimus]

Just because it's a new version doesn't mean the fundamental design flaws have been fixed, it just means they've added, changed, removed, or whatever enough of an existing design to warrant a new number being stuck on the end, and they (not just Microsoft afaik) have been doing that for over 23 years.

What is enough then?

A series of features that create incompatibility normally is my rough rule of thumb. They've done that.

I guess my idea of solve is different than yours, what you see as solved i see as workarounds, sticking plasters, kluges, call it what you will but to me something is solved when it no longer causes excessive problems that require constant fixing, if it keeps causing problems that need fixing it should be replace for a more reliable solution, that we (in the collective sense) aren't forced to work around problem.

What pray is the solution?

In Java I still have dependency problems. In .Net I still have them. In C++ I still have them. In JavaScript I have gigabytes of them thanks NPM. There isn't a solution to such a complex problem short of having compatibility versioning around all public endpoints, which is horrible on a new plane of existence.

I'm an engineer at Microsoft, do I get to invoke "argument to authority" and declare whatever I say is right?

Only if you promise to bring back singularity!

[Corky34]

What is enough then?

A series of features that create incompatibility normally is my rough rule of thumb. They've done that.

I think we're at cross purposes hear, I'm not saying adding, changing, or removing stuff doesn't warrant a version change, I'm saying there comes a time when you're better of starting over, that you (not you personally) maybe better off implementing all the lessons learnt into a new design, that there comes a time when you're better off starting anew instead of trying to add, change, or remove stuff.

What pray is the solution?

Personally, and speaking from a meta-view, something similar to a microkernel would be my choice, yes i know it's been tried and mostly dropped because of performance but IMO it would be better to start with a bare minimum that enables you to build a kernel from separate modules without running the risk that removing or adding something will have unforeseen consequences.

[directhex]

Personally, and speaking from a meta-view, something similar to a microkernel would be my choice, yes i know it's been tried and mostly dropped because of performance but IMO it would be better to start with a bare minimum that enables you to build a kernel from separate modules without running the risk that removing or adding something will have unforeseen consequences.

Kernel level isn't the problem

High level - and more specifically, how to fill in the plumbing - is.

App A needs libfoo version 1, and App B needs libfoo version 2, and they're incompatible. Congratulations, you're in DLL hell. You could bundle an appropriate libfoo with the app, but now you have 87 copies of libfoo on your system, and 13 of them have a critical security vulnerability the app author never included a fix for

[TheAnimus]

Micro Kernel approach is a 'weaker binding' so arguably brings more of the DLL Hell issues anyway!

Not that it's a bad thing to have DLL hell, if it's the opposite of Node then it's probably a good thing automatically.

So when are you bringing back singularity 'hex?

[Corky34]

DLL hell's only an issue because package management's so awful, both the adding and removing, and it's not just the libraries, it's also the adding and removing of features that's awful, if an end user doesn't want or need something they should be able to remove it, right down to the kernel level.

[directhex]

DLL hell's only an issue because package management's so awful, both the adding and removing, and it's not just the libraries, it's also the adding and removing of features that's awful, if an end user doesn't want or need something they should be able to remove it, right down to the kernel level.

Why? That's a bigger (more expensive) support & QA matrix

[directhex]

So when are you bringing back singularity 'hex?

Not my team!

[Corky34]

Why? That's a bigger (more expensive) support & QA matrix

I can't see why, it's not like the company would support or QA every possible scenario, just the default builds would be QA'd as they would contain a selection of each module, if anything it would probably reduce the support and QA because problems could be isolated to a single module.

[DanceswithUnix]

App A needs libfoo version 1, and App B needs libfoo version 2, and they're incompatible. Congratulations, you're in DLL hell. You could bundle an appropriate libfoo with the app, but now you have 87 copies of libfoo on your system, and 13 of them have a critical security vulnerability the app author never included a fix for

If App A needs 1.1 and App B needs version 1.2, then you install the package for version 1.2. Both apps use the same library, so they share the shared library. Version 1.1 has a nasty fault, you don't want that on the system.

If App A need 1.1 and App B uses 2.1, then both get installed because major numbers aren't compatible.

Unix systems have been doing that successfully for decades. But more important than library versioning, you need a proper packaging system which is something that I am stunned Microsoft still don't have. Instead, you get everything shipped with "C++ runtime", Direct X installation and who knows what else and they all get installed in parallel.

[directhex]

If App A needs 1.1 and App B needs version 1.2, then you install the package for version 1.2. Both apps use the same library, so they share the shared library. Version 1.1 has a nasty fault, you don't want that on the system.

If App A need 1.1 and App B uses 2.1, then both get installed because major numbers aren't compatible

Who's doing the regression testing on that? What if app B was actually depending on buggy, undefined behaviour in libfoo 1.1? Which library authors are actually making dependable API/API contracts (the Java and JS worlds show us "none of them")

[Corky34]

Didn't this whole discussion start with aidanjt saying software doesn't magically become invalid with age and TheAnimus saying that philosophy was a problem, now it seems your saying it's not a problem because regression testing needs to be done, I'm not being picky or critical it just seems odd that people are moaning because others ain't updating to the latest and greatest whatever but at the same time saying we have to make sure the latest and greatest works with old stuff.

And if app B was depending on buggy, undefined behaviour in libfoo 1.1 wouldn't that be the fault of whoever didn't fix the bug or who allowed undefined behaviour.

[peterb]

Im not convinced that Microsoft do any regeression testing except for their own products - and why would they? It then falls to the third party software to do the regression testing themselves and either release n update, or let the product (if they are drivers for example) involved become EOL - and start selling new ones.

To try to be fair to Microsoft, they could exercise some QA with third part applications sold through their App Store, making it a condition of listing that it is backwards compatible for x number of releases.

[directhex]

Im not convinced that Microsoft do any regeression testing except for their own products - and why would they? It then falls to the third party software to do the regression testing themselves and either release n update, or let the product (if they are drivers for example) involved become EOL - and start selling new ones.

You'd be surprised. There's an insane amount of per-app checking, to keep old apps running.

XP had this popup for known-incompatible apps:



And they kept working at it, to get a lot of XP-incompatible win95/98 apps running on Vista+!: https://support.microsoft.com/en-us/...-february-2010