TwitterFacebookGoogle

Successfully Building OpenCV with OpenGL support in Windows

I ran across an issue today while building OpenCV (the computer vision library) with support for OpenGL (the computer graphics library) in Visual Studio 2010, and thought I’d pass along the good word on how to fix it.

So here’s the situation. You download CMake and OpenCV, and start CMake. Then, you configure CMake to create Visual Studio 2010 projects and among your configuration settings, check the checkbox “WITH_OPENGL.” You’re at the pinnacle of excitement; from the thrill of working with new software, or from the novelty-sized cup of coffee you just consumed. No software project has ever been this easy. At this point, you find the Visual Studio solution file OpenCV.sln and start building. The building fails. What follows is likely anger and profanity. However, if you go back to CMake, uncheck “WITH_OPENGL,” re-Configure, re-Generate, and then rebuild in Visual Studio, it all works.

Here’s what happened. If you look through the output in Visual Studio, you’ll see something like the following scattered about:

LINK : fatal error LNK1104: cannot open file '..\..\lib\Debug\opencv_core243d.lib'

Okay, so opencv_core243d.lib isn’t being built.

Now, scroll up to the opencv_core project, right-click and build just that project:

Visual Studio opencv_core project

Here we get…

2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\GL/gl.h(1172): fatal error C1003: error count exceeds 100; stopping compilation
========== Build: 1 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

…more errors than our compiler cares to tell us about. So let’s start from the top.

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
2>------ Build started: Project: opencv_core, Configuration: Debug Win32 ------
2> opengl_interop.cpp
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\GL/gl.h(1152): error C2144: syntax error : 'void' should be preceded by ';'

This error’s a little cryptic, but if you’ve done any programming with OpenGL in Windows, you might recognize it.

Essentially what’s happening is that Microsoft requires a specific calling convention for system DLLs, so the OpenGL calls in gl.h have macros that carry a nonstandard C syntax. With that said, you need to include the  Windows header file prior to including gl.h (You can read more about this in OpenGL’s FAQ section).

So how do we fix this? Well, take a look at the file that loaded prior to gl.h. In this case, opengl_interop.cpp. If you’re like me and won’t be building OpenCV on anything but a Windows machine, include the Windows header as the first line of code:

#include <Windows.h>

Now save opengl_interop.cpp and build opencv_core  or the solution again.

2> opencv_core.vcxproj -> C:\lib\opencv\vs2010\bin\Debug\opencv_core243d.dll
========== Build: 2 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Boom!

Preventing Access to Bubble Breaker or Solitaire

So you’re managing a few billion Windows Mobile and Embedded Handheld devices, and you find out that one of your users has been popping bubbles all day on Bubble Breaker instead of working. How do you prevent it?

Unfortunately, you can’t – that is, unless you manage to score a custom OS from the OEM without Bubble Breaker or Solitaire included. Chances of that happening just for you are typically slim, so carpe bubbles.

However, you’re not completely helpless. Applications like Bubble Breaker are stored in ROM, and shadowed in RAM.  By overwriting the file in shadow RAM, you can prevent the novice user from running bubble breaker. Simple right? Actually yes, it’s very simple – you overwrite the application file in the file system.

Let’s say we’re going to prevent the user from launching Solitaire. We first do a look-see in the \Windows folder to find the program we want to block: “solitare.exe.” (Tangent – programmers can’t spell.) Now that we know what file to overwrite, we need a file named “solitare.exe.” Once we have that, we’ll use ActiveSync on Windows XP to navigate to the \Windows folder, drop the new file, and accept to overwrite the existing file.

Now there are a couple gotchas involved. First, this process is completely different using a PC with Windows Vista or Windows 7 and running Windows Mobile Device Center. It is much more involved, and I will step through the new process at a later time. Secondly, the file overwrite is only temporary until either the file in shadow ram is deleted, or the OS is “clean booted” – clearing all memory and persistent storage.

If you’re fine with the gotchas, I typically take one of three approaches.

1. Create an empty file, and name it “solitare.exe.” When you run solitaire, you should see the following message:

Zero Byte Solitaire

Running a zero-byte Solitaire

2. Confuse the user with an empty app. Create an application that loads and unloads, and does nothing in the middle. Each time solitare.exe runs, you’ll bypass the error message in #1 but still prevent the user from doing anything. You might even implement a counter to see how persistent the user was at accomplishing nothing.

