[Opinion needed] Considerations on Windows support

[Vitaly Orekhov]

I decided to open this thread for discussion as I'm going to take long-term (if I won't run in any circumstances that don't depend on me) Windows support on my own, after seven years of half-dead state of Prosody for this platform.

The last version built for Windows was 0.9.8, way back in 2016, when Windows XP was just two years after entering EOL support lifecycle and Windows Vista SP2 had one year more to live. Given that, Prosody's executables and libraries were compiled against VC100 (Visual Studio 2010) with Windows XP x32 subsystem, Lua version was 5.1, which is now not supported by current versions of Prosody. The list below is a properties summary of core libraries for Windows build of Prosody 0.9.8, for easier reading and reference.

• Target OS: Windows XP x32
• Toolchain: Visual Studio 10 2010
• Lua: 5.1
• OpenSSL: 0.9.8k
• libexpat: 2.1.0 (probably)
• libidn: 1.15
• zlib: 1.2.8

Smell the way outdated stuff, right? I do and I want to change this. But I would like to hear audience's opinion, won't hesitate to hear former Prosody for Windows users or current maintainers for other platforms and officially supported ones.

I'm looking at bookworm branch of Debian packages as a reference, keeping in mind our own dependencies list.

What I see now from core libraries?

• Lua: 5.4
• OpenSSL: 3.0 or newer
• libICU: 72.1 or newer (replaces libidn)
• libexpat: 2.4.1 or newer

zlib had gone to optional modules, as compression module is deprecated. LuaEvent, LuaReadline (not supported on Windows), LuaUnbound and LuaDBI are still optional.

-----

So what's the problem? I don't know what to target now. The target OS discussion was brought up in the Chatroom when I've been talking about native escape sequences support in Windows 10 November Update and newer. People who still use preceding Windows versions aren't going to have that nice colored output in the console because the current implementation of logging has no room for a trick with console output mode switching from early 0.10 versions and will have text fully painted. But the console prettiness isn't the main concern. I'm speaking about security and fresh tool here.

New target OS

Starting with Visual Studio 2015, the main subsystem becomes Windows Vista (NT 6.0). Binaries compiled with this subsystem and STL are not compatible* with XP and Server 2003 (NT 5.1 and 5.2 respectively). There are special versions of toolsets with _xp in the end (vc140_xp and vc141_xp, aka Visual Studio 2015 and 2017 toolsets for XP). ReactOS is affected too, since it targets NT 5.2 platform. I might make a functioning build for one, but it will be 'just for fun' and never will be a candidate to be an official Prosody build.

I don't want to put any effort in maintaining a version of operating system that requires special treatment, thus I set Windows Vista as allowed minimum. It also has kernel extensions, which noticeably improve compatibility with Windows 7+ software, but from what I see in Windows API calls in C libraries of Prosody, we probably can run natively on this OS without need to take tweaked Windows Server 2008 (6.0.6003) kernel**.

New target architecture

Application and libraries target architecture is another interesting question. When Windows 11 came out, Microsoft hadn't provided a 32-bit distribution and raised the system requirements in general. Some widely-known Linux distributions dropped compiling i386/i686 installation media years ago, leaving amd64 the only option. That means I want to make official Prosody for Windows builds exclusively x64, as there are major problems arising from optional dependencies coming from LuaDBI.

What's the problem with LuaDBI?

PostgreSQL and MySQL are the culprit. As I read through the Chatroom, maintainers recommend PostgreSQL for Prosody as the database solution and have quite controversal opinion on MySQL (nearly the same as on Windows). Current PostgreSQL versions (>=11.0) are exclusively x64 and require at least Windows 7. Windows Vista might be able to handle it with kernel extensions, but I doubt it. If we will provide official x32 builds of Prosody, we're likely to open a huge security hole on legacy OS caused by severly outdated PostgreSQL.

Oracle maintains MySQL 5 to this day. This version has builds both for x32 and x64 systems, but their support of Windows Vista is unknown. PE signatures of libmysql.dll for MySQL 5.7.41 show that it's compiled against Vista with VC142 (VS2019) toolchain. MySQL 8, the current version, is exclusively x64.

