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 <https://packages.debian.org/bookworm/prosody> branch of Debian packages as a reference, keeping in mind our own <https://prosody.im/doc/depends> 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 <https://learn.microsoft.com/en-us/windows/console/setconsolemode> 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 <https://reactos.org/> 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 r**eady 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. -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prosody-dev/c3e72466-3d58-4cca-ba1e-ccd1b260b832n%40googlegroups.com.
