Using a sensor in Windows 7

Support for Windows 7 ended on January 14, 2020

We recommend you move to a Windows 10 PC to continue to receive security updates from Microsoft.

What is a sensor?

Sensors are hardware components that can provide your computer with information about your computer’s location, surroundings, and more. Programs on your computer can access information from sensors, and then store or use it to help you with everyday tasks or to improve your computer experience. There are two types of sensors:

Sensors that are built in to your computer

Sensors that are connected to your computer by a wired or wireless connection

Some examples of sensors include a location sensor, such as a GPS receiver, that can detect your computer’s current location. A program could then use that location to provide you with information about nearby restaurants or driving directions to your next destination. A light sensor installed on your computer could detect the light in your surroundings, and then adjust the screen brightness to match it.

Using location and other sensors

By using sensors, programs on your computer can customize information and services for you based on your computer’s current location, surroundings, and more. For example, with a location sensor and your computer, you may be able to find a nearby restaurant, get directions to that restaurant, send the directions to a friend, and then follow the directions on a map as you travel to your destination.

Programs can access information from a sensor once it’s installed and enabled on your computer. Programs can then store or use that information to help you with everyday tasks or to improve your computer experience. To help prevent all programs and user accounts from accessing information from a sensor, you can disable the sensor.

Because some programs may send personal information over network connections, you can enable or disable a sensor only when you are logged on to Windows with an administrator account.

You may want to limit access to personal information about certain users on your computer.

How does a sensor affect my privacy?

By default, when a sensor is enabled, all programs and users on your computer can access the information from that sensor. Windows notifies you when programs access information about your location by temporarily displaying the Location and Other Sensors icon in the notification area. Windows displays this icon the first time a program or a service accesses your computer’s location from a sensor.

Some programs could potentially use personal information (such as your location) from sensors without permission. You can limit programs from accessing information from sensors by user account.

Change who can access information from a sensor

You might want to limit programs or services (which run in the background for all user accounts) from accessing information from sensors. By default, when you first enable a sensor, all programs and services can access information from the sensor for all user accounts. You can choose to limit programs from accessing information from sensors by user account. You can also choose to limit services from accessing information from sensors, but this will apply to all user accounts.

Open Location and Other Sensors by clicking the Start button , and then clicking Control Panel. In the search box, type sensors, and then click Location and Other Sensors.

Note: You must have at least one sensor installed before you can change user settings for sensors.

In the left pane, click Change user settings.

Under Sensor, from the list, click the sensor that you want to change user settings for.

Under Access, select the check box next to each user name to provide access, or clear the check box next to each user name to remove access, and then click OK. If you’re prompted for an administrator password or confirmation, type the password or provide confirmation.

Enable or disable a sensor

Programs can use information from a sensor after it’s enabled. You can enable or disable sensors that are installed on your computer in Location and Other Sensors in Control Panel. Disabling a sensor doesn’t turn it off. Some programs may still access information from a sensor when it’s disabled.

Once a sensor is enabled, by default, all users and programs on your computer can access information from it. The first time a program or a service accesses your computer’s location from a sensor, Windows will temporarily display the Location and Other Sensors icon in the notification area.

To enable or disable a sensor

Open Location and Other Sensors by clicking the Start button , and then clicking Control Panel. In the search box, type sensors, and then click Location and Other Sensors.

Select the check box next to the sensor that you want to enable, or clear the check box to disable the sensor, and then click Apply. If you’re prompted for an administrator password or confirmation, type the password or provide confirmation.

Install or uninstall a sensor

Check the information that came with your sensor or go to the sensor manufacturer’s website. After you’ve installed a sensor, you must enable it. This allows programs to access information from the sensor.

To uninstall a sensor

Open Location and Other Sensors by clicking the Start button , and then clicking Control Panel. In the search box, type sensor s, and then click Location and Other Sensors.

Click the sensor that you want to uninstall.

Under More options, click Uninstall this sensor, and then click OK. If you’re prompted for an administrator password or confirmation, type the password or provide confirmation.

How to repair Windows store App

Replies (4) 

Hi Keith, a lot of users are reporting problems with the Store app in version 1803!

Please try this:

Open the Windows Store

Click your User Icon and choose Sign out

Search for an App you want to download and click ‘Get’

Sign back into your Account

Can you now download that App?

