graemeg

That's exactly what I'm doing. :-) The world doesn't need another clone of FPC or Delphi. Blaise is Pascal for 2026+ without legacy baggage.

Do you know if there is ongoing work to support x86_64 on Windows?

Every new compiler needs to be bootstrapped by something - unless you head straight into Assembly Language from day1 - but I'm not that crazy!

Yes, Blaise reached self-hosting after just 7 days. Meaning it could compile itself, and was byte-for-byte identical to the bootstrapped version. The language was absolutely barebones, but that's not the goal at that stage. The first (FPC) compiled binary is called the Stage 1 binary. That binary then compiles the compiler code to make a Stage 2 binary (a read Blaise compiler binary). Then Stage 2 compiles the compiler code again to make a Stage 3 binary. Self-hosting is when the stage-2 binary and stage-3 binaries are byte-for-byte identical. Blaise has already achieved that.

I'm currently actively working on removing the FPC and GCC bootstrap requirements. After which Blaise would become it's own bootstrap compiler.

fpGUI Toolkit will be made to work with Blaise.

[1] Homepage (terrible looking): https://fpgui.sourceforge.net/ [2] Github repo: https://github.com/graemeg/fpGUI/ The Discussion area has some interesting conversations and screenshots.

And FPC also supports interfaces without GUIDs via the {$interfaces CORBA} directive, and it too, supports the Supports(...) construct just fine.

Delphi is just very Windows-centric with a lot of things they do.

It's magic! ;-)

Not wanting to go into too much technical details: Blaise's interface system uses TypeInfo pointers as identity tokens. Meaning manually added GUIDs are not needed.

The two Supports() forms. Delphi has two overloads:

// 1. Boolean test function Supports(AObject: TObject; const IID: TGUID): Boolean;

// 2. Combined test + assignment (the useful one) function Supports(AObject: TObject; const IID: TGUID; out Intf): Boolean;

In Blaise, without GUIDs, the second argument is an interface type identifier rather than a GUID. The most natural design is to treat Supports as a compiler intrinsic (like is/as) rather than a library function, because the second argument isn't a runtime value — it names a type.

So Blaise code looks like this:

if Supports(Obj, IFoo) then ... // boolean test if Supports(Obj, IFoo, FooRef) then ... // test + assign fat pointer

Thank you. fpGUI is 20 years old this year! :-D

Yes it has been fantastic to work with QBE so far. It's way simpler than LLVM, giving you about 70% of the LLVM performance, for 10% of the effort. :)

Only downside is Windows support.

Every new project starts at Day 1. :-)