With the intention of normalizing behavior across various browser O/S levels, Intel offers the Crosswalk HTML5 "runtime".
Adobe offers an option where the AIR runtime is bundled up or embedded as part of the mobile app deployment package.
How large are these two runtimes?
Related
Is there any browser for windows or linux that still using actual webkit engine version not blink engine?
This is a question that I also ask, periodically, so I can give an updated reply:
for Linux, there are several more-or-less platform-specific browsers that use webkit2-gtk (a more-or-less up-to-date WebKit2 implementation): notably Web/Epiphany and Midori. Both are rather simple/lightweight browsers.
for MS Windows, there is still the more full-fledged Maxthon 5 browser (or virus, according to some), but I have been unable to determine what WebKit version it really uses (based on its user agent string it might NOT be WebKit2). Some quick testing suggests it's a good alternative for slower hardware (many hybrid tablet PCs!) as WebKit is noticeably less resource-hungry than WebEngine (aka Chromium aka Blink). Note however that Maxthon 6 will become just another blink on the block (unless they decide to keep the dual-engine feature).
for Linux AND MS Windows (Qt-based, cross platform) there are Konqueror and Otter-Browser. The former is mostly focussed on its QtWebEngine backend, but the latter is indeed focussed on the "rebooted" QtWebKit (and aims to reimplement Opera 12; it provides installers for MS Windows).
The QtWebKit reboot is largely a 1-person effort at the moment that could probably stand a few more contributors, notably to merge a more recent WebKit version.
according to wikipedia, maxthon browser still uses webkit (You can switch engines in Maxthon though)
As of version 3, Maxthon supports two web browser engines: WebKit and
Trident
Wikipedia
I'm soon going to release an app for Windows Phone 8.1, using Nokia's imaging SDK. However, the Nokia Imaging SDK does not support the Any CPU target platform, so I have to choose between building towards x86 (for the emulator) or ARM (for my phone).
Is it safe to only upload an ARM build to the marketplace or might I lock out some users that way?
As far as my knowledge goes, it's perfectly safe to upload ARM-only packages.
Question 1
If I want to build an application with OpenCL support, do I have any guarantees that the OpenCL.lib implementation from my vendor is able to work with all devices from other Vendors? If yes what's the difference between the implementation?
Question 2
Is it possible to use different OpenCL versions in the same application? For example AMD has released a preview driver for OpenCL 2.0 support. On the other hand the lovely company called Nvidia is still trying to ignore everything past OpenCL 1.1. It would be nice if I could write platform specific code in different versions.
1: On Windows, OpenCL.lib is a static wrapper around OpenCL.dll, which is the ICD loader, and exposes all of the available platforms. It is provided by Khronos and redistributed by the OpenCL platform vendors. So go ahead and link to it; it will work with whatever is installed (although if nothing is installed your application won't run because it can't find OpenCL.dll; this is solved other ways).
2: Yes. As long as the ICD loader is the latest, you can get at the newer API on newer platforms / devices. Just don't use new API on old devices; that will crash or worse.
When I create a new OS X application project, I noticed many target options those confuse me quite a lot:
(1) The top-left setting of Xcode window:
(2) The "Base SDK":
(3) "Deployment Target":
(4) Architectures:
Here comes my questions:
For (2) and (3), I think it was clearer to understand. These are what I comprehend:
(2) This identifies what I develop with.
(3) This identifies what OS version my application will be used on.
Please tell me whether I am right...
But I could not understand (1). I just know that if I select 32-bit here, I could not use ARC.
Neither with (4), what are they? Are they represent the bit-width of the CPU? What was the difference between (1) and (4)?
I'll explain your items out of order.
The Base SDK
This defines the largest set of APIs you can use. You can use anything that existed as of the version number identified here. For example, if you use the 10.8 SDK, you can use -[NSColor CGColor] (introduced in 10.8), but not -[NSData base64EncodedDataWithOptions:] (first public in 10.9).
(Of course, you can also use anything older than that version.)
Accordingly, the SDK version is also known as the “max[imum] allowed” version in the Availability macros.
The SDK version also sometimes becomes important when Apple changes the behavior of an API. When they do that, they sometimes keep the old behavior around for applications linked with older SDKs. This is called an “on-or-after check”, as in “checks whether you're on 10.8 [SDK] or later”. (The concept and term pre-date Xcode having SDKs for each OS version. It used to just go by whatever OS you were running Xcode and building on.)
The Deployment Target
This is the minimum OS version you require. If something was removed in a prior version (rare, but it happens), you can't use it.
This tends to affect link-time and run-time things more than compile-time things. For example, ARC won't work if your deployment target is 10.5 or earlier.
Accordingly, the Deployment Target is also known as the “min[imum] required” version in the Availability macros.
The Info.plist can also specify a minimum OS version. Nowadays, this is set by default and it's set by macro expansion to the Deployment Target.
The Architectures build setting
Different CPUs have different architectures. Essentially, they fit into broad categories, such as:
PowerPC 32-bit (ppc)
PowerPC 64-bit (ppc64)
Intel 32-bit (i386)
Intel 64-bit (x86_64)
ARM 32-bit
ARM 64-bit
(PowerPC architectures aren't supported anymore. You can add them to the Architectures list, as ppc and ppc64, but Xcode will just ignore them.)
Macs nowadays have Intel processors. Almost all Intel Macs have 64-bit processors. You only need to worry about 32-bit Intel if you want to support Macs all the way back to 2006. That's probably more hassle than it's worth.
iOS devices run ARM processors, and most are still 32-bit. The A7 (iPhone 5S, iPad Air, iPad Mini with Retina Display) is 64-bit. But, if you run on an iOS Simulator, it's running on your Mac (it's a Simulator, not an emulator), so it'll target an Intel architecture (formerly always i386, but probably can now be x86_64 if needed).
The “top-left setting of Xcode window”
This is the build scheme and run destination. (Yes, it's two separate things in one pop-up menu. Actually, it's two separate pop-up menus in one control. Try it.)
“My Mac 64-bit” is the run destination. You'll be running the 64-bit version of your app on your Mac, not in an iOS Simulator or on an iOS device. Your choice for a Mac app is merely which architecture you want to run, and they should behave the same (this is, obviously, something you sometimes need to test).
iOS apps have more choices here. Some apps are iPhone-only, some are iPad-only, some are universal, and some may be set to build for both 32-bit and 64-bit architectures. You'll have a Simulator offered for each combination of form factor and architecture (e.g., iPhone Simulator 64-bit) you can run on. You'll also have the option to run your app on any iOS device that's connected and enabled for development (you get this prompt when you plug in the device in Xcode's sight).
TL;DR
Deployment Target is the lowest OS version your app will run on.
Base SDK is the highest OS version you can use stuff from. If it didn't exist yet, it doesn't exist at all for you.
Architectures are the set of hardware your app will run on.
Run Destination is the hardware you're going to run it on from within Xcode.
Just like with most OSes these days you can develop either a 32bit or a 64bit application. The "bitness" refers mostly to how memory addresses are structured (either using 32bit allowing so at most 4GB to address or 64bit (computation left as an exercise to the reader)). However the choosen architecture usually has more implications (like the missing ARC support for 32bit apps) but also how wide CPU registers are, how much memory a structure uses in RAM etc.
OS X also supports socalled fat binaryies that is, a bundle containing both 32bit and 64bit variants of your application. This is however only needed if you normally prefer to run 64bit code, but want your app also to run on OS versions that only support 32bit.
In XCode you can define for what architecture to build your project, either 32bit only, 64bit only or a fat bundle. In the project settings you can set what is allowed and in the top bar in XCode you can quickly switch between the allowed architectures (your questions 1 and 4).
The base SDK determines what you want to use to compile your application. If you select for instance 10.7 you cannot use new APIs that were introduced in 10.8 or 10.9 (which might perfectly be ok if you want your application to run on earlier OS versions only). However if you want to dynamically use new features if they are availble you'd select the latest OS as base SDK and check in code what OS you are running on and only use new features if they are available. It is totally ok to compile an application with access to new features and run it on older systems if you don't use the new APIs there (they are late-bound and hence only crash when you access them the first time and they are not available).
The deployment target determines the minimum OS version your application needs to run properly. This is a runtime check done when the application is started. The OS will refuse to start an application that is made for a later version.
I've noticed that all betas for Dropbox are released simultaneously for Windows, Mac and Linux. How do they do that? Anyone knows which platform they're using? I'm aware that there are many native -very impressive, actually- functions in each of the platform clients, but they seem to release critical bug fixes efortlessly for all platforms.
So any idea of which GUI platform they're using?
The Linux version includes files such as wx._windows_.so, libwx_gtk2*.so, etc. (I haven't checked the others), so I suspect Dropbox uses wxWidgets.
Qt is a popular cross-platform application and GUI framework with native look-and-feel.
I don't know what Dropbox uses for all its supported platforms, but it looks like its linux client uses at least Gtk: Dropbox linux System Requirements.