Slashdot Mirror

Sounds to me like someone has it in for Alexa.

It's either a hack, or someone wrote this into the code intentionally. Probably before they got fired/laid off/downsized, etc.

If it's truly a hack, I can't wait for it to hit other devices and platforms.

Like, say Cortana, perhaps.

Not that Windows 10 is doing anything creepy, all by itself in the middle of the night.
https://answers.microsoft.com/...
https://www.bleepingcomputer.c...

Oh, wait. Maybe, it's just auto updating, and wiping out your preferences and resetting your privacy settings when you're not looking...
https://answers.microsoft.com/...

That, or maybe the evil little AI is simply laughing in its sleep at what it will do to us next.

I guess we'll all see eventually.

Sounds to me like someone has it in for Alexa.

It's either a hack, or someone wrote this into the code intentionally. Probably before they got fired/laid off/downsized, etc.

If it's truly a hack, I can't wait for it to hit other devices and platforms.

Like, say Cortana, perhaps.

Not that Windows 10 is doing anything creepy, all by itself in the middle of the night.
https://answers.microsoft.com/...
https://www.bleepingcomputer.c...

Oh, wait. Maybe, it's just auto updating, and wiping out your preferences and resetting your privacy settings when you're not looking...
https://answers.microsoft.com/...

That, or maybe the evil little AI is simply laughing in its sleep at what it will do to us next.

I guess we'll all see eventually.

Windows 10 S is a specific configuration of Windows 10 Pro that offers a familiar, productive Windows experience that's streamlined for security and performance. By exclusively using apps in the Microsoft Store and ensuring that you browse safely with Microsoft Edge, Windows 10 S keeps you running fast and secure day in and day out.

For more information, please refer to this page.

Looks like there are a few more differences from Pro, like only being able to join a domain hosted in Azure.

Today: Running Fedora on Windows 10 using WSL

Sometime soon: New distros coming to Bash/WSL via Windows Store

Outdated apps in what sense? They were good enough in 2017, why will they suddenly become not good enough in 2018?

First, you're implying that 2017 was that last time some of these apps were updated. As this report notes, its been happening for years with WP apps. In some cases, apps that haven't been updated in years are the only ones available. Second, for those apps that have been updated recently does not mean that they have the latest and greatest features on par with other versions. Take for example this Twitter for WP comment.

It takes way too long for this app to catch up to Twitter's new features. As of the date of this review (11/13/17), it still does not support 280-character tweets, even though the website and Twitter apps for other platforms have supported the longer tweets for about a week. Also, it's been over a year and a half since Twitter introduced the ability to describe pictures to the visually impaired, yet the Twitter app for Windows still can't do this.

And that's if the app is bug free. As many WP users have noted, popular apps are crashing all the time because the developers barely update them to fix them. For example, Facebook has a great deal of instability and bugginess. And that's a Facebook which can afford decent programmers. It seems to that Facebook doesn't care about WP users or they can't get it right with their billions of dollars. I would guess it's more that WP users aren't enough for them to care.

Outdated apps in what sense? They were good enough in 2017, why will they suddenly become not good enough in 2018?

First, you're implying that 2017 was that last time some of these apps were updated. As this report notes, its been happening for years with WP apps. In some cases, apps that haven't been updated in years are the only ones available. Second, for those apps that have been updated recently does not mean that they have the latest and greatest features on par with other versions. Take for example this Twitter for WP comment.

It takes way too long for this app to catch up to Twitter's new features. As of the date of this review (11/13/17), it still does not support 280-character tweets, even though the website and Twitter apps for other platforms have supported the longer tweets for about a week. Also, it's been over a year and a half since Twitter introduced the ability to describe pictures to the visually impaired, yet the Twitter app for Windows still can't do this.

And that's if the app is bug free. As many WP users have noted, popular apps are crashing all the time because the developers barely update them to fix them. For example, Facebook has a great deal of instability and bugginess. And that's a Facebook which can afford decent programmers. It seems to that Facebook doesn't care about WP users or they can't get it right with their billions of dollars. I would guess it's more that WP users aren't enough for them to care.

tell the difference between a sheep and a letter, yes. So you are saying that all you need is a big neural net with different training set, or multiple sub-NN?

Yeah, if you want an NN to know about something you have to train it. If you want it to know about two different things, you have to give it a training set that spans both. Or you could have some sort of tiered affair. The letter recognition wouldn't see anything while the animal recognition would see a sheep, with something managing both. Generally the broader the training set the longer it takes to figure anything out.

