We-Dig.org RSS SP Feed

The Changing world

Everyone is saying the world is changing...it is getting smaller because boundaries are disappearing and new ways of communication are possible.

But are we aware that this is changing the people of the world as well?

We can setup meetings all across the world using many differnet devices and get back to our lives in no time. What are we doing with our extra time? well we work even more. The more we work the less time we spend with life's essential parts: Family, Love, Kids, Games.

And to compensate we are introducing the same technologies to exactly these parts of our lives...rushing them into new dimensions they were not meant for.

The result is a constant rush that we cannot escape anymore. If you check recent divorce rates, you will understand what I mean. We rush through these important parts of our lives, in speeds, our ancenstors could not even imagine.

Times have changed because the world has changed...finding a soalmate for former generations was nearly impossible and so they settled with the best to find. These days, you have many ways of finding the one. But we still tend to settle with compromises. Once recognized, we fix it by divorce - plunging our generation's kids into an even worse cycle of mistrust and carelessness.

What can we do to fix this?

Short answer...nothing!

Humans are a destructive race...not because we want to - but because we are curious to try. Curiosity is our greatest gift but also our greatest danger.

Yes, we will try to find out if we can clone a human...

Yes, we will try out how artificial intelligence in robots can advance a human "replacement"....

Yes, we will try out anti-matter reactions....

because if we will not do, the next one will do. There is no escape from human nature.

Lets take computer science

in the 80s developers were tuning code on the level of assembler commands. A saved command was a faster program. Than the new higher level languages came (like C or C++) and we took a step back to be happy to understand our C code. What the compiler generated was not interesting anymore...and for many C developers its still a riddle why a compiler is still necessary.

BASIC and other interpreted languages go the next mile. Now we trust in runtimes some other party wrote to handle our program code. We do not even know how these runtimes were written.

.NET is the next evolution of this paradigm. We now write code that gets jitted into an intermediate language (IL) that than runs on a runtime....another abstraction between the original idea, source and the running assembler code.

The next step is visible on the horizon....Modelling! Connecting little graphic block with lines and the tool creates all the code for us. This is still in its infant ages but in a couple of years it will be our main way to develop applications.

If you hire a student from an acadamy or university...is he still able to debug all we way down all the stacks to the assembly code? Not sure! But soon I am sure he will not be able...Because we loose the touch to the basic elements of computing.

Now to close the loop to my initial points of this article. The main reason why this student cannot debug anymore is that it takes way too much time! Application Development Cycles have shorten. Test Cycles have shorten because the amount of competition on the market has increased dramatically. If you are not done in time...your competitor will be. Leading to "RAD" development over quality development. Sure, over time the RAD tools will become better, faster and more reliable. But always with the next beta version of the next generation ahead, there will never be an end to the "tools" and "stacks" evolution.

Again, we have no means of stopping this. The world has become so small that even the slightest software idea can be replicated and evolved in another part of the world in no time.

If anyone still things, the cyberworld is only for computers...think again!

What can we learn from all this?

Use the tools wisely! Yes, the world has become smaller...yes, we can talk across the globe with out soalmate. Use it to talk longer and deeper to find out more about the other side. The more time we spend with each other - the more we understand that in the end, all technology was always meant to serve us, not itself.

