Indy.Sockets (VCL) 

About

Bug List

Indy Core
Team Blogs

Knowledge
Base

Indy for FreeBSD and Linux

I discuss Indy support for FreeBSD and Linux.

I am pleased to report that earlier this week, I was able to help get Indy working on Linux and FreeBSD using FreePascal.  This is why I have not been blogging recently.

The way we support several platforms in Indy is that we make custom TIdStack descendants for every platform we support.   TIdStack provides a basic interface that is used by classes such as TIdSocketHandle through a global isntance object called GStack.  Since no operating-system specific code is permitted in most units and you have to at least use the GStack instance for most functionality, most Indy code should work properly assuming that your TIdStack descendant works.

For many native programs (not DotNET), we have a descendant class called TIdStackBSDBase which provides some lower level functions that sometimes take pointers.  We then derrive the native operating system class on this.   For FreePascal, we have a TIdStackUnix class that uses the standard system calls on most operating systems using the FreePascal sockets.pp unit.  We support FreeBSD with that and I also verified that it also works in Linux.  There also is the TIdStackLinux class that provides stack functionality using the libc API.  On Linux, you can choose between either interface by changing a compiler directive in the Inc/IdCompilerDefines.inc file.  The IdCompilerDefines.inc section looks like this now:

// FPC (2+)

{$IFDEF FPC}
  {$MODE Delphi}
  {$IFDEF UNIX}
     {$IFDEF LINUX}
        {$DEFINE USELIBC}       // linux can also usebaseunix
        {.$DEFINE USEBASEUNIX}
     {$ELSE}
        {$DEFINE USEBASEUNIX}
     {$ENDIF}
  {$ENDIF}

I now even have the Indy property and component editors now working in Lazarus.  

I have to be honest, I really am excited about having Indy 10 work with FreePascal because it opens up many possibilities that Kylix could not address properly.  Kylix does not seem to work well in many newer distributions (particularly ones using the kernel 2.6 series which has been widely used for 2 years).  Then Kylix programs never could be used properly on various chip architectures that the Linux Kernel supports.  

That's all for now.