UniversalMediaServer 🚀 - UMS is not compatible with Windows XP and Vista [FFMPEG]

@444nonymous I agree and we have been discussing this lately. I plan to do a separate build for old Windows versions soon

SubJunk on 23 Aug 2017

Are you able to create UMS builds? If not I will make one of this https://github.com/UniversalMediaServer/UniversalMediaServer/pull/1370 for you to test

SubJunk on 23 Aug 2017

@SubJunk No, but i'll test your build.

444nonymous on 23 Aug 2017

XP isn't working anymore because quite some libraries switched to incompatible (mostly) print_secure functions.
Other just went along their ways with other API. But kudos to rdp team for finding the right switches.

On the other hand, Vista has nothing to envy to, say, 7, except for NUMA that x265 uses since version 1.6 or something along that.
Compile it with WINXP_SUPPORT cmake option and you are done.

mirh on 23 Aug 2017

@444nonymous

Just to clarify things:
I'm currently running WinVista SP2 32bit, fully patched (see here); I downloaded both UMS-6.7.3.exe & UMS-7.0.0-rc1.exe from releases and probed the ffmpeg.exe binary inside ./win32 folder; they're identical and I'll have you know they run fine on my Vista laptop:

ffmpeg version N-80363-g403a53c Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-nv
enc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enabl
e-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --en
able-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libil
bc --enable-libmodplug --enable-libmfx --enable-libmp3lame --enable-libopencore-
amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-
librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-li
bspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo
-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libweb
p --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-l
ibzimg --enable-lzma --enable-decklink --enable-zlib
  libavutil      55. 24.100 / 55. 24.100
  libavcodec     57. 46.100 / 57. 46.100
  libavformat    57. 38.100 / 57. 38.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 46.101 /  6. 46.101
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100

In fact, this is an older Zeranoe build dated from 17-Jun-2016, belonging to a specific time frame
starting when the builds broke on XP (29-Feb-2016) and ending when they broke on Vista, too (17-Jul-2016); see webarchive snapshot of the Zeranoe repo.
This binary fails to run on your WinXP SP3 box for reasons outlined by @mirh (e.g. --enable-libmfx), but continues to run on Vista because libx265 was still compatible with Vista at the time the build was compiled by Zeranoe; so the title of your issue is inaccurate wrt to Vista...

Currently, the Windows Zeranoe repo contains builds that are Win7+ compatible, only; should the UMS devs decide to upgrade their currently provided ffmpeg.exe 32bit binary with one more recent from the Zeranoe repo, then, sadly, UMS will be again broken on Vista, too (and in that case your issue title would be correct)...

@444nonymous wrote:

The FFmpeg code itself has not stopped being XP / Vista compatible, but compiling it with the inclusion
of some external libs that are either themselves by default not compatible or have become incompatible at some stage of their development is what broke recent builds on XP / Vista.

I am the original author of this e-mail, having a whole paragraph from there copy/pasted onto your issue here feels like such a great honour...

Vangelis66 on 28 Aug 2017

👍2

Tbh, after checking stuff here and there the other day, the reasons even XP isn't working are pretty stupid and solvable.
Only thing needed would be faster PR reviewers.

mirh on 28 Aug 2017

If someone was willing to go through the pain of figuring out how to build FFmpeg, we might be better of making the builds ourselves. Then we could get all we needed in one version. The problem is that I'm not that keen on diving into that. There's so many other things I have to keep track of already that I don't know if there's room for FFmpeg too 🤓

Nadahar on 28 Aug 2017

Well, that's why I had posted you those helpers
I must say that even these linked in the OP are of the highest quality. So.. your call?

The real feat on the other hand imo, is how to neatly integrate the building and deployment so that you aren't maintaining a separate fork of either the scripts, ffmpeg or even worse its binaries in UMS repo.

mirh on 29 Aug 2017

@mirh This isn't ultimately up to me, I'm just making suggestions. While I'm sure that the linked tools are of great help, the problem for me is that I'm not even familiar enough with FFmpeg to have any idea what most of the modules do. As such, the tools aren't of much help - because you still need to know what to include. Ideally we should exclude everything not relevant for UMS use, to reduce the potential for issues and save size. I'm simply not able to even have a vague idea of what should and shouldn't be included.

We also bundle FFmpeg for Windows, Linux and maxOS, so if we did "our own build" we should probably build for all those platforms with the same libs included. Knowing that the same options would give the same result on either platform would certainly make it easier to make UMS have a consistent behaviour.

