I had a question about where wine is headed. As a programmer, I like to jump from thing to thing myself, especially new things. However, since wine is supposed to provide a compatability layer, shouldn't it be focusing on the bricks first instead of the sky scraper windows? I'm not saying that I don't like when new directx support comes, and games tend to work better, because I do. A lot :). What I am saying is that I think wine is at the point where it's "mostly" working well with a lot of different things somewhat consistently, but I still see things like Office 200x that still don't work 100%. Now office itself isn't the most important thing in the world, but what It stands for is important. It's an application that almost every single pc with windows has. There is little left to do, and I know it's the boring stuff. But like I said, I think those things should be killed and gotten out of the way first to get wine to be more predictable and stable sooner. Don't get me wrong here, I'm not criticizing anyone or anything. I am amazed it's gotten this far, this fast. Wine is very impressive! I guess what I'm asking is, if some kind of roadmap exists anyone so I know what kinds of goals are being set, that kind of stuff. It would be cool to see some kind of subsystem diagram with little percentages in it so we know whats up in a single page.
http://test.winehq.org is where we mind our p's and q's. When the row at the top turns all green, all our low-level tests will have passed, which will be a huge milestone for us. We need a corresponding page listing application test results, but we don't have one of those automated yet. (There was one, cxtest, but it never caught on.)
Jim Hall the issue you are talking about is not exactly true.> Doesn't work with newer cards and motherboards that don't need or use shared RAM.Opengl itself that wine uses. Give no promise that data will be stored in the video card. Under opengl spec its fine to be stored in cpu ram or video card or anywhere else your opengl drivers see fit. Due to this fact Opengl does not in fact tell applications how much ram a video card has. Since it should not need to know. Wine has a table of video cards models it looks up and takes the size from that. How did you try the registry key for video card memory size. Many people stuff up. Set value stop wine completely with like wineserver -k then run application and the new size should appear. The value is not for shared ram systems at all. Its due to the fact opengl tell us nothing about how much ram the card has. So wine takes a guess. Now either Jim you have run into a bug with wine detection of your card. Or a bug in wine feedback path to application reporting memory size what will be fake or guessed never real. If it matches real everything has worked out good. Really you have not provided enough information Jim. If you are running a old version of wine. There is a possibility that wine is failing to 256 because it simply does not know you card. Wine --version, program and video card please oiaohm
Hey guys thanks for your answers, I was expecting people to fight a little bit more, but it's a nice surprise that this is not the case. I've got a better sense now that i've seen some of the other pages. As for being a programmer, yes I am. However I started with .net... VB.net, not even C# (although translating it isn't that hard *most* of the time). I wish I could help with the project, but I feel learning assembly would be easier than the myraid of unmanaged languages available in between. I am however pretty involved with windows subsystems, and I know just using directx is a real pain, let alone reverse engineering it! As for windows being an always changing beast with updates, I figured they were either just fixing bugs, or extending windows with new API's to play with. Also thanks for the clarification on office, I didn't realize that it uses directx. I did know that it must be incredibly complex just in order to support VBA inside itself and be so automateable. In your video problem, I never really noticed this. I guess i'll have to try to run some benchmark and information apps within wine to see if it's doing the same to me, and if I can get any ideas. I've only played red alert 3 wich mostly works minus high shader settings, and tomb raider (the mouse clicking one) and that seemed to look okay then go black. If I had to guess though, I'd just attach a debugger and set breakpoints all over the place where anything related to memory information functions are called and see where in the stack something is changing the value or detecting it incorrectly. In Visual Studio I'd just find a simple program that shows the memory installed and trace it backwards up the stack.
On 2/9/11 9:29 PM, kanaida wrote:> I wish I could help with the project, but I feel learning assembly would be easier than the myraid of unmanaged languages available in between.To hack on Wine (that is, write code for it), you only need to know one language: pure, procedural C. Plus, there are tons of other ways to help us besides writing code. Check out http://www.winehq.org/contributing for a whole list of ideas! Chip