Recently, Free Pascal (FPC) version 2.2.0 was released. This open source Pascal compiler has – since its initial release in 1993 – grown to be one of the most sophisticated open source compilers available today. Daily, more programmers discover FPC and develop their applications in Object Pascal. Specifically, the development of Lazarus has contributed to this phenomenon: Lazarus is a graphical open source IDE for FPC, with an extensive tool kit to design graphical (GUI) applications.
What is FPC’s strength?
For many programmers, the renewed interest in Pascal is surprising. Many
think of Pascal as an old language, no longer used, which has lost the battle with C a long time ago. Nevertheless, FPC has enough features to make it the language of choice for programmers.
Cross Platform
The biggest advantage of FPC is that it is cross-platform. The development
of this compiler has been focused on this aspect ever since the start of the
2.0 series.
This feature removes the need for laborious writing of complicated
Makefiles, which differ per platform, and which need to be generated with
tools like autoconf and configure: The programmer does not need to look for
all kinds of libraries: copying the compiler and the sources of the project
to another platform is sufficient for porting to a new system. Obviously,
cross compiling from one platform (say, Linux) to another (Windows is a
popular target) is also possible.
The reason Free Pascal code is portable is simple: it offers a large set of
cross-platform standard routines, bypassing the differences between Posix
and Windows API’s. While those can be simulated on other platforms, these
simulations require cumbersome libraries and installations, and often the
programs have a strange look-and-feel on the non-native platforms.
The Free Pascal compiler comes with a rich set of code libraries: The RTL
(Run-Time Library) provides basic functionality such as file-access,
classes, string manipulation and RTTI (Run-Time Type Information) for
streaming. The FCL (Free Class Library) is an object oriented library that
takes care of XML, Web programming, database access, image manipulation or a test-unit framework. As long as a programmer uses these libraries and
refrains from using system-dependent APIs, his program will not only run on
Linux, but also on Windows, Free BSD, Mac OS X, Windows CE and more.
It is self-evident that direct references to operating specific directories
such as ‘c:\program files’ or a configuration file in ‘/etc/myprog.cfg’,
are not cross-platform.
Using the FPC routines (for instance the TRegistry class) will take care of
these operating system details: The FCL knows where and how each system
stores configuration data. This almost completely removes the need for
system-specific API calls.
Graphical (GUI) applications
Graphical (Desktop) applications are the norm these days. Those are not a
problem: the IDE (Integrated Development Environment) Lazarus is designed
with the same principles in mind as when designing FPC: The LCL (Lazarus
Class Library) delivered with Lazarus makes it possible to develop desktop
applications that use the standard Windows 32 or 64 API. On Linux GTK 1 or 2 is used, and both a Qt and Carbon native layer are nearing their completion.
Using Lazarus, an application can be developed on Linux, and it will use
GTK. All that is needed to make a Windows version of this application is
supplying a compiler option: A recompile will then produce a windows
executable that works directly on any Windows version – without the need for
installing extra libraries. All that is required for this is a standard
Lazarus installation.
64-bits Windows
Compiling from Windows to Linux is slightly more difficult: the compiler
needs the GNU linker to compile ELF binaries, and it needs to have a copy of
all needed libraries available. Yet the principle remains the same. To
produce windows binaries, FPC has an internal linker. This enables the
compiler to generate 64-bit Windows binaries, when the GNU utilities do not
yet have this ability. This makes FPC and Lazarus the first big open-source
compiler and IDE for Win64.
New features for Object Pascal
In the past, the FPC added several new features to the pascal language, such
as operator overloading – later also implemented by commercial compilers.
New in version 2.2 is the experimental support for generics (templates).
This can be useful when programming e.g. list classes.
Speed
FPC is a fast compiler: FPC compiles code roughly 7 times faster than for
instance GCC. This may seem to be of little importance, but it cuts down
development time. The speed of the generated code is comparable to the GCC compiler: according to the Shootout benchmarks, the FPC 2.0.4 code is 30% slower code than GCC. In contrast, FPC code uses less memory than GCC
generated code. Compared to interpreted languages, one sees that FPC code
executes 50 times faster than e.g. Ruby. The difference with PHP and Java is
smaller, but these use 14 (PHP) to 17 (Java) times more memory than FPC
programs.
One can wonder whether the speed of benchmarks says anything about real
(graphical) applications. Comparing the response of the popular Java IDE
Eclipse with the response of Lazarus will quickly convince one of the
difference. Native code remains faster than interpreted and JIT languages,
even when pre-compiled. Native code uses less memory, and is easier to
install, since no extras need to be installed on the computer of the
end-user.
Libraries
As remarked earlier on, Free Pascal is shipped with the RTL and FCL code
libraries. The FCL comes with components for accessing databases such as
Oracle, Firebird, MySQL, SQLite, PostgreSQL and any ODBC enabled database.
It also contains code for XML, Web Programs (CGI and Apache modules) or
access to graphical libraries such as SDL and OpenGL. Lots of Delphi
components are directly usable with Free Pascal. The ZeOS database access
components and the Indy networking components jump to mind. An increasing number of companies makes its Delphi libraries available for Lazarus and Free Pascal.
Conclusion
Free Pascal is a mature compiler, excellently suitable for any programming
task at hand. FPC shines especially where it concerns cross-platform
applications: the ease with which applications for Windows and Linux can be
developed is simply astonishing. On top of this the Lazarus project offers a
2-way IDE for the development of GUI (Desktop) applications, something
scarcely available for C or C++ under Linux. This domain is traditionally
reserved to interpreted languages such as Java or C#, which suffer from
problems such as excessive memory usage, slow performance and
maintainability. All in all it can be said that the combination FPC/Lazarus
is a good choice for cross-platform development.
How good is Lazarus today? I was very interested in its development back in 2000-2002, partially because Kylix utterly failed. But then I learned C and GTK and kinda never looked back. I visited the Lazarus website from time to time, but their screenshots are severely outdated: they’re still showing GTK 1 screenshots in 2007! This made me think that their development has halted or is very very slow.
Does the LCL still imitate the VCL or did they also add new things? The VCL is nice for mostly-fixed layout GUIs, but horrible for resizable dialogs because of the lack of sizers ala GTK and wxWidgets. Delphi 7 still suffers from this problem.
It’s a shame to read that generics/template support is still in development. I think that any serious modern statically typed OO programming language should support generics/templates. Don’t make me think back of the days when I had to write 3 different list classes just because I want to store different data types in it without requiring clients to cast return values.
Edited 2007-09-10 16:39
You can compile Lazarus to use GTK2.
oh, and Lazarus tries to copy the VCL and it really bugsme, they should have worked on a independent multiplatform style GUI like wxWidgets instead of trying to clone the VCL, don’t get me wrong, VCL is the best productivity toolkit around for Win32 programing, but is not really designed to be multiplatform (no, Kylix doesn’t count), it is more dessigned to work with the Windows API.
There is a project that is trying to make it possible:
http://sourceforge.net/projects/fpgui/
Edited 2007-09-10 17:24
That’s correct. fpGUI doesn’t try and be VCL compatible and talks directly to the underlying Windowing System. Which means any fpGUI based application has no dependencies on large 3rdParty libraries like GTK1 or GTK2 does. Which makes application deployment a breeze!
fpGUI now also has a Visual Form Designer to speed up your development.
Lazarus has years of experience of porting the VCL to GTK. It is suitable enough. The nice part is the ease that people can use the native widgetset (GDI,GTK,Carbon) to improve the (OS specific) behaviour of the app, and mix OS independant with dependant components.
This avoids a bit the “lowest common denomitor” problem that a portable widget set has.
I miss templates as well… TObject just doesn’t cut it.
Idiot. Templates are no replacement for Inheritance.
(psht! Don’t tell anyone!, there are generics beta in this release)
See the FPC wiki (when it is unslashdoted) for more info
Delphi uses anchors for sizeable dialogs. This feature has been introduced even before Delphi 7. BTW, .Net uses the same concept just with a different name (“dock”). This concept is really easy and powerful.
Oh wow, I didn’t know that. Thanks a lot.
> Delphi uses anchors for sizeable dialogs
Correct. It also has the “align” property, and has so since version 1. It is a bit unweildy (just as it can be with any resizable container that is aligned to a specific “area” of another container), but it’s workable.
> .Net uses the same concept just with a different name (“dock”).
Wrong. This is called “anchor” in dotNet. It works exactly as the Delphi version does too.
Yeah… because sizing logic is so hard to do, if automatically done for me, I will use something else…
Chode.
Are you saying “I don’t care because I can write sizing code myself”? What an elitist attitude. Just because I can doesn’t mean I should. Give me one good reason why I should waste my time on micromanaging coordinates instead of focusing on solving the problem.
Jesus christ. We are talking about ONE function to handle resize… “Textbox1.Width = ParentDialog.Width – 540; Textbox2.Left = ParentDialog..Width – 1060;” etc. Seriously. You java/.NET folks need to get your head out of your ass… System.devices.cdRecorders.burnISO.FromFile(…) (or whatever the f–k that does all the work for you) does not make you a good programmer. And we aren’t even talking about something complex like burning an ISO. We are talking ONE TO TWO LINES OF CODE IN THE ONRESIZE FOR EACH WIDGET YOU NEED TO HANDLE. And they aren’t even functions! Simple value assignment. Loser
What kind of non-font-sensitive, non-language-aware, hard-coded piece of shit as that?
If you do resize logic wrong, then yeah, it’s easy, but it’s 2007 — we’re getting past the point where you can give a wrong answer to a hard question just because it’s easier than giving the right answer. If you do layout _right_, it’s hard, and it’s something the toolkit better handle.
Edited 2007-09-11 01:59
What are you talking about here?
Lazarus has the BEST sizing attributes I have used in any widgetset/toolkit. It has both anchors and alignment and also a concept of “neighbors”.
You can do virtually anything with all 3. Just coz you don’t know shit about what you say doesn’t mean it’s not there.
+ the gtk style of “autolayouts” is 80s. It’s useless.
I have no idea what Lazarus does. I wasn’t talking about Lazarus. I was talking about WidgityWack’s post about manually writing resize methods, specifically the:
“Textbox1.Width = ParentDialog.Width – 540; Textbox2.Left = ParentDialog..Width – 1060;”
Yes sorry, the original post was below my threshold so I misunderstood. You’re right on that front, and as I said, Lazarus has GREAT positioning and autosizing capabilities which have not been surpassed yet by any other model I used. (Netbeans 6, MS stuff including C#/.NET, gtk2(yuck), Qt). The only major stuff I didn’t try yet is Cocoa/Carbon (which btw is the same thing in the bottom anyhow so macboys stop yelling “switch” on everyone) since I don’t have a Mac.
Uhm yeah, good for you. But I have 300 widgets. You still haven’t given me a good reason to waste my time on 300 lines of code (probably more, because some widget’s position depends on others, or depends on some conditions) instead of using that to solve a real problem.
As I said, an elitist attitude.
It’s not elitist, it’s just dumb. I see these sorts of “programmers” all the time. They think they’re better because they do grunt work that can easily be automated by the language/libraries, instead of doing real thinking to solve real problems.
There is a layout engine as memson describes in the VCL (and LCL) If you don’t know that, you obviously never seriously worked with it.
I wrote a commercial application in Delphi which is still being sold today, so you cannot really accuse me of not having “seriously” worked with it. None of the 3 Delphi books that I have, have ever mentioned the use of anchors.
The LCL and VCL gets around this with a feature called Anchors. The LCL’s anchors are a lot more flexible (better) than Delphi’s ones.
BTW: The fpGUI project also features Anchors and should have Layout Managers (like Java or Qt) real soon.
Nice to hear that the pascal language is still around….as it is my first real language I learned when taking introductory courses in programming.
Wanted to try it out n freeBSD but since I’m running a 64 bits os, I wasn’t able to install it. Hope they will deliver that version in the future, so I can experiment with it (what will I still know of that language….”-)
Actually the development version generates 64-bit FreeBSD binaries. Unfortunately 64-bit FreeBSD refuses to run them (probably some ELF header gotcha).
This has stalled the progress in this department.
You compare and IDE that does background compilation, automatic syntax checking that not only checks the syntax but also offers solutions to said errors (via QuickFix), and also provides pretty much everything a developer can need to develop software, with a pretty barebones IDE. Is it any surprise that one consumes more memory and appears more sluggish than the other? What has this got to do with evil *waves hands about* JIT?
Eclipse uses Java, a managed programing platform that uses tons of memory, that makes it slower, Lazarus use Free Pascal witch is native, is obvious that native is faster than managed, not need to complaine about it since both are good.
Edited 2007-09-10 18:00
You’re mistaken. Lazarus also does syntax checking, code-completion, has refactoring tools, context-sensitive help and tooltips. Further a debugger, two-way form editor, syntax highlighting offcourse snd you can add your own plugins. Everything a Pascal-programmer needs.
It only doesn’t do background compilation (it can do syntax-checking, though) because you don’t need that when all your program are compiled within a few seconds.
For those waiting for an updated port of FreePascal to OS4 and MOS, read here:
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?forum=9&t…
i’m looking at the progress of freepascal every now and than because i liked pascal very much, back in the old days. the problem nowadays is developing GUI applications for mac os.
in the article it says, that carbon is near complete – but carbon is outdated and it’s a question of time, till it’s obsolete. no one wants to use carbon applications today. so my question is: what about cocoa?
are there chances that cocoa will be supported somewhen? i’ve searched the internet on this topic but can’t find much.
Cocoa requires Objective C, dunno if there’s any way around that.
Carbon is considered deprecated by Apple.However not by the users, since it seems the main widgetset used on Mac. What do you think the Offices, Adobe Reader and the many Aquifications of X apps (like e.g. LyX)use?
Carbon is way full featured enough, and is better suited to be accessed from existing applications.
Cocoa is an application framework, not a pure widget set. Even to the language (admitted, you appear to be able to avoid Objective C, but it is harder)
Carbon being deprecated by Apple means the resources that go into advancing the entire OS X Platform are on the Cocoa front alone. The law of diminishing returns will soon see the Carbon stallwarts either jumping ship when the dinky is still available or not. Apple gave you guys a decade to move to Cocoa.
Lazarus does not yet have the polish of Delphi, but it can create nice cross-platform applications. The Windows applications are really very good. Linux relies on GTK1, and dependency issues make supportimg all distributions difficult. The OSX Carbon components have really progressed rapidly – you can create usuable OSX, Windows and Linux apps simply by recompiling to the target OS.
I actually think that the Carbon/Cocoa distinction is a bit silly – Lazarus allows a user to create good applications fast, and I really think Carbon is so useful it will be supported for a long time, e.g. see
http://unsanity.org/archives/mac_os_x/carbon_vs_cocoa.php
So your evidence for Cocoa being slow is a blog post from almost 5 years ago? Cocoa was a new API back then since Carbon has existed since OS 9 times. These days, most of the development on OS X is focused on Cocoa.
Lazarus can use GTK2 as well, but the dependency issue is still there. That is why the fpGUI project [http://opensoft.homeip.net/fpgui/] has been started. It talks directly to the underlying windowing systems (Xlib or GDI) so there is no dependency issues.
Edited 2007-09-11 08:00 UTC
Why is GTK2 dependency a problem? I don’t know any post-2004 Linux desktop system that doesn’t have GTK2 installed. I think it’s safe to say that 99% of Linux *desktop* systems have GTK2.
NO, not all distros come with GTK2. Kubuntu or any other KDE based distro doesn’t come with GTK1 or GTK2. A bare bones X Window system (Linux or FreeBSD) comes with some lightweight window manager. Normally not with Gnome or some other GTK2 base WM.
Also installing GTK2 afterwards is normally a pain. It’s not just a single package. It’s gtk, gtk-comon, gdk, pango etc… A lot of packages just to get a GTK2 app running. Then lets talk about different versions on GTK2. Distro’s are normally behind compared to the latest GTK2 version available, so your applications will have a hell of a time trying to run if it was designed with the latest GTK2.
Talking directly to XLib (like fpGUI does) removes all those problems! And your applications will run, no matter what lightweight or heavy WM you have installed.
Might be true for GTK1, but I am pretty sure every distribution ships GTK2 and Qt3, especially since the two are part of the library set specified by the LSB.
All distribution package managers do dependency resolution, don’t they?
No and no.
Gtk2 isn’t present on some KDE only distroes, and vice versa. Gtk1 is even worse.
And package management is sometimes manual (see slackware, they DO have a dependency check tool, but it’s not default IIRC).
But generally you’re right. Distributing gtk2/qt apps isn’t much of a problem in the “mainstream” linux desktop world.
Thank you. Glad somebody agrees.
Still doesn’t solve the library version issue. You create a Qt app using the latest version of Qt 4.3. No distro I know includes that version. I think they are still on v3.x because of KDE.
So my point still stands. Using XLib (or GDI) directly as in the case of fpGUI, resolves all kinds of redistribution issues. Being a ex-Kylix developer I know all about redistribution issues and wasn’t going to make that mistake again!
The point stands, but you get non-native look & feel if you use xlib/GDI. Don’t take me wrong, low dependencies are a strong point of FPC and it is only logical to extend this to the GUI. However, Lazarus with GTK2 uses real GTK2 widgets, Lazarus with Win32 uses real Win32 widgets, so it is close to the most native look and feel possible.
One nice thing about Lazarus is that one can choose, though. GTK1/GTK2/QT/Carbon or the dependency friendly fpGUI, you choose with the push of a button. No source code changes necessary.
I write commercial software for a living and that statement is so over rated these days (quoted from my clients). With very popular apps like MS Outlook, MS Office, Windows Media Player, Winamp etc and even Windows Vista that all look non-native, the users have no problems using them! As long as they kinda work the same. My employer who commission my work on fpGUI even said the great feature of fpGUI is that they can select themes (looks) to make their product stand out above all other Windows applications.
That is still only a dream and doesn’t work 100% as advertised. The support layers for the different widget sets are all at different levels of completion. We found using the LCL to develop cross-platform applications that needed to be consistant on all platfroms was a nightmare. Hence the reason we wrote our own widget set. The LCL is trying to catch a constantly moving target – the underlying toolkits are being developed at the same time as the LCL, plus they are trying to be Delphi/VCL compatible. Always playing catch-up! Make no mistake, I like the Lazarus IDE, I just have issues with the LCL!
“Gtk2 isn’t present on some KDE only distroes, and vice versa.”
Kubuntu might not install it by default (dunno, I never used Kubuntu) but it sure does provide GTK2. One can install it in literally one command. Ditto for SuSE, another KDE distro.
“Gtk1 is even worse.”
I don’t think anybody cares about GTK1 anymore. GTK2 has been out for about 7 years now, and also has a much nicer API.
“But generally you’re right. Distributing gtk2/qt apps isn’t much of a problem in the “mainstream” linux desktop world.”
If my app is a desktop application then I don’t want its development to be hindered by distros that aren’t serious about entering the mainstream desktop market.
I didn’t say all. I said most. And which distribution today doesn’t support automatic dependency resolution? If I type ‘apt-get install gtk2’ then APT will automatically install whatever extra dependencies it has. Even FreeBSD’s ports supports auto-installing dependencies.
I dare to say that if people refuse to install GTK in order to use your app, then your app is not worth installing anyway. Likewise, if a good app is written in QT, and I need that app, then I will make sure I have QT. I don’t care about the GNOME/KDE “war”. Even commercial apps like VMWare and BitRock Installer depend on GTK2 and they don’t seem to be losing customers because of that.
Sure, there are hardcore geeks out there that absolutely to refuse GTK/QT (note that I didn’t say GNOME/KDE) or other “bloat” because they’re running a Pentium 300 with 64 MB RAM (or just because of irrational elitism), but those people consist of, like, 1% of the market. I’d gladly trade that market share with the amount of development time I save by using a good GUI toolkit.
It’s a good thing to care about users and to minimize dependencies, but at some point there will be a point of diminishing returns. And I believe anything below GTK2/QT lies past that point.
“Distro’s are normally behind compared to the latest GTK2 version available, so your applications will have a hell of a time trying to run if it was designed with the latest GTK2.”
But what does that have to do with you, the developer? Just don’t use the most recent GTK APIs and stick to the subset of APIs that were introduced in GTK 2.4 or something. The GTK API docs specifically mention the version where an API is introduced.
Edited 2007-09-11 18:42
Well yes you’re right, but also wrong.
As was pointed out to me also, there’s versioning problems. For example Gtk has breakage between 2.0 and 2.8 regarding some functionality. Some functionality has been added. So if you compile for some Gtk2 version (eg: using SOME newer gtk2 functionality) you won’t work on distroes with older gtk2.
The thing is, Lazarus/LCL tries to be low with new gtk2 stuff but I think even they need 2.4+.
It’s much worse with Qt4. Since Qt is done in C++ anyone using non-C++ has to use a “C-Wrapper” lib. This lib is directly dependant on specific version of Qt4 (4.0, 4.1 etc.) so redistribution is next to impossible without recompilation (typical linux world), or carrying your own qt/gtk libs. But then you might fail on glibc (which breaks between eg: gcc4 and gcc2)
Shouldn’t be a problem, LSB 3.1 spezifies GTK in version 2.6
http://tinyurl.com/2seaeq
Since 4.1 includes the ABI of 4.0, anything linking against 4.0 should be able to resolve all symbols when linking against 4.1
Yes but not vice versa and that’s the problem
LSB is also a moving target. Too much moving. They will probably go to Gtk 2.8 or even 3.x (if such will happen) and then what.
I’m talking “forward” compatibility here, not backward.
Compiling on an ancient distro and distributing on new ones isn’t the problem here. Compiling on new and making it work on older ones is.
Eg: in windows, I can compile on windows XP and if I don’t use specific stuff (which by default LCL doesn’t), I can happily run it in windows 95.
The plan is, as far as I know, to include new things but not to remove old things at the same time, but rather deprecate them and remove them later.
There was pretty much a consensus on this topic at the last desktop architects meeting I attended.
Hmm, if you are just using symbol also available on the old system?
I mean applying the same rules you mentioned about development on Windows.
Not possible. GLibc for example has broken ABI.
“It’s much worse with Qt4. Since Qt is done in C++ anyone using non-C++ has to use a “C-Wrapper” lib. This lib is directly dependant on specific version of Qt4 (4.0, 4.1 etc.) so redistribution is next to impossible without recompilation (typical linux world), or carrying your own qt/gtk libs.”
C++ ABI is a PITA on linux, no question about it (I would say C++ is broken from a ABI point of view anyway). But otherwise, I don’t get your problems: breaking glibc between gcc2 and 4 is really not a problem, they are like what, ten years different ? Also, binary incompatibility also arise on windows (I got a problem recently with file descriptor not being compatible between slightly different MS C runtime).
I tended to think that binary compatibility was the major problem on linux, but maybe the problem really is shared library: http://www.sagecertification.org/publications/library/proceedings/u…
The “IDE” that the article refers too is about as close to an “IDE” as notepad. What a bunch of misleading garbage. I read the article thinking dang man they must have something like Netbeans or Eclipse and what do you get instead, a friggin DOS based piece of crap that looks like the same friggin 386 compiler I used back in 1993 for ADA. Pascal was my first language and as such I kind of have fond memories of it since it is so easy to learn. So I was really excited when I read this article thinking I may have found a good cross platform solution for developing some GUI utilities that I need. Come to find out after downloading and installing the “IDE” it was nothing more than a DOS looking (yes I am not kidding) DOS looking piece of software right out of the pre-Win95 days. And I totally agree with the post above by evangs, comparing this to Eclipse is a complete mis-representation of the facts. Eclipse, Netbeans, Visual Studio, and SharpDevelop are light years ahead of this dinosaur and there is no friggin way you can compare them with “Free Pascal”. So unless I am just not finding the right “IDE” on the Free Pascal website then this is a total joke and should not be considered a serious contender for any major development decision. If there is a real “IDE” for Free Pascal please post a reply with the location because I would love to see it.
I wouldn’t be very quick to judge an IDE just by it’s look. The OpenDylan IDE has a distinct Win95 look to it, but in many respects it’s more advanced than Eclipse or NetBeans (eg: full compiler integration). SLIME is a pre Win95-looking Emacs add-on, but it’s much more advanced than NetBeans or Eclipse in ways that matter.
I used Eclipse for a couple of projects over the period of a year, and I’m not very impressed. It’s basically got a lot of gimmicks to make up for two major weaknesses: no real integration with the compiler, and a language that requires lot’s of wizards and crap to get anything done.
That said, I’m not saying the FreePascal IDE is any better, but rather that you’d be surprised how a primitive-looking interface can hide a lot of powerful features, which show themselves only when you use the thing to write a lot of code.
Hi, the included IDE is actually not as bad as you make it sound. It is a clone of Borland Turbo Pascal’s IDE for DOS.
However, the IDE that was talked about in the article that can do RAD is called “Lazarus” and you can find it at http://lazarus.freepascal.org/
Lazarus really is a good IDE if you’ve used something like Delphi or the early versions of VB. It’s very comparable to those. It also can do cross platform applications just like stated in the article, it really is just a simple recompile away from another platform. I’m just not a huge fan of Pascal, but if I was I’d definitely be all about Free Pascal/Lazarus, the speed of the compiler is just absolutely amazing after having used hello-world-in-c++-takes-five-seconds-to-compile-on-a-dual-core
GCC. Not that it is a fair comparison since C++ is a very difficult language to compile.
Thanks for the link, I will check it out.. I figured there had to be something better than what I saw from the Free Pascal site. And as far as trying to compare the DOS version of Free Pascal to Netbeans or any other full featured GUI based IDE ( this is in response to the first guy who posted a response to my thread ) don’t even think about going there. I would love to see someone sit down and whip out a GUI in FPC DOS at the same time someone is whipping out the same GUI in Netbeans and lets just see who gets done first. Anyway thanks for the link.
I never was able to accomplish anything in netbeans, so I can easily take your word for it 🙂
Where did you learn to read pal?
The “RAD” IDE is called Lazarus from http://lazarus.freepascal.org
The textmode IDE ala TP is called fpIDE and is part of the free pascal package (and btw. most fpc devels still use that because it had better gdb support in windows).
In any case next time, before you put something down, please try to read properly.
Just in case somebody didn’t notice, Pixel image editor is written using mix of FreePascal, C and assembler: http://www.kanzelsberger.com
As I am planning to use FPC on a small Linux system (read no X) I would like to know if there is _any_ textual user interface (such as TechnoJock’s Object Toolkit) for FPC.
I know that FreeVision is “available” but I haven’t been able to find any kind of Pascal documentation for it, only a reference that the FPC’s IDE (not Lazareus) uses it.
Please post if you know anything.
Free Vision is a TP Turbo Vision clone.
There are some differences (most notably the “driver” part for kbd), but for the general framework, you can almost use the TP docs (and 3rd party books) verbatim.
And those are cheap :_)_
In the latest LinuxJournal magazine there is an interview about the developer behind the image editor Pixel, one of the main strength is that it is very portable.
http://www.kanzelsberger.com/pixel/?page_id=12
http://en.wikipedia.org/wiki/Pixel_image_editor
Another feature for which FPC rocks is it’s ability to generate code WITH GUI ELEMENTS (!!!!!!!) that can run on ARM based PDA’s and Smart Devices. I have used it in arm-wince based devices.
Neat, clean and without the tons of GB’s and setting mayhem that comes with MSVS.
Well, one fundamental problem with the Linux model of backward compatibility is that a binary compiled on an old system will work on a new system (if the programmers do their work properly), but a binary compiled on a new system does not run on an old system, due to symbol versioning.
This even happens if you don’t use any new functionality, i.e. your source would perfectly compile on the system.
On the other hand, a Win32 program compiled on Windows Vista can run on Windows 95 or even Win3.1+Win32s if no new functionality is used.
The result is that Windows sometimes may get a message “sorry, you need a newer Windows”, but Linux users are constantly upgrading their systems, or compiling packages by hand. This is also the reason why different binaries are needed per Linux distribution.
Hi im a newbie programmer and I would like to know if there are any good tutorials for free pascal / lazarus so i can start learning.
Thanks!
Yes, for example see: http://taoyue.com/tutorials/pascal/