
Windows 10 Technical Preview Source Tree - cremno
http://windows-internals.com/source/files.html
======
hosay123
I'll bet $3 these were maybe extracted from Microsoft Symbol Server. Note it's
not a MSFT site, it's some training firm.

~~~
toyg
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](http://www.alex-ionescu.com/?page_id=2)

~~~
wila
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](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.

See also his tweet here:

[https://twitter.com/aionescu/status/547322576947523586](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

~~~
aionescu
I never worked or interned at Microsoft :)

------
sargun
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?

~~~
mischanix
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.

~~~
TillE
Possibly extracted from debug symbols? That would be my guess.

It takes a while to load even in Chrome.

~~~
mischanix
The only files that show up in PDBs are source files for the resulting objects
(e.g., .c); there are .exp and other files in that tree.

~~~
aionescu
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.

------
bkmn
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...

~~~
mikepurvis
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.

~~~
devcpp
Free for educational and personal use only. I doubt your use would include
that.

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.

~~~
dagw
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.

~~~
toyg
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.

------
drey08
It's kind of odd that it would be just one source tree. Surely it can't be one
giant Visual Studio project.

~~~
raverbashing
Of course it's not going to be one VS project

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

~~~
DominikD
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.

~~~
mdaniel
> pretty much nobody in Windows uses VS

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.

~~~
hamburglar
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.

~~~
mdaniel
_... use the monster of a custom build system._

Now __that __, I can totally see. IDE-based build systems drive me up a wall.

------
devsno
Looks like this is old: build 9364. Also a lot files representing recent
functionality are missing.

~~~
aionescu
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.

------
chj
Odd that all sources are c files. No cpp?

~~~
DominikD
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).

~~~
asveikau
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.

~~~
DominikD
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.

~~~
asveikau
This is true. The driver I am thinking of didn't use C++ exceptions. I just
found it weird not to use the pool APIs like everything else.

But speaking of exceptions the kernel did use a lot of SEH.

------
geonik
What a mess! And, frankly, I don't care unless I can read the source code

------
rikacomet
MS, why you no break that iso file in part files?

In Asia, people are still running on barely Broadband speeds (1MB or below).
So much for having a Indian CEO.

