Hello FPC community!

Today I release new version of my 'Ararat Synapse'. (rel. 32)

What it is?
'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix. Now it is for FreePascal too! It can be used for Wn32 systems and for Linux systems too.

Synapse is set of non-visual classes and procedures for TCP/IP programming. (IPv4 and IPv6 protocols is supported).

Additionally you can use my implementations of SMTP, POP3, IMAP4, SNMP, NTP, SNTP, DNS, Syslog, FTP, TFTP, HTTP or LDAP protocols. You can also use my MIME encoding and decoding engine, you can use my charset transcoding engine... and lot of more stuffs. ;-)

For more informations look to 'Ararat Synapse' web.

Why should we use your set of classes vs. another set of classes developer by person X ? :)

Just a friendly question, I know there are a lot of TCP/IP suites around...

cheers
James

That's clear I think. It works with FPC :-)

Just a friendly question, I know there are a lot of TCP/IP suites around...

Yes.

I've been cooperating to get it to work with FPC. It's one of the few suites that doesn't require threads and/or message pumps. So it was better suited to work with FPC, till we have sufficient support for threads and the like. (scheduled for 1.2)

Michael.

Why? It is not simple question. ;-)

Before a five years I need socket library for Delphi. In this time exists only two good libraries.. ICS (but it is using asynchronous sockets) and Winshoes (now it is called Indy). Yes, exists other libraries, but only this will be freeware and opensource!

For my purposes indy looks good. but it is components. You must do lot of things for install them to your system, etc. Indy is very huge and slow library. And on mostly places it is very badly written. ;-(

Rather then using it I wrote my own library based only on units with non- visual classes. It not need instalation, only add my unit to your 'uses' and go! When my fiend from Delphree association see my work, then tell me: "get your library for public, it is great!" Synapse was born!

By some years I create simple and fast implementation for lot of commonly used protocols. Synapse is not only one of TCP/IP libraries, this is technology leader. ;-) Yes, for example, Indy using lot of code based on my Synapse now! Synapse is first free and opensource library with solutions for email with automatic translating of charsets, Synapse is first free library with native SNMP implementation, Synapse is first free library with 'instant' IPv6 support, Synapse is first free library with native LDAP client, etc.

Yes 'First free' in delphi world! But on FPC world I not see comparable TCP/IP library. Really lot of people asking me: "Exists Synapse for FPC?"

FPC world now can use five years experience with Synapse from delphi world. ;-)

I've been cooperating to get it to work with FPC. It's one of the few suites that doesn't require threads and/or message pumps. So it was better suited to work with FPC, till we have sufficient support for threads and the like. (scheduled for 1.2)

Is it synchranous/blocking or asynchranous? TCP/IP without threads is an interesting idea, but I wouldn't like to have to use it. I don't see how it could be usable in a real life app.

TCP/IP is, by definition, only really suited to a multithreaded environment, otherwise one of two things happen. Your app blocks till it gets a packet and locks the GUI in the process, or your app has to do everything asynchronously and adds an order of magniture to the complexity of your event loop. You'll end up with the horrible mess that was Winsock on Win3.1x in the second scenario.

Mind, maybe I've just been spoilt by working on Windows and BeOS ;-)

Matt

Looking at Lukas' email, I will direct this at FPC and Michael's 'No thread' assertion. I see that Synapse itself is perfectly rational when concerning Multi Threading.

Matt

it

could be usable in a real life app. TCP/IP is, by definition, only really suited to a multithreaded

environment,

otherwise one of two things happen. Your app blocks till it gets a packet and locks the GUI in the process, or your app has to do everything asynchronously and adds an order of magniture to the complexity of your event loop. You'll end up with the horrible mess that was Winsock on

Win3.1x

You've convinced me :)

Thanks for creating this suite...

cheers
James

Good :) The more FPC stuff out there the better I say, it's a bloody beautifull compiler of a very nice old language!

cheers
James

I looked at the unit (mainly the synsock unit), and I see a Delphi project patched for Kylix, which is patched for FPC/Linux.

