Some new information on the Java compliance of PPC Web browsers

Menneisyys · 07-15-05, 11:17 AM

Over at iPAQ HQ, a Java-enabled browser was looked for for displaying and controlling the animation here.

As in the last two months two new Java-capable browsers (JVM stands for Java Virtual Machine and being Java-enabled means that the given browser will (?) be able to render Java applets) have been released (Thunderhawk 2.1 and NetFront 3.2), I’ve jumped on the chance to make some new comparison tests, mostly because

1, this applet has more advanced GUI components – that is, a scrollbar – and not just buttons/menus, unlike in my previous tests. I wanted to check out how Thunderhawk (TH), which, unlike the other Java-enabled browsers, uses strictly client/server (c/s) Java rendering, fares againts the competition (it failed).

2, it also uses an applet window bigger than the QVGA, and even the VGA screen. It was a big problem with the Jeode PIE plug-in, back in 2001, that it wasn’t able to render bigger applet windows than QVGA. Therefore, I wanted to know how the latest JVM’s fare in this area. (All passed.)

Please note that this is the nth instalment in my Java-on-the-Pocket PC series. You may want to read the following previous instalments; just to name a few (it’s the best to make a generic search on ‘Java’ on my nick in Pocket PC forums):
Compiling/editing Java on the PPC
Create your own custom word dictionary - a working, free solution
Using Java on the Pocket PC - the complete tutorial

Now, for the tests:

NetFront 3.2:

It displays the applet, everything works (to a certain degree), BUT:

on VGA devices, in the standard, default SE VGA mode, and even in forced VGA mode, it uses low resolution in the applet area:

Default SE

Default SE, with forced VGA mode

As you can see, NetFront 3.2 miserably failed at the forced VGA mode: it just chops off half of the applet area. Therefore, never use NetFront in the forced VGA mode to render large applets!

In native VGA mode (the one that can be switched to with SE_VGA or OzVGA), everything worked just fine:

I’ve also faced another problem (which was the same with version 3.1 of Netfront, which had a completely different JVM): the memory and the CPU leak. Even horizontal scrolling of the applet are was almost impossible while displaying it, due to he memory leaks and the CPU usage; after exiting NetFront, the JVM still remained in the memory, totally slowing down the entire device. That is, if you use the JVM in NetFront 3.2, you most probably end up reseting your PDA after your Java session. This problem is particularly prevalent in native VGA mode.

I’m not very happy to say that the JVM in NetFront is still buggy…

Pocket Internet Explorer with the CrEme 4.00b8 PIE plug-in:

It’s working great! Much better than Netfront 3.2 because
1, it’s Hi-res even in SE on VGA devices
2, is completely removed from the main memory after you exit, unlike the NF3.2 JVM.

A bit of warning: CrEme 4 blindly overwrites (instead of appending to it!) [HKEY_LOCAL_MACHINE\Loader], so, your all previous so-called “System path” settings will be gone! Please see for example this thread on the System path and its usage. Also, as with the older (3.26) version, the installer EXE file won’t be able to execute on desktop Windows computers that have localized \Program Files directories (for example, \Programme with German Windows).

Thunderhawk 2.1:

Well, unfortunately, the c/s communication and plain image reload model of the TH JVM certainly sucks at both animation, bandwidth usage and, certainly, GUI control, as I’ve predicted here and, later, in my first “real” TH 2.1 test, confirmed here. While the “Set Animation Speed” slider can be dragged without problems in other browser + JVM combos, in TH, as you may already have guessed, it’s impossible to do this. Why? Because you only get an image, and not real, client-side GUI controls. This means you can only slide a slider one step at a time, in a very time (and bandwidth-) consuming manner. There is no way of dragging sliders at all!

Furthermore, it’s QVGA on VGA devices, and, what is more, the picture is skweezed – that is, you will hardly be able to make out what is written on the map:

A quick TH tip never published before: the app creates a \Windows\winsys.bat file to store user information. If you remove/relocate it, you’ll be able to log into Thunderhawk from another user account – it’ll start with defining the new screen again.

Menneisyys · 08-15-05, 04:51 AM

While evaluating Pocket Mechanic in the Utilities /Maintenance category (I will publish adetailed roundup of these apps in the near future, so, stay tuned :) ) during the Pocket PC magazine Best Software Awards 2005 process, I’ve noticed another bug in CrEme, in addition to the above-mentioned System Path bug: it registers .jar and .jad files in the Registry without using “ marks when entering the path of creme.exe to the Registry. This will mean the system won’t find creme.exe at all when you click a .jar or a .jad file.

Curing this problem is very simple: insert " marks before and after the \< home>\NSIcom CrEme\bin\creme.exe string (so that the entire registry value becomes "\\SD-MMCard\\NSIcom CrEme\\bin\\creme.exe" -Of -mv '%1') in both [HKEY_CLASSES_ROOT\jadfile\Shell\Open\Command] and [HKEY_CLASSES_ROOT\jarfile\Shell\Open\Command] .

BTW, speaking of Web browsers, you may also want to read two of my newer, Web-related roundups, they contain everything you may want to know about Web browsing on the Pocket PC:

Pocket PC Web browsers - the complete roundup. (Alternatives: iPAQ HQ (sticky!), AximSite, PPC Magazine, PPCT (frontpage!), BrightHand, PocketMatrix)

Reducing Internet bandwidth usage on the Pocket PC - A complete roundup & comparison of Toonel, OnSpeed, Skweezer, WebWarper and the like (Alternatives:iPAQ HQ, AximSite, PPC Magazine, FirstLoox, BrightHand)

Menneisyys · 09-12-05, 09:28 AM

