Thought stackers might be interested in this video.
http://www.boygeniusreport.com/2008/...irefox-mobile/... 3rd Party BlackBerry Software forum
Mozilla concept video for Firefox Mobile
This one is only for touchscreen phones though...
I wanna see how it would work on a BB.
I have a BlackBerry and a WhiteApple. :)
~via BB (wap.pinstack.com)~
Yeah! But if its for a touchscreen...
It's progress though. I know we have a Mozilla petition floating around this forum somewhere (which I signed). Like I said, it's progress.
~via BB (wap.pinstack.com)~
Firefox would indeed dominate the world of mobile devices, if released! It has already aquired quite a board of users on the pc and mac side, all they need to do is move themselfa into the world of mobile browsing!
I doubt anyone from the Mozilla Foundation/Corporation would port Firefox to the BlackBerry architecture, regardless of the size of the petition.
Why? The Gecko layout engine is written in C++, as are all of the popular layout engines (WebKit/KHTML, Presto). Given current publically available BlackBerry development tools, a "port" would be a full rewrite in Java.
I would hate to see the result of applying an automatic translator from C++ to Java
Is that good or bad?
Originally Posted by gkast1
Neutral... It just says that language translation, theoretically a difficult problem, has
not yet being tackled to the point of being able to handle a project of this size.
ok.... Well, I will wait for an update.
Translating code (automatically) from C to Java is difficult because C has significantly lower level behavior than Java. You can manipulate memory in C as any type of data you want. A block of 4 bytes containing "abcd" as characters can just as easily be treated as an integer: 1633837924. Data in C is data, and it is up to the programmer to control how a block of data is used.
Java (and other managed languages) doesn't allow low level access to memory manipulation directly. If you define a 4 byte array containing "abcd", there is no straightforward way to extract the integer value produced above from it.
Further, Java lacks unsigned data types like C does. Allegedly this was for programmer "usability" concerns when the language was designed. Not taking into account signed versus unsigned in a program for almost any program would result in very serious problems. Unsigned arithmetic can be emulated in signed arithmetic, but this typically doubles the amount of work done per addition, or the memory used.
Finally, the treatment of data in C is so type agnostic, that you can create an array with machine code instructions, and directly execute the array as a function. This is how just-in-time compilers work.
But ultimately, when broken down to low level computability theory, any system capable of computing any well formed algorithm can emulate any other system of the same sort. The big question when emulating though, is speed. Sure, it is possible to take the Firefox Mobile source code, compile it to produce some sort of binary, then emulate the architecture on the BlackBerry -- it will just be unusably slow, and memory intensive.
High level C source to Java source code conversion will probably never be possible with sufficient accuracy. Low level system emulation isn't suitable on resource constrained systems, like smart phones. However, fortunately, solutions for this sort of problem don't need to be polar opposites on the spectrum.
Eventually, Firefox Mobile, or something similar (i.e. Gecko based) will be made available for the current BlackBerry architecture. It just won't be coming from the Mozilla Foundation. ;)
Tags for this Thread