3. And my favorite, yet never recommended (per se): have fun with the user. Pop up a ridiculous error message, sound an excruciatingly painful alarm, or flicker the screen on and off – this is your chance to get creative.

Having fun with Solitaire

Having fun with Solitaire

Two trick methods of recovering a lost Windows machine without a DVD drive

Recently, a friend of mine brought over a DVD drive-less netbook with a virus laden Windows 7 copy, and corrupt Windows recovery and Acer Recovery partitions. I used a second computer to remove the viruses, but it became clear that the virus had already replaced major system files, like explorer.exe. So we could start up a virus-free OS, but we still couldn’t get our desktop to show. What do we do from here if we don’t have an external DVD drive to reload Windows and don’t want to go through the hassle of setting up a network boot?

Well there are two tricks that work great for me. The first trick is a more recent development in the past couple years, which is to install Windows from a USB drive. To do so, you’ll need an ISO image of the OS. You should be able to get this from the Microsoft Store if you don’t already have one. In addition, you’ll need a relatively large USB flash drive (about 4 GB +), and the Windows 7 USB/DVD download tool from the Microsoft Store. Once you have all three, installing and running the Windows 7 USB/DVD download tool should be a piece of cake – the application walks you through the process. Before you know it, you’ll have a bootable USB flash drive, and be able to install or repair that failing Windows 7 copy. Remember that to actually boot from the drive, you may need to either alter the boot order in the BIOS, or jump to a boot menu on a computer start up that lets you select which medium to boot from.

Windows 7 USB/DVD download tool

Windows 7 USB/DVD download tool

The second trick is to take the bad hard drive and put it into another machine with a DVD drive. From there, you can install Windows from a disc as you would on any other machine. When the OS is completely running, you need to do a few things to make sure the drive is kosher to transfer to the “bad” PC. To prevent piracy, Microsoft has software in place that will render your current copy of Windows useless if it detects too many hardware changes at once. To bypass this software, open up Device Manager (you probably shouldn’t be doing this if you don’t know how to get to Device Manager), and uninstall all the controller drivers in the “IDE ATA/ATAPI controllers” section, making sure that you don’t reboot the computer between uninstalls. When you finish uninstalling all of the controller drivers, shut the computer down. Now, transfer the hard drive to the “bad” PC, and boot it up. At this point, it should load just fine, install drivers for new controllers, and force you to re-activate with Microsoft. If for some reason you get the Blue Screen of Death, you can still boot into Safe Mode to make changes to the controller drivers.

Device Manager

Device Manager showing active IDE ATA/ATAPI controllers

Good luck!

The OEM Windows Mobile/Embedded Handheld Software Version

While working at Intermec, we get this question quite a bit: I have a competitor’s device with the same Windows Mobile OS on it. Why does it work on one and not the other? The reason, clearly, is because (besides potential major hardware and platform architecture differences) the same OS version is not on both devices.

There are generally two different OS versions to consider when you look at a Windows Mobile or Windows Embedded Handheld computer. The first is what’s called the Microsoft Adaptation Kit Upgrade (AKU) version.  This is the version you see when in the About applet, and it represents the version of all the Microsoft compiled software on the OS. In the image below, the version you’re looking for is Build 23152.5.3.12, which actually translates to Microsoft Windows Embedded Handheld 6, AKU 5.3.12, Build 23152.

Windows Embedded Handheld 6.5 About Applet

Windows Embedded Handheld 6.5 About applet, showing the Microsoft AKU OS version.

The second OS version is the OEM software version. When companies like Intermec, Motorola/Symbol, Honeywell, etc., create computers, they need to write all the software that connects the hardware to the OS. So this version typically consists of a boot loader, device drivers, and the OAL (OEM Adaptation Layer). In addition, other pieces of software are often included as a part of the OEM OS version specific to both the device and OS release, such as an application to allow the user to set barcode scanner settings or enable remote management or allow you to more easily connect a mobile Bluetooth printer.

Unfortunately, there really isn’t a standard way of finding this OEM software version, and it also tends to vary by device at each OEM. To find the OEM version of your computer, check with product support personnel, the computer’s manual, web forums, or the good old fashioned Google search. On an Intermec CN50, for example, this OEM software version is hidden on the Packages tab in the About applet, listed under the package “Platform Software” (1.70.21.0038). This is the very version that you’ll find when grabbing a new OS build from Intermec’s website (CN50 Software Downloads).