Over at PPCT, I've been asked about the Pocket PC compatibility of JavaFIBS, a free Java client of the backgammon server FIBS.

My answer, summarized in a few words: the ability of displaying top-level (that is, not in-line, unlike (java.awt.Applet) applets) frames is painfully lacking from both Pocket Internet Explorer plug-ins and Thunderhawk. Therefore, they won't be able to run any applets that open top-level, individual frames.

There're very few applets like this, fortunately; maybe this is why for example Thunderhawk doesn't support opening system-level, independent (top-level) frames.

As our discussion continues a lot of other, interesting stuff as well, I copy it here in its entirety:

Originally Posted by AlmostDecent

Hi,

Many thanks for your info on Java. I have an Axim X50v, and was wondering whether you thought I might be able to run JavaFIBS (http://www.fibs.com/~cthulhu/) a client to play at the free online backgammon server FIBS. FIBS (First Internet Backgammon Server) is a wonderful place to play backgammon online, but as far as I know there are no Pocket apps to do so. Or any other site for that matter. There are many client softwares, and interestngly enough, this one is the best and is entirely in Java, hence my hope I may get it to run in VGA (using ozVGA if necessary) on the Dell.

I have some bad news for you.

The stand-alone application, JavaFIBS 2001 (version 1.008) , can't be used at all in current JVM's:

J9 PPR10: can't be hacked - after providing a pre-1.5 it the javax.swing and javax.accessibility package, it complains of a missing java.awt.Window method. As this class, therefore, should also be changed (which is impossible with the IBM J9 VM's - see my comments on its hackability), this JVM is not hackable.

(I used the script 255#"\Program Files\J9\PPRO10\bin\J9.exe" "-jcl:ppro10" -cp \swing.jar;\jfibs\JavaFIBS.jar JavaFIBS2001 to try to run the game, after copying the entire directory structure to the PDA. Here, I've put the missing Swing and javax.accessibility classes in the additional \swing.jar.)

CrEme 4.00b8: after some serious hacking (uploading javax.swing, javax.accessibility, java.awt.DefaultKeyboardFocusManager, java.awt.KeyboardFocusManager java.awt.KeyEventDispatcher, java.awt.KeyEventPostProcessor and overwriting java.lang.Boolean in VMclasses.zip), I coulnd't help the missing java.lang.Class.desiredAssertionStatus() because java.lang.Class is too deeply tied to the hardware and, therefore, can't be changed to a desktop version.

(I used the script 255#"\Windows\CrEme\bin\CrEme.exe" -Ob -classpath \swing.jar;\jfibs\JavaFIBS.jar JavaFIBS2001 . See the J9 section on the additional \swing.jar.)

Note that I haven't tested Insignia Jbed because they have no trial version. It may be able to run it - or not. (Sorry Insignia, you should provide a trial version of jBed - no trial version, no recommendations because I can't even test your stuff...)

The applet version is a no-go either:

CrEme 4.00b8 plug-in + PIE: no-go. Doesn't display any frames; they aren't visible in a task switcher either (unlike with Netfront). Using a multi-tab PIE plug-in like SPP or MultiIE doesn't help either - they only allow for multi-tabbed Web page viewing, but don't do the same with top-level frames.

CrEme 4.00b8 in standalone, AppletViewer mode: no-go.

(the script to start: 255#"\Windows\CrEme\bin\CrEme.exe" -av -Ob http://www.fibs.com/~cthulhu/javafibs.html)

It starts, but as with CrEme in general, has an inconsistent, non-standard GUI. This also means there is no menubar in any Frames - that is, you can't even connect to the server because this is only accessible from the menu. Unfortunately, this renders CrEme useless for running applets like this. A screenshot:

Thunderhawk 2.1: no-go: it doesn't display top-level Frames, just like PIE.

NF 3.2: a no-go because it can't connect to the server (User/JavaFIBS/Connect). I may try some day to find out why it doesn't connect (if we're lucky, it's just an easily fixable security problem); now, it seems to be absolutely useless.

As can be seen on the screenshots, the game's GUI is useless in QVGA because it uses fixed-sized Frames. Only the two on the left will be visible.

This also affects the native VGA portrait mode by default (fortunately, the frames can be moved around):

in Landscape, the window at the bottom right will be visible.

Note that the upper two frames (Chat and System) will always have hidden and they can't be moved back. Also note that you must use some kind of task switcher to switch between the frames. Another note: the menu bars will not be visible in neither NetFront and, as has already been pointed out, in the AppletViewer mode of CrEme; they can only be accessed from the Menu menu in the bottom left corner with NetFront and absolutely unaccessible from CrEme.

This all means it's only with Netfront that it may run some day (that is, when I find out the cause for the error). As the Netfront JVM has no error log/console (AFAIK), it's very hard to find out exactly what causes the network connection problem (that is, it, seemingly, it doesn't even try to connect).

**Rishad** · 09-12-05, 05:46 PM

Thanks. that was very informative. I'm using NetFront 3.2 myself and even though there are some limitations, I like it better than any other browser I have tried.

joedoe101 · 09-12-05, 05:49 PM

So will runescape work with this?

Menneisyys · 09-13-05, 05:10 AM

Originally Posted by joedoe101

So will runescape work with this?

Tested with the unsigned applet version:

NF 3.2: nope

Will also test other JVM's when I have some free time.

09-17-05, 01:01 PM

If anyone can confirm Runescape will work with any of these Javas I will jump on it. I would be able to play more if I had it available on my X50v! Please advise us fellow gammers...

Also, I have been advised here runescape is too advanced in the past, just wondering if anyone has tried and succeeded.

1234com · 04-28-06, 04:32 PM

ok look I have been on a wiled goose chase for a long time will some one just give me a place to downloud the program