We are planning the release of Lazarus 2.2

[Awkward]

No offense, but I hope they drop even Windows 7.
There's absolutely no need to use the newest IDE on old SOs when you can still use old versions of Lazarus.

No offense but did you checked how much people uses Windows 7? Dropping Win7 support can be VERY bad decision. Especially if we will remember what even DOS still supported by compiler.

[Gald]

No offense, but I hope they drop even Windows 7.
There's absolutely no need to use the newest IDE on old SOs when you can still use old versions of Lazarus.

No offense but did you checked how much people uses Windows 7? Dropping Win7 support can be VERY bad decision. Especially if we will remember what even DOS still supported by compiler.

Actually, when i said Win7, it was an hyperbole.
But, in fact, Win7 will no longer receives updates.
Even Embarcadero already dropped support for Win7 few years ago.
But I know that a lot still use Win7 today, but no one uses 3.11.

The list of new features are very good!
Some things they do that even Delphi can't, like the TCheckGroup, and Mask support for hexadecimal and binary.

[Zvoni]

I think there is a misunderstanding:
You have to differentiate between your dev-machine and a possible target-machine.

I agree that it doesn't make sense to install the newest IDE on Win2K, but developing on a Win7/10-machine, and the final program being able to run on a Win2K/XP-machine are two different things.

EDIT: Except if you're talking about the LCL supporting the WidgetSet used on Win2K, which should still be "win32"

[marcov]

We got no feedback on the RCs, so I assume it all works fine :-)

[lucamar]

We got no feedback on the RCs, so I assume it all works fine :-)

Isn't a little early? I took this to be more of a heads-up to prepare to start RC-testing when there is an RC available, since Martin didn't say there was one already: he just noted what the new release is about. Or that's how I took it; I might be absolutely wrong

[dbannon]

So, I need to point out that fixes_2_2 (downloaded this morning) has this bug, https://bugs.freepascal.org/view.php?id=38922

It affects windows developers who are using HiPDI screens and making binaries that will be used on normal screens OR developers using normal DPI and the binaries may possibly be used on a HiDPI system.  Important to note that the developer testing the code on his/her working system will not pickup this problem !

What happens is that forms that are not shown at startup, are having their FormShow event called during startup. The form is not actually shown, I guess its not ready at that stage. So, in some cases that does not matter but in other cases, code in the FormShow method depends other things having happened and a crash results. Personally, I would greatly prefer to have FormShow called when the form is being shown !

As many median priced laptops these days have hiDPI screens, we should see quite a lot systems being affected. 

Very easy to demonstrate, on (eg) a normal DPI screen system, make the usual default main form, add a second form, Unit2 and in its OnShow event, put "showmessage('Unit 2 FormShow'); "

Take the binary to a HiDPI system and run it.  Or take the project there and compile and run it (being careful not to make unit2.lfm rewrite).

The difference in DPI relates to a line in the lfm file, DesignTimePPI = 144

The bug report identifies the revision that the problem first appeared in trunk and also mentions a later fix that has subsequently been reversed .......

Davo
 

[wp]

Is Windows 2000 still supported?

I still have a VM with Win2000, pulled myself a Laz-trunk and built it on the basis of FPC3.2.2. "make bigide" resulted in an IDE which did not start. But "make all" made it work. I removed all the packages that I do not need, and then added TAChart, TurboPower, DateTimeCtrls, and DbfLaz - still working. Compiled and ran some of my applications, they all work.

So the message is: there is a good chance that you may be able to build your application with Laz 2.2/FPC3.2.2 on Win 2000. Of course - no guarantee...

[Martin_fr]

Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.

I don't have W2000 for testing. But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.

Strange though. I thought 2.0.x had fpdebug included too. So that should have had the same issue?

[trev]

Will there be a native apple silicon (M1) version available for download with the release of Lazarus 2.2?

I don't have a M1, so I can't test and build there. Maybe there is a volunteer?

Maybe trev can help since he's doing nightly builds for that platform anyway?

There's a small complication: the M1 operating system (Big Sur) will not execute unsigned code. The code can be signed with an ad hoc signature (ie without an Apple developer Certificate) but it is only valid for the machine on which it was signed. For those who want it to be "out of the box", every executable in the Lazarus distribution would need to be signed with an Apple Developer Certificate. Whether Lazarus recompilations would be ok, is unknown. The Apple linker will sign anything linked on an M1 with an ad hoc signature by default which may be ok.

The executables in the daily snapshots I do, need to be ad hoc signed by the enduser which I don't see as a big issue because anyone installing daily development (trunk) snapshot versions should possess the knowledge to do so (or at least be able to follow the explanation to do so which I added to the Wiki and link to).

I've been meaning to add signing and possibly notarizing of the executables with my (personal) Apple Developer Certificate, but as I haven't had any feedback since automating the daily build processes as launchctl daemons, I didn't pursue it.

Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.

[Wallaby]

Really, I think the easiest thing to do may be to simply provide a script to build Lazarus from the release source on M1 machines. It takes about 9 minutes on my base model M1 Mac mini including syncing the source repository.

Another way might be creating a simple shell script that checks if there is a signature on the Lazarus bundle and ad-hoc code-signs it if not. Then launches the Lazarus executable.

This script would be used to start Lazarus by user.

[marcov]

We got no feedback on the RCs, so I assume it all works fine :-)

Isn't a little early? I took this to be more of a heads-up to prepare to start RC-testing when there is an RC available, since Martin didn't say there was one already: he just noted what the new release is about. Or that's how I took it; I might be absolutely wrong

I'm talking about FPC 3.2.2, see e.g. the RC1 issues page: https://wiki.freepascal.org/Issues_3.2.2  No mention of 2k or XP. Conclusion: nobody cares.

[PascalDragon]

We got no feedback on the RCs, so I assume it all works fine :-)

Isn't a little early? I took this to be more of a heads-up to prepare to start RC-testing when there is an RC available, since Martin didn't say there was one already: he just noted what the new release is about. Or that's how I took it; I might be absolutely wrong

I'm talking about FPC 3.2.2, see e.g. the RC1 issues page: https://wiki.freepascal.org/Issues_3.2.2  No mention of 2k or XP. Conclusion: nobody cares.

Well, considering that no one found the problem with variants mentioned here during the RC phase, but only after the release, I'd have this conclusion: nobody cares about RCs.

[dbannon]

Well, considering that no one found the problem with variants mentioned here during the RC phase, but only after the release, I'd have this conclusion: nobody cares about RCs.

or perhaps no one cares about variants ?  In a strongly typed language, maybe that makes sense ?     

Davo

EDIT: I spent a good part of today getting a working Fixes on Windows to test for the bug I mentioned above, yep, I care about RCs !

[Martin_fr]

Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.

But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.

ok, the reference in fpdebug is now dynamically loaded.
If it fails an alternative had already been in place. So fpdebug may (or may not) work on win 2000. (not a goal to support this part, but if it does, well good)

[ssawgift]

Is Windows 2000 still supported? The reason I ask this is that I see that the latest svn trunk build has a dependency on DebugBreakProcess which is not available on Windows 2000.

But if that is the reference in fpdebug, I think that can be dynamically loaded. I have to look into this.

ok, the reference in fpdebug is now dynamically loaded.
If it fails an alternative had already been in place. So fpdebug may (or may not) work on win 2000. (not a goal to support this part, but if it does, well good)

I can verify the latest build runs on W2k. But debugging seems slow - F7/F8 takes about 20% CPU usage.