LRN commented 8 years ago

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)

LRN commented 8 years ago

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).

lwindolf commented 8 years ago

Thank you for the great work! I will start merging the patches.

lwindolf commented 8 years ago

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

genodeftest commented 8 years ago

AFAIK WebKit2 isn't available on Windows and won't be supported there.

Alternative: Use Trident/EdgeHTML on Windows. Will be a major change.

smaragdus commented 7 years ago

Windows port of Liferea would be great since QuiteRSS has no alternatives right now, almost all RSS readers have already been abandoned (including RSSOwl).

smaragdus commented 6 years ago

Any news about the Windows port?

GATOQSECOMIO commented 5 years ago

any news?

lwindolf commented 5 years ago

Not really. I've merged a lot of the patches, but cannot really test them as I'm on Ubuntu only.

smaragdus commented 5 years ago

@lwindolf

Not really. I've merged a lot of the patches, but cannot really test them as I'm on Ubuntu only.

Virtual machines?

Leiaz commented 5 years ago

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 ...

lwindolf commented 5 years ago

@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.

smnthermes commented 4 years ago

Is it still far away? How about using UXP, which is a hard fork of Mozilla platform code?

genodeftest commented 4 years ago

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.

smaragdus commented 4 years ago

@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.

genodeftest commented 4 years ago

@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.

smaragdus commented 4 years ago

@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.

nekohayo commented 3 years ago

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.

smaragdus commented 3 years ago

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.

nekohayo commented 3 years ago

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.

lwindolf commented 3 years ago

@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.

lwindolf / liferea

Liferea isn't ported to Windows #339