Building a Windows-native server executable

[Yuri Lifanov]

Ok, thanks for the quick response. I didn't know about the ports of pthread and libdl - thanks for the tip.

I'll try to get some time for this and will be back in touch if it does happen.

Thanks again for your input, I appreciate it.
________________________________
From: Alan DeKok <aland at deployingradius.com>
Sent: Tuesday, May 20, 2025 15:32
To: FreeRadius developers mailing list <freeradius-devel at lists.freeradius.org>
Cc: Yuri Lifanov <Yuri.Lifanov at onespan.com>
Subject: Re: Building a Windows-native server executable

[You don't often get email from aland at deployingradius.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On May 20, 2025, at 5:47 AM, Yuri Lifanov via Freeradius-Devel <freeradius-devel at lists.freeradius.org> wrote:
> I was, naively, thinking of trying to port the current FreeRADIUS server to run on Windows natively for a work use case where Docker, VMs and WLS aren't an option.
>
> I suspect this is a massive amount of work, but wanted to get a confirmation.

  It's not too bad.  Many years ago (before FreeRADIUS!)  I worked on a RADIUS server which ran on Linux, *BSD, Irix, HP/UX, and Windows.  It's a bit of a pain but it's not impossible.

> Aside from the build system and the dependencies, what do you think would be the first major challenge?

  IIRC there's a Windows port of libpthread, and a windows port of libdl for dynamic linking.  Those two libraries cover the bulk of the porting effort.

  After that, it's just a matter of getting the header inclusions correct.  The Windows APIs are _sort of_ POSIX, but not quite.  It's really frustrating.

  It should really be just time to get it done.  You shouldn't have to modify much of the FreeRADIUS source code.

  My $0.02 would be to start with the "master" branch.  While it's a lot bigger than v3, it's better organized.  And, we're not going to accept major changes to there v3 branches.  We don't have the resources to work on multiple feature branches at the same time.

  The good news about the build system is that you can just nuke things you don't need.  If a module doesn't build, remove its "all.mk" file, and it won't be built.

  Start with the src/lib/util/ library.  It has the lowest level APIs used by the server.  If you can get that building on Windows, the rest should be just more of the same.

  After