Active Topics
-
[ANNOUNCE] MeeShop - new app store (10)
to Applications by aspergerguy - 1 day, 19 hrs ago -
HTTP-401 Sfos-Builder when using /etc/ssu credentials (0)
to SailfishOS by insanelysexy - 3 days, 1 hr ago -
Longtime users: What device(s) are you using today? (54)
to General by ryu1 - 5 days, 6 hrs ago - more...
| The Following 3 Users Say Thank You to texaslabrat For This Useful Post: | ||
 |
|
2009-09-07
, 19:06
|
|
Posts: 1,878 |
Thanked: 646 times |
Joined on Sep 2007
@ San Jose, CA
|
#232
|
Originally Posted by texaslabrat
That's not completely true. If they have the same CPU family (meaning same instruction set architecture/binary-image), and the same executable file format (ELF, DWARF, etc.), then mostly what you really need from there is compatible library layers. That is, as long as no one is doing things like system() calls (ie. stick to QT calls, and things in the libraries you've provided for compatibility, and you're ok).
Each platform needs an architecture-specific compilation done to get an executable.
This has been done, in the past, to get things like BSD based OSes to run Linux and Solaris binaries. All it takes is: same CPU, support for the executable file format, and a set of compatible libraries. And, really, that's what WINE attempts to do (it's not an emulator, it's cross platform library linking, for the MOST part). WINE just doesn't have a full set of libraries and library definitions from which to build up that environment.
Symbian and Maemo don't have that limitation -- each team can easily talk to the other. And the QT team is in that same community. I'm willing to bet that they have more than enough opportunity to develop a full scope of library definitions for providing a complete common executable environment that can run 1 exact binary image on two OSes.
My main question would be: is it
- a Symbian library set (would run on any OMAP+ELF?+Symbian+QT system),
- a Linux library set (would run on any OMAP+ELF?+Linux+QT system),
- a Maemo library set (like the last one, but requires some Maemo specifics),
- pure QT libraries (no Symbian nor Linux/Maemo calls allowed, but would then run on any OMAP+ELF?+QT system), or
- a completely different executable environment (that wouldn't run on a straight Symbian+QT environment, nor a straight Linux/Maemo+QT environment, it would require OMAP+ELF?+QT+this-extra-library)
__________________
My Personal Blog
My Personal Blog
| The Following 3 Users Say Thank You to johnkzin For This Useful Post: | ||
|
|
2009-09-07
, 19:13
|
|
Posts: 271 |
Thanked: 220 times |
Joined on Sep 2009
|
#233
|
Originally Posted by johnkzin
I guess I should have been more specific in my use of the term "platform". In my world, "platform" necessarily implies hardware architecture unless otherwise specified (with the term "environment" referring the the OS/toolset unless otherwise specified). In the case of existing symbian devices (such as the E71) and the N900 (the comparison for which the demonstration was made), these cases would be different platforms even if they were both running the same OS or not, and thus would need a re-compile in order to fully take advantage to the respective cpu instruction sets (is there a performance-hindered, but compatibility-maximized least common denominator for the ARM series like there is in the intel world by compiling to "target=386"?). That was the point I was trying to make in reference to Cap'nCorrupt's questions/musings regarding an emulation layer to make the applications work cross-platform: They will either work because they can run natively (ie identical binary) due to the same platform or compiled to some least-common-denominator platform, or they will need to be recompiled. There is no vm/bytecode equivalent in the QT world as there is in Java, nor is QT a "just-in-time" language like python...and there's no emulation layer that's acting as glue to create the cross-platform capability. QT is basically a macro-ing engine for C++ if you want to get down to brass tacks...with the SDK handling all the "IFDEF" stuff for you behind the scenes. All the other usual restrictions regaring re-compilation remain the same as they would for a C++ application.
That's not completely true. If they have the same CPU family (meaning same instruction set architecture/binary-image), and the same executable file format (ELF, DWARF, etc.), then mostly what you really need from there is compatible library layers. That is, as long as no one is doing things like system() calls (ie. stick to QT calls, and things in the libraries you've provided for compatibility, and you're ok).
Last edited by texaslabrat; 2009-09-07 at 19:51.
|
|
2009-09-07
, 19:30
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#234
|
Originally Posted by johnkzin
You'd have to stick to a lowest common denominator (which can be really low, depending on how old Symbian/ARM sets do you want to support) and at that point it's not that attractive anymore (as you loose all the fancy extensions which actually constitute a large part of the improvements).
That's not completely true. If they have the same CPU family (meaning same instruction set architecture/binary-image), and the same executable file format (ELF, DWARF, etc.), then mostly what you really need from there is compatible library layers. That is, as long as no one is doing things like system() calls (ie. stick to QT calls, and things in the libraries you've provided for compatibility, and you're ok).
| The Following 2 Users Say Thank You to attila77 For This Useful Post: | ||
|
|
2009-09-07
, 19:41
|
|
Posts: 1,878 |
Thanked: 646 times |
Joined on Sep 2007
@ San Jose, CA
|
#235
|
Originally Posted by attila77
Right. For the devices given, we're talking about ARMv6 (N97 and E71) vs ARMv7 (N900) instruction sets, right? Hopefully the set of common instructions/features between ARMv6 and ARMv7 isn't too restrictive.
You'd have to stick to a lowest common denominator (which can be really low, depending on how old Symbian/ARM sets do you want to support) and at that point it's not that attractive anymore (as you loose all the fancy extensions which actually constitute a large part of the improvements).
Same with the Symbian in use -- I'd bet it's rather recent. And, while I've never done low level Symbian coding (nor high level, for that matter), it's my understanding that it does a good job of abstracting away specific hardware (peripherals and peripheral configurations, and such), just like *nix platforms tend to do. So, a difference in peripheral modules probably wouldn't keep you from running the same application.
__________________
My Personal Blog
My Personal Blog
|
|
2009-09-07
, 20:20
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#236
|
Originally Posted by johnkzin
Well, kind of. The problem is that ARM is not as incremental as x86 is (in order to provide minimum silicon that can do the job), so in each generation you have several processors with different feature sets, with a basic common functionality. Even if you restrict yourself to ARMv6 in general, you have to drop VFP, Thumb2 and whatnot as not all ARMv6-es have them (not to mention you're compiling for the wrong pipeline and cache sizes). The point is that on mobile devices overhead directly translates to lower battery life, so, unlike x86, you really want the best optimized code in there for that particular unit.
Right. For the devices given, we're talking about ARMv6 (N97 and E71) vs ARMv7 (N900) instruction sets, right? Hopefully the set of common instructions/features between ARMv6 and ARMv7 isn't too restrictive.
| The Following 2 Users Say Thank You to attila77 For This Useful Post: | ||
 |
|
2009-09-08
, 02:15
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#237
|
Haha.. I love this community!
In this day and age, I think that bytecode is the way to go. I feel there's a good performance to portability tradeoff.
Considering a long-term play, android, for example has the advantage of quickly being able to jump to many devices with without sacrificing the app library. Not so for apps that require a re-compile, even if it is simple recompile. For each additional piece of hardware, a new compile must be done for each app in the library. Of course, you can always distribute source, but this has it's own set of consequences.
I think an app layer like QT is good for portability but it is old-school-chic. In the age of bytecode interpreters, and more-than-before cpu options, it makes sense to distribute in a write-once/compile-once, run-anywhere manner.
Oh yeah, and portrait orientation rules!
}:^)~
In this day and age, I think that bytecode is the way to go. I feel there's a good performance to portability tradeoff.
Considering a long-term play, android, for example has the advantage of quickly being able to jump to many devices with without sacrificing the app library. Not so for apps that require a re-compile, even if it is simple recompile. For each additional piece of hardware, a new compile must be done for each app in the library. Of course, you can always distribute source, but this has it's own set of consequences.
I think an app layer like QT is good for portability but it is old-school-chic. In the age of bytecode interpreters, and more-than-before cpu options, it makes sense to distribute in a write-once/compile-once, run-anywhere manner.
Oh yeah, and portrait orientation rules!
}:^)~
| The Following User Says Thank You to Capt'n Corrupt For This Useful Post: | ||
|
|
2009-09-08
, 02:27
|
|
Posts: 1,878 |
Thanked: 646 times |
Joined on Sep 2007
@ San Jose, CA
|
#238
|
Originally Posted by Capt'n Corrupt
It depends on how performance intensive the app is.
Haha.. I love this community!
In this day and age, I think that bytecode is the way to go. I feel there's a good performance to portability tradeoff.
The good news for byte code is: it's portable to every platform that has the interpreter. And as time moves forward, and CPU's upgrade, it not only retains that application ecosystem, it gets faster at running those apps.
The bad news is: native will always do better. Handheld games that really push the envelope of a given platform will always do better than a bytecode version of the game. You can somewhat mitigate that by doing JIT compiling (or "compile to native at install time"), but not everything with JIT, or bytecode-to-native, does as well as something written to native APIs.
I don't think either strategy will eliminate the other. The best would be a platform that gives developers the ability to pick between bytecode apps, native apps, and hybrid apps. (Android, as far as I recall, only gives you "bytecode" and "hybrid" options, where hybrid means "mostly bytecode, but with some API's to call out optimized native code for some parts of the app)
In that regard, I think Maemo is much better positioned than iPhone-OS-X or Android. The possibility to get a JVM on it is there. The possibility to get Dalvik on it is here (and I wish someone would do both of those). And you've definitely got the ability to do fully native code. I don't see Dalvik for iPhone coming out, nor full JVM for Android (nor a fully native environment for Android) coming out.
__________________
My Personal Blog
My Personal Blog
| The Following User Says Thank You to johnkzin For This Useful Post: | ||
 |
