A Pragmatic Perspective by Nino D'Aversa

0.3 Release Update

So the last few nights I have been working towards my 0.3. My short term task was to port the minimo code over to work with the latest tree of Fennec. I added a phone directory to my mobile/components and placed my IDL, CPP and Makefile.in in there. I got to use the knowledge from the XPCOM Lab to help generate my makefile by using this command

../build/autoconf/make-makefile -d 0 mobile/components/phone

I added -d 0 because make-makefile could not automatically determine the depth on its own. Once I got my make file generating it was on to the task of compiling. First problem I had was with the following line in my cpp file:

HMODULE hPhoneDLL = LoadLibrary("phone.dll");

The parameter was giving me an invalid pointer error, I did some research and realized I needed to add the L in front of the string in order to cast the string to a Unicode literal, like this:

HMODULE hPhoneDLL = LoadLibrary(L"phone.dll");

After I got past this I ran into a few other issues. It appeared to me that I was having a linking issue as I got the following output from my compile attempt:

nsPhoneSupport.obj : error LNK2019: unresolved external symbol "unsigned int __cdecl NS_NewGenericMo
dule2(struct nsModuleInfo const *,class nsIModule * *)" (?NS_NewGenericModule2@@YAIPBUnsModuleInfo@@
PAPAVnsIModule@@@Z) referenced in function NSGetModule
phone.dll : fatal error LNK1120: 2 unresolved externals

My understanding was that phone.dll was from the Windows Mobile SDK, so I tried to figure out where the phone.dll file was and how to make sure it was included in my build path. I was on IRC at the time and humph graciously offered some help, his suggestion was that my linking order from the command could be the culprit. We tried manipulating the command manually to reorder it; but to no avail.

Then I received a tip from wolfe in #wince, he suggested that since the linking errors were for methods starting with ns that it was mozilla library dependencies that I was missing. Shortly after mfinkle arrived and indicated that I probably wasn’t linking to the right XPCOM Glue. So as I started reading and poking I came to the realization that the makefile was probably the area which I needed to update, as I came to the realization mfinkle asked to see my makefile. So it went that my makefile needed to some extra hacking to include the shared libraries I needed.

EXTRA_DSO_LDOPTS +=
$(XPCOM_GLUE_LDOPTS)
$(NSPR_LIBS)
$(NULL)

After add this I got past my linking errors! After this all that was left was making a change to my #include from #include “nsString.h” to #include “nsStringAPI.h”. Once I had all those bits in I was compiling and getting my phone.dll and phone.xpt (that’s where they are, I needed to build them!).

It was definitely a muddling through exercise; I appreciate all the help I received from humph, mfinkle, blassey and wolfe. Although I don’t think all the hand holding was in vein, I learned quite a bit about porting a small piece of code over.

Next on the agenda is testing my phone.dll. The problem I’m currently having is that the emulator is excruciatingly slow (rather Fennec inside the emulator is). So I asked mfinkle if I could test outside of Fennec itself. The answer is yes, if xpcshell would work (which it seems it doesn’t, yet) or through some other simple non-browser app we could test the component. So as of now I have my code ported and a simple JavaScript test ready to go, so the next step is figuring out a way to run that JavaScript test in the emulator.

Definitely a good night overall, I’m learning loads and discovering how committed and helpful the community can be, its very welcoming and reassuring, especially when you get thrown into the fire.

On to this week’s lab now…

0.3 Release Goals

So I spent some time today on IRC with mfinkle and blassey in #wince to work out what I could work on for my 0.3 release.

I have mixed emotions, I’m very excited to do something that can useful, but also intimated by the work in front of me (since its my first real coding assignment for Mozilla). The community is great though, its small but everyone seems to care a great deal about helping out and moving Fennec forward, so I feel that I will have the support I need to succeed.

So for my 0.3 I will be undertaking the job of making tel: links work for Windows Mobile.

The idea is when you have a link such as:

 <a href="tel:123-456-7891"> call me </a>

and when it is clicked, it will bring up the Windows Mobile dialer to make the call. What I need to do is port the code from minimo (which was older version of the wince browser) so that it works on the latest build of Fennec. This should provide the hooks needed to make a call with the phone.dll on WM. After that is complete I need to modify nsTelProtocolHandler.js to use my new dialing component.

This is definetly cool stuff, it just happens that earlier today I was checking some e-mails on my iPhone and there was a phone number in the message I needed to call, so all I had to do was click it and it started dialing. I said to myself, this is such a useful feature, so I’m glad that in a small way I can bring the functionailty to the Windows Mobile build.

I’ll update more soon when I get my hands dirty, but first I need to tackle that XPCOM lab, which looks to be critical to my success for my 0.3 objectives. (Well timed! – Good job humph!)

Update: the bug is here.

0.2 Release

I should have posted this on Thursday but things have been hectic.

I got my 0.2 release done, which involved building Fennec and setting up my build environment on Windows with Visual Studio.

I must say it was a very satisfying feeling when Fennec finally worked on my emulator. Although there were some roadblocks.

It’s challenging working on something as young as Fennec, it being in alpha stages, documentation is sparse and the bit of documentation that exists is always finding itself out of date as things change so rapidly. Luckily for me the Fennec community is very helpful, I found myself on #wince on moznet very quickly and was greeted warmly by wolfe, blassey, mfinkle and others. They helped me work through some of the problems I was having and were instrumental in helping me get my build working right. Although this may be a small step, it is the first and essential one if I wish to become part of the team on Fennec. Hopefully I can get a nice bug for my 0.3 and pick up some odds and ends over the break.

Thanks to David for suggesting the switch to Fennec, I am much happier and more excited as I look forward to the future.

Here is a screen cap of my emulator running Fennec.

Fennec running on Windows Mobile Emulator 6.1 Professional

I have noticed some chrome related issues (size and positioning being a bit wacky), but blassey suggests this is due to the limited screen size on my emulator, since the UI has not been accommodated for this (yet).

Also to touch upon my previous post the 6.1 emulator solved my problems. It is true that the 6.0 emulators (may seemingly allow you to change the ram allocation) suffers from a bug which results in the RAM not being avaiable, the 6.1 emulator has solved this, once I moved over to those emulators everything ran smoothly, thanks to wolfe for the tip.