I think static linking is a must for our use, relying on installed libraries make everything too random. I think that might constitute a problem for some distros (like Debian ?), but it's the only practical solution as I see it.

We're already hosting the binaries we bundle, and I'm not sure I see a realistic way to avoid that. They aren't hosted in the UMS repo though, but are downloaded and bundled by UMS's build tool.

Nadahar on 29 Aug 2017

I'm not even familiar enough with FFmpeg to have any idea what most of the modules do.

I'm definitively not either, that's why I was just thinking to target default config.

...

In other news static building on linux sounds bad.

mirh on 29 Aug 2017

In other news static building on linux sounds bad.

... Many Linux distros are by default tied up to old avconv/ffmpeg system packages; I don't claim to be a Linux expert, quite the contrary, but the fact that static Linux ffmpeg builds are already being offered by John Van Sickle makes this an attractive choice for the UMS devs...

Vangelis66 on 29 Aug 2017

@mirh

In other news static building on linux sounds bad.

I know and I disagree. I think that the sooner Linux abandons the "only dynamic" philosophy the sooner it will become a real desktop alternative. Sure, dynamic linking make sense in many circumstances, especially for "core OS" tools. But, I think the philosophy works best in theory and not so good in real-life.

If every application is to depend on the shared dependencies, what you do in reality is to put all the responsibility on the user. If the user want to use application A and application B with both requires a certain dependency but in different versions, the user should somehow figure out how to get around it; mock it up using symlinks, find different applications or just cry. Most real-world users don't know and don't want to know enough about these shared libraries, the implications of using this or that version or that they what they do or that they even exist. I really can't see why they should either.

It's so easy to get bogged down in "dependency hell". Demanding that all developers should spend a lot of time constantly updating, testing and retesting dependencies isn't logical to me, that leaves very little time to actually develop the application they are trying to develop. When you see the typical time it takes to solve many regressions, the hopelessness of this approach should be evident. What do you as a developer do when there's a regression in a dependency that breaks your application? You can't require a version before the regression occurs because some other application on the same system might require something added after the regression. Should the developer then find a workaround and implement that in the meanwhile, or just accept that your application will be broken for some months or years?

I've abandoned Debian for this very reason, after having had to give up a couple of installations that simply ended up being impossible to resolve. In one instance I had incompatible requirements for curl. Curl is a dependency for so many things that downgrading it is virtually impossible.

As I see it all this could easily be avoided by using static linking where that made sense. It gives an application encapsulation, and the ability to test a given set of components together and make sure they all play ball, at the same time as you know that your application won't suddenly break because some library is updated with a new regression that its maintainers might not consider very critical.

On top of all the problems this approach gives, there's so little to gain. Ok, you save a bit of disk space. I'll gladly spend an extra 10 GB on dependencies to avoid dependency hell and broken applications. The other thing you supposedly gain is that security updates propagate quicker and that some bugs might be fixed without you having to do anything. Security updates might be a valid point in some circumstances, but often they aren't relevant for your application or you have to change your use of said library to get a good solution. That means that you probably should do some changed or at least test your application with the updated dependency anyway, which makes the "automatic propagation" as good as pointless.

When it comes to the odd bug that is fixed for you, that's great, but it's simply not worth the risk of the new regressions you probably get as well. Your application simply very quickly become uncontrollable, you are not in control of whether it works or not for your users.

We have some of the same problem in Java with dependencies. Even though the user or OS won't change your dependencies without your knowledge, you can only have one version of a given dependency in your "dependency tree". That means that if you and one of your dependencies rely on a third dependency, you both have to use the same version of that dependency. This happens all the time, the same goes for multiple of your dependencies relying on a common dependency. We have cases where one dependency are used by 5 different dependencies and UMS itself (AFAICR). This is a real nightmare, because you have to do a very careful dance with which versions of the different dependencies you use. In some situations your only option is to drop a dependency and find another way to solve the same problem you used that dependency for. I would almost wish nobody ever got the idea of cross-project shared dependencies.

If UMS are to use a dynamic linked FFmpeg, we must either have to learn all about the different versions of the different of its dependencies and guide each individual user to get a working setup, or we'll just have to leave it to the users to figure it out. By using a static build we can eliminate all this - which makes me feel like going against the "political correctness" on Linux is a small price to pay.

Nadahar on 29 Aug 2017

👍2

Yes, dynamic builds are a real nightmare for us because FFmpeg uses about a million dependencies and if one of them is causing a bug it can be nearly impossible for us to pinpoint that, while with a static build we know exactly which versions of dependencies are used and it makes debugging much simpler

SubJunk on 29 Aug 2017