Power to the Developer!

MSI GV72 — 17.3″, i7-8750H (Hex Core), 32GB DDR4, 4GB GeForce GTX 1050 Ti, 256GB NVMe M2, 2TB HDD

5 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Not sure what steps you have already undertaken, hence steps might be repeated below.

Please try these options one by one and check after each option. (The first step usually solves the problem)

1. Open MS Store > Click on your profile picture on top right and sign-out. Then sign-in again.

2. Run Windows App Troubleshooter
Windows Key+X > Click Settings > Click Update & security > Click Troubleshoot > Scroll down to the bottom > Click Windows Store Apps > Click Run the Troubleshooter

3. Reset Windows Store through Command Prompt
Type cmd in Windows Search box > Right click on Command Prompt > Run As Administrator > Type WSreset.exe and click Enter > Reboot your computer

4. Re-register All Store apps
Right click on Windows Start > Right click on Windows Powershell (Admin) > Copy the following from below and right click in Powrshell to paste ? Enter > Restart your computer
Get-AppXPackage -AllUsers | Foreach

5. Uninstall & Reinstall Store
Right click on Windows Start > Right click on Windows Powershell (Admin) > Copy the following from below and right click in Powershell to paste > Enter

Get-AppxPackage -allusers *WindowsStore* | Remove-AppxPackage

Copy the following from below and right click in Powershell to paste > Enter > Reboot your computer

Get-AppxPackage -allusers *WindowsStore* | Foreach

Let me know if you have any more question or require further help. If above didn’t work, I will supply more troubleshooting steps to solve this problem.

Best regards
Vijay A. Verma @ http://www.eforexcel.com/

Timezone: UTC+05:30, PST+12:30
Availability Hours (UTC) : 05:00 AM — 05:00 PM

7 people found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Sumit
Volunteer Moderator- Microsoft Community

Mark the reply as helpful or answered to help others if your query is resolved

1 person found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

First, try signing out of the Microsoft Store. Click your Profile picture at the top right, click your account then sign out.

Restart your computer, launch the Microsoft Store app, sign in again, then attempt downloading again.

Other things you can try.

Start by running the Windows Store Apps troubleshooter.

Open Start > Settings > Update & security > Troubleshoot
Scroll down to the bottom
Click Windows Store Apps

Click Run the troubleshooter

When complete try opening the Store again.

Also check if the Store works in another user account.

Press Windows key + R
Type: wsreset.exe
Hit Enter

Do this a couple times then try launching the Store again.

Your Antivirus might be interfering with the Store, try disabling it ‘temporarily’ to see if it launches.

Check Windows Update and install the latest updates. Sometimes Microsoft releases infrastructure fixes for the Store through Windows Update.

You can also try resetting the store app using the following instructions:

Reinstall the Store:
Press Windows key + X
Click Windows PowerShell (Admin)
At the command prompt, type the following then hit Enter:

Get-AppXPackage *WindowsStore* -AllUsers | Foreach

If that does not work, try resetting the software distribution folder:
Before carrying out this procedure, disconnect from the Internet. That means turning off Wi-Fi and disconnecting from a wired connection. If you don’t, Windows 10 will indicate some files are in use and cannot be modified or the command will be non-responsive. Also, you should restart your computer after disconnecting from the Internet. The easiest way to do it is to enable Airplane mode from the Action Center — Windows key + A.

1. Open Start, type: CMD
Right click CMD
Click Run as administrator

Type each of the following then hit Enter

taskkill /F /FI «SERVICES eq wuauserv» (do this multiple times)
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
rmdir C:\Windows\SoftwareDistribution\DataStore
rmdir C:\Windows\SoftwareDistribution\Download

If that does not work.

1. Open Start, type: CMD
Right click CMD
Click Run as administrator

Type each of the following then hit Enter

Run these codes:
Net Stop bits
Net Stop wuauserv
Net Stop appidsvc
Net Stop cryptsvc
Ren %systemroot%\SoftwareDistribution SoftwareDistribution.bak
Ren %systemroot%\system32\catroot2 catroot2.bak
Net Start bits
Net Start wuauserv
Net Start appidsvc
Net Start cryptsvc
After running these commands, check if your issue is fixed.

When complete, hit Enter, then restart, then try updating again.

Ultrabook™ and Tablet Windows* 8 Sensors Development Guide

