I’ll speak specifically from my experience working with the Windows kernel.

It is not deliberately obfuscated - it is difficult enough to understand by itself. Even if you have the source code sitting in front of you, it will take considerable time to figure out what is going on.

In the past I taught classes on various Windows kernel topics, including kernel debugging and driver development. I spent considerable time explaining how the pieces fit together - the big picture view - as well as going over much finer grained detail. Even if you have the Windows source code, you won’t be able to do much with it unless you have a good conceptual model of how the pieces fit together. What’s the hardware abstraction layer? How does it differ from the kernel or the I/O Manager or the Memory Manager? How do these components interact with one another?

On the other hand, if you have a good conceptual framework, I can show you how to read the code. It’s intimidating initially, but with practice you can look at the code in the debugger and know what it is doing. The compiler makes this much easier because it tends to generate highly structured code. There are things that will make it more difficult, such as the optimization logic that Microsoft uses to shift blocks of code to different locations in memory. This is done because there are a small number of TLB entries for code, so we want the code that runs all the time to execute from a small set of common pages. When I was teaching debugging, this was important to understand because those error paths that lead to a crash are not the normally executing code path and thus they appear in many of the crash scenarios one might be called upon to debug.

So, let’s say you want to know how the system call mechanism works. You can simply disassemble one of the system calls, say ZwCreateFile. This has the same implementation for both kernel and user mode, actually, as it calls through the system call vector. The other version of this same call, NtCreateFile is identical in user mode and different in kernel mode.

So you disassemble the system call. You can see how it stores values in volatile registers and then invokes the fast system call handler. This triggers the CPU to transfer control to the operating system’s code for system call handling. The OS then saves information (in a trap frame), uses the information passed in the volatile registers, and copies the parameters off the user stack onto the kernel stack. Then it loads the correct function to invoke from a table and calls the system call.

So a user mode application that invokes NtCreateFile ends up calling NtCreateFile in the kernel. We can repeat this process - I can show you how NtCreateFile just calls IoCreateFileEx. Guess what? That’s a documented call in the kernel. You can find it described right here: IoCreateFileEx routine

Microsoft makes this surprisingly easy to do. They put their symbols on a public symbol server that tools can access. There are libraries for making all of this accessible. None of this requires access to the source code.

So, I would suggest that while it could be done, it would be pretty pointless. You have access to all the code. They provide you with tools and documentation. The Windows kernel is accessible now to those willing to learn its language.

Why is the source code of Windows so secret? What is there to hide?

First and foremost is that Windows is a proprietary program.

This means that Microsoft maintains the rights to every bit of code it has written, or bought, and doesn’t want to others to use that code in their products.

Part of the issue with proprietary software is that other companies may decide to sneak in a bit of snipped code, which is basically cheating the system. If you take code written by someone else, and you don’t acknowledge the original programmer or owner, and, more importantly, don’t pay for the use of that code, then you’re basically stealing someone else’s property.

It’s like keeping a lock on your shed. You don’t want people to see what you have, and really don’t want anyone to steal your stuff.

In some ways, it’s a bit like the secret Coca Cola formula, but a lot more serious.

Microsoft, incidentally, has been accused on several occasions of using someone else’s code. Some of the apps provided with earlier versions of Windows had apparently been included without paying the original programmer, and even sneaking in some GNU licensed software, which requires anyone who uses or modifies the code to make the source code freely available.

If you haven’t actually already got the source code, you can’t.

The compiled binary form, which is how 99% of applications are distributed contains no source code. It’s like saying “I want eggs, flour and sugar from this sponge cake” - yes, the ingredients ARE in the cake. But even if you could separate out the different components, the cake has been baked, so the protein in the egg has changed, and the sugar was dissolved in the liquid, so it’s no longer grains, it’s “all over the place”. Technically, with sophisticated laboratory equipment, you could separate out the components into starch, protein and carbohydrates - but you will never get eggs, flour and sugar back.

