Why are there so few open source Pascal/FP projects?

[anyone]

You are right, FPC programs do not require an external run time library to operate.  Just a note, it is also possible, depending on how you code, to create a VC++ application that does not use/require the VC++ run time libraries but, it's not straightforward.

I really appreciate your acknowledgement and additional notes on this.

[PascalDragon]

The reason I choose FPC instead of C# .NET and VC++ when creating console apps simply because FPC creates standalone Win32 executable (am I right)?
C# .NET console app requires .NET Framework. VC++ requires VC++ runtime.
Please correct me if I am wrong.

You are right, FPC programs do not require an external run time library to operate.  Just a note, it is also possible, depending on how you code, to create a VC++ application that does not use/require the VC++ run time libraries but, it's not straightforward.

At least when using Visual Studio it's simply done by switching the option Runtime Library in the page Code Generation from Multithreaded-DLL to Multithreaded. The command line switch is /MT compared to /MD.
The resulting binary will only depend on core Windows libraries like Kernel32.dll or User32.dll.

[marcov]

Hmm, does that also work for DLLs ? I use wrapper DLLs and that now requires a mess of runtimes to manage would be nice if that could be eliminated.

[440bx]

At least when using Visual Studio it's simply done by switching the option Runtime Library in the page Code Generation from Multithreaded-DLL to Multithreaded. The command line switch is /MT compared to /MD.
The resulting binary will only depend on core Windows libraries like Kernel32.dll or User32.dll.

Thank you for that information.  Visual Studio 2017 is what I use.  I guess I should try again with your suggestion which I believe is one of the many things I tried but, I could be wrong about that.  Though, at this point, I avoid VC++ and VS (except for debugging).  MS' unsolicited VS updates have resulted in some of my programs no longer compiling, it gets tiresome to figure out what happened and, correct the "problem" only to have it happen again at a later time after another unsolicited update.

All that said, thank you again.

[PascalDragon]

Hmm, does that also work for DLLs ? I use wrapper DLLs and that now requires a mess of runtimes to manage would be nice if that could be eliminated.

Yes, it's independant of whether you're compiling a DLL or an executable.

At least when using Visual Studio it's simply done by switching the option Runtime Library in the page Code Generation from Multithreaded-DLL to Multithreaded. The command line switch is /MT compared to /MD.
The resulting binary will only depend on core Windows libraries like Kernel32.dll or User32.dll.

Thank you for that information.  Visual Studio 2017 is what I use.  I guess I should try again with your suggestion which I believe is one of the many things I tried but, I could be wrong about that.

At work - where we use MSVC - we've used that already back with VS 2008.