First, I'd also have abandoned debian because I cannot really stand any non-rolling release OS.
Second, distros are already mocking up themselves different symlinks for ffmpeg-2.8, 3 and whatnot. Not sure what we are talking about.
Then I wasn't really thinking of security. My point (maybe because I too damn well know Steam's problems) was that there are so many different enviroments (I'm looking at you libgc) that I can't see this ending well.
Maybe a flatpack might solve this, but that's a point for another time I guess.

Also last but not least, ffmpeg itself is already listing, telling you, all the options it was built against. Not sure why we are talking about modules as if they were a black box.

mirh on 29 Aug 2017

@mirh Regarding the FFmpeg modules I meant that it would be relevant to include those we actually needed - in which case we'd have to know what they did. I know that FFmpeg lists which modules it was built with, but that doesn't really answer the question.

I must admit that I know to little about the Linux ecosystem and assumes it wouldn't be that hard. It seems like you're right and that we'd have to build one static version for each distro/version - which would be a real pain. It's sad that Linux hasn't manage to implement any standards at all, it makes it such a pain to work with. I'd think it would be practical for everybody if there were some very basic standard libraries. It seems like flatpack is trying to solve this, but I'm not sure how the sandboxing would work for us. We're doing cross process stuff, which might be a challenge in a sandboxed environment. As long as no basic standard libraries are available, I guess there's no other way.

Off topic it seems that Microsoft is hell bent on killing Windows (forcing all kind of shit on its users) these days, so I really hope Linux can get their standardization act together (I guess freedesktop is the best hope ATM?) soon so that it becomes a viable alternative. They must understand that software developers outside the "Linux sphere" needs something predictable to work with before it can become truely mainstream.

Nadahar on 4 Sep 2017

in which case we'd have to know what they did

If you have to ship/compile them yourself, sure. You can drop extra stuff (for as much difficult understanding where it is used might be).
If we are talking about linux, and dynamic linking, that's no your problem and peace. At least standard settings should be there for everybody.

As long as no basic standard libraries are available, I guess there's no other way.

There's also snap and appimage for that.
Anyway, to be really honest, I just gave a quick check to linux-specific forums boards - and as I was assuming libraries don't seem to be a problem at all.

so I really hope Linux can get their standardization act together (I guess freedesktop is the best hope ATM?) soon so that it becomes a viable alternative

I'd start to guess you aren't touching linux - not even with a pole - since ages?

mirh on 4 Sep 2017

@mirh

Anyway, to be really honest, I just gave a quick check to linux-specific forums boards - and as I was assuming libraries don't seem to be a problem at all.

I find that hard to believe. Are you saying that you can copy a dynamic linked FFmpeg binary on as good as any Linux distro, old or new version, and it will work consistently? If so, I'm amazed because my general experience with Linux (not with FFmpeg in particular) is the contrary.

I'd start to guess you aren't touching linux - not even with a pole - since ages?

That's wrong. I use it for several servers and have desktop VMs for the most common distros that I use for testing. I think the desktop environments are far from ready for mainstream. They might look fine when installed, but you don't have to try to do much personalization before something breaks (at least I don't have to). The lack of a standard way to do things is a big problem as I see it, doing things that's simple in Windows often requires you to know all kind of quirks to get it working. It generally doesn't take long before you find yourself configuring something from a text editor, in which case you've excluded most mainstream users. I implemented support for thrash can/recycle bin in UMS (as per freedesktop spec), and even something as simple as that was a bit of a nightmare of different implementations and vague or missing definition. When developers can't have a single API or other method to reliably do stuff like that, developing truely integrated applications becomes too expensive and time consuming.

I would really love to be able to switch my desktops to Linux, but as I see it there's just so much missing before it's a real option. There's so much software that's not available, and the open source alternatives (if any) are often unfinished, unpolished and buggy. I really hope this changes before Microsoft manages to make Windows completely unbearable. I hope I'll never have to use Windows 10 for everyday use, as I really can't stand it.

Nadahar on 4 Sep 2017

Are you saying that you can copy a dynamic linked FFmpeg binary on as good as any Linux distro, old or new version, and it will work consistently?

No. I was entailing that people are just fine with dynamic linking, end.

I use it for several servers and have desktop VMs for the most common distros that I use for testing.

Then there might lie your problem. Debian. Which is very very damn behind the 'head'.
Just yesterday I was complaining with a osx ~~fool~~ gamer about sticking to that retardely slow OS in 2017...
Only to discover after some arguing, that he indeed already had had the good will to try linux some time before.. But the so-much-outdated debian that he was thinking Gen7 Intel hardware was just OGL 3.0.
Which was something they already had got past in like 2013, for the uninitiated.

Anyway, if your criticism is about xdg and all that stuff, then I can see you might have a point.. I'm not really informed on the matter.
Ffmpeg (and/or other possible nasty dependencies) is another thing though.

mirh on 4 Sep 2017

@mirh

No. I was entailing that people are just fine with dynamic linking, end.

My point is that dynamic linking excludes a lot of users and makes developing software much harder. I think it holds Linux back. Most current users are fine with dynamic linking, but that's because all those who aren't simply don't use Linux. There's two basic problems with it as I see it:

All compatibility issues are left to the user to solve, and you often need to have at least a general idea of what a given dependency does to make the appropriate decisions. Most users don't know or don't want to know enough about what goes on under the good to be able to handle this.
It is very hard to develop applications that will work predictably with dynamic dependencies. Supporting such an application can be a real nightmare, as you'll have an almost endless amount of different combinations of dependencies in use. A lot of the "Linux ecosystem" don't care about that, because they generally don't offer support (unless it's paid, in which case I guess solving such issues is a good a way as any to make money).

Excluding most potential users and making it hard to support applications helps make sure that a lot of software aren't available, which is the biggest hurdle for me personally.

Then there might lie your problem. Debian.

I don't use Debian exclusively, in fact I don't think I'll be making any more Debian installation exactly because they are lagging too much behind. When I initially chose Debian for a couple of server, it was because the idea of stability before cutting edge appealed to me. I don't enjoy being a "beta tester" for every piece of software I use. It turned out that they lag too far behind for me though, but I still don't want to use versions that is battle-tested. I've since moved to Centos and Fedora for my servers. I've done the same with Windows over the years, and generally not taken new versions in use until they have become a couple of years old.

I do have installations of Ubuntu, Arch and Antergos too, in addition to several embedded/busybox devices and a couple of FreeBSD installations. I've previously had Mint and Gentoo installations as well.

Nadahar on 4 Sep 2017

It is very hard to develop applications that will work predictably with dynamic dependencies.

Just check if user has at least version X, and you are done?
Or if you are talking about program expecting an api, and deprecations happening every now and then.. It doesn't seem that bad nowadays.

But maybe I finally get what you are talking about. Regardless of what a wise-man should do, there are still a lot of people that for whatever the various right or wrong reasons stuck to 16.04 LTS say.
Which O-M-G is still using 2.8 (and of course it makes no sense to support 2 apis).

It is nevertheless a fact and a good program™ should 'support the mass'.
Therefore some kind of self-container would indeed pretty help (afaik even sandboxed ones should have permissions for full network access then)
They can get north of 100MB though.
(which aside of practical reasons, may even sounds bad conceptually, to some people)

So, anyway, long story short - I guess you could have a _normal dynamic build_ for everybody/maintainers.
Then a flat/snap/aimg for edge cases, granted to always work, maybe to replace the tarball on the website.

Which I suppose smells more complicated than Windows - but if I really think to it, it's more about trying to push the paradigms of this one (newer!=better => let's stick with old sw) on a platform where it doesn't belong.