You know this, stop feigning ignorance.

If that is the case, why don't we have one?

We do. Like the article mentions. Microsoft's Azure is an object recognition program. HERE. Just go play with it. Find a picture of a sheep. Load it into the API, hit submit, and one of the tags will, likely, be "sheep".

NN have been around for 40 years. When are we going to have one that can recognize sheep?

Around 2012. At least it was a nice mile-stone. There has been incremental improvements and the hit-rate has been getting progressively better.

What is your explanation?

I'd explain this line of inquiry with: You're a willfully ignorant troll that refuses to admit at the thing that's right in front of his face and that AI is a real thing.

The article is about how Azure failed ONE TIME to accurately identify an image. Does your imaginary 2 year old ALWAYS correctly identify objects? Do you? Are you some infallible god-like being? Are you omniscient? Does this line of hyperbolic inquiry lend any meaningful credence?

Here's the actual guidelines document: https://docs.microsoft.com/en-us/windows-hardware/drivers/driversecurity/

Microsoft not only yanked the phones from its mall stores

I bought this phone in a Microsoft mall store this winter.

they also stopped all updates to the OS

Nope, got one last week.

and disabled WiFi in the OS

I'm posting this over wifi now.

Is there like some tech version of Infowars that you spend time reading, or something?

Windows Phone 10 is still alive and well.

Oh, and about that:

https://support.microsoft.com/...;