Published: 09/04/2013 Last Updated: 09/04/2013

This guide gives developers an overview of the Microsoft Windows 8.1 sensors application programming interfaces (APIs) for Windows 8.1 Desktop and Windows Store applications with a specific focus on the various sensor capabilities available in Windows 8.1 Desktop mode. This Development Guide summarizes the APIs that enable creating interactive applications by including some of the common sensors such as accelerometers, magnetometers, and gyroscopes with Windows 8.1.

Programming Choices for Windows 8.1

Developers have multiple API choices to program sensors on Windows 8.1. The touch-friendly app environment is called “Windows Store apps.” Windows Store apps can run software developed with the Windows Run-Time (WinRT) interface. The WinRT sensor API represents a portion of the overall WinRT library. For more details, please refer to the MSDN Sensor API library.

Traditional Win Forms, or MFC-style apps are called “Desktop Apps” because they run in the Desktop Windows Manager environment. Desktop apps can either use the native Win32*/COM API, a .NET-style API or a subset of select WinRT APIs.

The following is a list of WinRT APIs that can be accessed by Desktop apps:

• Windows.Sensors (Accelerometer, Gyrometer, Ambient Light Sensor, Orientation Sensor. )
• Windows.Networking.Proximity.ProximityDevice (NFC)
• Windows.Device.Geolocation (GPS)
• Windows.UI.Notifications.ToastNotification
• Windows.Globalization
• Windows.Security.Authentication.OnlineId (including LiveID integration)
• Windows.Security.CryptographicBuffer (useful binary encoding/decoding functions)
• Windows.ApplicationModel.DataTransfer.Clipboard (access and monitor Windows 8 Clipboard)

In both cases, the APIs go through a Windows middleware component called the Windows Sensor Framework. The Windows Sensor Framework defines the Sensor Object Model. The different APIs “bind” to that object model in slightly different ways.

Differences in the Desktop and Windows Store app development will be discussed later in this document. For brevity, we will consider only Desktop app development. For Windows Store app development, please refer to the API Reference for Windows Store apps.

Sensors

There are many kinds of sensors, but we are interested in the ones required for Windows 8.1, namely accelerometers, gyroscopes, ambient light sensors, compass, and GPS. Windows 8.1 represents the physical sensors with object-oriented abstractions. To manipulate the sensors, programmers use APIs to interact with the objects. The following table provides information on how the sensors can be accessed from both the Windows 8 Desktop apps as well as from Windows Store apps.

Windows 8.1 Desktop Mode Apps

Windows Store Apps

C++, C#, VB & XAML
JavaScript/HTML5

Table 1. Features Matrix for Windows* 8.1 Developer Environments

Below, Figure 1 identifies that there are more objects than actual hardware. Windows defines some “logical sensor” objects by combining information from multiple physical sensors. This is called “Sensor Fusion.”

Figure 1. Different sensors supported, starting on Windows* 8

Sensor Fusion

Physical sensor chips have some inherent natural limitations. For example:

• Accelerometers measure linear acceleration, which is a measurement of the combined relative motion and the force of Earth’s gravity. If you want to know the computer’s tilt, you’ll have to do some mathematical calculations.
• Magnetometers measure the strength of magnetic fields, which indicate the location of the Earth’s Magnetic North Pole.

These measurements are subject to an inherent drift problem, which can be corrected by using raw data from the Gyro. Both measurements are (scaled) dependent upon the tilt of the computer from level with respect to the Earth’s surface. For example, to obtain the computer’s heading with respect to the Earth’s True North Pole (Magnetic North Pole is in a different position and moves over time), corrections must be applied.

Sensor Fusion (Figure 2) is defined by obtaining raw data from multiple physical sensors, especially the Accelerometer, Gyro, and Magnetometer, performing mathematical calculations to correct for natural sensor limitations, computing more human-usable data, and representing those as logical sensor abstractions. The application developer must implement the necessary transformations required to translate physical sensor data to the abstract sensor data. If the system design has a SensorHub, the fusion operations will take place inside the microcontroller firmware. If the system design does not have a SensorHub, the fusion operations must be done inside one or more device drivers that the IHVs and/or OEMs provide.

Figure 2. Sensor fusion via combining output from multiple sensors

Identifying Sensors

