I have Delphi XE4 Enterprise. How do I find out if I have FireMonkey or FM2 or FM3?
Where does Embarcadero store the detailed information about FireMonkey versions?
As of today, the list of FireMonkey versions, and associated Delphi versions is:
FM1: Delphi XE2
FM2: Delphi XE3
FM3: Delphi XE4/5
The FireMonkey version is more of a marketing designation than a true software version. Principally it's Delphi itself that is versioned.
It's a little debateable as to what FireMonkey version ships with XE5. Following the pattern, it ought to be FM4. But I can find no reference anywhere to Embarcadero using the name FM4. So I rather suspect that this is what happened (all speculation on my part):
The original release with XE2 was named plain FireMonkey.
The release with XE3 removed iOS support and fixed many deep and fundamental flaws with breaking changes So it was branded FM2.
With XE4, iOS returned and more flaws were fixed, again with breaking changes. The library was reaching stability, and named FM3. They even used FM3 in marketing material. Exponentially better than the original was perhaps the message. Or is that just the mathematician in me? Maybe the marketing people thought it looked cool.
XE5 added Android support and had some more, albeit more minor, breaking changes. Somebody at Embarcadero said, if we keep changing FM version then people will get fed up with all our breaking changes. So let's just call the thing FireMonkey and leave it at that.
Going forward I think you'll just see FireMonkey and FM from Embarcadero. The version that counts is the Delphi version.
The version of the FMX framework depends on the Delphi compiler version you use.
Until now, each Delphi version (starting from XE2) contains a somehow different/extended/changed Firemonkey framework.
BTW Delphi XE4 Firemonkey framework is FM3
Related
There is a code base in delphi 2006 with no development for last many years. If the development needs to be activated what are the options.
Continue developing in 2006. (Not sure of IDE support etc.)
Migrate to Delphi XE2. (Not sure of what it takes)
Recode it in Java.
It seems the second option is more viable but what it would involve to do that? I read some things on Unicode support and also not sure of graphics library support.
Just to put thing in perspective, I am a Java programmer all along with experience on C/C++. However I am trying to understand it more from the perspective of what is the least resistance path to go to market strategy.
Thanks in advance.
I cannot say anything about recoding it in Java. Depending on whatever the code base does, it might be a good option, given that you say you are experienced with Java (and, I assume, not with Delphi).
Regarding Upgrading to Delphi XE2:
Check whether any 3rd party components have been used.
If not, you will probably be able to upgrade to Delphi XE2 with very few changes.
If yes, check whether the source code of these components is already available.
If not, you will have to buy new licenses of these components (and this time take the license that includes the source code!) if you want to upgrade to Delphi XE2. If you are really unlucky, the company who developed these components has gone belly up. Then you are either stuck with Delphi 2006 or you will have to find a replacement for these components.
If you already got the component's source code, you might still want to check whether to upgrade them to Delphi XE2. It might save you some headaches. Upgrading well written components is not a problem for an experienced Delphi developer (I have done so countless times over the years), but might prove nearly impossible for somebody who doesn't know the possible pitfalls.
The only breaking change between Delphi 2006 and XE2 (actually it happened between Delphi 2007 and Delphi 2009) is the switch to Unicode strings. Switching an existing code base might be painless or a real pain in the lower back, depending on how well written it is to begin with and how it (ab)used strings.
Another option you have not yet mentioned, might be upgrading to Delphi 2007, which basically was more of a bugfix to Delphi 2006 than a real release in its own right. If I remember correctly Delphi 2006 packages worked with Delphi 2007 without even recompiling.
A year ago I moved from 2006 to XE (not XE2). This was quite painless. The biggest thing was unicode. But even that was relatively easy (in my specific case probably). Most is handled by Delphi in a correct way. Biggest problems were the import components, especially when character strings were used as byte strings, which in my field (music, midi) is the norm. There is a white paper on strings conversion on Embarcadero.
I only use components with source available. If you don't, you might have have to repurchase the licenses.
It is a long jump taking 2006 to 2011/2012!
But it is possible if you consider that:
You have to convert String variables using the new conversions methods ;
You have to check all the versions between 2006 and xe/xe2 to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
You have to buy/download the upgrade (if any) of your 3rd party components.
If you do that 3 things, the applications will compile just fine.
It's always easier to upgrade the IDE than rewriting the code, if there's any complexity in code beyond trivial cases like "Hello, World".
Big road blocks in Delphi 2006 might be: old components without source code, unicode issues, possible use of obsolete technologies (BDE mainly), and possible some low level hacking, like using undocumented features.
You get old versions of Delphi free when you buy XE2 licence. However Delphi 2006 is not there. Delphi 2007 is almost same (but better). It may even be possible to use D2006 binary packages with Delphi 2007.
When rewriting, first task for you is to find out what the software actually does. Line by line. Then you need to duplicate that in Java, hopefully in Java style, and then you need to verify against the old software that the functionality is actually there, duplicated.
So, you can choose between complete rewrite or something between recompile and partial rewrite, if there's problem with old components.
Read also this, old but good text: Things You Should Never Do, Part 1
That said, you need business reason for rewrite, and someone willing to pay for it.
I started occupational programming with Delphi when the Turbos came out , and have licenses for Delphi 2006 Turbo Pro and Delphi 2009 Professional. I have been asked to support another in-house tool, written by another occupational programmer, who has since retired.
It's a Windows program, but it was developed with Delphi 6 using the CLX library rather than the VCL.
From what I gather, the CLX library was QT based and was removed prior to Delphi 2006.The support only consists of a few bug fixes and some minor tweaks, so I would rather not port the code to VCL, if i can avoid it.
Is it possible to install CLX support into either Delphi 2006 or 2009?
Maybe not a direct answer but if you upgrade to Delphi XE, you will also get license keys for some of the older versions of Delphi down to 7, and Delphi 7 included CLX (it was dropped in Borland Delphi 2006).
The short answer is: no. Unfortunately I don't know any long answer which could tell you how to workaround this.
No, you can't add support for CLX to your other Delphi versions.
If it's in-house software, then your company should still have the in-house Delphi installation used to develop it. Multiple Delphi versions can co-exist on the same system; install earlier versions before installing later versions.
If the former employee took that installation with him when he left, can you get it back? I wouldn't expect it really belongs to him anyway. You said he retired; that wasn't a euphemism for died, was it? If not, then you can still contact him.
If there isn't an easy way (and I suspect that there is not), you may need to continue using D7. D2009 is going to introduce the hassle of Unicode, and even going to D2006 is going to cause problems with 3rd-party libraries.
You could run both versions of Delphi on the same machine, but another option would be to use a VM for the legacy development. Either set up a new instance, or you could use the VMWare Converter to convert the other developer's entire machine into a VM image, which you could run on your machine, via the free VMWare Player.
BTW, VMWare Converter is a GREAT way to preserve old environments, to allow maintenance on older software that really needs to use a particular Delphi version, on a particular OS, "just like I left it". If you have a bunch of dusty computers under your desk, consider this option. VMWare Converter is the only tool I know of that will easily convert a physical machine to a useable VM that will run anywhere.
From what I've read from the previous posts, Delphi 7 is stable and has the best help system but is slow, Delphi 2007 is fast but the help system is bad and the IDE is buggy. Delphi 2009 is stable and fast but the help system is bad too. The posts were made when 2010 isn't available yet. I am planning to upgrade from Delphi 7 to 2010. Is Delphi 2010 stable, fast and has a good help system?
Delphi 2010 is one of the best Delphi releases ever. It stabilizes some of the new features introduced in Delphi 2009. The IDE is fast, and in the project I used it was very stable.
The thing there is that the IDE and the help system are build as a RAD Studio for different languages. Especially the help system tries to be everything for everybody. Even having only one personality installed, it has many entires about other languages I do not care about (but I can filter them). Yet there are many entires missing depth that never made it into the new help format.
The help system starts painstakingly slow (especially at first startup). But, to be fair, this is partially do to the MS Help System being a pain in the neck (this, in my opinion, just was the wrong path to chose).
Embarcadero invests quite some effort into the help system, and it had several updates during the 2010 release.
You do know about the varying expense of conversion to Unicode as 2010 is fully Unicode based?
Here are some reasons why I stick to Delphi 7, having Delphi 2010 at hand to recompile and test what I wrote in Delphi 7, in a cross-version manner:
if your source code compiles on Delphi 7, and you make careful usage of Unicode/AnsiString, it will work as well with Delphi 2010;
if your source code compiles on Delphi 7, it will work as well with Free Pascal, so
cross-platform and 64 bits are open to you;
if your source code compiles on Delphi 7, it can be cross-compiled with CrossKylix directly from the Delphi 7 IDE - see Has any one used CrossKylix for real Cross-platform development?
Delphi 7 runs well on my Windows Seven 64 bits system, if you install it not in "C:\Program Files" but in "C:\Progs" for example;
Delphi 7 starts faster than Delphi 2007, and MUCH faster than Delphi 2009/2010 - see http://andy.jgknet.de/dspeedup
generated code is almost the same since Delphi 7 - when I need speed, I use better algorithms, and assembler if it's worth it;
Delphi 7 IDE is as powerful as Delphi 2010 IDE, if you use some IDE enhancements like http://www.cnpack.org;
Delphi 7 help is still the reference - why waiting for 20 seconds on my Core i7 processor waiting for the awful MS help system to launch? and if you want to create an application able to run under XP, its content will be enough for you; if you want to know about newer OS, just use msdn web site directly, or via google: it sounded to me easier than the help integrated with Delphi 2005/2010;
I use the assembler/CPU view a lot: all Delphi IDE have the Alt-F2, but you can close this window by the escape key on Delphi 7 - I was not able to find such a keyboard shortcut under Delphi 2007/2010, and it's very annoying;
Delphi 7 executable size are small, and even smaller with our LVCL libraries (30 KB for a form with buttons);
I didn't have the need for generics and such up to now - I like knowing which code is generated;
Delphi 7 is Unicode ready, whatever you say - its associated VCL was not, but CharSets are not evil, and work well - what I do is develop under Delphi 7, then compile with Delphi 2010 and get all the Unicode benefits if needed;
I use a large screen (at 1920x1280 resolution), and Delphi 7 makes it easy to have multiple edit windows at once - newer IDE locked layout was not a good idea... at such that EMB officially added the "Delphi 7 way undocked IDE" feature to Delphi 2010: and marketing sell it as a new feature;
and so on, and so on...
You can use Delphi 7 help in Delphi 2010, if you want to.
Use this or this addon. See item 5 here for instructions (sorry, it's machine auto-tranlation).
P.S. You can have more than one help installed. Say, a F1 for Delphi 7 help and Ctrl+F1 for Delphi 2010 help.
delphi 2010 is stable and fast and is actually a good delphi compiler after years of half-baked releases, they have improved help system in delphi 2010 but i still think delphi 7 help system is superior(but thats just my opinion).you do know delphi 2010 has a 1 month trial do you? download it and play around and see if you like it
EDIT: forgot to mention if you buy delphi 2010 you'll get marco cantu's Delphi 2010 Handbook for free ,the book covers whats new in D2010 so if you consider book as part of help system than help system is OK :)
Delphi7 was faster, but it was a lot simpler. I wouldn't worry too much about performance of the IDE, especially if you're working on a modern PC. At work I've got an old P4 machine, and it runs just fine.
New language features like methods on records and generics make it well worth it to switch.
For me it's hard to live without TList<T> nowadays.
For a while I've desperately tried to keep code Delphi7-compatible, but I've ported most of the important applications to D2010 already, and whenever I need to start D7, it all feels so low-tech and simple.
I've always hated the crappy component palette in the older Delphi's. Delphi 2010 has a much better interface, and the filter function is a real time-saver.
I've decided to give up on Delphi7 and just make full use of D2010's capabilities. That makes life a lot easier.
Currently we use Delphi 2007 because our application and some of our components are not compatible with Unicode. If and when we upgrade is it better to jump directly to Delphi 2010?
Propably, but I wonder if there is other compability issues except unicode?
How is performance, memory requirements and stability of those versions?
If you decide to upgrade, then yes, go with the latest version.
Delphi 2010 is definitely better than 2009, by not much though.
Don't expect your upgrade to be smooth.
For example: Delphi has a new version almost every year.
Then why it never helps you with the transfer of the settings between the versions?
Why all components are written in a way to lock you to the latest known version to the component? (this is not necessarily problem with Emabracadero, but they could provide guidelines)
Check if your components have '2010 version or you might need to fix hundreds of small but problematic lines of code.
No doubts, you should go directly to D2010, not to D2009 - in this aspect D2010 is actually more like D2009 SP1 than a fully new version, just with some nice additions like an updated RTTI. D2010 has no new known compatibility issues, has better stability, etc.
This is related to another Delphi-version question but still different;
I'm looking for a way to detect the service-pack (or build number) of the Delphi compiler that's compiling my code. The jedi.inc is nice, but it doesn't tell me the exact version. (I can't use the SUPPORTS_* defines in there either, as those are version-related too)
I need this, because some bugs are present in older versions (in this case, it's a _ValLong bug in Delphi 2009) that's fixed in a later service-pack (Delphi 2009 service pack 3 in this case).
Currently I have all kinds of checks in my code, like this :
{$IFDEF BUG_QC_68123}
But I can't just say this in my main include file :
{$IFDEF DELPHI2009_UP}
{$DEFINE BUG_QC_68123}
{$ENDIF}
...As this would miss the fact that D2009SP3 and later don't have this bug anymore.
Any ideas?
PS: This will probably also apply to older (and newer) versions of Delphi, so any library- and/or component-vendor will have an interest in this too, I presume.
There are symbols defined for each version:
VER80 - Delphi 1
VER90 - Delphi 2
VER100 - Delphi 3
VER120 - Delphi 4
VER130 - Delphi 5
VER140 - Delphi 6
VER150 - Delphi 7
VER160 - Delphi 8
VER170 - Delphi 2005
VER180 - Delphi 2006
VER180 - Delphi 2007
VER185 - Delphi 2007 (Note: symbol VER185, for example, is used to indicate Delphi 2007 compiler or an earlier version.)
VER190 - Delphi 2007 for .NET
VER200 - C++ Builder 2009
VER210 - Delphi 2010
VER220 - Delphi XE
VER230 - Delphi XE2
VER240 - Delphi XE3
VER250 - Delphi XE4
VER260 - Delphi XE5
VER270 - Delphi XE6
VER280 - Delphi XE7
WIN32 - Indicates that the operating environment is the Win32 API.
LINUX - Indicates that the operating environment is Linux
MSWINDOWS - Indicates that the operating environment is the MS Windows/li]
CONSOLE - Indicates that an application is being compiled as a console application
Source
Another source
You can't check for different build numbers.
And for the curious, VER10-VER70 where the turbo pascal versions, and VER110 was a C++ builder version.
Unfortunately, constants like RTLVersion in System.pas aren't updated in updates, but I think it would be a good suggestion if someone wants to make a QC entry for it.
If the bugs you are testing for are practical to reproduce in code, you could always test for them on startup and set your own global flags.
I get around these differences by making sure we always apply the latest updates. I haven't run in to a case yet where an update was unstable and forced me to roll it back. At least not with Delphi.
You could try including the compiler file version in your software. For example, DCC32.exe has a file version on it which you can programmatically get at and then write to a unit as a const. This could be done as part of your build process so it gets the version info before building your app (it'd be very easy to do with something like FinalBuilder).
I've done this for other things so that on our About screen we can get various bits of useful info. Also when we have an error in one our applications, we can bundle this info into our EurekaLog bug reports.
However I don't know if the file version on DCC32.exe is updated with every Delphi update.
The compiler does not expose that information. It only tells you the major version, which doesn't change when updates are applied.
I think the best you can do is to always write code for the latest update. Assume that consumers of your code will also have the latest update. If they don't, then it's their own fault, and not a problem you need to worry about. Mention it in your system requirements. Sure, your code won't work for them, but neither will anyone else's because they're still using known-bad code.
The next-best alternative is to write assuming that no updates have been applied. That is, write your code as though all known bugs are still present. The downside is that your code probably won't run as well as it otherwise could, so everyone who did the right thing by upgrading gets punished by continuing to have your suboptimal code.