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
<https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-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.
On Saturday, 4 March 2023 at 23:50:34 UTC+3 Vitaly Orekhov wrote:
> > 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
> <https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-tasks?view=vs-2022>
> .
> 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.
>
--
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/f9367fee-6c34-4af4-8a3e-f412ab3a3443n%40googlegroups.com.
