The Free Pascal team is pleased to announce that version 2.2.2 is
released and available for download for all major platforms:
(in alphabetical order)
Dos, FreeBSD, Linux, Mac OS X, OS/2, Windows, Windows CE
For different CPU types and both in 32 and 64 bit versions where applicable.
Version 2.2.2 is the new stable version. It contains mostly bugfixes,
and selected backported features. No major new features are introduced.
Version 2.2.2 also has a cleanroom implementation of some routines that
were suspected of copyright infringement. You are urged to upgrade to
this new version to avoid possible copyright issues.
Finally, the documentation has been revised completely and was brought
up-to-date, so it describes the current compiler and RTL behaviour as
closely as possible.
You can download your copy from the usual location:
http://www.freepascal.org/download.var
A list of major changes is available on
http://wiki.freepascal.org/User_Changes_2.2.2
If you download from a mirror, you may have to wait a couple of days
for the mirror to pick up the new version.
Enjoy,
The Free Pascal team.
>Hello,
>
>The Free Pascal team is pleased to announce that version 2.2.2 is
>released and available for download for all major platforms:
>(in alphabetical order)
>
> Dos, FreeBSD, Linux, Mac OS X, OS/2, Windows, Windows CE
>
>Enjoy,
>
>The Free Pascal team.
Yay, my favorite language in my current favotite compiler! Thanks!
Hans, |
http://www.hansotten.com, http://weblog.hansotten.com
Excellent stuff! Thanks.
I fetched FPC 2.2.2 and the latest lazarus from SVN and built it for
GTK+ on Ubuntu.
I really can't believe how much these projects have moved on since I
last looked (0.9.24 on Windows). The GTK+ IDE is looking very slick and
is now at a stage where it can definitely be used for real-world
development now (albeit with a few minor quirks/omissions in some of
the LCL for GTK+ still).
Keep up the great work.
--
Slower Than You
Thank you for the announcement. To add a little bit more info:
Additionally to what Marco said there is finally even a new version
for DOS (dos222.zip for GO32v2), with a usable IDE.
Unfortunately the Win32 IDE is not usable under WIN98. I reported
this bug here "Non-functional Del key in FP-IDE"
<http://www.freepascal.org/mantis/view.php?id=8978>
Still alive are the nasty CRT bugs reported by many user (see
my post from end on may 2007 in this group).
I have given up the hope that reporting these bugs in Mantis will
eventually get them fixed. Meanwhile I know the places where to fix
them in the source (although Marco thinks this will break code for
e.g. multi-byte character strings).
But all in all the new versions definitely are a great progress!
Thanks to Marco and the team.
Wolfgang
--
In order to e-mail me a reply to this message, you will have
to remove PLEASE.REMOVE from the address shown in the header
or get it from http://home.netsurf.de/wolfgang.ehrhardt
(Free open source Crypto, AES, CRC, Hash for Pascal/Delphi)
Due to heavy pressure fixed in 2.3.1. Of course, now my wife will cheat on
me, my children cry, and my dog will run away because I neglect them.
(If I were married and had children + dog)
Btw, do you happen to use some odd ball kbd? Like the original PS/2's that
are favoured by some programmers?
> Still alive are the nasty CRT bugs reported by many user (see
> my post from end on may 2007 in this group).
> I have given up the hope that reporting these bugs in Mantis will
> eventually get them fixed. Meanwhile I know the places where to fix
> them in the source (although Marco thinks this will break code for
> e.g. multi-byte character strings).
Things have started moving on the unicode front. Maybe we need a crtw. That
together with the near extinction of win98 will eradicate the need for
codepages.
>
>Btw, do you happen to use some odd ball kbd? Like the original PS/2's that
>are favoured by some programmers?
No, but as I wrote in the mantis background, this is really the
standard what is send from the keyboard. You have to distinguish
between cursor pad ins/del etc and num pad ins/del etc keys. The alpha
character #$E0 only occurs in the Win32-IDE under Win98, the DOS-IDE
and Win-32 under Win2000+ do not have this problem, always with the
same keyboard.
>
>> Still alive are the nasty CRT bugs reported by many user (see
>> my post from end on may 2007 in this group).
>
>> I have given up the hope that reporting these bugs in Mantis will
>> eventually get them fixed. Meanwhile I know the places where to fix
>> them in the source (although Marco thinks this will break code for
>> e.g. multi-byte character strings).
>
>Things have started moving on the unicode front. Maybe we need a crtw. That
>together with the near extinction of win98 will eradicate the need for
>codepages.
These are not codepage problems! IMHO they are simply buggy
implementations:
1) If you define a window, and the crt output does not respect this
window I call it a bug, see e.g. fpcbuild-2.2.2\fpcdocs\crtex\ex5.pp
2) If strings longer the the current console width are not wrapped but
truncated, this also is a bug.
And these problems also occur under Win2000 and XP, ex5 is too bizarre
to be shown here and therefor left as an exercise :)
program tcrt;
uses
crt;
const
long='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
var
i:integer;
begin
for i:=1 to 5 do writeln(long);
end.
Output on console with 80 character width:
D:\TMP>ver
Microsoft Windows 2000 [Version 5.00.2195]
D:\TMP>tcrt
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
STUVWXYZabcdefghijklmnopqrstuvwxyz
D:\TMP>tcrt
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQR
D:\TMP>
But once again: despite these problems FPC is an excellent product!
And because the source is available, every experiemced programmer
could theoretically fix them for his needs.
The URL I quoted is that this was the standard for _OLD_ keyboards, and
newer ones dropped it. Note that plain dos and linux use raw scancodes, for
windows in general they are cooked (processed)
This is logical, otherwise on the same machine you would have the same
keycodes, regardless of OS.
>>Things have started moving on the unicode front. Maybe we need a crtw. That
>>together with the near extinction of win98 will eradicate the need for
>>codepages.
>
> These are not codepage problems! IMHO they are simply buggy
> implementations:
>
> 1) If you define a window, and the crt output does not respect this
> window I call it a bug, see e.g. fpcbuild-2.2.2\fpcdocs\crtex\ex5.pp
True.
However if you write data in the system (MBCS) encoding, you also expect not
to wrap before you reach the end of the window. If it does it is also a bug.
And these two behaviours were balanced here. (to my knowledge btw, Florian
did something after that to lessen pain)
> 2) If strings longer the the current console width are not wrapped but
> truncated, this also is a bug.
> And these problems also occur under Win2000 and XP, ex5 is too bizarre
> to be shown here and therefor left as an exercise :)
Mantis # ?