[fpc-pascal]Synapse for FPC

[Marco van de Voort]

> > And the other way around. The main problem with Borland is that it only
> > supports one and a half platform on one processor.
> 
> Sure, but Borland is home for Synapse.

Also for FPC. See FPC as yet another Delphi version to support. If you
do a large Delphi product that will compile with a lot of versions, you
have to make adaptations also.

Porting always requires 
 
> FPC is only new playground for me now. Until FPC have comparable GUI
> based IDE with Borland's IDE, then I cannot use FPC for hard
> developing. ;-(

Lazarus is coming along nicely. But serverside use is also an option.
 
> FPC is new world for me. I do only first step to this world! yes,
> Synapse is not support lot of other platforms, but why? Because I am
> on begin of the way.

One of the strengths of FPC is that it can go where Borland tools can't.
Solaris, *BSD, BeOS, QNX and in the future also non-x86. Not tailoring for
that makes FPC use a bit pointless.

But changing a few things now and thinking about the way the code is sorted
over the diverse files might make future addition of platforms or Delphi
versions much simpler.

I'm thinking about 
- dividing stuff over files (units, includefiles), so that alternate 
	versions can be added for other os/processor/version/

> > > this is step back in features of Synapse. In old times it is used by this
> > > way. However now Synapse can use ANY socket library by dynamic loading.
> > How? How do I load FPC sockets unit, and avoid compiling in the non working
> > Linux kernel structuers in e.g. BSD?
> 
> I not mean pascal library, i mean system library. Under Win32 you can
> load any DLL with same interface as winsock. Under Linux you can load
> any '.so' file with same socket interface as libc. This is very
> important for me, because I need this in my some special commercial
> programs.

Aha, I'm slowly understanding what you are hinting at, and why there is 
the confusion.

Note that I am talking about all those defined types and constants in the
source, _NOT_ that you should use the actual functions in unit sockets.

You might also want to use some Unix typing in your prototypes (the procedure
variables), instead of just putting "integer" etc everywhere.

The types in unit socket and Unix describe nearly entirely that "same socket
interface" too, (it actually described the libc<-> kernel interface I think,
but the differences aer small) but on each platform has its own
implementation (under Linux/x86, the linux/x86 version, under PPC the
linux/ppc version, under FreeBSD the FreeBSD version etc)

> Of course, whn I go to platform without dynamic loading libraries,
> then I still can map my synsock to any static socket library. It is
> not a problem.

So this is not about the dyn-loading, but about defining the interface that
you link to. Static or shared.