131–140 of 153 posts
Earlier quoted context omitted.
Other than some stupid feature of it (like some of the ones you mentioned, maybe also forms), I really don’t think it is too hard to implement - there are plenty of open-source pdf reader libraries.
Plenty as in poppler, mupdf and pdfium? Are there others?
Earlier quoted context omitted.
It's a 2000 page spec that links to other specs (eg JPEG, PNG). It is a turing complete document format that can run arbitrary code without a sandbox. It is a mix of a binary and text format (some opcodes are in binary, some in text which just why?). All in all, it is a format designed to be incredibly hard to implement so people just give up and pay adobe.
Other than some stupid feature of it (like some of the ones you mentioned, maybe also forms), I really don’t think it is too hard to implement - there are plenty of open-source pdf reader libraries.
With no libraries! That was painful.
I use Wine for one thing: running MusicBee. It's a pain in the ass to get it working 100%. Every time I've tried to upgrade past wine 4.x it completely breaks my MusicBee wine prefix, so I've locked the version and will never upgrade. Ultimate goal is to wait until any native Linux music player is even 10% as good as MusicBee.
Earlier quoted context omitted.
Has this ever been tested? If Linux can decide license requirements for modules that implement their apis, I’m not so sure Microsoft couldn’t block Wine if they really wanted.
The license in Linux case is for distributing Linux (and the module). You can create modules with whatever license you'd like if you're not distributing your work. In Wine's case you're not distributing Windows so it's not the same. A more similar case would be Oracle vs. Google over the Java API.
That’s not true either. There’s no such distinction. A program using a GPL library (such as the kernel) is considered as a derivative work according to the FSF.
Canonical legal (for ZFS) decided that distributing a non-GPL module is fine, as did NVIDIA for their GPU drivers.
If the GPL is considered as enforceable on that front (which was _not_ tested), a lot of things would change.
Earlier quoted context omitted.
Interestingly, this announcement makes it sound like you might not even need 32-bit libraries anymore: - The 64-bit Windows-on-Windows (WoW64) architecture is implemented, and supports running a 32-bit Windows application inside a 64-bit Unix host process, using thunks to map 32-bit NT system calls to the 64-bit NTDLL. - WoW64 thunks are implemented for most Unix libraries, enabling a 32-bit PE module to call a 64-bi…
I wonder how that will work on M1 macs. Right now, trying to run any 32-bit executable with Wine 6 is being met with "bad CPU type in executable".
Available at https://github.com/Gcenx/homebrew-wine if you want to use a free build for example.
Earlier quoted context omitted.
Has this ever been tested? If Linux can decide license requirements for modules that implement their apis, I’m not so sure Microsoft couldn’t block Wine if they really wanted.
The license in Linux case is for distributing Linux (and the module). You can create modules with whatever license you'd like if you're not distributing your work. In Wine's case you're not distributing Windows so it's not the same. A more similar case would be Oracle vs. Google over the Java API.
Hope it will improve someday on this direction as well
Earlier quoted context omitted.
As far as I know, Wine has not primarily been a hobbyist project for about 15 years, with the bulk of development being done by CodeWeavers, which uses it as the basis for their CrossOver product. I don't believe any of that has substantially changed with the advent of Proton, though I assume that Valve is paying CodeWeavers to also pay attention to Proton issues.
You're probably right, I don't know for sure but I believe Valve has employees working on these projects too, considering their investment in SteamDeck.
Very few, actually. Most of the actual work on these projects is contracted out. You can view the git logs, not many @valvesoftware.com addresses.