mirh on 5 Sep 2017

@mirh

Just check if user has at least version X, and you are done?

That's the theoretical/utopian idea behind dynamic linking that if true would eliminate the need for static builds almost completely (unless wanting to run something on a very old or limited platform). In reality that's not how it is, and it never will be. There's several reasons for this, API stability is one.

Even something that is very carefully designed (which isn't true in most cases) can't guarantee that it won't have to break its API at some stage. It's simply impossible to predict the future when creating an API and sometimes an API will have to change because circumstances outside your library changes that makes the previous API impossible (another library changes, some security issue arise or other "rule" is imposed). Other times it turns out that the way the library has evolved the current API blocks further development, something need to be refactored in such a way that the calls have to be changed.

Another reason is bugs/regressions. Bugs are created all the time, and some aren't considered as critical by the developer and won't be fixed for years or at all. It could still be critical for your application, and unless you want to rewrite that part of your application or find another solution (if possible) each time this happens, you might simply have to stick to the version before the bug. This is probably the biggest problem, also because you won't know that the new version of the library has a new bug that affects you badly and will have to spend maybe a considerable amount of time to pin down the issue.

There was a regression in JNA (a library on which UMS depends) at one stage that I think took us more than 6 months to figure out, seemingly randomly creating problems for our users. I spent a lot of time to figure this out, and to be honest I'm not that tempted at just upgrading JNA again unless there's new functionality that we need. When a fixed version of JNA was finally available (about 1 year later I think), there were new problems (it would no longer work with Windows XP). As long as you control the version of the libraries you can at least to some extend handle this, but with dynamic linking you're basically at the mercy of the library developers. Add to this that there's often hundreds of dependencies, all which can cause similar problems, and to make it worse often depend on each other as well.

Yet another reason is that developers stop supporting/ditch things they consider irrelevant or "out of date" all the time. This might force you to stay with an older version or rewrite your implementation if that's a possibility.

I had to roll back 70 firewalls running on the Linux kernel once. Since firewalls are all about security, you typically update them pretty quickly when some update is available, and so we did. The result was that things stopped working completely on all these sites. There were no information with the update that indicated that we would get any problems, and as these sites were businesses I was under a lot of pressure to solve it. It was a real nightmare to pin down, but I managed to figure it out in the end.

In turned out that our configuration relied on something called IP masquerading, and the ability to do this was central to us, so central that we wouldn't have chosen that firewall if it weren't possible. The update contained a kernel upgrade, and it turned out that one of the central IP stack kernel developers had removed masquerading. His arguments were that it was basically a hack and that keeping it prevented some other development that he deemed more important. I found some discussions about the topic, but all protests were basically quelled. He might have been right in his arguments, but that's just the thing. We only used this, we knew nothing about it's kernel implementation. We relied on this functionality, and there were no alternative way at the time to achieve the same functionality. We had no other option than to downgrade.

Being stuck at an older version isn't something you want to do on a firewall, so we had to come up with an alternative network design that was inferior from our POV and was much more labor intensive to maintain, to be able to use updated version of the software. This one decision made by some to us unknown developer made what initially was a great solution become only bearable. The developers of the firewall knew nothing about this, as the change was in the Linux kernel.

The same kind of issues happen with libraries, and sometimes there are no good alternatives. In addition the older version of the library might just work perfectly for your use, and you might have nothing to gain from new functions or bugfixes that is applied in later versions. The headache is potential security fixes, that will be unavailable to you, and the risk that some other dependency requires a newer version.

Dependency management is more than a handful even when you do control the version of the dependencies, and when you've finally found a combination that works it makes a lot of sense to be able to "freeze" that as a static build. Dynamic linking with no control of your dependency versions reminds me a lot of Russian roulette. Sure, you can limit the versions of the dependencies you require to some specific versions, but that will make it very hard if not impossible for users to get your application to work, as these dependencies are shared with other components on their system with different needs.

The added size is a very small price to pay as I see it, and in many cases it's very worth it. Those that have conceptual/philosophical issues with this is clinging to an idealized utopia in my opinion. Sure, it's easy to agree that the ideal goal would be dynamic linking eliminating redundancies and allowing bug and security fixes to propagate quickly and effectively. The problem is that you have to close your eyes quite hard to a lot of realities to keep the idea alive.

As I've said all the time, dynamic linking makes sense in some cases, especially on the "OS" level or among closely related software. That doesn't mean it makes sense for everybody.

Nadahar on 5 Sep 2017

Ehrm.. I'd like to recommend you to at least finish reading posts before replying.
Also, you are quite mixing up stuff.

"Wanting to run something on a very old or limited platform" is exactly what the source of our problems reside. Which all Windows versions are (I mean, from ffmpeg pov) and _some_ times linux.
Seems a bit.. paranoic (? idk) to point the finger necessairly over this.

As for api breakage, I even linked the ffmpeg document that keep track of everything.

Then, putting aside bugs are a bit OT here, not wanting to be the firsts having to discover them, is why "keep old" is the ruling mantra on servers (but security fixes, but it's not like you need to stay on Arch unstable branch).

I'm really sorry for you and JNA, but.. Idk, if feels more of "that one time the worst of the worst happened" than anything, considering e.g. how quick folks on zeranoe are quick to spot issues.
I guess something similar is whatever happened with subs.. But that's the decreasing ladder to perfection?

And thank god you are not depending on any closed source dependency! ^^

p.s. case in point, users are pretty happy

mirh on 5 Sep 2017

As much as I am enjoying the recent exchanges between @mirh & @Nadahar (about the merits and flaws of static/dynamic linkage on various Linux distros), IMHO the discussion has derailed itself significantly from OP, which was reporting the fact ffmpeg.exe currently shipped with UMS won't run on Windows XP SP3 (and if the devs move on to a recent Zeranoe build, eventually on Windows Vista SP2).

I am not a troll, my intention is not to turn this specific issue into a "Running a Windows OS that M$ currently don't support" discussion. I am not running XP either, I have no ideological issues against that OS, however I still am quite miffed that many app authors seem to put my OS, Vista, in the same boat as XP;
most notably Mozilla devs copying to the letter what their idols, the Google Chrome devs, did... But this is another matter altogether, foreign completely to this tracker...

WRT Vista, securitywise I am covered by installing manually security patches for Windows Server 2008 SP2, that M$ will continue to patch for as long as Win7 SP1; and given that Vista accounts for ~ 0.6% of Windows OSes, I'm not that bothered a malware author will specifically target my platform...

I have in the recent past experimented with compiling myself (on this Vista laptop) a Vista compatible recent FFmpeg binary, however the native compiling suite itself (MSYS2) is moving at light speed away from Vista support...

So, to recap, we need an official word from the UMS dev team outlining their intentions/plans on keeping
a. Windows XP SP3 support (EOL'd April 2014 by MS)
b. Windows Vista SP2 support (EOL'd April 2017 by MS) & Windows Server 2008 SP2 support (on MS Extended Support until Jan 2020).
(Notice how I kept XP/Vista as separate to each other there... ).

Best regards

Vangelis66 on 5 Sep 2017

😄1

@mirh

Ehrm.. I'd like to recommend you to at least finish reading posts before replying.

I did, I'm describing the problem generally, not specifically for UMS or FFmpeg. If I missed some point of yours, please bear with me as I'm not a native English speaker.

Also, you are quite mixing up stuff.

Please enlighten me then, I'm using examples to try to explain what I see as challenges to an approach. The examples are just that, and isn't necessarily relevant for UMS or FFmpeg. What examples I choose depends on what I remember at the time of writing and how precisely they show a particular issue/problem/challenge.

"Wanting to run something on a very old or limited platform" is exactly what the source of our problems reside. Which all Windows versions are (I mean, from ffmpeg pov) and some times linux.
Seems a bit.. paranoic (? idk) to point the finger necessairly over this.

I'm not sure I understand what you mean here. It seems to me that you're implying that only the very latest iteration of everything is viable. I disagree for many reasons. If you're talking about one or two desktop computers with recent hardware that you periodically reinstall when things get to problematic, I guess it makes some sense. That's not always the case though, and I see no reason to retire hardware until it either dies completely or has no potential use because it's too slow or lack essential capabilities. In UMS' case it's something you'd typically run on a server, that might be a "retired" desktop that you leave running 24/7 performing various tasks you want available on your home network. Also, doing constant upgrades and reboots (and problem solving as a result of the upgrades) isn't my preferred way to spend my time.

It's not uncommon that hardware limits your upgrade ability, either by the lack of drivers, because newer versions require to much resources or require features you lack. I've got a laptop which is limited to Vista because nobody has bothered to create drivers that work with later OS'es (it becomes quite unstabile with Windows 7). I also have a scanner which is working perfectly, but for which I've not been able to find a working driver for any other OS than Windows XP and 2000. Using it means I need to have one computer running XP, and since it uses the LPT port running it as a VM on more recent hardware isn't that simple. Having a computer around only for running the scanner driver is quite stupid, which makes it quite logical to me to be able to put some other services on it as well. I don't want to buy a new scanner for around $1000 (very approximate one with similar capabilities the last time I looked at it) as long as the one I have works perfectly well the few times I need it.

I believe there are many such cases out there, and that we shouldn't be so quick to throw away stuff that works.

The JNA example isn't a "one off", I've been in similar situations many times. Even though this one took particularly long to figure out, I experience similar problems relatively frequent. Even if you solve it within 2 weeks, it feels like a waste of time - and sometimes there are no good solutions.

Nadahar on 5 Sep 2017

@Vangelis66 I agree that our discussion has went quite far off topic, and isn't very relevant to this issue.

I can only speak for myself, there can often be difficult to get a consensus among the developers because some aren't very responsive. My view is that we should try to find a way to support older OS'es as long as it is possible, although I can't say what will happen to the bundled FFmpeg version.

I think many developers simply are to lazy and arrogant to bother, and that support very often break for no good reason. In addition, there's a significant push from commercial sources to force people to upgrade so that they can make more money. I think it would be natural that the open source community tried to resist this and gave users the freedom to choose also what hardware and OS they want to use. The recent stunt from Intel refusing to release drivers for their latest chipset/CPUs to Windows versions older than Windows 10 really stunned me and have created a serious dent in my otherwise quite solid "Intel loyalty". I don't know how much Microsoft paid Intel for that, but it's so rotten that I've got a hard time to find the words. I often wonder if there are other "transactions" taking place, also to open source developers at times.

My point of view is that as long as Windows XP is used by so many people, ditching support for it shouldn't even be up for discussion. To me it is completely irrelevant if an OS is EOL'd by some commercial actor.

Nadahar on 5 Sep 2017

👍1

I did, I'm describing the problem generally, not specifically for UMS or FFmpeg.

_Yees_, but then you don't go on repeating stuff I already put off the list.

It seems to me that you're implying that only the very latest iteration of everything is viable.

On linux, yes I'm implying that latest>>everything. Aside of short update 'lags' to stay on the safe side, granted.
On windows as I wrote above the situation is very, very different.

p.s. for the love of all the sw headbanging in my life, I can hardly believe there's some driver working fine in Vista but not in 7
I do have a Vista pc, which I use and all, but that's only because I'm too 'proud' of its license to smuggle anything else (and my dad needs Access - whose 97 edition will run perfectly under wine by the end of the decade perhaps ^^)

p.p.s XP is really in a very special position then. Since hardware of those years can still carry out satisfactorily some tasks, but even assuming (and it hardly is) that drivers support is ok, modern linux can hardly use 130MB of ram.
And old one, objectively sucked hard.

I still am quite miffed that many app authors seem to put my OS, Vista, in the same boat as XP;

fucking /thread
is so sad exams got him to find/participate to the discussion only when it was too late to point that out

The recent stunt from Intel refusing to release drivers for their latest chipset/CPUs to Windows versions older than Windows 10 really stunned me

If you are talking about microcode, that's likely simply microsoft giving 0 fucks about updating their loader on older OS (workarounds exist btw)
If you are talking about, say, drivers for thermal/power and whatever... I'm not saying WDDM differences are really that huge as they make it sound.. But tbh it quite fall short of making sense to support these meticulous affairs for use-cases that are already special in themselves

I'd feel dirty, to be honest if even, to call that bad on Intel after all their immense work on linux. Seriously :\

p.p.p.s I took the liberty to let the OT go, since last time I checked we were already only waiting for #1370 to call a day on this.

mirh on 5 Sep 2017

@mirh

for the love of all the sw headbanging in my life, I can hardly believe there's some driver working fine in Vista but not in 7

I don't know how they managed either, but Dell has some "smart" device that controls all radios (Wifi, BlueTooth and GSM) which is integrated with the BIOS and a switch on the outside which lets you active/deactivate radios. This driver only works on Vista and below, and without it you loose access to all the radios. In addition I bought a Intel Wifi card off e-bay that was supposed to work in this laptop, which would install under Windows 7 but be extremely unstable (everything from connection loss to BSOD). Under Windows XP it works just fine. On top of that, I'm stuck with that laptop because it actually has an onboard serial port which was hard to find. USB-to-RS232 adapters can't be used in this case because I use it to run BMW's software for diagnosing and programming cars which runs on some old proprietary Linux version which has hardcoded the RS232 IRQ and address and can only talk via RS232.

I think you've gotten the time mixed up a bit, since the computers I run XP on all have 4GB RAM (which was the de-facto standard in the later years of 32-bit Windows). They are quite capable of many tasks still, mine has dual cores from 2.2 to 3 GHz.

If you are talking about microcode, that's likely simply microsoft giving 0 fucks about updating their loader on older OS (workarounds exist btw)

I haven't looked into the specifics/cause, but I'm talking about this. It seems Microsoft got AMD on board too. As I understand it, it's simply because Intel and AMD has agreed to not release chipset drivers for older OS'es. It's obvious that Microsoft won't do anything to support anything than their belowed Windows 10, but I don't understand why Intel and AMD would help them in their effort. All I need to know for now is that I have to use older hardware until Linux has become a viable alternative for me. I'm sure there are or will be workarounds, but I'm not too keen on that as they have a tendency to break or have other consequences that might compromise stability. This is especially true considering that Microsoft is doing everything in their power to force people to upgrade, so sabotaging workarounds will be high on their agenda.

Nadahar on 5 Sep 2017

Dell [...] via RS232

Fucking hell.
I read.. this?
EDIT: https://www.reddit.com/r/ReverseEngineering/comments/776mqa/reverse_engineering_of_the_nitro_obd2/

I think you've gotten the time mixed up a bit, since the computers I run XP on all have 4GB RAM (which was the de-facto standard in the later years of 32-bit Windows)

Well, maybe I was talking about older ones indeed?
Like, I had a P4 with a SiS gpu until last year.

p.s. of course 4GB is the standard when the death of 32-bit Windows come - in like every universe. That's not a synonym with XP os or systems though

I haven't looked into the specifics/cause, but I'm talking about this

Yes, which in turn is damn-not a problem. That was just about microcode. They are still x86 cpu.

As I understand it, it's simply because Intel and AMD has agreed to not release chipset drivers for older OS'es.

BS. Both works without a problem. AMD even has official chipset drivers on their website.

but I don't understand why Intel and AMD would help them in their effort.

It takes a good amount of will to misunderstand to go down your wrong slippery slope.
This indeed didn't happen. I'd really re-check whatever you did the day you got this info.

mirh on 5 Sep 2017

@mirh

I read.. this?

There's a lot of stuff you have to get right to get a solution up and working. I opted for a real serial port instead of using a PCMCIA workaround that sounds like a gamble to me. If I already had the laptop and a PCMCIA card I would have tried, but I didn't and I bought this laptop with this in mind. That said, I see it as generally very useful to have RS232 as there are lots of equipment that needs a serial port to communicate. I have no idea why they even killed it, USB in much more complicated and unstable and isn't a full replacement as I see it.

Yes, which in turn is damn-not a problem.

Wrong - read your own link and you will quickly see that the "war" has already started and Microsoft is blocking the workaround. They are hell-bent on killing of their own user base.

It takes a good amount of will to misunderstand to go down your wrong slippery slope.
This indeed didn't happen. I'd really re-check whatever you did the day you got this info.

As I said, I hadn't checked the details (I have no plans to upgrade any hardware for the time being). But, when reading the article I linked to you can find this:

Both Intel and AMD representatives who were contacted also confirmed that the policy was in place for future processors like Kaby Lake and Zen.

AMD said its CPU roadmap was "fully aligned with Microsoft's software strategy", and Intel clarified: "No, Intel will not be updating Win 7/8 drivers for 7th Gen Intel Core [Kaby Lake] per Microsoft's support policy change."

I don't remember where I got the information initially, but what gave a similar expression (although AMD wasn't mentioned there).

If Intel and AMD isn't part of this, I'm very happy. I still don't want to rely on a patch to work around this unless Microsoft has "given up" the war, so for the time being I still see this as a big problem and a reason for me to think that my current hardware is the last that will be running Windows. This is also why I wish the Linux distros can "get their act together" rather quickly and make it ready for mainstream use. I really doubt I am the only one with this dilemma, especially considering that Windows 7 still holds close to 50% of the desktop marked despite Microsoft's best efforts to both allure and force people to upgrade to Windows 10.

Nadahar on 5 Sep 2017

I have no idea why they even killed it, USB in much more complicated and unstable and isn't a full replacement as I see it.

Because for everything on this earth you are supposed to be just fine with USB-to-serial adapters. From simple JTAG to whatever they frigging use on Fendt tractors.
Except bmw and their need of DTR-whatever.

Wrong - read your own link and you will quickly see that the "war" has already started and Microsoft is blocking the workaround.

Your objection to my objection is misstated.
Your link, your source was talking about one thing. The microcode.
THEN, way, way later, they added the block updates thing. I guess you can consider the two things related, at least on the "microsoft planning side", but that's not what the article supported here.

Nonetheless, focusing on the second issue, even putting aside the workarounds - anyway, that still wouldn't account for your level of alarmism. You just miss post-May updates. Nothing even remotely comparable to FF situation, which would correspond to not booting.

As I said, I hadn't checked the details (I have no plans to upgrade any hardware for the time being). But, when reading the article I linked to you can find this:

Yes, and that just implicitly refers to microcode, as I was saying.
Then you can tell me you didn't inform yourself properly as much as you want, but you should be sure about stuff before spreading it, in particular which such conviction - otherwise it's FUD.

mirh on 5 Sep 2017

Not fixed yet :(

444nonymous on 20 Jan 2018

@444nonymous the support of the Windows XP finished four years ago and the same apply for Java and FFMpeg. I don't think that we could support it. Sorry but you should blame others not us.
EDIT: when @Nadahar will finish the PR #1372 it may work on WIN XP too but who knows.

valib on 20 Jan 2018

@444nonymous That's not true at all. Whether Microsoft "supports" it isn't relevant, it just means that they want you to spend more money buying another version. Java works fine on XP, and the same does FFmpeg if compiled correctly.

Nadahar on 20 Jan 2018

❤2 👍1

Universalmediaserver: UMS is not compatible with Windows XP and Vista [FFMPEG]

Most helpful comment

All 33 comments

Related issues