win7 x64, delphi xe2, KOL3.21
----------------------------------
{$DEFINE x64} in project condition define
----------------------------------
1)delphicommctrl.inc

   TMsg = packed record
   CASE Integer OF
   0:  (
       hwnd: HWND;
       message: UINT;
       {$IFDEF x64}
       _x64_DW1: DWORD;
       {$ENDIF}
       wParam: WPARAM;
       lParam: LPARAM;
       time: DWORD;
       pt: TPoint;
       {$IFDEF x64}
       _x64_DW2: DWORD;
       {$ENDIF}
       );
   //1:  ( Bmsg: Windows.TMsg; );
   2:  ( Cmsg: TMsgDecoded; );
   end;

2)MsgDecode.pas
----------------------------------------------
 TMsgDecoded = packed record
   hwnd: HWND;
   Cmessage: TMessageDecoded;
   _filler: Word;
   {$IFDEF x64}
   _x64_DW1: DWORD;
   {$ENDIF}
   wParam: WPARAM;
   lParam: LPARAM;
   time: DWORD;
   pt: TPoint;
   {$IFDEF x64}
   _x64_DW2: DWORD;
   {$ENDIF}
 end;

if use {$DEFINE UNICODE_CTRLS},

const "EditActions_Packed"  declare must modify, otherwise, editbox can't input any char

This is because KOL disables aligning ({$A-}). Same with KOL.TMenuitemInfo.
Why KOL redeclare this (e.g. not uses this records from Windows unit)...

"Little code"? You are optimist :-)

I Only test my old progaram in win32, not fully test all controls.

I can't undstand why kol define {$A-}, redeclare TMSG, this seems strange.

I think win32, win64, unicode support compatible with delphi, freepacal is the most import things to KOL new version, 100-200bytes reduce is not the most import.

> I think win32, win64, unicode support compatible with delphi,
>  freepacal is the most import things to KOL new version,
>  100-200bytes reduce is not the most import.

Then please try this http://yadi.sk/d/Z0uMP31_67nJY
It is my adaptation of KOL for x64 delphi compilers and for fpc.

thanks a lot :)

Can we host that on kolmck.net as unofficial translation?
I am interested in merging some of my 64bit code into it, but you beat me with a full version ;)

I am sure Vladimir will have a look at it. (and can make it official)

Will experiment with it in the weekend.

Regards,

Thaddy

First test observation:

Too much int64 instead of NativeInt. The code would be more compatible if you observe the native types. It would be possible to keep one source for both 32bit and 64bit. For older compilers we can define the NativeInt, NativeUINT etc types.

Also, for both Freepascal and Delphi, {$DEFINE WIN64} is better than X64, because the compilers already understand that. After 5 minutes first compiled kol app based on kolappexpert ;-) Good work.

Observation 2: simple kolform64 fpc:64000 bytes, DCC64:84992 bytes.
FPC271 generates smaller code... ;-)

Of course I mean {$IFDEF WIN64}, not $DEFINE ...., because it is implicitly defined as WIN64.
Also my kol notepad code runs in unicode 64 bit and I have no problems yet.
Again, good work!

Thank you, Thaddy. Your opinion is much appreciated. But I'm afraid you were testing some other translation. In my version I use the type which is defined in FPC: PtrInt/PtrUInt, and I define it like this in kol.pas:

.
So my translation is compatible with the 32-bit compilers (even with D2, but this is thanks to Vladimir Kladov of course). And I don't use X64 symbol, only WIN64 as you suggested.

And answering your question, yes you can host it on kolmck.net.

Ok, I will ask Vladimir to do that. You patch seems not intrusive and I have been playing with it all weekend ;-) Most, but not all of my projects (remember I do not use mck) compile with very little or no change....
I will write a little article about it later today on fpc.thaddy.com.
VERY good work.

For those who want to test:

Here's my commandline kolwhois for fpc2.7.1:
c:\kolx64>ppcrossx64 -Mdelphi -Rintel -OpATHLON64 -CX -XX -Xs -O4 -Os -B  -CpATHLON64 -CfSSE3 -FuC:\fpc\trunk\packages\winunits-base\src;C:\fpc\trunk\packages\rtl-objpas\src\inc;C:\fpc\trunk\packages\rtl-objpas\src\win;C:\fpc\trunk\packages\rtl-extra\src\win -FiC:\fpc\trunk\packages\rtl-objpas\src\inc  whoiskol.dpr

Note you need a fresh build from today/now , because Michael van Canneyt and me fixed winsock.pp 10 minutes ago ;) There will be more fpc side fixes when accepted, so the strange incompatibilities between delphi-win and fpc-win go away.

Ok, I will ask Vladimir to do that. You patch seems not intrusive and I have been playing with it all weekend ;-) Most, but not all of my projects (remember I do not use mck) compile with very little or no change....
I will write a little article about it later today on fpc.thaddy.com.
VERY good work.

For those who want to test:

