Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
Posted By Chris ElliottSenior Marketing Communications Manager
We wanted to know what you thought about Ford SYNC, so we asked.
And you answered!
SYNC fans tweeted their favorite features of the system for a chance to win an Xbox, a Microsoft keyboard or an Arc Touch Mouse. The overwhelming favorite was the ability to control SYNC with your voice. Many of you loved the Audible text messaging feature, and told us that going hands- and eyes-free makes you drive safer.
Comments Windows Embedded Automotive
Posted By David CampbellProgram Manager
He’s back! Doug Boling has once again supplied us with a great write-up for those who missed his July webcast. The topic will be a two-part post. In the first part, Doug details an overview of the three CEPC boot loaders as well as the boot sequence on a PC - which is key to understanding the Windows Embedded Compact process:
It may come as a surprise that the most popular hardware platform for Windows Embedded Compact 7 (WEC) is the standard PC chassis. This is also the hardware platform for Windows Embedded Standard (WES), but Compact 7 brings its own unique features. A properly tuned Compact system can boot faster than WES. Writing drivers is significantly simpler on WEC than on Standard. And of course, there is the dramatically lower licensing cost. This isn’t to say that Windows Embedded Standard isn’t a great operating system, it is. The point is that Compact has a different feature set than Standard and many embedded systems choose Compact over Standard on their embedded PCs.
Comments Windows Embedded Compact
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:
Comments Windows Embedded Standard
This week, we’re bringing Ford SYNC, powered by Microsoft, to the Emerald City as part of gdgt Live! Seattle. And we want to share the fun with you while we’re at it.
On Thursday August 16, we’re going social for a fun contest. Whether you are able to attend gdgt Live! Seattle or not, it’s easy to participate. All you have to do is go follow @MSFTWEB and tweet your favorite Ford SYNC feature some time during the day using the #SYNCSEA hash tag.
Told you it was simple.
So, what’s in it for you? Well, for starters, our grand prize giveaway is an Xbox 360 with Kinect. Plus we’ll have some amazing Microsoft Hardware up for grabs too. We like to show off all the great things you can do with SYNC like telling the car where you want to go, listening to text messages or calling up your favorite song using your voice. Join us at gdgt Live! Seattle to see and hear for yourself.
And don’t worry if you can’t make it, the contest is open to all residents of the US.
See you in Seattle!
The Fine Print
Welcome back! This is part 2 of Doug Boling’s great write-up on Understanding CEPC Boot Sequence in Windows Embedded Compact 7. Last time we covered the PC boot sequence in detail. That provides the background for the Windows Embedded Compact specifics. Let’s jump right in...
In Part 1, I started this discussion with an overview of two of the three different CEPC boot loaders provided in the Windows Embedded Compact 7. I discussed the LoadCEPC bootloader as well as how to use the BIOSLoader. I also talked about how the FAT file system. An understanding of the layout of a FAT storage device is important when understanding how these bootloaders work. In this installment, I will cover how the BIOSLoader and the WCELDR work and how to modify the WCELDR to adapt it to your hardware.
In Part 1, I discussed how the file system works, now let’s return back to the BIOSLoader to cover how it works. When the system starts, the BIOS will load the Master Boot Records (MBR) into RAM which will find and load the boot sector of the active partition. This boot sector will be one of the BIOSLoader boot sectors that will have to be installed on the disk. The source code for the BIOSLoader boot sectors is located in \WINCE700\platform\cepc\src\bootloader\biosloader\bootsector, There is a unique boot sector for each of the different File Allocation Table (FAT) formats including ExFAT.
The boot sector code finds the root directory and looks for the name BLDR with no extension. It expects to find this name in one of the first 32 entries in the root since the boot sector only reads the first sector of the root directory into memory.
When the BLDR entry is found, the boot loader finds the location of the file data by using the first cluster entries in the directory entry for the file. Instead of following the FAT chain to properly load the entire file, the boot sector assumes that the file will be stored in linear sectors on the disk and reads a fixed (68 sectors or 34816 bytes) into memory at address 0:1000. This hard coded size provides an absolute limit on the size of the BLDR code.
The boot sector then jumps to the first byte of the BLDR file. The BLDR then switches to protected mode and executes the remaining tasks from there. Those tasks include reading and parsing the BOOT.INI file and downloading or reading from the disk the NK.BIN file.