Version 1.12 of the installer for POS for .NET is available for download here: http://www.microsoft.com/downloads/details.aspx?FamilyID=EAAE202A-0FCC-406A-8FDE-35713D7841CA&displaylang=en
The download from this website contains a self-extracting archive. Once the archive is downloaded and extracted, you will find the following content:
Setup.exe - This is the installer setup program for POS for .NET.
1033 - This folder contains language localization files for the setup.exe installer.
Documentation - This folder contains release notes used by the setup.exe installer.
POSFor.NET - This folder contains the POSfor.NET.msi and related files used by the setup.exe installer.
Res – This folder contains resources used by the setup.exe installer.
VCRuntime – This folder contains the installer for the Visual C runtime.
If you would like to install POS for .NET on your local system, simply use the Setup.exe program to perform the installation. When you run the installer, you will be presented with a number of installation options:
Typical – Installs the POS for .NET runtime components and the PosDM command line tool
Complete – Installs POS all components (runtime, PosDM, and SDK)
SDK – This installs the SDK documentation and sample code
The installer can also be used from the command line or to perform silent installs from within your own installer. To see a list of available options, run the setup.exe with the /? option from the command line. The most commonly used options include:
/ADDLOCAL [feature list or “ALL”] – silent install of the specified features
/REMOVE [feature list or “ALL”] – uninstall the specified features
/REPAIR [feature list or “ALL”] – silent repair of an installation.
The “/ADDLOCAL” feature will add the components specified (if they are not already installed) using a silent install. The feature list is a common separated list and may include one or more of the following options:
Runtime – Indicate the POS for .NET runtime
Posdm – Indicates PosDM management tools
SDK – Indicates the SDK
ALL – Specifies all of the above components
For example, to perform a typical installation one could invoke setup from within their own installation program with the following options:
Setup.exe /ADDLOCAL Runtime,Posdm
Other MSI arguments (such as /s for silent install) may also be passed on the command line.
It is recommended that when installing POS for .NET from another installer to use the setup.exe instead of the MSI. This will ensure that all dependent components (such as the C runtime) are installed and properly configured.
- Sylvester
It was great meeting so many of our customers at Tech Ed 2008. We had a session that was intended as an introduction to POS for .NET, a hands-on lab for developers, and a booth that demonstrated a possible integration of WePOS and POS for .NET in “the lane of the future.”
For those who were unable to attend, I’m going to attach a hands-on lab to this blog. The lab is split into components that target software developers and hardware vendors. Setup instructions are included at the end of the lab. In order to complete the .NET service object and Plug-n-Play portions of the lab, one will need a USB barcode scanner.
The Windows Embedded Marketing team is interested in your POS for .NET experience. If you are interested in sharing your experiences with using POS for .NET, or would like to be considered for a joint case study, please e-mail wepos@microsoft.com.
Thanks,
- Sylvester
Microsoft Point of Service for .NET v1.12 has now been released and is available for immediate download at the Microsoft downloads site.
POS for .NET v1.12 has been updated to be fully compliant with the latest release of the Unified POS specification. New devices that have been added includes:
· Belt
· Electronic Value RW
· Gate
· Item Dispenser
· Lights
· RFID Scanner
In addition the there is now support for encrypted MSR devices as well as some updates to the FiscalPrinter.
- Sylvester
The Unified POS specification, “UnifiedPOS Retail Peripheral Architecture” available at http://www.nrf-arts.org/UnifiedPOS/default.htm, makes a distinction between a Device Name and a Logical Device Name. The device name is expected to be unique among other devices within the same device class. The default value of the Device Name key is the Service Object Name. There are cases, however, where the application or system administrator, may wish to add a level of isolation between the service object and the application. In such cases, one or more logical device names may be created to represent a device. The posdm.exe command line utility provides one way for administrators to assign logical device names.
When writing an code, it is best to avoid any assumptions that all devices will have a logical device name. When attempting to query available devices, it is recommend that one use the logical device name(s) if available; however, if a logical device name is not available, then the code should fall back to the service object name. Finally, if the service object name is not available, the code should fall back to the device description.
Below is an implementation of the GetDeviceDisplayName() method, taken from the sample Test Application included in the SDK, that demonstrates the above logic:
|
static string GetDeviceDisplayName(DeviceInfo device)
{
string name = CombineNames( device.LogicalNames );
if (name.Length == 0)
{
name = device.ServiceObjectName;
if (name.Length == 0)
name = device.Description;
}
return name;
} |
- Sylvester
One common problem that arises when using SMS to manage WEPOS machines alongside XP machines is that there is no simple way for SMS to distinguish the two. Whenever a query is run that specifies XP machines, WEPOS machines will find themselves lumped in too. The following is a pair of methods that help you work around this problem.
The first method is the quick-and-dirty method. WEPOS has a few files that are branded specifically for WEPOS. Executable files are picked up by Software Inventory by default, so it makes sense for our query to look through the Software Inventory for any WEPOS-specific executables. For example, one such executable is WEPOS’s explorer.exe. If we decided to look for the WEPOS-branded explorer.exe, we could use the following query:
select distinct sys.Name, sys.OperatingSystemNameandVersion, sys.LastLogonUserName, SMS_G_System_SoftwareFile.FileName, SMS_G_System_SoftwareFile.FileVersion from SMS_R_System as sys inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceID = sys.ResourceId where SMS_G_System_SoftwareFile.FileName = "explorer.exe" and SMS_G_System_SoftwareFile.FileVersion = "6.00.2900.2647 (xpsp.050404-1634)"
Notice the FileName and FileVersion portions of this query near the end. The file version has been collected from the file properties dialog.
Great, we’ve got our WEPOS machines now, right? Eh, not quite. This solution isn’t workable in the long run for a couple of reasons. First, there’s no guarantee that the versioning on a WEPOS-specific file will always remain the same. If an update is applied to some of your machines which alters the file your query is looking at, those machines will find themselves dropped out of the query. Second, if you have machines with WEPOS installed to a secondary partition and another OS installed to the first, you could wind up with some false positives.
Why consider this method at all? It’s simple, and it will be reliable if you’ve met the right conditions and only need a temporary solution. Perhaps you need run a one-time install of a batch of updates to several fresh WEPOS installations. This query might be all you need. Just be sure to double check that it’s actually doing what you want it to do.
The second method is a bit heavier, but it is much more reliable. With SMS, it is possible to extend the Hardware Inventory to collect other information about the client. Our silver bullet with regards to our problem is to use an extended Hardware Inventory to collect information in the registry about the WEPOS installation, which is found at HKLM\Software\Microsoft\WEPOS. This is done by editing the SMS_def.mof file.
First, some suggested reading:
http://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/default.mspx?mfr=true
http://www.microsoft.com/technet/archive/sms/sms2/proddocs/sms-regx.mspx?mfr=true
These resources describe how to extend Hardware Inventory in SMS. The first link is to the SMS Operations Guide. In the guide, go to (Chapter 2 > Hardware Inventory Administrative Tasks > Configuring Hardware Inventory Rules) for info on editing the SMS_def.mof file in order to customize what Hardware Inventory data is gathered. Also, (Chapter 3 > Extending Hardware Inventory) will provide further information. The second link is to a whitepaper describing how to edit SMS_def.mof in order to collect information from the registry of the client machine during Hardware Inventory.
Here is one example of an addition to SMS_def.mof that will gather WEPOS registry data.
|
//----------------------
// WEPOS Install
//----------------------
#pragma namespace ("\\\\.\\root\\cimv2")
[DYNPROPS]
class WeposInstall
{
[key]string Name = "";
string Value;
};
[DYNPROPS]
instance of WeposInstall
{
Name = "Version";
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS|Version"),
Dynamic, Provider("RegPropProv")]
Value;
};
[DYNPROPS]
instance of WeposInstall
{
Name = "Additional Code Page Support";
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS\\Optional Components|Additional Code Page Support"),
Dynamic, Provider("RegPropProv")]
Value;
};
[DYNPROPS]
instance of WeposInstall
{
Name = "Additional Driver Support";
[PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS\\Optional Components|Additional Driver Support"),
Dynamic, Provider("RegPropProv")]
Value;
};
// And so on...
// Add one of these for every optional component install you wish to report:
//
//[DYNPROPS]
//instance of WeposInstall
//{
// Name = "Optional Component Name";
// [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WEPOS\\Optional Components|Optional Component Name"),
// Dynamic, Provider("RegPropProv")]
// Value;
//};
#pragma namespace ("\\\\.\\root\\cimv2\\sms")
[ SMS_Report (TRUE),
SMS_Group_Name ("WEPOS Install"),
SMS_Class_ID ("MICROSOFT|WEPOSInstall|1.0") ]
class WeposInstall : SMS_Class_Template
{
[SMS_Report (TRUE), key ]
string Name;
[SMS_Report (TRUE) ]
string Value;
}; |
1. Add the text to the end of your SMS_def.mof file.
2. This new SMS_def.mof needs to be compiled on your client machines before they will report the extended hardware inventory. This can be done by creating and advertising a package to all of your clients which:
a. Contains the new SMS_def.mof file, and
b. Runs a program containing the command “mofcomp.exe SMS_def.mof”
3. After the program runs, trigger a hardware inventory cycle on the clients. When the inventory completes, the clients should be reporting WEPOS install information.
After these steps, resource explorer should show a new entry called “WEPOS Install” (this is true for all clients that compiled the SMS_def.mof, not just WEPOS Installs). This entry will display whether or not a particular WEPOS optional components is installed on the client. Additionally, the WEPOS version number is collected here. If these optional component entries are blank, then the machine you’re looking at is not a WEPOS install.
From here, a simple query checking that the WEPOS Install optional components (or version) are not blank will become your “All WEPOS Systems” query. You might also consider updating your XP queries in order to exclude WEPOS systems. And of course, give this a try in a test environment first!
- Ryan
The September 2007 Windows Embedded for Point of Service Supplement Updates are now available on the Mobile & Embedded Communications Extranet (ECE) for Microsoft® Windows® Embedded for Point of Service (WEPOS) 1.0 and WEPOS 1.1.
This supplement includes the following updates:
- KB 928365 Vulnerabilities in .NET Framework Could Allow Remote Code Execution.
- KB 928366 Vulnerabilities in .NET Framework Could Allow Remote Code Execution.
- KB 928367 Vulnerabilities in .NET Framework Could Allow Remote Code Execution.
- KB 933360 Installing this update enables your computer to automatically adjust the computer clock on the correct date in 2007 due to revised Daylight Saving Time laws in many countries.
- KB 939683 Install this update to improve how Windows Media Player manages shortcuts you create and add to the Start menu pinned list.
The September 2007 WEPOS Updates are available at the following link on the ECE:
https://ece.partners.extranet.microsoft.com/ece/ProductDownloads/TheDownloads/Embedded/WEPOS/OEMDownloads/DistOEM-Sept2007WEPOSSupplementUpdates.htm
If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.
- Katy
The August 2007 Windows Embedded for Point of Service Supplement Updates are now available on the Mobile & Embedded Communications Extranet (ECE) for Microsoft® Windows® Embedded for Point of Service (WEPOS) 1.0 and WEPOS 1.1.
This supplement includes the following updates:
· KB 921503 Vulnerability in OLE Automation Could Allow Remote Code Execution.
· KB 933579 Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution.
· KB 936021 Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution.
· KB 936181 Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution.
· KB 936782 Vulnerability in Windows Media Player Could Allow Remote Code Execution.
· KB 937143 Cumulative Security Update for Internet Explorer.
· KB 938127 Vulnerability in Vector Markup Language Could Allow Remote Code Execution.
· KB 938828 This is a reliability update. Install this update to improve the stability of computers running Windows XP.
· KB 938829 Vulnerability in GDI Could Allow Remote Code Execution.
The August 2007 WEPOS Updates are available at the following link on the ECE:
https://ece.partners.extranet.microsoft.com/ece/ProductDownloads/TheDownloads/Embedded/WEPOS/OEMDownloads/Aug07WEPOSUpdates.htm
If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.
- Katy
SJJ Embedded Micro Solutions, one of our Windows Embedded Partners, announced that they have put together a new training course: “Introduction to Windows Embedded for Point of Service / POS for .NET”. Their webpage states that "the course covers the fundamentals and features of WEPOS and POS for .NET." And that there is a specific "focus on POS for .NET 1.11 with support for C# and VB.NET developers."
It is a one day course with dates already scheduled on September 21st and November 2nd. Check out more details here.
If you know of any other courses or trainings covering WEPOS or POS for .NET in your area, please let us know so we can help spread the word!
- Shayna
On Mike Hall's blog last week he announced that the Microsoft Windows Embedded team will be hosting a free food/beer/chat evening event during LinuxWorld. There will be several members from the team there, as well as some of our MVPs to answer questions you may have about Windows Embedded products, including WEPOS, Windows XP Embedded, and Windows Embedded CE 6.0. So if you are going to be around please join them on August 8th from 6-8pm at Jillians. Check out more information on Mike's blog.
- Shayna
An article on Windows For Devices talks about a new Panel PC from Belview Technologies that is available running WEPOS and substitutes a compact flash card for the standard slim-line disk drive. The device is called the PP6500 All-in-one Panel PC, and Belview says that it's perfect for Self-Service applications. Check out either of the sites linked above for more information about the features and specifications.
It's exciting to see more devices running WEPOS!
- Shayna
The July 2007 Microsoft Windows Embedded for Point of Service Supplement Updates are now available on the Mobile & Embedded Communications Extranet (ECE) for Microsoft® Windows® Embedded for Point of Service (WEPOS) 1.0 and WEPOS 1.1.
This supplement includes the following updates:
- KB 923689 - Vulnerability in Windows Media Format Could Allow Remote Code Execution
- KB 936357 - A microcode reliability update is available that improves the reliability of systems that use Intel processors
- KB 939373 - Vulnerability in Microsoft Internet Information Services Could Allow Remote Code Execution
- KB 931212 - .NET update (.NET1.1: KB928366, .NET2.0: KB928365)
The July 2007 WEPOS Updates are available at the following link on the ECE: https://ece.partners.extranet.microsoft.com/ece/ProductDownloads/TheDownloads/Embedded/WEPOS/OEMDownloads/DistOEM-Jul07MicrosoftWEPOSSuppUpdates.htm
If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.
- Katy
Those of you familiar with the WEPOS attended installation process may have seen the “Press any key for a command prompt” screen that appears during the setup initialization. Pressing any key on the keyboard while this message is visible will interrupt setup and give you a command window. From this command window you can perform a number of tasks before you continue with setup. Once setup completes, the focus returns to the command window and you can perform additional tasks before exiting and rebooting the computer.
To take this a step further, you can take advantage of this functionality during an unattended installation by placing the files presetup.cmd and postsetup.cmd into the Setup folder. Let’s use the example where you want your WEPOS system to have two partitions. You could create both partitions prior to your unattended answer file being processed, and format the second partition after the setup completes.
To create both partitions before your unattended answer file is processed; in presetup.cmd you would call DISKPART.EXE to execute a DISKPART script located in the same directory as presetup.cmd. The script would instruct DISKPART.EXE how to create the partitions. Once the script is complete, setup will begin processing your unattended answer file. If you want to install WEPOS onto a partition that you created in presetup.cmd, make sure you use the <ModifyPartition> element within <DiskConfig> in your unattended answer file rather than <CreatePartition>.
The postsetup.cmd file would contain instructions to format the second partition. Call FORMAT.EXE to format this partition. Since FORMAT.EXE prompts the user for a confirmation before proceeding, you can embed the confirmation into the postsetup.cmd script by adding “ECHO Y |”, resulting in a command like “ECHO Y | format.exe /FS:NTFS /V:HDD2”.
After setup is finished and WEPOS has completed the FBA process, you will find a second partition formatted and ready for use.
For information about writing a DISKPART script, please refer to TechNet DISKPART Documentation.
For a complete list of console applications that can be used in presetup.cmd or postsetup.com, look for other .EXE files in the i386/System32 directory on the WEPOS CD.
For additional information of using custom presetup.cmd and postsetup.cmd scripts, please reference the MSDN WEPOS Using Custom Scripts Documentation.
- Terry
The June 2007 Microsoft Windows XP Embedded Supplement Updates are now available on the Mobile & Embedded Communications Extranet (ECE) for Microsoft® Windows® XP Embedded Service Pack 2, and Feature Pack 2007, as well as Microsoft® Windows® Embedded for Point of Service (WEPOS) 1.0 and 1.1 products.
Updates for WEPOS are contained in the DQI folder, and are intended to individually update the WEPOS image.
This supplement includes the following updates:
- KB 929123 - Cumulative Security Update for Outlook Express and Windows Mail - URL Redirect Cross Domain Information Disclosure Vulnerability.
- KB 933566 - Cumulative Security Update for Internet Explorer.
- KB 935839 - Vulnerability in Win 32 API Could Allow Remote Code Execution.
- KB 935840 - Vulnerability in SChannel could allow Remote Code Execution.
- KB 931836 - February 2007 cumulative time zone update for Microsoft Windows operating systems.
The June 2007 Microsoft Windows XP Embedded Supplement Updates are available at the following link on the ECE: https://ece.partners.extranet.microsoft.com/ece/ProductDownloads/TheDownloads/Embedded/XPE/XPEMonthlyUpdates/DistOEM-June2007XPESupplementUpdates.htm
If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.
- Katy
We’ve heard several reports of customers with concerns regarding the Epson OPOS ADK for .NET when used in conjunction with POS for .NET 1.11. Specifically, the Epson Check Health Utility produces the following error when run with POS for .NET 1.11:
CheckHealthTest.exe – Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
Process id=0xbec (6052), Thread id=0xbf0 (3056)
Click OK to terminate, Cancel to debug.
It appears that the Epson CheckHealthTest.exe application is compiled against the 1.x version of the .NET Framework and the POS for .NET 1.11 libraries are compiled against the .NET 2.0 Framework. When the Epson application starts up it loads the .NET 1.1 framework and then attempts to load the POS for .NET binaries which fail because they require the .NET 2.0 framework (only one version of the .NET Framework can be loaded in a process).
The fix is to create a .config file for the Epson application so that it loads to .NET 2.0 Framework when it starts. A sample config file is below. The config file must be named ‘CheckHealthTest.exe.config’ and must be located in the same directory as ‘CheckHealthTest.exe’.
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
You can find more details about this topic in the POS for .NET 1.11 Release Notes (see the .NET Framework Compatibility Issues section).
This code sample is subject to the terms of the Microsoft Limited Permissive License (Ms – LPL). If you do not agree to these terms, do not use the code.
- Shayna
