Head over to winehq.org and see if all programs work, because there are a lot rated as "garbage". About the DLLs... they shouldn't need to ship MS DLLs if they are trying to emulate them. If they can't, you end up with some kind of cyborg (half emulated - half native), for sure not open source anymore (Richard Stallman would cry if you used a closed source DLL). And that's exactly my point, why use a cyborg when you can use the "real thing" ? According to winehq.org, the project started in 1993, that's 20 years. If they have not managed to achieve a working piece of software in 20 years... well, maybe they should change business. This is obviously my opinion, and I respect yours.
Originally Posted by ninez
Wine works just fine. I'm able to run fomat factory, virtualdub (using ffdshow for decoding), avisynth scripts, Emule Extreme (this was such an surprise), games like Medal OF Honor Pacific Assault and Cossaks for example. Even atube catcher worked for me.
Wine can be what it was supossed to be: a complete compatibility layer of windows that can run any windows app in linux. Back in 2008 the project was likely to fail but now they've managed to get something working properly. I kneel to these developers. They deserve our support.
P.S: Sorry for bad english.
Why would somebody care about it being all open source or not if you are going to use it to run windows stuff ?
Originally Posted by wargames
I'm quite aware of WineHQ, thanks. I didn't say that ALL programs run, I said that "i can run all of the programs that I like". Which i can. I run several Plugin Suites / boxsets (VSTs) in Wine very reliably, good performance. Wine is intended to be able to use Windows DLLs / i don't think the idea is to re-write any and every dll in Windows. -> You may have the expectation that anything less than porting every last DLL / component, means that Wine is junk - but that's a pretty unreasonable expectation to begin. It also doesn't change the fact that your problem with Wine not working is your own fault... The problem is your thinking, not Wine.
Originally Posted by wargames
Also, it does not make Wine any less oensource - Wine is LGPL to begin with - ie: it's intended to be able to be used with and/or have Non-GPL components linking against it; including proprietary S/W... Again, you claim that it isn't a working peice of software - yet i have tons of applications that run fine && you also must not be aware of the fact that Wine is used in several peices of Commercial H/W (high-end Proaudio gear). ie: i don't think they need to change business; Several successful commercial versions of Wine + winelib has been used to port many applications over the years in Linux && MacOSX. Other S/W also has leveraged Wine code / Codeweavers expertise; ie: paid work for those developers..
The problem is that I don't know which combonents to install. An advice is to check wine database. But I don't learn anything from that when copying other users. I have no clue how they have solved the issues they are facing with wine. I have recently checked wine git and I have seen really empty files basically just some definations. No wonder those files don't work.
Get any game you want. Search it's name on youtube with +wine and you surely find a gamer that has got it working on wine.
But when I try to do the same I don't get the exact results.
Now I have tried metro 2033 and I have some weird issues on the starting screen.
I don't see the DX9 State Tracker. FAIL!
Wine DOES work. Yo cannot be serious saying that every dll should be ported. Like you say it's 20 years and they are "just" developing a compatibility layer (actually wine is not an emulator). Porting the dll's cannot be done. Too much time, too few resources, and it makes no sense. Once they implement every system call that windows offer it will run EVERY app and dll (not counting bugs). Wine tries to make every dll run natively, without ports, and that's what trully matters now. Porting dll's is just a waste of time that leads nowhere, except more problems. And shipping all the dll's with wine is not viable either; it's a waste of HDD space. So anyone that wants to use wine has to install things that are needed.
Originally Posted by wargames
Waste of hdd space?
How small is your hdd?
I would not mind downloading bigger wine if it had more dlls and files if it would help wine to self diagnoze what files are needed.
Porting DLLs matters when they need to use Linux-side stuff (since winelib apps use both Linux and Win APIs), in these situations, it's crucial to port, but for other higher level code/DLLs it's not essential or even wanted, in some cases. (just to add to what you said)...
Originally Posted by lequim
But to correct you on one point; not shipping DLLs in Wine has NOTHING to do with being "a waste of HDD space". It is a legal matter; It is illegal for the (Wine) project to include that stuff. You are subject to Microsoft's licenses / EULA... Hence why winetricks is a script that pulls DLLs / fonts / Runtime(s) from MS' servers (which is not illegal).
Plus (regarding instlaling DLLs), installing most of what you need is easy (unless it's wine64, which is more manual but simple too). You basically install; all fonts, all codecs, vcrun* stuff (runtimes), gdiplus, etc - and leave the rest until a specific app needs something extra. (literally, check a few boxes and let the script run, depending you may need to run it again in some situations. easy stuff).
most of the time, you can tell what is missing by starting the app from the commandline - usually an error will appear and it is often easy to identify the missing component based on that + a quick google search, if needed.
Originally Posted by deri
Last edited by ninez; 09-14-2013 at 02:14 PM.
I am using playonlinux because of simplicity to use.
What I see on playonlinux debug, I don't see easy interpreted messages that give you hint what files to install.
It should be like that wine reports files that are MOST likely to be missing.
It goes wrong if I have to search all myself out.