Makes sense. XP was released in 2002 and took years of work before the release.
A good chunk of languages we take for granted today did not exist at that time, or were in the very first release. Perl came out in 1987, it was quite the thing in the late 90s.
Indeed. There is an episode of the sitcom Frasier (set in Seattle) featuring Bill Gates, that aired in Nov 2001. Gates appears on Frasier's call-in radio show, but all the calls end up being tech support related. Gates comments on whether Windows XP needs a boot disk or not.
Yes it makes sense from a technical standpoint but I was amused by this fact because Microsoft is supposed to be a vendor of programming languages and operating systems. And to build their own OS they go to the world of open source.
So it's a neat confirmation of the power of open source over proprietary software.
Not really. I created and maintained a Linux distribution, and while Perl was sometimes used it was almost never strictly required (i.e., it was for documentation or something that really would have been better if the release maintainer had already generated....). This covers a few hundred packages, like gcc, binutils, glibc, linux, core-utils, util-linux, flex, ...
Notable, also, is that I didn't compile perl for my Linux distribution because perl's configuration system is terrible (there's an out-of-tree patch to make it less terrible, though).
Probably beats python and the continuous version idiocy - Python 2 vs Python 3, 3.7 vs 3.9 &c, p.p. If you have throwaway scripts in a startup, fine, but unacceptable when you are maintaining an OS that all the world relies on. You wonder - what does Dr Hipp use for sqlite? Never looked into that build system!
Perl has its own version naming problem. But there's no reason to think it would be any more stable or secure than Python, which is in the critical path of all sorts of things (not just "throwaway scripts in a startup").
If you're referring to Perl 6 versus Perl 5: that problem has been fixed by renaming Perl 6 to Raku (https://raku.org using the #rakulang tag on social media).
According to the Linux kernel documentation: "You will need perl 5 and the following modules: Getopt::Long, Getopt::Std, File::Basename, and File::Find to build the kernel."
I’ve never understood this type of “gotcha!” that always gets trotted out when a company uses another company’s product to develop their own.
If all of the debugging, testing and factory management tools are standardized on Windows - why rewrite them if you don’t need to? It seems like a waste of resources.
(This isn’t limited to Apple or even technology companies. It applies to tons of businesses.)
What else are you going to use? Batch? Python certainly hadn't caught on yet in the late 90's when XP was being written.
In 2013 when I was interning for a company making an audio driver for Windows, we used Perl to run our builds. While I hate Perl, it does make it real easy to run an executable and analyze its output.
At this point, a "free to use" license for XP or better yet win2k up to win7, would be worth it for m$ for the PR and goodwill.
"you can get it if you want it" is just lame.
m$ should, ideally, bite the bullet and do a (stripped if need be) source release of what they can, explain what they can't release. Everyone will then benefit from the relief from worry and lack of friction things like emulation and software archeology and etc will gain.
You can, but it's your problem if you don't stringently configure SELinux and have clear policies for yourself. If you use Linux like Windows thinking it's more secure, and run everything with 'sudo' "Just to make sure it doesn't crash or pop an annoying prompt.", you're worse off.
They should release software with known security problems, that they have said they won't be fixing? Please no... Botnets are large enough as-is.
Plus a lot of people under-estimate the cost and difficulty in releasing the source code of previously proprietary software. You don't just slap it onto Github and everyone goes home, you often need a team of lawyers to look at third party licensing and go through the code file by file looking for potential liabilities.
Code that started out open source software has to narrow third parties to only specific licenses/waivers. Code that has for tens of years been closed source may contain licensed source code (e.g. decoder libraries) that they don't own the license to publish for just one example.
>They should release software with known security problems, that they have said they won't be fixing? Please no... Botnets are large enough as-is.
The source code has already been leaked, and I would bet that malware authors have no problem with acquiring it illegally. While security researchers working within the law may not be able to look at it at all. The current situation does a lot more to help botnets than it does to help honest customers.
>Plus a lot of people under-estimate the cost and difficulty in releasing the source code of previously proprietary software. You don't just slap it onto Github and everyone goes home, you often need a team of lawyers to look at third party licensing and go through the code file by file looking for potential liabilities. [...] Code that has for tens of years been closed source may contain licensed source code (e.g. decoder libraries) that they don't own the license to publish for just one example.
I'm sorry, I just have no sympathy for the trillion dollar company that trapped themselves in restrictive license agreements and then wants to cheap out on lawyers. It is entirely a problem of their own making, and I would expect them to pay to fix it.
The issue isn't malware authors acquiring it the source, the issue is that other people would then build said source and run it (XP) or worse, build products on it as XP was very stable. Those systems would then get infected and become botnets.
You don't see people flying in trijets anymore as they are dangerous, likewise you don't want to encourage or incentivize people to use or build products on an insecure OS.
Sympathy doesn't matter in the business world, costs do. No normal company is going to undertake a legal review of an unsupported product; it simply isn't worth it.
I'd never heard of trijets being dangerous before and I can't find anything to support that claim. I thought the issue with them was the expenses around building and maintaining them.
There are documented cases where failure of the central engine has caused a loss of the rear stabilizer. This can be resolved via additional engineering -> which increases cost of manufacturing and maintenance (which as you note was the main factor in why they went away).
>The issue isn't malware authors acquiring it the source, the issue is that other people would then build said source and run it (XP) or worse, build products on it as XP was very stable. Those systems would then get infected and become botnets.
I don't follow where you're going with this. Why would they build the source or build products on it if they were not interested in deploying security fixes? There is no other developer interest there and no company would ship a white-labeled "XP 2020 Edition" to developers if it was instantly vulnerable to malware.
>Sympathy doesn't matter in the business world, costs do. No normal company is going to undertake a legal review of an unsupported product; it simply isn't worth it.
Right, that's why I don't buy these lines about how they can't afford it. If it becomes a serious security issue that causes them problems then it is worth it.
From reading your comment, you appear to think that I am assuming someone would ship XP to developers, that is not the case and I apologize if I wasn't clear. I am assuming someone would use XP in a product that would be shipped to consumers.
Companies have and will ship products with outdated or unsupported OS if they think they can harden them acceptably. See all the networking devices that run some variant of the Linux 2.x kernel that still appear on the market today as an example.
Embedded XP was also a thing and probably still is in many places.
Even if somehow the leaked XP code were legitimized, it wouldn't do anybody much good since the driver model has changed significantly since XP and none of the hardware OEMs are going to go back to producing XP compatible drivers again.
no, my grudge against them goes back to the days of 16bit and their kneecapping DOS era comms software. its only childish for so long, then its "quirky"
MS outsourced/bought a lot of stuff so they may not have a clear line of release it without a bunch of legal work. Something like that can be done I am sure. But the cost would be decently high.
Also some interesting portions of the OS are under a 'view but do not touch' license already. Such as MFC, ATL, and the CRT and others. Depending on which SDK or Visual C++ you grab you can get whole examples of interesting bits of the code. I know for example one of the fun ones is the pipes screen saver code is an example in one of the Visual C++ disks (5.0 I think). I recompiled it years ago to make every joint a teapot and the hard one to find was the bend.
I was under the impression that at least the CRT part was fine to modify. At least, Firefox used to ship a custom version with jemalloc, I think (with the necessary patches checked in as ed scripts so that they could avoid having the original source in the repository).
That may be true. I would have to go back and re-read the licence. In practice I do not think they minded too much so long as you were not claiming it as your own and were just changing it for your program only and not overwriting the ones in the system32 dir.
Why wouldn't they just release Windows 10 instead? They don't "need" the money (because any self-respecting IT department that has a modicum of budget will pay for Microsoft 365, where they almost give away the Windows licenses and support, or have a SA license), so the only people still really buying Windows are home users with their laptops. Enthusiasts could maybe submit pull requests, and they could get rid of even more in-house dev/QA staff. It's the latest version of the kernel, so new drivers work. And they are still patching it.
or in support contracts more accurately, which would disappear if others would bring ability to support those (by access to same source code and ability to fix bugs)
ReactOS has always taken a "we will rebuild anything from complete ignorance of the source" approach, precisely because of the legal liabilities. They are so good at it though, that people at Microsoft have actually claimed that the developers must have source code access.
Wait, pardon my ignorance, but isn't a decompiler required for the kind of work they do at react?
Person A's Job:
- Decompile shit.
- Then write down the names of the functions with (1) input, (2) output, (3) a description of what person a think the code is doing (4) any side effect / preconditions / post conditions they can deduce.
Person B's Job:
- Take the spec created by person A and write code.
while(missingFunctionality.hasNext): goto Person A's Job
It is and the split between person A doing the first part and person B doing the second part is important in a "clean room" reimplementation in the US.
You don't have to use a clean room methodology. Decompiling the code and reimplementing the functionality is a perfectly valid approach in any jurisdiction that permits reverse engineering.
Same as Wine: none, since they are required to be 100% black-box reimplementations. No one who contributes to Wine is allowed to even look at the original Microsoft source code.
While I haven't seen such a case, I can imagine a mailing list 'leaking' with posts like "like the trick Windows did for fast_malloc()" and such, then being summoned.
Are you talking about "3D Pinball"? Looking around it seems to be available for later versions of Windows (but I didn't look into the details of whether it's a port or something else).
It was developed by Cinematronics. These guys then had a deal with Microsoft to include Pinball (it was called as 'Space Cadet') for exposure. Later Cinematronics acquired by Maxis.
> Cinematronics was founded by David Stafford, Mike Sandige and I in 1994, and Space Cadet was our first published game
> The deal David did with Microsoft was non-exclusive. As Danny noted, we were more interested in the exposure and didn't see much revenue from it. However, it did lead to our relationship and eventual acquisition by Maxis.
"Bring out your XP CD, copy PINBALL.* from it, and EXPAND the files (yes, you will have to either guess the correct extensions or hunt through installation files, but it's not rocket science)."
Whoa. I thought when that was leaked, that there would be no way it would be able to compile or, well, run without Microsoft's extensive and extremely complicated build setup. What an accomplishment.
I believe Microsoft's internal build toolchain was part of the leak. Looks like the particular tool used wasn't part of the centralized CI system, but rather one intended to be used to time how long builds take (guessing: intended to be run on the developer's workstation as a pre-checkin checklist step, in order to avoid committing code that bloats CI build-time?)
Heh, nope, `timebuild.pl` is the canonical entrypoint for an "official" Windows build, and has been for a very long time. It's a hideously elaborate dependency resolver and task runner that is responsible for tying together all the various build steps necessary to create an installable OS.
In order to perform these operations, execute the following command from within a razzle window, whose current directory is %sdxroot%.
· perl tools\timebuild.pl
That job description is strange to me–how could they ask for experience with an internal tool? Is it just a filtering mechanism to hire ex-Microsoft employees? This seems like an Apple job posting asking for experience with XBS, or an Amazon one asking for Brazil familiarity–unless this has been published in some form to the public, like Google and Facebook have done?
> #gamingjobs
Heh. Someone needs to tell Microsoft recruiting to dial back the "fellow kids" :P
Most large companies, for various legal, policy, and compliance reasons, require job requisitions to be posted externally in order to be posted for internal hiring and vice versa. This job listing is probably intended to make an internal hire.
the company and the hiring manager are interchangeable here and it's a lot easier to make sense of this if you know that it's basically one person making this decision instead of some nondescript black box grinding gears.
Because some middle manager is likely filling out a web form with zero regard for accuracy because it's just a formality they already have someone in mind and HR is gonna bin all the resumes anyway.
They do it if there is a candidate(s) internally they want to hire, but HR requires (either because of laws or internal policy) that they also look for outside candidates. The outsiders won't pass the screening because they don't have experience with the required tool, and the team gets to hire the person they wanted anyway.
How would this comply with the law if an external candidate would have no chance to pass anyway (due to work experience required with an internal tool not available to the public)?
Wouldn't posting a job that an external candidate has no chance of obtaining still violate the intent of that law?
There can be external candidates with that qualification. In general the standard is “Bona Fide occupational qualification” which means that you have a legitimate reason for the requirement. For a college hire this would likely not suffice ... you can teach a college hire what they need to know. For the engineering director running the project it very well might be.
That's exactly what it is. I worked at IBM many moons ago, and at one point was asked to create a list of job requirements that would ensure I was provably the only person in the world who met the constraints. Big companies are weird, man.
It's also how procurement works in the public sector. Either of their own, or with a help of an external consultant, public sector workers will create a set of requirements that are tailored to fit a particular desired supplier, with a bunch of extra bullshit requirements thrown in so that technically allows other competitors, and doesn't look obviously illegal.
Probably ActiveState.[1] Microsoft had surprisingly good support for Perl back in the day, and I remember running into knowledge base articles or documentation that had Perl snippets in examples of how to automate some things.
...which bears a striking resemblance — both back then and to this day — with the root-level categories that divide up the features in the "Add or Remove Windows Features" chooser in the Control Panel.
I guess those root-level categories in the chooser (which were always pretty meaningless) turn out to represent which particular Microsoft source repo the component's code can be found in.
As a wild guess, the "Add or Remove Windows Features" chooser is the way it is, because it's the runtime representation of what's actually mostly a build-time feature selection system; where disabling a component at build time speeds up your build, at the cost of that component being forcibly greyed out in the "Add or Remove Windows Features" chooser for that build. Basically the same as disabling the building of a kernel module in a Linux modular build.
As Raymond Chen would say, "it makes sense with kernel-tinted glasses."
1. Windows developers did not build large parts of the product on any regular basis. Windows took ~18 hours to build on incredibly powerful build lab hardware -- as soon as it took longer, it was time to buy a new build lab. Incremental rebuilds were notoriously flaky, at least in the days before https://github.com/microsoft/BuildXL. The most common dev loop that I saw was to install a recent dogfood build (so APIs and binary interfaces were reasonably recent) and then repeatedly rebuild and clobber binaries on that install.
2. The only real build-configuration options for timebuild were architecture and compile mode (dbg, chk, fre, opt). There wasn't an option to build or not build parts of the tree.
3. raymondc's reference to "kernel-colored glasses" is about viewing things from the kernel side of API guarantees. This is more an applied lesson in Conway's Law.
Re: the second point, I wasn't hypothesizing passing a runtime option to timebuild, but rather running a build against a local "root enlistment directory" that has the Base and Windows depots synced, but not necessarily all the depots for the other components.
I suppose this wouldn't have resulted in an installable release, though. (At least on its own. I guess the populatefromvbl.pl script described in the memo is there to bodge a partial clean build of individual components, together with "the rest of Windows" from some parent release, to form a test build?)
oh god, flashbacks. when I joined Azure Fabric we'd inherited Razzle and all its arcane passes. I still have no idea why; we weren't part of Windows except in name back then.
also, what a strange email to be public. not that it's a hot secret, but who cares about sdx outside of MS 10 years ago?
I've said for a long time that if you could snap your fingers and delete all Perl code in the world the lights would turn off. I didn't realize Windows builds would also cease.
I thought that by the time Windows XP was under development Microsoft had migrated to Perforce and individual dev teams were running their own full Windows builds.
I have nothing to do with ReactOS, but I've heard this allegation made many times on HN, but I have yet to see anyone point to a hard example. Some of the allegations relate to symbol names, but Microsoft has leaked private symbol names in the past[1].
So just because some internal symbols have been leaked (or even have been published by MS in symbols tables) you can copy them legally ? But somehow you can't copy the source code ? But however you can copy a hand (or tool assisted) disassembly and even copy the symbols on top of that ??? Why ? What kind of crazy interpretation of copyright law is that ? (And this is tremendously clear at least something like that has been done for some key parts, and some of the people even told the world they believe this was OK because they did it basically like that...). And oh, maybe in some jurisdiction you actually can, but I would like to have the list. And in the US, especially after Oracle vs. Google I would be astonished to learn that this is actually legal, and I would actually already have been astonished to learn this is legal even before Oracle vs. Google.
Win 2k and NT4 sources have had a very very wide circulation for a long time. Probably there was no source copy directly at source level because they magically audited their codebase, somehow, and told us that this did not happen, BUT it at least means that it's easy for anybody not wanting to take the handwaving at face value to directly do a comparison themselves. And no magical process is going to produce virtually the same functions, including the internals, suddenly not a copyright violation, because of some random wishful thinking about how if you copy with some crazy extra steps and a cute little magical dance in the middle it becomes suddenly ok in the eye of the law. Maybe that idea would make lawyers laugh hysterically while randomly saying "AFC test", but I'm not it would have any other effect.
Just take the two trees and diff key functions and see by yourself. There is no way to justify it can't be reimplemented differently to implement even the same specification. Would MS want to destroy that project, I believe they would be able to do it, effortlessly, in a court. But I suspect it is not worth the potential PR backslash given how the narrative is already set that it is "clean", and the high number of free software enthusiasts believing it blindly for years without even checking by themselves.
Copyright has a creativity threshold, symbols might easily not pass it, they are only unique, and creations that are merely unique, are not copyrightable.
Back in the day, IBM published technical documentation (and assembly source? It's been a while) on the 5150 Personal Computer BIOS. The first PC clone BIOSes were created by having a team re-document how the BIOS worked from IBM's docs, and then having an entirely separate team create new code from that documentation.
How useful would this technique be to the ReactOS and Wine teams? Are there things that they don't know how to make work correctly that this source leak could help them with?
They are doing this (clean room implementation) right now, and very-very-very thoroughly trying to avoid coming in contact with source code leaks in any shape or form: https://reactos.org/wiki/Audit
They were called red books ;) i loved reading through them even though i didn't know assembly and often the content was waaaaaaaay over my fragile little mind.
someone please correct me if i'm wrong cause i'm going off of what i was told decades ago.
in reverse engineering there has to be an intermediate person. in other words, someone could read the source code and the documentation, however they CANNOT actually do the programming. They must write, IN THEIR OWN WORDS, steps and designs for the implementation of the feature and give it to someone else who then interprets and does the actual implementation. this is to ensure that anyone who question how the feature was implemented, they have documentation showing the steps and design of the feature.
again... i don't know what the laws and procedures are today as i'm going off of what i was told, so please someone correct me if i'm wrong.
Michael MJD has a video on Escargot, which hosts a server instance that knows how to talk to clients using the MSN protocol (official clients need to be modified, however, so connection attempts don't go to the now defunct servers): https://youtu.be/yrvNyvFwCJg
> official clients need to be modified, however, so connection attempts don't go to the now defunct servers
Presuming they don't use any form of encryption (and I think that's a safe assumption for that era), one could keep the clients official, while routing the packets themselves using a virtual Ethernet driver (or via software-defined routing, if the relevant copy of Windows is running in a VM.)
I set up a local Escargot server for chatting with homestay family kids aged 6 and 9 (too young for having their own email accounts).
They had a LOT of fun with the fonts and animations, dancing pigs and that kind of thing.
The trouble is, Escargot is a real pain to set up. Certificates need to be patched into the hosts file every 30 days. The server must run on Windows 7 x64. The Windows XP client never worked for me; only on Windows 7 x32 and Windows 10.
If I were able to run an Escargot server from my MacBook Pro, that would make it a whole lot more fun. In practice it takes me hours just to set it up, while they'd rather be playing.
Having extensively used MSN in the early 2000s, I bang my head every time I use Skype at work.
How could they make such a terrible IM app after having made MSN? I just don't get it.
Fun fact about the zoom in old mspaint: It gave you the options for 1x, 2x, 6x, and 8x zoom. But if you clicked one of the pixels directly below 8x you get a hidden 10x zoom.
The majority of that torrent was junk -- something like 20 GB of Microsoft's (freely available) patents downloaded from the USPTO, a couple of DVD rips of documentaries tangentially related to Microsoft (like Revolution OS), and a bunch of wacky conspiracy videos downloaded from YouTube (Bill Gates 5G nanoprobe vaccines, etc).
All of the actual content was available elsewhere as much smaller downloads. In particular, the Windows 2000 and XP leaks are distributed as a single 3 GB archive ("nt5src.7z").
XP compiled but would not run due to missing programs. Server 2003 would run because it's source was complete. Am wondering now if the XP code could be made to run by using parts of the Server 2003 code.
Seems likely. Someone who has seen the actual source would have to confirm, but my understanding from back in “the day” was that Server 2003 was based on the XP SP0 tree, but that XP SP2 and later were re-based on the Server 2003 tree as part of the security focus of SP2.
Windows XP 64 bit edition was based on Server 2003, as it was released after it. You can even say it was 64 bit, client edition of server 2003.
Windows XP service packs were based on, well, Windows XP. Because that's what service packs were. Lot s of new features have been developed for SP2 (and possibly some backporting from 2003 happened, too) but XP is still XP.
Actually, only somewhat. One of the "tricks" to get the whole thing to build was to replace some of the missing files with production, already-compiled versions from Windows.
Thus, even though a few files are missing, you just need to include the few official missing ones, and the thing boots.
If it was ever put on GitHub, Microsoft would take it down instantly. I don't think anyone would get away with filing a PR.
At the same time though, that would be hilarious. Someone is going to do it just so they can claim that they were the first person unauthorized by Microsoft to ever file a PR on Windows...
The Russian government compromised Microsoft in early 2000 and the source code for windows 2K XP and 2003 were all leaked on usenet over a decade ago. Why is this news?
Because the more general public (for a certain degree of generality) apparently didn't know about this until this week. Usenet is now seen mostly as a device for good ol' piracy.
Probably because it's now marginally less likely that MS will pursue any hobbyist attempt to work with the codebase, considering all those versions are long dead.
Now's your chance everybody: Someone has uploaded the source code to GitHub, no torrent needed now. If you want to be the first unauthorized person to ever file a PR against Windows, you have the opportunity.
I've heard for years that it was floating around, and saw some torrents that claimed to be the XP source, but I've never downloaded it myself to find out.
I also remember Windows source code leaking in the early 2000s. I even downloaded it myself back then but that was many computers ago.
And afaik it was not buildable. It was a large chunk of the source code that iirc had leaked from a 3rd party who was tasked with making some component, perhaps related to the image library.
The kernel source code (NTOS) was available for years through an academic program[1], it was easily findable on emule/edonkey/torrent. IIRC, the implementation of NTFS was not included. This leak is the full source code of Windows XP, both kernel and userland (+50 Gigabytes).
Anyone else think the smartest move for microsoft here is to leave it up, unless another copyright holder complains?
Not only has XP been sunset many times, many years ago, it might finally have all of its bugs picked clean and unofficial patches made to shore up any systems too embedded to move off XP still.
Conspiracy theory time: Microsoft intentionally leaked this code so they can gear up to fully open sourcing all of Windows and crowd sourcing its development and bug fixing.
It makes sense, I don't think MS cares about Windows anymore in the azure/O365 era.
It makes sense, they have very little to lose other than the glarimg issue that even with a non-free license it would inevitably end up being used to run Office on Linux via syscall or full emulation.
Maybe they're testing the waters? Perhaps there's a political problem with open-sourcing a current product that nearly every company has sunk a sizeable amount of revenue into?
Yes it is totally outlandish. This was leaked, not open sourced. No one is going to seriously contribute to a project that can't be legally distributed.
It's probably not all that useful for that, to be honest. People building this are setting their clocks to sometime 2003 because something in the process is timebombed (including the resulting build). SP3 was 2008. Support officially ended 2014. Patches for wannacry snuck out in 2017 & 2019.
So if people want to take this tree as a base to start releasing unofficial patches, they have 16 years of work to catch-up on just to reach parity.
Possibly, yeah. But I think they'd benefit more from the official updates.
I'm not trying to argue that unofficial patches would be a bad thing. I just don't think a source tree from 2003 is a good place to start. Any binary you build off this codebase will be missing 16 years of microsoft's patches. Until such a project caught up with all the changes made 2003-2019, any binary you build off this is likely to cause more harm than good (eg, you fix one issue, and reintroduce every issue that was fixed after 2003.)
The idea's good. This sourcetree isn't. Let's just say 2003 was not XP's golden age. If this was at least SP3 onwards, but preferably 2014+, sure. But it's not, it's SP1.
It's possible as long as Microsoft removes all code commissioned by third parties, rewrites all copyright and trademark statements and explicitly licenses the very release that got leaked. Anything else could be seen as non-action in case of a software leak which could lead to very unfortunate results in any lawsuits that come up.
That's a lot of work for what is essentially a gross intellectual property violation as well as a leak of trade secrets.
Tk protect your trademark, you absolutely must go after trademark violations. Any build labeled "Windows" that results from this source code must be taken down if Microsoft wants to keep the trademark on things like "Windows".
270 comments
[ 3.4 ms ] story [ 250 ms ] threadI hope your company firewall does not block YouTube.
A good chunk of languages we take for granted today did not exist at that time, or were in the very first release. Perl came out in 1987, it was quite the thing in the late 90s.
2001, actually.
https://www.youtube.com/watch?v=gpRiDl48ERA
So it's a neat confirmation of the power of open source over proprietary software.
Notable, also, is that I didn't compile perl for my Linux distribution because perl's configuration system is terrible (there's an out-of-tree patch to make it less terrible, though).
There's some tcl involved.
What about Git? Last I knew, it required Perl to build.
https://github.com/torvalds/linux/blob/2324d50d051ec0f14a548...
That was added 11 years ago(!!) so it may be out of date.
There are tons of examples like this. My favorite is Apple using windows xp to make and test iphones https://www.businessinsider.com/apple-uses-windows-xp-in-iph...
If all of the debugging, testing and factory management tools are standardized on Windows - why rewrite them if you don’t need to? It seems like a waste of resources.
(This isn’t limited to Apple or even technology companies. It applies to tons of businesses.)
What else are you going to use? Batch? Python certainly hadn't caught on yet in the late 90's when XP was being written.
In 2013 when I was interning for a company making an audio driver for Windows, we used Perl to run our builds. While I hate Perl, it does make it real easy to run an executable and analyze its output.
"you can get it if you want it" is just lame.
m$ should, ideally, bite the bullet and do a (stripped if need be) source release of what they can, explain what they can't release. Everyone will then benefit from the relief from worry and lack of friction things like emulation and software archeology and etc will gain.
Plus a lot of people under-estimate the cost and difficulty in releasing the source code of previously proprietary software. You don't just slap it onto Github and everyone goes home, you often need a team of lawyers to look at third party licensing and go through the code file by file looking for potential liabilities.
Code that started out open source software has to narrow third parties to only specific licenses/waivers. Code that has for tens of years been closed source may contain licensed source code (e.g. decoder libraries) that they don't own the license to publish for just one example.
The source code has already been leaked, and I would bet that malware authors have no problem with acquiring it illegally. While security researchers working within the law may not be able to look at it at all. The current situation does a lot more to help botnets than it does to help honest customers.
>Plus a lot of people under-estimate the cost and difficulty in releasing the source code of previously proprietary software. You don't just slap it onto Github and everyone goes home, you often need a team of lawyers to look at third party licensing and go through the code file by file looking for potential liabilities. [...] Code that has for tens of years been closed source may contain licensed source code (e.g. decoder libraries) that they don't own the license to publish for just one example.
I'm sorry, I just have no sympathy for the trillion dollar company that trapped themselves in restrictive license agreements and then wants to cheap out on lawyers. It is entirely a problem of their own making, and I would expect them to pay to fix it.
You don't see people flying in trijets anymore as they are dangerous, likewise you don't want to encourage or incentivize people to use or build products on an insecure OS.
Sympathy doesn't matter in the business world, costs do. No normal company is going to undertake a legal review of an unsupported product; it simply isn't worth it.
Wikipedia notes it as a design issue: https://en.wikipedia.org/wiki/Trijet
There are documented cases where failure of the central engine has caused a loss of the rear stabilizer. This can be resolved via additional engineering -> which increases cost of manufacturing and maintenance (which as you note was the main factor in why they went away).
I don't follow where you're going with this. Why would they build the source or build products on it if they were not interested in deploying security fixes? There is no other developer interest there and no company would ship a white-labeled "XP 2020 Edition" to developers if it was instantly vulnerable to malware.
>Sympathy doesn't matter in the business world, costs do. No normal company is going to undertake a legal review of an unsupported product; it simply isn't worth it.
Right, that's why I don't buy these lines about how they can't afford it. If it becomes a serious security issue that causes them problems then it is worth it.
Companies have and will ship products with outdated or unsupported OS if they think they can harden them acceptably. See all the networking devices that run some variant of the Linux 2.x kernel that still appear on the market today as an example.
Embedded XP was also a thing and probably still is in many places.
What is it, 2000?
Also some interesting portions of the OS are under a 'view but do not touch' license already. Such as MFC, ATL, and the CRT and others. Depending on which SDK or Visual C++ you grab you can get whole examples of interesting bits of the code. I know for example one of the fun ones is the pipes screen saver code is an example in one of the Visual C++ disks (5.0 I think). I recompiled it years ago to make every joint a teapot and the hard one to find was the bend.
The real money is in Azure/Office/MSSQL anyway.
Incidentally, this is also why you should separate your work and personal life.
Source?
Arent decompilers and disassemblers pretty good today anyway?
Person A's Job:
- Decompile shit.
- Then write down the names of the functions with (1) input, (2) output, (3) a description of what person a think the code is doing (4) any side effect / preconditions / post conditions they can deduce.
Person B's Job:
- Take the spec created by person A and write code.
while(missingFunctionality.hasNext): goto Person A's Job
https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=58...
They don't make software like they used to! /s
https://en.wikipedia.org/wiki/Full_Tilt!_Pinball
From https://web.archive.org/web/20190108095105/https://blogs.msd...
> Cinematronics was founded by David Stafford, Mike Sandige and I in 1994, and Space Cadet was our first published game
> The deal David did with Microsoft was non-exclusive. As Danny noted, we were more interested in the exposure and didn't see much revenue from it. However, it did lead to our relationship and eventual acquisition by Maxis.
I had posted this on the Old New Thing comments at the time, but comments on all old posts were lost in the blog transition.
https://web.archive.org/web/20190108095105/https://blogs.msd...
refs: https://web.itu.edu.tr/~dalyanda/mssecrets/other/Startup.htm
https://careers.microsoft.com/us/en/job/869511> #gamingjobs
Heh. Someone needs to tell Microsoft recruiting to dial back the "fellow kids" :P
Also, people do boomerang to companies they've worked at before.
Wouldn't posting a job that an external candidate has no chance of obtaining still violate the intent of that law?
Is this like recruiters looking for 20 years of Go experience lol?
Large OEM partners that need to do driver development, academics, and government customers are all granted source access licenses.
1: https://www.perl.com/pub/1999/06/activestate.html/
> The complete list of depots follows [...]
> Admin, Base, COM, Drivers, DS, EndUser, InetCore, InetSrv, MultiMedia, Net, PrintScan, Root, SdkTools, Shell, TermSrv, Windows
...which bears a striking resemblance — both back then and to this day — with the root-level categories that divide up the features in the "Add or Remove Windows Features" chooser in the Control Panel.
I guess those root-level categories in the chooser (which were always pretty meaningless) turn out to represent which particular Microsoft source repo the component's code can be found in.
As a wild guess, the "Add or Remove Windows Features" chooser is the way it is, because it's the runtime representation of what's actually mostly a build-time feature selection system; where disabling a component at build time speeds up your build, at the cost of that component being forcibly greyed out in the "Add or Remove Windows Features" chooser for that build. Basically the same as disabling the building of a kernel module in a Linux modular build.
As Raymond Chen would say, "it makes sense with kernel-tinted glasses."
1. Windows developers did not build large parts of the product on any regular basis. Windows took ~18 hours to build on incredibly powerful build lab hardware -- as soon as it took longer, it was time to buy a new build lab. Incremental rebuilds were notoriously flaky, at least in the days before https://github.com/microsoft/BuildXL. The most common dev loop that I saw was to install a recent dogfood build (so APIs and binary interfaces were reasonably recent) and then repeatedly rebuild and clobber binaries on that install.
2. The only real build-configuration options for timebuild were architecture and compile mode (dbg, chk, fre, opt). There wasn't an option to build or not build parts of the tree.
3. raymondc's reference to "kernel-colored glasses" is about viewing things from the kernel side of API guarantees. This is more an applied lesson in Conway's Law.
I suppose this wouldn't have resulted in an installable release, though. (At least on its own. I guess the populatefromvbl.pl script described in the memo is there to bodge a partial clean build of individual components, together with "the rest of Windows" from some parent release, to form a test build?)
also, what a strange email to be public. not that it's a hot secret, but who cares about sdx outside of MS 10 years ago?
[1] https://kobyk.wordpress.com/2008/10/29/oops-microsoft-privat...
Win 2k and NT4 sources have had a very very wide circulation for a long time. Probably there was no source copy directly at source level because they magically audited their codebase, somehow, and told us that this did not happen, BUT it at least means that it's easy for anybody not wanting to take the handwaving at face value to directly do a comparison themselves. And no magical process is going to produce virtually the same functions, including the internals, suddenly not a copyright violation, because of some random wishful thinking about how if you copy with some crazy extra steps and a cute little magical dance in the middle it becomes suddenly ok in the eye of the law. Maybe that idea would make lawyers laugh hysterically while randomly saying "AFC test", but I'm not it would have any other effect.
Just take the two trees and diff key functions and see by yourself. There is no way to justify it can't be reimplemented differently to implement even the same specification. Would MS want to destroy that project, I believe they would be able to do it, effortlessly, in a court. But I suspect it is not worth the potential PR backslash given how the narrative is already set that it is "clean", and the high number of free software enthusiasts believing it blindly for years without even checking by themselves.
How useful would this technique be to the ReactOS and Wine teams? Are there things that they don't know how to make work correctly that this source leak could help them with?
https://en.wikipedia.org/wiki/IBM_Redbooks
[0] https://www.imdb.com/title/tt0115398
in reverse engineering there has to be an intermediate person. in other words, someone could read the source code and the documentation, however they CANNOT actually do the programming. They must write, IN THEIR OWN WORDS, steps and designs for the implementation of the feature and give it to someone else who then interprets and does the actual implementation. this is to ensure that anyone who question how the feature was implemented, they have documentation showing the steps and design of the feature.
again... i don't know what the laws and procedures are today as i'm going off of what i was told, so please someone correct me if i'm wrong.
Source code is available at https://gitlab.com/escargot-chat .
Presuming they don't use any form of encryption (and I think that's a safe assumption for that era), one could keep the clients official, while routing the packets themselves using a virtual Ethernet driver (or via software-defined routing, if the relevant copy of Windows is running in a VM.)
Thanks for sharing, will look into it!
They had a LOT of fun with the fonts and animations, dancing pigs and that kind of thing.
The trouble is, Escargot is a real pain to set up. Certificates need to be patched into the hosts file every 30 days. The server must run on Windows 7 x64. The Windows XP client never worked for me; only on Windows 7 x32 and Windows 10.
If I were able to run an Escargot server from my MacBook Pro, that would make it a whole lot more fun. In practice it takes me hours just to set it up, while they'd rather be playing.
Sounds like a job for letsencrypt...
> The server must run on Windows 7 x64.
It's Python code, might just need some love to go crossplatform (?)
I remember when our office was cut from Internet. Many people did not notice, because Skype kept working like nothing happened.
I miss easter eggs.
Easter egg to me is a flight simulator in Excel or pinball in word etc.!
All of the actual content was available elsewhere as much smaller downloads. In particular, the Windows 2000 and XP leaks are distributed as a single 3 GB archive ("nt5src.7z").
The nt5src.7z src file can also be found on anonfiles and 4chan which was the actual source. It's around 7ish GB unpacked.
Windows XP service packs were based on, well, Windows XP. Because that's what service packs were. Lot s of new features have been developed for SP2 (and possibly some backporting from 2003 happened, too) but XP is still XP.
Thus, even though a few files are missing, you just need to include the few official missing ones, and the thing boots.
At the same time though, that would be hilarious. Someone is going to do it just so they can claim that they were the first person unauthorized by Microsoft to ever file a PR on Windows...
Not sure how big the repo would be though...
Because the more general public (for a certain degree of generality) apparently didn't know about this until this week. Usenet is now seen mostly as a device for good ol' piracy.
I’ve seen a ton of stuff on Empire that wouldn’t have a direct link and Empire is gone now
And afaik it was not buildable. It was a large chunk of the source code that iirc had leaked from a 3rd party who was tasked with making some component, perhaps related to the image library.
[1] https://web.archive.org/web/20100213105753/https://www.micro...
Anyone else think the smartest move for microsoft here is to leave it up, unless another copyright holder complains?
Not only has XP been sunset many times, many years ago, it might finally have all of its bugs picked clean and unofficial patches made to shore up any systems too embedded to move off XP still.
It makes sense, I don't think MS cares about Windows anymore in the azure/O365 era.
OPs hypothesis isn't totally outlandish.
So if people want to take this tree as a base to start releasing unofficial patches, they have 16 years of work to catch-up on just to reach parity.
I'm not trying to argue that unofficial patches would be a bad thing. I just don't think a source tree from 2003 is a good place to start. Any binary you build off this codebase will be missing 16 years of microsoft's patches. Until such a project caught up with all the changes made 2003-2019, any binary you build off this is likely to cause more harm than good (eg, you fix one issue, and reintroduce every issue that was fixed after 2003.)
The idea's good. This sourcetree isn't. Let's just say 2003 was not XP's golden age. If this was at least SP3 onwards, but preferably 2014+, sure. But it's not, it's SP1.
That's a lot of work for what is essentially a gross intellectual property violation as well as a leak of trade secrets.
Tk protect your trademark, you absolutely must go after trademark violations. Any build labeled "Windows" that results from this source code must be taken down if Microsoft wants to keep the trademark on things like "Windows".
Too embedded to move off XP but they're going to install a home brew version of WinXP? Extremely doubtful.