The OS will be fully dead and buried on December 10th, 2019 (unless you have windows phone embedded handheld edition, then it's some time in 2021.)

I'm actually tempted to try a windows phone

Just keep in mind that security patches are scheduled to be discontinued on December 10th, 2019, per Microsoft's website.

https://support.microsoft.com/...;

On that date, the final nail will be hammered on the windows phone coffin, unless you're a windows 10 mobile enterprise customer, (do any exist?) then you get patches until some time in 2021.

The structure alignment rules for anything that's not a packed structure are likely to be the same for both

I found this for Android - long long is aligned to 8 bytes on ARM but 4 bytes on x86

https://software.intel.com/en-...

Microsoft compilers have an option to align. It seems like /Zp8 is the default

https://msdn.microsoft.com/en-...

What that means is that anything up to 8 bytes will be naturally aligned

And if you look here it confirms it

https://msdn.microsoft.com/en-...

I still think there'd be some corner case where the layout in memory of a structure would be different. Bitfields for example, though Windows usually doesn't use those because of portability concerns. Or SIMD data.

Another issue is that x86 and x64 are strongly ordered and ARM is not. You have to add in explicit barriers to for ARM to work the same. ARM I&D caches are not coherent too - self modifying code works on x86 because writes to the D cache automagically end up in the I cache. That's not true in ARM. x86 goes to great lengths in hardware so that code now sees the same machine that code back in the 386 days did and one which is very different from both a moder x86/x64 chip and any Risc chip. Modern x86/x64 chips have extra hardware to maintain the illusion and Riscs like ARM do not.

The structure alignment rules for anything that's not a packed structure are likely to be the same for both

I found this for Android - long long is aligned to 8 bytes on ARM but 4 bytes on x86

https://software.intel.com/en-...

Microsoft compilers have an option to align. It seems like /Zp8 is the default

https://msdn.microsoft.com/en-...

What that means is that anything up to 8 bytes will be naturally aligned

And if you look here it confirms it

https://msdn.microsoft.com/en-...

I still think there'd be some corner case where the layout in memory of a structure would be different. Bitfields for example, though Windows usually doesn't use those because of portability concerns. Or SIMD data.

Another issue is that x86 and x64 are strongly ordered and ARM is not. You have to add in explicit barriers to for ARM to work the same. ARM I&D caches are not coherent too - self modifying code works on x86 because writes to the D cache automagically end up in the I cache. That's not true in ARM. x86 goes to great lengths in hardware so that code now sees the same machine that code back in the 386 days did and one which is very different from both a moder x86/x64 chip and any Risc chip. Modern x86/x64 chips have extra hardware to maintain the illusion and Riscs like ARM do not.

ARM and x86 are both little endian, so that difficulty goes away.

Last time I did ARM they could be driven in either little-endian or big-endian mode based on flags in the AIRCR register.

According to Overview of ARM ABI Conventions:

Although the SETEND instruction in the ARM instruction set architecture (ISA) allows even user-mode code to change the current endianness, doing so is discouraged because it's dangerous for an application. If an exception is generated in big-endian mode, the behavior is unpredictable and may lead to an application fault in user mode, or a bugcheck in kernel mode.

So Microsoft isn't going to stop you from changing endianess on the fly. No doubt in coming months we'll be seeing WebASM and Javascript attacks crashing Windows 10 ARM devices because of this.

The 32 bit port of NT for Alpha was released but the 64 bit one was internal only - they used Alphas until they got Itaniums

https://technet.microsoft.com/...

A colleague of mine rescued an Alpha AXP machine from a dusty closet. Upon booting up the system, he discovered that it was running a 64-bit version of Windows from early 2000. How is that possible?"

I happened to have one of these machines in my office then. In its prime, this machine was a force to be reckoned with. It was about the size of a small refrigerator and generated about as much noise as a vacuum cleaner. It contained four-count 'em, four!-Alpha AXP processors, each running at a mind-boggling 400 MHz. It had one gigabyte of RAM and thirteen gigabytes of hard drive space, striped over a dozen fast SCSI drives. This may sound puny today, but back in the 1990s, these Alpha AXP machines were the envy of the block and made you the popular kid at the lunch table.

In 1999, when Compaq announced it would no longer support Windows on the Alpha AXP, a lot of Alpha AXP systems were suddenly left sitting around Microsoft with no official duties. Some of these machines, however, were pressed into a variety of unofficial duties. I used my Alpha AXP system to index the entire Windows source code. You can imagine how convenient it can be for a programmer to be able to identify all callers of a function in just a few seconds or to locate the source code for a function or dialog box that shows up in a debug trace.

But even for the simple task of indexing the Windows source code, the Alpha AXP was soon overshadowed by x86-class machines. These were cheaper and faster, they offered more hard disk space, and they had more memory. So for this reason, my machine soon joined its forgotten brethren. It was assumed that the end of support for the Alpha AXP was the end of these machines, but then they were given an opportunity to go out in a blaze of glory, breathing their last breaths in service of the next generation.

The 64-bit Windows project was already well under way, and of the 64-bit processors under consideration, only the Alpha AXP was actually available in physical form. The Intel Itanium was still under development and ran only in a simulator, and the AMD64 architecture hadn't even been invented yet. As a result, 64-bit Windows was initially developed on the Alpha AXP.

When Compaq announced that they would no longer support Windows on the Alpha AXP, all these Alpha AXP machines that previously had been used for 32-bit Windows 2000 development and testing got repurposed and began serving a secret life as test machines for a 64-bit operating system that will never ship in that form. The Alpha AXP was merely a proof-of-concept platform.

The Alpha AXP machines served that role well, giving the 64-bit Windows team real hardware to work with instead of having to run the operating system on an Itanium simulator. (You can imagine how slow that was.) Sure, the Alpha AXP wasn't the final target hardware, but it was a big help. And when physical Itanium CPUs began showing up, the niche filled by the Alpha AXPs vanished, and they were once again retired into dusty closets.

There is next to no chance that I will ever use this, but for those who would, it looks like useful information. You may want to skip to the actual information as the quoted article is as thin as it gets.

https://docs.microsoft.com/en-...

It's probably not '64 bit apps', but "64bit x86 code" that isn't supported because transpiling that to ARM is harder.
But native ARM 64 bit binaries probably work fine.

Again, seems logical. I'm guessing that the windows user interface has been re-built, and probably lacks a whole lot of backwards compatibility. Given that ARM devices are likely performance restricted by comparison, it's no surprise to me that there's little or no access to any ARM-specialized user interfaces (i.e. all of them). Not really disappointing, but a limitation for sure.

Actually, the 'journalist" is an "idiot". Read the actual documentation .

Shell extensions. Apps that try to hook Windows components or load their DLLs into Windows processes will need to recompile those DLLs to match the architecture of the system; i.e. ARM64. Typically, these are used by input method editors (IMEs), assistive technologies, and shell extension apps (e.g. to show cloud storage icons in Explorer or a right click Context menu).

Long story short; Explorer.exe is recompiled as native ARM64. Thus any DLL that is loaded into explorer.exe has to also be ARM64. I think that's a pretty damn reasonable technical limitation. (And, most importantly, Microsoft are stating shell extensions are supported; they merely need to be ARM64 native.) The journalist is completely and utterly wrong and could not be more wrong if they tried. They're so wrong, that I would argue they're defaming Microsoft.

What ISN'T supported is "injecting x86 dlls into ARM native processes".

(Interesting comments there -- looks like the x86 world is "Windows on Windows", exactly how the x86-32 world exists as "Windows on Windows" within x64 windows. Same limit there, I think you can't load 32 bit DLLs into 64 bit processes today. That might be why x64 machine code isn't supported because there already is that 'bubble' for 32 bit x86 WoW tested, but not a second WoW for 64 bit. And presumably they simply aren't going near ARM32.

What is ACTUALLY a surprise is the OpenGL limitation - which is far more 'microsoft being anti-competitive' than literally everything else this reporter thinks.

Aside from the absurdity of his claim, he could just get a Windows 7 ISO from here: https://www.microsoft.com/en-g...

https://www.microsoft.com/en-u...

https://www.microsoft.com/en-u...

and I'm sure Windows has lots of easily installed stuff.

The same tools used by professionals are now available free for the asking and have been for years now on Windows. Visual Studio Community Edition and Visual Studio code are both free to download and use. You can get them at VisualStudio.com and there's a vast wealth of programming knowledge, how to articles and countless reference materials available free of charge on Microsoft Docs. What more could you ask for if you wanted to get started with programming?

1) Summary indicates there are people who are annoyed. No actual links to annoyance.
2) Summary indicates it's quoting a blog post. No blog post linked, just the rules page.
3) The rules page has been around since 2015: https://archive.fo/https://www... - not that "new code of conduct" means that the writer intended to convey it was brand new, but certainly it will be interpreted that way by a lot of folks.
4) FreeBSD had some sort of discussion around it when it came to be in 2015: https://www.phoronix.com/scan.... and it looks like there was some actual internal stuff for project participants that occurred but again, nothing really happened
5) This type of code of conduct isn't really crazy in the OSS world by a simple search. For example, https://www.contributor-covena... shows a plethora of OSS projects that participate and is based on similar principles. Big names OSS participants include Eclipse, Spring, Atom,
6) Microsoft has code of conduct that touches on similar issues: https://opensource.microsoft.c...
7) Github has a guide actively encouraging codes of conduct within communities: https://opensource.guide/code-... and pointing to other OSS projects that have them: https://www.djangoproject.com/...

