• Create a reusable static library
• Create a executable project
• Mix C++ code with object C code

1. Start terminal, cd to root folder of protobuf and run ./configure here to generate config.h header file and makefile.

2. Start XCode and create a new project. Select iOS – Library – Cocoa Touch Static Library project template.

3. Right click Other Sources and select add Existing Files.

4. Select the src/google directory, and add the directory recursively.

5. In the previous step, we add too much source files than actually needed. The sources files for the protoc compiler and unittest are included too. They’re not needed to run ios application. To filter out unnecessary files, we can refer to the libprotobuf_lite_la_SOURCES and libprotobuf_la_SOURCES variables in src/Makefile, which list source files needed for protobuf library.

6. Now we need to add header file search path. Click Edit Project Settings under Project menu item.

7. Double click Header Search Paths.

8. Add protobuf and protobuf/src directory.

9. Now build the project.

10. In the terminal, run “make install” command to build protoc compiler and install it to default location(/usr/local/bin/protoc).

11. Go to examples directory and run “protoc addressbook.proto –cpp_out=./” to generate addressbook.pb.cc and addressbook.pb.h files.

12. Create a Window-Based Application.

13. Add reference to the static library we built. Right click Frameworks and select Add Existing Frameworks.

14. Click Add Other button.

15. Select the libprotobuf_ios.a file and click add button. Also, we need to add protobuf/src and protobuf/examples directory to Header Search Paths for this project.

16. Rename add_personAppDelegate.m to add_personAppDelegate.mm so that it’ll be compiled as object C++.

17. The basic logic of add_personAppDelegate.mm is first create the addressbook.dat file in iphone’s document directory. Then create a new AddressBook instance and add a person to it. Finally serialize the addressbook to the file we created. The full source is :

18. After build and run the application in iphone emulator, we get generated addressbook.dat file in /Users/user_name/Library/

1. It has an efficient binary serialization algorithm
2. It runs cross platforms
3. It support mainstream programming languages, c++, python and java. there are also lots of porting out there for other popular languages.
4. It’s designed to make protocols both backward and forward compatible.
5. It enables developers to focus on protocol design.

 Currently, there is no official windows CE version for protobuf. It’s not an easy task to port protobuf full version to windows CE. But the lite version, which supports less feature than full version (check the explanation for optimize_for option in this page for what’s the difference), is easier to port. Here is how I port it:

1. Create a Win32 Smart Device Project library project, name it protobuf-lite-ce
2. Copy all source files from protobuf-lite project to protobuf-lite-ce project in Solution Explorer
3. Create a ce_port folder in the project’s directory, and copy the errno.h header file from (Visual_Studio_Root)/VC/include into the folder. This is because Windows CE doesn’t have this file, so we need to provide one. Actually, this errno.h can be a pure empty file.
4. Add “../src;.;./ce_port” to the project’s Additional Include Directories.
5. The windef.h header file already defines OPTIONAL macro, it conflicts with Cardinality::OPTIONAL enum. So the extension_set.cc fails to compile, to solve this, add following code before enum Cardinality definition to undefine OPTIONAL:

Now the protobuf-lite-ce project should compiles fine.
Here is the project file for downloading. Just get everything there and place them in protobuf/vsprojects/ directory.

I noticed below statements in section “4.2 Functions Returning Non-integers”, which explains the question, why can we use printf without including stdio.h.

So, let’s take a look at the hello world sample below:

When the code is compiled, the statement on line 5 implicitly declares the printf function because it’s not declared explicitly. It’s the same as if we declared printf as:
  int printf();
And there is no assumption about its argument, so the code can pass the compile phase.

In link phase, unlike c++, only the function name (function signature doesn’t matter) affects the symbol name. So the printf symbol name can be found from the standard c library which is linked automatically. As a result, the code above can compile and run successfully.

The two buttons will each create a new thread to send and recv audio data respectively. And the sender will read audio data from the file /data/1.wav. Then, it sends the data to udp port 2048 on localhost. The receiver reads on 2048 port and feed data received to AudioTrack object.
Full code is available at:
http://code.google.com/p/rxwen-blog-stuff/source/browse/trunk/android/streaming_audio/src/rmd/media/StreamingAudio/UdpStream.java

3. Include  platform/platform_name/src/common/bootpart into our build