Meeting Notes: Security Analysis and Windows Embedded [mtg #35]

WE-DIG / Seattle - Meeting #35

Meeting Report by Paul Yao

Security Analysis and Threat Modeling

A Presentation by Steven Yee,

bSquare Corporation

The topic at the August 2007 meeting of WE-DIG/Seattle was security. The speaker who gave the main presentation is someone who currently works at bSquare, which is known as one of the bigger consulting shops for Windows Embedded development. At least, that is how I introduced Steven Yee at the start of the meeting. In fact, my brief introduction did not do justice to his experience and time spent working in the area of software security. Fortunately, Steven was quite happy to fill in the blanks.

Steven worked at Microsoft for 3+ years, as a program manager for Windows Live One Care. This Microsoft product watches over a desktop PC for a wide range of threats, from wicked malware to the semi-innocuous threat of you forgetting to back up data. After he described his experience on the Windows Live One Care team, Steven pointed out that good security practices are the same whether you are developing for the desktop or for devices. Since he was speaking at the WE-DIG/Seattle group, however, he used an example of a Windows Mobile phone. [By the way, this is similar to the talk that Steven delivered in May 2007 at the Mobile and Embedded Developers Conference (MEDC) in Las Vegas.]

While the media gives a lot of coverage to security failures on desktop and server systems, embedded and mobile devices are not completely immune to threats. By way of example, Steven showed a chart that listed the malware which has been identified on mobile phones. From the first virus that targeted Symbian phones in June 2004 until today, his chart showed a total of 170 different types of malware. Compared to the number of threats on desktop and server systems, this amounted to little more than a rounding error. But we should not grow complacent, because as mobile phones and other embedded devices become more sophisticated, so will the number of attacks against them increase. For example, within a week of its introduction, there was already a malware attack against the Apple iPhone.

Just how big an impact has there been from malware? Steven showed us a graph which suggested that the overall cost to business from malware has grown from US$ 500 million in 1995 to US$ 14.2 Billion in 2005. What exactly was covered by such a huge figure? Steven gave a list which included:

Recovery - time spent restoring the attacked systems,
Productivity - what was lost while such systems were down,
Direct Revenue Lost - Steven mentioned that Amazon sells something like US $1 million every hour, and so downtime for amazon.com directly translates into lost revenue (this was simply by way of example; no specific downtime for Amazon was discussed),
Tools - Infrastructure and utilities needed to backup, restore, and protect against future attacks,
Consultants - Hiring security consultants to help design and implement good security practices, and
Loss of customer trust - sometimes referred to as an intangible or "goodwill", customers who have been burned will probably go look for another vendor - presumably one who is able to operate a more secure computing environment.

===== The Security Analysis Process

Steven described a five-step process for analyzing the possible threats to a system. Ideally, these steps should be undertaken during a project's design phase, when the impact on project costs and schedule are lowest. However, this approach can be retrofitted to a project that is underway or even to an existing system. These steps are integral to the Security Development Lifecycle (SDL), which describes the approach that Microsoft has adopted in developing all of its software. The five steps are as follows:

1) Identify Assets to Protect

2) Estimate the Value of the Assets

3) Identify Potential Threats

4) Evaluate the Likelihood of Threats

5) Define the Mitigation Plan / Strategies

The more you learn about security, the more you realize that nothing is ever perfectly secure. Or, as Steven put it, security is never about protecting everything 100%. Instead, it is about identifying potential threats, weighing the costs of protection, and putting in place measures based on a systematic cost/benefit analysis. While such knowledge might make you feel uncomfortable, having a false sense of security is the greatest problem to worry about. From such a position, it would be easy to justify not doing anything to improve the situation. And yet, compared to inaction, almost any action that attempts to mitigate potential threats will improve the intrinsic security of a system.

To help illustrate the use of the security analysis process, Steven walked through the five steps in the context of a Windows Mobile phone. The accompanying table summarizes his comments.

Step	Windows Mobile Phone
1) Identify Assets to Protect	Cost of the device itself. And while substantial (upwards of US$ 500), the assets that truly need protecting are probably the data on the device, plus whatever network access might be possible using the device. Data. Financial data such as credit card numbers, bank account information, or social security numbers. Some data may be protected by privacy laws (such as HIPAA for medical data), by corporate accountability laws (such as Sarbanes-Oxley). Applications. The ability to run some applications may allow access to the data on the device, or on a corporate network.
2) Estimate the Value of the Assets	Q. Can data that is lost be recovered? Q. How long does it take to recover the data? Q. What is the cost to recover the data? Q. What is the impact of disclosure of data to third parties (which may include your competitors, or bad guys intent on doing illegal activities)?
3) Identify Potential Threats	Device Loss. With a mobile phone, device loss is clearly a threat. By one estimate, 100,000 mobile phone were lost in London in the year 2005. In the USA, the FBI loses 3 to 4 laptops every month. Data Disclosure. When a mobile phone is lost, the contents of the phone might be accessible - especially if the phone is not password protected. A device might contain emails, documents, spreadsheets, etc.
4) Evaluate the Likelihood of Threats	As Steven pointed out earlier, nothing is 100% secure. Whether owing to neglect or to malevolent intent, lapses in security do occur. There is no way to protect against every possible lapse. But because resources are limited, it is important to think about the probability of various kinds of threats, and to use such an estimate to help decide the priority by which the various threats need to be addressed.
5) Define Mitigation Strategies	The end result of this analysis will be a set of strategies, rank-ordered by priority, for mitigating each of the threats. Some suggested mitigation strategies include things like: Password - use passwords for mobile phones, laptops, and other systems which contain sensitive data. Enforce a policy of automating password protection, such as with an inactivity timer. Encryption - protect important data using encryption. Secure authentication is needed, of course, since encryption relies on having a method of distinguishing authorized users from unauthorized users. Remote Wipe - allows a signal to be sent to destroy data on lost or stolen device.

===== Mitigation Strategies for Windows Embedded

While most of the talk applied to all kinds of computing devices, Steven commented on some features which are specific to Windows Embedded operating systems. From the standpoint of security, some have argued that Windows-based desktop PCs are an attractive target because of the large installed base - 95% of desktop PCs run some version of Windows. The thinking goes that a virus that affects one Windows PC can potentially affect all Windows PC. And the large number makes them an attractive target to malware creators.

