You are browsing the archive for Free Pascal.

Open source project website

April 2, 2009 in .NET, Cocoa, Delphi, Elements, Free Pascal, Linux, Mac, Mono, MonoDevelop, RemObjects, Tools, Visual Studio, Windows, Xcode

For a while we’ve been looking for a good way of working with the open source projects we’re working on but never could find a good community website that was simple enough to install and maintain, but had all the features we needed.

So now we setup a simple website at http://code.remobjects.com for 3 projects:

  • ShineOn the delphi/Win32 compatibility library for Delphi Prism
  • Pascal Script the free script engine for Delphi
  • C# to Oxygene a new (unofficial) project I’ve been working on for a while to convert C# code to Oxygene.

Comments on the website appreciated, it’s not definitive yet but I like it so far.

Migrating from Delphi to Lazarus

September 9, 2008 in Delphi, Free Pascal, Linux

Not to me on time, even to this boring, but again I got a challenge on my shoulders is really difficult to meet.

The fact is migrating an application from Delphi to Lazarus is easy, by the way, but specifically this beautiful Delphi library im wornking on make a heavy use of Windows API messages…

Reviewing the steps to begin to migrate an application to Delphi Lazarus are very simple.

1) Create a new structure, independent of the one containing the Delphi application, so that you touches does not affect your Delphi application (is basic but very few do it).
2) For each Delphi project file (only for the dpr)

makepasx Proyect1.dpr

3) For each .pas file executes the following command

makepasx unit1.pas

4) For each delphi form execute this command

dfmtolfm unit1.dfm

5) Lazarus uses a resource file for each form, with extension lrs. To generate:

lazres unit1.lrs unit1.lfm lazres unit1.lrs unit1.lfm

Made. We already have everything we need to take the first step in our journey of 1000 miles (the more important).Now just compile and see what happens.

Usually some functions or calls vary somewhat between Delphi and Lazarus. It could put some of them here, but it makes no sense because they are many. Instead I will give you a way to resolve discrepancies in the simplest way, or by various methods that generally make me reach the correct result:

1) If you can not find an identifier or method just look in the sources references in the sources of Lazarus. Sounds silly? Is the simplest way, this way you can know that unit is defined and objects that use it.

2) If the identifier or method does not exist in lazarus, go to the forums Lazarus and looking for. Sure someone before you crash with that stone and found how to setp out ;)

3) If none of that works, the friend google comes to the rescue. You might try Lazarus discrepantname or add the word replacement, and so on.

Finally, as the case may happen in the library that attempt to migrate, that there are too many calls to the Windows API. In this case point 2 and 3 are generally much help.

4) Subscribe to groups Lazarus and fpc. Who better than those who have already been there can help you? Even if a feature is not suported they will help you to implement it and produce the miracle of Lazarus and fpc library get enriched. :)

In other deliveries i will comment about my progress in the conversion and as the problems were resolved.

Namaste.

Going from Delphi to FPC/Lazarus, my first steps

April 13, 2008 in Delphi, Free Pascal

After analize my options to migrate from win32 to linux some Object pascal projects, and under take little test i finally get the trip. My choice is to give a try to FPC/Lazarus. :)

I start migrating a server from Delphi/Win32 to FPC/Linux that weekend.

The first thing i do is get the latest beta version of RO/DA libraries for FPC and make it compile under lazarus. After a little work i have RO/DA in my lazarus palette. Happiness!

RemObjects SDK palette

RemObjectsinLazarus_Short

Data Abstracts palette

DataabstractinLazarus_Short

Next, i copy all my sources to a new folder, allowing to advance in my experiment with peace of mind. :)

Lazarus IDE have severals experts to do that help that job. One is the delphi project converter. I try that and the result was part of the project work and another forms complains about strange chars in several dfms , maybe because of the spanish language used in mostly of them.

So, i start the manual process. First converting DFM files to LFM files, and then editing all my units to make it FPC friendly.

The process is almost trivial, the main points you must have in account are:

1) Most of third parties components are delphi/windows related, so before start the process get out that libraries of
your code or you will have several headaches.
2) Activate Delphi mode in the project options. In my experience i also must do in the unit itself {$MODE delphi}
3) Add to your unit a def to change between LResources unit and windows unit. Example:

unit fServerForm;

{$ifdef FPC}
{$MODE delphi}
{$endif}

interface

uses
{$ifdef FPC}
LResources,
{$else}
windows,
{$endif}
uDAMemDataTable;

type

I put whenever i can defines.My idea is maintain a unique code base, merging that experiment with the project delphi codebase when work done.

4)Remove or embrace in ifdef the *.dfm line.

{$ifndef FPC}
{$R *.dfm}
{$endif}

5) If already no defined add initialization section including lrs files.

initialization
{$i aService_Impl.lrs}

6) Threading is a little diff,example;

{$ifdef FPC}
InitCriticalSection(aCriticalSection);
{$else}
InitializeCriticalSection(aCriticalSection);
{$endif}

TryEnterCriticalSection not implemented, use EnterCrticialSections instead.

