I am working on a C++/Win32 project, and I have some Delphi code from some other (not mine) project that is relevant, and I want to convert it to C++ and integrate into my project.
Keep in mind I have no experience with Delphi.
What's a good and user-friendly Delphi complier? I don't mind about command line or GUI, as long as it's clear to use.
The only Delphi compiler is the Delphi compiler. It's not free. There is the Free Pascal Compiler, FPC. That is, as its name suggests, free. FPC can compile most Delphi code but be aware that many Delphi libraries, e.g. the VCL, are not available for FPC.
I do not know whether this would be too painful for you you to convert the source code in C++ manually.
But have you tried Lazarus? It is intended to be an open source equivalent of Delphi.
Hope it helped.
The previous responses here were all valid in 2012, but things have changed.
Nowadays there is a free (as in beer) Community Edition:
https://www.embarcadero.com/products/delphi/starter/free-download
in C# you can easily open an assembly (just another word from an EXE) and then get reflection information from that assembly. I've been looking for something similar for Delphi where I can write a Delphi program that can point to a Delphi EXE then get me reflection information. How can I archive this? Thanks
There are a handful of programs that can extract RTTI from Delphi programs and DLLs. It's not as rich as what's available for .NET, but it can be done to a limited degree. There's a lot more RTTI available in Delphi 2010 and later versions, but as far as I know there's no program out yet that can extract info from them.
I was at the conference where this system was formally announced, and a bunch of people asked how this would affect security. Barry Kelly, who created the new RTTI, said that there would not be enough metadata available to create a "Delphi Reflector".
Well, sad news is, you probably can't. You can easily view .NET assemblies because they a) are compiled to what is called intermediate language (thus you can even get the code back using the likes of Reflector etc.), and b) contain metadata. Delphi, on the other hand, compiles to native code that and produces regular PE files that do not include rich metadata like a .NET assembly.
Delphi just doesn't work that way.
There are tools that can assist in reversing (Delphi written) executables but it will never be easy and it requires good x86 assembly knowledge.
Some examples of such tools are:
IDA Pro and/or Hex Rays
DeDe
Interactive Delphi Reconstructor
PE Explorer
The resource sections of a Delphi Executable also reveals usefull info like the form and it's components.
See also Is there a program to decompile Delphi?
If you have Delphi2010+ you can load a bpl and then use the rich rtti over it lik. e you do with c# and a .net assembly. If you need to do this in a .exe AFAIK you can't.
TestComplete seems to identify most objects in a running Delphi executable. You can extract this information with a script. A demo can be downloaded from http://www.automatedqa.com/downloads/testcomplete
This is maybe not the type of application you want as it is big and made for GUI-testing, but yes it can identify the objects.
As mentioned Remko, IDR (Interactive Delphi Reconstructor) can extract all RTTI information (if program contains it!) for Delphi version from 2 to 2009. Version 2010 will be available later. Moreover IDR can use all information that it finds in program to create a lot of comments to disassemled program code (this is a first step of analyses). You can also look forms and easy go to event hadlers associated with controls.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been very happy with the Delphi IDE for programming in Delphi.
But I've heard about the Lazarus programming environment, and I've also heard that some Delphi programmers use it instead of the Delphi IDE.
What are the advantages that Lazarus has over the Delphi IDE, and why would, or should a Delphi programmer switch to it?
The answers are leaving me with more questions than I had before. There seems to be some disagreement as to whether Lazarus can or cannot be used as an editor in developing Delphi code. I guess I thought you could leave everything in Delphi and just change IDEs. The Lazarus for Delphi Users section of the Lazarus Wiki says:
The first thing to do when converting
a Delphi project
Having opened
Lazarus, you should go to to Tools and
then Convert Delphi Project to Lazarus
Project. This won't do everything for
you, but nonetheless will take you a
good deal of the way. Note that the
Lazarus IDE's conversion tools are
generally one-way conversions. If you
need to retain Delphi compatibility so
you can compile your project with both
Delphi and Lazarus, consider
converting your files with the XDev
Toolkit instead.
Because Lazarus is free is not a reason to switch, but does not penalize you in physical $'s for switching. (You will still have to invest your time to convert and learn. Time = $).
My as-much-as-I-understand conclusions from your answers as to why someone might switch from Delphi to Lazarus: obviously it must be providing something that Delphi currently can't. Currently that is multiplatform support and possibly 64-bit support. Delphi did have Kylix at one time, but not Mac support.
But with both of those and 64-bit promised soon by Embarcadero, you've answered my question by telling me there's no reason (at least for me) to switch.
Ok. This is an old thread, but could do with some updating. I stopped using Delphi, maybe a decade ago, largely because I had no choice. Having spent 5+ years working as a Delphi coder, I was now a student again and the prices for Delphi were simply outrageous. The problem with Delphi was never Delphi. Delphi was a genius system, but Borland (and later its successors) completely misunderstood the changing computer world. Microsoft was able to deliver a programming environment, that you could download for free, and its .NET environment was comparable with the VCL in all the important ways, meanwhile even a basic version of Delphi would break your bank or be plain out unavailable to student budgets. The end result is that with no new Delphi programmers coming on-line, it became a risky proposition for businesses to continue to use. Finally with the rise of linux, Kylix turned out to be a total trainwreck of an environment, not utilizing available UI toolchains and with a suspicious stench of Wine pervading it, topped off with an insulting attitude to GPL software that treated it as if it was shareware. Finally when Turbo Delphi came out many years later, it was unable to utilize the amazing resources available via sites like tories component sites. It was clear Borland had no respect at all for its coder ecosystem.
So Lazarus seemed to emerge out of all this, taking a very long time to gestate and seemingly aiming at some sort of analogue to Delphi 4, held by many to be one of the cleanest and neatest in the Delphi line. It complied to just about everything, its implementation of Object Pascal was spot-on, and most importantly it was free in all the senses that matter to open source.
However, it has had a long history of bugginess, and incomplete implementations of its controls. And this was bit of a deal breaker for me and many others.
With that said, I recently decided to download it, out of curiosity, and found that it's actually come a hell of a long way. The database components just work, although you might need to follow a few tutorials and chase some leads around to get them all up and running, and serious progress has been made towards iPhone and Android build targets.
I'm not sure I'm ready to deploy this to any of my commercial clients yet, but I'm going to give it another run with a personal project to put it through its paces, and if it does work, I think I'm finally going to be re-united with my first programming love, Pascal, and in a matter that lets me use my Mac to do the heavy lifting, whilst providing Windows and Linux builds.
So basically here are the facts on the comparison;-
Lazarus and Delphi are totally separate entities. Lazarus is NOT a cross compiler for Delphi, but has a certain degree of compatibility. Its more like GCC vs MS C++.
Delphi is more polished and likely more stable.
Lazarus provides a Delphi 4 like environment that old-hand Delphi coders will find very comfortable.
but Lazarus can be temperamental at times, and Delphi programmers need to understand that not everything in the latest and greatest Delphis will be there for them.
Delphi does Windows, and it does it very well (yes I know the new one has some cross compilation targets, but word on the street is, that it's a bit hacky and needs some time in the embacardo cooker before it's really there), whilst Lazarus complies to almost everything. The current target list is;- Darwin, NetBSD, OpenBSD, FreeBSD, Linux, Solaris, Win32, Win64, WinCE go32v2 (I think that's MS-DOS with 32bit extensions!), OS2, Netware(!), BEOS, Haiku(?!), QNX, wdosx(?), emx, netwlibc, Atari, Amiga, Palm-os, Gameboy advance, nds, MacOS, Morphos, Plus, there's experimental support for IOS and Android. On top of this, the thing can use widget sets from QT, GTK, GTK2, Win32/WIn64, Carbon, fpGUI(no idea), Cocoa or no GUI at all, with various degrees of implementation transparency.
Its an exhaustive list!
So Caveat Emptor. I strongly recommend Delphi coders download this and do some personal projects to get a feel for it, not on the boss' dime, but there's a lot of depth and substance to Lazarus, and it's potentially a vital tool in the belt for dealing with life outside the Windows crib.
Plus since Delphi's new masters still haven't learned a !##$%^&* thing about why Delphi fell from grace (Hint, make it affordable or free to hobbyists and students to learn and create custom components) , it's really the only budget option available. If Embarcadero ever wake up, maybe that will change. Until then, viva Lazarus.
The two main reasons for me are
1) Multiplatforms support (Linux, Mac OS X, Windows)
2) The price $0
Well a Delphi programmer cannot use Lazarus to write Delphi code because Lazarus is not Delphi. Lazarus is actually an IDE and a bunch of Delphi-ish class libraries for Free Pascal. But note, things like Delphi's VCL is not there, and to be perfectly blunt the IDE and debugging experiences in Lazarus are pretty spotty, however it is free, so that counts for a lot.
Bottom line, Delphi <> Lazarus. Use Delphi if you want a great IDE and debugger huge 3rd party support and tech suport you are targeting MS Windows, plus you are willing to pay for it. Use Lazarus (free pascal) if you want a Free IDE that supports multiple platforms and has a Delphi-ish syntax.
Maybe I'm just reading this wrong, but you seem to be under the impression that the IDEs are somehow interchangeable. That's not correct. Lazarus is built on top of the FPC compiler and is tied to it in much the same way that Delphi is tied to the DCC compiler. Also, they use different form description file formats. Delphi can't read LFMs, and Lazarus can try to read DFMs but it doesn't do a particularly good job of it.
FPC/Lazarus is very similar to Delphi, but it's a different dialect of Object Pascal and it would be a mistake to think they're equivalent.
I have a sound recognizing algorithm running on Delphi. When my superior asked to run it on WinCE I tried Lazarus. Pascal is Pascal. Lazarus is super. I have done it.
Algorithm is written in Pascal. I tried to convert. C# was prone to decompile and used different logic. Luckily I've found Free Pascal.
I have it running on WinCE on ARM. Thanks to all FPC collaborators.
edit: I have it running on Linux too.
Lazarus is cross-platform and free both as in speech and beer, while Delphi is neither. Lazarus does use a different compiler that compiles a language 99% compatible with Delphi, and provides a different visual component library, similar to but not compatible with Delphi's VCL.
Yes, Linux is installed on 70% of servers. It is powering the Facebook which has 400,000,000+ users. And you tell me to use Windows? You tell me not to use 64 bit?
I will use Lazarus. Until Delphi catches on.
Main reason for me - Delphi cannot currently compile 64bit apps and as such cannot see, read or write certain registry keys.
Well, I am one of those who uses Lazarus IDE to write Delphi source code.
I Like Delphi a lot. But use Delphi's editor is really a painful. I've tried VIM, and always dreamed to have an IDE like visual studio: simple, clean, and can split window horizontaly or vertically...
Finally I found Lazarus editor, way much better than Delphi's. So I use Lazarus write Delphi source, and RAD IDE is just for compile and debug.
For me :
64bit is alive (Delphi... yes may be, not and yes again, and finally no...)
Cross platform (Delphi not) By the way a lot of works still have to be done but it works !
FPC is a very good compiler
Community is cool and active
I don't have that much new to add, but I thought I'd relate my crossplatform experience. As far as putting together a cross platform application sketch fairly quickly, I find Lazarus to work very nicely. I've recently been using MonoDevelop of which there is much to commend, but the gui designer stetic doesn't seem as complete as the Lazarus GUI designer. Or is it the toolkit (GTK#) that seems to lack some bits? Before that, I've used Qt / C++ which also seemed to work out fairly well for crossplatform development, but I'm not real keen on C++, and Qt's signal/slot framework is a bit curious, but works well once you get your head wrapped around it. In sum, I find RAD work, and coding using Lazarus to be mostly joyful, besides, what a cool name for an IDE!
Cheers
Only CodeTyphon/Lazarus/FreePascal 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 platforms are supported in Lazarus/FreePascal, but others are not yet integrated in CodeTyphon. One code to rule them all ;-). CodeTyphon is a powerful one click installation package for cross platform native Delphi like RAD/IDE based on Lazarus/FreePascal that eliminates painful cross platform setup. You can start coding just few minutes after the download, so if cross platform, 64 bits or price are key benefits for you then choose Lazarus over Delphi. Lazarus is highly compatible to Delphi, and I have converted few applications without much problems. It is possible to maintain code that compiles on both.
Does Delphi support internationalization in any way?
I've seen that I can add different languages for a project, but that seems to create multiple instances of the dfm files. Am I right that the language therefore cannot be changed at runtime?
How do you handle internationalization (if you do)? Are there any best-practices?
Delphi ships with some tools to do this.
Here is a tutorial for Delphi 2005, and a video of Nick Hodges showing off the more recent version for Delphi 2009.
I have once experimented with runtime change of languages. It worked great, but I needed to write lots of code myself (and circumvent the dfm files). The problem is, it is a lot of hassle and you almost never need this.
The better option (in my opinion) is to create a base language version and use a translator tool for the other language. We use a third party translator that works on the executable and dll. It replaces the strings in the resources and creates new binary files.
One big plus of this tool is that it shows the translated dialogs (standard windows components only) so you have direct feedback if labels are too large.
Amd then there is dxgettext:
http://dxgettext.po.dk/
traditionally one of the tools used to change language runtime without restart.
Note that with Delphi/unicode the amount of code changes with this packages has decreased (one no longer has to change any resourcestring use)
I have been using the SiComponents before. They allow you to change all text independently from the executable. You can embed the diferent languages in your executable (not recomended) or load them from files. There is also an editor to support translation. They are very good, stable, and fast.
In Delphi 2006 under Tools, Options, Translation Tools Options you can configure the translation tools, especially theTranslation Repository. It can be found under View, Translation Manager. All translated strings will be ressource strings and can be stored in language specific dll. Searching the help for Translation Manager will point you in the right direction.
I second the recommendation for using the TsiLang components(www.sicomponents.com). I've just used them to upgrade from English-only to English + Chinese, selectable at run-time, and found the process to be quite a lot easier than I was expecting. The end results are not perfect, but certainly good enough to work with.
I have source code for a Windows DLL that is written in C++ and uses Visual Component Library. Now my task is to port that to Linux, but I don't have source code for the VCL itself, or any kind of documentation (and I have never worked with Borland C++; in my Windows days I used MFC).
This should not be all that hard, since my DLL does not have any GUI: as far as I can see, it mostly uses VCL for multithreading. I ran into a class that inherits from TThread and that is where I got stuck. I did some search on the Internet, but found no documentation for VCL so far. I would like to avoid buying a book on Borland C++ Builder, because I don't have time to wait for it to arrive from the Amazon. I cannot consider buying the package for Windows, because at work I only have a Linux box.
Any suggestions?
The Boost libraries, and wxWidgets, will provide analogs to the VCL classes.
You should be aware that the VCL used by C++ Builder is written entirely in Delphi/ObjectPascal. c++ builder apps all involve c++ making use of delphi-based libraries.
The FreePascal/Lazarus open source project has reverse-engineered most of the VCL (almost all of the non-visual stuff and much of the visual stuff) and it runs natively on Linux. The non-visual VCL-compatible stuff is known as the "Free Component Library" ("FCL")
http://www.freepascal.org/
http://www.freepascal.org/fcl/fcl.var
The source of the TThread implementation in the FCL should be easy enough to find.
One option would be to rewrite in FreePascal, where language would change to ObjectPascal but calls to the VCL and usage of VCL components would be virtually identical.
Another option might be to port to c++ on Linux and somehow make use of FreePascal's VCL from c++. I'm not sure of the practicality/feasibility of that. Someone at FreePascal's forums should be able to help answer that.
So another option as someone has mentioned would just be to rewrite using some other threading library.
The VCL is documented on CodeGear's web site. TThread in particular is described here.
I've found the documentation on the threading-related components of the VCL to be rather sparse. This site has a much better description of the Delphi/VCL approach to threading.
You can download their free compiler and try experimenting with it. It should be possible to run it under WINE at least. Maybe even under FreeDOS.
It should be related to the TThread class in Delphi/Kylix. That is another alternative for exploring it. I do believe that the most important methods were run() and sync() but it's been ages since I used it.
However, if you plan to cleanly port the code to Linux, it may help to re-implement the TThread class yourself, using some boost libraries or something.
Many years ago, Borland released a version of their IDE for linux, marketed as Kylix. I'm not sure if it is still supported, but that might be the path of least resistance, for you.
There are several libraries that provide frameworks like threading e.g. Boost (www.boost.org) or ACE (http://www.cs.wustl.edu/~schmidt/ACE.html)
It should be fairly easy to port the code to use one of these threading infrastructures.