Unlike Windows-based desktop PCs, Windows Embedded devices are not homogenous; there is, instead, a high degree of customizability that is possible for all Windows Embedded operating systems. If you buy into the "homogenous means more vulnerable" argument, then by extension "customizable means more secure."

In both Windows Embedded CE and in XP Embedded, each platform can be configured with just the set of components which are required for the needs of that platform. A headless industrial controller, for example, does not need the GUI elements that Windows CE provides, and so those components can be omitted. A thin client with no need for local storage can be configured to have no available storage space. These kinds of variations help reduce the risk - but does not completely eliminate - the possibility of having malware targeted at a broad range of embedded platforms.

The reality, however, is that threats exist that target mobile and embedded devices. Like on desktop and server PCs, where there is something of value, someone will attempt to gain control of that value. As such, threats against mobile and embedded devices will continue to grow and evolve. Windows Embedded provides mechanisms for locking down devices, including the following:

Windows Embedded CE supports (but does not require) a trust model, to allow only trusted modules to run on a platform.
Windows XP Embedded has its Enhanced Write Filter (EWF) feature, to allow devices to be deployed with a static, unchangeable operating system image.
Network Firewalls - For network-connected devices, Steven suggested that firewalls are a necessity. Both Windows Embedded CE and Windows XP Embedded suppport software firewalls. For the maximum protection, a hardware firewall is also suggested.

===== Summary

Once upon a time, computer security meant simply the physical security of the hardware. Today, physical security is still important, but is insufficient by itself. Physical security must be supplemented by electronic measures - meaning both hardware and software - to more fully protect computing assets. Steven briefly mentioned something called the "Botnet", to refer to the collection of Internet-connected computers which are "owned", meaning controlled by someone other than their rightful owners. As long as there are assets of value, there will be someone attempting to harvest and use them. Security is not an optional or extra part of the software development process. Your software - and the hardware it runs on - has value, and it adds value; protecting that value is a necessary and crucial part of how you design, develop, and deploy your systems.

Other Resources

Software - Microsoft Threat Analysis & Modeling Tool (click for Download page)

Book - Writing Secure Code, by Michael Howard and David LeBlanc

Book - Threat Modeling, by Frank Swiderski and Window Snyder

The Tangle of Wires

Most technical types do not read the Wall Street Journal, prefering instead to read more technology-oriented magazines. I enjoy reading the WSJ for the great business articles, which are the best bar-none.

The one nod that WSJ gives to technology is in the form of a weekly column written by Walter Mossberg. He gives grandfatherly advice about how to pick a mobile phone, fix problems with hooking up peripherals to computers, and other end-user-oriented advice. Walt seems to me to have an anti-Microsoft bias, so I generally ignore his column.

Quite by accident, though, I happened to read this one. Walt has almost redeemed himself in my eyes. And - especially if we get some STANDARDS that help solve the rats nest of charger wires - I will completely absolve him of all past trespasses. [Note to Walt: this is not a get-out-of-jail card for whatever future articles you may write!]

A brief excerpt of that article appears below. If you want the full story, you'll have to buy the paper. Or better yet, do like I do and subscribe to the online edition.

Respectfully,
Paul Yao

=========================================================

June 29, 2006

PERSONAL TECHNOLOGY

By WALTER S. MOSSBERG

It's Time to Reduce
The Tangle of Wires
We Use for Gadgets
June 29, 2006; Page B1

I was interviewing Howard Stringer, the CEO of Sony, on stage at The Wall Street Journal's "D: All Things Digital" conference a few weeks ago, when domestic guru Martha Stewart rose to ask a question. Dipping into a shopping bag full of charger cords and electrical adapters for the electronic devices she carries -- laptop, cellphone, digital camera, BlackBerry -- Ms. Stewart asked Mr. Stringer why each device requires a different, and incompatible, charger.

"Why can't this thing be this thing?" she asked, holding up two identical-looking, but very different, charger cables. The audience of high-tech executives, identifying with her complaint, applauded.

Mr. Stringer, to his credit, said he, too, sometimes felt he was drowning in cables. He said he had been unable to locate some medication in his briefcase on his flight to the conference because the pills were buried under a rat's nest of cables and adapters for his various Sony gadgets. "So, I'm my own victim," he said. "I think it's a fair question."

(For the complete text, please see the June 29, 2006 edition of the Wall Street Journal)

[Mar-06] Mtg: What's New in Windows Mobile 5.0 and Platform Diff Wizard

WE-DIG - March 2006 Meeting March 1, 2006 - Redmond, WA. At the March 2006 WE-DIG meeting, the theme was Windows Mobile 5.0 development. Two speakers presented at this meeting: Paul Yao (who also wrote up this summary) and Mike Hall.