In short, x64 builds will be way more secure and feature-complete comparing to x32. With x32 libraries we also forced to use OpenSSL 1.1.x exclusively for PostgreSQL. It will bloat the installation and will have doubtful performance.

SQLite has no issues on all architectures and platforms.

Checkout?

I see new Prosody for Windows builds like these:

• Target OS: Windows Vista SP2 or Windows 7 SP1, x64 only
• Toolchain: Visual Studio 17 2022
• Lua: 5.4
• OpenSSL: >=3.0.8
• libexpat: >=2.5.0
• libidn: >=1.41, libICU replacement preferred
• zlib: don't use

Optional dependencies like LuaDBI are not shipped with the installer. LuaEvent will be required and enabled by default because select backend is deprecated. Prosody 0.9.8 did ship LuaEvent, but hadn't it enabled by default.

I'm ready for your questions and suggestions.

____

* unless One-Core-API kernel extension is used, but I'm not going to support this unstable environment

** I'm more likely to support this environment, as it doesn't affect Prosody compilation process, I can still use VC143 for this.

[Matthew Wild]

Hi Vitaly,

On Sat, 4 Mar 2023 at 19:20, 'Vitaly Orekhov' via prosody-dev
<proso...@googlegroups.com> wrote:
> I decided to open this thread for discussion as I'm going to take long-term (if I won't run in any circumstances that don't depend on me) Windows support on my own, after seven years of half-dead state of Prosody for this platform.

Thanks for your post, and your recent patch submissions. Sorry I
haven't responded to any yet - I'm currently under some time pressure
for other work, and I have limited time for patch review currently.
However I don't want you to feel ignored :)

That said, the whole topic of Windows support does deserve some
discussion. I can write a few words from my perspective, and also
summarize the feelings of the core Prosody developers.

We used to have a team member who primarily worked on Windows. They
haven't been active for many years, and have switched to another OS
anyway. We tried to maintain Windows support for a short while in case
anyone was using it, but at some point it became too difficult.

There are various things that come to mind when thinking about
potentially re-adding Windows support:

1) Is there sufficient demand for it? Although not uncommon for
developer desktops Windows servers are a minority compared to
Linux/BSD.

2) In recent years we have automated tests, CI, builds and packaging
for Prosody on all our supported platforms. This has always been much
harder to achieve for Windows, but I now consider these things a
strict requirement for any new platform we support.

3) We try to keep platform specific code isolated wherever possible,
however adding a new platform inevitably affects the entire codebase.
There are small quirks of every platform (e.g. you found out about the
weird stdio buffering on Windows that affects console output logging).
More platforms means more code complexity, which means more
maintenance burden and slower development. There is a cost to
supporting more platforms, and we've been planning to remove a huge
chunk of dead code left behind from Windows support:
https://hg.prosody.im/timber/rev/c72ecf61d0d1

Now, despite all this, you are clearly very motivated to get Prosody
running on Windows again. And I don't want to get in your way :)

My proposal for now is that we get you access to the community's
contrib repo, and there you can freely maintain a Windows branch with
your commits. From there, we can see how it goes in the long term: How
large are the changes? How easy is it to test, build and package? How
many people are interested in it?

What do you (and others) think?

Regards,
Matthew

[Vitaly Orekhov]

> Thanks for your post, and your recent patch submissions. Sorry I
> haven't responded to any yet - I'm currently under some time pressure
> for other work, and I have limited time for patch review currently.

That's absolutely okay, I'm both on study and work for the whole daylight, and getting home at 7 PM is sorta average for me. :)

>  We used to have a team member who primarily worked on Windows. They
> haven't been active for many years, and have switched to another OS
> anyway. We tried to maintain Windows support for a short while in case
> anyone was using it, but at some point it became too difficult.

Yeah, I remember that moment pointed in the Chatroom, when I asked about e-mail address mentioned in the 0.9.9 release announcement where deprecation was declared.