{$IFDEF FPC}
DoneCriticalSection(aCriticalSection);
{$ELSE}
DeleteCriticalSection(aCriticalSection);
{$ENDIF}

7) Fomclose have slightly diff params.

{$ifdef FPC}
procedure TfmInputOutput.FormClose(Sender: TObject;
var CloseAction: TCloseAction);
{$else}
procedure TfmInputOutput.FormClose(Sender: TObject; var Action: TCloseAction);
{$endif}
begin
Poweroff;
end;

I think is invaluable the possibility of compile native servers, cross platforms using remobjects framework. Is worth the effort to make it works.
I love Delphi, but in the meantime, while codegears shareholders or anyone taking the path to other platforms give the needed step i will give a try to Lazarus.

What do you think? Is some of the several platforms offered by FPC a need for you in the short time?
I appreciate any comments.

Going from Windows only to anywhere with RemObjects.

June 10, 2007 in Data Abstract, Delphi, Free Pascal, Linux

My current challenge is to migrate a RemObjects SDK server working in Win32 Delphi/VCL to Linux.

I am analyzing the technology to use. A few months ago I had only one option: Chrome/Mono.
I am not displeased because I now have an additional option and, because of it, I am pleased with RemObjects. If there is something that defines the technologies that RemObjects offers, it is in giving options to the developer.

Provided that Remobjects’ next version named ‘Vinci’ brings support to Free Pascal Compiler, now I can choose to use this tecnology or Chrome/Mono.

The server to migrate is a RemObjects SDK server working 24x7x365. The tasks that it fulfills are sophisticated and are mission critical:

  • Control of industrial hardware in real time across serial ports (using Async 32).
  • Control of industrial hardware in real time across ethernet UDP (using Synapse with self build threading).
  • Remote access to information and business tier (RemObjects SDK / Data Abstract).
  • Visualization of objects used in the industrial control through RemObjects’ message tiers.

All that stuff is separated in own and shared tasks, with communication channels via RemObjects SDK version 4.

Stay tuned, I will present a report of my selection and the justification.

My first step will be to migrate from Remobjects Version 4 to VINCI, the new and exciting technology offered by RemObjects.

Meanwhile, I will cetainly listen to ideas. Open for discussion!

Profile photo of marc

by marc

Vinci Part #11 – Support for 64-bit and Linux through Free Pascal

May 22, 2007 in Data Abstract, Free Pascal

Over the past year, more and more developers have been asking for support for developing 64-bit applications, especially for the server side, where the new architecture brings many benefits, most importantly for access to more than 4GB of RAM and easier handing of large blocks of continuous memory.

While we have been supporting 64-bit development with the .NET editions of our products for some time, many users prefer writing native code, or want to more easily get their existing Delphi projects to the 64-bit platform without rewrite. And with a 64-bit Delphi compiler still being a distant glimmer on the horizon, the obvious choice was to open up our library for the Free Pascal Compiler (FPC), which, among many other platforms, supports 64-bit Windows.

With the first release of ‘Vinci’ this June, we are providing full FPC support for the core RemObjects SDK and Data Abstract libraries, supported on four platforms: 32-bit Windows (i.e. the same platform as supported through Delphi), 64-bit Windows, as well as 32- and 64-bit Linux on the x86 and x64 architectures.

As mentioned before, FPC supports a variety of additional platforms, most notably including Max OS X and Windows CE on the StrongARM CPU, and we will be investigating support for these and other platforms for the future, based on both work involved and customer demand.

What does “support for the core libraries” mean?
As you know, both the RemObjects SDK and Data Abstract are extensible frameworks that provide a wide variety of options. The SDK continues a large number of optional client and server channels, and Data Abstract supports somewhere around 10 to 15 Borland third-party database access layers.

When investigating FPC and cross-platform support, one thing that became obvious from the start was that not all these options would be feasible to port over. Some client and server channels, for example, are based on Indy, which at the time of writing doesn’t fully support FPC yet. The WinINet and named pipe channels rely heavily on Windows technology, so obviously won’t port to Linux. Similarly, most of the database drivers supported by Data Abstract are either tied to Delphi (ADO, DBX, BDE) or not officially supported for FPC by their vendors (most third party drivers).

What we concentrated on was updating the core library code of the SDK and Data Abstract for FPC and testing it on the platforms we decided to support. On top of that, we made sure that we support a reasonable subset of the channel and driver options, whether by getting existing implementations to work, or by providing new options.

Where channels are concerned, we found that we can support the popular WinINet client channel for FPC on the Windows platform. We’re also supporting the Synapse based client, the BPDX based servers, as well as the all-new Super HTTP Channel. This leaves FPC developers with a few less options than available on Delphi, but should cover all common scenarios. And obviously, FPC support will be a prime factor for all future channel development.

For data access drivers in Data Abstract, the situation looked a bit bleaker, as it turned out that virtually all the existing data access technologies were bound to Delphi and/or Win32. To solve this, we are providing a brand new driver (both for FPC and for Delphi) based on the popular ZEOS data access components. This driver supports a wide range of databases – including ADO (on Windows), Firebird, Interbase, MySQL, Oracle, PostgreSQL, SQLite, Sybase and more – covering pretty much all common data access needs on the supported platforms.