|
2009-09-08
, 04:25
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#239
|
Do you realize post #225 was the last on-topic in this thread?
The discussion about Qt portability is *very* interesting but don't expect anybody finding it under a thread about portrait mode in Maemo 5.
Can you please continue in a new thread? And can admin please move all these posts there? Thank you!
The discussion about Qt portability is *very* interesting but don't expect anybody finding it under a thread about portrait mode in Maemo 5.
Can you please continue in a new thread? And can admin please move all these posts there? Thank you!
| The Following 3 Users Say Thank You to qgil For This Useful Post: | ||
|
|
2009-09-08
, 11:04
|
|
Posts: 75 |
Thanked: 11 times |
Joined on Feb 2008
@ Bay area, CA // Kampala, Uganda
|
#240
|
Yeah, not to go back on topic or anything...
Anyway, I know this has been said ad nauseum, but just want to remark that I, too, consider a near-universal portrait mode a must. Android -- even from the outset -- did that rather well. But it lacked a text entry mode for portrait, which was really irritating. Sure you could turn it and flip out the keyboard and use two hands -- no doubt about it, that's really easy to do. But It's also pretty easy to reach into your bag and get out your laptop -- but for all of us here, the convenience (and inconveniences) of an N8x0 are worth not having to do that. Especially for a device intended to reach a broader audience -- people who aren't willing to inconvenience themselves for the benefit of their devices -- that's an unacceptable limitation.
At least the iPhone only allows landscape where it has a landscape keyboard. It never fools you by allowing landscape and then not having a way to enter text. I think if the N900 does this, it will be a big mistake. I suppose, then, from the outside, until there's an OSK, only applications that will seldom or never take text input should be portrait enabled, like the media player, phone dialer, etc. And, frankly, that's a shame.
$800+ US ought to buy a whole lot of convenience for the user (especially since nowadays many other higher end smartphones can be readily acquired, albeit not necessarily new, but sans contract obligations for $500 or substantially less).
Anyway, I know this has been said ad nauseum, but just want to remark that I, too, consider a near-universal portrait mode a must. Android -- even from the outset -- did that rather well. But it lacked a text entry mode for portrait, which was really irritating. Sure you could turn it and flip out the keyboard and use two hands -- no doubt about it, that's really easy to do. But It's also pretty easy to reach into your bag and get out your laptop -- but for all of us here, the convenience (and inconveniences) of an N8x0 are worth not having to do that. Especially for a device intended to reach a broader audience -- people who aren't willing to inconvenience themselves for the benefit of their devices -- that's an unacceptable limitation.
At least the iPhone only allows landscape where it has a landscape keyboard. It never fools you by allowing landscape and then not having a way to enter text. I think if the N900 does this, it will be a big mistake. I suppose, then, from the outside, until there's an OSK, only applications that will seldom or never take text input should be portrait enabled, like the media player, phone dialer, etc. And, frankly, that's a shame.
$800+ US ought to buy a whole lot of convenience for the user (especially since nowadays many other higher end smartphones can be readily acquired, albeit not necessarily new, but sans contract obligations for $500 or substantially less).
 |
| Tags |
| display, fremantle, landscape, maemo, maemo 5, orientation, portrait, portrait v. landscape war, use-case |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 14:39.
In this way, it's similar, yet different from Java. Java bills itself as "write once, run anywhere" when it is more aptly labeled "COMPILE once, run anywhere" due to the production of platform independent bytecode and the presence of platform-specific virtual machines on each target. QT, on the other hand, is more strictly "write once, run anywhere" since you write the code once, but then you compile it for your targets.
Last edited by texaslabrat; 2009-09-07 at 18:45.