If you want to make it more generic (I think Solaris/*BSD/MacOSX should be possible long term), you need to clean up some things:

- Make a global include file, that stores things like FPC mode, and all the defines set in each unit.
- Move OS dependant things for a unit as synsock to include files or units.
- Separate everything under $IFDEF LINUX in real Linux stuff (like kernel structures, glibc base and derived types), and "unix" generic stuff.
- Try to get as many of these structures etc from generic units as Linux/Unix sockets etc.

Why would an alternate implementation be unloadable just because the built-in default one uses a few units?

Libc and Windows are also statically loaded, and I don't see any difference with the other units.

As far as I was told, this is explicitly not done, so an alternate TCP/IP implementation can be dynamically loaded.

Michael.

Is it synchranous/blocking or asynchranous? TCP/IP without threads is an interesting idea, but I wouldn't like to have to use it. I don't see how it could be usable in a real life app.

Synapse is blocking by default... but you can use it in non-blocking mode too.

It is greately usable for command-line programs or for visual programs where blocking operation is not a problem.

Threads you need only for visula programs with TCP/IP operations on background or when you need create multithreaded servers.

I looked at the unit (mainly the synsock unit), and I see a Delphi project patched for Kylix, which is patched for FPC/Linux.

In all library is very small 'IFDEFs' except synsock.pas. However lot of 'IFDEFS' is only for FPC incompatbility with Borlands compilers!

Current Synapse is not final state of my developing! This is not firts version and this is not last version. You not need learn me to programming. ;-) First I create working version and then I do optimalisations. For example, I plan rewrite synasock.pas to unit with common thinks and with two include files.. one for Win32 thinks and second for linux thinks. I rewrite dynamic loading stuffs (where is lot of incompatibilities in FPC) into form used in synassl.pas. Etc.

- Try to get as many of these structures etc from generic units as Linux/Unix sockets etc.

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. For example, you create your own socket library and synapse can call them instead Libc!

So was I. I just don't see why :-)

This is a mess. It might not even work on linux/ppc, let alone other unices.

Anyway, I saw that synapse needs FCL units that are win32/linux only like syncobj, so it is all a moot point.

I was of course just referring to your last point: i.e. the use of structures/calls from generic units as Winsock/Linux/Unix was explicitly avoided.

Michael.

And the other way around. The main problem with Borland is that it only supports one and a half platform on one processor.

If you want more than that, you'll have to use the (rather large) common subset between FPC and Borland, and design modularly to accomodate for changes. A bit of compromising. Not a Borland product with FPC compability bolted on, and not the other way around.

Current Synapse is not final state of my developing! This is not firts version and this is not last version.

Don't take it personally. It is meant as constructive criticism for the long run. However if you are aware of the issues it is easier to work in the direction

First I create working version and then I do optimalisations.

That's what I'm talking about too. But a working version on most FPC targets.

For example, I plan rewrite synasock.pas to unit with common thinks and with two include files.. one for Win32 thinks and second for linux thinks. I rewrite dynamic loading stuffs (where is lot of incompatibilities in FPC) into form used in synassl.pas. Etc.

Using a unit like dynlibs is the right way for that, you alraedy do that.

However with just win32 and Linux you are only halfway there. You have to differentiate Linux into
1) Unix and linux
2) x86 specific and not.

How? How do I load FPC sockets unit, and avoid compiling in the non working Linux kernel structuers in e.g. BSD?

For example, you create your own socket library and synapse can call them instead Libc!

I'd rather use the readily available one :-)

It is greately usable for command-line programs or for visual programs where blocking operation is not a problem.

Apps with a GUI will cause a problem, no matter what. I include programs that use TurboVision/FreeVision/NCurses et al for GUI. I work on a large app that is completely TCP/IP based (uses raw Delphi socket classes) so I have come to this conclusion through bitter experience!

It's pretty hard to use blocking sockets without multiple threads without your application halting whenever there is a request that takes a long time to respond.

I like your library though, and will look at using it in the future for small projects (e.g. just used Indy to add NTP services to our server.)

Matt

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.

I create Synapse primary for my programs. I am professional programmer and I create lot of commercial programs by my Synapse. This is reason why Borland is very important for me. Programming is not only compiler, but IDE too! I not see comparable IDE for FPC with Borlands IDE. ;-(

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. ;-(

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.

Don't take it personally. It is meant as constructive criticism for the long run. However if you are aware of the issues it is easier to work in the direction

Ok. For discussing about internals in Synapse you can use special email list called Synalist. :-)

> 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.
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.

It's pretty hard to use blocking sockets without multiple threads without your application halting whenever there is a request that takes a long time to respond.

yes, but... with other large TCP/IP libraries you MUST use threads... with synapse you CAN use threads. This is mojor difference! One day will be finished thread support in FPC and all will be happy. ;-)

LG> yes, but... with other large TCP/IP libraries you MUST use threads... LG> with synapse you CAN use threads. This is mojor difference! One day LG> will be finished thread support in FPC and all will be happy. ;-)

Why must I use threads?

Following works perfectly for me for many years:

ioctl(Sock,FIONBIO,@tmp); // nonblocking

All but one applications are single thread.

I'm using standard Socket/Bind/Listen/Accept/Connect socekt functions.

vtech

Because not exists non-blocking large TCP/IP library with lot of protocol implementations! Show me any comparable library with my Synapse or Indy, what is based on non-blocking sockets? I not know it!

Primary, you MUST NOT use Synapse! You CAN use Synapse, if you wish.

You can use your own non-blocking code. Or you can use non-blocking mode in Synapse too. (some of my customers using this!)

Well, where I get working version for Win32? On screenshot it looking very good, but I not see working lazarus on Win32. ;-(

I try to compile them from latest sources. Result? Lot of non-working functions, rest is very very slow... I try it and I not see it as usable. ;-(

When I see to latest voting on lazarus page, then I think, lot of people need lazarus for Win32... But lazarus Win32 binary downloads is empty. ;-(

See

http://www.lazarus.freepascal.org/

The IDE is VERY good. The editor is smarter than Borlands. The form designer is getting closer every day, but it is very usable.

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. ;-(

See above.

Michael.

:)
The IDE does only work under Linux, Free-, Net-, OpenBSD. Win32 support is progressing and any helping hand is welcome.

Mattias

I was of course referring to the Linux version :-)

This is correct.
The lazarus team needs people to help develop the win32 version.

The Linux version, on the other hand, is VERY usable.

Michael.

Why must I use threads?

You must use threads in blocking tcp/ip else you will hang your application everytime the network traffic slows or the application you connect to (server?) does not immediately respond. Try changing your calls to blocking and see what happens.

Yes. You are using the 'work around'. Traditional UNIX sockets block. Microsoft (and others) realised this would not work with a co-operative multitasking operating system (e.g. Windows 3.1, MacOS 9 and prior) and so the idea of non-blocking sockets was concieved. Indeed M$'s first Winsock implementations used purely Non-blocking sockets.

The tcp/ip developer has two avenues to wander down. Use threads and blocking api. It's fast and responsive and we only have to worry about sharing data between threads, or use non-blocking code and then have to work around the fact that tcp/ip can be slow and we will not get all my data in one big chunk. Using Non blocking sockets means that your code becomes more complex and convoluted because you may well have to go through the event look many hundreds of times before your download or upload has completed. Using multiple threads, you simple hand the data over to the thread when uploading and either carry on. Downloading you simply send a message to the main thread when the data is ready. It's also easy to simulate non-blocking sockets with blocking code using threads. This gives you a clear seperation between your tcp/ip mechanism and your application code. This is the route we usually take here.

Swings and roundabouts, I know ;-)

Matt

What is major problem in developing of WIN32 lazarus?

For example, I cannot help directly, because I must do my own opensource projects. (it is not only Synapse :-).) I not have time for study lazarus sources. But when some of lazarus developer isolate some WIN32 related problem like "how to do this on WIN32?", then lot of people (include me) can help with answer.

Maybe this is done in lazarus e-mail list, I don't know. ;-)

The Linux version, on the other hand, is VERY usable.

Great... but Win32 is very needed. ;-)

ME> Use threads and blocking api.

I have (almost) nothing against threads, but they definitely have disadvantages to, especially when used in a huge project:

1. synchronization - need to use critical sections / locks
2. they are very hard to debug and time dependant bugs can be introduced.
3. many libraries (general/graphic/sound/db/etc.) are NOT thread safe

That's why I prefer non-blocking single thread solutions.

vtech

ME> It's fast and responsive and we only have to worry about ME> sharing data between threads, or use non-blocking code and then have to work ME> around the fact that tcp/ip can be slow and we will not get all my data in ME> one big chunk. Using Non blocking sockets means that your code becomes more ME> complex and convoluted because you may well have to go through the event ME> look many hundreds of times before your download or upload has completed. ME> Using multiple threads, you simple hand the data over to the thread when ME> uploading and either carry on. Downloading you simply send a message to the ME> main thread when the data is ready. It's also easy to simulate non-blocking ME> sockets with blocking code using threads. This gives you a clear seperation ME> between your tcp/ip mechanism and your application code. This is the route ME> we usually take here.

ME> Swings and roundabouts, I know ;-)

ME> Matt

ME> _______________________________________________ ME> fpc-pascal maillist -
ME> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

> 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/

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.

Hmm, I think this is more due to the move to event driven programming models than cooperative multitasking.

The tcp/ip developer has two avenues to wander down.

The _GUI_ (Event driven) tcp/ip developper. Server processes can use select and fork mechanisms easily too, since network is its main event loop.

People.

Win32 developpers are numerous, but that includes RAD users, while we need RAD implementors.

So the good ones that are willing to work on open implementations (freeware/open source/pd) strangely are more rare on win32 than Linux.

This might become more important in the future. The main problem is a central figure that does a lot of the work. Recently Micha Nelissen started working seriously on win32/Lazarus, and it improved a lot in a few weeks.

> The Linux version, on the other hand, is VERY usable. Great... but Win32 is very needed. ;-)

Apparently not :_)

> 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.

But is is not easy! I create my code on Delphi3, and it working on all higher versions without any modification! It is same for Kylixes! I have only one version of sources, and this sources working under Kylix with very small modifications. It is very easy!

When I porting Synapse into FPC, then i find lot of incompatibilities between Win32FPC and LinuxFPC. For example, look to Kylix sysutils.pas... in FPC is not here lot of stuffs! Some stuffs is in another units, some stuffs is is very bad
situation for create programs for Delphi and FPC!

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

I know. I only not need this yet. That is all. And redesign of this huge library needs a time.

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.

When you ask me why I using my sockets definitions instead another one?

Because lot of delphi versions have this definition file different! It is strange, because then I must use lot of INDEFS. Additionally Borlands files not have IPv6 stuffs, it not supporting Winsock2 level properly, etc. I create my own definitions what working on all supported platforms and it create exactly same socket interface for all supported platforms.
(for example, It provide WSAStartp function for Linux platform. Socket developing on both platform is exacly same by my synsock.pas. ;-))

Hmm, I think this is more due to the move to event driven programming

models

than cooperative multitasking.

No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code without threads? It will block untill it receives the response. This *completely* stops the flow of the application, be it DOS, WinAPI, VCL, or some exotic home brew GUI toolkit. Now consider M$ Windows 3.1. It had no threaded capability and only very crude methods for yielding to other processes. This is the reason that M$ opted for non-blocking api, and the fact that it eased the event driven model was a bonus rather than a goal. If your app on Win3.1 didn't yield to other processes, you locked Windows. It wasn't common, but I do remember using Netscape 2 under Windows for Workgroups at University, and it was quite easy to lock the 3.11 when doing large downloads etc. This is why we all went to the Sparc labs ;-)

Matt

Strings.pp for example holds a lot of string related functions that really need to be in sysutils now.

This is a topic that has already been noted. I think it's a time related problem - the developers have no time to alter what they see as a perfectly normal layout. The problem is that the unit structure has changed between Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or invent it's own scheme. This is something I hope that 1.1 or 1.2 will address!!

I know. I only not need this yet. That is all. And redesign of this huge library needs a time.

I believe that FPC is in the wrong in many ways. FPC would be a lot easier to support if it stuck to a single Object Pascal target and dialect. This is also a point that I've brought up in the past.

As for TCP/IP implementations on differing platforms - surely providing a uniform interface for FPC would solve this (IIRC that was the idea) and this could then be wrapped into a Delphi alike interface for use by Synapse etc. Even better, without any alterations, I would hope that VCL style implementations would simple seamlessly compile using the wrapper.

Matt

They are shared.
What exists in as ansistring code in strings is also in sysutils.

We do not invent our own scheme:

We have TP units and Delphi units. The TP units are nearly perfect, because TP doesn't change any more. The Delphi units were started in the time that D3 was still the current version, but meanwhile D7 is out and D8 expected, and the units change sometimes wildly. We simply cannot keep up.

This is not correct. The TP object model/language is finished - again, because TP doesn't change. So we have no work on that any more.

Now, the Delphi language compatibility is being worked on. There the situation is more complex as Delphi itself still changes. What is more, there has been feature overlap: FPC had features that delphi didn't have, and vice versa. Borland seemed to take pleasure in implementing something that already existed in FPC in a different way in Delphi.

As for TCP/IP implementations on differing platforms - surely providing a uniform interface for FPC would solve this (IIRC that was the idea) and this could then be wrapped into a Delphi alike interface for use by Synapse etc.

It exists. See ssockets.pp in the FCL.

Even better, without any alterations, I would hope that VCL style implementations would simple seamlessly compile using the wrapper.

ICS of Francois Piette - with some minor patches - compiles using FPC. Synapse as well. The changes have been quite minor - even some potential bugs in Synapse were discovered and solved.

So finally, I don't think we're doing a bad job. We'll get there, slowly but surely.

Michael.

Yes.

It will block untill it receives the response. This completely* stops the *flow of the application, be it DOS, WinAPI, VCL, or some exotic home brew GUI toolkit.

But under Dos you would do simple polling, since the eventloop of your own. The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision, but the eventloop is under your control)

E.g.

repeat
  a:=select(...);   //block but maximal n msec.
  if (a) Then		// if a not timed out
   Event:=TranslateTCPIPEvent(A)
  else
   Event:=PollEventKeyBoardMouse();
  If Event=filled Then
    Dispatchevent(Event);
  {$ifdef Win31}
   ProcessMessages():
  {$endif}
until Event=quit;

While with most other OSes/toolkits the OS/toolkit has the eventloop, and you only provide callbacks and msghooks.

Now consider M$ Windows 3.1. It had no threaded capability and only very crude methods for yielding to other processes. This is the reason that M$ opted for non-blocking api, and the fact that it eased the event driven model was a bonus rather than a goal.

But TCP/IP and blocking/non-blocking existed before Windows (and probably will exist after). Maybe win3.1 that had some effect on the Windows api, but not on TCP/IP as a whole.

If your app on Win3.1 didn't yield to other processes, you locked Windows.

This means that your app can't be 100% blocking. However that doesn't mean you need to have threads. You app must deblock once every second or so and process messages/yield.

ICS suffers from the same (though relatively minor) problems as Synapse, Jedi's JCL have similar problems:

- Defines and ifdefs need a generic rework, Delphi versions IFDEF'ing need to be generalised. Not working directly on versions, but on capabilities. So in your actual source you should never directly test Delphi or Kylix values. Test that in a central include file, and then work with HAS_INTERFACES to encapsulate code that needs interfaces etc.
- Separation of OS platform and x86 dependant behaviour.
- That also affects the "uses" clauses a lot. Some of these packages import wintypes,winprocs (IIRC ICS because it is still D1 compat)
- Some functions typing need to be fixed.

So finally, I don't think we're doing a bad job. We'll get there, slowly but surely.

Certainly. The problem is that all of the above things are minor work if you are aware of these issues, and the source is gradually adapted along these lines while working on it (while working on normal revisions, e.g. for Kylix and Delphi)

They are a lot of work if you have to fix everything at once later on, to support FPC, or an additional FPC target, and that makes FPC look bad unnecessarily.

Nobody says a package should change in one day. FPC doesn't neither. E.g. FreeBSD support came only in, in 1.0.2, and see how far we have come with that in 1.0.10. The 1.1 branch (2.0 release in time) is even more important in that respect, since it will make the base units much more platform independant, with less hacks, so that generic wrappers can be easier implemented on top.

The important thing to remember is that making an inventory what's fundamentally wrong now, and then acting upon it in the long run is a really a lot less work then trying to fix everything at once.

So finally, I don't think we're doing a bad job. We'll get there, slowly but surely.

You're all doing a good job, I was just pointing out that these are not new issues.

> Strings.pp for example holds a lot of string related functions that

really

> need to be in sysutils now. They are shared. What exists in as ansistring code in strings is also in sysutils.

Why does this need to exist in two places? This is not helpful.

The truth is, I have no right to complain. I'm perfectly capable of using FPC as is. It's the people that come to you from other sources that seem to be confused (ex-TP people especially.)

Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe], fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see no real need for it. I made my opinion of the obj fpc made clear a long time ago ;-)

> This is a topic that has already been noted. I think it's a time related > problem - the developers have no time to alter what they see as a

perfectly

> normal layout. The problem is that the unit structure has changed

between

> Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or

invent

> it's own scheme. This is something I hope that 1.1 or 1.2 will address!! We do not invent our own scheme:

You don't follow the Borland one. This is therefre your own scheme. A mix between Delphi and TP.

LOL!!! I've been using Delphi since v1. This is a complete exageration. Between D2 and D5 the unit changes are minor. D6+ granted, there are a excess of new units, and some things change wildly, but in 90% of cases where new language features and routines are not being used, the *only* change needed is the removal of the 'variants' unit from the uses clause of D6+ projects. This is proven by the fact that Synapse Delphi examples are all Delphi 7 projects, and all I needed to do was accept the compaint from the IDE about properties not existing and remove 'Variants' to compile under D5.

You should aim for D5. Most large corperations are still using D5. We will not move to D7, we are waiting for D8 for the dotNET implementation. Even then, we will likely leave some of our legacy systems in D5.

As for language features. Borland got it right in many places that FPC didn't. Explicit overloading is an example of this. The only thing I see FPC has over Delphi still, is operator overloading. Even then I wonder if I really need that feature.

> > I know. I only not need this yet. That is all. And redesign of this > > huge library needs a time. > > I believe that FPC is in the wrong in many ways. FPC would be a lot

easier

> to support if it stuck to a single Object Pascal target and dialect.

This is

> also a point that I've brought up in the past. This is not correct. The TP object model/language is finished - again, because TP doesn't change. So we have no work on that any more.

I won't ask why TP is still supported because it will doubtless start a flamewar. I don't understand though. Have you looked in "Borland.public.turbopascal" recently? Not exactly the busiest community ever.

a

> uniform interface for FPC would solve this (IIRC that was the idea) and

this

> could then be wrapped into a Delphi alike interface for use by Synapse

etc.

It exists. See ssockets.pp in the FCL.

I assumed as much.

Matt

But under Dos you would do simple polling, since the eventloop of your

own.

The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision, but the eventloop is under your control)

Yes, but doing that in DOS was not trivial. Where as in UNIX it's just a fork away.

While with most other OSes/toolkits the OS/toolkit has the eventloop, and you only provide callbacks and msghooks.

Yes, but most other moder OS/Toolkits run on top of a mutitasking kernel. If you're lucky it's preemptive. That wasn't always the case.

> Now consider M$ Windows 3.1. It had no threaded capability and only very > crude methods for yielding to other processes. This is the reason that

M$

Never said M$ invented it. Just said that it came about on small OS (small as opposed to large commercial OS of the 70's like UNIX) because the OS as they were could not handle blocking TCP/IP.

> If your app on Win3.1 didn't yield to other processes, you locked

Windows.

This means that your app can't be 100% blocking. However that doesn't mean you need to have threads. You app must deblock once every second or so and process messages/yield.

Yes. This is how non-blocking api's work, in essence. Surely this is a circular argument?

Matt

Because strings already existed in TP.
Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils.

We _do_ follow Borland's one, just they have two schemes, separated in time.

We also have two schemes, but not separated in time.

Have a .

This is not 'minor'. e.g. all code setting these 'new' properties would have to be removed. For a small demo app, this is unlikely to happen, but in a large project with about 126.000 lines of implementation code, it can be painstaking...

But I agree that Borland tries to keep backward compatible. And rightly so.

You should aim for D5. Most large corperations are still using D5.

So do I.

This is highly a matter of taste and preference.

Explicit overloading is an example of this. The only thing I see FPC has over Delphi still, is operator overloading. Even then I wonder if I really need that feature.

You don't need overloading either, just as you don't need exceptions and classes and interfaces. This is a matter of taste...

Maybe so, but there are still a lot of old projects or code snippets that people made, and which can be compiled with FPC to be reused again.

The number of times that I get a message from someone thanking us that we keep fpc compiling TP code e.g. on linux is more than enough justification for keeping the different modes and language options.

But rest assured, I don't program TP code, I program Delphi code, as I think it is more 'right'.

Michael.

And does it work on lower versions without any modification? Otherwise you still don't support multiple versions.

It is same for Kylixes! I have only one version of sources, and this sources working under Kylix with very small modifications. It is very easy!

Hmm, I actually saw a lot of ifdef linux in synapse :-) More than ever will be needed for e.g. FPC/win32 :-)

When I porting Synapse into FPC, then i find lot of incompatibilities between Win32FPC and LinuxFPC. For example, look to Kylix sysutils.pas... in FPC is not here lot of stuffs!

Stuff that was there in D3? Don't forget that basically the _fixes_ (1.0.x) branch delphi compability is roughly D2-D4 level! (though michael added quite some later stuff from time to time from later 1.0.x versions)

Some stuffs is in another units, some stuffs is is very bad situation for create programs for Delphi and FPC!

If it is missing, and it is not because of it being somewhat platform dependant, it is because it is not implemented _for_ delphi mode yet.

Also keep in mind that FPC is aiming for much more platforms than Delphi ever will. That's a strength of FPC, but no strength comes without compromises.

FPC therefore can't work around certain issues that Borland still can. If you want FPC (and non win32 and linux targets) you will have to think about those issues. Adding features (including extra targets) always needs an investment, there is no free ride, exactly like that you often need to ifdef linux for Kylix too.

The FPC core team tries to minimalise this, but to fully take advantage of this, you have to adapt some of the mindset, and the minimalisation of work is meant to yield the solution that requires the least work _in the long run_.

We have no other choice, since we all have day jobs. We can't quickly invest a lot of time in some temporary work arounds, and sell you the next workaround as a new version next year like Borland can.

The attitude of a 3rd party library builder towards us simply has to be different. You are not our customer in the same way you are Borlands.

That has disadvantages (we can't make it always easy for you, e.g. if it hampers long time development, and fully commit ourselves to every hype-of-the-day, which is why there is no FPC.NET yet)

But there are also advantages:
- short communication lines. You talk directly to the developpers, and when reasonable, your fixes will be quickly absorbed.
- (useful for third party library creators) Most users use the most recent version, or the version before that, and usually upgrade within a year after a certain release. (1.0.2 usage is nihil, 1.0.4 low) Simply because they don't have to _buy_ the upgrade, and we don't support more than one or two (two if there is a major version difference) versions.
- We design FPC so that your codebase will be high quality long term, not just to convince you to upgrade to the next version quickly.

I think at the time we are at the second release of the 1.1 branch, (so 2.0.2 or so) most of the growth will have happened, and our lagging behind will end for the base libraries (RTL, FCL etc). But we will have that on a lot of systems and architectures.

Some of this might sound negative towards Borland. It isn't meant to. It's Borlands business model, and you essentially pay them to adapt and tackle such issues quickly.

Good. That's an important realisation. All my criticism is meant long-term. I compiled a lot of Delphi stuff with FPC, mainly to test the 1.1.x compiler compability (ICS, Decal, Jedi win32 headers, Jedi JCL, and some more), and the issues are always the same.

So try to grasp the mindset of the combination of multi-platform FPC development and Delphi, and then try to slowly morph to that vision, simply by making changes from time to time, and if you have to revise a particular part of the code, revise it so that it is more compatible with FPC.

I'd aim for convergence near the time when we are starting to finalise the 1.1.x branch for release.

I wouldn't spend to much time achieving compability with 1.0.x, since a lot will change in 1.1. However the basic principles of making a source somewhat compiler, processor and OS agnostic and building a infrastructure for that are universal.

All operating systems also have this different (and the same operating system on a different processor usually counts as "different", you often can't do without ifdef or special design). Think about a number of 20 here. You can't ifdef forever, sometimes you have to revise the concept structurally.

... Or give up everything except Linux and win32 now, and in the forseeable future.

It is strange, because then I must use lot of INDEFS.

.... because that would mean each item ifdef'ed another 20 times. Or at least once for each added platform.

Additionally Borlands files not have IPv6 stuffs, it not supporting Winsock2 level properly, etc.

You now only combine FPC/Linux and Kylix on one side and Delphi (+versions) and FPC/Win32 on another side. So basically two versions with each some additional internal ifdefs maybe. Adding any other FPC/platform means extra ifdef and extra constants etc. (though they'll generally they'll be close to linux, it will still be a lot, and everytime you add a platform, you have to review and test every issue)

I'd suggest to leave the combination of win32 and Delphi intact. FPC's win32api can better be brought in sync with Delphi's in time, there is not much reason not to. I would move it to use includefiles to make readability of the synsock file a bit better.

However for the non win32 platforms the situation is different. With some work, (needed changes to the sockets units could be absorbed back into fpc, as much as possible), you can base all non-win32 unixy platforms on one sockets unit. If there are ifdefs, they'll probably be on the FPC side, or for really exotic OSes, not the avg unix.

That means three choices, "win32 combined", Kylix and "FPC sockets based except win32" instead of two.

That's only one more case, but a potential for a _lot_ more possible platforms.

Because strings already existed in TP. Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils.

You only therfore need sysutils, *or* the old scheme. Not both. I understand why this was done by Borland. Legacy is hard to break, and D1 broke with legacy.

> You don't follow the Borland one. This is therefre your own scheme. A

mix

> between Delphi and TP. We _do_ follow Borland's one, just they have two schemes, separated in

time.

We also have two schemes, but not separated in time.

And therefore your own scheme. It's not the current, nor the old, but a hybrid on the Windows platform, and on the Linux/BSD platform I expect you *do* have some of your own scheme in place, I have never looked.

> LOL!!! I've been using Delphi since v1. This is a complete exageration. > Between D2 and D5 the unit changes are minor. Have a truth is, I have ported extermely large apps from D1 to Delphi 3 and 4.

There is no significant problem, so long as you didn't do nasty hacky things with the implementation of TTable etc.

Class hierarchies have changed, but this should and does not matter. The code, so long as it does not break any rules, still compiles. D1 was the biggest DB change, and D1 apps are fairly trivial to convert to D3, so long as you respect the language features that have changed. From D2 to D5 is pretty straight froward too.

This is not 'minor'. e.g. all code setting these 'new' properties would

have

to be removed. For a small demo app, this is unlikely to happen, but in a large project with about 126.000 lines of implementation code, it can be painstaking...

The IDE will remove all unknown properties from the DFM when streaming it in. The rest is accademical. Most properties that have been introduced are to do with support for unicode and bidirectional languages. Borland are very good at not adding nasty additional features. It's thrid parties that usually excel at that.

But I agree that Borland tries to keep backward compatible. And rightly so.

If you mainly use native Borland VCL components, the transistion from D2 to D5 is fairly trivial. The migration from D7 back to D5 is also trivial, although you will run into incompatibilities due to language features that have been added (the new $if and enum types that allow indexes to be specified being two that crop up frequently.) I've ported Dave Jewels GDI+ examples from the Delphi Magazine to Delphi 5, and he uses just about every new feature he can find. That was pretty trivial.

Sure. Overloading should be used sparingly (as James Mills proved last week.)

Exceptions are needed. Classes are needed. Interfaces are usefull. Not my taste, just a fact. They are too well established not to argue on.

Maybe so, but there are still a lot of old projects or code snippets that people made, and which can be compiled with FPC to be reused again.

Any many more that do not work due to the flat 32bit memory architecture. That's a bit like saying "I can use COBOL.Net to compile my old mainframe apps for Windows." Maybe even like saying "I can recompile my old VB6 apps in VB.Net." ;-)

The number of times that I get a message from someone thanking us that we keep fpc compiling TP code e.g. on linux is more than enough justification for keeping the different modes and language options.

Sure. But you could create a 'TP' branch of the compiler, remove it from the main compiler soure tree and leave it for the legacy peeps. If you got the seperation right, you could still share sections of the engine, just not the code parser and such. This would then focus FPC on the here and now, and you could remove the legacy from the unit tree.

But rest assured, I don't program TP code, I program Delphi code, as I think it is more 'right'.

You got my vote ;-)

Matt

Delphi 1 would be unlikely. Delphi 2 was an awful compiler, (roughly a hacked Delphi 1 that supported 32bit development, but through partial emulation iirc) and was never really used by a lot of hardcore dev's. Delphi 3 is regarded as the lowest common denominator by most Delphi programmers these days.

Matt Emson wrote

You only therfore need sysutils, *or* the old scheme. Not both.

You do need both if you advertise both TP and Delphi compatibility.

Jonas

[some minor remarks]

Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe], fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see no real need for it. I made my opinion of the obj fpc made clear a long time ago ;-)

Opinions differ. But the IDE and parts of the compiler itself are TP.

If we had a lot of hard working people, we could make a nice new set of platform dependant units, and more and more TP units would become legacy.

Do you volunteer?

We do in general. But 1.0.x is frozen, and we have to make adjustments for the fact that we have a strict visual<-> non visual separation, and a lot more platforms (and processors in the near future).

Giving that up is no option. It is the main edge that FPC has over Borland, except the doubtful one that it is free.

This is therefre your own scheme. A mix between Delphi and TP.

No it isn't. It is roughly a superset of Delphi and TP, so also a superset over Borlands scheme.

So ansistrings, widestrings, dynamic arrays etc changes are minor?

How many differences are there inside the core units (like sysutils) compared to e.g. D3? What are the deviances of FPC except adding a few extra units, and putting some platform dependant stuff in extra units?

D6+ granted, there are a excess of new units, and some things change wildly, but in 90% of cases where new language features and routines are not being used, the *only* change needed is the removal of the 'variants' unit from the uses clause of D6+ projects.

Try to compile something from Jedi. They still support D5, but I sometimes wonder how long. FPC is still getting more compatible to newer Delphi's fast, I don't really see the problem.

This is proven by the fact that Synapse Delphi examples are all Delphi 7 projects, and all I needed to do was accept the compaint from the IDE about properties not existing and remove 'Variants' to compile under D5.

The synapse author already said in this thread that Synapse is a suite that already exists for a couple of Delphi versions.

You should aim for D5. Most large corperations are still using D5. We will not move to D7, we are waiting for D8 for the dotNET implementation. Even then, we will likely leave some of our legacy systems in D5.

This is not common IMHO. While in my surroundings there are indeed a lot of people/companies that don't upgrade, I don't see a firm separation somewhere between D5 and D6+.

As for language features. Borland got it right in many places that FPC didn't. Explicit overloading is an example of this. The only thing I see FPC has over Delphi still, is operator overloading. Even then I wonder if I really need that feature.

I don't understand all this. Sure, FPC is lagging behind in features, but "Borland got it right in many places that FPC didn't". Where does this come from?

Simple. We are not a major vendor, but providing a suite for a certain niche (roughly people with Borland affinities and demands that are not met by Borlands current product lines. Think portability, legacy, total access to source including compiler etc, e.g. because of embedded world). That and the Open Source price advantage are our only plusses over Borland.

So if it is a from a worldwide IT perspective, it doesn't have to be a niche for us. We are already a niche :-)

There are of course also historical reasons. The compiler is already Delphi compatible

The only way to improve the situation is more collaborators, and/or a much higher users that e.g. occasionally does some work for FPC (update a certain unit, make an interface etc). The situation nowadays is already much better than it used to though say a few years back, on the other hand, there is a lot more to do nowadays too.

Use aliases for sysutils. That or aliases in Delphi mode for strings, dos etc.

Matt

Matt Emson wrote

Use aliases for sysutils. That or aliases in Delphi mode for strings, dos etc.

That's kind of hard to do if you don't support aliases yet. We may support them now, but we most certainly did not support them when those units were written.

Jonas

In reply to your message of July 23, 2003

If we had a lot of hard working people, we could make a nice new set of platform dependant units, and more and more TP units would become legacy.

This is a truly interesting discussion, I hope you don't mind a few comments from someone who's just now re-joining the programming game, as retirement approaches...

On the subject of Strings and on a strictly personal note:

I would prefer a language that is tightly integrated with an OS... so tightly that OS calls and language calls fit together in one smooth flow. I should not have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to get things to work. OS calls should be so seamless as to appear to be part of the language, not part of yet another complex bag of tricks that has to be studied and understood.

I'm not saying you should mask API calls to make them look like Pascal syntax. Just the opposite, I'm thinking it might be better to bend Pascal to work better with the OS... Make it natively work with null terminated strings in windows, give it the same numerical structures as BEOS, support LINUX file handling in Pascal's normal file handlers, etc.

Source code portability is a wonderful idea, but not at the expense of speed or power in the language. As a one time professional software developer, I'd rather write highly specific code that works flawlessly than have to mangle and mask things to get stuff to work. I do understand the need for cross-platform developement, especially with Linux nipping at Window's heels these days... but I would rather have to run a source code converter program once to switch platforms than to always run string, math and file converters on the platform I'm using...

Just my 2 cents worth...

-----
L D Blake

> But is is not easy! I create my code on Delphi3, and it working on > all higher versions without any modification! And does it work on lower versions without any modification? Otherwise you still don't support multiple versions.

what? I support Delphi 3, 4, 5, 6 and 7... is is not multiple versions? And for this support I not need any IFDEFS!

I maybe also supports Delphi 2, but I not tested this for long time, I cannot confirm this. I cannot support Delphi 1, because delphi 1 is for ANOTHER operating system platform. (It is for Win16, not for Win32!)

Look to this deeply. Lot of LINUX IFDEFS is for FPC! Otherwise LINUX IFDEFS is in synsock.pas, because this unit hides platform differents on sockets for rest of my library. Other IFDEFS is minor!

(and this is for huge platform differents, for example: Linux compute checksum of ICMPv6, but under Windows must compute by your hands...etc. Sorry, but create special library for platform independent ICMPv6 checksum computing is not right way.. it only create tons of other units... ;-()

I know, some stuffs from newer versions is added by my requests. ;-)))
But when I porting Synapse to FPC, I found lot of incompatibilities with my D3 (and with all higher versiopns of Delphi too!)...

For little example: On Delphi workd exists structure TSystemTime. Thjis is defined in Windows.pas, and all related time functions on delphi using this structure. For example, lot of functions inside sysutils.pas. it allows get system time by Win32 API call and then you can handle returned value by lot of functions in Sysutils.pas. This is great...

Now Look to FPC: windows.pas have one TSystemTime record... and sysutils using another TSystemTime structure. Two different structures with same name! Now I must get system time by API call, I must CONVERT IT to another structure... and then I can continue.

All this and similar problems is reported by me to Michael. He really very help me with porting of Synapse by adding lot of stuffs, what is missing and I need it.

Also keep in mind that FPC is aiming for much more platforms than Delphi ever will. That's a strength of FPC, but no strength comes without compromises.

I know, it is not easy.

here is tw ways, and both is needed:

1. easy to create multipltforms programs. You need lot of platform independent units.

2. but someone not need multiplatform compatibility, they need use existing code from delphi. For delphi exists very lot of code, Delphi is biggest pascal community on world, I think.

I say, multiplatform compatibility is important, but compatibility with delphi is important too! Maximum compatbility with Delphi is very strategic.

We have no other choice, since we all have day jobs.

[...]
I know, you not need taling me about hard live in opensource community. I am opensource developer too, I have same problems as you. ;-)

[...]

I'd suggest to leave the combination of win32 and Delphi intact. FPC's win32api can better be brought in sync with Delphi's in time, there is not much reason not to. I would move it to use includefiles to make readability of the synsock file a bit better.

As I say here before, I PLAN to rewrite my synsock! You not need convincing me aboyt thinks what I know. ;-) I only explain here, why it is not yet rewrited.

That's indeed a problem but there is no solution which works in all cases if you want multiplatform developemt. At least 1.1 allows type aliasing which causes problems in 1.0.x. But there are also some "strategic reasons" why 1.0.x isn't very much compatible with Delphi: the goal for 1.0.x was a 32 bit compiler understanding the subset defined by Turbo Pascal of object pascal. It was planned to achieve Delphi compatiblity as far as possible but if there was a choice between stability of the compiler and delphi compatibility we prefered stability, that's why 1.0.x doesn't have e.g. interfaces or multi threading support. For 2.0, i.e. the 1.1 development branch which will become 2.0, the goal is to compile as much as possible delphi code without changes.

I would prefer a language that is tightly integrated with an OS... so

tightly

that OS calls and language calls fit together in one smooth flow. I should

not

have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to

get

things to work. OS calls should be so seamless as to appear to be part of

the

language, not part of yet another complex bag of tricks that has to be

studied

and understood.

In most cases, casting an ansistring as pchar will work. The only caveat is when Windows wants to alter the variable you pass' contenets.

e.g.
       MessageBox( pchar(MyMessage), 'test', MB_OK);

but not:

      GetUserName( pchar(Username), 255 );  //error!!!

instead:

var
  Username: array[0..255] or char;
begin
  GetUserName( Username, 255 );  //This works!!
end;

This, however, is how Delphi does it, so you may find that your mileage varies. For example, the second GetUserName example my require an '@Username' param.

I'm not saying you should mask API calls to make them look like Pascal

syntax.

Just the opposite, I'm thinking it might be better to bend Pascal to work better with the OS... Make it natively work with null terminated strings

in

windows, give it the same numerical structures as BEOS, support LINUX file handling in Pascal's normal file handlers, etc.

Most OS have similar concepts; they just accomplish things in different ways (e.g. Linux devices are all file descriptors, but BeOS devices are almost all file descriptors, and Windows Devices are not.) Wrapping up the differences is the smart way of making sure your skills are transferable.

Matt

[ Charset ISO-8859-1 unsupported, converting... ]

What about

var username:AnsiString;
begin
 SetLength(Username,255);
 GetUserName( pchar(Username), 255 );
 Setlength(username,strlen(pchar(username));
end

Or does that mess up reference counts?

Started a new thread because this is all getting off topic from Synapse.

Opinions differ. But the IDE and parts of the compiler itself are TP.

Are there any plans to change this in future development? I, for one, like the idea of comiling the compiler in Delphi, but TP features are no longer supported. They are classes as legacy, and have many bugs in D3 let alone D5+.

If we had a lot of hard working people, we could make a nice new set of platform dependant units, and more and more TP units would become legacy. Do you volunteer?

To create a more rational unit set? Possibly, but last time I looked at the way in which FPC creates units, the scheme was awfull. You used a generic frame and {$i xxx.inc} for the platform. This is unmaintainable imho. One thing I like from the Borland Source is that I can easily read it. If I was to think about doing this I'd insist that the inc files went and that the units are assembled by concatenating a PROCESSOR_PLAFFORM_UNITNAME.INF and PROCESSOR_PLATFORM_UNITNAME.IMP together into a unit with a tool (sed?) using a script. This way the units are kept seperated as you currenlty have them, until realease, but at release you end up with a final unit that is similar in layout to Borlands.

It's something I'd like to do, but I have a few things that I need to finish first. Certainly when the PPC port is stable, I want to port it to BeOS ppc. This may be a juncture to thing about contributing more time.

We do in general. But 1.0.x is frozen, and we have to make adjustments for the fact that we have a strict visual<-> non visual separation, and a lot more platforms (and processors in the near future).

I think that, so long as you break all code into chunks that exist as Interface and Implementation (as mentioned above) then install routie could construct TP, Delphi or Wang doodle units structures. The unit construction script (a makefile maybe? ) would simple have a rule for each unit, and be driven by the 'platform' you select and the 'target processor' and 'programming environment'. Please stop me if anyone hates this idea. This is what I envisioned the future structure to be though.

No it isn't. It is roughly a superset of Delphi and TP, so also a superset over Borlands scheme.

It's more a subset of Delphi and the majority of TP merged to create a Superset over Borland's shemes. This is therefore your own design, be it unintentional or not. Let's not argue this point anymore.

> LOL!!! I've been using Delphi since v1. This is a complete exageration. > Between D2 and D5 the unit changes are minor. So ansistrings, widestrings, dynamic arrays etc changes are minor?

Unless you use widestrings, nope, no difference. Unless you use dynamic arrays, nope no diffewrence. Remember, we spoke of D3 -> D5, and D7 -> D5, *not* D7 -> D3.

How many differences are there inside the core units (like sysutils) compared to e.g. D3? What are the deviances of FPC except adding a few

extra

units, and putting some platform dependant stuff in extra units?

Not for mainstream, regular features.

Try to compile something from Jedi. They still support D5, but I sometimes wonder how long. FPC is still getting more compatible to newer Delphi's fast, I don't really see the problem.

The main problem with Jedi is the fast car syndrome. "My car is fast, I must use it at full speed."

> You should aim for D5. Most large corperations are still using D5. We

will

> not move to D7, we are waiting for D8 for the dotNET implementation.

Even

> then, we will likely leave some of our legacy systems in D5. This is not common IMHO. While in my surroundings there are indeed a lot

of

people/companies that don't upgrade, I don't see a firm separation

somewhere

between D5 and D6+.

Most people are waiting for D8 now if they are still using D5 because D6 and D7 have been such turkeys. Two guys in a shed don't constitute enough developers anymore, so hopefully Borland have improved this situation ;-)

I don't understand all this. Sure, FPC is lagging behind in features, but "Borland got it right in many places that FPC didn't". Where does this

come

from?

One of the main feature that FPC does in a way I find poor is oveloading of proc's. Not sure if you support the Borland method now, but still annoying. Also annoying how you are stricted with regards to assignment of pointers. I remember that an additional cast used to be needed when setting up a tagWNDCLASSEX for example. The lpfnWndProc field needed to be cast and dereferenced, unlike Delphi. This made it necessary to use an ifdef for no good reason! Maybe this is fixed now, but it was amazingly annoying. It cropped up in other areas too.

The only way to improve the situation is more collaborators, and/or a much higher users that e.g. occasionally does some work for FPC (update a

certain

unit, make an interface etc). The situation nowadays is already much

better

than it used to though say a few years back, on the other hand, there is a lot more to do nowadays too.

My main problem is that everytime I go to look at the compiler source, I can't get it to compile, even though I can't see a reason why. I had the BeOS port compiling fine, but I rehashed the dir structure. Maybe I'll have another look. I want to make a plugin that uses the Delphi IDE to edit FPC source and lets you compile from the IDE too. Maybe I'll do that sometime soon.

Matt

100% platform independance is indeed often counter-productive. However that isn't a good reason to don't do anything platform independant at all:-)

This sucks big time.

I'm stuck with half a windows api on non windows platforms.

Now Look to FPC: windows.pas have one TSystemTime record... and sysutils using another TSystemTime structure. Two different structures with same name! Now I must get system time by API call, I must CONVERT IT to another structure... and then I can continue.

Yes. The solution is not to mix platform dependant and independant programming, and only use platform dependant calls if strictly necessary.

IOW, use a solution in sysutils that is platform agnostic to get the time.

All this and similar problems is reported by me to Michael. He really very help me with porting of Synapse by adding lot of stuffs, what is missing and I need it.

But I don't think the platform dependant issues like this should be "fixed", but Michael probably agrees with that.

The solution I choose. However it takes time.

2. but someone not need multiplatform compatibility, they need use existing code from delphi. For delphi exists very lot of code, Delphi is biggest pascal community on world, I think.

Yes. But most of the people using FPC use the multiplatform compability, except some educational users. It's FPC's main strength. Most of the Delphi code is copyrighted VCL dependant anyway, so can't be used without modifications.

I say, multiplatform compatibility is important, but compatibility with delphi is important too! Maximum compatbility with Delphi is very strategic.

That's why we strive for both. But the multiplatform issue has priority if those two interests collide. At least in most cases.

FPC may let you do that, but Delphi will have an error about not passing const params iirc. That or the result is garbage back from Windows.

Matt

100% platform independance is indeed often counter-productive. However that isn't a good reason to don't do anything platform independant at all:-)

But I create tool for programmers and I hide all platform differencies in my tool. By my tool other programmers must not resolve any platform depending thinks in their socket programming. What is bad on this? :-O

Fine.. but borland using sysutils unit as platform independent. In this unit is lot of functions what hiding differencies between Linux and Win32. By this Borlands programmers using this and similar units as platform independent wrappers. I not need to mix platform dependant and independent code, because I am using independent code! All platform depended thinks is hidden inside this units...I can very easy to create programs what running fine on Delphi and kylix.

Now I try to port this my code to FPC. What is this? lot of functions in Syutils is missing! Well, lot of this functions is in another units.. and some of this functions have different names... I have platform independent code, but I must do lot of IFDEFS for FPC! This IFDEFS is not for platform independency, this is for incompatibility with Borland! ;-(

Mostly all FPC based IFDEFS in Synapse is for result similar incompatibility problems.

Maybe most of the current people. ;-) How large is FPC community? How large is Dephi community? How many third-party code is available for Delphi? How many is available for FPC? How many programs is created and used by FCP... how many is created by Delphi?

How many costs FPC? Nothing! But Delphi is very expensive. When you can be better compatible with Delphi, then you get access to lot of code (by third-party without Borland copyrights!). When you can get FPC as replacement of delphi, then you can get lot of new programmers, lot of new code, lot of new programs...

That's why we strive for both. But the multiplatform issue has priority if those two interests collide. At least in most cases.

All problems have their results! It must not to be 100 compatible, but you must have simple tools for good and quick Delphi porting. For example, in FPC sysutils is missing some Delphi stuffs. Well, you can create new unit with all missing Delphi stuffs. Porting programmer only add this new unit to their program. It is easy...

??? I am using this constructs under Delphi without problems... :-O

On the contrary. We switched to this exactly because the opposite cannot be maintained. 8 years of cross-platform experience.

You can simply make a preprocessor which does that if you find it fun to do. But this doesn't change the unit structure, and gives no advantage in most the end user finds it easier to read the
sources.

I think you'll have a hard time convincing the core members. You haven't convinced me. The system as it is works well, it took us some time to get it like that, so we're not likely to change it, just because someone doesn't like split-up files.

When I was at borland for an interview, the first thing I asked was support in the IDE for include files. They scratched their head, and said they would think about it.

This is the main reason why Delphi sources are generally without include files: because the IDE doesn't support them. Personally, I find it more logical e.g. to have one include file per class, this is simply not possible in Delphi.

This is largely a matter of taste. In -Sd it is mandatory to use Borland's way, so if you restrict yourself to that mode, you should be fine.

See: We accomodate most tastes :-)

Michael.

> FPC may let you do that, but Delphi will have an error about not passing > const params iirc. That or the result is garbage back from Windows. ??? I am using this constructs under Delphi without problems... :-O

I don't remember ever getting it to work, but then I come from a D1 background (way back when) so maybe I assumed it doesn't work.

Matt

On the contrary. We switched to this exactly because the opposite cannot be maintained. 8 years of cross-platform experience.

See below

You can simply make a preprocessor which does that if you find it fun to

do.

But this doesn't change the unit structure, and gives no advantage in most the end user finds it easier to read the sources.

Your final line is the reason I mention it in the first place. The include file system may be lovely for yourselves, but it is a mess imho. I have to look at 3 files before I find the piece of the source I want to look at, and even then I have to switch between the Interface and Implementation includes!!!! *This* is not acceptable or compatible with the way I work. This is what puts me off using FPC 90% of the time. This and the inconsistencies of the Unit structure.

I think the end user would benefit from the 'preprocessed' units at release time, and the developers would keep whatever grand scheme they desire at development time.

Please understand, I do not mean you should change your way of working, just that the end user should not have to see your messy include file ridden source. Does that make sense?

I think you'll have a hard time convincing the core members. You haven't convinced me. The system as it is works well, it took us some time to get it like that, so we're not likely to change it, just because someone doesn't like split-up files.

See above.

When I was at borland for an interview, the first thing I asked was support in the IDE for include files. They scratched their head, and said they would think about it.

I'm pretty sure that the Unit files that are distributed by Borland are constructed by a script from a larger source repository. I doubt they work directly on the source files as we end users see them.

This is the main reason why Delphi sources are generally without include files: because the IDE doesn't support them. Personally, I find it more logical e.g. to have one include file per class, this is simply not possible in Delphi.

The IDE doesn't support them because they make the browsing of code complex and irritating. The way CBuilder handles Headers and C files is annoying enough imho. Thankflly Borland do not subject us to the torture FPC does.

Remeber, just because it's easy to maintain for you, doesn't mean it's a good thing for the end user. That's a fact I'm afraid.

Nice to see FPC has come along since I last attempted to use raw Windows API in it ;-)

Matt

> ??? I am using this constructs under Delphi without problems... :-O I don't remember ever getting it to work, but then I come from a D1 background (way back when) so maybe I assumed it doesn't work.

On D1 not exists ansistrings and not exists setlength for strings. on D1 is impossible do this construct. From D2 I am using this construct for API calls without any problems. ;-)

That isn't. I was more hinting at the TSystemTime example. Sysutils is platform independant, and Windows is dependant.

Therefore, don't mix it with a windows unit call!

I see a getlocaltime function in sysutils for obtaining the time, using sysutils.TSystemTime record.

Now I try to port this my code to FPC. What is this? lot of functions in Syutils is missing!

You must make a difference between functions that are missing or slightly incompatible on purpose
(e.g. because there are multiplatform considerations), and that are simply missing.

The first categorie won't be fixed out of principle, though sometimes new discoveries/opinions can often change the behaviour.

The second categorie will be remedied in time, and patches that fix them are usually accepted with gratitude. Open Source must come from both sides.

Well, lot of this functions is in another units.. and some of this functions have different names..

It is hard to say. I'll look at synapse some more, but the important reason is _why_ they are in other units. Portability, or are you just searching equivalent functions in TP functions, while there is no reason to not add them to sysutils too?

.I have platform independent code, but I must do lot of IFDEFS for FPC! This IFDEFS is not for platform independency, this is for incompatibility with Borland! ;-(

In time it should get less, but some will stay.

We have to regard _our_ community. So we are only interested in the part of the Delphi community that is possibly interested in FPC.

And interested in FPC because of its features and possibilities, not just a way to circumvent Borlands fee. Users that donate code back, and report fixes (like yourself) are much more important to us than people that only want to avoid Borlands money.

How many third-party code is available for Delphi?

What is the advantage to use FPC at all if it is not portable? (there are some other technical reasons like linking to gcc etc, but I mean _important_ ones here)

So yes, compability issues that can be adressed, have to be addressed, but this is open source, and users are partially responsible for that too.

Only active users are responsible users that contribute to FPC. The rest are just people avoiding fee's.

How many is available for FPC? How many programs is created and used by FCP... how many is created by Delphi?

Does it matter at all?

How many costs FPC? Nothing! But Delphi is very expensive. When you can be better compatible with Delphi, then you get access to lot of code (by third-party without Borland copyrights!).

How much free code exactly is not-visual do you think?

When you can get FPC as replacement of delphi, then you can get lot of new programmers, lot of new code, lot of new programs...

True, but it is much less than you'd expect.

You're welcome to submit it :-)

It does, with the proviso that 'messy' is a very personal appreciation of our file structure. I find it logical and not in mind that it must be cross-platform. Your remarks are focusing on the point of view of a single platform user.

For multi-platform development, wading though include files is easier than wading through zillions of IFDEF statements: At least from the name of the include file (displayed by your editor) you know in what part you are working. Not so when working with IFDEFs.

I think they do, because the IDE does NOT support include files, so you simply cannot work with include files and enjoy the blessings of the IDE. I was told that for productivity reasons they do all development in the IDE itself, so...

Once more, this is a matter of taste.

Michael.

Exactly. For the average joe user, it's single platform work that matters. You are focusing as a FPC developer, not an end user. That is why you can't see how unwieldy and intimidating the FPC unit structure can be if you don't undestand it, or if you come from a Borland background.

For multi-platform development, wading though include files is easier than wading through zillions of IFDEF statements: At least from the name of the include file (displayed by your editor) you know in what part you are working. Not so when working with IFDEFs.

What I was proposing was that the FPC developers can keep their own scheme, but the end users should be presented with readable, single file units. This would make everything more accessable to the end user.

I think they do, because the IDE does NOT support include files, so you

simply

cannot work with include files and enjoy the blessings of the IDE. I was told that for productivity reasons they do all development in the IDE itself, so...

That will be why there are a lot of machine generated directives for C Builder then. They do that all by hand I guess. They at least use a master set of VCL units from which the distro is created.

> Remeber, just because it's easy to maintain for you, doesn't mean it's a > good thing for the end user. That's a fact I'm afraid. Once more, this is a matter of taste.

No, it's not. This is a matter of fact. It's also a matter of fact that many developers focus on their own back yard, and don't bnecessarily see the bigger picture. The end user is often ignored or worse still told they are wrong. Kind of like now really ;-)

Matt

That isn't. I was more hinting at the TSystemTime example. Sysutils is platform independant, and Windows is dependant.

Ok, enhance this my example: What is different between TSystemTme structure in sysutils and in windows? Windows structure have only one additional field 'DayOfWeak'!

Why platform independent implementation in FPC sysutils not have this field? Simply add this field to FPC sysutils and then you have two compatible structures. What is platform depended on 'DayOfWeek'? Why is not here this field?

Core of this problems is not platform independency. Or not?

I see a getlocaltime function in sysutils for obtaining the time, using sysutils.TSystemTime record.

Yes, but look to implementation. How much code is needed only for convert between two very similar data structures, because 'platform independent' not have one field? ;-O
And this is only one of time functions... for example, I neet to get GetSystemTime. I must do same conversion as in your sysutils... uf!

For example, dynlibs. Same functions is in Borland sysutils. (for both, delphi and Kylix). But in FPC it is in separate unit, and one function have different name. (I mean UnloadLibrary instead FreeLibrary)

Why is impossible put into your sysutils same functons as in Borland and this new functions will internally call dynlibs unit? If some platform not support dynlibs, then simply not add this functions into sysutils on this platform.

We have to regard _our_ community. So we are only interested in the part of the Delphi community that is possibly interested in FPC.

I can turn this. ;-) FPC is interesting for Delphi community only when FPC is interesting for Delphi. ;-)))

And interested in FPC because of its features and possibilities, not just a way to circumvent Borlands fee. Users that donate code back, and report fixes (like yourself) are much more important to us than people that only want to avoid Borlands money.

You are right. but people in delphi community have lot of their code. This people not like rewrite all only because FPC is great. It do rewriting only when then know: "it is small work and FPC add me more features."

What is the advantage to use FPC at all if it is not portable? (there are some other technical reasons like linking to gcc etc, but I mean _important_ ones here)

How you know 'it is not portable'? And I think, some non-portable code can be interesting for FPC. Exists lot of technologies what is not portable and exists only on one platform. You ignore this technologies only because it is not portable? :-O

> How many is available for FPC? How many programs is created and used by > FCP... how many is created by Delphi? Does it matter at all?

Sorry, what is freepascal? This is developer tool. Developer tools is for developing programs. When not exists lot of programs developed by this developer tool, then it is not developer tool, but this is developer toy. ;-)

> How many costs FPC? Nothing! But Delphi is very expensive. When you > can be better compatible with Delphi, then you get access to lot of > code (by third-party without Borland copyrights!). How much free code exactly is not-visual do you think?

I not count this. I cannot count of this. look to www.torry.net, for example. You can found lot of code what will be interesting for FPC, here is lot of code what is not platform dependant too. But convert it for FPC not interesting their developers, because it is not easy... ;-(

I plan do this very similar for Synapse's purposes. ;-)

NOT if they want to use FPC, which we _explicitly_ target as a _multiplatform_ development tool.

Note that I don't deny that there is still work on the Delphi compatibility front. You're welcome to make contributions in this area.

You are focusing as a FPC developer, not an end user. That is why you can't see how unwieldy and intimidating the FPC unit structure can be if you don't undestand it, or if you come from a Borland background.

The average user will not want to dig in our sources in the first place.

He/she wants to install the compiler, compile programs and not look at our sources. In fact, many don't even install the sources. Most developers in my company have never even seen the Delphi units, and they should not. Likewise for FPC.

All other developers, which want a little more control and background, must endure a small learning curve.
A small price to pay for cross-platform development IMHO.

This I can live with, but I would provide this only as a service to the end user, and definitely not as the 'source' distribution.

I meant that some people prefer include files to ifdefs. In that sense, it is a matter of taste.

If one presumes as a fact that everybody prefers single-file sources with IFDEFS in it, then your statement about 'a matter of fact' is 100% correct, and I will not dispute it.

But this presumption is IMHO not correct. It's all I wanted to say.

Michael.

One my notice:

FPC style of coding is good for handle multiplatform sources, but for me (mean program developer) is this sources very badly readable. ;-(

example:

I need some some functions. What I need for use this function? i must know unit where this function is. (for adding it into uses)

On Borland, i do simple text seach on Borland sources and directly I can see what unit I must use.

But on FPC I gen only some include unit. I must do search again.. again... for getting unit name what I need. ;-(

It's a matter of taste, but don't forget otherwise you have to scroll/search through the same amount of info. I really dislike units that are longer than 1000-2000 lines.

In time Lazarus could be adapted to make things a bit easier (e.g. opening all includefiles too when opening an unit, and clicking a {$I ..} line switches to it or so.

I do have to acknowledge that when I started on core, it took some time to get used to it though. However there is no other clean solution.

Don't forget that for e.g. 2.0 there will be about 20 processor-OS combinations.

Ifdeffing them all is simply not possible, and most system independant units have a system independant part (header, but also utility routines etc) a dependant part, and sometimes even a processor dependant part (but that usually is much smaller)

I think the end user would benefit from the 'preprocessed' units at release time, and the developers would keep whatever grand scheme they desire at development time.

How do you merge back user fixes then? Do you want to distribute each unit for each platform-OS version? Would become a huge source zip then.

Please understand, I do not mean you should change your way of working, just that the end user should not have to see your messy include file ridden source. Does that make sense?

"Messy" is your label, I don't consider it messy. It is close to the iron, sure, but show me a large multi platform project that isn't.

Though there is some merit maybe in your arguing. While I don't feel like distributing the mangled version, maybe the util that does that (for a single unit or unit set) could.

People that prefer it, or want to for debug purposes, can generate a fully OS-platform dependant unit (without much ifdef or includefiles).

The systematic directory layout used in most places should make finding the includefiles automatically easy. So only defines that are not strictly about platforms are a problem, but those will be relatively small.

So that is maybe a good point. So all we need is an interested volunteer I think.

They probably have a full time helpdesk staff to deal with it, between users and developpers. Under FPC, core does everything. Usersupport, documentation development (there are 10 categories below this alone), bugrepport analysise, release engineering, advocacy, website analysis, faq creation etc.

Putting more stress on the core team (this is yet another nail on the coffin) would grind development to an halt. Why do you think that sysutils unit is lagging behind?

The only systematic solution would be more people. And not in the future (people have been saying that for years), but NOW.

Extra people don't have to be really hardcore developpers:
- People that get a kick out of helpdesk work can always apply ;-) (answering questions, bugreport analysis)
- Intermediate users that compile a lot of Delphi code, and make a very precise analysis of what is wrong, and how to fix it.
- we still need a webmaster
- documentation. (Michael does this nowadays), both making it and proofreading.
- making headerconversions.
- making demoes
- be Lazarus liasions officer.
- somebody to look into the win32 net-installer thing.

And the list goes on.

Talking about raw api, maybe we should import Marcel van Brakels win32 API into FPC 1.1.x (the same that Jedi advocates on its site). It is a bit biggish though, first we need the net-installer then ;-)

They use the pascal sources I think. What are all those $HPEMIT and $EXTERNALSYM are for otherwise? (or are they for something packages $related?)

It is taste. I'd bet that a lot of users would dislike the very long utils that are the result of that.

In this particular example, the field was simply forgotton, and we'll add it. This is not a problem.

For example, dynlibs. Same functions is in Borland sysutils. (for both, delphi and Kylix). But in FPC it is in separate unit, and one function have different name. (I mean UnloadLibrary instead FreeLibrary)

Simple:
Our unit was implemented first, and the Borland unit appeared later !

1. We will add them in the main branch, just as you say, they will call the implementation in dynlibs, and will be Borland compatible.

2. They will raise an exception if not implemented on a specific platform. Otherwise users will still need IFDEFS anyway.

Michael.

Excuse me, but you are NOT the mean program developer. The mean program developer does not write a TCP/IP suite.

4 clicks using the documentation:
Index, function name, jump to declaration. Unit is visible in navigation tree.

I have tools set up to make the docs searchable on our website, but I need some free time to fix it.

The ways of using Delphi and FPC are simply different...

Michael.

This is what I was saying to Michael. The FPC team may thing the unit structure with include files is good, but I for one look at the source code *before* I look at the docs, because 80 - 90% of the time I find this more productive. FPC makes this very hard.

Lukas - I think grep is your best friend with FPC. You need to find the function 'GetXXX' but don't know where it it - I usually grep for it (using Cygwin on Windows.) If you're not familiure with grep, some thing like:

grep -r [Gg][Ee][Tt][Xx][Xx][Xx] c:\fpc\units > output.txt

will generate you a list of all places it exists, recursively. The regular expression syntax I use is one of brute force rather than anything else and [Gg]etXXX would probably work too, so long as the case is consistent. You can probably do case insensetive searches too, I've never really looked into it myself.

A good tutorial is at: http://pegasus.rutgers.edu/~elflord/unix/grep.html

I'm not going to comment any more on this issue except to say that it *is* an issue.

Michael - if none of your developers look at the Delphi source code, I shudder to think at the standard of programming they produce. I've never met a professional programmer who doesn't at least look at headers/interface sections of code to understand how a routine works. Not doing so is completely alien to the way I work normally, and I am not alone in this either.

Matt

Ifdeffing them all is simply not possible, and most system independant

units

have a system independant part (header, but also utility routines etc) a dependant part, and sometimes even a processor dependant part (but that usually is much smaller)

What I suggested used no IFDEFS, platform end user release, has a set of platform specific units created by a preprocessor. This would be specifically for x86/Dos, x86/Windows, x86/Solaris, x86/BSD, x86/Linux, ppc/MacOSClassic, ppc/Linux etc. Surely this removes your problem with the idea. Single minded units that only contain a single platforms code. You give these to the end users, and you use these for unit testing etc in pre-release. However, the FPC developers continue to use the include file style units internally.

Your source code should document your work, and making the document hard to read makes the work harder to use. IMHO of course.

Matt

In reply to your message of July 24, 2003

I tried that and still had problems. What I ended up doing is writing a really tiny string unit (CString) of my own that translates back and forth between string formats. It completely elimated the issue for me...

I ended up with syntax like this:

        var
          Buffer : CString;
        begin
          MessageBox(CSTR(MyMessage,@Buffer), 'test',MD_OK);
        CSTR is a procedure that places the Null Terminated string in
        MyMessage into Buffer and passes the pointer to Windows.
        To get a string into pascal from windows, where I can mess with it I
        wrote an opposite translator PSTR which reads the buffer and converts
        it to a pascal string variable.
        var
          Buffer : CString;
          USer : String
        Begin
          GetUserName(PSTR(@Buffer),255);
          UserName := PSTR(@Buffer);

This works. And so far it's 100% reliable...

Typecasting and the Strings unit often produced strange results that ended up putting garbage into edit boxes and left me with unusable strings. For example, If the username was "Fred Smith", by your suggested method Length(Username) would return an error and SizeOf(username) would be 256. My way --running everything through a translator-- Length returns 10 and SizeOf returns 11 (because of the length byte).

FWIW... CString is a tiny unit, less than 2k! If anyone wants a copy they can drop me an e-mail and I'll send it out by attachment... (I've submitted it to a website but it's not online yet.)

I'm not angry, I like FP just fine, but, really, why should I have to write this unit?

Most OS have similar concepts; they just accomplish things in different ways (e.g. Linux devices are all file descriptors, but BeOS devices are almost all file descriptors, and Windows Devices are not.) Wrapping up the differences is the smart way of making sure your skills are transferable.

It is exactly this difference that spawned my comments. Unless there is a way to make the wrappers transparent to the programmer, you really have little choice but to bend the language a little. If you think about a project of some size (eg: a new web browser) it would be a lot smarter, and a lot more compatible, to run the sources through a conversion routine when going cross-platform than to include 1000 instances of some translator routine which would give you fits on the new platform.

What I'm saying is that the native syntax of the language should be maintained as closely as possible between platforms, but the mechanics of each function and procedure should be altered to suit the platform.

EG: when on windows FPC should work natively with null terminated strings, when on DOS it should work with pascal strings. But this difference should be invisible to the programmer...

But then... I'm having the time of my life over here. Getting back into Pascal, learning a little C, writing my first windows programs (3 on the go right now), meeting a bunch of new people online... hey... I'm not complaining <G>.

-----
L D Blake

How do you propose to look without violating copyrights? We have to reverse engineer free Delphi apps to see what they call, and how they call it.

Then I have to fix one bug 20 times, since generic code is not shared. Somewhere, platform dependant and independant code come together in a unit.

Surely this removes your problem with the idea. Single minded units that only contain a single platforms code. You give these to the end users, and you use these for unit testing etc in pre-release. However, the FPC developers continue to use the include file style units internally.

I don't see the problem with that, but I also don't see the harm in a generator for people that want otherwise.

Your source code should document your work, and making the document hard to read makes the work harder to use. IMHO of course.

Oh, please. We are not in school anymore. This is a production product, spanning a host of version-compability and operating systems with a total source size over 50 MB.

And more important, {$ifdef linux} etc is also selfdescribing source, so documentation. The source clearly displays the differences between the platforms.

If you want to start such converter tool btw, you might want to look at the fpdoc documentation subproject, IIRC it already contains a parser.

That is not true. He suggests that we keep the source exactly as it is now in CVS, but to distribute it as explained above.

Jonas

> Michael - if none of your developers look at the Delphi source code, I > shudder to think at the standard of programming they produce. I've never

met

> a professional programmer who doesn't at least look at headers/interface > sections of code to understand how a routine works. Not doing so is > completely alien to the way I work normally, and I am not alone in this > either.

Your developer was refering to the people you work with that you mentioned do not look at Delphi source. Not FPC people.

How do you propose to look without violating copyrights? We have to reverse engineer free Delphi apps to see what they call, and how they call it.

Free CLX contains a large chunk of the RTL, and is already supporting Linux and Windows. I see sysutils, sysinit, system, types, variants, math, inifiles, syncobjs, typinfo, classes, contnrs, and a whole host of Linux specific units such as LibC. All the code is under GPL according to sf.net project page, and so all should be usable in some way shape or form by FPC developer without fear of reverse engineering. Look at Syllable (also of SF iirc.) This project has branched a complete operating system that was GPL, so Borland wouldn't have a leg to stand on imho.

Matt

Matt Emson wrote

Michael - if none of your developers look at the Delphi source code, I shudder to think at the standard of programming they produce.

I am not the judge of my collegae, so allow me not to comment on this. But believe me if I say that they haven't looked at the sources, this is simply a fact.

I've never met a professional programmer who doesn't at least look at headers/interface sections of code to understand how a routine works.

Then you're a lucky man. Stick around on the mailing lists, and help people who don't do this. There are still lots of them.

Not doing so is completely alien to the way I work normally, and I am not alone in this either.

It is also alien to the way I personally work. I don't think there is a single VCL source file I haven't gone through at least once for my work, but I am not an average programmer.

At least, I like to think that this is so. Opinions on this may wildly differ ;-)

Michael.

Having been a consultant for many years, this is the *only* way to work imho. I walk onto a site that I have never been to before and I must understand their source code immediately. I think that taking your approach, I would never get anything done. It's laughable to be honest. Your mindset is one of a deskbound office worker, not someone who has to pick up the pieces when the lead developer leaves (for example) and no one else understands his code. This is what the real problem is. I'm trying not to make this personal, but some of you FPC guys should look at the real world sometimes.

With your practice how do you use third party tools? In most cases they do not include any source to look at.

You buy the version with source. I've never come across a vendor that will not sell you the source for a price. This covers your back when said vendor (e.g. Turbo Power) go out of business and don't opensource *all* of their products (if at all.) What would you do, start again from scratch??!??!

How would you use 'C' libraries or ActiveX or code in Visual Basic. It is an interesting thing to do to look at the original source but to use it for your coding practice seems very strange to me.

I use the Pascal import Unit and curse M$ for creating a standard that so many vendors abuse.

As for VB; sir you insult me to assume I even consider using a toy to get real work done :-P

As MVC already stated in most cases FPC users don't even install the source so what would they have to look at in the first place.

More fool them.

As was also stated you are using the mind set of a single platform development tool. FPC is not a single platform development tool and can not be viewed in that fashion.

But all the source is seperated isn't it ? It doesn't all reside in a single dir? Last time I looked you had a Units/Win32, Units/Linux etc. Maybe this has been extended by now?! How on earth is concatenating the include files into a platform specific unit and putting it in the platforms source dir going to ruin cross platform development? You are finding excuses for the sake of it. No offence, but it sounds a lot like "father knows best" to me.

This can be talked about back and forth for a long time but I think it is safe to say that this isn't *AN ISSUE* this is *YOUR ISSUE*. You are free to use a different tool that is more to your liking.

I do. Every day, man ;-) I'd use FPC if it was friendlier. I'd really like to; I'd like to contribute too, but I always get such negative feedback from the developers. No offence again.

Why don;t you make it more democratic and put up a poll.

Matt

If you want to start such converter tool btw, you might want to look at

the

fpdoc documentation subproject, IIRC it already contains a parser.

I think I already have a Pascal parser. I'd have to look in my personal code lib.

I'll add it to my todo list and see what happens.

Matt

Ok. But that is quite common btw, specially for people that use RADs. (type-ahead and function syntax in those floating over texts). I also did that when I used JBuilder.

Yes, maybe to peek at, but not to use (when I last looked it was only the QT part, and only a bit bad), since that would contaminate FPC's license, and disallow commercial use of FPC generated binaries.

I did use parts to test 1.1.x compability about half an year ago, when widestrings started to work a bit (as least their parsing), but in general it is confusing due to a lot subtle internal differences.

However 1.1.x keeps getting better, and maybe it can be ported sometime, as compiler test or so.

Look at Syllable (also of SF iirc.) This project has branched a complete operating system that was GPL, so Borland wouldn't have a leg to stand on imho.

If it remains GPL, that is not a problem, but we don't want the libraries GPL (the compiler and other end-user programs are though, but not the runtime libraries, since that would hamper users to distribute generated binaries without those apps themselves getting GPL'ed)

You may not be alone but you are in a very small minority. I have been coding in Delphi since 1.0 and can never think of any reason why I had to look at the Delphi code to do my own coding. They only time I had to dig into it was when I wanted to determine how Delphi did something that I wanted to match in the LCL.

With your practice how do you use third party tools? In most cases they do not include any source to look at. How would you use 'C' libraries or ActiveX or code in Visual Basic. It is an interesting thing to do to look at the original source but to use it for your coding practice seems very strange to me.

As MVC already stated in most cases FPC users don't even install the source so what would they have to look at in the first place.

As was also stated you are using the mind set of a single platform development tool. FPC is not a single platform development tool and can not be viewed in that fashion.

This can be talked about back and forth for a long time but I think it is safe to say that this isn't *AN ISSUE* this is *YOUR ISSUE*. You are free to use a different tool that is more to your liking.

Each to their own ;-)

Believe me, I used to train Delphi for Borland. (My old company was the PSO for Borland when I joined them for approx 1 year, then Borland decided to do it themselves.) I also consulted for Borland at a couple of sites too. I'm not saying this makes any difference, just that I have quite a bit of experience of teaching Object Pascal to a wide range of abilities.

Then you're a lucky man. Stick around on the mailing lists, and help people who don't do this. There are still lots of them.

I do. I have. I will continue to ;-) It's not always easy to find the time and unfortunately my examples are often Delphi specific because I prototype in Delphi. Maybe writing that FPC plugin for the Delphi IDE would be a good place to start ;-)

It is also alien to the way I personally work. I don't think there is a

single

VCL source file I haven't gone through at least once for my work, but I am

not

an average programmer. At least, I like to think that this is so. Opinions on this may wildly

differ ;-)

You have my respect ;-) Don't read me complaining about file structures to be any kind of insult to your abilities. All FPC developers seem capable if not expert programmers ;-)

Matt

I not mean ''main'.. I mean 'program developer'. I not programming only TCP/IP... I am programming final application too. It is my job. ;-)

You not understand me. ;-) For me is readable written sources much better then documentation. Yes, documentation may be good, but sometimes I need information what is not in documentation. Where I can found reply? In sources! For me is readable sources very important, because it can give me reply for all my questions. Ilove opensource, because I can get answers from sources.

And FPC sources is not good readable for me. This is just my opinion. ;-)

Lukas - I think grep is your best friend with FPC. You need to find the function 'GetXXX' but don't know where it it - I usually grep for it (using Cygwin on Windows.) If you're not familiure with grep, some thing like:

I am using much easier way for this... I am using TotalCommander and their filesearch. I can directly browse fouded files, i can continue find within search result... and all by a few hit to keys. ;-)

However searchingg through sources in delphi is much mure simple. ;-)

In reply to your message of July 24, 2003

Exactly. For the average joe user, it's single platform work that matters. You are focusing as a FPC developer, not an end user. That is why you can't see how unwieldy and intimidating the FPC unit structure can be if you don't undestand it, or if you come from a Borland background.

Speaking as an FPC "end user" who's only a few weeks into using it on a part time basis, I have to agree. I've tried looking things up in the source code folders and it's a real chore. I was used to seeing the Interface parts of units as contiguous files where you can actually see each procedure (etc.) listed out ... the FP include files are a nightmare to wade through. I finally ended up doing some very time consuming in-file string searches trying to find a simple variable declaration. And after not finding what I wanted, I ended up writing to a complete stranger asking questions... (Good thing for me he turned out to be a nice person <G>)

What I was proposing was that the FPC developers can keep their own scheme, but the end users should be presented with readable, single file units. This would make everything more accessable to the end user.

Yep.. at least for the Interface parts...

FWIW, my dominant experience is in customer support and about half the calls my crew used to take were related to unclear or incomplete documentation. People would say "The help file says '...' What does that mean?" or it would turn out the information they needed just wasn't days when we used to say "RTFM" in jest are pretty much gone. People do read these things (i.e. they do read FPC docs and source code). Now the problem is they either don't understand what it says or can't find the information they went looking for. They can't read at our level of technical skill, so we have to ... It is very likely FPc's user base is being harmed by it's own file structure. Re-arrange the unit collection, hide the file used by the file used by the file that is used by the unit and give us clear Interface documentation for every unit and it's likely FPC will end up doubling it's user base in very short order.

The first step is to simplify and rationalize the file structure... Start from your base PPC directory, branch to targets, then to units,bin,lib, then to sources and docs for each second level branch. I rearranged my copy of FP like this:

h:\frepas\win32\bin
h:\frepas\win32\bin\source
h:\frepas\win32\units
h:\frepas\win32\units
h:\frepas\win32\units\fcl
h:\frepas\win32\units\fcl\source
...
h:\frepas\go32\bin
h:\frepas\go32\bin\source
...

and it's a LOT easier to find stuff in there now. Mind you, I doubt I could compile it from that without a LOT of fuss and trouble but it's also unlikely I would ever need to re-compile it. At least I can now find information when I need it.

Where you must include depenencies in a distribution the file structure should reflect that, as in:

\ppc\%target%\units\fcl
\ppc\%target%\units\fcl\uses

Where only the main ow and ppw files for FCL are in the fcl folder. The rest, the ones used by the main units, should be in the "uses" directory where we don't need to worry about them.

A concise Interface declaration should also be present for each file we can directly list in our Uses clause. I'm used to seeing something like "sdos.tpu" accompanied by "sdos.txt" listing the interface declaration and, where necessary, any special instructions the unit requires.

It might also be a lot clearer for the end user (i.e. me) if you moved the DOC directory over to:

\ppc\%target%\units\fcl\doc

Same with the sources:

\ppc\%target%\units\fcl\source

At least then we could easily associate the information with the files it's describing.

Also... do you realize that *noplace* in your documentation do you tell us which files to list in our USES clauses for each unit?

Thing is, FPC is a great little compiler... I didn't choose FPC because it's free. I have 2 different versions of Delpi and a copy of C++ within arm's reach... I don't need to use free compilers. I chose it because it's the best for what I want to do.

Reason 1... I have a small DOS program that loads up, renames about 10,000 files I have in a clip art collection and then exits. I just re-wrote it for windows In D7 it's about 380k, in FP it's under 40k.

Reason 2... To give a copy of a Delphi program to a friend I may also have to give out one or more DLLs. FP creates standalone EXEs.

Reason 3... Doing a simple test of a "count to a zillion" program Delphi takes much longer than FP.

Reason 4... I am not using "Object Oriented Programming". I'm an old school, brute force, programmer. Delphi gives me no choice. FP lets me do as I wish.

Reason 5... Delphi's IDE hides a lot of stuff from me. Using the visual designer in D7 I never see the RES files or the Source Code until I am writing method handlers. In FP I have complete control over every last character of my work.

But, even with such compelling reasons, I almost trashed FP a dozen times; not because of the way it works or because it has limitations... Being someone's part-time project, I expected to run into crashes and things I just couldn't do, but that hasn't happened yet. Frankly it's the documentation and the "scrambled eggs" file structure that was giving me fits. I'm in a learning curve here... I need information and I need it in a concise and readable way.

It really isn't enough to just zip up the developement directories and send them out... WE don't know what the developer did or why they did it... we just want to use the package... because it's a great little compiler.

Ummm... very simply... End users aren't mind readers.

In this case, presentation of information is at least as important as the quality of the software.

-----
L D Blake

No. It never has, at least not since 1997 when I joined. Unless you of course try to assemble it from the various files to form one source.

Last time I looked you had a Units/Win32, Units/Linux etc. Maybe this has been extended by now?! How on earth is concatenating the include files into a platform specific unit and putting it in the platforms source dir going to ruin cross platform development?

It isn't, if it is only the source that goes to the endusers, generated from a master source. (and keeping the file with includes for development)

Those directory hierarchies only contain the parts that are dependant on that platform.

Generic include files are in inc/,
processor dependant parts in <cpuname>/
OS AND processor dependant parts in <osname>/<cpuname>

Files shared by the full Unix (clone) OSes are in unix/
(*BSD and Linux mainly)

Most of the other platforms like QNX, BeOS share directory posix/ which implements a bit more restricted base library, you are probably more familiar with the exact BeOS situation than myself)

Some Delphi parts (extensions to the system unit and sysutils generic include files) are in objpas/

You are finding excuses for the sake of it. No offence, but it sounds a lot like "father knows best" to me.

Hmm, seems to be as "Consultant knows best" actually :-) But I'm sure you are a fine consultant.

The current situation is an agreement between at least 10 people, all of them "fine" programmers, quite some professionally even, and at least 10-20

I urge you to be very careful btw, unless you really have real experience in full (as in lots of OSes and architectures independant) portable programming. Things aren't as easy as they seem.

Also do an estimate about how much work something as FPC is, and then make it tenfold.

It is a group process.

Why don;t you make it more democratic and put up a poll.

Two possible answers.

1) Democracy doesn't work in companies or open source projects. In companies it is who pays the bills, in open source projects it is in who wants to do the work. Period.

2) It already is as democratic as it gets. Only the voters are the contributors not the users, and rougly pro ratio of their work. And the majority of the contributors (not users) decides, the rest (users and minority contributors) are left with the right to fork.

That sounds harsh, but it is the only way really. Outsiders otherwise dream up elaborate plans, often with great grandeur and idealism, (the so called Silver Bullet), the more realistic main contributors bail out or realise that they are too few to even make a dent in the design on a parttime basis, and ultimately nobody does anything except discussing and arguing on the maillist, and a few concept source bits.

Open Source reality is simply different from the business world.

That this concept works is also proven by the relative rarety of forking, despite it being easy to do legally.

I made that mistake too before I joined core. Dig for messages from me in the period 96-97 to see :-)

Only if you actually have done quite some work, you get a feel for why things are the way they are, and that you can't tell core people to fix your problems first. Ask them also had a lot of plans, and a lot would become better because I saw things clearly. Ultimately, only some minor readjustments remained. Reality came crashing in.

Matt Emson wrote

Free CLX contains a large chunk of the RTL, and is already supporting Linux and Windows.

... and it's full of terrible ifdef linux/win32 ... Can you imagine the mess if you handle 10 or more targets this way :) ?

Almost ten years ago I started OS/2 and linux support this way and I decided really fast to use include files instead :) And from the view of maintainability it was a good decision.

Yes, this is really pain under Delphi.

Lazarus opens the include files internally. I don't think that many users wants to open the 20 include files when opening classes.pp. They are opened automatically when you do for example a method jump or a find declaration or doubleclick on a codeexplorer item.
I think, an overview of the include files would be nice. I think, the code explorer is a good place for this. Any ideas, how this information should be merged into the code explorer?

and clicking a {$I ..} line switches to it or so.

"Find declaration" and "open filename at cursor" does this.

.. and think about bugreports and other communications referring to files and line numbers. This can become a tower of babel.

:)

- somebody to look into the win32 net-installer thing. And the list goes on. [...]

Mattias

I think that is ok.

I think, an overview of the include files would be nice. I think, the code explorer is a good place for this. Any ideas, how this information should be merged into the code explorer?

I think this will be a bit hard, because not only purely the sequence matters, but also the exact place inside of the source.

OTOH, for simply moving up and down from unit into include files it could be ok. But I'm not really that used to such visual gadgets (I prefer kbd shortcuts), so maybe I'm not the best judge of this.

> and clicking a {$I ..} line switches to it or so. "Find declaration" and "open filename at cursor" does this.

I'd keyboard shortcut the last one, but for the rest ok:-)

Yes. The only option anyway is to provide a tool to generate such files for own personal reference. But the human resource of the core team simply are not up to adding anything which isn't really absolutely essential.

And no patches will be accepted about such units, and ambigious bugreports set to "unreproducable" or so.

It is actually quite serious.

> - somebody to look into the win32 net-installer thing.

- release engineering
- other tools building (think about an idl2pas or so)
- helpfile and related tools.

I've just discovered that the MMSYSTEM unit for Win32 is missing at least one of the function call prototypes... MCIWndCreate(...) is just plain not there.

Anyone know where I can get a fixed copy?

-----
L D Blake

Having read this thread with interest, I feel compelled to say something.
Very simply put, I have no care how good a piece of code is by any other judgement. If it cannot be ported, it has already failed the most crucial test for code.
Okay, maybe that is a bit harsh, there are obviously exceptions (nobody expects you to write a platform independant network device driver) and if you stick too religiously to this, then you deny developers the opurtunity to ever make use of platform specific features.

However, if what you are depending on is in fact a platform specific bug, easter egg, undocumented feature, kludge or limitation then frankly your code has lost all interest.
Doom was a great game, but all the greater because it scale from the single user dos world to the multi-user linux world without exploding.

We are entering a world where the amount of platforms are increasing, maybe right now most software companies haven't noticed yet, but how long can they ignore the incessent growth of other platforms and be economically viable ?

I first started using FPC in the very early days because it offered a TP compatible compiler on Linux, and those of you who knew me from then will remember the dos kludges of my code at the time. I stuck with FPC (including trying in my own ways to contribute) because it was multiplatform.

It takes time to learn how to code platform independantly to the greatest degree. But it is a skill that I think will become a vital job requirement for all developers in less than 5 years.

You can either stuff yourself up with java - or use a decent cross-platform compiler, and just code a little smarter (seems like a nobrainer to me).

Having said all this, I think Lukas has written a really good piece of code in synapse, and I am glad about the fpc port. But Lukas, fpc is not intended to be a free replacement for borland, or a linux clone of tp or delphi. It is so much more than that, and if you code for it or in it, it is a deffinite advantage to never forget that.

A.J.

> Core of this problems is not platform independency. Or not? In this particular example, the field was simply forgotton, and we'll add it. This is not a problem.

Great! ;-)

If I replay my discussion int very short form, then it is look as:

X> Synapse is not good, because it using lot of IFDEFS I> Lot of IFDEFS is using for resolve incompatibility between Delphi and FPC
X> This incompatibilities is because FPC supporting much more platfrms.
I> Lot of this incomptibilities is not dependng on platforms.

I only try to explain, why I have lot of IFDEFS... I must create lot of IFDEFS only because FPC is not very copatible with Delphi, and this incompatibilities is not depending on multiplatform nature of FPC.

Porting is not easy work. In this example, I use TSystemTime structure, and FPC compiler get me error: "No! What you are using? I need TSystemTime!" It must confuse lot of Delphi programmers. ;-/

One my mind... when FPC reporting error with expected data type, can they report me where this data type is declared?

L D Blake wrote

I've just discovered that the MMSYSTEM unit for Win32 is missing at least one of the function call prototypes... MCIWndCreate(...) is just plain not there. Anyone know where I can get a fixed copy?

There is no such "fixed copy" of MMSystem unit. MMSystem unit is a translation of mmsystem.h C header and functions MCIWnd* are in vfw.h (BTW, this is true for Delphi as well). So you need a different unit. As far as I know there is no such unit in FPC packeges.

Here are the complete instructions on how you can obtain the unit that you want:
Searching with google I found this archive
http://www.torry.net/vcl/mmedia/video/vfw.zip
(linked from page http://www.torry.net/video.htm). It contains unit Vfw.pas and this is what you need. BUT this unit is for Delphi 2/3/4 and you have to modify it (a little) to compile this with FPC.

1) Remove two units from "uses" clause changing
Messages,
CommDlg,
to

     {$ifndef FPC}
     Messages,
     CommDlg,
     {$endif}

Those two units are not needed under FPC (their stuff is in Windows unit) and both of them are even not available under FPC 1.0.x. (I don't think CommDlg is available even in 1.1).

2) You need to add

   type POPENFILENAMEA = POPENFILENAME;

and take declarations of two functions (GetOpenFileNamePreviewW and GetSaveFileNamePreviewW) in interface (and their export-clauses in implementation) in similiar {$ifndef FPC} ... {$endif} brackets.

(it's not the most elegant way to do that, you should check is UNICODE symbol defined etc.; but doing as I said you will also get what you most probably want)

And that's all - you have a unit Vfw.pas that can be compiled with FPC 1.0.10. Warning - I only compiled this unit under FPC 1.0.10, I did not tested it (basically, I know nothing about functions in this unit, I was simply able to adjust Delphi unit to FPC) ! So I don't guarentee it works as it should. But probably it does, it's just a simple export unit. And it containd MCIWnd* functions that you wanted.

Hope this helps,

Hello,

I think the point about users finding include files cumbersome to use, and developers who require maintainability, has been made clear.

We can discuss about this for ages, and never agree. So I would like to conclude the discussion with a proposal.

My proposal is as follows:

If someone contributes a tool which does the necessary preprocessing i.e. including needed files, then I will set up a system where the source files are 'assembled' into single-source units for a given platform/cpu combination. These single-source units can be distributed with each platform or separately downloaded.

This tool can be run on a daily basis on our CVS server, and zips can be made available as a service to the FPC users.

As for the tool, I ask only 3 things:
1. It should compile with FPC and should be cross-platform.
2. Should obey {$ifdefs}/{$define} and the like, such as run-time platform selection.
(linux based tool must generate sources for e.g. win32)
3. As for the rest, it would be good to have the command-line options which match the compiler's:
-d define symbol
-u undefine symbol
-I/-Fi set include path
-T select target os/cpu
-FE set output name.

If someone makes this tool, I will do the rest.

Hopefully, this proposal helps to end an otherwise lengthy discussion.

Michael.

In reply to your message of July 25, 2003

Here are the complete instructions on how you can obtain the unit that you want:

Thanks.

The reason I wanted this was that it's got the direct-play MCI function in it.

MCIWndCreate lets you hand MCI a filename and it will play anything mci can handle... which is how windows sounds are done.

-----
L D Blake

Hmmm, this could be easily done by the compiler but I see no real use for it. I think it would be much more useful, if fpdoc could be extended to include the file name and line number into the docs ...

This can be done too. But that will not solve the problem of the 'include' files. You saw that many people don't want to have the docs as an in-between.

But it's noted as a feature for fpdoc. It's a good idea.

Michael.

This was all I ever really wanted to be honest.

This tool can be run on a daily basis on our CVS server, and zips can be made available as a service to the FPC users.

Cool, that sounds like a good idea.

I will will initially write it in Delphi, simply because that is to hand, but will get it to compile under FPC 1.1x when I have got it to work here.

One question, do you want a recursive batch job, or single file operation. i.e, do all in one go, respecting commandd like options, or simply the files passed to the command line. Think of the difference between gcc and fpc. gcc expects explicitly to be given all files at command line, fpc will look for them automatically. I have no preference and may simply add this as an option.

Hopefully, this proposal helps to end an otherwise lengthy discussion.

Done ;-)

Matt

[ Charset ISO-8859-1 unsupported, converting... ]

I think it can be done better to match the commandline behaviour to the compiler as close as possible. AND to generate an empty .ppu and .o file for each access, and also a .a file if there is a -CX parameter.

This will make sure that simply running

make all PP=<your tool> OPT='other parameters to your tools like rootdirectory of the output'

visits the same units that would be build in a release build. It would also avoid the trouble of keeping what units need to be generated.

However it doesn't have to do unit search, since you don't have to access dependant units (uses clauses)

Single file operation: name of a input unit file, name of output file. (plus command-line options for where to find include files, and defines)

Michael.

Hello,

Just for adding my few cents : I'm not keen on FPC , and rather know a little about FPC design but I think this is academical disscuss becouse Pascal never used preprocessor like C++ and becouse of that was so fast, but also so complicated when using it in multiplatform envinronment. Look into wxWindows details and You will find that an platform independent code and platform dependent library working very good together ! And even processor specific such like type declaration or machines with different byte orders is doable that way.

I'm not insist that it is the right solution for FPC, but looking into it could help.

Boguslaw

We can be short about this: The complexity of a few includefiles pales by the magnitude of complexity of bringing a C/C++ macro preprocessor. The average C system is a mess in this respect.

People that disagree, are welcome to make a fully automatic (read: perfect) header translator for C header files to Pascal. Or at least come up with a design that _could_ work.
It doesn't have to be compiler independant, just basic C+preprocessor macro's are enough.

If you succeed, the gratitude and the glory would be immense :-)

Moreover The average C system that interfaces to a multitude of OSes or other deeper libraries have the exact same solution as FPC. A directory per item (OS, GUI toolkit) that contains a wrapper if needed + headers that are independant of the system, and a common include dir. They use "make" to hide it.

(check nearly every project, GDB, GCC, libc, _anything_), and you will find OS (or GUI toolkit, or both) directories.

I'm not insist that it is the right solution for FPC, but looking into it could help.

The C preprocessor is a kludge from an historical perspective. The main reason for it was to defer preprocessing from the actual compiler, so that the actual compiler needs less memory. Later it was extended to make up for other problems of C. (most of which reasons were valid then, but not now, to make the compiler more lightweight).

C/C++ designers know that too, and have known it for a long time. You just have to read all C standards, and study the C++ design, and you see that the preprocessor got less and less important with time.