Windows Embedded POSReady and POS for .NET Blog : Misc

Servicing FAQs for Windows Embedded POSReady 2009 OEMs

posblog — Mon, 26 Oct 2009 15:30:00 GMT

When I go to a monthly update download page for POSReady 2009 on the ECE from April, 2009 or earlier, why isn’t POSReady 2009 listed in the title?

The monthly Security updates for Windows Embedded POSReady 2009, from code freeze through April-2009, do not list POSReady 2009 on the download page Titles themselves. This is because the downloads weren’t mapped for POSReady 2009 applicability until April. Updates since April-2009 do list Windows Embedded POSReady 2009 in the page Title. All of the POSReady 2009 Monthly Updates are linked from here:

https://ece.partners.extranet.microsoft.com/ece/Embedded/Products/ProductSupplements/Embedded/POSReady/POSReady2009Updates.htm

What updates should I install from the monthly supplemental DVD I download from the ECE?

POSReady 2009 consumes the same updates as Windows XP. Windows XP updates are delivered on the Desktop Operating System (DTOS) update IMG, along with all other DTOS updates, including Vista, Windows 7, etc.

Use the Security Bulletin announcements (http://www.microsoft.com/technet/security/bulletin/summary.mspx), particularly the Affected Software, Windows Operating System section, to indicate which of the updates are intended for installation on Windows XP. The only updates that are potentially applicable to POSReady 2009 are those updates targeting Windows XP, x86, ENU.

Even some of the Windows XP updates may not be applicable to a POSReady 2009 environment, since it is a subset of Windows XP technologies. If an update is not applicable, it will not install even if executed on the system. This is also how updating Windows XP works, you may not have everything installed that could be installed on the system, therefore the update technology checks to see if the update is required and only installs when it is.

I’m an OEM, how do I ensure my POSReady 2009 image is up to date with Security updates?

End users depend on OEM guidance and a defined servicing plan with their OEM to ensure they install compatible and necessary Security updates. With this plan in place, their systems stay secure, and maintain industry standard compliance if required.

If your servicing plan for your customers includes Windows Update usage, one choice to bring a system current with security updates is to enable Windows Update on the device, and update the device with all required Windows Security Updates.

Another way to ship up-to-date POSReady 2009 devices is to download the monthly security supplemental update DVDs from the ECE, beginning with October, 2008. Apply each Windows XP, x86, ENU Security Update (see the previous question for information about applicable updates) through the current month prior to deploying your devices. Ensure that you have a servicing plan in place with your end users to maintain the security and integrity of the devices.

-Gina

Technorati Tags: Point of Sale,Point of Service,Embedded

Interfacing with Biometric Devices from POS applications

posblog — Wed, 23 Sep 2009 19:19:00 GMT

Support for Biometric devices (such as fingerprint readers) was added to the Unified POS specification and incorporated into Microsoft’s POS for .NET in version 1.10. This device category allows applications to interface with such devices and is helpful in capturing and verifying biometric data (such as a finger print). This blog will attempt to describe one possible way to interface with this device using POS for .NET. As always, the developer should first carefully read and understand the Unified POS specification for this device category before attempting to interface with the device (See chapter 5 of Unified POS specification v1.13). Also, before you interface with a physical device, you must install a .NET Service Object for the device (contact the hardware vendor to get the .NET service object). Note that legacy OPOS based service objects are not supported for this device category, one must have a .NET Service Object for this device.

First, an application will want to know what biometric devices are available. This can be done using the PosExplorer class. For example, to get an ArrayList of all Biometric devices, one would do the following:

// Create an instance of an explorer synchronizes events to the main form's thread.

explorer = new PosExplorer(this);

// Create a list of all available biometric devices and bind them to the list box

biometricList = new ArrayList(explorer.GetDevices(DeviceType.Biometrics));

Next, an application may want to register for the DeviceAddedEvent and the DeviceRemovedEvent. Doing so will allow the application to respond to plug-n-play events for the device. Once the application has a device, it will need to do the normal open, claim, and enable as well as subscribe to the required events. This can be done as follows:

// Create an instance of the device, open and claim it.

activeBiometricDevice = (Biometrics)explorer.CreateInstance(selectedDevice);

activeBiometricDevice.Open();

activeBiometricDevice.Claim(1000);

// Enable the device, subscribe to date events, and enable data events

activeBiometricDevice.DeviceEnabled = true;

activeBiometricDevice.DataEvent += new DataEventHandler(activeDevice_DataEvent);

activeBiometricDevice.ErrorEvent += new DeviceErrorEventHandler(activeBiometric_ErrorEvent);

activeBiometricDevice.DataEventEnabled = true;

activeBiometricDevice.StatusUpdateEvent += new StatusUpdateEventHandler(BiometricsStatusUpdateEvent);

The above snippet will open, claim, and enable the device. It will then subscribe to desired events and will enable data events. Once this is done one can use the device as desired. Typically, one will use the beginEnrollCapture() method in order to capture biometric data for a given user. This method customarily results in a series of biometric data captures aggregated together returned in the final form of a BIR (see “beginEnrollCapture” method in the UPOS specification for more detail). Status update events may be provided to instruct the user what actions are required during this process. Status information may include indications such as:

· StatusSensorReady – typically indicates that the device is ready for the user to swipe their finger or provide other biometric data

· StatusSensorComplete – indicates that the biometric data has been captured

· StatusMoveSlower – Indicates that the user needs to move slower

· Etc.

After issuing a beginEnrollCapture method one will wish to save the data in the BiometricsInformationRecord property that is available after a data event. This data is associated with the user providing the biometric input and will be used to identify the person when attempting to verify the user. In order to identify a person, one needs to issue a BeginVerifyCapture command to the device. Again Status update events may be provided as well as a data event (if desired, one can end the operation by issuing an EndCapture command). In response to the data event, the application can then pass a list of BiometricsInformationRecord data to the service object via the IdentifyMatch() method to determine if the biometric data provided by the user matches any contained within the list. This can be done as follows:

List<BiometricsInformationRecord> birs = /* Your list of BIR data */

int[] order =

activeBiometricDevice.IdentifyMatch(50, 0, true,

activeBiometricDevice.BiometricsInformationRecord /* current biometric data to match */,

birs /* list of biometric data to check for match*/ );

Where order[] is a list that identifies all users where the biometric data provided matches within the criteria range specified. Well, that is pretty much all that is needed in order to get biometric data from a user (in the form of a BIR) and then to later verify that the biometric data matches a previously provided BIR.

Ever wonder what it takes to release products at Microsoft?

posblog — Thu, 31 May 2007 01:37:19 GMT

Before I came to Microsoft, we always joked about the quality of the software products – “Don’t use V1.0” – everyone has heard that. But now that I’m at Microsoft, I see what goes on behind the scenes to try to make sure the products are release quality before customers get their hands on them. It’s pretty impressive.

Like any company, Microsoft balances shipping products that people want (and often demand!), and ensuring there very few bugs. Everyone knows the longer you test a product, ideally the fewer bugs are in it when it ships. On the other hand, the longer you test, the less chance you get to make the window of opportunity!

First of all, products are built every day. Microsoft builds “from-source” using timestamps in the source control system to ensure they can re-build a product, in a known way. Products are not only compiled and linked, they are built several ways: release-quality, debug-quality, code-coverage, and up to 6 different ways to inform developers and testers that the code being shipped is of reasonable quality, and meets the legal requirements set by Microsoft. Additionally, each day localized versions of the product have to be produced, and frequently each build is run through a set of Build Verification Tests (automated tests to inform the team that the build made the “first cut” or not).

Once the product is “built”, it is then tested using more automation than I’ve ever seen outside Microsoft. The tests cover the GUI and the API parts of the product. Every day, someone on the product team looks over those results and ensures they mean something, and are not just a set of percentages. The automated testing is designed to make sure that the maximum amount of code-paths are executed to ensure the highest ship quality possible. Not many companies invest the time it takes for developers to write test cases, but Microsoft does - it’s a serious investment in product quality!

Manual testing is happening all the time. Because testers are familiar with the product objectives, they catch lots of things that the automated tests don’t. Also, they sit in the same area as the developers, so there is rapid closure of many issues. Testers are often engaged before the product has been formally built the first time – I know that sounds crazy, but by starting early, reviewing what the developers are going to do, and planning the tests cases ahead of time, the testers stay in-step with developers as the product development cycle progresses.

Every product team has a third set of people to ensure the overall product metrics are met. The Test Leads, Development Leads, and Program Managers regularly meet to review all bugs, and ensure progress is being made. This helps us balance business objectives with product quality. Several times quality issues will force a reevaluation of ship schedule, which tells me Microsoft is serious about quality.

Many products go through a “dogfood” phase prior to release – which means that the people inside Microsoft use the product just like customers and provide critical feedback to the development team. Before formal release to customers, Microsoft has a variety of programs in place to allow previews of upcoming releases so customers get a “front row seat” with the product – again, to ensure higher quality in the shipping product!

And finally, Microsoft ships the product! But the quality doesn’t stop there – there is a massive amount of personnel supporting all these products that have reached the customer!

When you think about all the processes used to ensure one product gets out the door to meet the market demand and quality metrics, it becomes truly impressive when you look at the list of products that have shipped to know that all these metrics are applied to every product.

Thanks for letting me give you an inside tour of Microsoft release quality!

- Bruce