Intermec CN50 OS Version

Intermec CN50 OS Version on the Packages tab of the About applet.

So the next time you’re comparing two devices that you think are similar, consider that you really need to first ensure that they have the same hardware and system architecture, then determine if their Microsoft AKU versions are the same, and finally, compare the OEM software versions to see if the rest of the software matches up.

Windows Embedded Mobile CE Handheld Madness

The relationships between Android operating system versions are easy to understand, and they all have delicious codenames – you have Cupcake (v1.5), Donut (v1.6), Eclair, Froyo, and Ice Cream Sandwich to name a few, with “Obesity” and “Type II Diabetes” expected to debut somewhere between 2030 and 2035. Although phone and computer manufacturers may take that OS and change it drastically from device to device, you essentially know that your computer is running Android, and for the most part, an app made for Cupcake works on every OS release following it. Yummy.

The same is only sort of true with the Microsoft Windows Embedded OSes, which tends to really confuse application developers planning to develop or port their application across embedded OS versions. Adding to that, there isn’t really one guide that explains all the OS lineage or name changes. So with this article I’m going to attempt to to touch on the versions of embedded Windows products, and provide a conceptual overview of how they’re connected. For sake of brevity, I will be leaving out many many details and adding overly simplistic introductions. If you find you need more meat, please consult the Links and Other References section near the end of this post.

Here we go.

In the beginning, there was a big bang in Redmond, Washington, and amongst the cloud of blood, sweat and tears, Windows CE was born. Windows CE was designed from the ground up as a tiny, modular (after CE 1.0) operating system that supported a subset of the Win32 API. Modularity meant that the embedded computer manufacturer could pick and choose what pieces of the OS it wanted to include for its specific hardware, while trimming the unnecessary fat. For example, if you make a computer with a Bluetooth chip in it, you include the Bluetooth OS package. You certainly don’t need all the WiFi software in your tiny operating system if you don’t have a WiFi radio, so you leave it out. The name of the game in embedded devices is obviously small, fast and efficient. In addition to the benefits of modularity, Windows CE supported a subset of the Win32 API, ensuring that all those Windows 95 software programmers didn’t have to learn a new way of life to jump on the CE programming bandwagon. In many ways, Windows CE seemed ahead of its time.

And so Windows CE (also known as “Windows Embedded CE”) grew all the way from version 1 to version 7. However, that did not happen without a few confusing name changes. In version 4, Microsoft decided to add a “.Net” to the end of the “Windows CE” name, which actually has nothing to do with the .Net Framework. Thankfully, it was reverted back to the original name for versions 5 and 6. Now going back to confusing people for fun, Microsoft more recently decided to have another change and renamed the product line at version 7 to “Windows Embedded Compact.” So the Windows CE is essentially just like the lineage of the Android OS. Let’s draw it out as a crudely drawn horizontal text tree, for all those visual learners. Happy now, visual learners?

WinCE 1 (1996) –> WinCE 2 –> WinCE 3 –> WinCE.Net 4 –> WinCE 5 –> WinCE 6 –> Windows Embedded Compact 7

Now, let’s go back to the beginning of Windows CE again, and branch out that horizontal text tree. When Microsoft was coding away at Windows CE, they immediately envisioned three types of hardware platforms running Windows CE: set-top television boxes, automobile computers, and handheld PCs. First, Microsoft created a set of hardware and software requirements to certify what they deemed a Handheld PC (H/PC), such as  (*1):

  • Run Microsoft’s Windows CE
  • Have a pocket form factor
  • Weigh less than 1 pound
  • Contain a QWERTY keyboard with Ctrl, Alt and Shift
  • Have a grayscale LCD touch screen display with a resolution of 480×240 pixels
  • Stylus to use like a mouse on the touch screen
  • Run on the SH3, MIPS 3000 or MIPS 4000 processor architecture
HP 300LX

HP 300LX Handheld PC based on Windows CE 1.0 (*2)

