I've been reading about CrossKylix recently, but for most uses one has to consider 3rd party components.
So I would like to know which of the actively developed components still support Kylix.
Many added partial or complete Kylix support back in the day, but I'm affraid some never kept updating, and the IFDEF-ed parts that compile with Kylix might not be tested.
So, ideally, I'd like a report from those with real apps and practical experience.
This might be of interest for users that are looking forward to future cross platform releases of Delphi that have been announced, as well as current Kylix/CrossKylix users.
The two most known components,
SynEdit
Virtual TreeView
both have some Kylix support.
I think that JCL and JVCL still have Kylix support. At least they still have mention of Kylix all over the code.
FastMM.
TsiLang.
Synapse.
You can also browse Kylix section on Torry. Pick category at the left menu and see if there are active projects.
TurboPower Abbrevia (zip/tar/gzip/bzip2) supports Kylix and CLX for everything except .cab archives, which rely on MS DLLs.
Related
The following question has had me wondering for some time now as to how 3rd party component developers are able to ensure there components are compatible with all the various IDE versions?
I am just a single developer who uses Delphi XE and occasionally Lazarus, if I developed some components in Delphi XE how would I ensure they are compatible up to Delphi XE6 for example, and also compatible with older IDEs?
I don't mean in a coding sense because I believe you use the IFDEF flags when checking the Delphi version numbers. I mean if you don't have access to different Delphi versions how do you test the component?
It is not possible for me right now to purchase XE6 or a new Delphi IDE for a while - if it all, and even if I could I would not have previous IDE's like Delphi 5,6,7 etc.
So how do other component developers do it?
Purchase all the IDEs? which seems unlikely
Download Trials for the IDEs? which also seems unlikely
Get people to test the component if they have another IDE? Seems possible
Make it Open Source and let others test it? Also seems possible unless you want it Close Sourced
What it comes down to is I want to make a few simple components but I want them to be compatible with as many Delphi versions as possible should they ever be released to the public.
I don't have the means to get all the Delphi IDE versions and downloading trials may also not be possible. Even if I bought XE6 or the next release I would not be able to test with Delphi 8 for example.
So, how do 3rd party component developers make there components compatible and tested on various IDEs? Am I missing something obvious here, how can you have access to every Delphi IDE Version?
As a component vendor myself (I am the primary developer of Indy) who needs to support multiple versions, I can only speak for myself, but here is how I do it:
Purchase all the IDEs?
If possible, yes. I have a number of IDE versions installed in VMs, which I use for testing purposes. And for some versions that I do not have installed, I do have their RTL source code for reference purposes, at least. On the other hand, as a member of TeamB, I get free IDE licenses, which helps. Not everyone can afford to purchase every version, although newer versions do provide free licenses for older versions, so you should take advantage of that. I recently installed Delphi 7 through this. If a components works in Delphi 7 and Delphi XE6 then there is a good chance it will work in all versions in between (barring any version-specific RTL bugs, etc).
Download Trials for the IDEs?
N/A for me, but that might be a viable option for some people.
Get people to test the component if they have another IDE?
I do this with Indy. Although I do have several versions, I don't have every version. Other users who have versions I don't have myself do help. If nothing else, for setting up version-specific project files and testing install procedures.
Make it Open Source and let others test it?
This also helps. If you want to develop closed-source components, you could setup a private repository and give access to select users/volunteers. Most users want/need source code (to find and fix bugs when used in their projects, to satisfy corporate policy requirements, etc), so you should make sure you offer an option to pay for source code.
When you buy the latest you get access to all the previous versions (from v7 on - thanks Uwe Raabe)
Previous versions
I am using the first approach: Buy all versions. I have all Delphi versions back to version 3 (from 1997), but only 6 to XE6 are installed on my machine (with the exception of Delphi 8 which in my opinion should better be forgotten). But of course I didn't buy them all at the same time, I started with Delphi 3 and updated from there on.
Unfortunately it becomes more and more complicated to get older versions installed and running on "modern" operating systems (currently Windows 8.1 so far) so sooner or later I will be forced to switch to virtual machines. Not yet, though. Switching to VMs has the drawback that you can't batch compile using different Delphi versions:
call CompileForDelphi6.cmd
call CompileForDelphi7.cmd
etc.
like I do for GExperts.
Should I upgrade from Delphi 2009 to delphi XE?
As I don't use all the technologies, such as mobile, cloud computing, profiling, 64 bit, new database drivers, I don't need to change to the new XE?
What would change my mind?
Does the new Delphi IDE help me to write less code? Is the package management better?
Do you feel that the IDE gives more automation? And is it worth the upgrade?
I use Delphi XE all day every day, and I wouldn't use anything else.
It is the most stable version of the IDE that I have ever used. The compiler has had a huge amount of attention paid to it, and it works, and doesn't have the many internal failures, internal access violations, or other ways that compilers fall down, that every Delphi release since Delphi 2005 has. So the main feature that makes Delphi XE the best version ever is stability. It is even more stable than my old standby - Delphi 7. And delphi 7 is pretty stable, but working all day in Delphi 7, I did experience regular crashes, something that is finally a thing of the past, with Delphi XE. Okay, I've crashed XE's IDE a couple times, but it's rare.
The second reason is that it comes with great tools; A version of final builder, a version of CodeSite, and a version of AQTime are included. CodeSite was new to me with XE, but I love it, and now that I have used it I couldn't live without it. AQTime is an old friend of mine, and the version included with XE does most of the things that the full standalone AQTime will do, that I need it to do. The final builder version included, is also a huge time saver, especially if you have complex builds to do, including several Delphi application compiles, and an installer script to run, and perhaps other steps.
I like the code-formatter. I am not a big fan of Generics, but you can use them now, and they don't kill the compiler. I still prefer simple readable code, to a morass of generics, and I don't like the way that you do constraints with generics using IUnknown-style reference counted interfaces. Not nice, and not fun.
I don't use much of the database, cloud, or multi-tier application development features. I can't report on that aspect, but I do know that there's a lot more in the RAD XE product than any single developer, however intrepid, can probably even discover.
(Ethical Disclosure Footnote; I work for embarcadero. But even if I didn't, I'd still say everything above. Perhaps, I'd state it even more strongly.)
Does the new Delphi IDE help me to
write less code? Is the package
management better? Do you feel that
the IDE gives more automation?
No real changes there I think.
The area with possibly the most noticeable differences is generics. If you use generics at all then you should upgrade. The versions that followed 2009 have far fewer bugs and wrinkles in the implementation of generics.
In addition to what David said, there also is the new RTTI in Delphi XE which might make the upgrade worthwhile.
Besides the generics improvements, there are new features in the IDE. The addition of a code formatter, IDE Insight improvements to help you find things, integration of SVN, the reworking of the configuration manager, custom build tools, form designer changes, and more. There's also a bunch of new stuff in RTTI.
See this page for a list of what's new in XE, and go up a level from there to see a listing of what's changed specifically from 2009 to XE.
I think it's worth it...
Many bug fixes - they have focused alot on closing out issues. You cannot discount this...you'll never get any more fixes in your current version and the time saved by not having to work around just a single bug or two certainly pays for the upgrade cost if your time is valuable.
SVN integration is handy.
"Show In Explorer" from the project manager. (I don't know if it's just me, but I use this alot and it saves me time.)
If you like code formatters, there's a new option to format all sources in the project.
Debugger visualizers are kinda cool
Third Party Tools included: somewhat crippled, but very usable versions of: AQTime, Beyond Compare, CodeSite, IPWorks, Finalbuilder (depending on Pro/Enterprise)
Online help updated quite a bit
Can it help you write less code? Yes, as you can now rely on generics more due to many fixes from 2009, 2010 and XE. There's also some additional live templates added if that's what you are after.
What would change your mind? I'd say the bug fixes, additional Third party tools, and Online Help improvements make it a no-contest upgrade for the Pro edition. If you are going for Enterprise upgrade, and not using dbExpress, or other enterprise features, then it might be a little less convincing of an update depending on your budget.
The Help has been improved a great deal in XE - in 2010 it was a (bad) joke. 'Show in Explorer' is also great, although not enough reason to lay out that much money. Also much better support for REST, JSON etc. And XE just feels very mature and stable - I don't work for Embarcadero, but I use XE every day, as much as possible - unfortunately I am currently working on a project that uses components compiled for Delphi 5 without source code so I can't use XE for everything. There are some VS guys in my shop who think 'Delphi is Dead' and give me some grief - I am proving them wrong with XE...
Once 64 bit Delphi will be releases (is it for 2012?) how will components will work?
I mean I use several 3rd party components: will they automatically work on 64 bit or not? Will they need to release 2 separate versions of the components?
I think you can compare it with the first release of the Unicode version of Delphi, Delphi 2009. When Delphi 2009 came out the 3rd party component vendors all supplied Unicode aware components pretty rapidly. Many had components ready at release.
In many ways, I suspect that the changes needed for 3rd party components to support Unicode will have been more onerous than will be needed for 64 bit. The 3rd party vendors will already be looking ahead and making use of NativeInt and NativeUInt types.
As for different versions, the normal practice from 3rd party component vendors is for their source code to compile on all supported platforms. If you are using packages then clearly you need different versions for different compilers but that's true today as well – components are delivered with packages for each supported Delphi version.
One point I would stress would be that if you have not already moved to a Unicode Delphi, then you should do that as soon as possible. You won't be able to move to the 64 bit version of Delphi without doing so and since you can port to Unicode Delphi now you really should get that out of the way.
In short, I have little apprehension over this issue.
In short: components might automatically work in x64 Delphi, however most of them likely need changes, especially when they use pointers or assembly language.
I know that the Delphi team strives for an upgrade path to be as smooth as possible.
But x64 - like Unicode - is a breaking change, so be prepared to update your components too.
Usually, platform vendors will brief 3rd party vendors before the general public so they have time to make their 3rd party products compatible with their new platform version.
Microsoft has done this for .NET, the Delphi team has done this for Unicode and .NET, and other vendors have done similar things.
Like Eugene mentioned, 3rd party library vendors could also use the x64 version of Free Pascal to get a feel of what changes might be needed.
When you look at the source code, you see that some vendors indeed do.
You can get yourself a feel for the changes too.
For instance, Allen Bauer uses his blog and his twitter feed to post some info on x64 Delphi. He also talked about Delphi x64 on this Delphi.org podcast interview.
Embarcadero has shown an alpha version of the Delphi x64 command-line compiler during roadshows and conferences, including the last virtual CodeRage conference.
--jeroen
Those vendors who look ahead, have already started to test their code (wherever possible) with 64-bit FreePascal. In general, the answer to your question is very specific to the component. If pointers are used extensively or if hardware is involved, adaptation of code will be needed. Otherwise there should be no significant problems on recompilation for 64 bits.
And yes, separate versions of code are required in any case for native code.
I've just received an assignment to upgrade an old Delphi 3 project that I wrote in 1999 to a newer version and add features (I previously discussed this in related questions here and here). I was assuming that the appropriate route would be to first upgrade my development environment to Delphi 2010 and then port the application.
I'm now considering whether to upgrade the application to my existing copy of Delphi 2007 instead in order to avoid the Unicode complications. The application runs at a single company in the United States and is tightly bound to requirements of a single state, so it would not benefit from Unicode support.
My question is: would the additional hassle of dealing with Unicode issues outweigh the benefit of using the most recent version of Delphi? You may assume that I have no experience with Unicode.
why "upgrade" to a version that is not the latest, it just guarantees an earlier "next upgrade".
I'm very very happy with Delphi 2010, I recommend porting to that version unless you use a 3rd party lib that is not available for D2010
You should try it (the upgrade) on a D2010 trial, and give yourself a day or so to get a feel for the type of complications that result. Generally, if you didn't use a lot of PChar for pointer arithmetic, and you didn't use sub-ranges of strings, e.g. Code[1] := 'A', and so on, there should be few or no upgrade issues. Aside from the unicode upgrade, the D2010 IDE is much nicer to use, and seems faster than D2007.
D2007 may be easier to upgrade, because you it will not require changes of your code to work probably with Unicode, and if your code doesn't require a lot of PChar and others ANSI dedicated functions, it may work in Delphi2010 without a lot of work.
But if you have time and resources to upgrade to Delphi 2010, it will be better options, because sooner or later version from Delphi 2009 and later will be the standard versions.
Also the IDE productivity is higher in D2010, beside new language additions like generics, anonymous methods and others which make your code better, if you going to rewrite some sections of it.
They have done such a good job implementing Unicode in Delphi 2009 that most programs that do not do tricks with characters and bytes convert over with no problem.
The caveat is as long as you are not using any 3rd party packages. If you are, you should upgrade those. If they don't have upgrades and you don't have their source code, then you might be better off not going to Delphi 2010.
But I would make the jump if at all possible. I did and I'm glad I did.
"That depends"
It depends on the number of 3rd party controls and the current state of those controls. (Are they still on the market with updates for 2007 and 2010?)
It depends on code size and code quality. If you have a large, loosely managed code base it will be a harder path to 2010.
It also depends (largely) on project input/outputs... are you reading from files/databases/communications? How will they react to Unicode, or can you easily narrow down all of those touch points to ensure proper handling?
One other major dependancy is the life of the application... "Going Unicode" now might serve you better if you are going to support this application over the long term as eventually they'll stop selling 2007 and you'll be forced into it.
I own 2009 and have built minor applications/utilities with it, but the main work is still in 2007, 2006, D7, and D5 depending on project.
See here. It can confuse the things when coming to D2010.
I have a few Delphi 6 third party components which I need to add to Delphi 2010 to begin my migration. Is it possible? The interface seem a lot different and I can't seem to find a way to do this?
This help...
My components: DBGridEasy, TSerial, Varian Async32.
Thanks a lot.
As has been mentioned this is not straightforward. But you do have options.
Check with Vendor and get update
if you have source you can try to update yourself.
I don't agree that it is neccesarily too complicated to upgrade. Delphi 2009 did add (finally - about a decade after it should have) very good Unicode support into the heart of delphi, but this was done down to the level of almost every built in function.
We upgraded a large (700,000 lines) project in only a couple of days. There is info on the net on what to do, there are a number of functions you need to replace if you use them (such as any funcion with Ansi in the title). Its worth a try at least.
If you dont have the source I'm afraid you have no choice but to contact the vendor, there is nothing you can do since the binary format for each Delphi version is differnt.
I don't know for sure about those particular components, but it probably won't work even if you have the source for them because there were many changes between those versions, such as the string type changing. You would be better off finding out if the vendor has updated them.
The biggest change between Delphi 6 and Delphi 2010 is the changing of the default strings to Unicode in Delphi 2009.
I highly recommend against using any pre-Delphi 2009 component with your upgrade. They will not know about Unicode and you will run into problems.
First, you should see if the new version of Delphi already has the functionality you want built in. Many things have been upgraded over the years. You may find you don't need some of your old components at all.
For the ones you still need, try to find an upgrade, or some other similar component that is ready for Delphi 2009. There are many grids around. I am not familiar with Serial or Async programs to recommend one.
This might already help you: Varian Async was acquired by TMS, the same component is now known as TMS Async32