===== What's New with Windows Mobile 5.0?
Paul Yao used WINDIFF to highlight new features being introduced with Windows Mobile 5.0. The technique is not limited to Windows Mobile development, but can be applied to compare the differences between any two Windows CE-powered devices. The only thing required is an SDK for each target device.

Because the theme of the meeting was Windows Mobile 5.0, Paul showed comparisons between these devices:
. Windows Mobile 5.0 Power PC
. Windows Mobile 5.0 Smartphone
. Windows Mobile 2003 Pocket PC
. Windows Mobile 2003 Smartphone

Assuming that you have access to the SDK, the technique involves dumping, massaging, and then comparing the contents of the library (.LIB) files from each SDK. [We plan to make these files available for download; check back in a few days.]

Tools - What You'll Need
If you want to use this technique yourself, the tools you need are readily available with the Microsoft development tools, including eVC++ 4.0 and Visual Studio 2005. You need the following:
. dumpbin.exe
. A text editor
. windiff.exe

Discovering Supported Functions
To compare the supported functions on two devices, start by creating a set of text files that contain the exported function for each library. Open an MS-DOS command prompt, and set the current directory to the directory that contains the .LIB files for a target device. This example shows the steps for a Pocket PC 2003:

c> cd \Program Files\Windows CE Tools\wce420\Pocket PC 2003\Lib\Armv4
Get a list of the .LIB files, with the output redirected to a file. The use of the /b switch retrieves the files in bare format, to get just the file names:
c> dir *.lib /b > dumplib.bat

After the command has executed, the file dumplib.bat contains a list like the following:

authhlp.lib
aygshell.lib
btd.lib
. . .

With the .BAT extension, this file could be an MS-DOS batch file. It is not a proper batch file yet, since it just has file names. The next step is to call a character-mode utility, dumpbin.exe, for each of the libraries named in the file. And we redirect the output of the utility, saving it to a file so that we can later use it. When done, the first few lines of dumplib.bat look like this:

dumpbin /linkermember:1 authhlp.lib > authhlp.dat
dumpbin /linkermember:1 aygshell.lib > aygshell.dat
dumpbin /linkermember:1 btd.lib > btd.dat
. . .

When all of the lines in dumplib.bat have been modified so that each is a proper command, you run the batch file to create a text file for each library file. Within that text file is a list of the public symbols defined for the library.

Study the output for one of the output files. You see that there is a list of function names, which is what we are interested in. There are also some extraneous items, such as a header of a dozen lines or more; there is also summary information, made up of five or six lines. There is also address information for each public symbol.

If you just want a list of public functions, then you are done. But if you want to compare the public functions from one platform (say, Pocket PC 2003) with the public functions from another platform (Windows Mobile 5.0 Pocket PC), then you have to remove all of the extraneous information. There may be an easy way to do it; I could not think of one, and so I edited each of the files by hand. It was somewhat tedious, but it only took 2-3 hours. At the end, what I had was a set of files that gave me a pure list of public functions for each of the libraries on the platform.

You can download the files I created, and compare them (using a tool such as windiff) to compare the set of supported functions between Pocket PC 2003 and Smartphone 2003, or any other combination that is useful to you.

===== Windows CE 5.0: Platform Diff and New Wizard
In the second half of the meeting, Mike Hall demonstrated a tool that he created. Mike created his tool to help manage Windows CE platforms configured with Platform Builder. At issue is that he needed a way to (a) compare two platforms, and also (b) make it easy for others to replicate a platform configuration.

