Can someone explain what this is exactly to me? Is it just the source tree / directory listing? It doesn't appear I can click through and view the code of any of these files, or am I mistaken?
Yeah, it's just a list of files, no file data. It's also implemented in a CSS-only manner that lags horribly in Firefox. The filenames themselves look legitimate, though.
Actually, static and dynamic libs also show up, as do resource files. So I guessed that .obj is .c (not always accurate), .res is .rc, and dynamic .lib is .exp, and so on and so forth.
Windows doesn't use VS projects. Build system is (well, was when I worked on it) custom and utilized compiler drops from developer division[1]. If you take a look at the Microsoft WDK, you'll get an idea of how the build system works, with "sources" and "dirs" files sprinkled around. VS projects wouldn't work great for yet another reason: pretty much nobody in Windows uses VS. People come from different backgrounds and already have preferences. So vim, Emacs, SourceInsight, SlickEdit and others are much more popular than VS.
Top level directories represent depots (think: repositories) of the SourceDepot version control system (home grown Perforce fork). Directory levels also tend to represent branches, so e.g. WINMAIN has branches for most depots (e.g. FBL_minio, FBL_minkernel, etc.) with additional subbranches following this pattern (e.g. FBL_minkernel_devices).
I liked Windows build system a lot. It's pretty neat how it works, what you can do with it, how you can build whole system or just parts of it, etc. It's not that simple to get build system of this size right, but I think MS actually nailed it.
[1] It has to be like that, otherwise it'd be impossible to support new platforms, like - say - ARM before WinRT was announced.
Between your comment about the dog-fooding of compiler drops, and the raving reviews of VS that I've heard (no first-hand experience, mind you), that surprises me. If nothing else, I would think that having everyone on VS while editing something like the Windows source code would surface VS bugs that one might not encounter in other situations.
That said, I do have a deep appreciation for the pushback against a corporate editor mandate.
VS is not designed for code base this size, because there aren't that many code bases this size out there. Same reason VSS ain't used for code versioning. Having said that - I don't see how having msvc build drops earlier than anyone else and testing it on the Windows code base is bad for the compiler and goes against dogfooding.
Speaking of dogfooding - using unstable builds of VS (the IDE, not the compiler which tends to be pretty stable) for something else than developing VS itself sounds like a recipe for disaster when it comes to something as massive as OS. If you read some OSS mailing lists devoted to low level dev, you'll see that what low level developers actually want is LTS compiler, not some half baked C++ year 2135 early draft compliant turd. This is why e.g. OpenBSD sticks to some old GCC with custom patches.
It's not exactly true that nobody uses VS. They just don't use it for building windows. I'd say that for debugging and editing source, the majority of windows developers probably have their own ad hoc "workspaces" that define projects for the portions they're interested in, and that's where they do their editing and debugging, but when they actually want to build, they go to a command prompt and use the monster of a custom build system.
Looks like it's owned by a ReactOS developer with quite a bit of experience in digging into Windows low-level internals: http://www.alex-ionescu.com/?page_id=2
Alex Ionescu works for Microsoft ^H^H^H^H^H edit: actually my memory might be wrong, seems he was only there for an internship. Here's his linked in.
https://www.linkedin.com/in/aionescu
This is not a file dump, but a file directory listing where he reproduces something Mark Russinovich did a while ago.
This doesn't look entirely accurate. My guess is that extensions were guessed when parsing symbols (which seem to be the source of this data). I'd bet that all of the things in minwin/kernel/io are pure C with upper layers being half-in-half C and C++ (most COM stuff has to be OO).
I'm not sure what you mean by "C++ object semantics" but COM objects are just objects, that I'm positive. My code was in .cpp file, not .c - that I'm sure of as well. This is why I'm saying that extensions seem to be guesses - PDBs carry module names w/o extensions.
Nothing stops you from following the COM ABI from C or any other language, which is kind of the point. The .h files generated from the idl have that CINTERFACE macro which has the vtable structs, in a form convenient for consuming from a C (and not C++) program.
Sure it's doable. I wrote some DirectX apps in pure C back in the days. Heck, I wrote one in ASM. But it's art for art's sake. There's no point in complicating your life like that, especially not when you're working on a commercial project.
I was at microsoft from 2008-2011 and definitely saw some C++ in the kernel, even one driver using operator new for its allocations which I thought was a little nuts at the time. I also personally introduced some user mode .c files, it was just my preference. I don't think there's much rhyme or reason to which is used, although MS does lean very heavily towards C++ over C, seems like more and more as time goes on.
As for this directory tree... I found it creepy, like maybe source was leaked. The only inaccuracies I found relative to my memory of parts that I worked on was (1) I don't think they have done well tracking files that are part of static libraries and (2) what I presume are new files introduced by folks who came after me.
C++ code in kernel typically wouldn't fly for the new stuff, but I bet there were some legacy pieces, sure. But even then nothrow would be forced on new and prefast/prefix warnings around failed allocations would have to be handled.
The build number comes from the build server, and isn't accurate I believe. Some pretty recent functionality is in the file list, including mobilecore, mincore, and other "One Windows" refactorings from Windows 10.
As others have said this is probably just a test/erronous/etc, but it's pretty funny there's a "darwin/" directory in there.
I'm betting Windows 10 will be free (as in beer) - there's not much else MSFT can do to keep Windows competitive. But it's an interesting thought experiment to think they would add a darwin compatibility layer in Win 10...
Free as in beer would make Windows so much more competitive as a development and deployment environment— being able to pull a base image off Vagrantcloud alone would be a big difference for many, I suspect.
I bet there would be a spike of interest in packaging stuff for cygwin, too.
How much money does Windows make from OS licenses vs licenses from SQLServer/Office/Exchange/Sharepoint etc. etc. It's not impossible that a free OS would lead to selling more SQLServer and Office licenses and making up some of the difference there.
Office is the real cash cow, what users really want.
Everything else can be emulated away, but no accountant will ever work without MSExcel, no lawyer will work without MSWord, and Outlook is still the best integrated mail/calendar tool. Exchange and SQLServer are profitable, but they don't provide the same amount of lock-in and revenue that Office does.
However, this won't continue forever, especially with the move to mobile. I'd argue that giving away Windows Server would be a good move to try and secure the Office monopoly beyond the next five years.
> Free as in beer would make Windows so much more competitive as a development and deployment environment.
Windows Server is unlikely to be free any time soon. Windows desktop might be, if they can plug/bundle some subscription models into it (perhaps office).
Even if Server was free (improbable like I said), that alone might not make it a competitive development or deployment environment. A lot of important work currently happening involves Open Source collaboration, and a free-as-in-beer ecosystem will not be able to take advantage of it. Earlier today, I was reading up on how AppFabric (scaling middleware) is evolving. Looks like it won't, and will soon join the other near-abandoned frameworks (Workflow Foundation, WPF, Silverlight) on the Windows stack. The future of scaling (on Windows) will have something to do with containers just like Linux or BSD. A Windows only approach to solving general industry problems is not going to cut it anymore.
In such a scenario, the primary development and deployment platforms supporting important industry trends will be free-as-in-speech Open Source platforms.
Add: Not saying MS is going anywhere. They have plenty of momentum.
How about a first-class Posix layer for Windows, a supported cross-platform native application SDK, and a hacker friendly app store supporting the union of packages available from a debian repository plus commercially licensed software? Well, a man can dream.
The important market segments won't get Windows 10 for free as in beer. The segmentation will be along the lines of Redhat [desktop costs more than Windows per year] and Fedora.[you get pointed to a BBS for support].
So yeah there may be a zero dollar option, but it will offer a poor ROI under many business models. Shedding support for zero dollar users by crowd sourcing would allow Microsoft to promote their paid support options in a more focused way.
48 comments
[ 2.5 ms ] story [ 115 ms ] threadIt takes a while to load even in Chrome.
However it's not weird to be one source tree
(There might be some things off-tree like some tools)
It's certainly debatable and there are advantages and disadvantages either way
Top level directories represent depots (think: repositories) of the SourceDepot version control system (home grown Perforce fork). Directory levels also tend to represent branches, so e.g. WINMAIN has branches for most depots (e.g. FBL_minio, FBL_minkernel, etc.) with additional subbranches following this pattern (e.g. FBL_minkernel_devices).
I liked Windows build system a lot. It's pretty neat how it works, what you can do with it, how you can build whole system or just parts of it, etc. It's not that simple to get build system of this size right, but I think MS actually nailed it.
[1] It has to be like that, otherwise it'd be impossible to support new platforms, like - say - ARM before WinRT was announced.
Between your comment about the dog-fooding of compiler drops, and the raving reviews of VS that I've heard (no first-hand experience, mind you), that surprises me. If nothing else, I would think that having everyone on VS while editing something like the Windows source code would surface VS bugs that one might not encounter in other situations.
That said, I do have a deep appreciation for the pushback against a corporate editor mandate.
Speaking of dogfooding - using unstable builds of VS (the IDE, not the compiler which tends to be pretty stable) for something else than developing VS itself sounds like a recipe for disaster when it comes to something as massive as OS. If you read some OSS mailing lists devoted to low level dev, you'll see that what low level developers actually want is LTS compiler, not some half baked C++ year 2135 early draft compliant turd. This is why e.g. OpenBSD sticks to some old GCC with custom patches.
This and GPLv3. ;)
Now that, I can totally see. IDE-based build systems drive me up a wall.
This is not a file dump, but a file directory listing where he reproduces something Mark Russinovich did a while ago.
See also his tweet here:
https://twitter.com/aionescu/status/547322576947523586
quote: I've built an entire mapping of the Windows 10 Source Tree, similar to what @markrussinovich did back in the days
As for this directory tree... I found it creepy, like maybe source was leaked. The only inaccuracies I found relative to my memory of parts that I worked on was (1) I don't think they have done well tracking files that are part of static libraries and (2) what I presume are new files introduced by folks who came after me.
But speaking of exceptions the kernel did use a lot of SEH.
In Asia, people are still running on barely Broadband speeds (1MB or below). So much for having a Indian CEO.
I'm betting Windows 10 will be free (as in beer) - there's not much else MSFT can do to keep Windows competitive. But it's an interesting thought experiment to think they would add a darwin compatibility layer in Win 10...
I bet there would be a spike of interest in packaging stuff for cygwin, too.
Free for business would kill Microsoft, as much as they bet on their hardware locked in devices these days. They're not Apple just yet.
Everything else can be emulated away, but no accountant will ever work without MSExcel, no lawyer will work without MSWord, and Outlook is still the best integrated mail/calendar tool. Exchange and SQLServer are profitable, but they don't provide the same amount of lock-in and revenue that Office does.
However, this won't continue forever, especially with the move to mobile. I'd argue that giving away Windows Server would be a good move to try and secure the Office monopoly beyond the next five years.
Windows Server is unlikely to be free any time soon. Windows desktop might be, if they can plug/bundle some subscription models into it (perhaps office).
Even if Server was free (improbable like I said), that alone might not make it a competitive development or deployment environment. A lot of important work currently happening involves Open Source collaboration, and a free-as-in-beer ecosystem will not be able to take advantage of it. Earlier today, I was reading up on how AppFabric (scaling middleware) is evolving. Looks like it won't, and will soon join the other near-abandoned frameworks (Workflow Foundation, WPF, Silverlight) on the Windows stack. The future of scaling (on Windows) will have something to do with containers just like Linux or BSD. A Windows only approach to solving general industry problems is not going to cut it anymore.
In such a scenario, the primary development and deployment platforms supporting important industry trends will be free-as-in-speech Open Source platforms.
Add: Not saying MS is going anywhere. They have plenty of momentum.
So yeah there may be a zero dollar option, but it will offer a poor ROI under many business models. Shedding support for zero dollar users by crowd sourcing would allow Microsoft to promote their paid support options in a more focused way.
Off topic: Could someone in the startup industry please create a betting site for these sorts of things?