I do agree with difficulty of maintenance versions for Windows, due to inconsistent cryptographical APIs between major kernel updates (like between XP and Vista) and beforeamentioned console problems that got their minutes of care only with Windows 10, skipping quite large chunk of versions. Personally, I develop apps targeting Windows 8.1, and providing compatibility with previous versions for me is not a priority and depends on my mood, but I'm not going any older than Windows Vista anyway.

> Is there sufficient demand for it? Although not uncommon for

> developer desktops Windows servers are a minority compared to
> Linux/BSD.

I won't be arguing here, Windows servers are quite rare stuff to see in production, but I'm one of those weird guys who runs services on Windows Server 2012 R2 and having plans for updating to more recent version as I upgraded my hardware. :)

Unfortunately, I can't tell if there is a demand for XMPP servers on Windows, because my friends who develop stuff either don't like XMPP due to its design or just don't understand why I'm so passionate about it.

> In recent years we have automated tests, CI, builds and packaging

> for Prosody on all our supported platforms. This has always been much
> harder to achieve for Windows, but I now consider these things a
> strict requirement for any new platform we support.

That's what I wanted learn about as well. I never used automation in my development routines as I didn't have any needs for it. Gladly this will give me some first experience. I'm open to this.

> We try to keep platform specific code isolated wherever possible,

> however adding a new platform inevitably affects the entire codebase.
> There are small quirks of every platform (e.g. you found out about the
> weird stdio buffering on Windows that affects console output logging).

Mhm, and it's not even mitigated by updated console host of Windows 10 and newer builds. :D

I'd like to know why output buffering to console is needed. For file output it's clear to me, but for the console, why?

> More platforms means more code complexity, which means more
> maintenance burden and slower development. There is a cost to
> supporting more platforms, and we've been planning to remove a huge

> chunk of dead code left behind from Windows support.

Well, yeah, that's exactly where part of my changes belongs. I've been expanding windows.c mostly to get it as close as possible to recent Windows (useful) bells and whistles.

> Now, despite all this, you are clearly very motivated to get Prosody

running on Windows again. And I don't want to get in your way :)

If the warning on the download page said 'support was removed', I'd not even attempt to initiate the holy war about needing support or not. XD

When things are 'deprecated', there is still a chance to save the guy. :)

> My proposal for now is that we get you access to the community's

> contrib repo, and there you can freely maintain a Windows branch with
> your commits.

I guess maintaining Windows version in a separate branch will be a wise choice. If you ever decide to cut Windows components from trunk, I'll be still able to continue like nothing happened in mine. I think it's fair, how about you?

> From there, we can see how it goes in the long term: How

> large are the changes?

The changes are not really large, part of them is already submitted as patches, so you have in queue around 80% of stuff I adapted to today's date.

> How easy is it to test, build and package?

I'm performing a cleanup from my draft build I made using GitHub mirror repo (bjc/prosody), baking stuff into a combined Visual Studio 2022 solution that should build everything in one pass. I haven't reached the unit testing (is that what 'busted' does?) yet. The hardest part is OpenSSL. It's impossible to configure it the way it won't bury compiled object files and libraries from previous configuration. You have to wait until it completely reassembles stuff before you can link it against needed libraries, so as a slight hack, the compiled libraries are copied to a folder with built binaries and every time the solution is built, their presence is checked. This thing is quite fragile, but 'it just works'. ©

Haven't reached the packaging stage yet, if you are talking about NSIS installer. Or, if you are about preparing the distribution by copying the Lua side of Prosody to processed folder (yeah, my English is weird, it's not native for me. :D), it's done rather easy by MSBuild's tasks.

I had to patch dozens of Prosody's dependencies to get them working with MSVC. My worst nightmare was Unbound — it was designed to be compiled via MinGW even on Windows, and knowing that Windows version of Prosody prefers dynamic linking on everything, I had to spend some hours adding __declspec(dllexport) to all functions of libunbound and fixing laziness with #includes of headers that are conditionally added, like HAVE_TIME_H. :)