If you look at FreeBSD's code of conduct in context it really seems like they're late to the party, which may just be a formality (the community norms might already be enforcing these types of rules anyway) or a dramatic change, but there's no way to actually get that from the summary at all.

The OEM license only extends to the original manufacturer and its first consumer or another consumer they directly transfer the license to (both parties have to explicitly agree to the transfer and the original owner is seemingly liable for compliance of its next owner) and the hardware has to stay with the software.

This is factually incorrect.

The law says you are wrong, and Microsoft says you are wrong.

A retail license extends to a consumer. An OEM license extends to a computer.

A computer can not grant permission for anything, let alone transferring its license. An OEM license never applies to a human being, so it can't be transferred by one.

Even Microsoft says this:
https://blogs.msdn.microsoft.com/mssmallbiz/2009/10/27/no-oem-microsoft-windows-licenses-cannot-be-transferred-to-another-pc/

As you can see, the OEM Windows license is âoelockedâ to the original PC it comes with and cannot be transferred to any other PC.

The license remains with the computer. The original owner discarded the computer+license. This shop picked up the computer+license. When they resell it, it will still be the computer+license.
The license MUST remain with the computer, the reseller shop can't legally seperate the two if they wanted.

All of these computers have a valid license

What's more, the Windows Restore disks were downloaded by the reseller shop at the time the computer+license was in their possession!
Once the computer+license was sold, the restore disk went along with the computer+license.

There was simply no copyright infringement at all.

Windows 10 install disc that installs with a valid Windows 7/8.1 product key: https://www.microsoft.com/en-u...

OEM install discs are *usually* available from the OEM for what is considered a small, media duplication fee. OEM install discs include device-specific drivers and other licensed software.

For those not aware of how this works, it's not an illegal copy. To install Windows on a PC, you need a install disc PLUS a key... the content of those discs can be downloaded online or made with any Windows computer to be used in another. In order for you to install it in a new pc, you need a key that will be validated for that machine alone. The recycled computers had them... Dell desktops comes with a sticked on it with said key. No one getting those DVDs needed a pirated copy, just a install disc, which again, anyone can get without paying a dime.
https://www.microsoft.com/en-u...