Eventually the hardware requirements changed — grayscale LCDs are cool (if you’re a hipster), but not as cool as, say, actually being able to play solitaire without memorizing the color of each suit of cards. The Handheld PC based on Windows CE 2.11 then became known as Handheld PC Professional. After one more release, the Handheld PC family died with a name of “Handheld PC 2000,” which was built on Windows CE 3. (Nerdy side note here – there was actually a version of Linux developed for some of these handhelds. Check out JLime Linux if interested: http://jlime.com)

HP Jornada 720

HP Jornada 720 Handheld PC 2000

At the same time as the Handheld PC, Microsoft developed a product line for automobile computers. It started off as “AutoPC,” but has since been renamed with each new version – to “Windows CE for Automotive,” then “Windows Mobile for Automotive,” then “Microsoft Auto,” and finally “Windows Embedded Automotive.” Not confusing at all. To make it even easier to understand the product line, Microsoft even changed the base OS from Windows CE to Windows 7 somewhere in there.

Rewinding again on the Windows CE trunk, version 2.01 introduced support for the new Palm PC – a keyboardless computer that fits in the palm of your hand. After legal battles with 3Com over the “Palm” name (referred to just as Palm Pilots for almost everyone), Microsoft had the product line renamed to “Palm-Size PC.” Somehow, that was legally acceptable, but akin to creating a tablet PC called the iPad-ish Tablet (henceforth, iPad-ish Tablet™). The Palm-Size PC OS was either built on the Windows CE 2.01 or 2.11 cores, and eventually phased out in 2000.

HP Jornada 420

HP Jornada 420 Palm-Size PC

 

In 2000, Microsoft needed a new device that could directly compete with the stylings of 3Com’s Palm computers. Everyone knew what a Palm Pilot was, but not a Microsoft Palm-Size PC. To achieve this, the Palm-Size PC user interface was redesigned and coupled with a Windows CE 3.0 core OS. With the addition of some new hardware requirements and software packages, this OS became the Pocket PC 2000.

And the Pocket PC line was so successful that it continued for many years with different version names and core Windows CE versions. Although it was mostly targeted at enterprise devices, the product line made it’s way onto consumer PDAs and phones as well. Additionally, in the later years, the terms “Professional” and “Standard” appeared in OS names. This essentially meant “touchscreen” and “non-touchscreen,” respectively. In order of OS appearance:

  1. Pocket PC 2000, with a Windows CE 3.0 core OS.
  2. Pocket PC 2002, with a Windows CE 3.0 core OS. There were also “Phone Editions” which contained a WWAN (cell) radio.

    Intermec Model 70

    Intermec Model 70 running Pocket PC 2002 (*3)

  3. Windows Mobile 2003, with a Windows CE.Net 4.2 core OS.

    Intermec 700 Series Computer

    Intermec 700 Series Computer running Windows Mobile 2003

  4. Windows Mobile 2003 Second Edition – basically the same as #3 with some bug fixes and small changes.

    Windows Mobile 2003 SE

    Windows Mobile 2003 SE

  5. Windows Mobile 5, with a Windows CE 5.0 core OS.

    Windows Mobile 5

    Windows Mobile 5

  6. Windows Mobile 6, with a Windows CE 5.0 core OS.

    Windows Mobile 6

    Windows Mobile 6

  7. Windows Mobile 6.1, with a Windows CE 5.0 core OS.
  8. Windows Mobile 6.5, with a Windows CE 5.0 core OS.
  9. Windows Embedded Handheld 6.5, with a Windows CE 5.0 core OS. This is essentially the same as Windows Mobile 6.5, with a shiny new name for the enterprise/vertical (think business computer) market OS line.
  10. Windows Phone 7, with a Windows CE 7 core OS. Note that this OS is for the consumer market, and broke compatibility with previous product line OS releases.

 

And unless I forgot something (which I most likely did), that pretty much covers where we stand today! If you need more information, the following articles and books are fantastic references – I’ll add more as I remember them.

 

Links and Other References

  • “The History of Windows CE” http://www.hpcfactor.com/support/windowsce/
  • Murray, John. Inside Microsoft Windows CE: [in-depth Details of the History, Architecture, and Ever-expanding Potential of This Remarkable Operating System]. Redmond, WA: Microsoft, 1998. Print.
  • Boling, Douglas. Programming Windows Embedded CE 6.0 Developer Reference. Redmond, WA: Microsoft, 2008. Print.

 

 

 

 

Article References

*1: Tilley, Chris. “The History of Windows CE: Windows CE 1″. HPC:Factor, 18 Feb. 2001. Web. 20 Mar. 2012.

*2: Kajac123. “File:300lx.jpg.” Wikipedia. Wikipedia, 17 Apr. 2011. Web. 20 Mar. 2012.

*3: “Intermec_70.jpg.” PenComputing.com. Web. 20 Mar. 2012.