Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
Posted By J.T. KimbellProgram Manager
A lot of our summer interns are wrapping up their experiences here at Microsoft, so you’ll be seeing several more of these posts in the next few weeks. In this post Arijit Choudhury, an SDE intern, tells you about his experience and work this summer.
Getting a chance to work as a Software Development Engineer (SDE) intern at Microsoft is my very own ‘What do you want to be when you grow up?’ story. I still remember using my first PC from the 90s (Windows 95 running on an Intel MMX processor) and how it introduced me to the Internet, PC games and computer science (CS). Today I am going to share my experiences about my Microsoft internship and in particular, my stint with the Windows Embedded Componentization team.
But first, whoami? I am Arijit Choudhury and I’m studying for my Master’s degree in Computer Science at the University of Florida in Gainesville. Before that, I finished my bachelors from the Dhirubhai Ambani Institute of Information and Communication Technology in Gandhinagar, India. Most of the time, you’ll find me programming (complete with noise cancellation headphones) or playing Soccer wearing an Arsenal jersey on the University field. Getting a chance to learn how to write good code for Microsoft and playing soccer along with other Microsofties in beautiful Seattle is my idea of a perfect summer.
Now that I’ve introduced myself, let us move straight to the three things that impacted me the most during my internship:
So what is it like being an Intern at Microsoft? In one word, brilliant. You get to meet incredibly bright people working on next generation technologies and cool side projects (part of platforms such as The Garage). In addition to that, interns are invited to the intern speaker series which is an exclusive series of technology talks by senior members from the Microsoft family (Technical Fellows, Principal Developers, Division Heads such as Steven Sinofsky and finally, Steve Ballmer). There are tons of fun intern events throughout the summer, boatloads of free stuff and a yearly signature event. This year, the signature event included a bus tour around the city of Seattle and then onto Gasworks Park where we were treated to epic performances by the Alabama Shakes (here’s Hold On, their hit single) and Young the Giant, one of my favorite live bands. To top it all, we came home with free Samsung Series 9 laptops loaded with the latest Windows 8 build. What more could a computer science guy in his early 20s ask for? Here a bird’s eye view of what it was like!
Software Development Engineers write production code in Microsoft and a SDE Internship is a glimpse into their lives. In the first two weeks of my internship I was given a user story to investigate. The challenge was to develop an application using a viable technology and simple UI to tackle this user story. Over two months, I worked in 2-week sprints (yes, my team follows the Agile Scrum model) designing sub-features or tasks, writing code and testing. This model was incredibly powerful in getting things done quickly without the unnecessary overhead of the elaborate design documents. Also, I was able to demo new features in my application as soon as they were done rather than waiting for the entire development phase to be over. Once the application began giving the expected results I received the chance to demo it to teams within Windows Embedded who provided some excellent feedback.
So to put it simply: Design-Code-Test-Demo. Then repeat. Awesome.
Modules are essentially the building blocks of Windows Embedded Standard 8. To deploy a Windows Embedded device with the right functionality, we need to choose the right modules. For example, if you want your device to run an application that requires audio support you will need to use the Windows Audio module as a part of your custom Windows Embedded Standard 8 image. Modules are organized into broad functional groups called categories. Here’s an example of a category ‘Graphics and Multimedia’ containing the module ‘Windows Audio’ that you can see during a Windows Embedded Standard 8 installation:
To learn more about modules, see this detailed explanation from Dave Massy. With Windows Embedded Standard 8 we can build custom modules i.e. modules containing other modules.
So now we know what modules are. But how do you pick the right modules for your app? Some readers may recognize this problem as that of dynamic dependency analysis. This is essentially the problem that I was lucky enough to have a crack at during my internship.
Let me then rephrase the problem in terms of a user story by taking Skype (a much loved application) as an example:
Immediately, a trivial way to solving this problem could be to import every available module in Windows Embedded Standard 8 onto our custom image (let us call this particular configuration a “MAXBOOT” Windows Embedded Standard 8 image) but this is often impractical. The term ‘right’ here denotes necessary modules for Skype to create the most light-weight image of Windows Embedded Standard 8 possible.
How would we approach this problem? Here’s how I went about it:
First, let us assume that we have access to the Skype source code. Say it looked like this:
1: #include <
> // ntdll.dll is contained in the Embedded Core module
2: #include <
> // msvcrt.dll is contained in the Embedded Core module
3: #include <
> // kernel32.dll is contained in the Embedded Core module
5: int main()
8: if (someCondition)
) // mshtml.dll is contained in the HTML Display Engine module
15: return 0;
Therefore for Skype to be able to run reliably on our custom Windows Embedded Standard 8 image, we need to import the Embedded Core module and the HTML display engine module. The interesting thing to note here is that the first three binaries loaded (i.e. ntdll.dll, msvcrt.dll and kernel32.dll) are necessary for Skype to start and are called static dependencies. But to be able to effectively use Skype we will also need to address the issue of handling runtime dependencies such as mshtml.dll i.e. binaries loaded by Skype based on the way that application is used.
Identified binary dependencies will then need to be intelligently mapped to Windows Embedded Standard 8 modules. In Windows Embedded Standard 7, we provided the Package Mapper PowerToy to do this and are currently trying to determine the appropriate way to provide this functionality in Windows Embedded Standard 8.
But… we don’t have the Skype source code! And even if we did, we would want to automate this process in some way to decrease our overall deployment time.
An application that is frequently used to tackle this problem is called Process Monitor. It is a powerful SysInternals tool that lists all the binaries loaded by an application. Here’s a white paper that describes using Process Monitor along with Package Mapper (another familiar power toy for Windows Embedded Standard users) to discover dependencies. Users however need to be extra careful while noting down dependencies with Process Monitor.
This is because many applications create child processes that have their own binary dependencies and do not have similar names (e.g. If you check the ‘Install Bing Bar’ option during Skype installation, SkypeSetup.exe will spawn a child process named ‘BingBarSetup-Partner.exe’) so that we may identify them easily by looking at Process Monitor logs. For enterprise applications, the number of child processes that need to be monitored manually through Process Monitor can run into dozens, which can be impractical.
After preliminary investigations and discussions with my manager and mentors we identified the project goal. It was to develop a tool that:
After the 8 weeks’ worth of development, I was successful in building a tool that satisfies the aforementioned requirements for deploying most applications (I’ll explain what the limitations are in a bit)! Let’s call the tool dda.exe (short for Dynamic Dependency Analyzer) for now.
Here’s the entire workflow:
Dynamic Dependency Analyzer uses Debugging APIs for Windows. To put it simply: the application acts as a debugger that attaches itself to SkypeSetup.exe and monitors the LoadLibrary() and CreateProcess() calls (a debugger can track these through Debug Events) made by it. It also does some other cool stuff.
Finally, a word on limitations and availability of this tool. Dynamic Dependency Analyzer cannot monitor Remote Procedure calls and therefore cannot monitor services. As with all debuggers, running your target application with Dynamic Dependency Analyzer may sometimes cause it to crash! And of course, since the binary dependencies noted by the tool are based on how a user used an application; the identified set of modules is not necessarily the minimal required set (but rather a very good estimate). We hope to release this tool as a PowerToy in the near future!
Throughout my internship at Microsoft I have come across some of the brightest and most enthusiastic people I have ever met. I really hope that the work I have done can help our customers deploy applications on their devices faster. My manager Jon Parati and mentor (or “peer buddy”) Saravanan Somasundaram were the best that any intern could have asked for and I learnt a great deal from them. Finally, the 12 weeks at Microsoft made me more mature as a developer; attacking user scenarios rather than coding challenges and accepting feedback whilst being humble. Thanks for walking along with me through my internship! And stay tuned for more perspectives from Windows Embedded interns!