Introduction Windows CE is a scaled down version of Microsoft Windows intended for use in embedded systems. It features a small footprint, good real time capability and the availability of powerful development tools. The fact that it can be burned into ROM greatly speeds startup of the system and also greatly reduces the need for the end user to setup and configure the system. Vendors incorporating CE into their hardware can optimize functionality and size by choosing which system components to include in the baseline sysgen and can also choose from several families of processors including x86, MIPS and SH3 based on cost, performance and their own preference and experience. CE also features off the shelf support for reliable, low cost hardware and software options including keyboards, displays, Comm ports and network adaptors. As anyone who has developed or used Ethernet for a PLC is aware, the availability of an off the shelf PCMCIA ethernet card and TCP/IP protocol stack can greatly reduce the cost and time required to add this capability to a PLC. The result is a reduction in time to market, development cost and manufacturing costs for new products. This translates into lower end user purchase and maintenance costs and frequently into a reduction in ongoing maintenance costs for the vendor as well. OPC, which stands for OLE for Process Control and Factory Automation, is bringing the same ability to leverage standard off the shelf components to the Process Control and Factory Automation Software industry and it's users. Specifically, it defines software interfaces that allow easy transfer of data between programs that provide automation data (Servers) and programs that use automation data (Clients). OPC has demonstrated success and interoperability on Windows NT, Windows 95 and 98 and even on NT running on the DEC Alpha Platform. With the growing popularity and cost effectiveness of Windows CE, there is obviously a lot of interest in leveraging OPC technology on the CE platform. This paper briefly describes the technical challenges in porting OPC Code to CE. The Challenge So, does OPC work on CE? The answer is a qualified yes. The main issue is that at this time, CE supports only an in-process server (DLL). This is one of the three models (in-process, local and remote) that are supported by COM and by OPC. As we will see below, there are a number of other minor issues with CE but none of them are critical. The remainder of this paper will discuss the missing features, their impact (if any) on interoperability and workarounds for each issue. This information should serve as a guide to anyone porting OPC Code to windows CE. In general Windows CE is a 'windows like' operating system. The Win32 API supported by CE is similar to the one on NT, but some things are missing, some new things are added and a few things behave differently. More important to most programmers (although less so to OPC programmers) is the User Interface which, from the programmer's point of view, is very different from NT. All of this is not surprising under the circumstances (completely new hardware platform and CPU set) however it is not terribly good news for programmers trying to port code. What this means is that existing code can be ported to CE more easily than it could be ported to say OS/2 or UNIX but, depending on the nature of the code, it could be a lot of work. A discussion of specific issues that affect OPC follows. No DCOM: There is no DCOM support built into CE at this time. This means that only in-process servers will work on standard Windows CE. This does not really create any interoperability issues. In any case, in-process servers are the most efficient and on CE with its somewhat limited CPU capability this can only help. In the mid to long term, there are already third party solutions which provide capabilities similar to DCOM on CE and Microsoft has announced tentative plans to support DCOM in the n