Meanwhile Windows has DirectX 12.
X11 is crap. The response is Wayland and Mir are coming soon.
Every single time something is missing the response is "don't worry, it's coming soon", but it's never soon.
And OpenGL is probably going to get mantle and we'll have that. At that DX12 will have a lot of bugs on release like everything else. 11 and 10 might be meh but a lot of games are still using 9. When 10 and 11 come that'll just be more area to fill. More I am going to be that the DX12 games will also have 10 and 11 support. That just means we can play the new games that are coming out and DX 12 will get it's work pushed in just like everything else.
I never said that Wine is too difficult to use by an average user.
Instead of using the toolkit myself, I could have just used an sdb file that somebody else created with the toolkit. I was just curious to see how the toolkit works.
From a programmer's point of view, it's a lot easier to use the toolkit to create an sdb file and make it available for anyone to download, or to make a tutorial, than it is to make Wine compatible with a certain program.
Yeah, and thousands of people make wine how-to's and playonlinux how-to's.
http://www.gamersonlinux.com/forum/portal/index.php
http://www.gamersonlinux.com/forum/forums/guides.20/
The difference is that you don't have to code sdb files to be able to use wine. You don't have to code at all.
When I said programmers I was talking about Wine developers. The people who program Wine to make it compatible. They choose the hard way because open source.
Opensource just makes it easier. If you want to work on bugs on wine, jump in! There is a userpool of programmers that work on the platform. It's the same as Wendell submitting a bug report on the ubuntu install he did. It was on the installer breaking. Canonical doesn't make it's own installer it's made by users. Those same users can make the patches and a lot of them do.
We're repeating ourselves at this point so either this debate is done or something new is going to pop up.
TL:DR : They aren't doing it the hard way. Users can fix the stuff they find wrong and sending it to the devs or submitting it to the the WineDB. Thats why open source is better than having 15 guys only.
Ask any linux user.
If I was a small developer I would program for Windows and I would not depend on undocumented API behaviour, so that the program will continue to work for a long time, without me having to keep up with Windows updates. That way I only update the program when I want to, not when I have to.
On Linux, if my program is not popular enough, nobody will maintain compatibility for my program.
Undocumented? HA don't make me laugh because I won't be able to stop.
Undocumented my ass. Did you even see the WineDB?
https://appdb.winehq.org/objectManager.php?sClass=application&iId=5839
https://appdb.winehq.org/objectManager.php?sClass=application&iId=13667
https://appdb.winehq.org/objectManager.php?sClass=version&iId=19444
https://appdb.winehq.org/objectManager.php?sClass=application&iId=25
Users document the versions, distros they use, list down the bugs and bug behaviour, and work together to get things to work.
The versions are listed, the use of those versions is listed, and the quality of those versions in compatibility is listed. Undocumented my ass. And if you want to argue support everyone is going to say "There is an IRC channel for that". IRC is easy to use and almost any linux user in ANY linux channel who has wine experience is willing to help. If I ask something about an issue in wine in the archlinux channel alone I get about 15 responses.
Do research before saying there is no documentation.
I'm talking about stuff that's not found in Microsoft's official documentation. Microsoft only maintains compatibility for it's own official documentation.
You...... DO know wine has no MS devs..... Right?
When I said:
I was referring to:
I wasn't talking about Wine.
It was you who brought up Wine's documentation, not me.
I should have explained which documentation I was talking about.
At that same area why would I make a program based on windows XP. Your wording makes it sound like a new dev would make an app based on outdated software.
Of course if I was a new dev I would make an app on a new platform that just came out. Unless you were doing projects for unused systems (like making PPC based apps for something like a powerbook 5,7) you would be kind of stupid to be a "Windows 98 developer". You would be the ONLY current windows 98 developer.
That's not my point. My point is:
Meaning that if I make a program for the latest version of Windows, it will still work on future versions without me having to update it.
Nobody says that I can't update it in the future and base it on a future version of Windows. But like I said in that quote, I only do that when I want to, not when I have to.
There are apps like this. With that, the current version of Wine that is labeled as LTS, 1.6.2, was released FOREVER ago. If you're a wine user like me and want the newest version, currently 1.7.50 (or 51 maybe), you can add that. Updates to wine are just added in the rest of the system updates and, unlike windows, you don't have to reboot all the time and wait 20 minutes for them to install. The most you would have to reboot for is GPU drivers.
In any sense Wine 1.6.2 is worked on by the users and guides for 1.6.2 are still being made.
You think that just because the version number is 1.6.2, than the code is exactly the same when you install it on different versions of a distro.
Linux doesn't work that way. The Whine 1.6.2 that you find on the latest version of a distro has been modified to only work on that version, and Whine 1.6.2 that you find on a previous version of that same distro also has different modifications to make it compatible. It's not exactly the same program.
The only purpose of the version number is to tell you that, even though is not the same code, the program behaves (or should behave) exactly the same on all versions of the distro on which it's available, like it's the same program, but it's not. It's a common misconception.
People don't notice this because repositories hide this information. They make it look like it's the same code.
In the case of Wine, it means that all games that are reported to work on Wine 1.6.2 will work on Wine 1.6.2 regardless of which version of the distro it's installed on.
If you have eidence of this that would be grand. If your evidence is that these "Special versions" are that they are compiled for different package managers for the differences in .rpm, .deb, and .tar then you saying that these "different versions" that are "specially modified" holds no ground. Of course it's given minor changes for the new versions of those package managers.
It's open source, so check it for yourself.
That's just one method.
The other is when you put all those modifications in one program (or one executable file), and when the program is executed, it checks to see what version of the distro you're running and selects the appropriate modification.
If you're asking "Well if the API function that checks the version isn't backwards compatible, how is this supposed to work ?", well it just tries different versions of that function until it finds the version that works correctly.
This is just as bad, because you still need to add new modifications when the distro is updated.
I mean actual evidence, ie documentation, that what your saying makes sense, because to me it doesn't
Yeah, theres going to be certain bugfixes. Each wine version adds another tool that wasn't there before.
I can check it myself, but there should be a document that says what you're saying as fact isn't fiction. It's not being coy, you just sound like you're making stuff up at this point.
If anyone else can back him up, by all means, go ahead.
Edit: I have provided sources for my statements.
Edit 2: Saying that different package managers need to have the packages set up differently is basically reaching as far as possible. That has nothing to do with how wine works, how it's development works, or how updated it is. It is a fact that RPM is different than DEB. Ooooo~~~.....? Congrats, you've discovered letters! / That package managers work differently!
If you are a third party developer for a Microsoft target, you will need to maintain your packages just as well, except that you'll also have to live with the uncertainty of the platform, which depends only on executive decisions by Microsoft, not on the actual opinion of all the users like in open source.
There is no "fire and forget"-type software development, you have to remain active to maintain your product. Open source development is constantly a work in progress, because everyone can add improvements all the time. With closed source, the software quality is just not visible, the bugs are obfuscated, but that doesn't mean there are less of them, the difference is, that nobody is going to fix them except by executive decision... I'd rather put my faith in the hands of the actual users lolz...
1 Like
Now can we stop this stupid debate? This is getting awfully boring at this point and you're not basing any of your arguments on any facts.