The restitution for lost sales is just bullshit, even if the dvds had pirated content, which they didn't.
It is fucking shameful that a corporation this big would throw a guy that's trying to do some good in jail without understanding how their own OS works.

You can download windows images for free straight from microsoft.com

Yup, when you're the copyright holder you can do exactly that. Allowing anyone to download it in no way implies any relinquishment of Microsoft's distribution rights. It's like when Weird Al made "Don't download this song" available as a free download. He can do that, but unless he gives you permission to do the same, you'd still be violating his copyright by redistributing it.

Also, the OEM license you'd typically find on a Dell or its ilk requires a specific OEM copy of Windows (or some hackery of the installation files, last I checked). You usually can't just download Windows from Microsoft and have it accept the OEM license serial number.

The best solution for these type of used computers is to simply restore Windows yourself (as part of the refurbishment process), and dump the Windows ISO onto the hard drive, for the end user to burn as a "recovery disc". That way, everything on the computer is licensed, and it's the end user making a "backup" (which they are legally entitled to do).

You can download windows images for free straight from microsoft.com. No verification of any kind or product key required. All he did was burn it on a dvd and hand it out as a freebie.

You'll start reading a lot more stories about upgrading come fourth quarter 2019. Security updates for Windows 7 end on January 14, 2020 (source).