To manipulate a sensor, a system is needed to identify and refer to. The Windows Sensor Framework defines a number of categories that sensors are grouped into. It also defines a large number of specific sensor types. Table 2 lists some of the sensors available for Desktop applications.

Boolean Switch Array

Table 2. Sensor types and categories

The sensor types required by Windows 8 are shown in bold font:

• Accelerometer, Gyro, Compass, and Ambient Light are the required “real/physical” sensors
• Device Orientation and Inclinometer are the required “virtual/fusion” sensors (note that the Compass also includes fusion-enhanced/tilt-compensated data)
• GPS is a required sensor if a WWAN radio exists, otherwise GPS is optional
• Human Proximity is an oft-mentioned possible addition to the required list, but, for now, it’s not required.

All of these constants correspond to Globally Unique IDs GUIDs. Below, in Table 3, is a sample of some of the sensor categories and types, the names of the constants for Win32/COM and .NET, and their underlying GUID values.

Table 3. Example of Constants and Globally Unique IDs (GUIDs)

Above are the most commonly used GUIDs; there are many available. At first you might think that the GUIDs are silly and tedious, but there is one good reason for using them: extensibility. Since the APIs don’t care about the actual sensor names (they just pass GUIDs around), it is possible for vendors to invent new GUIDs for “value add” sensors.

Generating New GUIDs

Microsoft provides a tool in Visual Studio* for generating new GUIDs. Figure 3 shows a screenshot from Visual Studio for doing this. All the vendor has to do is publish them, and new functionality can be exposed without the need to change the Microsoft APIs or any operating system code at all.

Figure 3. Defining new GUIDs for value add sensors

Using Sensor Manager Object

In order for an app to use a sensor, Microsoft Sensor Framework needs a way to “bind” the object to actual hardware. It does this via Plug and Play, using a special object called the Sensor Manager Object.

Ask by Type

An app can ask for a specific type of sensor, such as Gyrometer3D. The Sensor Manager consults the list of sensor hardware present on the computer and returns a collection of matching objects bound to that hardware. Although the Sensor Collection may have 0, 1, or more objects, it usually has only one. Below is a C++ code sample illustrating the use of the Sensor Manager object’s GetSensorsByType method to search for 3-axis Gyros and return them in a Sensor Collection. Note that a ::CoCreateInstance() must be made for the Sensor Manager Object first.

Ask by Category

An app can request sensors by category, such as all motion sensors. The Sensor Manager consults the list of sensor hardware on the computer and returns a collection of motion objects bound to that hardware. The SensorCollection may have 0, 1, or more objects in it. On most computers, the collection will have two motion objects: Accelerometer3D and Gyrometer3D.

The C++ code sample below illustrates the use of the Sensor Manager object’s GetSensorsByCategory method to search for motion sensors and return them in a sensor collection.
C++ does not have a GetAllSensors call, so you must use GetSensorsByCategory(SENSOR_CATEGORY_ALL, …) instead as shown in the sample code below.

Sensor Life Cycle – Enter and Leave Events

On Windows, as with most hardware devices, sensors are treated as Plug and Play devices. There are a few different scenarios where sensors can be connected/disconnected:

1. It is possible to have USB-based sensors external to the system and plugged in to a USB port.
2. It is conceivable to have sensors that are attached by an unreliable wireless interface (such as Bluetooth*) or wired interface (such as Ethernet), where connects and disconnects are common.
3. If a Windows Update upgrades the device driver for the sensors, they will appear to disconnect and then reconnect.
4. When Windows shuts down (to S4 or S5), the sensors appear to disconnect.

In the context of sensors, a Plug and Play connect is called an Enter event, and disconnect is called a Leave event. Resilient apps need to be able to handle both.

Enter Event Callback

If the app is already running at the time a sensor is plugged in, the Sensor Manager reports the sensor Enter event; however, if the sensors are already plugged in when the app starts running, this action will not result in Enter events for those sensors. In C++/COM, you must use the SetEventSink method to hook the callback. The callback must be an entire class that inherits from ISensorManagerEvents and must implement IUnknown. Additionally, the ISensorManagerEvents interface must have callback function implementations for:

Code:Hook Callback for Enter event

Below is the C++/COM equivalent of the Enter callback. All the initialization steps from the main loop would be performed in this function. In fact, it is more efficient to refactor the code so that the main loop merely calls OnSensorEnter to simulate an Enter event.

