Abstract: Windows CE is an operating system suitable for embedded applications. This paper introduces the system architecture of Windows CE embedded systems, discusses how to build an embedded application platform under Windows CE, and finally presents the development process of network communication protocols under Windows CE. Keywords: Windows CE; Embedded operating system; Network protocol Introduction An embedded system is defined as a dedicated computer system that is application-centric, based on computer technology, with customizable software and hardware, and adaptable to the strict requirements of application systems in terms of functionality, reliability, cost, size, and power consumption. An embedded operating system is the operating system software that supports embedded system applications. It is a crucial component of an embedded system and typically includes hardware-related low-level driver software, system kernel, device driver interfaces, communication protocols, graphical interfaces, and standardized browsers. Compared with general-purpose operating systems, embedded operating systems have significant advantages in real-time efficiency, hardware dependence, software solidification, and application specialization. The emergence of embedded operating systems has greatly improved the efficiency of embedded system development. Developing embedded systems on top of embedded operating systems reduces the workload of system development, enhances the portability of embedded application software, and makes the development methodology of embedded systems more scientific. In recent years, with the continuous progress of electronic technology, embedded system development has become a hot topic. Windows CE is an embedded operating system developed by Microsoft specifically for the field of embedded products. It is a compact, efficient, and scalable 32-bit operating system, mainly for various embedded systems and products. Its multi-threaded, multi-tasking, and fully preemptive features are designed for various hardware systems with very strict resource constraints. Its modular design allows embedded system and application developers to easily customize it to adapt to a series of products, such as consumer electronics, dedicated industrial controllers, and embedded communication devices [1]. The biggest advantage of Windows CE is the universality of the interface, which is easy for users to accept. At the same time, applications under the Windows general operating system can be ported to embedded application systems. There are many research papers on Windows CE, but there is a lack of systematic analysis from platform construction to network applications. This paper starts from network applications and conducts in-depth research on how to implement the TCP/IP protocol under Windows CE, which is very meaningful for embedded network applications. 1 Structure of embedded systems based on Windows CE [2][3] To carry out application development of embedded systems, a development platform must be established first. A Windows CE-based platform consists of the Windows CE operating system kernel, the OEM Adaptation Layer (OAL), device drivers, and the hardware devices that make up the system. Figure 1 shows the hierarchical structure of a Windows CE-based platform. As can be seen from Figure 1, a Windows CE-based embedded system can be divided into four layers, from bottom to top: the hardware layer, the OEM layer, the operating system layer, and the application layer. Figure 1: Windows CE-based target platform and its components. The hardware layer is the system's hardware, including the microprocessor and various peripheral devices. The OEM layer is a hardware abstraction layer that provides the interface between the hardware and the operating system. The operating system can access specific hardware through the APIs provided by the OEM layer without directly interacting with the hardware. The operating system layer contains Windows CE components. Users can customize it according to their system needs, selecting necessary components and removing unnecessary ones, thus reducing memory requirements and optimizing system performance. The application layer consists of applications developed by the user for a specific embedded system. At the operating system layer, the Device Manager provides support for installable devices, allowing the installation of devices such as PC card memory and modems to expand functionality. The kernel provides the most basic operating system functions, such as process scheduling, memory management, and inter-process communication. The graphics and window event handling modules convert user keystrokes, mouse movements, and control selections into messages, which are then sent to applications and the operating system to process user input. Object storage, file systems, databases, and the registry handle user input. Object storage, file systems, databases, and the registry provide the ability to store data. Additional technology modules refer to optional dedicated function modules provided by the CE operating system, such as Java language support modules and handwriting input recognition modules. The user interface module provides the system with a graphical user interface similar to a Windows operating system on a PC. For system designers, the parts that need to be developed are the applications and the parts directly related to the hardware, including the hardware system itself, the OAL (Operating Access Module), and device drivers. The OAL is a layer of code built between the hardware device and the system kernel, whose main task is to support the kernel in managing the clock, interrupts, and implementing power management for specific hardware devices. Device drivers are responsible for supporting the operating system's access to the target hardware. Both OAL and driver programs need to be written for specific hardware devices. Generally, hardware manufacturers will provide driver software support for the devices. If there is a driver program specifically written for the CE system, it can be used simply by adding it to the corresponding module of the operating system. If not, it should be written according to the driver development package provided by the manufacturer. Usually, these development packages already contain standard code to complete various hardware operations. The developer's job is simply to map it to the corresponding CE system API function. In the CE system, all hardware-related operations are completed by calling the corresponding API interface function. The OAL and driver program are to provide support for these API functions and translate them into low-level operations that directly target the hardware. In this way, the CE system isolates the application program from the specific hardware device. The application program only needs to call the API function to access the hardware. In this way, the programmer does not need to write any code directly targeting the hardware when developing the application program. Therefore, the programmer does not need to consider the specific hardware characteristics, and the application program also has independence from the specific hardware device. 2 Network communication protocol in Windows CE Windows CE network communication is based on a layered network stack [1], as shown in Figure 2. The network stack is actually a component of Windows CE. It's responsible for processing data transmission over the network, breaking down data from applications into smaller segments, adding relevant addresses and segmentation information to each segment, and forming packets that can be stored and forwarded. The addresses in the packets ensure the data reaches its final destination. There are three ways to access the network stack: The first is the WinSock port socket method. This is an intermediate-layer transport interface protocol. WinSock handles all header details of the established packets, but doesn't care about the data format. Windows CE network communication uses WinSock directly or indirectly. Using the IrDA protocol to implement client/server network communication based on infrared sockets is a feature of the Windows CE platform. The second is the WinInet API method. The WinInet API is Microsoft's Internet function interface based on the Win32 platform. Windows CE's WinInet API has certain limitations or extensions, providing high-level data protocols such as HTTP and FTP, as well as support for SSL. The API method avoids the operation of directly using WinSock to access the network, simplifying network programming. The third method is the CIFS relocator method. Windows CE allows Windows CE-based devices to establish connections with remote hosts by supporting Remote Access Service (RAS) clients. Figure 2 Network communication components in Windows CE 3 Examples of network communication protocols in Windows CE 3.1 HTTP Windows CE provides a toolset called WinInet for developing Internet client applications. Compared with the method of establishing network connections using Socket, it simplifies the operation details of accessing the Internet. WinInet can be used to connect to remote sites, access HTML pages, upload and download files via FTP, or obtain file directory listings, etc. The Windows CE version of WinInet is similar to WinInet on the desktop platform, but there are two important differences: First, in Windows CE, most callback functions are processed synchronously, and only InternetReadFile and InternetQueryDataAvailable have both synchronous and asynchronous operation modes; second, Windows CE supports Unicode by default, and all WinInet functions require wide character variables [4]. The most common example of network communication via WinInet is accessing HTTP pages on Internet sites using the HTTP protocol. The process is consistent with that on desktop platforms: 1) Call InternetOpen to obtain an Internet handle; 2) Call InternetConnect to establish a session handle for a given site; 3) Call HttpOpenRequest to open an HTTP request handle; 4) Call HttpSendRequest to send a specified request to the HTTP server; 5) Call InternetReadFile to read and download information from the handle opened by HttpOpenRequest; 6) Call InternetCloseHandle to close the Internet handle. 3.2 Remote Access Service (RAS ) RAS is a software-based multiprotocol router for connecting remote devices, also known as a RAS client, or a RAS server for desktop hosts. RAS applications typically run on the device and connect to the server via PPP/SLIP. Windows CE provides support for RAS clients. Although there are many standard Win32 RAS functions, only point-to-point connections are allowed here via serial cable or dial-up modem. In the Windows CE environment, the RAS phonebook entries contain the necessary information for establishing a RAS connection, which Windows CE stores in the registry. The RAS phonebook information includes: the dialed phone number (including country and region codes), the IP address of the current connection, the network protocol, and the device type used to establish the connection. The steps to establish a connection using RAS are as follows [4]: ​​1) Determine the phone number to be called; if the number is not in the phonebook, the RasEnumEntries function needs to be called to find it. 2) RasDial establishes a connection; DWORD RasDial (LPCTSTR lpszPhonebook, // Path and filename pointer to the phonebook file DWORD dwNotifierType, // Handle type of the RasDial event LPVOID lpvNotifier, // Handle to the RasDial event LPRASCONN lphRasConn // Pointer to connection handle type variable); The parameter settings for this function differ from those on desktop platforms, requiring lpszPhonebook to be set to NULL and dwNotifierType to 0xFFFFFFFF. 3) When the session ends, terminate the connection with RasHangUp. DWORD RasHangUp ( HRASCONN hrasconn); 3.3 WAP Applications Typically, a web server needs to have a file system installed on the target machine. However, embedded systems often face limited storage resources, and a file system can increase the system load. Windows CE's Web Server is designed with a Web page format editor that can convert Java, GIF, JPEG, PDF, TIFF, HTML, and ASCII into standard C source files, which can be linked with other applications. The Web Server accesses these files in a virtual file system. When developing mobile communication products, the WAP protocol is required. Windows CE provides a WAP solution that is very convenient to develop. The protocol stack can support any standard wireless protocol, including GSM, UDP, GPRS, etc. The protocol stack includes WAE, WSP, WTP, WTLS, WDP, etc. [3]. See Figure 3. Figure 3 WAP application In addition, Windows CE also supports Bluetooth protocol, RFCOMM protocol, SDP protocol, L2CAP protocol, etc. 4 Creating an embedded platform based on Windows CE After the hardware design is successful, it is necessary to create an embedded platform based on Windows CE. With the platform, users can use the development tools of Windows CE to develop applications on the platform. To create a Windows CE-based platform, you first need to select a Windows CE OS configuration, install or create an OAL and device drivers, create a user-configured OS image file, and develop a bootloader to transfer the image file to the target device [1][2][3]. First, select a Windows CE OS configuration, and then add an OAL and device drivers. You can create your own OAL, use a pre-configured BSP (Board Support Package), or create your own BSP. A BSP contains an OAL, device drivers, and a custom list of hardware default components. Windows CE Platform Builder 3.0 includes a CEPC (CE-base PC) BSP and a Hitachi D9000 Hardware Development Platform (ODO). System developers can also develop their own BSPs or use third-party developed BSPs as needed. 5 Conclusion In embedded systems, network communication applications are becoming increasingly widespread. Choosing a suitable real-time operating system is key to developing embedded systems. This paper studies the development of Windows CE in network communication. There are still many issues worth studying in the future, including how to port Windows CE applications in ARM-based embedded applications, and how to use Windows CE debugging tools in conjunction with DSP and MUC debugging tools. References [1] Microsoft Corporation. Introducing Microsoft Windows CE 3.0 [M]. Microsoft Corporation, 2001, 1. [2] Microsoft Corporation. Microsoft Windows CE 3.0 Operating System Configurations [M]. Microsoft Corporation, 2000, 4. [3] Microsoft Corporation. Building a Localized Platform in Microsoft Windows CE Platform Builder 3.0 [M]. Microsoft Corporation, 2000, 6. [4] Hu Xuhuai. Communication technology based on Windows CE [J]. Computer Applications, 2000, 11