There is an inconsistency with luasec — it has its own bundle of LuaSocket, but Prosody also depends on it. So I can't choose whether version of LuaSocket I need. The one with luasec is older.

The future Windows branch will include patches to patch dependencies to make them compileable with MSVC. I build stuff mostly in MSVC, so I really need help understanding how Linux differs from my environment in perspective of compatibility. Though one of my friends uses Linux on daily basis and develops there, knows MinGW like the back of his hand.

I also want to address a question about static linking of DLLs. What's allowed and what's not. Because my current Visual Studio solution is configured for both 'classic' Prosody with every C library as DLL and 'all-in-one' with everything in the executable.

>  How many people are interested in it?

The side project I'm working on with my friend actually involves and requires an XMPP server for chat infrastructure. It has to be a native Win32 application because we plan to scope at least Windows 7 and newer systems. All I'm allowed to say is 'game server solution' (like rAthena or Hercules for folks who play Ragnarok Online on their private servers), neither less, nor more, so for now the range of interest is just... two persons, take it or leave it. The number might slowly crawl up in future, but I primarily target general Prosody for Windows support rather than such narrow-scoped task.

> What do you (and others) think?

I'm always been a pioneer in unknown or unoccupied areas. I never been to some serious software development, mostly modmaking in games, trying to discover some new ideas or refresh ones that were long forgotten.

I have seen some examples of good software being ignored just because of lack of platform the user uses, picking rather hard to understand or resource demanding ones instead, but working for the platform of subjects (like ejabberd in Erlang or Openfire in Java). Prosody is a winner in both perspectives — it's lightweight and plugins are fairly easy to write. I never written anything in Lua before last September or October, but now I feel rather confident with it.

I want good stuff available to those who can't jump easily on another system or doesn't want to use virtual machines or WSL. Like me or any other advanced Windows user who might want to start his own XMPP server one day.

Although, there is one problem IRL that affects me. This July I might be cut from communication for year or two due to stuff I would never tell on public for personal safety reasons. No, it's not a law problem, I'm in top shape here. I can explain what's going on in personal messages on XMPP, if you really want to know more.

[Vitaly Orekhov]

We reached an important milestone! All patches to fix Windows support are in the mailing list, and here I will point the currently known issues. Their majority might sound subjective and again, I'm open to feedback and opinions.

• [Minor] If console output buffering is enabled (by default), text output is incomplete
  • Can be mitigated by adding buffer_mode = "no" parameter to console logging setup, which disables buffering
• If pidfile is defined in Prosody configuration, closing Prosody by clicking Close button or killing the server via Task Manager will keep pidfile in the filesystem
  • This might prevent Prosody from starting, falsely claiming that pidfile is already occupied. Double check that Prosody isn't running (or pidfile is not write-protected) and delete it. After that, Prosody will start normally.
• [Important*] util.crand will rely on OpenSSL or LibreSSL, depending on which library was used to compile the utility.
  • Windows does not have /dev/urandom, but BCryptGenRandom exists, which is used by those when compiled under Windows.

This list might be incomplete. If you found something that's missing, feel free to submit reports here!

______

* I heard that this wasn't heavily tested.

[Vitaly Orekhov]

Some news to wrap up this week.

A few funny bugs have been found during fiddling with Prosody console (via mod_admin_telnet). If you needed for some odd reason "internal_plain" authentication, user:create() will fail to create the user, as there is no proper handling in mod_auth_internal_plain for case when password is nil. The default "internal_hashed" handles such properly, disabling the account until the password is created. The fix is coming soon.

I will not use libIDN in the builds, neither modern Linux builds of Prosody do.

Following the bookworm branch of Debian, my choice goes to libICU. In case of Debian, their package depends on ICU version 72, while on Windows version 58 (the last officialy compatible with Windows Vista) seems to work without problems. I might raise the used version number for security reasons, but it would require investigations in case of presence of kernel extensions in the system. When the latest compatible with 'extended' Vista will be found, I'll move up to this version. Stay tuned.