Code: Callback for Enter event

Leave Event

The individual sensor (not the Sensor Manager) reports when the Leave event happens. This code is the same as the previous hook callback for an Enter event.

Code: Hook Callback for Leave event

The OnLeave event handler receives the ID of the leaving sensor as an argument.

Code: Callback for Leave event

Picking Sensors for an App

Different types of sensors report different information. Microsoft calls these pieces of information Data Fields, and they are grouped together in a SensorDataReport. A computer may (potentially) have more than one type of sensor that an app can use. The app won’t care which sensor the information came from, so long as it is available.

Table 4 shows the constant names for the most commonly used Data Fields for Win32/COM and.NET. Just like sensor identifiers, these constants are just human-readable names for their associated GUIDs. This method of association provides for extensibility of Data Fields beyond those “well known” fields that Microsoft has pre-defined.

Table 4. Data Field identifier constants

One thing that makes Data Field identifiers different from sensor IDs is the use of a data type called PROPERTYKEY. A PROPERTYKEY consists of a GUID (similar to what sensors have), plus an extra number called a “PID” (property ID). You might notice that the GUID part of a PROPERTYKEY is common for sensors that are in the same category. Data Fields have a native data type for all of their values, such as Boolean, unsigned char, int, float, double, etc.

In Win32/COM, the value of a Data Field is stored in a polymorphic data type called PROPVARIANT. In .NET, there is a CLR (Common Language Runtime) data type called “object” that does the same thing. The polymorphic data type will need to be queried and/or typecast to the “expected”/”documented” data type.

The SupportsDataField() method of the sensor should be used to check the sensors for the Data Fields of interest. This is the most common programming idiom that is used to select sensors. Depending on the usage model of the app, only a subset of the Data Field may be required. Sensors that support the desired Data Fields should be selected. Type casting will be required to assign the sub-classed member variables from the base class sensor.

Code: Use of the SupportsDataField() method of the sensor to check for supported data field

Sensor Properties

In addition to Data Fields, sensors have Properties that can be used for identification and configuration. Table 5 shows the most commonly-used Properties. Just like Data Fields, Properties have constant names used by Win32/COM and .NET, and those constants are really PROPERTYKEY numbers underneath. Properties are extensible by vendors and also have PROPVARIANT polymorphic data types. Unlike Data Fields that are read-only, Properties have the ability to Read/Write. It is up to the individual sensor’s discretion as to whether or not it rejects Write attempts. Because no exception is thrown when a write attempt fails, a write-read-verification will need to be performed.

Table 5. Commonly used sensor Properties and PIDs

Setting Sensor Sensitivity

The sensitivity setting is a very useful Property of a sensor. It can be used to assign a threshold that controls or filters the number of SensorDataReports sent to the host computer. In this way, traffic can be reduced: only send up those DataUpdated events that are truly worthy of bothering the host CPU. The way Microsoft has defined the data type of this Sensitivity property as a container type called IPortableDeviceValues in Win32/COM and SensorPortableDeviceValues in .NET. This container holds a collection of tuples, each of which is a Data Field PROPERTYKEY followed by the sensitivity value for that Data Field. The sensitivity always uses the same units of measure and data type as the matching Data Field.

Requesting permissions for Sensors

Some information provided by sensors may be considered sensitive, i.e., Personally Identifiable Information (PII). Data Fields such as the computer’s location (e.g., latitude and longitude), could be used to track the user. For this reason, Windows forces apps to get end-user permission to access the sensor. The State property of the sensor and the RequestPermissions() method of the SensorManager can be used as needed.

The RequestPermissions() method takes an array of sensors as an argument, so an app can request permission for more than one sensor at a time. The C++/COM code is shown below. Note that (ISensorCollection *) must be provided as an argument to RequestPermissions(). Properties of the SensorDataReport object can be referenced to extract Data Fields from the SensorDataReport. This only works for the .NET API and for “well known” or “expected” Data Fields of that particular SensorDataReport subclass. For the Win32/COM API, the GetDataField method must be used. It is possible to use “Dynamic Data Fields” for the underlying driver/firmware to “piggyback” any “extended/unexpected” Data Fields inside SensorDataReports. The GetDataField method is used to extract those.

Using Sensors in Windows Store apps

Unlike the Desktop mode, the WinRT Sensor API follows a common template for each of the sensors:

