[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
There are projects where the purpose of a tiny embedded device is to work robustly as a standalone unit and there are times when embedded devices are required to participate in sophisticated enterprise scenarios. Examples that fall into the latter category could be automation controllers or thin clients. Naturally, these types of devices have very different specifications for both their hardware and software. It is quite surprising that, despite this, a single embedded operating system such as Windows Embedded Standard is able to be a good fit for both use cases, as opposite as they are.
There have been a lot of posts on how to build smaller devices and now it is time to shed some light on the enterprise features of Embedded Standard.
Directory Services – the very core of an enterprise network
Directory Services are found at the heart of every company’s network, because they provide the management system where all user, computer and other system credentials and rights are stored, as well as managed. In a Windows network this directory service is called Active Directory and requires special servers, called Domain Controllers, which are solely dedicated for this purpose. A new developer API to interact with and maintain these services was created at the time Active Directory replaced the older NT Domain model: ADSI.As the name says, it was created as a scripting interface based on COM technology to give administrators fast and easy access to the directory infrastructure. The ADSI syntax can be compared to WMI scripting, because the two technologies were created roughly in parallel.
Here is a simple code snippet that shows how to move the ATL-Users group from the HR organizational unit into the Users container of the same domain:
The first line of code binds the action to the Users container of the Fabrikam domain, which acts as the target. Careful, this approach needs some acclimatization when you start writing scripts!
The second line then moves the ATL-Users group into the target container.
TechNet and MSDN are your friends
There are a lot of valuable script samples on the Microsoft TechNet site on how to accomplish day to day scripting tasks using ADSI. I explicitly state Technet, because developers normally turn to MSDN for coding information. Of course, there is a lot of additional information on MSDN, too, about the programmatic use of this API. Be aware that, due to the nature of the underlying COM technology, the effort required to use ADSI with native code (C++) is much higher than the effort required for scripting languages such as VBScript or Jscript.
There is a managed wrapper for this API, as well. One needs to set a reference to the System.DirectoryServices.dll in the managed project and add this namespace to the code:
After including this, AD is accessible from a managed embedded maintenance application or a custom shell running on e.g. a thin client device.
Including ADSI in an embedded image
There is one important thing necessary to make these code samples work. The ADSI components need to be added to the image configuration from the infrastructure node, as shown below. As one can see, there are additional providers for other non-Microsoft directory services, as well.
This is great, because it enables embedded devices to integrate into 3rd party environments as first class citizens. The footprint impact of ADSI on an embedded image is relatively modest - around 20 MB. The impact of a .NET Framework component is much higher. One should also not forget to include this infrastructure for managed code or the Windows Scripting Technologies in an image.
ADSI Tools
There are some helpful tools available to make a developer or administrator’s life easier.
The ADSI scriptomatic, including some entertainment, comes from the TechNet scripting guys.
Really funny folks over there….
ADSIEDIT is part of the Windows support tools.
It is a lightweight LDAP editor to manage objects and attributes in a directory.
Not only AD!
ADSI provides a valuable way to access and maintain the functionality of Internet Information Server (IIS) or Exchange Server, too. While having IIS on an embedded box is not too unrealistic, running Exchange Server certainly will present at least a licensing problem.
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
An issue was found with the April Security database update for Windows Embedded Standard 2009. Although database updates are not usually provided in odd-numbered months, the Embedded Windows July Security Update DVD image will include a database update for Windows Embedded Standard 2009 which corrects this issue. There are no database updates for other platforms, and as usual, the July security updates will be rolled into the database updates for all platforms in the even-month Security updates for August.
OEM’s who have already deployed Embedded Standard 2009 images built with the April-2009 database update applied, and are experiencing versioning inconsistency, should apply the hotfix, scheduled for release at the end of July to correct these inconsistencies.
- Gina
**Updated at 5:47pm, 7/1/09: Correction-The June updates included both the componentized updates for applying to the database, as well as the updates in the \DQI folders that can be applied to runtimes.
- The downloads in the WindowsEmbeddedStandard\Windows folder are only to be used with the Component Database within the Target Designer toolkit in the Windows Embedded Standard release.
- The downloads in the WindowsXPEmbedded\Windows folder are only to be used with the Component Database within the Target Designer toolkit in the Windows XP Embedded release.
The June 2009 Windows XP Embedded and Windows Embedded Standard Security Updates - Product Download is now available on the ECE for Windows® Embedded Standard 2009 (Std 2009) and/or Microsoft® Windows® XP Embedded (XPe) with Service Pack 2, Feature Pack 2007, Update Rollup 1.0 and Service Pack 3.
This download is a cumulative update which incorporates all updates from prior months. Therefore you do not need to download and install previous monthly updates. These updates can be applied directly to runtimes that include the necessary dependencies.
The Updates in this rollup package are arranged in the following way:
- The downloads in WindowsEmbeddedStandard folder are applicable to Windows Embedded Standard 2009 toolkit and images.
- The downloads in the WindowsEmbeddedStandard\DQI folder contains individual updates for use with Desktop QFE Installer only. Use these updates to individually update the Windows Embedded Standard image.
- The downloads in WindowsXPEmbedded folder are applicable to Windows XP Embedded toolkit and images.
- The downloads in the WindowsXPEmbedded\DQI folder contains individual updates for use with Desktop QFE Installer only. Use these updates to individually update the Windows XP Embedded image.
The June Security updates include:
- KB 969898 - Update Rollup for ActiveX Kill Bits
- KB 971888 - Update for DNS Devolution
- KB 969897 - Cumulative Security Update for Internet Explorer
- KB 970483 - Vulnerabilities in Internet Information Services (IIS) Could Allow Elevation of Privilege
- KB 961501 - Vulnerabilities in Windows Print Spooler Could Allow Remote Code Execution
- KB 968537 - Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
- KB 970238 - Vulnerability in RPC Could Allow Elevation of Privilege
For full details on the June 2009 Embedded Windows Security Updates see the ECE site.
Note: I also want to remind folks that there were no security updates for Std 2009 or XPe released for May 2009.
If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.
Thanks,
- Patrick
This is an issue reported by a customer who’s using XP embedded for a banking kiosk device.Their FBWF overlay was filled up very often and they had to reboot the machine almost every day. They gave 128MB (out of 1GB total RAM) to the overlay. They were wondering if there is a way to clear the overlay without rebooting.
We found the same issue in our internal longhaul testing.Unfortunately, there is no perfect solution to solve the problem. However, there might be a work around -
Customers can check which files consuming their overlay by using ‘FBWFMgr.exe /overlaydetail’ command. They can then check if they need all files in the cache and make their clean up accordingly. Clean-up actions include committing and/or restoring files, or deleting unwanted files . Note that deleting a protected file deletes it only from the cache; it does NOT delete the original file. This way they can reclaim memory used by these files without rebooting.
Please note that FBWF does not provide a way to automatically clear the cache.
If you encountered the same problem, please share with us how you handled it. If you can also share the various components that you have found to contribute a large volume of data to the overlay, we can compile these recommendations and provide them as suggestions for our future releases. Thank you.
- Weijuan
Technorati Tags: XPe,Standard 2009, embedded
A while back I discovered that it was possible to do kernel mode debugging of an OS on a virtual machine (VM) running under Virtual PC using a single computer. Even if you are not concerned with debugging a device driver, kernel mode debugging can be useful for debugging applications on Windows Embedded Standard when a failure occurs in the system rather than the application itself. I have personally used this technique to verify that a Windows Embedded Standard runtime OS has at least began the boot process. I highly recommend the following book for more information on debugging: Advanced Windows Debugging (Addison-Wesley Microsoft Technology Series), by Mario Hewardt, and Daniel Pravat.
Typically for kernel mode debugging, we use two physical devices with a null modem cable connected between the serial ports. In Virtual PC, we can create a virtual null Mmodem cable between the development machine and the Target VM using Named Pipes.
The steps below will walk you through how to setup and begin kernel debugging from a development machine running WinDbg (available here) and a Target VM running a Windows Embedded Standard runtime OS.
Configure the Virtual Null Modem cable
1. Run the Virtual PC Console on the development machine by selecting Start-All Programs-Microsoft Virtual PC
2. Select your Target VM and click Settings
3. In the Settings dialog click COM1
4. Select Named Pipe and enter “\\.\pipe\mydebugpipe” for the value (without the quotes)
5. Click OK
Configure the Target VM for Kernel Debugging
6. In your Target VM add the following line to the c:\boot.ini file (either boot the VM and use notepad or use the VhdMount utility available with Microsoft Virtual Server). If you have the Server Command Line Tools in the target OS Configuration you can see how to use bootcfg.exe to modify the boot.ini file here.
Note that this is one line in the file.
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows Embedded Standard" /noexecute=optin /fastdetect /DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200
7. Shutdown the Target VM
Launch WinDbg
We are going to use WinDbg to kernel debug the Target VM. Download and install it now if you do not have it already.
8. On the Development machine, open a Command Prompt
9. Launch WinDbg using the following command
<install-path-of-windbg>\windbg -k com:pipe,port=\\.\pipe\mydebugpipe,resets=0,reconnect
Debug with WinDbg
10. Start the Target VM from the Virtual PC console and select the Microsoft Windows Embedded Standard [debugger enabled] operating system to start
11. At this point, WinDbg will connect and start to spew some information to the screen
12. In WinDbg, select Debug->Break
13. Now select View->Call Stack from the WinDbg menu to see the current call stack of the OS
Well, I hope this introduction to kernel mode debugging was interesting and enjoyable. I did spare you the need to have two machines and string a null modem cable between the two. With this new knowledge, I suspect that you will find, or create, a need to do some kernel mode debugging in the near future.
- Preston
Technorati Tags: XPe,Standard 2009
In my previous screen cast I focused on importing a sound card driver inf into Component Designer in order to automatically generate a component. This video continues with the theme of interpreting and solving warnings that you receive when importing various kinds of driver infs, using a webcam and a printer driver as examples.
Importing Driver INFs into Component Designer with Windows Embedded Standard ...
- Lynda
Technorati Tags:
XPe,
Standard 2009
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
In any Windows embedded project that has requirements regarding advanced graphics or multimedia you will not be able to avoid the term DirectX. DirectX is the multimedia API in Windows operating systems and can even be found (as a subset) on Windows CE. It is based on the COM standard and therefore can be used from native as well as managed code via Interop.
Early stages
The first versions of DirectX were released in the mid 90’s and were mainly considered a gaming API. At that time MS-DOS based games ruled the gaming world, because of the direct memory access and speed available on this platform. For game developers newer multitasking OS’s such as Windows 95 at that time provided quite a challenge and Microsoft started to offer a set of APIs to make writing games on Windows easier. Over time this gaming API has evolved not only into a game platform, which is used e.g. on the XBox 360 gaming console, but into a multimedia framework that covers a remarkable spectrum.
In Windows Embedded Standard the complete collection of APIs can be found at Software\System\Multimedia&Graphics\Infrastructure\DirectX in the component catalog.
To ensure that all the DirectX components are added to a configuration, a recommended approach is to use the DirectX macro component (below) to include this technology in an Embedded Standard image. The footprint hit for a complete installation is about 70MB, but if one knows the requirements of the game or application well, the dev can include only those DirectX components needed to support the application.
Developing DirectX applications
Gaming and Multimedia are some of the main application fields for Windows Embedded Standard devices and so it makes a lot of sense to have a closer look at developing with this powerful set of APIs. The best place to start is the DirectX Developer Center on MSDN, which provides a good entry point into the fabulous world of advanced graphics on Windows.
A new was released just this spring. Developers that need to dive even deeper should have a look at the Microsoft XNA developer center, which provides essential resources and even an IDE focusing on game development.
DirectX on Embedded Standard
But, there is one thing to be aware of, despite all the excitement. In Windows Embedded Standard the latest and last available version is DirectX 9.0c. The most recent version, DirectX 10, is supported only by Windows Vista, Server 2008 and higher. This means that some of the new, cutting edge functionalities are not available on Embedded Standard, yet. But, no need to worry! Embedded developers are not left behind, because they will be able to catch up as soon as the next version of Windows Embedded Standard (aka Quebec), which is based on Windows 7, is released.
DirectX version troubleshooting
DirectX applications can be very picky about the version of DirectX included in an XP embedded or Windows Embedded Standard image. Therefore, it is good to know which DirectX version the application has been developed against. If running a wrong or older version quite a few applications show a variety of performance issues, strange graphical artifacts, or even effuse to start up.
To find out if the correct binaries are available in an image the DirectX Diagnostics Utility should be included in the configuration, as well.
DXDiag.exe provides a lot of useful information, and can be used to find an error or to check the prerequisites of an application.
When thinking about test and troubleshooting tools, the download of the DirectX SDK contains further system tools, to support advanced usage scenarios.
Graphic card drivers
If there are problems with a multimedia application, the cause may not be solely related to DirectX. Quite often, it is helpful to check with the vendor which version of a graphic card driver behaves well with the DirectX version in the image.
If one gets all the numbers and files matching up, there is nothing that will spoil a splendid embedded multimedia experience!
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
Have you ever heard about Microsoft selling an application server? No? Well, this is because in Windows the application server is part of the operating system! It carries the inexpressive name “COM+ Services” and is located in the Software\System\Application Support node of the component catalog.
There are no settings related to this component and therefore, if you want to use it just adding it to the configuration is sufficient.
History
The former name of COM+ Services was “Microsoft Transaction Server”. This name explains a little bit better what COM+ Services were targeted at in the beginning. The first releases of this technology were able to provide a transactional runtime environment for application components based on Microsoft’s Component Object Model (COM) standard. In this environment components were able to participate in transactions across application and machine boundaries, leveraging Remote Procedure Calls (RPC) of the distributed COM (DCOM) technology.
Services
Over time the ability to have distributed transactions remained one of the features of the application server, while quite a few other functionalities were added to it.
Here are is an overview of the current state as provided in the MSDN library:
This is a long list and therefore the name for the technology was changed in later releases to show that the focus lies not solely on transactions. If one looks deeper into the functionality provided by these services the scope is overwhelming. Therefore, let us pick some interesting ones from an embedded perspective for a brief overview:
· COM+ Transactions - are great to be used, if an application needs to provide data consistency while storing data in different places e.g. updating a song database and the corresponding file store e.g. in a multimedia application.
· COM+ SOAP Services - are able to turn plain COM components into real Web Services. This is a quite compelling approach to integrate (legacy) COM Applications into .NET Framework or web solutions.
· COM+ Object Constructor Strings – You want a safe, but configurable place to store a database connection string? Object Constructor Strings do have the means to provide this.
· COM+ Queued Components - are able to add robustness to an application by storing methods calls even when a requested component is currently not available.
COM+ Services in the .NET world
The arrival of the Internet showed limitations of the RPC communication standard and problems with registration requirements of COM (known as “Dll hell”) brought an end to the COM evolution. But, this does not mean that COM+ Services are dead. They are still hiding beneath the covers wrapped by the System.EnterpriseServices namespace!Because to this, it is not hard to access the very capable COM+ infrastructure from a managed application as shown in the snippet below.
The three required things are a reference set to the System.EnterpriseServices assembly, a transaction initiated by the declarative “[Transtaction]” statement above the method and, lastly, the class must be derived from ServicesComponent. If these prerequisites are met the managed application is, for example, able to create, take part or abort distributed transactions.
Impact on a Windows Embedded Standard image
Com+ Services are a part of the overall Windows infrastructure, which has not been developed with embedded requirements in mind. Therefor, the impact to a Windows Embedded Standard image is significant. The COM+ Services component pulls in additional infrastructure, such as the Distributed Transaction Coordinator (MSDTC), which overall adds up to 80 MBytes. Nevertheless, when you look at increasing compact flash sizes compared to falling prices for these storage devices and the functionality by including the services, overall there still may be a win for an embedded device.
On the other hand, if your embedded project does not use COM+ Services, it is easy enough to leave this infrastructure part out (which is not possible on a Windows desktop system), and save the footprint.
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
As a member of the Windows Embedded team, my business is embedded devices. For fun, I spend way too much time playing video games and following the video game industry. Whenever I can combine the two is always a bonus (this might be a stretch so you will have to bear with me).
About this time each year the video game industry gathers in Los Angeles for the Electronics Entertainment Expo (it was June 2-4 this year). I have had the pleasure of attending in person on several occasions, but I always follow the happenings of E3 regardless. One of the major announcements from Microsoft was Project Natal for the Xbox 360. If you watch the video you will quickly see Project Natal promises gaming without controllers. I am very interested in the concept and how it will apply to traditional games, but I’m not so sure about utilizing the wardrobe selection feature (watch the video). If you look at the end of the video you will see the embedded device that provides the Project Natal functionality. I have already spent more than a few minutes staring at the paused video wondering what is inside that device and how it is doing what it is doing.
BTW, in my continuing attempt to tie business with pleasure I plan on spending some time checking out the new Direct2D API’s for Windows 7 that replace GDI for programming 2D graphics.
- Preston
Technorati Tags:
XPe,
Standard 2009
Available for download is a new Windows 7 Training Kit for Developers. This kit includes presentations, hands-on labs, and demos designed to help you learn how to build applications that shine on Windows 7 by utilizing key features such as:
- Taskbar
- Libraries
- Multi Touch
- Sensors and Location
- Ribbon
- Trigger Start Services,
- Instrumentation and ETW
- Application Compatibility
Want more than the kit and looking to download the Windows 7 Release Candidate? You can get the RC version and a product key for x86 & x64 here from this page.
- Andy
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
During the course of a Windows Embedded Standard project it is common to need to configure the OS image or to read information from the image, be it for documentation purposes or to plan your next steps based on this information. The Windows standard API for getting this information or accomplishing these tasks is called Windows Management Instrumentation (WMI). Think of it as a very powerful tool, like a Swiss army knife, that provides access to nearly all settings and configuration methods on a Windows system. WMI does not only come in handy for devices in the field, but there are quite a few other occasions where this infrastructure is able to provide valuable services creating devices, such as automating post-FBA configuration..
Getting WMI into the image
Windows Management Instrumentation is contained in the WMI macro component found under Software\System\Management\Infrastructure in the component catalog.
WMI is built as an extensible infrastructure, which means that the different Windows subsystems are required to publish their settings with the help of WMI providers and need to follow certain implementation rules. As one can see in the image above, the list of selectable functionalities is quite long. Therefore, when developing an embedded image, only the required technologies should be selected. Otherwise the footprint impact of including all of WMI is huge. A complete installation will add a maximum of 150 MB to the overall image size.
Extending WMI
In highly functional embedded images the idea of having an extendable configuration infrastructure is very interesting. One could write a WMI provider for custom applications or a custom shell to make its data and capabilities accessible via this infrastructure. All you need to do is to implement the required interfaces as specified in the WMI SDK.
Using WMI
But before you get into the game of extending WMI, you most probably would start off using the standard offerings. Here are some samples of common scenarios:
- Automating post-FBA configuration (build process)
- Automate domain join and setting computer name (in factory)
- Listing installed software packages and drivers
- Configuring network settings
- React to system changes using WMI events (e.g. network cable unplugged)
- Change desktop environment
- List processes
- Remote shutdown of systems
- Monitor process creation
- Etc.……
The standard access to WMI is either via scripting or, programmatically, via native or managed code. When using script, WMI leverages its implementation as COM objects, which can be easily scripted with the Windows Scripting host languages VBScript or Jscript.
This script snippet shows how to get and display operating system information via WMI. It instantiates an object of the WMI services with the help of a moniker (which, can be thought of as a smart string that triggers an action in a Windows system). With the help of the returned service object the device then can be queried using Windows Query Language (WQL), which is derived from SQL syntax. The result of this query is a collection of objects which can be enumerated and inspected looking at properties desired.
This is not too complicated, is it?
Detecting Embedded Devices
In the example above there is a property called OSProductSuite, which should catch our attention. If it is set to “OSProductSuite=64” it proves that the system is either an XP embedded or Windows Embedded Standard system. If this number is higher, the system would be running another Windows OS. This distinction is especially important, if one does remote updates e.g. to devices in a local subnet. Checking the OSProductSuite property helps to make sure that only the embedded systems get the patch, as desired and not desktop systems that may be located in the same subnet as well.
In managed code a query for the OSProductSuite property could look like this:
Please note the reference to the System.Management namespace at the top. This pulls in managed wrappers for WMI COM objects and makes these available in C#. The rest of the example is pretty analogous to the scripting snippet.
WMI Resources
One of the challenges regarding WMI is coping with the overwhelming number of possibilities. A good start is to have a closer look at the WMI documentation on MSDN. In addition there is the Scripting Guys site on TechNet (well, officially it is called TechNet script center) and although it focuses on scripting, it contains a ton of valuable documentation, solution snippets and examples, which quite often leverage WMI as the underlying infrastructure. Check it out!
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
Technorati Tags:
XPe,
Standard 2009
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
This post’s focus is on the Internet Information Server Technologies (IIS) macro component, which in fact, is more than a web server. The HTTP server is just one part of the portfolio, which includes FTP services, execution environments for dynamic web pages and web services, as well. Therefore, IIS should be regarded as an application platform for quite a number of interesting technologies.
The complete IIS macro component pulls in about 100 MB of required functionality into a Windows Embedded Standard image. IIS therefore is not a good choice when it comes down to optimizing footprint, but if one just chooses the technologies needed for the individual device the impact can be reduced to a certain extent. However, if you need a more lean approach, for example for ASP.NET hosting capabilities, Microsoft’s Cassini web server sample may be worth a look. It comes as a 217k download and the footprint impact to an OS image is negligible.
Usage scenarios
This brings us to embedded use cases. Why on earth, would one include full-blown IIS in a Windows Embedded image? HTTP/FTP/etc. servers normally are an essential part of data center infrastructure and at first glance it seems strange to leverage this technology on an embedded device. But in fact, it is not. It is better to look at these servers from a different perspective, namely as being access doors for an embedded device to a network or the Internet.
The FTP server, for example, can be leveraged to collect log files from a device, push down system updates or even complete OS image updates. The HTTP server is able to provide a web user interface, which can be essential to headless systems that do not provide other means to access them. In this scenario one is able to leverage a lot of different technologies out of the Microsoft web application portfolio. This starts with developing custom ISAPI extensions which trigger functionality based on the information included in a URL. ISAPI is the IIS API, through which developers are able to access the server’s functionality directly. The extensions provide minimal footprint, a high degree of functionality and good security. They normally are implemented as DLLs in native code.
User Interfaces
Another lean approach for developing a web UI is the use of classic Active Server Pages. This scripting technology leverages VBScript or Jscript, and it dominated dynamic web page creation before ASP.NET arrived. It is infamous for spaghetti code, mixing presentation as well as application logic on an HTML page, but nevertheless it works fine for simple to advanced presentation tasks.
<% @LANGUAGE="VBSCRIPT" %>
<% Option Explicit %>
<!--#include File="adovbs.inc"-->
<HTML>
<BODY BGCOLOR="White" topmargin="10" leftmargin="10">
<!-- Your ASP Code goes here -->
<%
Dim Source
Dim Connect
Dim Rs1
Source = "SELECT * FROM Authors"
Connect = "Provider=sqloledb;Data Source=srv;" & _
"Initial Catalog=Pubs;Integrated Security=SSPI;"
Set Rs1 = Server.CreateObject( "ADODB.Recordset" )
Rs1.Open Source, Connect, adOpenForwardOnly
Response.Write("Success!")
%>
</BODY>
</HTML>
The code snippet above shows how a simple database call could look like from an ASP page.ASP is included in the IIS Web server component and requires the Windows Scripting engines, which are about 1MB of additional footprint. If one wants to create state of the art web applications on IIS, ASP.NET can be used to implement compelling user experiences leveraging the full power of a managed environment. But keep in mind that the footprint impact is significant. ASP.NET always requires the full corresponding .NET Framework version. More resources for this technology can be found at the MSDN developer center or the official ASP.NET site.
Web Services
With ASP.NET the infrastructure to create not only UIs but Web Services is brought to an embedded device, as well. This is a very interesting usage scenario on connected embedded systems, which, with the help of suitable web services, turn into functionality nodes. These nodes then can be used by applications or others nodes to create agile systems and solutions.
Security and operations
Quite a while ago, IIS was infamous for the number of exploits and hacks targeted at this technology. Due its prominent role in Microsoft’s internet strategy it was, and still is, an interesting target to hackers and all sorts of malware programmers. Microsoft has addressed this very thoroughly by not doing a default install of IIS to all Windows systems as well as numerous security improvements and fixes. Nevertheless, providing a functionality gateway to the Internet always raises certain security issues. But, there is help! A lot of best practices, tools and resource kits are available on TechNet and Microsoft’s IIS site www.iis.net to address these issues. By applying best practices and protection mechanisms, is it not a problem to run embedded or other systems with IIS in a robust, reliable and secure fashion.
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
Technorati Tags:
XPe,
Standard 2009,
IIS
I’ve recently read a few books on engineering and thought it might be worth sharing what I thought of some of them with our community. So here are my reviews of three books; hopefully you’ll find the reviews useful.
The Pencil by Henry Petroski is commonly found on suggested reading lists for engineers, but I feel it is not his best work. I enjoyed much more the other two books I’ve read by Petroski – The Evolution of Useful Things and Success through Failure, the Paradox of Design.
In The Pencil, Petroski attempts a detailed study of the history of the design and manufacturing of what was an essential tool for engineers. His purpose is to illustrate that even with a mundane object like a pencil there are genuine and significant engineering problems in its production. He succeeds in making his point. However, an underlying theme is revealed in this effort, but left to the other two books to be explored in greater detail.
In The Evolution of Useful Things, Petroski examines the history and development of several ordinary objects to convincingly make the point that the “evolution of form begins with the perception of failure”. By tracing the history of objects like the paper clip, Petroski is able to show how each successive design was an attempt to remedy failings of its own antecedents. This process has culminated in the modern paper clip which, while certainly not the perfect design, has not been supplanted for more than 100 years.
In the third book, Success through Failure, Petroski studies both successful and failed designs of large and small objects. By defining failure as an “unacceptable difference between expected and observed performance”, he proceeds to make the case that the most successful designs are ones which are “based on the best and most complete assumptions about failure.” Later, Petroski goes even further to say that:
There are two approaches to any engineering or design problem: success-based or failure-based. Paradoxically, the latter is far more likely to succeed.
Perhaps it’s because I’ve spent much of my career thinking about how things can fail, but Success through Failure is my favorite of the three books. I particularly liked the discussion of how an unanticipated, shall we say, use case scenario embarrassed a security device company.
Read and enjoy.
-Jim
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
In my upcoming blog entries called “Component Tales” I am going to pick prominent components from the Windows Embedded component catalog to highlight some important facts. The first pick is a real interesting one: Microsoft Internet Explorer.
Love and Hate
It is remarkable that the selection of an Internet browser sometimes leads people right into religious discussions. But, in this post the focus is on functionality!
In a clean installation of Windows Embedded Standard 2009, Microsoft includes IE version 6.0 and 7.0. Note that if you are upgrading from a previous version of XPe that has IE6 to Standard 2009 you have the choice of staying with IE6 or upgrading to IE7 during the installation, but if you already have IE7 installed on your XPe system and upgrade then you will automatically get IE 7.0. If you need an earlier version of the browser but you have already upgraded to IE 7.0, because for example this version is your company standard, there are two was to achieve this: Either use XP Embedded with that IE6 version or build a Windows Embedded Standard image without IE7 and install the earlier browser version after running FBA using an installation package. The second approach might be the better approach, because it still guarantees that the newest patches and hot fixes are included in the image. The caveat here is that all the dependencies for IE6 need to be satisfied in the image you build.
While a lot of users like the good web site compatibility of IE, administrators fear the countless number of exploits lurking on the web. Therefore, it is a best practice to harden your image from a security perspective as described in one of my previous posts. Additionally IE security best practices as documented in TechNet apply for Windows Embedded Standard images, too. But, do not be afraid! With the help of the Embedded Enabling filter features there are more means to defend against security threats on a Windows Embedded Standard device than there are for desktop systems.
Footprint Monster, but Functionality Hero
Adding the Internet Explorer Technologies macro component does not result in lean image footprints. The dependencies pulled in by the IE macro add 292 components, requiring 165 MB of storage in an image.
This clearly shows that modern browsers should not be regarded as thin clients but as dynamic rich clients. The footprint penalty comes with a lot of valuable functionality, which in most projects is worth the cost. The macro pulls in a lot of functionality that would normally be present in an average embedded image, because other components also reference items, such as GDI+.
Kiosks
A very popular use case for IE on Embedded Standard is in kiosk or digital signage systems. Here IE can be used e.g. as a “custom” shell running in kiosk mode using a command such as:
"C:\Program Files\Internet Explorer\IExplore.exe -k http:\\www.wechsler-consulting.de"
In kiosk mode IE runs full-screen and cannot be closed easily (well, one can kill the process if you have administrative rights or use various hotkeys to do so, but the average kiosk user would not be doing that). Of course, for a more locked down solution you could create a custom component with IE as your shell and restrict user access through autologon, security templates or group policies.
A nice start page for IE, as well as other settings, can be pre-configured in Target Designer.
More IE settings are available via the standard dialogs after running through FBA or, in a more direct way, editing the registry.
Application Infrastructure
Speaking of custom shells or applications, Internet Explorer can be leveraged as a very powerful application component, as well. Put a complete web browser into your shell or application!
This picture shows a C# application using the web browser control of Visual Studio 2008, which relies on IE in the background to render a given URL. Using this managed IE browser object it is quite easy to navigate the web from within a custom application. In fact, it is just a single line of code that needs to be added to the Visual Studio Windows Forms project template containing a browser control and a button.
A simple click on the “Go Home!” button, navigates directly to the Windows Embedded home page on MSDN. No magic! Powerful for developers, isn’t it?
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
Technorati Tags:
XPe,
Standard 2009
The first post in the Windows Embedded Installer Testing series discussed a detailed level of the testing process that the installer undergoes. The purpose of this second post is to give a higher-level view of this process by introducing the automation test framework used in testing the installer along with many features of Windows Embedded Tools. Implementing automated tests has many advantages which include:
- Removing the risk of human errors in testing.
- Providing consistency with respect to which tests are run on a frequent basis.
- Reducing time and cost of running the test and thus allowing the test engineers to have more allocated time to develop and run more tests.
- Allowing the ability to run tests simultaneously on multiple platforms in an efficient way. This includes overnight stress and other types of tests.
- An important point mention here is that as much as it sounds great to have all of our existing planned tests automated, it is rarely the case where all the test cases for a specific feature are automated. In some cases, developing and maintaining test automation can lead to more effort being put on the automation process than what is actually required to run the tests, and there lies the responsibility of each individual test engineer in determining which way would be the best way to proceed with when she/he is creating the test plan of a specific feature.
The framework:
At Microsoft, there is a test automation framework that is internally developed and heavily used throughout different teams across the company. Much like any other test automation framework, this tool functions as follows:
- A controller machine controls and monitors the testing process and gives an in-time updates on the status of the network and the test cases being run.
- One or more client machines which can have different platforms and which will run the assigned test cases and reply to the controller with the test results.
Fig. 1
Fig. 1 gives a visual representation of the process mentioned above. In the case of running test cases for the Windows Embedded installer, the test client machines are usually running the installer specific test cases such as installing/file checking/uninstalling simultaneously and reporting back the result to the test controller PC where the test engineer monitors those test to ensure that the installer’s quality is meeting the expected high quality metrics.
Finally, for readers who are interested in learning more about test automation frameworks and to have some hands-on experience in it, I recommend trying out some of the open source automation frameworks. STAF (Software Testing Automation Framework) is one of the many open source frameworks that you can find online. More information about STAF can be found here http://staf.sourceforge.net/
-Sami
Technorati Tags: XPe,Windows Installer,Standard 2009,Testing
