A Mango phone (Windows Phone 7.5/Windows Phone OS 7.1) at my hand says "7.10.XXXX" when I executed the following code:
System.Environment.OSVersion.Version.ToString()
I expected "7.1.XXXX".
Why is the minor version number (the second number) "10" (not "1")?
Is there any convention to interpret "10" as "1" ???
I haven't heard of any such convention; To clarify, this is how I understand it:
In consumer/marketing land, Windows Phone Mango is Windows Phone 7.5.
In developer land, the assemblies are Windows Phone 7.1, and more
importantly the SDK is 7.1
In OS Build land, 7.10.7720.68 is Mango
RTM.
Having said that, you can equate 7.10.7720 to Mango / 7.1 / 7.5 - but 7.10.8200 has been spotted in the wild, but unconfirmed whether it's Tango or Mango.
To answer your question: Pretty sure there's no convention to read 10 as 1.
Related
My app contains a multithreaded engine that plays a game which can be compared to chess.
It performs a lot of bitwise operations (shift, and, etc.) on 64-bit words.
On a PC the 64-bit version is much faster than the 32-bit version, and on a recent phone/tablet you would expect the same.
The table below contains some test results (best result is 100, less means slower).
The benchmark consists of adding the numbers 1 through 200 million in parallel. I verified that 4 threads is faster than 2 or 1.
hardware os build threads benchmark search task
----------------------------------------------------------------------
MacBook Windows 64-bit JVM 4 100 100
MacBook Windows CN1 Simulator 4 100 42
iPhone X iOS debug armv7 4 14 2
iPhone X iOS debug arm64 4 14 2
Samsung Tab A 10.1 Android debug 4 8 1
Samsung Tab A 10.1 Android release 4 10 7
Observations:
On the MacBook the search task is performed more than twice as slow in the simulator compared to a normal 64-bit JVM.
Presumably this is because there is no (native) support for the functions Long.bitCount() and Long.numberOfTrailingZeros(),
which I had to replace by (slower) code. Question: is there a way to improve this?
There is no difference between the iPhone X armv7 and arm64 builds. How is this possible? (I tried removing the app and
restarting the phone before installing the arm64 version. The current AppStore version is 32-bit, IIRC.)
The Android release version does a much better job on the search task than the debug version: 7 times faster!
On the Samsung Tab the performance is satisfactory, on the iPhone X I would say it is below par.
Comparing the CPUs (iPhone X: 64-bit 6-core # 2.39 & 1.42 GHz, Samsung Tab A 10.1: 64-bit 8-core # 1.6 GHz)
the iPhone X should not be 3.5 times slower (score 2 vs 7).
To be sure, I looked at the iOS arm64 debug build ipa with the MacOS 'file' command and it says: Mach-0 64-bit executable.
So I am confused: why isn't the arm64 build faster on my iPhone X?
I read somewhere that 'The iPhone X’s processor is more powerful than the newest MacBook Pro' (2017), that can't be right. (My MacBook is 2015 I think.)
BTW, I use one external library, Device, to detect if a device is an iPhone X, and I tried using ios.add_libs=ExternalAccessory.framework.
EDIT
Some more information on the iOS ipa files:
32-bit Main.ipa 7.3 MB file: Mach-0 executable arm
64-bit Main.ipa 7.1 MB file: Mach-0 64-bit executable
On a 2012 iPad 4 only the 32-bit ipa installs. (The search task performance on a scale of 0-100 is 0.4.)
On an iPhone X both the 32-bit and 64-bit ipa's install, but there is no performance difference, which is odd.
The search task performance is 2.0, which is low compared to the Samsung Tab (7.0).
On the MacBook the search task is performed more than twice as slow in
the simulator compared to a normal 64-bit JVM. Presumably this is
because there is no (native) support for the functions Long.bitCount()
and Long.numberOfTrailingZeros(), which I had to replace by (slower)
code. Question: is there a way to improve this?
You can use a native interface and implement the JavaSE portion as the Long.bitCount() or Long.numberOfTrailingZeros(). This will work as fast on the simulator.
Another approach is to implement a Codename One API that does that natively to the important OS's and uses a simulation as a fallback for things you don't support. Then submit a PR to Codename One. You can do that by modifying CodenameOneImplementation.java with the fallback code then updating JavaSEPort.java, AndroidImplementation.java, IOSImplementation.java etc.
You would then expose these APIs somehow to the user which normally we do via Display but in this case might not be the ideal user API venue.
There is no difference between the iPhone X armv7 and arm64 builds.
How is this possible? (I tried removing the app and restarting the
phone before installing the arm64 version. The current AppStore
version is 32-bit, IIRC.)
64 bit is now required by apple so we no longer support building without it.
The Android release version does a much better job on the search task than the debug version: 7 times faster!
These things are hard to tell. It could be the Android JIT which iOS doesn't allow or it could be a piece of code we failed to optimize. We would need to microbenchmark the resulting code to tell.
However, the JavaSE JIT is amazingly fast and will run circles around any native compilation benchmark we throw its way. That's just not something an AoT VM can compete with. We do have other advantages such as more consistent behavior and less hiccups when running.
We're in a pre-release stages of our mobile game, and it's been mostly tested on android devices. As we get closer, we started to run tests on iOS devices and noticed that the same versioning that works great on Android is not working for iOS.
Our version is automatically increased and looks like this: Major.Minor.Commit
We've noticed, that in TestFlight a version 1.0.9 would be higher in the hierarchy than 1.0.10.
In Apple Documentation it is pointed that a version - is a string that consists of up to 3 integers separated by a dot. If it is an integer, how come 9 is higher than 10? I assume that AppStore treat this number as a decimal, but this is not what the documentation suggesting.
The solution we found so far is to use only Major and Minor versions in the version string, and assign an incremented build number, but it's not ideal, as we would like to have similar version strings in both Android and iOS versions of the game.
So far I haven't found a proper explanation to this, and it could be that this is only a display bug in the developer dashboard.
is there a fix for the app store for the Mac OS platform? I create my apps with Firemonkey but it's been a while that I am NOT able to upload my works. There is the warning about the compatibility from apple but still nothing!
From June 1, 2018 the 64 bit version is needed but we are in august and still nothing.
I have seen that David Nottage put a temporary fix to android sdk target. I have tested that because I need android too. It changes some libraries and the manifest. Do I have to do something similar with mac os apps?
Is there any tutorial online?
I have googled a lot but I didnt have success. Maybe it's me that I am weak at googling stuff but nothing.
Per Embarcadero's current roadmap, support for Mac OSX 64bit is planned for RAD Studio 10.3:
Key roadmap themes for 10.3 (and 10.3.x) include macOS 64-bit support, C++17 support, consolidating our debuggers and updating the IDE UI/UX, in addition to FireMonkey z-order support on Android and more.
Note that 10.3 is scheduled to start beta testing soon (invites went out a few days ago), so it will likely be released sometime this Fall. Users with an active Update Subscription have early access to betas for "hotfixes, updates, and major “next” versions". Otherwise, contact Embarcadero to become a beta tester if you can't wait for the final release.
Update: Embarcadero has just released a new roadmap, and clarified their plan regarding OSX 64-bit support:
One roadmap change you may notice compared to the September 2017 roadmap is that we removed macOS 64-bit platform support from the initial 10.3 release.
This doesn’t mean that we don’t think macOS 64-bit is important. We removed it from the 10.3 release to focus on providing more quality and stability for the other key features that are in flight. With that said, our intent is to provide support for macOS 64-bit, including support for targeting the iOS 11 (and iOS 12) simulators, in a follow-on 10.3.x release. We know that developers looking to target the macOS App Store or leverage 64-bit APIs require macOS 64-bit support.
We have a number of customers today who distribute their existing 32-bit applications through their own web store and are currently not impacted by this Apple requirement.
There is no fix at the moment because there is no 64 bit Delphi compiler for Mac OSX. You smply have to hope that Embarcadero release one soon.
I'm trying to write an app for my own use on my iPhone (iOS 6.0). Unfortunately I'm also traveling with my OSX 10.5 laptop with Xcode 3.1.4 loaded. Is there any way to run an app built with this xcode on my iPhone? I don't need any feature from a recent iOS and there are plenty of old apps that run just fine and were probably developed with old Xcode versions, but I always get an amber button indicating the iPhone iOS isn't supported when I hit build and run.
The oldest version of xcode that can develop for iOS 6 is xcode 4.5, and for running xcode 4.5 you need to have MAC OS 10.7.4 or later version
Sorry man, You can't.
You need Xcode4 and Lion for iOS6 development.
EDIT:
Now(2014 AD) Apple doesn't allow any app developed using below Xcode 5, so you need to have Xcode 5.
No. To develop for a modern iPhone, you need an Intel mac, and I doubt that a laptop with 10.5 is an Intel Mac (or that 10.5 even supports x86). Also, Xcode versions are correlated to API versions, if you haven't noticed, so even if possible, you'd probably only be able to use the 3.0 APIs, which are now not even usable because of the multitasking introduced in 4.0.
Short answer: No.
My Application is not running one the old simulators With Blackberry JRE 5,6. The project runs fine on the new simulators with JRE 7 (model 9900, 9810, 9860). The memory size of the application is more than ~6MB.
I tried Cleaning the application in all such ways. In lower simulators the COD file also gets deployed in the simulator, but it doesn't shown in the downloads folder.
What might be the problem.
You say "~6MB". That is pretty close to the maximum app size on older versions of BBOS. You might need to factor your app into multiple cods, to keep the size of the cod groups smaller.
Which BlackBerry JRE did you develop your app in? Please note that BlackBerry apps are not backward compatible, i.e. an app developed in JRE 7.0 will not work below OS 7 as not all APIs used in JRE 7 will be available in the older operating systems. BlackBerry apps are forward compatible and for an app to function on OS 5, 6 and 7, you should develop the application in JRE 5.