Is there any good reason to support older versions (lower than current stable release 2.4.2) with kol?
FPC is free and it would be easier to maintain kol for just stable releases.
Contrary to Delphi, which you have to pay for in principle, I do not see any reason to support old FPC versions.

Plz give feedback, maybe I am wrong.

i discovered that question and made my own "small set" for FPC
but right now very hard to rewrite FPC compatibility for FPC. KOL have ANSI and UNICODE WinAPI functions, main part of which  available just through Jedi package. But it constructed by way to include SysUtils, Classes and Variants modules, so, program size increases too much. and KOL staying almost useless with it (as library for size decreasing) :((

and if to use "old" method - just to use WinAPI modules from Delphi - we will lost multiplatform  (for example, 64 bit) compatibility

"i discovered that question and made my own "small set" for FPC
but right now very hard to rewrite FPC compatibility for FPC. KOL have ANSI and UNICODE WinAPI functions, main part of which  available just through Jedi package. But it constructed by way to include SysUtils, Classes and Variants modules, so, program size increases too much. and KOL staying almost useless with it (as library for size decreasing) :(("

This is not true: most functions from sysutils etc are already in KOL.
But KOL is written for ONLY win32 NOT for win64 or other platforms.
You  do not want JEDI, because the makers do not care about size. Again, there are KOL equivalents to be found.

Do not make the mistake that you can mix KOL code with \VCL code, you can NOT!

I understand you want small code, in that case learn more about kol. There is enough information and a lot of examples on the website.

It is not very difficult to translate kol to 64 bit (in pas_version, not asm) but it is a lot of work. In other words: kol is not designed to be portable.

What CAN be done is a full webserver in7 k (multithreaded) and a mail server in 4.5 k.

Let me make a clear statement:
If you want to do that in pascal, don't, learn intel asm. It is by default the simplest language there is.

If you want small professional grade applications written in pascal, use for example KOL. And learn to use it.

But I hate it sometimes when my virus scanner goes bazirk when I just WROTE a program. Luckily most virus scanners do not trigger on kol library code any more.

KOL and its maker have nothing to do with malware.

you didn't understand what i meaned :(
you want to make KOL compatible with FreePascal, ok... but it IMPOSSIBLE without WinAPI units replacing (on FreePascal, need to get it from Delphi) OR without using JEDI WinAPI units on FreePascal. And "Variants" and "SysUtils" accordinly linked "hard" with JEDI. It what i meaned.

I understood what you mean.
I have a fully working setup for fpc 2.5.1 in alpha and I am doing my own version of the windows files right now to avoid copyright issues (using Rudy Veldhuis new conversion tool)
I mean this setup compiles almost anything from available KOL sources you throw at it.

Btw: fakevariants also works for FPC, so that problem is non - existant.

I do not say it is easy, but it can be done and I can prove it's (almost) done.
Some of you already have the alpha release.

But what I ment was that you cannot expect a framework (not a set of routines) like KOL is to be compatible with a framework like the VCL or the FPC equivalent for that matter.

What IS compatible is the compiler itself.
Although FPC generates a bigger binary, it will compile 99.9% delphi 7 (and almost 90% D2006) sourcecode.
Changes to KOL are very minor and do not impact KOL for Delphi.

I'd be happy to share this alpha with you too.

Glad to hear it. it ok, i can wait some time ^_^
only one of my miranda plugins used KOL alot, others can be modified not to use KOL (just need to disable 1-2 small advantages).

PS. i modified CommCtrl unit from FreePascal to avoid ActiveX module using (it very easy and econom size even without modules replacing)

try this and you will see the work has become much easier:

in fpc.cfg (or fpc commandline):

#the usual
-Mdelphi
.....

#undefine compiler indicator
-uFPC
#define Delphi 7
-dVER150

<smile> It works, and not much is missing <smile>
Works only for trunk: VER2.5.1

erm.... all nice but i use FPC condition somewhere in my project....

Google desktop or - better - old fashioned Grep ;-)
Try it on a small project. You will be amazed.
If you do it like the above - at least with d5 windows sources - the changes are minimal, say a couple of fixes in windows.pas (only';') and a few small undiscovered bugs in kol.pas and a few things that really need a fpc implementation, but the compiler tells you what is missing.
It is all very minimal.

If you let FPC define on, there are much more problems.

I understand you want a 64 bit kol, but in that case, let's minimize the defines.
I am making good progress with a new windows directory translation anyway.

Regards,

Thaddy

btw: translation is made by hand after automated header translation.
If the compiler fails, I adapt the routine. It is completely separated from any borland/inprise/codegear/embarcadero translations.
I can't help both fpc and dcc give away their declarations, which are not copyrighted anyway (ms copyright is, but open - even freeware -sourced provided their name is in the headers.

i made condition to not to use KOL if need 64 bit compilation. but to have it in my projects, i still must use some FPC units and use "FPC" condition too :(

Can you give me an example of such a unit, than I can see if I know a solution?

This is generally not a problem. You can compile the fpc units separate f.e. if they require mode objfpc. They will still link succesfuilly.
A problem is that fpc's rtl has a lot of units that depend on fpc sysutils.pp. Just like for kol delphi sysutils this is possible but not an ideal situation because of code bloat.

Current compatibility is so good that it even includes the misarable granularity of the runtime library units.

i have places where winapi different just by "var something:any_type" and "someting:pany_type". some places can refers with sysutils but i trying to avoid it in my projects. so? it not problem. and keep source files, not compiled not always possible due to many crosslinks on includes... btw, if i use sources, i can't compile ComObj for example... it not so critical (need for one project only)
btw, sources you can find here: http://code.google.com/p/delphi-miranda-plugins/

1. Yes, but that is why I am translating the winapi again, to be delphi compatible instead of FPC compatible. In other words: replace fpc windows stuff with Delphi stuff. This has always been the case for kol: Vladimir did something similar for FPC 1.X in ppdelphi.zip, still available, but old. Basically what I do is update that to bring it to FPC 2.5.1 (soon 2.6).
2. I also know about the sysutils unit and simply write my own, without the dependencies on codebloat.
3. I have many projects with ComObj, but didn't try that on fpc yet. I suspect I will have to write a variants unit of some kind. If these are only COM compatible variants, this is not very difficult for an experienced programmer. Leave out the custom variants stuff.

New website to follow: <alpha, but with content> http://thaddy.com/drupal

thanks for work. time of time i clear/rewrite some code parts so, while it all in my "development", it can be changed freely. i hope, not me only will find it usable. But problem still actual: is that WinAPI modules will be compilable on 64 bit?

If anything goes to plan it should be possible to create delphi 64 compatible windows headers. kol itself is a different story, although the pas_version may be not too difficult to translate to 64 bits.

Btw: I did a scan on the fpc windows and it may even be possible to solve it with overloads. More experiments ;-)
But first I have to finish a PHP syntaxhighlighter for the new website.

and tabs for sources please!

Will come this weekend.

Clarification:  The wiki is accessible to the pbiluc, and for the convenience of our group, very few pages are password-protected, only those most subject to vandalism, like the front page and sidebar.  We've opened up our wiki to members of the pbiluc who wish to contribute, but we expect that they should follow the policies set forth on the site, as well as the standard wiki etiquette of respecting the contributions made by others.Kottkamp's deletions were not in line with our wiki editing policies.  Nor do they show respect for others who spent time researching and adding information to the wiki.  The deleted information was not biased, nor was the information inaccurate.  His edit was self-serving and subtracted from the value of the profile page, rather than adding to it.Even so, had the IP address traced to anywhere but a government computer, I would have simply restored the page and moved on.  The key problem I have is the use of taxpayer-funded resources to interfere in the political process and whitewash a serving politician.