• There is usually a single event called ReadingChanged that calls the callback with an xxxReadingChangedEventArgs containing a Reading object holding the actual data. The accelerometer is an exception; it also has a Shaken event.
• The hardware-bound instance of the sensor class is retrieved using the GetDefault() method.
• Polling can be done with the GetCurrentReading() method.

Windows Store apps are often written either in JavaScript* or in C#. There are different language-bindings to the API, which result in a slightly different capitalization appearance in the API names and a slightly different way that events are handled. The simplified API is easier to use, and the pros and cons are listed in Table 6.

There is no SensorManager to deal with. Apps use the GetDefault() method to get an instance of the sensor class.

• It is not possible to search for arbitrary sensor instances. If more than one of a particular sensor type exists on a computer, you will only see the “first” one.
• It is not possible to search for arbitrary sensor types or categories by GUID. Vendor value-add extensions are inaccessible.

Apps only worry about the DataUpdated event.

• Apps have no access to Enter, Leave, StatusChanged, or arbitrary event types. Vendor value-add extensions are inaccessible.

Apps only worry about the ReportInterval property.

• Apps have no access to the other properties, including the most useful one: Sensitivity.
• Other than manipulating the ReportInterval property, there is no way for Windows Store apps to tune or control the flow rate of Data Reports.
• Apps cannot access arbitrary Properties by PROPERTYKEY. Vendor value-add extensions are inaccessible.

Data Report properties

Apps only worry about a few, pre-defined Data Fields unique to each sensor.

• Apps have no access to other Data Fields. If sensors “piggy-back” additional well-known Data Fields in a Data Report beyond what Windows Store apps expect, the Data Fields are inaccessible.
• Apps cannot access arbitrary Data Fields by PROPERTYKEY. Vendor value-add extensions are inaccessible.
• Apps have no way to query at run-time what Data Fields a sensor supports. It can only assume what the API predefines.

Table 6. Sensor APIs for Metro Style Apps, pros and cons

Summary

Windows 8 APIs provide developers an opportunity to take advantage of sensors available on different platforms under both the traditional Desktop mode and the new Windows Store app interface. In this document, an overview was presented of the sensor APIs available to developers creating Windows 8 applications, focusing on the APIs and code samples for Desktop apps. Many of the new Windows 8 APIs were improved with the Windows 8.1 Operating System and this article provides links to many of the relevant samples provided on MSDN.

Appendix

Coordinate System for Different Form Factors
The Windows API reports X, Y, and Z axes in a manner that is compatible with the HTML5 standard (and Android*). It is also called the “ENU” system because X faces virtual “ E ast”, Y faces virtual “ N orth”, and Z faces “ U p.”

To figure out the direction of rotation, use the “Right Hand Rule”:

* Point the thumb of your right hand in the direction of one of the axes.
* Positive angle rotation around that axis will follow the curve of your fingers.

These are the X, Y, and Z axes for a tablet form-factor PC, or phone (left) and for a clamshell PC (right). For more esoteric form factors (for example, a clamshell that is convertible into a tablet), the “standard” orientation is when it is in the TABLET state.

To develop a navigation application (e.g., 3D space game), a conversion from “ENU” systems in your program is required. This can be done by using matrix multiplication. Graphics libraries such as Direct3D* and OpenGL* have APIs for handling this.

MSDN Resources

About the Authors

Gael Hofemeier
Gael is a Software Engineer in the Developer Relations Division at Intel working with Business Client Technologies. Gael holds a BS in Math and an MBA, both from the University of New Mexico. Gael enjoys hiking, biking, and photography.

Deepak Vembar, PhD
Deepak Vembar is a Research Scientist in the Interaction and Experience Research (IXR) group at Intel Labs. His research interests are at the intersection of computer graphics and human computer interaction including areas of real-time graphics, virtual reality, haptics, eye-tracking, and user interaction. Prior to joining Intel Labs, Deepak was a Software Engineer in Software and Services Group (SSG) at Intel, where he worked with PC game developers to optimize their games for Intel platforms, delivered courses and tutorials on heterogeneous platform optimization, and created undergraduate coursework using game demos as an instructional medium for use in school curriculum.

Intel and the Intel logo are trademarks of Intel Corporation in the US and/or other countries.
Copyright © 2012 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.