As always, I hope to hear any feedback from maintainers regarding minimum system requirements and related stuff for future Windows builds, as well as from current users.

[Vitaly Orekhov]

On Wednesday, 15 March 2023 at 02:02:26 UTC+3 Vitaly Orekhov wrote:

• If pidfile is defined in Prosody configuration, closing Prosody by clicking Close button or killing the server via Task Manager will keep pidfile in the filesystem
  • This might prevent Prosody from starting, falsely claiming that pidfile is already occupied. Double check that Prosody isn't running (or pidfile is not write-protected) and delete it. After that, Prosody will start normally.

Got a bit of time to revisit the problem.
SetConsoleCtrlHandler allows me to add a handler that will trigger when user closes the window containing the running instance of Prosody. Thus it gives us an option to close the server cleanly, as "server-stopping" event is properly fired. But I have something to clarify: in the current implementation of the handler, lua_State* is exposed to the global scope, and there is no way (by Windows API design) to throw thing directly into the handler. Not sure if I am too paranoid on this, but could this do anything bad from any of perspectives, including security?

In the meantime, I'm cleaning up the Visual Studio solution to prepare it to get into prosody-windows repository. There's still stuff to redo.

[Vitaly Orekhov]

I had made some tests on unpatched Windows Vista SP2 (by unpatched, I mean without the extended kernel). The observations I made had shown that this system is acceptable to be the bare minimum to run Prosody for Windows, the current implementation of util.encodings (as in Prosody trunk) allows to link against libicu (ICU4C) of any version starting with ICU 58. Given that, server administrators who want to run Prosody in Vista or Server 2008 environment, will have to compile Prosody from sources to fit these conditions. Other libraries do not seem to have strict Windows specific system requirements (does not apply to LuaDBI plugins for PostgreSQL, for example) and do not require any special treatment.

The general availability version of Prosody for Windows (the one can be obtained on Downloads page) must follow the dependency tree that Debian releases have.

As a result, I want to show you the system requirements for Windows version I came up with after dependency review.

Common requirements

• Lua: >=5.4
• OpenSSL: >= 3.0.0
• libevent: >= 2.1.8
• libexpat: >=2.4.1
• libicu: >= 72.1
• libunbound: >= 1.8.0
• C/C++ runtime libraries: Visual C++ 2022

Windows requirements

• Target OS: Windows 11, version 22H2 (client), Windows Server 2022 (server)
• Minimum supported OS: Windows 7 SP1 (client), Windows Server 2008 R2 SP1 (server)

All listed operating systems must be x64. x86 versions are not supported. In future, if volunteers will come, it may expand to ARM64, since Windows 11 for ARM exists, too.

Information provided here is relevant at the moment of writing and is subject to change in future, mostly towards newer versions and deprecating older versions if blocker issues happen.

Notices on Windows Vista and Server 2008

In order to run Prosody for Windows on Vista, Prosody must be built from sources. Running Prosody on unpatched Vista SP2 is not advised due to noticeably outdated ICU4C library (58 vs 72), thus extended kernel installation is highly advised for consistent experience. I have no data for Server 2008 SP2, so I cannot state clear requirements there. In case of Vista SP2 with extended kernel, all issues happened in this environment, are covered by warranty, as I maintain this. Without the kernel — sorry, it's too outdated for me, please, use either the extended kernel or upgrade to newer release of Windows.

Notices on ReactOS

Recent build artifacts of ReactOS 0.4.15 feature NT 6.0 subsystem. I 'participate' in ReactOS development and all bugs that may happen when running Prosody on ReactOS could be mostly the operating system bugs. It does not mean that ReactOS with NT 6.0 subsystem is unsupported, it will be supported, as we need our network stack to be as good as possible. OS architecture requirements are different here: x86 is fine, but x64 is more preferred — reports from both versions are accepted. NT 5.2 version is not supported and never will be. You can volunteer yourself for NT 5.2, but I won't join the party.

———

Provide me your suggestions in replies. I will be happy for any response!