• datacenter nework switches is probably Microsoft's SONiC distro.
• cell phones is (god I hope it's not Android - but it's certainly not SONiC or Debian either.
• servers running open source software is almost certainly Debian.
• servers running closed source software (Oracle, etc) is probably Red Hat or some Canonical offering.
• my laptop - Debian.

Linux is in far too many places for "a" "best" distro.

But it's not hard to pick candidates for the best for specific purposes.

Last time I checked a complete rewrite is not necessary at all. Sometimes a one liner, e.g. SetDllDirectory(""), is more than enough.

While officially Microsoft supports static linking, in practice, it is necessary to use DLLs in many situations. The Microsoft official answer is at: Extension DLLs

The practical reasons that I have been forced to use DLLs are:

• 1. If you want your application to upgrade smoothly over the years, you have to use either the DLL calls or the windows system calls and avoid the statically linked C libraries. For instance, when the times and dates for daylight savings time change, only the windows calls get updated automatically. The statically linked libraries don't get updated. DLL libraries get updated when the DLL gets updated (which can lead to DLL Hell, but that is another story.)
• 2. If you have an application that allocates memory in one DLL and frees it in another, then it is vital that the library that does the memory management be a DLL. Otherwise, each DLL has it's own statically linked memory mapping library, and they don't know about each other's allocations.
• 3. (2) applies to applications that use new and delete. It also applies to applications that are ActiveX controls and using IMalloc.
• 4. Some of the cool Microsoft libraries link to DLLs, so it doesn't matter if you want to use static libraries. You are getting DLLs.
• 5. Only the really old languages like C++ and QuickBasic supports static linking. I'm pretty sure Visual Basic, C# and .NET all require DLLs.

Windows forms have had a stable and consistent API for going on 30 years now, with braindead-easy implementation in .Net for more than 15 years.

WNDCLASS is a struct to define the settings of a window while you're creating it. This was in common use back in the Win16 days, along with the CreateWindow() function.

WNDCLASSEX is the same thing, but EXtended with a few extra settings, like the small icon in the window title bar. This became a thing with the dawn of the Win32 era, along with the CreateWindowEx() function. CreateWindow(...) is now just a macro to CreateWindowEx(0, ...), which can take any WNDCLASS(EX), which self-specifies the struct size for future expansion.

Meanwhile, in .Net-land, all of this is just "Form f = new Form()" (or, if you're a mouth-breather, "Dim f As New Form") and you're done. But under the hood, the CLR is still using all of the same CreateWindowEx() stuff.

That's how you stable API. Javascript certainly can't touch it. It hasn't even existed as long as Win32 has, much less been stable for that whole time. And Win16 has 10 years more beyond that.

Windows forms have had a stable and consistent API for going on 30 years now, with braindead-easy implementation in .Net for more than 15 years.

WNDCLASS is a struct to define the settings of a window while you're creating it. This was in common use back in the Win16 days, along with the CreateWindow() function.

WNDCLASSEX is the same thing, but EXtended with a few extra settings, like the small icon in the window title bar. This became a thing with the dawn of the Win32 era, along with the CreateWindowEx() function. CreateWindow(...) is now just a macro to CreateWindowEx(0, ...), which can take any WNDCLASS(EX), which self-specifies the struct size for future expansion.

Meanwhile, in .Net-land, all of this is just "Form f = new Form()" (or, if you're a mouth-breather, "Dim f As New Form") and you're done. But under the hood, the CLR is still using all of the same CreateWindowEx() stuff.

That's how you stable API. Javascript certainly can't touch it. It hasn't even existed as long as Win32 has, much less been stable for that whole time. And Win16 has 10 years more beyond that.

It's not as simple as that. Suppose I'd built some Mac software at the time I built my NT 4.0 binaries in 1997.

At that point I'd have been building a 32 bit 68K and PowerPC binary for MacOs 8.x.

For the first few releases of OS X my code could have run in the Classic Environment. That is no longer supported.

Then I'd have had to move to Carbon, which requires code changes.

Since then support for Carbon has been drooped so I'd need to move to Cocoa. More changes.

At some point I'd need to have moved from PowerPC to Intel. More changes.

And finally support for 32 bit binaries is being killed off, so I'd need more changes to get my code to build for 64 bit.

I.e. to keep my application running I'd have had to make at least four sets of changes.

Meanwhile with Windows I can run literally the same binary I compiled in 1997. It's Win32 x86 code. In fact a few of the things I wrote needed Admin rights. Since I wanted them to work in corporate environments where not everyone is Admin they actually work OK on a machine with UAC - they say you need Admin rights to run, so you run them from an Admin command prompt.

The GUI ones look at bit dated, but that's because Windows runs them with the old version of the Common Controls. If I added a manifest they'd look pretty modern. And of course running old code with an old version of the common controls is something MS do to increase the likelihood of it working.

Compare that to multiple changes of instruction set and API for an equivalent Apple utility. Plus of course there are lot more Windows machines than Macs. About 10x now and it was up to 20x in the past.

https://www.netmarketshare.com...

So for Mac you have to do more busy work because Apple keep killing off legacy features in return for a 10x smaller market. And you need to keep buying Macs to support the latest OS so you can run the latest development environment and do that busy work.

In fact the development environment has changed at least once in that time too.

Adobe Photoshop was aimed at Carbon. John Nack at Adobe explained why Photoshop wouldn't be 64 bit on Mac at the same time it was 64 bit on Windows

https://web.archive.org/web/20...

Basically Photoshop was a Carbon App. Apple had been telling Adobe that Carbon would be able to run 64 bit applications and but when they went to the WWDC they heard from the stage that Carbon 64 had been cancelled. In the comments you read a lot of people flaming Adobe for sticking to an old API but one comment that points out that moving a large application from CodeWarrior to XCode is not easy and you need to do that to port from Carbon to Cocoa -

This is one of the very few areas where I simply cannot fault Adobe management in any way. To the general public, and to younger Mac developers who jumped on board after the iPod, it may seem as though they've been dragging their feet all this time, but the reality is that Apple has hasn't expressed much interest in supporting the efforts of third-party developers since the NeXT buyout, and Adobe engineers had every reason to reject the grossly inferior tools they were being offered every step of the way.

First they killed CFM in favor of Mach-O; not because it made any sense at the time, but because Avie stood to profit from Mach-O's adoption. Remember how CFM had all that multi-ISA support in there? Wouldn't that have come in handy during the Intel transition? I personally thing it might have, but I'm not in a position to look at Rosetta's code and offer anything resembling an educated opinion--just uneducated speculation.

Then they gave Mike Ferris free reign over the amount of turd polish that would be applied to Proje

Second snippet of the windows 2000 code:

while (true) {
KeBugCheck(0x000000E2);
}

Consider Microsoft's position:
Many of the operating systems are on End-of-Life status which means this product will no longer receive assisted support or security updates from Microsoft. These OSs are still widely used and are now even more vulnerable, if that's possible.
Microsoft is in a bind. They could provide patches for these vulnerabilities, or restate their policy: "Your're on your own bucko". How many people left at Microsoft worked on the Windows 2000 software or remember it? If MS does somehow figure out how to patch these OSs, then I can see that as setting a precedent that says they will provide security fixes in certain situations. That's the kind of vague context that lawyers love and could lead to future class action lawsuits when they refuse to fix a bug that caused problems for someone. "Hey Microsoft, you did a fix for Eternal Blue but didn't do one for Never Ending Orange and my data got stolen! It's your fault."

BTW Windows 7, which even MS haters grudgingly admit was a pretty good product, is really "Vista 2" based on Microsoft's internal version numbers for Windows.

Vista = Windows NT 6.0
Windows 7 = Windows NT 6.1

In other words, Windows 7 was basically what they hoped to ship as Vista; it took them another dev cycle to get it right.

(And Windows 7 still shipped with a filepath limit of 260 characters....)

3. Vista was the first version of Windows which enforced admin/user separation. Unix-based OSes (Linux, OS X) have this built-in since Unix was designed assuming a multi-user environment. Users are given just enough privileges to run their programs, and likewise user programs are written assuming these minimal permissions. Windows was built upon DOS and the assumption that there was a single user who had total control of the computer. Consequently, even though Windows 2000 introduced the concept of admin/user separation, it was widely ignored. Most Windows programs were written assuming they had admin privileges.

When Vista took away admin privileges (for programs run from a non-admin account), lots of programs stopped running. The ones which did run triggered countless UAE elevation request dialogs - so many that users became trained to just click OK every time it popped up, which pretty much defeated the whole purpose of requiring privilege elevation. Over time, programs were modified to run limited to user privileges, which is why it isn't a problem to run Vista now. But if you had to use it when it was first introduced, it was a nightmare.

4. Microsoft's system requirements for Vista were totally unrealistic. Most XP systems at the time had 128-256 MB of RAM, with the occasional 512 MB system. 1 GB was profligate with XP. Microsoft didn't want to freak people out, so set Vista's minimum memory requirement at an unrealistic 512 MB. With that little RAM, Vista begins swapping the moment you try to start your first program. Realistically, 1 GB is the minimum, 2 GB a comfortable amount.

5. XP was developed from 1998-2001 and released in 2001. Vista was developed from 2001-2006 and released in 2007. 2004-2005 was when Intel ran headfirst into the brick wall of physics (higher clock speeds resulted in excessive leakage and power consumption) and processors stopped doubling in clock speed every 1.5 to 2 years. Based on Windows 3.x, 95, 98, and 2000, Microsoft had assumed CPU speeds would increase by a certain amount from development to release. Consequently, XP was a dog when it was being developed, but by the time it was released computers had gotten fast enough that it performed well on customer machines. Vista was a dog during development, and was still a dog when customers began buying it.

Those of you claiming Vista runs well and was unfairly maligned should try running it on period hardware - a Pentium 4 or Core Solo/Duo (not Core 2) with 512 MB of RAM. I'd say run it with period software too just so you can experience getting a UAE elevation prompt a dozen times a day, but it'll probably be tough to find period software.

Linux was more successful precisely because it wasn't tied up in dozen-plus years of support.

To me that's a red herring because various programs broke in Windows XP SP2. Microsoft chose to keep supporting XP because they chose to keep supporting XP. Clearly as time progressed, they started breaking things as they added new features. But, they clearly also chose to keep the bigger improvements in the new Vista code base.

Ie, to avoid letting users get all the new features as they were made, they chose to segregate them to try to lure people into a new version. Otherwise, all they have left is people choosing to update to continue to get security updates. They only need those because their software--like most software--is full of security holes.

That's not an issue with Linux because most releases are pretty arbitrary and the whole LTS stuff is more about trying to isolate the bigger churn of code from the user for testing purposes and the like. Ie, effectively it's trying to isolate the alpha/beta code by trying to separate out the more well tested stuff (by the community) from the rest. Hence, support extends to the degree at which distros actually listen to their community and incorporate changes more than anything.

They already do for bigger businesses, it's called "software assurance". Believe you me, if/when they could figure out how to force smaller business users into subscription Windows they will.

Dont worry, it's coming. You can now get "Microsoft 365" and Microsoft will be forcing companies to it by abandoning WSUS and system center. For instance, after beating my head against the wall for a while it turns out you can't upgrade Windows 10 to the fall update via WSUS - it just.. fails.

Want to keep using SCCM and WSUS? bad luck.
My guess is we'll soon see "sorry not supported on Windows 10. but for only $17 to $28 per month per seat, we can do it all for you on Azure."

"Removing support for old stuff at the right time is part of the software flow"

I agree but seeing as they are offering extended support until 2020 for win 7 and 2023 for windows 8.1 i would argue that this is nothing more than a push for windows 10 adoption. Otherwise they would have rolled back the support for windows 7 first and then at the appropriate time windows 8. In other words i agree with your sentiment if they were only stopping support for windows 7, but killing support for win 7 and 8.1 has nothing to do with software flow and everything to do with strategic decision to gain control over people's desktops through windows 10. (you should also note the support dates for windows 10, because as they continue on with this "rolling update" operating system they are making a play for greater control through shorter service life)

https://support.microsoft.com/...

That's the difference between Apple and MS. If you have MSDN Universal you can get old versions of Windows.

Admittedly MSDN Universal costs a tonne of cash and you're only supposed to use the old versions for testing.

MS used to provide digital downloads of old versions via Digital River but they killed that service off when 8 came out and people were using it to get 7

https://answers.microsoft.com/...

Unfortunately Microsoft suffer from Apple envy and have a tendency to copy the things Apple do, usually in a way that makes Windows a less desirable platform.

One example would be not patching old OSs to run on new CPUs and requiring new CPUs for new OSs. I.e. in a very Apple like way they're trying to tie a new OS to new hardware and old OSs to the old hardware.

It looks like you can also disable the patch (or at least the spectre variant 2 and the meltdown migitations) in Windows clients now also. If I'm reading the bottom part of this article right: https://support.microsoft.com/...

Back in the old days Windows had a style WS_THICKFRAME. That both made the resizeable and gave them a frame a few pixels wider. The wide frame was cue to the user they could resize and also made it bit easier to grab the frame to resize. Now of course designers have decided thick borders are aesthetically ugly, even though for less dexterous users that must make the UI harder to use.

It's like accelerators. In the original Windows accelerators were always visible. So for example the F in the File menu was underlined as cue that Alt+F would open that menu. So to save a file you'd type Alt+F, S.

Then in WIndows 2000 designers got involved and decided this was ugly so they're hidden until you hit the Alt key

https://blogs.msdn.microsoft.c...

I.e. there seems to have been a move to flatter UIs on aesthetic grounds even though this makes them less discoverable to noobies. Modern Android, macOS and Windows take this to absurd levels.

You should go to Raymond Chen's Old New Thing blog and tell him this. I'm sure he'd be eager to hear one liner technical advice from Slashdotters on how Microsoft should handle back compatibility.

https://blogs.msdn.microsoft.c...

>> Don't collect data from my devices. No ifs and buts. Don't.

Microsoft tried this, and you complained about how Windows crashed all the time and never worked right.

Now Microsoft collects telemetry and uses it to fix what is broken including (with stunning frequency) working with hardware vendors to fix their shit-tier drivers.

"Muh telemetry!!!" my ass. You aren't interesting enough to spy on, pleb. Read the fucking privacy policy already. http://microsoft.com/privacy. They aren't Google.

That is the joke.

In the same vein, Windows machines had an issue with the TCP ports on machines with 495 days of uptime.

There is a hotfix.

The "hotfix" requires a reboot.

How do we know that the hotfix isn't just the reboot?

The innovative bounded floating point system computes two limits (or bounds) that contain the represented real number. These bounds are carried through successive calculations. When the calculated result is no longer sufficiently accurate the result is so marked, as are all further calculations made using that value.

- Any floating-point-type error is certainly programmer's fault as far as being aware about these limitations is part of the basic knowledge which someone working with big decimal values should posses. So, avoiding problems like the one referred by the quote below these lines doesn't require a programming structure re-definition, just a competent developer.

the most notorious floating point error was the Patriot missile failure in Saudi Arabia...

The innovative bounded floating point system computes two limits (or bounds) that contain the represented real number. These bounds are carried through successive calculations. When the calculated result is no longer sufficiently accurate the result is so marked, as are all further calculations made using that value.

- Any floating-point-type error is certainly programmer's fault as far as being aware about these limitations is part of the basic knowledge which someone working with big decimal values should posses. So, avoiding problems like the one referred by the quote below these lines doesn't require a programming structure re-definition, just a competent developer.

the most notorious floating point error was the Patriot missile failure in Saudi Arabia...

The link provided in the article doesn't show anything with Javascript disabled.

So here is the original link:
https://blogs.microsoft.com/bl...

The book is here:
https://msblob.blob.core.windo...