liferea
liferea copied to clipboard
lwindolf
Liferea isn't ported to Windows
There are roughly four categories of problems preventing Liferea from being built and working on W32:
- Some macros and functions are unavailable on W32 and need to have their implementation built into Liferea, or Liferea should use alternative functions on W32
- W32 needs certain paths detected at runtime, it can't use hardcoded paths like PACKAGE_DATA_DIR
- The way gobject-introspection and signal handler connection work on W32 requires Liferea to export its API (currently it does not; or it does, but in a way that doesn't work on W32)
- Certain actions need to be done in a W32-compatible way (for example, file:// URIs need to be composed slightly differently when running on W32)
Attached are the patches that i cobbled together in a couple of evenings:
0001-Support-building-without-gobject-introspection.patch
Initial patch that allows building Liferea without GI. I've fixed GI later, but this change is still valid, as configure offers --enable-gobject-introspection=[no/yes/auto], and "no" doesn't really work.
0002-W32-Use-W32-incompatible-headers-conditionally.patch
Usual suspect - sys/wait.h. Make its inclusion conditional. This should work sufficiently well.
0003-W32-Don-t-set-up-SIGHUP-handler.patch
No SIGHUP on W32. Maybe add W32-specific code for SIGHUP-ish events (hidden window + WM_SHUTDOWN?), but that is a battle for another day.
0004-W32-Compatibility-for-time-functions.patch
This contains a relatively large piece of borrowed code. It should probably go into separate source file (something like compat.c?). Alternatively, consider rewriting the code to not use strptime().
0005-W32-Don-t-use-configure-time-paths.patch
0006-W32-Use-lib-and-data-directory-getting-functions.patch
Liferea was already doing g_build_filename() in some places, i've just had to extended that to all paths and add functions to detect paths at runtime.
0007-W32-Special-construction-of-file-URIs.patch
Without this opening help files doesn't work.
0008-Implement-export-control.patch
Marks certain functions for export. I do not have a correct list of function that should be exported, just went with my gut here (any GType registered by Liferea -> export; also, export everything that looks like a signal handler). This is based on GTK code. I can't test the effects of the visibility attributes, you'll have to figure this one out on your own.
0009-W32-Don-t-forget-EXEEXT.patch
This fixes GI.
0010-Use-g_rename-instead-of-rename.patch
This does not really fix anything much (except for the use of UTF-8; by the way, there are likely other places where UTF-8-aware GLib functions should be used). I've added this only because this renaming consistently fails on W32 (maybe one of the files is opened when it's being moved? If that's true, this will require a different fix).
Just merged patches 7 and 9. About 7: Lifereas current Glib dependency is 2.4 which does not yet provide g_rename(). I added a FIXME instead to switch it later. I do not want to raise the dependency yet as even Ubuntu has not reached Glib 2.6
AFAIK WebKit2 isn't available on Windows and won't be supported there.
Alternative: Use Trident/EdgeHTML on Windows. Will be a major change.
Windows port of Liferea would be great since QuiteRSS has no alternatives right now, almost all RSS readers have already been abandoned (including RSSOwl).
Not really. I've merged a lot of the patches, but cannot really test them as I'm on Ubuntu only.
@lwindolf
Not really. I've merged a lot of the patches, but cannot really test them as I'm on Ubuntu only.
Virtual machines?
Quite some time ago I looked into compiling Liferea in a virtual machine (on a desktop machine I don't have right now) using msys2 as suggested here, but there is no WebKitGTK package there. This would be a first step, if someone wants to give it a try ...
@smaragdus Yes, virtual machines can be used for this. Still this is not the kind of personal private dev environment I do use. It's just a simple Linux laptop that cannot handle much, so no VMs for me :-)
I know this seems strange when everyone these days runs minikube clusters on their work laptops... still that's how it is and that's what I'm willing to do. I shouldn't have to say this explicitly, though.
Is it still far away? How about using UXP, which is a hard fork of Mozilla platform code?
Using a hard fork of a software with high attack surface and regular security updates is a very dangerous thing. Think about when someone finds a security critical bug in Firefox and Mozilla fixes it. Then the world (including evil hackers) will know about this bug and how to exploit it. Your favorite fork will probably not fix this bug because they don't care or don't have the manpower to do so. As a result, everyone who already has exploits against Firefox will have exploits against this fork and thus put all users at high risk.
@genodeftest
What you are talking about is highly improbable and is unlikely to happen in the real world. Using Windows is high security risk yet people use it. Using the internet is a high security risk yet people connect to the internet.
Unified XUL Platform is in active development and as far as I know it has deviated a lot from from Mozilla original code.
@smaragdus wrote:
What you are talking about is highly improbable and is unlikely to happen in the real world.
You are very wrong about that. This happens all the time everywhere. Globally. I just ran in a similar issue (in this case in WordPress) yesterday. A blog I visited by accident had an old open security whole and it has been abused for advertisment and malware.
Using Windows is high security risk yet people use it. Using the internet is a high security risk yet people connect to the internet.
Not as bad as using software with known (and exploited) security bugs in it.
Unified XUL Platform is in active development and as far as I know it has deviated a lot from from Mozilla original code.
Do they have a public CVE tracker? Is there anyone in this project who has a look on every single CVE registered against Mozilla Firefox? I guess not.
@genodeftest
My experience- for about 20 years have got infected only once many years ago when I connected my Windiws XP machine to game club LAN to play multi-player games and the event was so unique that I still remember the name of the malware- Sality. For years I used old and severely outdated versions of Firefox before finally switching to other browsers ( Chromium forks, Pale Moon) and I have never had a security accident. I still use long ago discontinued programs like RSSOwl (as I need an alternative to QuiteRSS). For me the most dangerous malware is the state-sponsored one (Duqu, Flame, Stuxnet, etc) and against such malware there is virtually no defence. For me the best defence against malware is common sense, use of a good ad-blocker, disabling of JavaScript when possible. Also I doubt that the Pale Moon developers will not fix critical exploits.
Is it still far away?
I do not think a Windows port will happen unless someone new shows up, does the work and promises to maintain the port. I do not consider it reasonable to expect Lars to maintain a port to a platform he does not use and is not familiar with.
So I would say tag this issue "PATCH OR WON'T HAPPEN", wishlist, low priority, and maybe close the ticket until someone comes forth to shoulder this responsibility.
and maybe close the ticket until someone comes forth to shoulder this responsibility.
An open issue means that the issue is still not solved, not discarded and might be resolved in the future. I suppose that the maintainer of this repository may tag it with help-wanted label so that possible future contributors to this project might be notified that their help would be appreciated.
Tickets that remain open "just because it would be nice someday" do not help maintainers ship software faster; on the contrary, it clutters the view of what are actual bugs (you quickly end up with hundreds of such tickets in a bug tracker). "Liferea isn't ported to Windows" is not a bug. If a maintainer has no intention of doing a Windows port themself, I believe it is more honest on all sides to close the ticket (alternatively: convert it to a forum thread, like the newly introduced GitHub "Discussions" feature) unless a new contributor shows up and does the work; tickets can always be reopened, particularly if they are "bugs" or refinements to the UI/UX.
@nekohayo I wholeheartedly agree. As a developer/maintainer the ticket tracker is my means of work and given open source contributions to be a very scarce resource should IMO be optimized towards benefiting this resource. At the same time many ticket writers as @smaragdus disagree.
This is the old issue of the OSS license focus while containing the "AS IS" clause doesn't seem to extend to the social contract that's implicitly hidden in ticket tracker, mailing lists... The license focus makes it easy for this social contract to be ignored.