Phoneme advanced and eSWT Running Under x86 Windows

Phoneme advanced and eSWT Running Under x86 Windows

Recently I still try to find interesting things to explore freely. One thing is that I mention I'd like to contribute the Eclipse in some projects, like e4 language or VE(I avoid contributing to the projects full of employees). However, the feedbacks seem not active. In my view, the reason that Eclipse is the current Eclipse is just the gigantic, passionate, dream-filled community.

Oh, come to the right topic.

There are many research JVMs under the linux. All of them are much not friendly to Windows users(the fact is that almost of them even do not consider the problem of porting to Windows). Although the linux environment is better for some programmers, it is very dangerous to think only from the programmer's perspective as a programmer. This behavior could kill your community. 

"Phoneme advanced" is one CDC target Java platform(JavaME, academically. And, I will call the "Phoneme advanced" JVM as "CVM" as follow), which is opensourced from Sun's product(after the OpenJDK borning) under the GPLv2. 

The attractive thing for me is that CVM could be seen as the compact version of J2SE 1.4(yes, that is, CVM fully complies with the JVM Specification, 2rd). That is, we can do many useful things on it.

It is easy to get the source of Phoneme. However, like all other research VMs, the build system of Phoneme is based on the sh/make of Linux. This is not easy to Windows users. To find , We need Cygwin, which provide a linux-like enirvonment for Windows. A little inconvenience for Cygwin is that it needs to be installed via internet connection. 

The good news is that the phoneme adv. provide make files for win32-x86 platform and VC build toolchain. The bad news is that the the default building scripts are not fully matched with your actual options. If your VC or SDK was installed into non-default directory, you need to carefully examine the output infos to find what the enirvoment variables are wrong and you should redefine those variable. Two detail clues here, 

1. the path for Windows is not valid for Cygwin, modify it like c:\xxx -> /cygdrive/c/xxx

2. for the Vs8 build script, the variable "PLATFORM_SDK_DIR" can not be overrided(a bug?). You should modify it by hand.

After more or less tweaking, I get the CVM into running successfully, Cool! The coolest thing is not that the CVM could be run, but that the packed size of the runnable CVM with the foundation runtime library is just about 1.1MB.  

The next big is the capability of UI application for cvm. One thing here is, you need to rebuild the native codes against with CVM' JNI headers. Don't try to use existed native library directly. Firstly, I test the SWT. But I get errors when compiling the sources under VC++2005EE and MS Platform SDK. Error logs like as follow,

...

...\MicrosoftSDK\Include\exdisp.h(39) : error C2061: syntax error : identifie

r 'IWebBrowser'

...\MicrosoftSDK\Include\exdisp.h(39) : error C2059: syntax error : ';' 

...

I can not figure out how to solve this problem. If you know, please let me know:)

Then, I remember the eRCP again. In my eye, it's a lightweight RCP implementation even for desktop. The eSWT is the base of eRCP. I fetch the eSWT sources. But frankly, bugs in the eSWT win32 codes is not rare. I have some years not to touch the C/C++ codes.Otherwise, this is a good chance for me to play with JNI deeply. After a while, I get them compiled successfully again. Cong! 

 

The above sreenshot is a sample code shipped with VE, called "SimpleSWTTextEditor". I do a little modifications to the text to test UI(JNI) and Unicode support of CVM. As you say, the basic aspect of UI is nice. However, the text of widgets has been append unreadable characters.

After intensively debugging, I find the problem exists in the #GetStringChars() method. This method return the jchar* which is called by #convertToNativeString, however this implementation in CVM seem has a non-standard behavior. (I am not sure to open this bug to eswt? or cvm?). Then after fixing this problem, I get the nearly perfect solution. The Unicode support is nice for both English and Chinese.

 

Cong! You can dream the next story...