Windows CE is an operating system built by Microsoft for embedded devices, and there are many embedded devices. This requires the CE operating system to be customizable, therefore, Microsoft designs Windows CE as a modular operating system. To put it simply, we can think of Windows CE as a box of building blocks. You can build any object with blocks, but you don't have to use all the blocks.
An object built by Windows CE is a platform. It is a subset of the operating systems applicable to some fixed-standard embedded devices. The most famous platform is the Pocket PC, it is a platform provided for handheld computers without a keyboard. Because of the consistency between the platform and hardware, sometimes we also use the platform name to name the entire system-the sum of hardware and operating systems.
We can also develop our own platform. The development tool is the platform builder provided by Microsoft, and the version number of platform builder is the same as that of Windows CE.
More programmers are concerned about application development, and application development is targeted at specific platforms. Before development, we must install the SDK for the target platform, to develop development tools that adapt to the target platform.
Windows CE development environment overview
Another confusing concept for beginners is the version issue. Now we can see two generations of Windows CE products on the market. Their kernels are based on Windows CE 3.0 and Windows CE. net (4.0 ).
Microsoft collectively referred to the newly launched Pocket PC 2003 and smart phone 2003 as Windows Mobile 2003 this year. Most of the time, we still get used to the old title.
Pocket PC 2002, which is often seen on the market, is based on Windows CE 3.0, while Pocket PC 2003 is based on Windows CE.. NET platform. Note that the kernel of Pocket PC 2003 is Windows CE. net 4.2. Smartphone2003 is also based on Windows CE. net. The first version of smartphone is 2002, based on Windows CE 3.0, but Microsoft has not released the Chinese version of smartphone2002.
It is easy to explain the relationship between the platform and the CE. Tools provided by Microsoft to application developers include: Embedded Visual tools 3.0, including embedded Visual C ++ 3.0 and Embedded Visual Basic 3.0; Embedded Visual C ++ 4.0 and Visual Studio.. net.
The development tool version number corresponds to the Windows CE version number. Evc3.0 and evb3.0 are used to develop applications based on the Windows CE 3.0 platform. common platforms include Pocket PC 2002, Pocket PC 2000, palm-Size PC, and HPC. Evc4.0 is used to develop programs on the Windows CE. NET platform, including Pocket PC 2003 and Smartphone 2003.
Visual Studio. NET requires the support of Sde for embedded device development, while vs. NET 2003 includes SDE and does not require additional installation. Programs developed by Visual Studio. NET must support. NET Compact framework on the target platform. Currently, platforms that support. NET Compact framework include Pocket PC 2002 and Pocket PC 2003. Note that Smartphone 2003 does not support. NET Compact framework.
Getting started with EVB Development
Microsoft has announced that EVB no longer supports Windows CE. net, so the final version of EVB is 3.0. However, because EVB is easy to operate and fast to develop, it became the best choice for rapid development on the Windows CE platform before vs. Net was born. Now, EVB is still suitable for the rapid development of small applications on Windows CE 3.0. If you are not a full-time Windows CE programmer, but you only need to develop a part of the entire system on the Windows CE platform, EVB allows you to develop your desired program in a short time.
The EVB development environment is also very simple. You can download EVT 2002 from Microsoft's website, including EVC 3.0, EVB 3.0, Pocket PC 2002 SDK, and smartphone 2002 SDK. Follow the prompts to install the EVB and Pocket PC 2002 sdks before development. The SDK contains a simulator. You can use the simulator to debug the program without the actual device.
Note that the development environment communicates with the simulator through the network connection protocol, so the computer used for development must have an active network connection. If not, you can install Microsoft's virtual network card.
The development environment of EVB is similar to that of VB. Because Windows CE applications need to be debugged on simulators or devices, we must select the output target of the program. If you select emulation, after you press run (or F5), EVB automatically starts the simulator and downloads the program to the simulator.
Because of the new Windows CE. net will no longer support EVB. Microsoft recommends that EVB programmers use VB. net to develop new programs, and the original EVB Program also provides the migration path. For more information, see the msdn Article moving from Embedded Visual Basic to Visual Basic.. net.
Getting started with EVC Development
Visual c ++ is a powerful development tool for both Win32 and wince platforms. EVC is also a mainstream development tool on wince. EVC supports the subset of the MFC class library and provides developers with the most powerful support. It also allows VC programmers on the Win32 platform to easily migrate to the wince platform. However, because the MFC class library requires a DLL, it is a great burden for some embedded devices with limited storage space. Therefore, smartphone does not support MFC.
Let's create an EVC project. Is it similar to VC? Please note that, because the embedded devices support many CPU types, when we choose to create a project type, select the CPU type supported by the project. The process of creating a project is the same as that of VC. Of course, different platforms support different engineering types. For example, Pocket PC 2003 supports two types of projects: MFC and API, while Smartphone 2003 only supports one type of project.
In the EVC environment, a drop-down menu option is added, which is used to select projects, sdks, cputype, and output devices. Taking the Pocket PC as an example, Win32 (wce armv4) debug should be selected for debugging on the actual device, and Win32 (wce emulator) debug should be selected for debugging on the simulator.
Getting started with vs.net
It's time for our. Net again? Recently, everyone has been overwhelmed by Java and. net, right? No matter how noisy,. NET Compact framework is undoubtedly a good news for Embedded programmers who lack development tools. Visual Studio. NET 2003 fully supports mobile device development. Well, let's start a fantastic. Net journey.
Open vs.net 2003 and select File-New-project to open the interface above. Let's create a Visual C # project, select smart device application, and then OK.
Here you need to select the target device: Pocket PC, smartphone, and Windows CE (other platforms). The following shows the project type you have created. Select "Windows application ", on the left is the simulator supported by the selected platform. Click OK to go to the main page of vs. net.
Selecting an output device is similar to EVB. You only need to select an output device instead of the CPU type. Of course, because. Net runs on a virtual machine. In many embedded fields of CPU type,. NET and Java can truly exert their strengths.
Of course, we can also choose VB. NET as the language for developing smart devices. The situation is exactly the same as that of C. Currently, smart device development only supports C # and VB. NET. C ++ programmers may have to wait for a while.
Windows CE development advice
It can be said that when we spend most of our time porting existing applications to Microsoft Windows CE. Generally, this plan is not too difficult. We started with Microsoft Win32 code. Of course, Windows CE is based on Win32 application interfaces (APIS. It is advantageous that our application (Raima Data Manager) has easy-to-use interfaces and contains a library consisting of approximately 150 sub-functions written in C, it can be used to create, manage, and access databases.
By setting up an application, we thought porting it to Windows CE was a relatively simple C language programming exercise. However, we will soon encounter some difficulties. Starting from a careless error, for example, using the Microsoft Windows NT library on a Windows NT-based Windows CE simulator, and then violating the Windows CE programming rules, for example, "Do not assign an odd memory address to Unicode (International Standard Organization 10646) characters ".
About 90% of problems are more or less related to Unicode. Although Unicode programming is not difficult, it is easy to make mistakes when writing code for single-byte characters (I have had many errors ).
The following suggestions are based on our experience in writing Raima Data Manager on Windows CE, but I believe they are worth learning before any other Windows CE program. After all, when most Windows developers create the first Windows CE application, they actually use the existing Win32 knowledge.
Do not use the Windows NT library on the simulator
The first mistake discussed here is too stupid, but I am stuck in it. Maybe you will. When Microsoft Vc ++ (Version 5.0) is used to create a Windows CE program, you will find that the include path and library path) and the executable program path is automatically adjusted to match the selection of the target environment. Therefore, for example, when creating an application for the Windows CE simulator, you will find that the include path does not point to the Win32 inclusion file (in the VC directory ), instead, it points to the Windows CE inclusion file (under the wce directory ). Never modify it.
Because Windows CE runs in Windows NT, the program running on the simulator can call functions in any Windows NT dynamic link library (DLL), even if the DLL is not a member of the simulator. Obviously, this is not good because the same functions may be unavailable on handheld PCs (H/PCS) or Windows CE devices, and your software will eventually run on these devices.
When you load a non-Unicode application into a Windows CE Simulator for the first time, you will find that many functions in use are not supported, such as the American National Institute of Standards (ANSI) strcpy (). This may lead you to link to the Windows NT Runtime Library to solve all the problems.
If you are programming with Windows CE at the beginning, you may be able to include files and library files obviously. The answer is, you should not use include files and library files that are used when writing common Win32 or non-Windows CE programs.
Do not confuse tchars and bytes
If you are writing a non-Unicode application on Windows CE, you may want to convert all strings from a single character (chars) to a wide character (widechars) (for example, the C variable type whcar_t ). Almost all Windows CE-supported Win32 and Runtime library functions require wide character variables. Windows 95 does not support Unicode. However, to make the program code portable, you should try to use the tchar type defined in tchar. H, instead of using wchar_t directly.
Whether tchar is defined as wchar_t or char depends on whether the pre-processor's symbol Unicode is defined. Similarly, all macros related to string processing functions, such as _ tcsncpy macro, are defined as Unicode function wcsncpy or ANSI function strncpy, depending on whether Unicode is defined.
In existing Windows applications, some code may imply a single-byte length. This is often used to allocate memory to strings, for example:
| Int myfunc (char * P) { Char * pszfilename; Pszfilename = malloc (maxfilelen ); |
In this Code, the allocated memory block should be written (maxfilelen * sizeof (char), but most programmers prefer to simplify it to maxfilelen, because sizeof (char) for all platforms) the value is equal to 1. However, when you use tchars to replace multiple characters, it is easy to forget this inherent concept and write the code into the following form:
| Int myfunc (tchar * P) { Tchar * pszfilename; Pszfilename = (tchar *) malloc (maxfilelen ); |
This is not acceptable. It will immediately cause an error. The error here is that the variable size specified in the malloc function is bytes, but the third variable used in the _ tcsncpy function is specified as tchars rather than bytes. When Unicode is defined, a tchar is equal to two bytes ).
The above code segment should be rewritten:
| Int myfunc (tchar * P) { Tchar * pszfilename; Pszfilename = (tchar *) malloc (maxfilelen * sizeof (tchar )); |
Do not place Unicode strings in an odd memory address
On intel series Processors, you can store any variable or array in an odd number of memory addresses without causing any fatal errors. But on H/PC, isn't this always possible? You must be cautious with data types larger than one byte, including wchar_t defined as unsigned short. When you try to access them, placing them in odd addresses will cause overflow.
The editor often reminds you of these issues. You cannot manage the stack variable addresses, and the editor will check whether these addresses match the variable types. Similarly, the Runtime Library must ensure that the memory allocated from the heap always meets a word boundary, So you generally do not have to worry about those two points. However, if the application contains code that uses the memcpy () function to copy the memory area, or some type of pointer arithmetic is used to determine the memory address, the problem may occur. Consider the following example:
| Int send_name (tchar * pszname) { Char * P, * q; Int nlen = (_ tcslen (pszname) + 1) * sizeof (tchar ); P = maloc (header_size + nlen ); |
This code allocates memory from the heap and copies a string, leaving a header_size at the beginning of the string. If Unicode is defined, the string is a widechar string. If header_size is an even number, this code will work normally. However, if header_size is an odd number, this code will fail, because Q points to an odd address.
Note that this issue does not occur when you test this code on an Intel series processor Windows CE simulator.
In this example, you only need to make sure that the header_size is an even number to avoid the problem. However, you may not be able to do this in some cases. For example, if a program inputs data from a single PC, you may have to use a pre-defined binary format, although it is not suitable for H/PC. In this case, you must use functions that use character pointers to control strings rather than tchar pointers. If you know the length of the string, you can use memcpy () to copy the string. Therefore, a function that analyzes Unicode strings one byte may be enough to determine the length of a string in widechars.
Translation between ANSI and Unicode strings
If your Windows CE application interface is on a Windows PC, you may have to operate the ANSI string data (for example, char string) in the PC ). Even if you only use Unicode strings in the program, this is a fact.
You cannot process an ANSI string on Windows CE because their library functions are not manipulated. The best solution is to convert an ANSI string to a unicode string on the H/PC, and then convert the Unicode string back to the ANSI string to use the PC. To complete these conversions, you can use multibytetowidechar () and widechartomultibyte () Win32 API functions.
Split (hack) for String Conversion in Windows CE 1.0)
In Windows CE 1.0, these WIN32API functions are not completed yet. So if you want to support both Ce 1.0 and Ce 2.0, you must use other functions. You can use wsprintf () to convert an ANSI string to a unicode string. The first parameter uses a widechar string and recognizes "% s" (uppercase), which means a string. Since wsscanf () and wsprintfa () are not available, you must find another way to convert Unicode strings back to ANSI strings. Because Windows CE 1.0 is not supported by NLS, you may have to turn to hack, as shown below:
| /* Definition/prototypes of conversion functions Multi-byte (ANSI) to widechar (UNICODE) Atow () converts from ANSI to widechar # Define atow (stra, strw, lenw )/ # Define wtoa (strw, stra, Lena )/ # Else/* _ win32_wce >=101 )*/ /* Endif/* _ win32_wce >=101 */ # If (_ win32_wce <101) Int atow (char * stra, wchar_t * strw, int lenw) /* Int wtoa (wxhar_t * strw, char * stra, int Lena) # Endif/* _ win32_wce <101 */ |
This method is easier to implement for Windows CE 1.0 than to use the wsprintf () function, because it is more difficult to limit the length of the string pointed to by the target pointer by using the wsprintf () function.
Select the correct string comparison Function
If you want to classify Unicode Standard strings, you can use the following functions:
Wcscmp (), wcsncmp (), wcsicmp (), and wcsnicmp ()
Wcscoll (), wcsncoll (), wcsicoll (), and wcsnicoll ()
Comparestring ()
The first type of function can be used to compare strings. do not refer to local or foreign characters. If you never want to support foreign languages, or you just want to test whether the content of the two strings is the same, such functions are very useful.
The second type of functions use the existing local settings (system settings, unless you call the wsetlocale () function before the string comparison function) to compare the two strings. These functions can also correctly classify foreign characters. If the local character "C" ("C" locale) is selected, these functions have the same functionality as the first type of functions.
The third type of function is Win32 function comparestring (). This function is similar to the second type of function, but it allows you to specify the local settings (the locale) as a parameter, rather than using the existing local settings (current locale settings ). The comparestring () function allows you to specify the length of two strings. You can set the second parameter to norm_ignorecase to make the function case insensitive when comparing strings.
Generally, the comparestring () function is not case sensitive even if the second parameter is not set to norm_ignorecase. We often use the wcsncoll () function to distinguish between uppercase and lowercase unless the local character "C" ("C" locale) is used ). Therefore, in our code, the comparestring () function is not used for Case sensitivity, but the wcsncoll () function is used for Case sensitivity.
Do not use relative paths
Unlike Windows NT, Windows CE does not have the current directory concept. Therefore, any path is relative to the root directory. If your software uses relative paths for files or directories, you are likely to move them elsewhere. For example, the path "./ABC" is treated as "/ABC" in Windows CE.
Removed call to calloc () and time () Functions
The calloc () function in the C Runtime Library cannot be used, but the malloc () function can replace the calloc () function. Do not forget that the memory allocated during the calloc () function Initialization is zero, while the malloc () function is different. Similarly, the time () function cannot be used, but you can use the Win32 function getsystemtime () instead of the time () function.
After the above warnings, you will happily learn the two points of advice that surprised you at the end.
You do not need to change the call to the Win32 input/output (I/O) file.
Windows CE also supports Win32 input and output functions. Allows you to access objects as you access the Win32 file system. The createfile () function does not recognize the file_flag_random_access flag in Windows CE. However, this flag is only used for optional disk access and does not affect function calling.
Do not worry about the byte status
When we write an application to Windows CE, we can find that the digital data type of Windows CE is in the same byte State as that of intel, windows CE supports all processors.
Like almost all database engines, the Raima Database Manager stores digital data in binary form in database files. This means that a record is processed as a series of bytes no matter when it is written to or read from the database. As long as the database files are not transmitted to any other system, the problem of the byte status of the digital data is solved. If the database file is accessed by a processor from the original system with different bytes, the digital data will be misunderstood.
This problem occurs whenever you transfer files on machines with different processors. It is worth noting that all types of processors use the same byte status.
When using Windows CE, these suggestions should attract enough attention to avoid learning detours.
This article from: http://www.biplip.com/Default.aspx? Tabid = 34 & Mid = 348 & CTL = view & Itemid = 288
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