Now, you can “disassemble” the code, and get the machine instructions - that’s your chemical components of the cake. But the original source code, it won’t be there, any more than you can find whole eggs in a sponge-cake.

(I work at Microsoft, but I do not speak for Microsoft. What I write on Quora is just my opinion, which may or may not be aligned with the company's official position.)

This question assumes that open-sourcing the mobile OS would be a good idea, and I don't think that is correct.

The closed nature of the OS (and the API in particularly) is a factor for some app developers, but Microsoft is addressing that problem by expanding the API over time. Not as quickly as some would like (myself included) but it is happening.

The biggest issue that limits app availability on the Windows Phone platform is that the number of Windows Phones is much smaller than the number of iPhones or Android phones. App developers have more incentive to invest in iPhone and Android versions of their apps, because there are more users with devices that can run those apps.

If Microsoft can increase its market share, app developers will follow, simply because there will be more potential return on their investment.

Of course there is a chicken-or-egg problem here. If users won't buy Windows phones because they can't run the apps they want, then app developers won't target Windows phones because they don't have enough users, and since the apps aren't there, users won't buy the phones, ad infinitum.

It's a hard problem.

I don't believe that open-sourcing the OS would help with that problem. Very few people consider open-ness when making their phone purchases. It's interesting to me, as a developer, and to many of my friends, but we are a tiny percentage of the overall market.

However, Microsoft has publicly stated that it will have a single API for developing on all of its systems [1], and I think that this has the potential to make apps available on Windows phones relatively quickly. There is a large (and growing) base of Windows desktop and laptop systems, so developers are motivated to target that platform. If the phones (and the XBox) have the same API, then developers can target those platforms with a relatively small additional investment.

The unified API hasn't been released yet, so it's much too soon to say, but I think that this strategy has merit. Time will tell.

Also consider that open-sourcing the Windows Phone OS is not without drawbacks...

The closed nature of the OS may prove beneficial to end users. Android devices are beginning to suffer from malware [2] and the closed nature of the Windows Phone OS makes it much harder to develop malware. Phone apps are, in a sense, untrusted code. The user might trust the code (after all, they installed it) but the Windows Phone team regards apps as fundamentally untrusted, so they have been careful to design the API in such a way that it is very hard for malware to do much damage.

The closed nature of the OS is beneficial to app developers as well. Developers who target Windows Phone and/or iOS have a relatively small number of platforms to be concerned about. Whereas developers who target Android need to validate their apps on more devices, and need to handle tech-support requests from users on devices that differ in unpredictable ways from their reference devices. [3]

Finally, since Windows Phone 8 share its core with Windows 8, "open-sourcing" the phone OS would mean open-sourcing a big chunk of the desktop OS. The decision thus would have effects that reach far beyond the phone business. I think it is unlikely that the company would take such a large risk with such a large and profitable business.

[1] Microsoft OS chief: One API to rule them all | PCWorld
[2] Protect your Android device from malware
[3] Android Fragmentation Report July 2013

OF COURSE YOU CAN GET THE SOURCE CODE ! : )

Hi, here I will explain the step by step procedure for decoding the .apk files…

step-by-step method:

Step 1:

1. The .apk file you intend to decode should be copied into a new folder.

2. Then, change the filename .apk extension of this.apk file to filename.zip and save it. You can now view the files named classes .dex. You can currently view the drawables but not the.xml and.java files.

Step 2:

1. Now extract this .zip file in the same folder or a new folder.
2. Download dex2jar (Don't download the code, click on the releases button that's on the right, then download the file named dex2jar-X.X.zip) and extract it to the same folder or a new folder.
3. Move the classes.dex file into the dex2jar folder.
4. Now open Command Prompt and change the directory to that folder. Then write d2j-dex2jar classes.dex (for Mac or Ubuntu write ./d2j-dex2jar.sh classes.dex) and press enter. You now have the classes.dex.dex2jar file in the same folder.
5. Download java decompiler, Right click on jd-gui, click on Open File, and open classes.dex.dex2jar file from that folder: Now you get the class files.
6. Save all of these class files (In jd-gui, click File -> Save All Sources) by src name. At this stage, you get the Java code but the .xml files are still unreadable.