4. The last step is to update other modules’ sources file. For any module that depends our modified bootpart module, we should change its sources file so that it can find the new bootpart instead of the original bootpart shipped with CE. For instance, change $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\bootpart.lib to $(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\bootpart.lib     

Given the PC register value, we need to figure out on while line in our code did the application crash. winaddr2line makes it an easy task as long as we have the pdb symbol file for the application. It’s a attempt to port addr2line to windows world.
Let’s take the preceding log for example. In order to find out the line number of the code that incurs the crash, we need following information.

1. In which module did the crash happen
2. What’s the address can we use to query

For question 1, the module name is already available in the log. In our example, it’s test.exe. For question 2, we can see the PC register’s value is 0×00011048. So, we run “winaddr2line.exe -e test.exe 11048 -a -p -s -f” command, and get this: “0×00011048: foo::crash at test.cpp:8″. Now we open test.cpp and check what’s around line 8, the root cause is very obvious.

In order for the preceding command to work correctly, we must make sure the test.exe and its symbol file test.pdb is available in current directory of the shell that we run winaddr2line. If it’s not the case, we should pass correct path to test.exe for -e argument and path to directory containing test.pdb for -y argument respectively.

In the example, we use PC register’s value directly to query line number. But it’s not always the case. Consider the crash log below:

The crash occurred in coredll.dll module. We run command “winaddr2line.exe -e coredll.dll 4006d270 -a -p -s -f”, but we can see it fails to find the line number. This is because we can’t use the PC register’s value directly here. The coredll.dll is loaded at 0×40010000 (0x4006d270-0x0005d270), which is different from its preferred ImageBase address (0×10000000, which can be examined with “dumpbin /headers coredll.dll” command). And winaddr2line can only make use of the ImageBase address contained statically in PE header of the binary. So, we must change the address to 0x1005d270 (0×10000000+0x0005d270). By using this address, we can see the crash occured at: d:\dublin2-1\private\winceos\coreos\core\dll\crtsupp.cpp:240

Source code for winaddr2line:
http://code.google.com/p/winaddr2line/

The main drawback with Alt+Tab is it forces us to deal with more problems. For example, we want to switch to firefox task, the essential problem we’re dealing with is finding the task using the clue “FIREFOX”. After we press Alt+Tab, we get a window list in which all tasks are identified by icons. Now, we have to deal with another problem, finding out the icon that represents firefox. That’s to say, our brain has to do a “context switch” from the “word processing” problem to an “image recognition” problem.

It’s not intuitive at all. The idea of QuickSwitch is very similar to Spotlight on mac and FuzzyFinder on vim. We can keep concentrating on the “word processing” problem, no context switch.

QuickSwitch runs as a daemon. By using it, at any time we want to switch ao another task, press Ctrl+Alt+S key combination to bring up the QuickSwith main window, in which all tasks are listed. Then, type any part of the window title of the desired task and press enter to switch to it.

For instance, if we want to switch to firefox task. Type “firefox” in the input box. As we type, the window list is filtered. Those windows don’t contain the word we typed in title are filtered out. When there is only one result left in the list, we can press enter key once to switch to it. If there are more than one one result left, we can continuing typing more characters to filter out more un-desired tasks. Or we can press enter to bring focus to the result list and use up, down keys (or Ctrl+P, Ctrl+N) to select desired task and press enter again to switch to it.

Source code:
http://code.google.com/p/quickswitch/

Features
1. Extensibility
The essential feature of oalioctl is it enables us to extend windows ce kernel’s functions, and new functions are directly accessible to application layer developers.
2. Separation
oalioctl is completely separated from kernel source code. From the sense of code organization, it doesn’t differ from a normal device driver. The separation makes it easy to maintain and port oalioctl module.
3. Easy to use

Compared to a normal ce driver, the usage of oalioctl is easier from an application developer’s perspective. In order to make use of a normal driver, application usually follows below sequence:
CreateFile -> DeviceIoControl -> CloseHandle
But the application can simply call KernelIoControl to make use of oalioctl library, which is a far more easy way.

Implementation
oalioctl is implemented as a standalone dynamic library. And it will be loaded automatically during kernel initialization (relevant code is in LoaderInit() function in X:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\loader.c). So it’s not necessary to register this module in platform.reg as other stream drivers do.
When an application calls KernelIoControl, the call stack goes like this:

How to implement our own oalioctl
It’s a fair simple task to implement oalioctl layer for our own platform with following steps:

1. copy public/common/oak/oalioctl directory to platform/platform_name/src/drivers
2. change TARGETTYPE to DYNLINK in sources file
3. define our own iocontrol code with CTL_CODE macro
4. add a case branch for the new iocontrol code

There are two ways to resolve the connection issue.

1. Run remote tools from windows start menu (e.g., Microsoft Visual Studio 2005\Visual Studio Remote Tools\Remote Process Viewer, which is a shortcut to C:\Program Files\CE Remote Tools\5.01\bin\ccpview.exe), instead of starting from visual studio menu (e.g., Target/Remote Tools/Process Viewer, which is a shortcut to C:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\bin\wce600\cepview.exe). remote tools version 5.01 work fine.

2. Copy
c:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\target\wce600\armV4i\
to
c:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\target\wce600\armV4\
. The lack of the second directory is a bug in remote tools version 6 that causes the connection issue.

When we have a long call stack, instead of running the command above for each line in the call stack manually, we can feed the whole call stack to agdb through pipe and get the full resolved call stack. For example, use  “adb logcat | agdb.py -r” command for adb logcat output with below contents:

we get:

Similarly, we copy a tombstone file to our development pc, and use “cat tombstone_01.txt | agdb.py -r” command to resolve call stack addresses in the tombstone log file.