Does Delphi support ARMv5 and ARMv6 CPU's and is there a way to make my app work on them?
The answer is no because Delphi compiles native code targeted at a specific CPU, in this case ARMv7 with NEON support.
David I posted this on the subject:
Brian Long gives additional Android requirements in his blog post at
http://blog.blong.com/2013/09/delphi-for-android-aka-delphi-xe5-aka.html?showComment=1378942045563&m=1
Here is what he lists from our Documentation:
Android requirements
Because the Delphi compiler generates native machine instructions, its
output is processor-specific. In other words it doesn’t target the
Dalvik Virtual Machine, where regular Android applications reside,
which are basically Java p-code applications that are executed by a
variant of the Java VM. Instead it generates raw machine code, as all
the current wave of Delphi compilers do (the long gone Delphi for .NET
was the exception to this general rule). So because it’ a compiler
compiling native machine instructions Delphi’s Android support has the
following requirements:
there must be a GPU
the CPU must be ARMv7 with NEON instruction support
the OS on the target device must be one of: GingerBread: Android
2.3.3+ (MR1 or later), which is API level 10 Ice Cream Sandwich: Android 4.0.3+ (MR1 or later), which is API level 15 Jelly Bean:
Android 4.1+ (release, MR1, MR2 or later), which are API levels 16, 17
and 18
Embarcadero clearly states in their manual what is supported.
As far as I know (and what embarcadero tells on the RAD studio road shows), for Android at least ARM v7 with NEON support is required.
Edit: The (German) data sheet states "Android-Smartphones und –Tablet-Computer: ARMv7-Geräte mit NEON-Unterstützung," on the bottom of the last page.
Related
I use TOSVersion.ToString function (uses SysUtils) to detect Windows version. However this is what I get in Windows11:
Windows 10 (Version 10.0, Build 21996, 64-bit Edition)
Is there any reliable way to detect Windows 11? I'm using Delphi 10.3.3.
UPDATE: Windows 11 is officially released and I tried again.
Here is what I get:
Windows 10 (Version 10.0, Build 22000, 64-bit Edition)
As Remy pointed out: using the WinAPI you risk of being in some compatibility mode, resulting in getting a version reported that is lower than the actual.
One alternative is to check the file version of expected files, i.e.
%windir%\system32\ntoskrnl.exe or
%windir%\explorer.exe
using GetFileVersionInfo() and VerQueryValue() - the HiWord(dwFileVersionLS)
should be 22000 or higher (according to Windows NT build/release number).
Another is to look in the Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ at the text values CurrentBuild and CurrentBuildNumber, checking if the highest of both is 22000 or higher.
David already wrote a detailled answer in Checking Windows version on W10 with even more alternatives, although concentrating on the high/low version numbers, not the build. But WMI might help.
(This only works in retrospective with confirmed knowledge.) Check which API exports are available: the idea is that specific functions were introduced with specific Windows releases/versions, so if importing fails for one you know you're on a version below. An outdated example and an outdated list of minimum versions per function will give you an idea. Now you "only" have to find out which new functions are introduced with Windows 11.
Those are all not bulletproof, but you could combine them and then draw conclusions. And after all that you can still try your approach to parse texts instead of relying on numbers only. It also shows how easily you can manipulate your system into reporting different versions as per which method is used.
Official major version number for Windows 11 is 10.
The official build number for the public preview of Windows 11 is
10.0.22000.168
Earlier builds:
10.0.22000.71
10.0.22000.65
10.0.22000.51
Microsoft Windows 11 FAQ
If you want to detect Preview versions, earliest build number was 10.0.22000.51 Windows 11 version history
TOSVersion relies on some hard coded names and logic to return OS name. You will have to implement your own detection, copy and modify TOSVersion record or make wrapper around it, where you can use existing logic for older versions and implement check based on Windows 11 build number to detect Windows 11.
For other general issues and approaches in detecting OS version you can refer to AmigoJack's answer
Except the very weak, atleast for me, solution of considering Windows 10 builds greater than 22000, such as Windows 11, the only solution I found which is actually working is the WMIs Win32_OperatingSystem class - Caption property.
On my dev Win10 machine, it gives the following string: Microsoft Windows 10 Pro.
On my another dev machine, with Win11 installed, the same function gives: Microsoft Windows 11 Pro.
The difference is in string values - "10" vs "11"- but this is at least something far better than the "build greater than" solution.
C# and C++ work well.
The simplest way is to get the version of Kernel32.dll and if Major Version is 10 and Build Version is >= 22000 then you have Windows 11.
See my code here: How can I find the Windows product name in Windows 11?
I would like to add Direct3D as an optional graphics backend of a 2D game to get around DirectDraw's limitations (such as the horrid DirectDraw emulation in Windows 8).
Can I do this in such a way that the majority of users would not need to install anything? I noticed that Windows XP comes with some Direct3D files, can I target that version of the runtime?
According to John McCaskey, a software engineer on Steam:
Games which don't use the D3DX helpers (such as Source engine games) don't require running the annoying installer on first launch as they only depend on major d3d9/10/11 versions being installed. However, games that do use D3DX must run it as it's the only way Microsoft has allowed for distributing and checking the version info on the files.
Thus, using Direct3D 9 (d3d9.h) directly should be fine, assuming the user has some version of DirectX 9 installed.
Source: Why Steam Makes You Reinstall DirectX - Rock, Paper, Shotgun
Obviously, one needs a PC with a copy of Delphi XE2. But, do you need a Mac or iPad? Mac OSX running in a virtual machine? ... Can you create and compile the application entirely on a PC?
You require a Windows PC (32 or 64 bit, running Vista or 7 - though XP has limited support) to use Delphi XE2's IDE and compiler. These simply will not work on any other platform, so you can only develop on a Windows PC!
With only a Windows 32 (or 64) bit PC, you can build Win32, Win64 and OSX applications.
To test/run 64bit Windows applications you require a 64bit system with a 64bit edition of Windows installed.
To test/run OSX Applications, a Mac system running 10.6 (Snow Leopard) or 10.7 (Lion) is required. A "Hackintosh" or VM running MacOSX will not work (and is a violation of Apple's EULA)!
To produce iOS Applications, you require the same criteria as stated above for testing OSX applications, with the additional requirement of installing the FireMonkey iOS package (containing the FreePascal compiler and FireMonkey libraries), XCode, and the iOS emulator.
The iOS Emulator will run Delphi-made iOS applications, though of course testing on the physical device is often considered better.
You can create and compile the entiry application on a PC.
You need OS X version 10.6 or 10.7 to test it on a MAC: Prerequisites
Watch Andreano Lanusse video
Found with Google: Mac in a VM
a bit late, but the question still stands (me at least, I'm researching the subject)
regarding the virtualization part of the mac, which is dismissed by everybody above, and how that is not possible to be used instead of a physical mac (same for the open-gl FM related comment above), I'd quote XE5 official documentation:
"All FireMonkey applications require a graphics processing unit (GPU) on both the target platform and the development system. The GPU can be accessible either directly or through virtualization" (http://docwiki.embarcadero.com/RADStudio/XE5/en/FireMonkey_Platform_Prerequisites)
Take note that this is not XE5 requirement, it will work as well with XE2, because having the GPU accessible to the VM basically means giving the VM direct control to it (in case of vmware, through passthrough aka VMDirectPath I/O, although in this aprticular case there are limitations). XEN, on the other hand, it said to do very nicely with GPU passthrough.
I've been using this method for a lot of other, non delphi-iOS related, activities that also require access to a physical GPU, and they all work just nice (the "how nice" depends on the chosen hardware so care must be taken there, of course).
so the short answers are: no, yes, yes.
as others said, it is advisable to test your applications on the actual target systems, so at one point you may want to consider purchasing some 2nd hand device for the job.
There seems to be a lot of confusion regarding deploying Adobe Air apps to ios after the restrictions were lifted. Before apple lifted the restrictions you had to go through the process documented here: http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html using the Packager for iPhone. But now that the restrictions have been lifted and the Air 2.7 update we can use the same ADT tool in the flex SDK that we use with all air applications.
My understanding is that the old Packager for iPhone (PFI) some how converted actionscript code into native objective C in order to be accepted by apple.
If that is correct does the restrictions being lifted mean that the ADT tool is not converting to objective C and is only bundling the AS3 .swf and air player together when creating the .ipa app file?
What exactly changed in the Air deployment process after apple lifted its restrictions?
If anyone could point me to some documentation on how the .ipa file is being created behind the scenes I think this would really clear some confusion.
Thanks for the help
Nothing really changed; apple just lifted the ban. The ban wasn't just on flash-created apps, it was on any tool that created any kind of intermediary language or used a virtual machine, etc. What the PFI does: it actually uses the LLVM compiler to statically compile actionscript 3 BYTECODE (not AS3 source) into native ARM assembly. So essentially when you're deploying an IPA it's the same idea as publishing a SWF to an exe (as in the publish settings) in the sense that both your SWF application and the flash virtual machine are bundled together, except instead of being an exe where the code inside is x86 ASM with AS3 bytecode executed along the VM, it's ARM. The PFI and all its classes were simply merged into the ADT tool. The PFI contained a LLVM dll which is accessed through various LLVM java classes that were added to the internal adobe version of the ASC or actionscript compiler. These LLVM classes and other associated classes, however, are not open source, which adobe is allowed to do, even though the ASC is open source because it's licensed under the MPL or mozilla public license, which permits the use of the open source code in proprietary closed source applications without sharing your changes.
For proof of all that I've told you, just download the new flex SDK that includes the ADT with the PFI merged in and you'll find the LLVM dll's etc. Further, you can decompile the ADT jar and see all the LLVM classes. The LLVM classes ( I believe ) intercept the ASC bytecode through the class GlobalOptimizer, or at least it did back in the day... they've probably changed that. The only other thing that has changed is that apparently Adobe has optimized the PFI (now merged into ADT) quite a lot. More info here:
http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html
http://www.leebrimelow.com/?p=2754
Update
Here is an official Adobe article confirming the things I've told you:
http://www.adobe.com/devnet/logged_in/abansod_iphone.html. I also should clarify that I've really over-simplified the process behind the scenes and appear to me mistaken in one of my points. I guess somehow the PFI actually merges the AS3 bytecode and the VM into a single seamless executable that doesn't use JIT compilation, and thus would technically not be a virtual machine? Not sure on that point, but the above article does seem to imply this:
"When you build your application for iOS, there is no interpreted code and no runtime in your final binary. Your application is truly a native iOS app."
Is there a Cross Platform ( Win32 / Win64 / Linux32 / Linux64 / MacOSX Snow Leopard ) Commercial Development Tool / IDE / Programming Language ?
( No Java / .Net , only NATIVE )
From the answers i'am understandig ( my understanding) there is not any single Comercial Tool/IDE/Programing language ( combined all toggether ) for native cross platform development ( platforms in the question ) !!!
And I 'am asking for a Comercial product , having in mind the "quality" of the microsoft visual studio or the RAD Studio ( delphi . c++ ).
I looked at Freepascal/Lazarus but it give not the impresion of a "full quality product" ( sorry guys , nice but way way far from Delphi or VS , any way keep the good work )
.
Thank you all for the interest , I will keep searching , any new information will be helpfull.
And I like to apologise for my english ( not native !! to me , learned what i know by my self).
Sebastian.
Embarcadero (the current owner of Delphi) has promised a cross-platform version (win32. Mac, Linux) in the near future... Check the Delphi road map (by product manager Michale Rozlog) on their developer web site (dn.codegear.com) for more details.
It will be a native compiler for each platform, according to the current, limited, information available.
What exactly do you need? A Tool or a IDE or a Language? Why it has to be commercial?
You tagged this Question with "delphi", so I expect you looking for a cross patform IDE/Compiler.
For what I know, the only native cross platform compiler is FreePascal, you can use the Delphi 7-Like IDE Lazarus with that compiler. But both aren't commercial, but opensource.
In a few Months (nobody knows exactly when) there will be a new cross platform Delphi.
Embarcadero Delphi XE2 is now in beta test, native support for MacOS and 64 Bit is included, support for Linux is announced - see http://www.embarcadero.com/products/delphi/64-bit
and What should be tested in 64-bit Delphi
Another (commercial but inexpensive) toolkit is wxForms for Delphi, based on wxWidgets:
"wxForms for Delphi is an integrated
form designer plugin for CodeGear
Delphi that helps you to create cross
platform applications for Windows Mac
OSX and Linux using single source
base.
wxForms code from Delphi can be
compiled in Mac OSX and Linux without
much change using FreePascal/Lazarus."
http://www.twinforms.com/products/wxformsdelphi/index.php
Have a look at Qt library recently bought by Nokia. You can use it in C++ but there are bindings in many languages for example this is the python binding.
You can choose from three different type of licenses (commercial, LGPL or GPL)
There's also wxWidgets and the UI designer tool DialogBlocks.
There's also CodeBlocks for C++ only. And if you add multiples plugins you can consider vim and emacs. With the latter two you can use any development language.
While it's not free and I haven't used it in awhile, Metrowerks Codewarrior used to be cross platform, not sure if it is still around or not though.
Qt + Qt Creator + GCC (or perhaps some other compiler on Windows, such as the MS Visual Studio Express Edition compiler). Qt provides great support for building cross-platform GUI applications, Qt Creator provides a uniform IDE, and then you just need the appropriate compiler for your platform.
Qt Creator is open source, and Qt is available in both open source and commercially-licensed versions (although the open source version is suitable for commercial development these days due to its use of the LGPL).
CodeTyphon is a powerful one click installation package for cross platform native development. It already supports 4 CPU/OS hosts (Win32, Win64, Linux32, Linux64), and 16 CPU/OS targets (arm-Wince, arm-Linux, arm-Embedded, arm-gba, arm-nds, i386-Win32, i386-Linux, i386-FreeBSD, i386-Haiku, x86_64-Win64, x86_64-Linux, x86_64-FreeBSD, powerpc-Linux, powerpc64-Linux, sparc-Linux, sparc-Solaris). More are supported in Lazarus/FreePascal, but others are not yet integrated in CodeTyphon. Did I mention that it is free?
One code to rule them all ;-)