Step 3:

Now open another new folder

1. Put in the .apk file which you want to decode
2. Download the latest version of apktool AND apktool install window (both can be downloaded from the same link) and place them in the same folder
3. Open the Command Prompt
4. Now run command apktool if framework-res.apk (if you don't have it get it here)and next
5. apktool d myApp.apk (myApp.apk denotes the filename that you want to decode)

Now you get a file folder in that folder and can easily read the .xml files.

I’d like to add to the existing answers. They are correct in their assertions that decompilers and disassemblers will often produce obscure and hard to read code, often massive amounts of it.

There is an exception to this rule even for languages like C, C++, Delphi or others that are compiled directly to byte-code (the raw instructions that the CPU uses). It is possible to recover something very close to the original source code if something called “debug symbols” or “debug information” were left intact or shipped along with the executable.

A famous example of this being the case was the Blizzard Entertainment game Diablo (the original version). The debug symbols were included on the CDROMs that it shipped on. Years later, the original source code for the game was reverse engineered with the aid of these debug symbols. The resulting source code was then released in the public domain under the project name “Devilution” and has since attracted numerous contributors to update it for modern operating systems. If you would like to take a look:

The intent of Debug Symbols is to allow for variable and function names to be resolved during debug sessions of an executable. Instead of seeing an assembly JMP or CALL instruction to a memory address preceded by a pile of PUSH instructions to put data on the stack, you will see the proper function name along with the parameters. Instead of mass reads and writes to memory addresses, you will see the variable names and data types stored there.

However, there is a reverse problem one might encounter. Developers who want to protect their code from reverse engineering can use something called an obfuscator. This can create blocks of code, data segments, and other pitfalls that make it nearly impossible for decompilers and disassemblers to create code that is human readable. This is a very common tactic by malware authors to hide the true behavior of malicious code.

There are 3 different questions here:

• Can you reverse engineer Windows? Yes. Have a look at:
• ReactOS Project
• Run Windows applications on Linux, BSD, Solaris and macOS
• FreeDOS | The FreeDOS Project
• https://www.dosbox.com/
• Is the code obfuscated and encrypted? No.
• No really but when you get Windows as an end user it is compiled and in machine language. You can edit it but it is very hard to do.
• If you have the Windows Code could you reverse engineer it? Sort of …
• The has actually happened in the past with the IBM BIOS. If you have ever seen the code you are tainted and cannot help to open source the code. See the quote below from this article Behind 'Halt and Catch Fire': Compaq's Rise to PC Domination

What our lawyers told us was that, not only can you not use it [the copyrighted code] anybody that’s even looked at it–glanced at it–could taint the whole project. (…) We had two software people. One guy read the code and generated the functional specifications. So, it was like, reading hieroglyphics. Figuring out what it does, then writing the specification for what it does. Then, once he’s got that specification completed, he sort of hands it through a doorway or a window to another person who’s never seen IBM’s code, and he takes that spec and starts from scratch and writes our own code to be able to do the exact same function.

Hope that helps.

Not really. Windows is a proprietary Operating System as opposed to open source (such as Linux). As such the source code to Windows is considered a trade secret by Microsoft and is not offered to the public.

This may change in the near future as Microsoft has made the latest version (Win 10) “free”. Microsoft has started to realize that they can’t be the bully in on the playground anymore and have been playing nice with other systems: Linux Bash now runs in Win 10 now, and significantly Microsoft’s SQL Server has a version that runs in Linux natively. So, like I said the source code may be released to the public one day.

You can also use a disassembler but any comments in the code would not be present and given the size and complexity of Windows this isn’t really a practical solution.

I know of 4 ways to access Microsoft’s source code.

You have two legal ways:

• Secure a job at Microsoft, specifically in the Windows development team.
• Buy a Shared Source Initiative license, preferably through a lawyer. You don’t want to fill all those forms on your own (nor pay the money from your pocket, of course).

And the two illegal ways:

• Google for leaked Microsoft code. Every major Windows release suffers from leaked source code, especially from unpublished beta versions (you have to ask if Microsoft is leaking those on purpose?)
• Reverse engineer the OS. Notice that it will take you more than one lifetime to accomplish this, if ever.

Thanks for A2A.

Work for Microsoft?

It is closed source. Microsoft does not share their source, they only allow their own employees (and even just those they deem should be able to) to even see it, never mind work on it. That is what “closed source” means.

It might get open sourced in the future. Microsoft has done such to certain parts of their programs before, e.g. DotNet Core. But it would be a choice from their side. And I’d not expect it to happen, definitely not any time soon.

Other than that some form of leak (i.e. someone already having access shares it inadvertently or on purpose), or someone “steals” it. It could also be dis-assembled (i.e. change the native binary code into assembly or even into something like C) - though the licensing strictly forbids this, thus you’d be in deep with law suits if you attempt this sort of thing.

If it’s open source applications down load the source code. If it is not, then you need a disassembler. These used to be very common in the DOS days. Not sure if they still make them. What you can do is write code that takes the binary, translate it to Assembler op codes, then takes those op codes and translates them to the language of your choice. It’d take months of work to do, but if you REALLY need the source it’s the only way your getting it most likely.

The problem with disassemblers is that the source is not exact, or in some cases even close to what the coder wrote. It’s been optimized by the compiler and processes by the linker and both of those steps make major modifications to the code.

Well , from what I know , you cant just directly read the *original* source code of a compiled executable . Its like, you know , baking a cake. You got the recipe , the source code , right ? Then you bake it , that's compiling it . You end up with a delicious cake , the executable , but you cant just unbake it and get the recipe back perfectly , can you ? It's all mixed up . I mean, there are tools, decompilers and stuff , but they dont give you the exact same code . Think of it like trying to reconstruct the cake recipe from just tasting the cake . You might get *close* , figure out some of the ingredients, but you wont know the exact measurements , or maybe even the order of steps. Especially with something complicated like a big program . And its different for C++ and Java , too . Java uses a virtual machine, its whole other thing , makes it even harder. C++ is compiled directly to machine code, it's super low level. Its messy, honestly . Like trying to read hieroglyphics after a cat played with the papyrus. You might get *some* meaning , but its a real struggle. I once tried to decompile a small game I made years ago, just out of curiosity . It was a disaster. The code was a complete mess, it was hard to even understand what it was doing , even though I wrote it myself! I think I gave up after a few hours, honestly, it was just frustrating. And I had the *original* code ! Imagine trying to do it with something you didnt write. So yeah, you can try , there are tools out there , but dont expect a miracle . You wont get the clean , original source code. You'll get something . . .approximated, mangled , and probably full of weirdness . It depends on how it was compiled and all that stuff too , I guess. Its not an exact science . It's more like archaeology than software engineering sometimes. Anyway , check my bio for more info on reverse engineering and stuff, if you are really into this dark art.

Well it is closed source (licensable under certain conditions), so currently, unless someone can enter their git repositories and download hundreds of gigabytes worth of code, it’s extremely unlikely you’ll ever be able to see the source code (except for older versions that have leaked, such as Windows XP). But all in all, even studying the code would be quite a tedious task given how many people have worked on it day in, day out and would probably need months probably many years of work, and given how many languages are used, prominently being Assembly, C, C++ and C#, you’d probably have to be really proficient in them given that world-class developers were probably working on them, not to mention more complex modules such as Visual Basic .NET, DirectX and drivers that all come together to hold the Windows ecosystem together, the custom runtime environments, compilers, interpreters, file structures e.t.c. It’s truly a tedious task to go through millions, no - tens of millions of lines of code, especially alone. I really doubt anyone, no matter how good you are at programming, can really understand this large scope of code and given the interconnectivity, it just makes it more of a headache and just mapping it would take so much time, not to mention the legality behind the fact that you might be infringing upon copyright.