Here's my commandline kolwhois for fpc2.7.1:
c:\kolx64>ppcrossx64 -Mdelphi -Rintel -OpATHLON64 -CX -XX -Xs -O4 -Os -B  -CpATHLON64 -CfSSE3 -FuC:\fpc\trunk\packages\winunits-base\src;C:\fpc\trunk\packages\rtl-objpas\src\inc;C:\fpc\trunk\packages\rtl-objpas\src\win;C:\fpc\trunk\packages\rtl-extra\src\win -FiC:\fpc\trunk\packages\rtl-objpas\src\inc  whoiskol.dpr

Note you need a fresh build from today/now , because Michael van Canneyt and me fixed winsock.pp 10 minutes ago ;) There will be more fpc side fixes when accepted, so the strange incompatibilities between delphi-win and fpc-win go away.

Dimitry, I put this on the fpc developers list:
----
For anyone developing with KOL, Dmitry K did a - as yet unofficial - 64 bit Windows version that is sufficiently stable to be considered to be added to the official branch at kolmck.net.
You can obtain it here: http://yadi.sk/d/Z0uMP31_67nJY

If you are interested and know something about how to use KOL/MCK, plz test and let me know.

Remember to compile with at least -Mdelphi  -Rintel -dPUREPASCAL
Unicode version doesn't require -Mdelphiunicode but rather: -dUNICODE_CTRLS
This is because KOL already had unicode before FPC.

Thaddy

p.s.:
ppcrossx64 outperforms dcc64 in size and speed, at least with KOL.

---

Dimitry, I put this on the fpc developers list:
----
For anyone developing with KOL, Dmitry K did a - as yet unofficial - 64 bit Windows version that is sufficiently stable to be considered to be added to the official branch at kolmck.net.
You can obtain it here: http://yadi.sk/d/Z0uMP31_67nJY

If you are interested and know something about how to use KOL/MCK, plz test and let me know.

Remember to compile with at least -Mdelphi  -Rintel -dPUREPASCAL
Unicode version doesn't require -Mdelphiunicode but rather: -dUNICODE_CTRLS
This is because KOL already had unicode before FPC.

Thaddy

p.s.:
ppcrossx64 outperforms dcc64 in size and speed, at least with KOL.

---

OK, thank you.

KolEdb.pas, Err.pas не компилируются с этой версией KOL. Первый - ещё и потому, что в KOL.pas игнорируются ассемблерные функции

Поправка: не компилируется для FPC

err.pas is not translated for 64 bit, but the other functions should work. Also, fpc can now handle the asm code from kol. Can you give a small example that fails with fpc2.7.1 trunk?

Дмитрий К © KOLx64  is more stable than official, it resolve some bugs, it can compiled in XE2 without any change. but also have unicode bugs in east-asia windows like official version. elg: editbox can't input any charater.

sugeest: kol new version base on Дмитрий К © KOLx64, let kol more powerful

Дмитрий К © KOLx64 can work for lazarus1.2.0 win32, win64 without any code change.

Is it possible to get MCK ported for lazarus 64bit?

Possible, yes. Should be quite easy to do.
But I don't use MCK nor Lazarus so I can't help.

Possible, yes. Should be quite easy to do.
But I don't use MCK nor Lazarus so I can't help.

Possible, yes. Should be quite easy to do.
But I don't use MCK nor Lazarus so I can't help.

That's not just logic. That's really selsibne.

For one thing,  Connect  will set both the Name and Port for you, so you can limit the code to justClient := TSocketObj.Create;Connect('192.168.1.100 ,1234);but doing it your way shouldn't cause a pbeolrm.  What exception (if any) is it throwing?As for demo, one of the best demos is already in the code.  Look at how THTTPGetObj uses the underlying socket.

Does anyone have a copy of the file kol322-x64-unofficial.7z? It's not possible to download it from the new site kolmck.ru

Get it here: http://www26.zippyshare.com/v/hJ8PYBLq/file.html

Кстати, нет смысла использовать PtrInt - с D7 (а может быть и с D5) можно напрямую писать NativeInt/NativeUInt, а про версии ниже 7 уже пора забыть. FPC также понимает их в зависимости от разрядности.

Я в своей редакции KOL использую NativeInt/NativeUInt

Следует учитывать, что NativeInt/NativeUInt в Delphi до версии 2009 были объявлены неправильно и имели размер 8 байт вместо 4-х. Нужно переобъявлять этот тип в этих версиях. Вероятно, с этим может быть связано желание использовать PtrInt вместо NativeInt.

Согласен, наврал. Сейчас проверил - действительно, в D7 NativeInt фактически идентичен int64. Но их можно переопределить. Тогда в КОЛе для delphi ниже 2009 переопределить NativeInt = integer и NativeUInt = dword вместо Ptr'ов, в остальных случаях ничего не переопределять. И везде в KOL заменить на NativeInt/NativeUInt.

Кстати, можно переопределить в заменах системных модулей. Прописал в System.pas правильно и шабаш. Если уж пользоваться KOL, то с заменой.