Windows Embedded Compact 7 CTP Installation Problems RRS feed

  • Question

  • I downloaded the Windows Embedded Compact 7 CTP Evaluation version.   The installation instructions in html format that come with it tell you to extract the zip format files.   I'm on a Windows 7 machine and the unzip just doesn't work.   For some reason the system thinks that the files already exist and gives errors that state "the volume cannot be used as both the source and destination".   I got around this by manually copying each and every file from the source to the destination.   It makes you wonder why that happened?   Anyway, the instructions say to run WindowsEmbeddedCompact7.exe.   It ran fine.   The default destination directory it specifies is C:\WINCE700   Ok fine.   So it creates a bunch of files in that directory.   Then what?    The installer says it is finished.   What is WINCE700?   I was assuming that I was going to install the Windows Embedded Compact on the computer.  Instead I created this directory with a bunch of contents which I don't know what to do with. 
    Thursday, February 17, 2011 1:52 AM

All replies

  • When you install Windows Embedded Compact 7 (specifically the Public CTP in your case) what you actually are installing is a tool called Platform Builder.  Platform Builder is an addon for Visual Studio (specifically VS2008 in the case of WEC7) that allows you to create and configure a project to build a customized version of the Windows Embedded Compact operating system for specific target device.  The directory WINCE700 is called the OS folder (by the installer) or the _WINCEROOT folder (by CE developers because that's the name of the environment variable that points to this directory) and it holds all the libraries, DLLs, EXEs, source code, command-line build tools, batch files, makefiles, build configuration files, etc., that go into building a custom Windows Embedded Compact 7 operating system image.  In addition, the installer also should have created a folder called C:\Program Files\Microsoft Platform Builder\7.00 (or C:\Program Files (x86)\....) that contains the components that provide the visual interface that Platform Builder adds to Visual Studio.

    It sounds like you're pretty new to CE, and if that's the case, I wouldn't recommend learning about it from the documentation that's included with a pre-release version (which the CTP is).  Instead, use the online documentation of the latest released version (CE 6.0 R3) at and consider picking up a book or two about Windows CE platform and/or application development.  Don't let that stop you from exploring the contents of the WINCE700 directory and all the source code that's in there as, ultimately, that's where the greatest wealth of knowledge about Windows Embedded Compact can be found.

    Tom Gensel PTG Systems, LLC
    Thursday, February 17, 2011 3:23 AM
  • Wow!   All of that work just to be able to set the priority of a thread/process higher than 97 with the help of CeSetThreadPriority. 
    Thursday, February 17, 2011 6:03 PM
  • Whoa - I think you're crossing threads here with this dicussion.  Please see my other reply in your "Newbie question about CeSetThreadPriority" thread.
    Tom Gensel PTG Systems, LLC
    • Edited by T. Gensel Thursday, February 17, 2011 7:27 PM
    Thursday, February 17, 2011 6:10 PM
  • Not really.  Installing Windows CE is a prerequisite to setting priority high.   Anyway, I'll take a look at the documentation you recommended.   You response is much appreciated.
    Thursday, February 17, 2011 6:29 PM
  • Well, no actually it isn't.  If you are just developing an application that is intended to run on a Windows CE device and you need to set a thread priority using the CeSetThreadPriority API, you don't need Platform Builder installed at all. You just need VS2005 or VS2008 and a suitable SDK for the CE device your application is to be built for. 

    Installing Windows CE Platform Builder would only be a prerequisite for creating a Windows CE operating system image for a specific hardware platform and/or creating an SDK for use in developing applications for that platform.

    Tom Gensel PTG Systems, LLC
    Thursday, February 17, 2011 7:34 PM
  • According to the doc Windows CE 3.0 or later is a requirement for CeSetThreadPriority:

    OK, then how do I get a Windows CE operating system for a generic off-the-shelf standard PC?   The title of the download said "Windows Embedded Compact 7 CTP" and I assumed it's an operating system.   It turns out it's not an operating system but a Visual Studio tool which will let me create custom operating systems for all kinds of devices.  All I need is Windows CE to be running on a PC.   Asus motherboard, Intel I7 CPU, 12GB RAM, 120GB SSD disk for OS.    Windows 7 installs and runs just fine on this machine.    How do I go about getting Windows CE to run on this machine?   Do I still need to do this through Platform Builder or is there a pre-packaged version of Windows CE for a generic PC?

    Thursday, February 17, 2011 9:42 PM
  • Msdnacct,

    There is no such thing as a “pre-packaged version of Windows CE” for a generic PC or any other device.  A customized image of the CE operating system specific to the target device must always be built for a board.  The creation of this customized image usually starts with the development or acquisition of a board support package (BSP) for the PC board that is the target of the OS.  Many board manufactures provide a BSP for their boards that includes drivers for some or all of the hardware devices on their boards.

    Microsoft happens to provide a board support package for x86-based PCs.  This BSP is called CEPC, and it is included with the Windows CE Platform Builder.  This would be the starting point for creating a CE OS image for you PC, but because of the many variations in PC hardware, the base CEPC BSP may need to be modified in order to work properly on a given board.  In addition, devices on your board not supported by the drivers included in CEPC would need to have new drivers written for them.

    Tom Gensel PTG Systems, LLC
    Sunday, February 20, 2011 6:49 AM
  • Don,

    Would you please move your question to a new thread so we don't get confused by discussing multiple, unrelated questions in one thread?  Just click the "Ask a question" link at the top of the page and I or one of the experts here will be glad to help you out.


    Tom Gensel PTG Systems, LLC
    Sunday, February 20, 2011 7:08 AM
  • Brilliant Question by msdnacct and although a little crudely put was the exact silly question I wanted to ask someone. Myself not knowing a thing regarding Windows Embeded other than it's used on EPOS systems and the such was hoping to replace a pc I have running windows 2000 pro embeded with Windows Embeded 7. So basically the answer to my question is that if I want to upgrade my pc to a better O/S I'd better go on amazon and purchase Windows 7 Ultimate instead. Thank you T.Gensel you have saved me a whole heap of time wondering why my Embeded 7 download from technet wont boot up.
    Monday, February 21, 2011 1:15 AM
  • Why do you say it's a "better" OS?  Remember that Windows 7 and Windows Embedded Compact 7 are NOT THE SAME OR EVEN STRONGLY RELATED.  Windows Compact 7 is designed for devices that have processors like your phone and which have very limited resources.  While Compact 7 has additional capabilities compared to earlier versions of Windows CE/Windows Mobile, it doesn't come close to the feature set of Windows 2000.  If your PC can run Windows 7, use that, unless you have a good reason to want an embedded OS.

    What's the actual problem?  We can probably give you a more-helpful direction if we know what your goal is.

    BTW, can't you download Windows 7 Ultimate from Technet?

    Paul T.


    Monday, February 21, 2011 4:47 PM
  • The problem is as follows.  We have an off-the-shelf PC on an industrial device.  It is running a data acquisition program that I wrote.  I want to give the program top priority on that PC.   Consider it a real-time time critical program.  The PC has no other purpose but to run this particular program.    The program is written in C# but calls functions in a Win32 library which is provided by a data acquisition device manufacturer and uses InterOp services and unsafe code to access data.

    The original solution attempt was as follows.  I started out with changing the C# Thread.Priority property.   From what I understand it sets priorities in the high range, not low range.   So it proved useless.  I googled around and found this page:   I also found another page which I can't recall right now but it said something to the effect of Thread.Priority only affects priorities between 248-255 and that SetThreadPriority is the command to use to give a thread real time 0-96 priority.   In retrospect finding these pages via google was a blunder because the page I stumbled upon was the WindowsCE version of the SetThreadPriority Class.  The CE version of SetThreadPriority depends on the nk.lib found in Windows CE.   There is another version of SetThreadPriority out there that depends on kernel32.dll found in Windows 7.  To add to my confusion over the years I associated the words "embedded" with "real-time" so I assumed Windows Embedded or Windows Embedded Compact had some special real-time powers that Windows 7 didn't have.   So I thought that I needed Windows Embedded Compact to do real time operations like CeSetThreadPriority.   This turns out not to be the case.

    The current solution attempt is to use SetPriorityClass with the normal Windows 7 operating system.   The only problem I am having with this is to access the handle to the thread started in a C# environment, however that is outside of the scope of this topic.


    Wednesday, February 23, 2011 7:24 PM
  • OK, now I'm on the same page.  Windows 7 itself is not a real-time operating system and, because of memory management in C#/managed code, your program will never be a real-time program because the memory management is not bounded.  When a collection is required, the amount of time it takes is unknown and could be greater than any number you care to name.  Windows 7 itself *always* avoids starving threads so, even if you are set to the highest priority imaginable, the lowest-priority threads will always get some time.

    For this sort of thing, Windows CE *can* be a better choice because its scheduler *is* real-time.  If you have a thread at real-time priority, until it blocks, it will get all of the processor time.  Further, if there is a high priority thread ready-to-run, it will *always* get the CPU away from a lower priority thread.  This is important because you never actually want to set your main application thread priority to real-time for any significant period of time (interrupts have to happen and get processed for any application beyond the most simple-minded to do their work; any disk I/O requires the ability to yield, any communication with your external device likely requires yielding, etc.)

    So, yes, Windows CE is a possible choice for your sort of application.  However, since it requires porting to every new device, I'd be reluctant to do it in your case because you're running one application on one device.  The porting time you spend never pays you back.  In your case, I would look at some of the real-time kernel add-ons for desktop Windows. They allow you to create threads that really are real-time threads and they schedule them much more like Windows CE does than normal Windows does.  I'm not sure if this will do anything for C# (and suspect it won't), but you may have to give that up to get a true real-time application.  I don't have any experience actually using them, but here are a few:

    Paul T.


    Wednesday, February 23, 2011 9:24 PM
  • Thanx, I'll look into these products.    I am curious however which leads me to two follow up questions.  1. Why do you think that SetProcessPriority and SetThreadPriority (kernel32.dll version) would not work in this case?   What deficiencies does it have?   Am I wasting my time to even follow this path?   Why do these commands even exist if they don't work?  2. Do these companies have some sort of agreement with Microsoft to get access to the source code of some operating system libraries that they tweek?  

    By the way, forget for a moment that C# is used.  Let's just say the application was written as a Win32 project using C.    We used C# because it's a fantastic development environment and the system used unlicensed wireless communications which are not very real time anyway.    The system works.  Now we're going back to see what we can do more efficiently and faster.


    Monday, February 28, 2011 11:31 PM
  • They "work" fine.  However, your assumption that having a thread of priority 5, say, will *always* get all processor time when there is a lower-priority thread ready to run in desktop Windows is *incorrect*.  To avoid starving the low-priority thread and to maintain the highest possible user responsiveness, rather than assuring real-time responsiveness, Windows does *not* schedule threads based solely on the priority.  I can't tell you whether you're wasting your time or not, without knowing the real-time requirements of your system.  In most industrial control applications, you need to have a bounded potential delay before processing every external event (interrupt, etc.). That is, if the guy running the metal stamping press hits the STOP button, the press damn well better stop within the time specified.  A one or two second delay while a memory collection operation occurs in C# is NOT OK.

    My understanding is that the real-time extensions for Windows do not run under the Windows scheduler.  That is, they treat Windows itself as one task and your tasks as others.  Since they are in control of the scheduling, they decide if you, or Windows, will have the priority and they can make sure that the things that you say are real-time are actually real-time.  I'm uncertain if this requires access to source code for the Windows kernel or not, but that's not all that hard to get, so it wouldn't surprise me if they had it.

    So, it sounds like you now don't really need real-time.  If "fast enough" is fast enough, then you're fine and you can do it in virtually any operating system.  You simply have to understand that your application will not be real-time, in the common definition of that term.  If there's no event which, if handling were delayed beyond some amount of time, would "break", then you definitely don't need real-time and all is well.

    Paul T.

    Tuesday, March 1, 2011 12:36 AM
  • Hey Don, can you please share this information with me. I work on the installer for Compact 7 and would be interested in getting more details on these problems.

    There are a couple of things you can do. The first is checking the logs which the installer places in the user's environment variable %temp%. After that, some screenshots of the errors you are seeing.

    Brian Rogers
    Friday, March 4, 2011 5:20 PM