Is Microsoft going back to the future on release cadences? Industry talk of a revised engineering schedule that would see Microsoft take a step back from the regular Windows release cadence of recent years in favor of a three-yearly cycle is gaining volume. Could this be a cure for the giant's quality woes? Users of a certain age will remember how the cadence used to be. Windows 1.0 …
Some would probably argue that stability has always been missing from the Windows world. But W2000 was probably the peak of stability* after they'd mostly abandoned running on top of DOS (with only ME still to come).
* And with a FAR better and consistent user interface than the clusterfuck of badly nailed-together shit it has been since the Windows 8 disaster.
This post has been deleted by its author
MS fully abandoned to run on top of DOS since Windows NT was delivered - relegating it to the Win 3.x/9x line. 2000 was NT4 + the missing modern parts (USB support, Direct X) and Active Directory.
On NT system, DOS apps are run separately in Virtual86 sandboxes.
NT was a whole other lineage, born from their work on OS/2 for IBM, and existed in parallel with the DOS versions of Windows until XP, where the NT line staged a royal coup and put the world out of DOS' misery.
I still use Win2K: It's got the enormously successful Win95 user interface. But it wasn't entirely bug free: on release it had an unrecognized SMB problem that caused occasional file corruption.
People blamed Source Safe and MS Access. But 'file corruption' isn't really an application bug: it was the Win2K network file system underneath. (And the applications had worked correctly on Win98 networks.)
I have to ask, for all the new stuff MS has trickled out in Windows 10, how much of it has actually been a success?
3D Paint? Nope, that's been quietly shuffled aside, and plans to bin Paint Basic have been reversed.
Groove Music? Quietly going back to Windows Media Player now in W11.
Snip & Sketch? That's been replaced with an upgraded version of the previous Snipping Tool
Cortana? Dead, basically.
That's the thing, MS has spent so much time with Windows 10 introducing a whole pile of new features and new utilities over the past 7 years, yet many of them have turned out to be complete and utter flops. Maybe, just maybe MS is beginning to realise that instead of questionable gimmicks, their time might be better spent on features people actually want.
Of course I say that, but if they really were interested in features people want, we wouldn't have the Windows 11 Taskbar / Start Menu shambles that we currently have, so they still have some learning to do...
Nobody wants almost any programs that come with Windows.
To be frank, the only thing most users want from Windows as an Operating System is to Operate Systems. ie; to get from the Windows UI to their program of choice to either do work, play games, read their emails or whatever.
The last improvement that I personally noticed in Windows was from XP to Win7 when hovering over a music player on the taskbar gave options for last track, pause or next track without having to bring the program into focus.
If we take "minimum time, effort and annoyance required to do a job" then the actual usability of Windows 10 if judged by this metric has gone backwards from Win95(SP4, the crashes in the earlier versions were more than slightly annoying) going by the amount of time spent in the Windows shell because the Win10 start menu and UI generally is an unmitigated disaster. It's trying to force smartphone norms for a 7" touchscreen onto a often 24"+ non touchscreen device which originally was to try and persuade all of us to go out and buy a Microsoft Phone.
But now that they killed off the Microsoft phone it would be nice if they'd kill the off interface too, or just offer a classic mode with the Win7 GUI.
I know it's still fashionable to hate on Microsoft and Windows, but the reality is, a few missteps aside, it's gotten progressively more stable over the years. Anyone who used Windows 3.11 (or earlier) probably remembers the GPF errors that would pop up randomly. You could just be sitting there, not doing anything, and BAM, GPF error. With the move to 32-bit in Win95, allowing the use of protected memory, the GPF slowly disappeared as 16-bit software was replaced with 32-bit counterparts. Now in the 64-bit world, where 16-bit support has been dropped completely, the GPF should be impossible to ever see.
Then those of us who are old enough to remember the early years of XP remember how literally, every week, there was at least one new critical remote exploit found, most of the time not even requiring any user action to trigger. Remember the Messenger service spam, or when some knucklehead figured out you could reboot 2000/XP systems over the Internet? Remember all those email worms?
People complain about how Windows 10/11 force them to reboot to install security updates, but we saw what the alternative was when people just never bothered to install updates. It's easy to forget now that most of these problems no longer exist thanks to Microsoft's engineers plugging away at them over the years.
Users of a certain age will remember how the cadence used to be. Windows 1.0 turned up in 1985, Windows 2.0 in 1987 and Windows 3.0 in 1990. Windows 3.1 and 3.11 appeared in 1992 and 1993 respectively before the big bang of Windows 95 in 1995.
Yeah, I remember this time... 95 in 95, OSR2 in 96 to fix bugs... 98 in 98, then 98SE in 99 to make 98 good... then ME 2 years later, which was... erm...
In parallel to that there was NT3 in '93, NT4 in '96, and the much delayed NT5, which I seem to remember was due out about 1998 but eventually turned up as Windows 2000 4 years later.
Then there was XP a year later in '01, which was flogged a bit (MCE in various guises around '03-'04) then Vista appeard in 06.
They then went back to 3 year releases for Win 7 and 8, even though 8 was a cluster fuck. (In a very 98SE move though 8.1, a year later, was okay but forgotten).
Perhaps not quite as regular as MS would like us to remember. :)
"In a very 98SE move though 8.1, a year later, was okay but forgotten"
8.1 was a bit less shit than 8, but I wouldn't go so far as to say it was OK! Still had no proper start menu (the button had reappeared, but it just linked to the full-screen big-tiles mess). Still had the confusion of two separate versions of IE, one the normal desktop version and one the tablet-esque full screen one.
The server version, 2012 R2, was actually reasonable provided you put Classic Shell or similar on it, and it had a few innovations such as DHCP failover scopes which were quite useful and not in earlier versions.
ok, here we go (again):
XP was the same codebase as Server 2003 (and XP SP3 was the same effectively as 2003 R2)
Vista and 7 were the same as Server 2008, with windows 7 SP1 being the same as 2008 R2.
8 = Server 2012, 8.1 = Server 2012 R2
Windows 10 "Anniversary Update (build 14393) = Server 2016.
Windows 10 "October 2018 Update (Build 17763) = Server 2019.
Windows 10 "November 2021 Update (Build 19044, aka 21H2) = Server 2022
(From WIkipedia)
The major thing I do not like about the windows 10 release cadence is that it gets treated as a full install or upgrade, which is not nearly as bad as, say, installing a service pack or cumulative update*. A lot of corporates have their OS update process tied to their desktop refresh process (which, to no one's surprise, was three years), so increasing the OS's release cadence threw a bit of a wrench into the works. I know that it did for [RedactedCo] at least, although the OS upgrade process got tested pretty hard before we deployed it to the masses (SCCM is actually a pretty good tool for that now, and worth the hassle and effort of standing it up, as long as it's done correctly.)
I would prefer a stable environment as opposed to the latest shiny, at least for my operating systems, and especially for servers.
I want to take a specific note to Exchange Server- the Cumulative updates of which are, to no one's surprise, full installs of the server software. Needs to deploy a new DAG node? use the latest CU to install it (and to patch the other DAG nodes while you are mucking around in there.) Deploying new Edge servers because the on prem email gateway got 'upgraded' to a hosted solution and won't talk directly to the designated relay box in the environment? Use the CU update installer.
It's madness, but it's a refreshing madness, because then all one has to do is pull down anything since that CU.
Regarding Exchange, yes it's a pain in the arse - and the CUs have to be installed manually: they can't be pushed out through WSUS, and so far as I recall Microsoft only supports the most recent two CU levels so it needs doing at least once a year, probably at least twice if you prefer to keep with the current version.
Not by any means a quick process to install them either!
Plus with a hybrid setup you have to stick with Exchange 2016, which in turn also means Windows Server 2016, unless you want to pay for an Exchange 2019 license (2016 is free for use as a management machine in a hybrid setup with cloudy mailboxes; 2019 is not). And 2019 has an official minimum of 128GB RAM.
If you ditch the full server you have to do everything with Powershell or third-party tools. No thanks! Powershell is useful for bulk tasks, but for the odd tweak to an individual account the GUI is much more practical.
Didn't realise 2019 was free now, but the RAM requirement is more of an issue. I understand it will run with a lot less, but Microsoft's excuse if asked for support and it's running with less is fairly predictable...
While the above is correct, they've done something odd with how Server 2022 reports - type ver at the command prompt and it gives you 10.0.20348.859 (current fully-patched install).
I don't know for sure why this is, but I would surmise that by reporting 20348 rather than 19044 the aim is to avoid future issues with software which thinks it's W10 and checks for a minimum build number, then refuses to install because you are not on one of the three 'supported' releases of W10 according to the build number (despite it not actually being W10). This does happen with 2016 and 2019 (which report the build numbers as stated above), and can be a particular issue where you need to install client-side software (e.g. on a terminal server). It was and is an issue with some of the Adobe Creative Suite programs, to give one example
Until W10 there had for a while been a direct correlation between the client and server versions.
They used to be the same product.
The dread word "agile" was slung around and the result was the catastrophic
That's a big misunderstanding of agile though.
Agile is pretty much the way to develop software.
The problem is most people don't do agile, they call waterfall 'agile' and carry on as before.
I worked for a company that actually did agile correctly. We wrote good, well tested software.
We have since been taken over and the new parent company is 100% Waterfall. Going back has been a terrible shock, the quality of the software we produce has declined, the time taken to write it has increased, and all the old problems associated with Waterfall have come back around. (Unrealistic deadlines set without full understanding of the complexities of the software; months spent planning by people who don't actually write or design the software so make generic assumptions, timescales that are 'estimates' that become set in stone, immovable deadlines despite the product being behind schedule, everyone looking out for themselfs rather than the product, people complaining as their 6-12 month resourcing plans have gone out the window as devs are still on this project, people actually thinking you can make 6-12 month resourcing plans in the first place, etc.)
The problem with Agile is doing it correctly is a significant mindset change for everyone involved, and you're fighting against ingrained ideas that seem sensible despite time and time again them being shown as poor ways to project manage. You have to have buy in from everybody, not just the development team, an Agile developent team working within a larger Waterfall framework is still Waterfall.
The best description of Agile, and the one that made me 'get it' is this:
"Work out where you're trying to get to, take a small step towards that goal, repeat until you're there."
That can mean starting a large project without an end date; ie you have to recognise you may have to spend some budget to determin if a project is viable, or there are a load of gotcha's that you didn't forsee on the way. Many people find that hard, but don't consider that actually the 6 months everyone spends discussing a solution that's only ends up being 75% there costs as much, if not more.
The problem is most people think it's much easier to sell a cool new product or feature and then shout at IT when they don't write it in time. (as we did our bit at the start of the project so it can't be us).
No it isn't.
At least, it's not the only way.
It is, however, become the way for people who can't be arsed to properly define the needs of the software and require multiple iterations to finally think : "yeah, that'll do".
The Apollo program wasn't built on agile.
I'm willing to bet that JWST wasn't built on agile.
Agile is just the excuse for the majority of people who can't plan properly.
OTOH, SpaceX is, at its heart, agile. And the Nancy Grace Roman Space Telescope will be riding an agile SpaceX rocket, not a decidedly non-agile SLS.
Agile is certainly not the ONLY way to write software but I also believe it's the best.
The problem with "properly defining the needs of the software" is that it takes time to write, test, and implement that software and during that time things change.
As an example, Linux deploys incremental release candidates followed by incremental kernel updates. These are driven by individual developer submissions. Currently Linus says 5.20 MAY include Rust. Your strategy would call for requiring Rust and holding 5.20 until Rust was complete.
"OTOH, SpaceX is, at its heart, agile".
Well no, if they were, all those rockets going up that have exploded while testing would have had a payload in them from paying customers.
SLS is a complete cluster fuck because of attempts to save jobs in different states using the same companies by reusing parts from the shuttle that were not fit for the SLS so having to retrofit everything. Doing so as slow and taking as long as possible because it was not a fixed contract price. AKA corruption.
It is, however, become the way for people who can't be arsed to properly define the needs of the software and require multiple iterations to finally think : "yeah, that'll do".
Nope, that's the problem with Waterfall, sit and think and think and think, then realise you've forgotten something far down the line.
Or as more often happens, the wrong people sit and think because they think they know slightly more than they do, then when development happens all the niggles come up, but that's months later and all the people planning are now annoyed because you should've written it by now, especially after the good job they did planning it out.
Itteration and checking at each step is much better.
"Yeah, that'll do" isn't agile, it's lazyness. That can affect any project or team, especially one in the throes of a horrific waterfall monstrosity that just want to get it done.
The Apollo program wasn't built on agile.
And you don't have one that was to compare it against.
Also, it's possibly fair to say that putting a man on the moon for the first time is a farily special case, not really a basis for comparison with the majority of software development.
I'm not saying it's a good fit for everything. Things like Apollo, medical systems, flight control systems are enginnering, both in the hardware and software sense.
most people reading this program, where the risk of serious injury or death doesn't happen.
I'm willing to bet that JWST wasn't built on agile.
What about Starliner?
SpaceX, however, are a big proponent of itterative development, and they've launched more rockets than everyone else combined; significantly reducing costs in the process.
Agile is just the excuse for the majority of people who can't plan properly.
No, agile is the method you use because the majority of people can't plan properly.
When one person does something wrong you train them. When a process, time and time again proves to be unfit for purpose because the majority of people find it difficult, you either berate the people for being not as clever as you, or you accept that the process doesn't work for the majority and use a different one.
We're not talking about Apollo or JWST, we're talking about software, and it's not just the outcome that's important. If I have a torrid time working on a project then I'm more likely to leave or not put in the best of my efforts. If a project has become 'hell' then people will rush it out, that's as much to do with the methodology as the end result it.
. Nope, that's the problem with Waterfall, sit and think and think and think, then realise you've forgotten something far down the line.
No, that is very badly managed waterfall. Even in waterfall projects you should break it down into smaller stages. After all you can't build the walls of a house before the foundations are laid. So oh look - you already had agile.
Agile is just lots of mini-waterfalls, it works better for some things than others i.e. Horses for Courses.
At the end of the day many an agile project has that one, last critical waterfall before you get a working product.
"It is, however, become the way for people who can't be arsed to properly define the needs of the software and require multiple iterations to finally think : "yeah, that'll do"."
That's the cynical viewpoint. The more positive spin is that agile gives you the ability to start developing something based on an initial specification, and to then refine it based on feedback from whoever it is you're developing the product for, rather than assuming (naively based on pretty much every single example throughout history) that anyone is capable of generating a spec which is so utterly complete, correct and visionary that it's able to define exactly what the end product needs to provide.
Part of what makes Agile so damn powerful is that it accepts humans are fallible, and gives us multiple opportunities to catch mistakes early enough so that the amount of work required to fix said mistakes is kept to a minimum. It also improves the relationship between the people tasked with implementing the product and the people for whom the product is being developed, by requring the latter to become an integral part of the whole development process, rather than letting them just dump a spec on you on day one and then having no further contact with the project until the first milestone review however many months in the future that might be.
It also means that, in the event that the product specs need to be changed mid-development due to changes that not even the most prescient of product managers could have forseen, you've got more ability, agility even, to respond to those changes with less disruption.
Yes, it can also be used as a way to hide incompetence and allow development teams to just keep iterating until they get something that works well enough to chuck out the door, but you're doing it a huge disservice if that's all you think it's good for.
"The Apollo program wasn't built on agile."
Neither was it necessarily a shining example of traditional product development done right - if I borrow your cynical hat for a moment, it's not a stretch to suggest that it was overall a success in spite of how it was developed, and had it not been for several examples of on the spot decision making by mission control to get around the problems caused by the way the product (mis)behaved, could well have ended up being regarded as a disaster of a program which consumed even more lives than the 3 it took to prove that the specs for the Command Module hatch design and pad test procedures were fatally flawed...
The problem with "agile" is that the word is now so tainted by charlatans that it's become pure, unadulterated snake oil*.
Every time I hear a manager say "agile" now, I wince. I personally now have only two words to describe it: "considered harmful".
* Ironically, snakes are quite an oily meat and apparently taste like chicken. Bonus: there's only two out of the however many bazillion species of snakes there are in the world whose meat is poisonous, so as long as you're the one doing the biting, you should be safe.
The problem with "agile" is that the word is now so tainted by charlatans that it's become pure, unadulterated snake oil
Ah, that age old problem in computing.
Remember XML, it's a verbose tree structured data format, with namespaces (to allow nesting without clashing) and well defined validation. It's a PITA to read and write manually though, and it's very verbose.
If that sounds like something that's useful to you and the downsides aren't a problem then it's a perfectly acceptable file format.
However for a few years it was basically the solution to everything.
Now, if you suggest using XML in anything modern you'll probably need a flame proof suit, even if it is actually the apropriate solution. (Although to save the replies, if the validation and namespaces aren't useful to you then JSON is the way to go these days. There are also JSON validators too. If bandwith is your enemy then other things exist.)
JSON is now desperately trying to get all XML had - schema validation, query language, etc. etc. because it is also suffering from scope creep - it was designed as a platform-agnostic data interchange text format and now people try to define everything in JSON - which does not even allows comments. But then there is YAML and maybe something else trying to get that spot - but maybe someone will soon try to transmit data in YAML.
These approaches show all that is bad in the actual software development panorama. I call it FaDD - Fashion Driven Development
"However for a few years it was basically the solution to everything."
I remember when I discovered that Novell was using XML for configuration files in Netware 6.5. Why? It's a configuration file - shouldn't the programs relying on a configuration file already pretty much know what to expect in the file? I mean, I can understand not using straight binary config files with internal byte fields that are only specced out in a printed manual somewhere, but XML seemed like way overkill. IMHO, there's nothing fundamentally wrong with text-based key-value files for configration settings. All I could figure was the XML libraries Novell was using made it extremely easy to use XML. Plus it made them seem "hip" and down with the yoof to have XML in Netware.
Not that it helped. Netware still withered and died.
> one of Microsoft's regular restructures would lead to layoffs among Windows' dedicated testers and changes to developer-to-tester ratios<
Agile may work well for a lot of scenarios if implemented properly.
If you start with the expectation it will allow you to put less effort in testing and start with laying off your testers getting agile implemented well is doomed already.
That can mean starting a large project without an end date; ie you have to recognise you may have to spend some budget to determin if a project is viable, or there are a load of gotcha's that you didn't forsee on the way.
The issue for some parts of the organisation is that if you abandon it after six months then they see it as you having wasted that six months. Had they had their way and spent the six months writing the requirements for you to follow (even if they turn out to be impossible) then that money wouldn't have been wasted.
"attempts to deal with all that cruft (most recently via the doomed Windows 10X) have tended to flounder on the requirement to make that one weird app work."
I do wonder just how many of these old and weird apps are written in a way which requires direct access to the underlying hardware (*), and how many of them would merely fail to run on a "clean/current-API-only" version of Windows due to things like changes in the API calls, differences in where user files are stored etc, and from there how many of these "worthy of continued support despite the headaches it causes" apps could then be catered for simply by providing a set of VMs for different versions of Windows - i.e. re-introduce the XP Mode functionality MS offered back in the early days of Windows 7, but extend it to cover enough different versions of Windows (even back to 3.1 etc if needed) that pretty much every legacy app anyone might still want to run on a modern PC could be accommodated without the need to continue compromising the core OS with legacy support cruft.
Wouldn't necessarily even need MS to build this functionality into Windows themselves, all they need to do is provide a set of licence-free/pre-activated OS images for use with VirtualBox etc. so that anyone who needs this level of backward compatibility can set it up for themselves without the need to either still have their own copies of the installation media (assuming they still have access to the necessary reader hardware, and that it's all still in working condition), or to obtain a copy via means which may be not entirely legitimate.
(*) and which haven't already been rendered useless/unable to be run on a newer PC due to changes in the hardware itself - e.g. anything using a dedicated ISA/VLB/MCA (any other legacy formats I've forgotten?) card which can't be connected to anything built in the last couple of decades...
None of them try to access the hardware directly, which is not possible in protected mode, even under Win95 - you need drivers for that.
The problem with many Windows application is not only that old one may need to use old, deprecated APIs, is that many were written as if any version of Windows was 3.1, so they feel free to attempt to write everywhere, read data directly from places they should not (instead of using the proper access API), use API in weird ways, some developers reversed some Windows code and made calls they should not have done, and so on. The Old New Thing blog has many of these madness, and since many of these applications were and are running at very large customers, Microsoft feels it has to keep them running.
"all they need to do is provide a set of licence-free/pre-activated OS images for use with VirtualBox"
Why free and for VirtualBox - they could simply let you download them on your valid Windows copy and run them on Hyper-V, after all...
But still running them separately in VM sometimes it's not always the right choice, especially when they are end-user applications.
With Win95 the 8086 IO port address space was virtualised (using a simple single-user capture virtualisation model). That meant that programs using direct access to hardware still worked over Win95 and Win98.
Win2K did not provide virtualisation of the I/O address space (although it did provide virtualisation of the Video memory address space). Programs that used 'direct' control of hardware have to be re-written to use kernel drivers, using dll function calls instead of CPU instructions.
Windows 95 still uses a VxD to virtualize port access. It uses the IOPM to trap access to **some** ports which are those that can be used - other ports will simply raise the General Fault exception. If you need to access specific ports not in the list of supported ports, you need your own VxD. Same for devices memory mapped to the physical address space.
Writing a VxD is easier that writing an NT family driver. Since VxDs were never supported on the NT line, applications relying on them were never supported.
"Why free and for VirtualBox - they could simply let you download them on your valid Windows copy and run them on Hyper-V, after all...'
Free, because MS don't expect you to pay (at least not financially) for backward compatibility in Windows right now.
For VirtualBox, because I'd completely forgotten about Hyper-V being buried away within the latest versions of Windows already.
The point I was getting at here wasn't about suggesting the use of any specific tools, rather that based on prior experience with XP Mode, I wouldn't necessarily trust MS to want to continue supporting such VM-based compatibility solutions for as long as they ought to, whereas if they just dumped the OS images on a server somewhere, that would give users the ability to set up their own such solutions as and when required.
Why not? Backward compatibility is a feature MS ensures in Windows - and is included in what you pay for. If you read the "Old New Thing" blog, you'll find how many fixes were added in Windows to allow old applications work.
But it looks some people hate Windows just because they have to pay for using it legally, so wish to get free copies in some ways. If you need an OS you don't have to pay for there's Linux for that.
By the way, using old, unsupported versions with known vulnerabilities to run important applications would be quite dangerous and stupid. Freeloaders don't care about security also - but those running company systems do care.
There's hobbyists aplenty, enough for Microsoft to release the Visual Studio Express and Community editions so they wouldn't be tempted over to the Linux camp merely to play with their home computers. And there's leaked Windows source trees aplenty, as well.
If they are going to have to keep supporting truly ancient application software, why not make the support for the ancient MS Windows APIs and OSes, a hobbyist-run thing? Do an official release of the older MS Windows source trees right up to Vista (including the Vistabetion lot) or even including MS Windows 7 under the GPL or the like, make the hobbyists feel wanted, and make their work official.
"make the hobbyists feel wanted,"
Why? They don't make their paying customers feel wanted.
Just razzing you. That's not a bad idea, but could lead to MS losing major face if the "hobbyists" come up with a better version of Windows than Microsoft's paid-programmers did (and the smart money says they would). Not to mention said hobbyists could then start mixing Windows with Linux in extremely un-holy ways that MS wouldn't approve of and couldn't control.
(personally, I've always thought the ideal solution would be to run the Windows GUI on the Linux kernel. But my wife says I'm brain damaged to think such a thing)
And if the hobbyists screw up royally too. Writing an operating system is not for everybody - the Linux kernel is not maintained by a bunch of "hobbyists" and Torvalds is not kind with those who screw up.
Companies relying on Windows would not like to rely on "hobbyists" to run their applications. Many of the companies requiring compatibility and obtaining it are the classic "Fortune 500" ones - which pay and do expect a far different level of support.
"he ideal solution would be to run the Windows GUI on the Linux kernel. "
Sure, what Linux really lacks is a decent GUI - and drivers for a lot of hardware - but there are many features in the Windows kernel that are far more advanced that anything Linux has.
"And if the hobbyists screw up royally too."
Well, if the hobbyists screw up, the project will die but we still won't be any worse off than we are right now. Are all of your glasses half-empty?
"Companies relying on Windows would not like to rely on "hobbyists" to run their applications."
Really? They used to hire them in droves to run their servers. All they needed was a little piece of paper with the letters "MCSE" on it, and they were golden, even if they didn't actually know their ass from their elbow in the server room.
"Many of the companies requiring compatibility and obtaining it are the classic "Fortune 500" ones"
So, that leaves how many million other companies without those requirements, but who could benefit from a better, older version of WIndows?
"but there are many features in the Windows kernel that are far more advanced that anything Linux has."
Other than the proprietary parts of the NTFS and SMB drivers, eh, what? IO scheduling isn't any better as far as I can tell. Memory allocation seems about the same. CPU support is better in Linux. Yeah, no, other than the stuff Microsoft has gradually convinced the industry to bake into the hardware to benefit Microsoft, I'm going to say you're talking out your arse. Linux's kernel is no BSD, but it's at least Windows' equal.
Starting with WindowsXP (technically all versions of NT before it too) the OS enforces a prohibition on direct access to the hardware from software. You MUST go through the OS provided API or your app will not work. I think the only exception are Ring 0 apps like AV software which have a legitimate need to access hardware directly, such as scanning for boot sector viruses.
If you remember back to the early XP days and people complaining about App X (often a game) not working on XP when it worked perfectly on 98/Me, was because it tried to directly access the hardware.
I don't know how much Microsoft is paying those people from PR to come up with such a brilliant and elaborate response but I'm sure they're wasting way too much money on them. Me for instance I could do it for fifty bucks.
Originally when employees were working for a company they were working to build the company, making it larger and more efficient in the future. But these days everyone is only working to bill the company and make more money in the future. Product functionality is irrelevant these days, the only important factor nowadays is more advertising.
This is not just a criticism of Microsoft, I see this happening everywhere. The icon describes Pascal Monett's title, not what's happening ... this is how it goes now.
They've been frantically trying (and failing) to convince the business IT world this year that W11 is fantastic and there are loads of excellent reasons to start rolling it out now. This has, predictably fallen on deaf ears as IT decision-makers aren't going to be taken in by marketing hype. If they are changing the model and there will be a Windows 12 next year or the year after, we will probably now see a dialling-down of the attempts to push W11.
they don't stop the weekly security patch reboots. I've grown accustomed to the weekly half hour forced paid break from work. It's not even a bother to spend another half hour setting back up, nor does The Boss whine about it anymore.
And before anyone says anything about being able to set a time for the updates, our company IT department keeps the computers locked down tighter than a duck's arse. IT works 10AM to 4PM, and sets the time when it won't affect their workday. Those of us in a 24x7 shop just have to deal with it.
Weekly? how bleeding edge are you? We tend to lag a month behind unless there's a "PATCH THIS RIGHT NOW!!!1oneoneone" 13.0 level CVE* that gets announced and is being actively used against us. And while we don't allow users to refuse updates, we do allow them to delay them, because our IT department listens to the users...
*YEs, I know the scale only goes to 10. :P
I wonder if my place has done something similar, only not quite as well. I do get the choice here to select a date/time for the reboot, but strangely if I pick the time furthest ahead (usually 3 days away), Windows tells me I cannot select a date in the past and refuses to accept that selection. It has done this for a couple of months now.
Kind of sums up the quality issue really when it is the 21st of July, I tell my work laptop to reboot on the 24th July and it tells me the date is in the past...
And entirely predictable, given how bloated and monolithic Windows is.
Trying to make its development agile was rather like trying to fit roller skates to a Diplodocus. The beast may move more quickly, but the crashes are bound to be frequent and disastrously damaging.
Let's talk about my own experience.
Even in the early 2000s; people was still using Computers with Windows 3.1 and 3.11. It did help most of those were computers with no Internet access. And that F-Prot was a free and great antivirus for Dos that worked perfectly fine for those machines. There was also Norton Antivirus Scanner that keep getting updates for a ridiculous amount of time for a free virus scanner.
Last time I used Windows 95 in a real machine and not a VM was 2009, then I couldn't anymore cause the machine bios died, then again it was a Compaq from 1995.
I used Windows 98SE on a machine I no longer used online until about twelve years ago.
I usec Windows XP on a laptop until a few years ago. Mostly I used to play old games, unfortunately the video card died so bye bye old Windows Media Center Laptop.
I still keep Windows 7 Pro on a laptop,is all for videogames.
So... changing versions numbers every three years will just fragment Windows usage even more even if most people move to the latest version.
Let's be honest, most developers won't be happy if the changes are as big as Windows 11 is from Windows 10.
Videogame developing is not the only thing that takes longer nowadays. Do you really want to expend many months of coding to make a program that might not work in just two years and a half because there is a new Windows? And if Microsoft keeps the compatibility then isn't the number change mostly a cosmetic lie?
It will just keep developers doing code the old way until the support is finally pulled out.
You know like many still do today.
YAY!
The MacBook Air M2 will be here in a few days.
Windows has become squirrelly as hell in the few years besides morphing into an intense and dedicated mass surveillance app (THOUSANDS of connections, every day).
I am sure MacOs has it's problems, but I tend to trust Apple somewhat more than MS anymore and besides, I kind of like the whole "Apple Family" thing. I mean, who doesn't have at least one iPhone anymore?
https://www.theregister.com/2022/07/19/apple_butterfly_settlement/
https://www.theregister.com/2022/07/21/m2_macbook_air_teardown/
https://www.theregister.com/2022/07/19/apple_pay_lawsuit/
https://www.theregister.com/2022/07/19/apple_hiring_freeze/
> While the CI/CD platforms might be splendid for the odd app or two
No, automated testing is much more important the more complex your system gets, and it scales with the more test combinations there are. Manual testing is fine for the odd app or two - after that, automated testing becomes more and more obviously the right thing to do.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