After the meeting, Mike was so stoked about his new tool that he promised to post info on his blog. He's a man of his word, and you can find more details on this tool - as well as download the tool - in Mike's blog (navigate to http://blogs.msdn.com/mikehall/archive/2006/03/02/542414.aspx).

Event Report: The Microsoft Feature Community Summit

WE-DIG at the Windows Feature Summit

Last week, Microsoft invited the web-master of several community and user group web-sites to Redmond and briefed them on the latest Windows client technologies.

While the focus of the summit was on the desktop side of the Windows Client, nearly all of the web-masters had mobile device interest, too. And to my very pleasant surprise there were even two sites represented that are like WE-DIG in the embedded space: MobiDogs.com and WindowsForDevices.com.

Most of the presentation were around the Digital Media part of the Windows Client like the new Media Player 10, the Windows Media Center Edition, the Portable Media Center and the new MSN Music service on MSN.com. Many of the technologies shown will not have an immediate effect on Windows Embedded or Windows Mobile until their next releases with the exception of the new Media Player 10 that is shipping with some of the new Smartphones (i.e. the AT&T Audivox) and Pocket PCs (i.e. the Dell Media Pocket PC). XP Embedded SP2 is shipping with the Media Player 9 and so did Windows CE 5. Both embedded OS could ship an addon-pack for MP10 if there is enough demand from device manufacturers.

As you will see in upcoming articles from me, my passion area, the Windows Media Center Edition (MCE), had a big focus on the summit and most of the attendees had a MCE installed already. The new version 2005 that had just been released in October is Microsoft's first good shot at the HTPC (Home Theatre PC) market. As usual it took Microsoft three versions to get it right. But if you look how much activity around MCE is on the web or the newsgroups is just ramping up these days, you will find that they are no minute too late. Next year HDTV will be the "consumer driving" technology and MCE2005 has already quite good support for OTA (Over the air) HDTV. Additional, HD gaming has entered the home and titles like Doom3, UT2004, FarCry and the brand new Half-Life2 are titles just demanding to be played on a big-screen TV with 1080i resolution.

What is the embedded story of MCE?

well...as of now ...simply non existent!

If you have been attending the XPE WE-DIG meeting, you know that I am an advocate for adding the MCE components to XPE in order to give device vendors the opportunity to build really cool set-top boxes. MCE 2005 is still a PC and once you start installing broken codec packs your stability goes down. For a good MCE solution to reach mainstream home market, a "closed" or better locked-down set top-box is required. Check out the Denali Edition HDTV Media Center PC from Niveus Media (http://www.niveusmedia.com). This box is currently the highest end MCE you can buy and if you look closely on Niveus' website you will find an interesting Pocket PC remote control solution for the MCE.

The new MCE Extender (MCX)....

The MCE Extender is an optional component for MCE 2005. Its either a standalone set-top box (aha! so for your bed-room you can get a closed-lock-down box, so why not for the living room as well?), or software title for the X-Box in conjunction with the MCE remote and the old DVD-Addon. I ran into a store and bought myself the X-Box MCE Extender to be able to play my videos and DVDs in my kids room. Unfortunately I was pretty disappointed by it because it could not handle the exact three things I am using my MCE for:

HDTV Recorded TV (well, I can accept this. Neither the XBox nor the standalone set-top MCE are powerful enough to decode this huge stream on-the-fly)
DVD (such as family DVDs) stored on the PC. The MCE in the family room can do it just fine, the extender does not show anything
Videos compressed in a different format than WMV. Well, if the WME9 encoder would work flawlessly there might be more content out there in WMV but right now Divx is the first choice for any media encoding and not supporting this format is a big oversight. It is also a bit strange since the family version of the MCE supports Divx without codec pack since version 2005.

Another problem with the MCX is the fact that I have not yet been successful accessing any content on a server. The reason is that each MCX (and you can have up to 8) has its own user account on the main MCE PC. During the installation of the extender Software this account gets created automatically and a unique password is created as well. Without a password, I cannot give permission to that account on any other PC/Server. I have started a thread in the newsgroups on how to make this possible (some extender startup scripting that creates a mapped drive to the other PC ....or what ever we will come up with). Also watch www.thegreenbutton.com and www.microsoftusernetwork.com for updates on this topic.

I am preparing another article about my MCE experiences here at WE-DIG in my crusade to bring the MCE components to XPE.

Summary

All in all it was a great summit and the most important aspect of the summit as the networking between the different web-masters. I am hoping that Microsoft will continue this effort and we can see each other at least once a year in Redmond.

3/2/2005 8:47:04 PM - by Chris Muench

This was good!

Report: Nov-2004 Meeting

WE-DIG/Seattle

Meeting Report

By: Paul Yao

November 4, 2004

At the WE-DIG/Seattle meeting yesterday, the theme was "Windows Mobile". We - the board - picked this theme because it is the third major area that we have chosen to focus on. I enjoyed the meeting, mostly because of the time that the various Microsoft dev-team members took to come and explain where they were taking their technology. But also, the questions that got asked helped to broaden my understanding of lots of the little nooks and cranny details.

==== HELLO PINKIE ====

Without a doubt, the highlight of the meeting was the ".man with the pink hair." Yes, that is right. Microsoft's Program Manager on the Visual Studio 2005 team, Neil Enns, had pink hair. When he walked into the room and I saw him, I thought "oh boy - how to break the news to this guy that they glory days of punk are long, long ago?"

It turns out that Neil had agreed to dye his hair if his team shipped their feature set on time and at an agreed upon level of stability (zero bugs, I believe he said). They beat the goal by two weeks. So Neil was not making a fashion statement, but instead had put his dignity on the line to help motivate his team. I like that. He was willing to put some skin into the game - or should I say "hair into the game"? - for his feature set. Way to go Neil!

Neil's contribution to the meeting went beyond being a poster child for developer motivation, as he gave a demo of the latest build of Visual Studio 2005 (still in beta!). More in a moment.

==== CASE STUDY: XP EMBEDDED KIOSK ====

The theme of yesterday's meeting was Windows Mobile. But first - as a follow-up to the October meeting - we got to take a look at a custom embedded device under development. Chris Muench, a WE-DIG/Seattle board members and Siemens Strategic Relations Manager to Microsoft, is working on a survey kiosk that uses XP Embedded.

Chris brought his machine in, which was no easy thing! He got help from another board member, Mike Salamone and Mike's monster truck (Ford F-250). The kiosk took two people to bring into the building where we were having our meeting.

Chris is going to be working on this system over the next few months, and promised to give us updates. The system is a stand-alone kiosk with a touch-screen. It is powered by XP Embedded, which runs on an older laptop computer that Chris acquired on eBay (purchase price: $50). The kiosk runs surveys, and is intended for meetings (like a WE-DIG meeting!) and conferences as a way to get input from attendees.

The basic survey program was a .NET Windows Forms program, which gets its input from the touch screen. Longer term plans include the ability for the kiosk to automatically configure itself without requiring a software engineer to set it up. Idea is that it would set itself up - either by phone, over WiFi, or via Ethernet - from the Self Surveys web site (http://www.selfsurveys.com).

So thanks, Chris - we look forward to updates as you add new features.

==== THE WORLD OF WINDOWS MOBILE ====

I was up next, to introduce the theme of last night's meeting: Windows Mobile. A quick survey of the audience showed that most had developed for Pocket PC and/or Smartphone. A few had not, but still there was not anything that is so incredibly overwhelming. Rather than dig into stuff that is pretty obvious to most developers, I talked a bit about Windows Mobile.

The first thing to be said is that Windows Mobile is a branding of consumer-level Windows CE devices. As such, its existence has more to do with marketing of Microsoft products and less to do with the technical aspects. Still, some people get confused about the difference between Windows CE and Pocket PC. There is a very detailed white paper on the Microsoft site that describes the differences between these. There is a good summary of the article on the Windows For Devices web site, as well as a link to the article on the Microsoft web site at this URL: http://www.windowsfordevices.com/articles/AT5612706156.html. The summary is useful because the white paper itself has tons of detail - perhaps too many details for some people.

From a software development perspective, the key issue about Windows Mobile is that all the key technologies from desktop Windows development have been leveraged in the software development options that are available. Knowledge of desktop technologies - Win32 API, .NET, Component Object Model (COM), and others - is very helpful in getting started with Windows Mobile programming.

I wrote some white papers on picking a programming interface in Windows CE. The first article is from August 2002, "Application Development Landscape for Windows CE .NET" - really version 4.x of Windows CE. That article is available at this URL: http://msdn.microsoft.com/library/en-us/dncenet/html/apdvlscape.asp. A second article, which I wrote in September 2002, focuses on the choices between managed and native code. That article, "Choosing a Windows Embedded API: Win32 vs. the .NET Compact Framework", covers the tool choices which were available at the time. Those choices are still valid today, although the pending release of Visual Studio 2005 is going to change all that, but more on that later. The URL for the second white paper is: http://msdn.microsoft.com/library/en-us/dncenet/html/choose_api.asp.

So this technology has been out for awhile, so instead of revisiting what is pretty well known to most of those present, I decided to get on my soapbox about a subject that is near and dear to my heart: battery-life. I guess that maybe I had listened to one too many election speeches because I made a promise to the group. I hope that I can fulfill my promise, though, and not have my promise come back to haunt me in four years! But I digress.

I spent a few minutes on my soapbox on the subject of battery-life. Many people put this subject in the category of hardware problems. "If those hardware guys could just get their acts together, then all would be goodness." In truth, there is a lot of work being done on this problem in the hardware arena. For example, ARM has announced what they call an "Intelligent Energy Manager", a joint project with National Semiconductor to improve battery life on mobile devices. (Details at: http://www.arm.com/products/CPUs/cpu-arch-IEM.html.) And Intel has announced some research initiatives (http://developer.intel.com/labs/features/hw03032.htm) around battery life. The Mobile PC Extended Battery Life (EBL) Working Group (http://www.eblwg.org/index.asp) is an industry group created to research day-long battery life for notebook computers. Okay, so the hardware part of the industry has acknowledged the importance of this issue - a good start!

Another refrain that I sometimes hear is that battery life problems are caused by device drivers. This is really just the first categorization in disguise. So yes, some software is involved - that is what a device driver is, after all. But if you think about it, you realize that software is really just the programmable end of a device. So once again, this problem gets sent to the "hardware problem" department, and software types do not need to worry about it.

I think this is really wrong. Okay, yes it is true - hardware uses power. But the usage of that power is to run software. So is there anything that can be done in software to improve battery life? Put another way, is there anything that software developers can do to minimize the system's power requirements? I think there is. I wrote a white paper on the architecture of Windows CE power management, but I wrote that article before I got on my soap box. The article provides descriptive information about the role of the application and device drivers in power management, but it does not include any recommendations for how to do it right. (Okay, so I can be my own worst critic!). Here is the link to the article: http://msdn.microsoft.com/library/en-us/dncenet/html/power_management_features.asp.

What I am very interested in doing - and what I promised to do - is to dig into the software side of getting better battery life. Stay tuned, details to follow at future WE-DIG meetings.

==== UPCOMING TECHNOLOGIES: SQL MOBILE ====

Kevin Collins, Microsoft's man on the ground for SQL Server CE, paid us a visit. He talked about the next version of SQL Server, also known as SQL Mobile. One of the very cool aspects of this next version is that it is going to be made available on the Tablet PC. The team is doing this because there are customers who want to deploy software solutions that run on a wide range of mobile devices, including Tablet PC, Pocket PC, and Smartphone. Custom Windows CE embedded devices are also supported.

The focus of this new version of SQL Server reflects device usage, and not the device OS. Unlike the other devices, the Tablet PC does not run Windows CE. It runs Windows XP Tablet PC Edition. This has been a source of confusion for a lot of people, and it does not help that the Tablet PC is part of a group at Microsoft that focuses on mobility. It is easy to clear up this confusion, though, and then developers can start to see how Tablet PC provides a great step forward for mobile devices. I wrote an article for the December 2004 MSDN Magazine on the Tablet PC, available at this link: http://msdn.microsoft.com/msdnmag/issues/04/12/TabletPC/default.aspx.

As of this writing, Tablet PC is the only non-Windows CE device that will support SQL Mobile. All other systems - including Windows XP Embedded-based systems - are going to need another version of SQL Server. These include SQL Express and the Microsoft Database Engine (MSDE). During the meeting, some questions were raised about whether support for SQL Mobile should also be provided for Windows XP Embedded, which is used by some as the basis for mobile devices. That remains to be seen.

The importance of this SQL database engine on Pocket PC and Smartphone developers is going to be huge. Today, you can install SQL Server CE onto these Windows Mobile devices. In the future, the core storage engine for SQL Mobile - with its 300K footprint - is going to be present on all Pocket PCs and Smartphones. At that time, the Pocket Outlook applications will be updated to use this new storage engine. (Today, these applications use CEDB; tomorrow, they are going to use the new EDB storage engine.) For developers who use the Pocket Outlook Object Model (POOM), this change should be transparent. For developers who make direct calls to the CEDB functions, you are going to need to update your code to use the EDB functions.

Developers building custom Windows CE devices for Windows CE 5.0 and later can include SQL Mobile in their platforms. This is done through this SYSGEN variable: SQLCE_MODULES_EDB.

A big thank you to Kevin for taking the time to talk to us and to answer our questions.

==== UPCOMING APIS: TOMORROW'S POCKET PCs ====

Robert Levy spoke next. He is with Microsoft's Mobile and Embedded (MED) division, and is a Program Manager responsible for the APIs that are unique to Windows Mobile. He had quite a few things to tell us about, including new managed code support that is being introduced for existing APIs, and completely new APIs that are being added in the next version of the Windows Mobile platforms.

In the next version, expect to see managed code support for the following programming interfaces: Pocket Outlook Object Model (POOM), Mail API (MAPI), and the Telephony API (TAPI). [For developers new to device development, managed code support in this context means the creation of extensions to the .NET Compact Framework. The next version of the .NET Compact Framework, version 2.0, is going to ship with Visual Studio 2005.

And then there are going to be some new APIs added to the next version of the Windows Mobile platforms. All of these new APIs are going to be available as both native (C++/Win32) as well as managed code (C#/VB.NET + .NETCF) libraries.

A new control, the Contact Picker Control, is going to be available for applications that use the Pocket Outlook Object Model (POOM). Previously, applications had to reinvent the wheel when it came to providing a user-interface for the Contact List. This new control is going to eliminate that, making life easier for application developers. Device end-users are going to benefit by the added consistency that will be available between different applications. The Contact Picker control allows a common set of operations on the contact list: add, remove, search, connect (make a phone call / send an email message / initiate an instant message), and view notes.

Support for cameras is getting added to the next generation of Windows Mobile devices. More and more PDAs and mobile phones have cameras; soon, we are going to have a standard set of programming interfaces to access those cameras. Among the features that Robert mentioned was a Picture Picker Control, to display a set of thumbnails when a user is looking for a picture.

Robert also talked about a new universal notification API. (That is not their name for it; that name just popped into my head during Robert's talk.) In the past, Windows CE has had specialized notifications for network and device connections, power on and power off, and time zone change. The new notification API provides a wide range of new types of system notifications - Robert gave the example that a program will be able to set up a notification for when the battery power drops to 10%.

The new notification API is built around changes to values in the registry. In the next version, a bunch of new system state is going to be put into the registry and have notifications assigned to them. In addition - and this is where things get very interesting - anyone can use the registry to define custom types of notifications. For example, a device driver could set a registry value for the percentage of an input buffer that is full. A program could register to get notified when the value reaches 50%, and then it could call the driver to receive the input data. As the program is performance tuned and load balancing is done on a system, the program can change the trigger point for optimal results. For example, if the buffer was not getting emptied fast enough, the program might modify the trigger value to 35%.

I have not spent time experimenting with it, but I suspect that this mechanism is going to provide several types of benefits. For one thing, a polling loop can be replaced with a notification to save processor time. This should help make the system more responsive. It should also help save battery life, since a CPU can run in a lower power state.

Like the other new APIs, the notification API is going to be supported for both native and managed code development. When an event occurs, there are several ways that a notification can be delivered. Like the current notification support, the new API allows a program to get launched. This is a handy feature, except when a program is already running. To support that situation, an event notification will be able to be created that sends a message to a window when an event occurs. In managed code, event notifications can also be defined as managed code events.

There are some great new API's in store - thank you Robert for stopping by and filling us in on these.

==== SNEAK PEAK: VISUAL STUDIO 2005 ====

The final talk of the night was from Neil Enns (a.k.a. "Pinkie"), from the Visual Studio team. He talked about both native code and managed code improvements in the next version. We also got a sneak peak at Visual Studio 2005, using a build that was only a few hours old (and still hot to the touch!).

One big news item - which is already pretty well known - is the native development support. Instead of an upgrade to Embedded Visual C++ 3.0/4.0, the next generation of devices is going to have a single development environment for both native and managed code development. And as has also been announced elsewhere, new versions of both the Microsoft Foundation Class (MFC) library and the ActiveX Template Library (ATL) are going to be included - we are going to see version 8.0 of both of these libraries.

Another important item that is going to impact every developer is the debugger. It has been rewritten and tweaked to make it fast, fast, fast. Previously, when you single-stepped through code, you got to celebrate one - and sometimes two - birthdays before control was returned to you. In this next version, it is much faster. For developers who have been using network connected debuggers, this was not a big issue - the network has a ton of bandwidth. The big win is going to developers who have been using USB-connected devices for debugging, something that was necessary for those situations when a device just did not have a network connection. You know who you are - and I know you are looking forward to taking the new debugger for a spin around the block when it ships.

When developing for smart devices, we have a love-hate relationship with the emulator. We love that it makes it easy to get started, but hate that it does not provide an exact duplication for actual device behavior. One obvious difference is that the past emulators all ran x86 instructions, whereas all Pocket PCs run ARM v4 instructions. In the next version, that changes.

The reason is that the next generation emulator is built to run native ARM instructions. That sounds pretty amazing, and it is. One thing that I worried about was speed - hardware emulation of one CPU by another CPU has come at a performance cost. Amazingly, however, that does not seem to be the case based on watching the emulator in Visual Studio 2005.

I mentioned this to Andrew Sloss, an author of the Arm System Developer's Guide, and his first reaction was that the emulated ARM would probably run faster than an actual ARM. When I asked why, he pointed out that ARM designs its processors to be as low-power, and therefore as simple as possible. By way of comparison, he pointed out that a typical ARM-designed processor might have 40,000-50,000 logic gates. A processor for a desktop system - like an Intel Pentium 4 or an AMD Athlon - has around 40,000,000 logic gates. With 1,000 times the horsepower, a desktop system can emulate an ARM processor very easily, with plenty of CPU cycles to handle all sorts of other chores.

In his demo of Visual Studio 2005, Neil warned the audience that the version he was going to show us was not very stable. It did crash a few times, but we still got to see some pretty cool things. The Forms Designer, for example, supports both landscape and portrait forms layout. It also supports skins, and custom skins are easy to create - just a PNG file and an XML file to provide the look and feel of a specific device. Design-time tools have been added for SQL Mobile, which makes it very straightforward to connect to a SQL Server, query the layout of a database, and use that for the definition of a new database in a smart device project. Once designed, a database can be added to a Visual Studio project so that the database can be deployed along with the other parts of a solution just by hitting the F5 key.

Thank you Neil - your talk and demo were very valuable and I am glad you were able to come by.

All in all, it was a great evening with many good tips provided, and lots of questions from the audience. Best of all, we had some really good pizza during the break!