With these considerations in place, the June release of ‘Vinci’ should provide Delphi and FPC developers with everything they need to move their projects to Win64 or Linux. And of course, as always, full wire compatibility between all platforms is guaranteed, so your existing Win32 or .NET projects will communicate seamlessly with their Win64 or Linux counterparts.

What’s Coming Next?
Our development doesn’t stop here, and we’ll be moving forward with FPC support on several fronts. As mentioned before, we will be looking at supporting additional platforms, depending on customer demand and the effort involved in supporting and testing these platforms. In the future, we’ll also be looking into providing more product options that are compatible with FPC: more channels, more drivers.

Lastly, our current release focuses only on library support for FPC, allowing you to take existing code and recompile it using the Free Pascal compiler. In subsequent releases of the ‘Vinci’ product cycle, we’ll be looking at providing support for the Larazus IDE, as well as the upcoming CrossFPC IDE add-in for Delphi that is currently being developed by a third party.

What about Kylix?
As the Kylix project has been all both abandoned by Borland/CodeGear and not updated in several years, we are officially dropping support for Kylix with the ‘Vinci’ releases, in favor for FPC. In the past, the number of developers using our products with Kylix has been very small, and the effort involved with providing support for a development tool that hasn’t been maintained by its vendor for several years and has problems running on all current Linux distributions is simply not viable for us.

We strongly recommend all users using Kylix to consider FPC for their Linux/x86 development instead.

Vinci Part #7 – “Internet Pack” for Delphi

May 4, 2007 in Data Abstract, Delphi, Free Pascal, Linux, Mac, Windows

When we started working on the Super HTTP Channel for Delphi, we soon realized that none of the TCP/IP socket wrappers we currently use were a good idea for the server part of the channel, as Indy, Synapse and BPDX all use one thread per connection – which would amount to 2 thread per client and wouldn’t scale very well.

What we had to do is write our own socket wrapper that would work 100% async, like the .NET code does, and still would scale properly. Our new socket class uses Begin/End pairs for every method that would be blocking and accept a callback as a parameter for when the data was available, the connection accepted or the socket was ready to send data. The actual implementation uses the portable “select” call on 64 sockets at once, keeping the thread usage down quite a lot. On top of that we wrote our own simple Http server class, using only async callbacks.

We didn’t tie the Super HTTP Channel to this socket implementation, however, instead we wrote an abstract implementation and a subclass that implements it based on the async IP code. So it’s always possible to implement it on top of alternative HTTP server implementations.

We’re considering the async socket and http layer to be the first step towards an “Internet Pack for Delphi” – although will be treating is a part of the RemObjects SDK, for now.

Vinci Part #5 – Super HTTP Channel

April 28, 2007 in .NET, Delphi, Free Pascal, Linux, Mac, Mono, MonoDevelop, Visual Studio, Windows

One of the new features of RemObjects SDK for Delphi and .NET in version 5 will be the Super HTTP Channel. This channel is a variation on the regular HTTP channel but supports two way traffic like the Super TCP Channel. Because it uses HTTP, it works through HTTP proxies and strict firewalls, it does however cause slightly more traffic than the TCP version.

The new HTTP Channel allows you to send multiple requests without having to use multiple HTTP channels. It also makes it possible to send an event from the server to the client without having to explicitly poll for it. It works by using two connections at once, one for sending, the other for receiving.

As side-effect of the implementation for .NET, we have introduced a new “normal” HTTP server component in Internet Pack: AsyncHTTPServer. The Async HTTP Server uses Windows built in IO Completion Ports to handle requests, which uses less threads than the traditional blocking sockets model. Besides the Internet Pack based server, we also have an ASP.NET “Handler” and an http.sys async implementation.

DllMain Thread Deinitialization

October 5, 2006 in Delphi, Free Pascal

I came across an interesting issue with Windows dll loading/unloading capabilities. The issue is that Windows does not return from an EndThread/ExitThread/TerminateThread when DllMain is running until it’s done. This causes some interesting issues with the Delphi TThread class, which waits for the thread to be terminated to free it, so when a thread is freed from the finalization section of a unit in a dll, it will indefinitely wait. It’s not possible to use FreeOnTerminate instead and keep it running. This would leave the thread running in address space that doesn’t exist anymore.

There is no real workaround except changing the source code of TThread to stop waiting just before it reaches the ThreadProc’s EndThread or writing your own TThread class. In writing a solution for use in the RemObjects SDK we had several problems. Obviously we couldn’t change the Classes unit on every Delphi installation the ROSDK was installed. Another problem was that we support Delphi 6 and that doesn’t expose a static Synchronize method, so the class had to descend from TThread. We had to do, what I consider one of the worst hacks but it looked like it was the only way. We reintroduced WaitFor, implemented it so it would return right before the thread was calling ExitThread, using a Windows event. After that we introduced a method to wait for it to finish and free it so it mimicked the existing behavior of the TThread destructor.