Heaps of Windows 10 internal builds, private source code leak online A massive trove of Microsoft's internal Windows operating system builds and chunks of its core source code have leaked online. The data – some 32TB of official and non-public installation images and software blueprints that compress down to 8TB – were uploaded to betaarchive.com, the latest load of files provided just earlier …
This post has been deleted by its author
@kain preacher
Who cares? it is not as if you can use the code to improve anything or to create your own product. maybe this is useful for learning about the innards of windows? Something that has been possible for 20+ years if not more?
No one cares. oh yeah pirates and people who write malware may do.
Nothing to see here, move along.
You completely miss the reason why I say this. I'm for linux, more and more as time wears on. Microsoft has made some really horrible moves of late - did you even see Windows 8? I did, and it was complete garbage. What I am hoping this does is bring us closer to linux getting the driver support it deserves. I could tell you a story about a laptop upgrade to Windows 10 that failed miserably due to a graphics driver, but I digress. The point is, linux needs to unify, not segment, and this event could be the catalyst. I'm just hoping to get the application and driver support in linux that I get in Windows. By far, it is the best news I've gotten this year - one step closer to an unfragmented linux culture.
Hm, yes, I saw Windows 8.... seeing it now, as a matter of fact!
Obviously, it's a disaster as far as OOBE, but so is 10... but 8 (and by that I also mean 8.1 for the purposes of this message) can be made quite nice with things like Classic Shell, Old New Explorer, and Metro Killer in a way that 10 cannot. Metro was largely "tacked on" the outside of a Win32 core, and it's relatively easy to wall it off and live completely in the Win32 part. With MS removing more and more Win32 functionality and adding it to UWP, you can't do that on Windows 10.
Once all the de-dumbification of Windows 8 is done, you get an OS that allows the user control over updates, doesn't spy on you (same caveats as with Windows 7 about those telemetry updates MS pushed out), doesn't have advertising in it, doesn't uninstall your stuff without permission, doesn't install Candy Crush or other apps without your permission, doesn't change your drivers without permission, doesn't nag you endlessly to use their crappy Edge browser... things that we used to take for granted as being baseline-level expectations for OS behavior are now "features."
The best part of 8 is that it gets security updates for six more years. That's a very long time in computing, of course. By then, Windows as we know it may not even exist... or maybe MS will have seen the light and given us something that doesn't try to be a crappy phone and a PC at the same time. Whatever the outcome, that's six more years that a Windows user gets without being subjected to Windows 10.
Six years is more than enough time for the irrational exuberance over Satya Nadella's inane vision and how "innovative" Microsoft is now to come crashing back to reality (including their stock prices). As long as the stocks are up, they're not going to change direction, but everything about the current stock prices of MSFT screams "bubble." It's a lot of sizzle and not a lot of steak.
How would any of the Windows source code give sensible users the OS they actually want?
You are too sensible for these parts. Begone!
Does the leak include versioned file? Much fun can be had in checking coding hotspots.
"can we get at the bits of code that do the telemetry and forced updates and REMOVE THE F*****G THINGS"
Instructions on how to stop forced updates and hack out the other nasty bits are all over the webernet. You could have had the system running the way you like it at any time.
No one on this thread is "we users!" You folks are all a bunch of computer geeks who hate Microsoft and have zero bearing on any reality other than your own. Few people in the world want a stripped down OS that doesn't update drivers, software and security. Reading your posts is my tech comedy hour.
Few people in the world want a stripped down OS that doesn't update drivers, software and security
Actually, most people in the world hate updates. They slow the system down (on Windows, seldom noticeable on Linux), most people get along well with their existing drivers, same for their existing software (especially when said update means learning how to do things again, or features they use being removed), and most only "care" about security because of those who do their darndest to make them see sense.
Besides, the only "security" updates from MS in recent years have been the ones that break the networking or brick the machine so it can't get online. All the rest is just their usual bug-ridden filth.
Few people in the world want a stripped down OS that doesn't update drivers, software and security.
Duh. it's not about NOT updating stuff, it's about having control of the updating instead of it being MS who just forces out updates as if PCs were XBoxes (which I have no problem with getting 'auto' updated due to the limited uses such gaming consoles are used for). PCs are tools of the trade and need to remain functionally capable of what the user needs them to do and without loads of adverts getting in the way. Had MS created a suitable, stable, secure version of Win 10 for small business and professional users (who all have confidential stuff to deal with in the shape of their business accounts) then this problem would simply go away.
It already exists, since Anniversary Update. Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to 1, reboot system.
Microsoft's been trying to get that added for years. Every time they try it, they get tons of reports from enterprise customers that it breaks <insert-important-and-private-internal-app-here>.
It already exists, since Anniversary Update. Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to 1, reboot system.
So.. You have to futz around with the registry to get something that should've been there by default at least 20 years ago?
Microsoft's been trying to get that added for years. Every time they try it, they get tons of reports from enterprise customers that it breaks <insert-important-and-private-internal-app-here>.
Yet other systems have had it a lot longer, without said issues...
I pretty obviously wasn't talking about hardware compatibility.
Linux devs change APIs with great regularity without any concern for backwards compatibility, and that's a pretty well-known thing. I can run ten year old binaries on Windows without issue now; on Linux, you're lucky if you can do that with binaries a third of the age. Don't let your Linux fanboyism blind you to the deficiencies of Linux; the problems it has can't be overcome by pretending they do not exist. There's little hope for Windows, but Linux at least can evolve in the right direction (and generally it is, if slowly).
In Linux, the typical dev attitude is that since the source code is available for the program in question, it doesn't matter if the APIs change, just recompile it with whatever is the newest version of gcc, Xorg, what have you (often systemd, to the chagrin of many). That's great if you're the kind of person who can recompile things at will and if the program in question is actually open source, but those two things are not always going to be true, particularly if Linux is ever going to exist in significant numbers on the desktop. It certainly doesn't work with things like proprietary video drivers from AMD and nVidia, with their binary blobs that prevent drivers a few years old from working with recent distros. A lot of older GPUs don't have Linux drivers newer than that, so you either run the open source driver (often slow and lacking in features, including power management on laptops) or use a distro release that's several years old.
The idea that requiring users to recompile their programs 'cause we done just broke all the APIs again isn't compatible with the way regular people use computers. As a niche hobbyist OS, that kind of thing is fine, but if the idea is to compete with Microsoft head to head on the desktop, it's not going to fly. Linux is going to have to work with closed-source precompiled binaries if they want to get any traction on the desktop. Precompiled binaries that people have to pay for means they are going to want to keep using them for years; no one wants to pay hundreds of dollars for a program (precompiled binary, as is the norm with closed-source) only to have it go out of date in six months because the APIs it relies on have changed because reasons.
Linux devs change APIs with great regularity without any concern for backwards compatibility, and that's a pretty well-known thing. I can run ten year old binaries on Windows without issue now; on Linux, you're lucky if you can do that with binaries a third of the age
That's the best part of your post. It's utter crap, and the rest descended quickly into something even worse, not worth reading further. And I seldom find a post so rubbish I stop reading.
Considering the number of articles on here in recent times about MS updates killing software because incompatible, the posts from coders about how much MS changes the goalposts (one in this very thread) - at least some of whom work for well known programming firms, and the general cries for help the web over about stuff that doesn't work anymore since the user updated Windows, and the great many articles and posts about people stuck with XP because they cannot run a more modern version of Windows again due to significant changes in the way things are handled, well you'll see your post for what it is. 2 words, one being the male form of bovine and the other being what the neighbours dog left on the back lawn.
As to that "recompile" bullshit you post.. Last time I compiled software on Linux, it was a program I was writing (in Pascal) to fix a problem in Windows (something went and added a number in brackets to ever filename in a folder, eg winlogon.exe became winlogon(25446).exe ). I don't know when I last compiled something for Linux but it can't have been since 2007. I do believe I've done it but not sure what or why. (ftr I just caught the phrase out of the corner of my eye, couldn't be bothered reading more becuase it's 1990's MS shill lies)
Icon - what should be done to MS HW, while they're have a party for all their fanbois.
> Developers of other systems don't concern themselves with backwards compatibility as much.
HP-UX had this issue before Windows was an OS. It simply made it a mount option and long filenames quickly became the default, but the option of limiting filename lengths existed for customers who suffered from old applications which didn't handle them.
Linux does not have binary compatibility as a design goal. You might be expected to recompile software from time to time, and even edit Source Code in extreme cases (such as when a library function goes from "deprecated" to "removed"). Distributors will do all this for you, of course; and package management software will deal with multiple things having to be changed at once.
The alternative is to leave dangerous subsystems in place, just so old software will still work without being tweaked to suit a more modern OS, but which then leave the OS vulnerable to malware .....
"Yet other systems have had it a lot longer, without said issues..."
These other systems have issues of their own. For one thing, they almost certainly don't run <insert-important-and-private-internal-app-here>. If that's not important to you, go ahead and run other systems, but you can hardly blame Microsoft for supporting their existing customers.
Actually the registry hack isn't safe. For 25 years, MS have promised developers that a 260-character buffer will be able to accomodate an arbitrary path. If you quietly raise that limit, all that happens is that end-users suddenly find that the filename they type is not the one that actually gets used by the program. At best, that's a bug. At worst, it is a security hole.
As an alternative to the registry hack, where developers have taken the trouble to support longer paths safely they can advertise that in the program's manifest. Users will then get the benefit where it is safe and be protected with legacy behaviour where it would not be safe. (Please note, however, that if your program uses a standard file open or file save dialog, you are potentially hosting arbitrary Explorer extensions, so you can't honestly write that manifest entry.)
And on a completely different tangent, 260 characters is over three lines of text. If your paths are longer than this paragraph, I'd say you were using the filename to write a short abstract of the document contents, which is an abuse of the metadata.
"Yet other systems have had it a lot longer, without said issues..."These other systems have issues of their own. For one thing, they almost certainly don't run <insert-important-and-private-internal-app-here>. If that's not important to you, go ahead and run other systems, but you can hardly blame Microsoft for supporting their existing customers.
Actually they will. I have a number of <insert-important-and-private-internal-app-here> on my systems, usually small scripts to automate jobs I'm to lazy to do via typing a couple of command lines or things where I'd rather not have to remember/look up what I am supposed to be doing again. And I don't do Windows. Well not very often anyway.
Actually the registry hack isn't safe. For 25 years, MS have promised developers that a 260-character buffer will be able to accomodate an arbitrary path. If you quietly raise that limit, all that happens is that end-users suddenly find that the filename they type is not the one that actually gets used by the program. At best, that's a bug. At worst, it is a security hole.
I've had to clean that mess up often. I've seen something break with Windows where you get some recursive paths, which very quickly pass that tiny 260 char limit1. I've seen AMD drivers seem to do this a bit (or at least the AMD driver files/paths get messed up, not necessarily their fault, but they do have lots of little files (and I mean lots!) with long names in paths with long names). If you're lucky you can fix them by renaming some of the folders to single character names, once that's done you can delete the messed up folders. Otherwise you need to do something else to get the problem fixed. The only MS tool that can fix that issue is format2, but you can go in with Linux and delete the offending path without issue.
1 You're right. You can get a fair bit in 260 chars
2 Actually I never thought to try power shell when I came across those situations. Was quicker and easier3 to boot into Linux, delete the offending path, and reboot into Windows
3 From experience of course, could take longer to learn Windows power shell commands than it would just to use a familiar Linux GUI :)
- I was not talking about Windows apps in general, but the File Explorer application that ships with Windows.
- Applications written for other OSes commonly make files with paths that exceed 260 chars, why should Windows users be unable to handle those files ?
e.g. https://stackoverflow.com/questions/37880447/file-path-too-long-on-windows
- I have not heard a file's path called its "Metadata" before.
"- I was not talking about Windows apps in general, but the File Explorer application that ships with Windows."
That would be the file explorer that has always supported third party extensions, written by people who read the docs and therefore know that a 260-character buffer is safe.
"- Applications written for other OSes commonly make files with paths that exceed 260 chars, why should Windows users be unable to handle those files ?"
Because Windows documentation has, for 25 years, consistently stated that a 260-character buffer is the maximum that you need to support, even if weird hacks are available to let you manipulate files created by other sub-systems.
"- I have not heard a file's path called its "Metadata" before."
Meh. It seems like a perfectly reasonable use of the term to me. It isn't part of the file's data, but is nevertheless *about* the files data. Would you have been happier if I'd followed the NTFS documentation and called it an attribute?
"I wouldn't call it metadata because it doesn't tell you anything about the data."
The original post about using an overly-long path was alluding to using the path to describe the data. For example, I had a user once trying to restore a file with a path something like this:
C:\Users\User Name\Documents\Meeting Minutes\Biggest Project Ever - Never Delete This Data - EVER\Project Scope Meeting With Bob Bill Jonathan Matthew and Jessica\Meetings in 2017\Meetings in March\Meetings on the 19th\Meeting where we discussed the Project Scope with Everyone and Jessica too\Part of meeting where Angela was there\Minutes.doc
THAT is including metadata in the path name. And no, the restore would not work to the original location (yet somehow the file had been created and backed up) while a restore to C:\Users\User Name\Documents worked great.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
