May 2009 - Wine-Devel - list.winehq.org

"How Not To Develop On Windows"

by Dan Kegel

http://pdh11.blogspot.com/2009/05/how-not-to-develop-on-windows.html is a partial guide to developing Windows GUI apps on Linux using mingw and test them with Wine. Seems like an expanded version of this might belong on the Wine wiki...

May 31, 2009

Re: winecfg: Update WinXP version to SP3

by Austin English

On Sun, May 31, 2009 at 1:36 PM, Vitaliy Margolen <wine-patches(a)kievinfo.com> wrote: > --- > programs/winecfg/appdefaults.c | 2 +- > tools/wine.inf.in | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) You forgot to update ntdll/version.c -- -Austin

May 31, 2009

Re: DIB engine

by Stephan Rose

On Sun, 2009-05-31 at 12:23 -0700, Dan Kegel wrote: > On Sun, May 31, 2009 at 12:45 AM, Stephan Rose <kermos(a)somrek.net> wrote: > >> If you're looking for something better specified, try finishing off > >> gdiplus. > > ... I'll check into gdiplus missing bits sometime next week. :) > > > > My name's Andrew Eikum, I'm an undergraduate Computer > > Science student at the University of Minnesota. > > I contacted a Wine dev a few weeks ago asking for a small > > project to use to get familiar with Wine. I was pointed > > towards the gdiplus section and told to begin stubbing > > out the missing functions, to facilitate debugging. > > After familiarizing myself with how Wine's DLLs are built, > > and with Git, I'm now making quick progress. I expect to > > have a (huge) patchset ready in the next week or two with > > most of the gdiplus functions stubbed. > > Excellent! (And Stephan, there's more than enough work > to go around, don't worry that Andrew's going to do it all :-) Hahaha, not worried. Btw, I seem to have a handle on the stringformat alignment bug. By the looks of it I may have a patch for that sometime over the next couple days. Don't know if I will make it today as I have a roughly 5'6" brunette incentive to do something other than write code tonight. :) Stephan

May 31, 2009

Re: DIB engine

by Dan Kegel

On Sun, May 31, 2009 at 12:45 AM, Stephan Rose <kermos(a)somrek.net> wrote: >> If you're looking for something better specified, try finishing off >> gdiplus. > ... I'll check into gdiplus missing bits sometime next week. :) > > My name's Andrew Eikum, I'm an undergraduate Computer > Science student at the University of Minnesota. > I contacted a Wine dev a few weeks ago asking for a small > project to use to get familiar with Wine. I was pointed > towards the gdiplus section and told to begin stubbing > out the missing functions, to facilitate debugging. > After familiarizing myself with how Wine's DLLs are built, > and with Git, I'm now making quick progress. I expect to > have a (huge) patchset ready in the next week or two with > most of the gdiplus functions stubbed. Excellent! (And Stephan, there's more than enough work to go around, don't worry that Andrew's going to do it all :-) > After that, I plan to begin work on implementing some of > the functions. My degree's emphasis is computer graphics, > so working on gdiplus will give me a chance to learn more > about the field as well as apply what I already know. > I'm looking forward to working with other Wine devs on > gdiplus, and other parts of Wine in the future. That's great to hear. Looking forward to seeing your patches. BTW, don't forget to look at http://wiki.winehq.org/GdiPlus, which has a few notes that might be helpful. My archive of Lei's notes at http://kegel.com/wine/sweng/2008/project.html from last year might be useful, too - it was tailored for people new to wine who want to contribute to gdiplus. (Though its big list of bugs is mostly all fixed now, I think only four remain.) - Dan

May 31, 2009

Re: Its Alive! Patchwatcher is reborn.

by Zachary Goldberg

On Sun, May 31, 2009 at 2:59 PM, Dan Kegel <dank(a)kegel.com> wrote: > Congratulations! It's nice to see it running again! > > Are you running it all on one node, or are you > using the distributed mode? I am using the distributed version of the code but for now its just on one machine. I was actually able to get it mostly working using just the provided wine-slave and master.sh. Over the summer I will look into seeing if I can scale it out a bit to a dedicated linux &&/|| windows slave . It seems plenty fast enough to keep up with wine-patches running just in Wine for now. > > Have you been watching patchwatcher's mailbox > for partial patch series? That was the biggest > chore of running Patchwatcher. > At one point they blocked the pipeline of > incoming patches, not sure if I fixed that. > Having patches back up is bad because they rapidly > go stale. > - Dan > I have seen the stale problem (I had the mailbox enabled several days before I let it start processing patches...). I haven't been but will now look out for a partial series. I will be away for the next 2 weeks starting Wednesday so there is a high probability it hangs sometime while I'm gone. It'll provide a good test case when I'm back to try and find a solution in-code =P -Zach

May 31, 2009

Re: DIB engine

by Austin English

On Sun, May 31, 2009 at 2:11 PM, Andrew Eikum <andrew(a)brightnightgames.com> wrote: > I am definitely doing small commits and following the WineGit wiki page. > One concern I have is that the number of patches will probably be over 50 > or even 75 -- I'm not sure if it'd be better to submit them all in one go as > they're pretty much all alike (just stubbing), or just do batches of 5-10 > every couple days as I finish them (so it's not a deluge of patches). Any > suggestions? No need to wait, go ahead and submit a couple. Since you're new to wine, it may take a couple days for them to get committed. Once you've got your feet wet and a few patches submitted, go ahead and submit a few more (5-10) a day. Try to avoid flooding wine-patches. The patches don't depend on each other, and it's not a huge rush to get them all in. And no need to wait to stub everything before sending implementations. If you've got it ready, and it works (add testcases to verify), send it in. Don't sit on your good patches, share them with everyone else :-). -- -Austin

May 31, 2009

Re: DIB engine

by Andrew Eikum

Austin English wrote: > On Sun, May 31, 2009 at 11:16 AM, Andrew <andrew(a)brightnightgames.com> wrote: > >> My name's Andrew Eikum, I'm an undergraduate Computer Science student at the >> University of Minnesota. I contacted a Wine dev a few weeks ago asking for >> a small project to use to get familiar with Wine. I was pointed towards the >> gdiplus section and told to begin stubbing out the missing functions, to >> facilitate debugging. After familiarizing myself with how Wine's DLLs are >> built, and with Git, I'm now making quick progress. I expect to have a >> (huge) patchset ready in the next week or two with most of the gdiplus >> functions stubbed. >> >> After that, I plan to begin work on implementing some of the functions. My >> degree's emphasis is computer graphics, so working on gdiplus will give me a >> chance to learn more about the field as well as apply what I already know. >> I'm looking forward to working with other Wine devs on gdiplus, and other >> parts of Wine in the future. >> > > Welcome to Wine! > > Be sure when sending patches to break them into small sets, with one > change per patch. It makes it much easier to review that way, and if > your patch causes a regression, much easier to identify which part if > it's in multiple patches. > Thanks for the welcome! I am definitely doing small commits and following the WineGit wiki page. One concern I have is that the number of patches will probably be over 50 or even 75 -- I'm not sure if it'd be better to submit them all in one go as they're pretty much all alike (just stubbing), or just do batches of 5-10 every couple days as I finish them (so it's not a deluge of patches). Any suggestions?

May 31, 2009

re: Its Alive! Patchwatcher is reborn.

by Dan Kegel

Congratulations! It's nice to see it running again! Are you running it all on one node, or are you using the distributed mode? Have you been watching patchwatcher's mailbox for partial patch series? That was the biggest chore of running Patchwatcher. At one point they blocked the pipeline of incoming patches, not sure if I fixed that. Having patches back up is bad because they rapidly go stale. - Dan

May 31, 2009

Re: DIB engine

by Austin English

On Sun, May 31, 2009 at 11:16 AM, Andrew <andrew(a)brightnightgames.com> wrote: > My name's Andrew Eikum, I'm an undergraduate Computer Science student at the > University of Minnesota. I contacted a Wine dev a few weeks ago asking for > a small project to use to get familiar with Wine. I was pointed towards the > gdiplus section and told to begin stubbing out the missing functions, to > facilitate debugging. After familiarizing myself with how Wine's DLLs are > built, and with Git, I'm now making quick progress. I expect to have a > (huge) patchset ready in the next week or two with most of the gdiplus > functions stubbed. > > After that, I plan to begin work on implementing some of the functions. My > degree's emphasis is computer graphics, so working on gdiplus will give me a > chance to learn more about the field as well as apply what I already know. > I'm looking forward to working with other Wine devs on gdiplus, and other > parts of Wine in the future. Welcome to Wine! Be sure when sending patches to break them into small sets, with one change per patch. It makes it much easier to review that way, and if your patch causes a regression, much easier to identify which part if it's in multiple patches. -- -Austin

May 31, 2009

Re: DIB engine

by Andrew

Stephan Rose wrote: > On Sat, 2009-05-30 at 14:14 -0700, Dan Kegel wrote: > >> Stephan Rose wrote: >> >>> My ears perked up when the two words DIB and spec were put >>> together in the same sentence. One frustration I encountered >>> when wanting to contribute to wine a little over two years ago >>> was that nobody seemed to be able to say "Hey, this is what >>> we are missing/need, here are the specs, go implement". >>> ... >>> So if anyone can drop a full spec into my lap which outlines >>> everything I need to write and where (given I adhere to things >>> as I should of course) I won't have any issues getting that accepted later on... >>> >> I don't think such manna is likely to fall from heaven any time soon. >> If it was that easy to spec, we would have been done by now. >> >> If you're looking for something better specified, try finishing off >> gdiplus. That's a somewhat well defined graphics package, >> and Wine's implementation has a few missing bits yet, last >> I checked. >> > > Ok, then judging from the last few posts i'll leave DIB be for now > seeing how there still seems to be some figuring out to do and I'll > check into gdiplus missing bits sometime next week. :) > > Thanks, > > Stephan I suppose this is as good a time as any to introduce myself. My name's Andrew Eikum, I'm an undergraduate Computer Science student at the University of Minnesota. I contacted a Wine dev a few weeks ago asking for a small project to use to get familiar with Wine. I was pointed towards the gdiplus section and told to begin stubbing out the missing functions, to facilitate debugging. After familiarizing myself with how Wine's DLLs are built, and with Git, I'm now making quick progress. I expect to have a (huge) patchset ready in the next week or two with most of the gdiplus functions stubbed. After that, I plan to begin work on implementing some of the functions. My degree's emphasis is computer graphics, so working on gdiplus will give me a chance to learn more about the field as well as apply what I already know. I'm looking forward to working with other Wine devs on gdiplus, and other parts of Wine in the future.

May 31, 2009

Re: Its Alive! Patchwatcher is reborn.

by Zachary Goldberg

On Sun, May 31, 2009 at 3:27 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > On Sunday 31 May 2009 09:05:36 Zachary Goldberg wrote: >> All, >> >> As you may have noticed in the last WWN I have been working on getting >> patchwatcher back up on a rather nice server whose cpu time is >> graciously donated by STWing (stwing.org) I've got it running at the >> moment at >> >> http://winepatch.stwing.upenn.edu/results2/ > > The most notable issue is that most patches fail to apply and apply claims > they're reversed patches. Are you sure you're using git am the right way? > > Cheers, > Kai > > -- > Kai Blin > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -- > Will code for cotton. > The code wasn't correctly checking for previously applied patches. Does it look more reasonable now in the number of patch application failures? -Zach

May 31, 2009

re: DIB engine

by Stephan Rose

On Sat, 2009-05-30 at 14:14 -0700, Dan Kegel wrote: > Stephan Rose wrote: > > My ears perked up when the two words DIB and spec were put > > together in the same sentence. One frustration I encountered > > when wanting to contribute to wine a little over two years ago > > was that nobody seemed to be able to say "Hey, this is what > > we are missing/need, here are the specs, go implement". > >... > > So if anyone can drop a full spec into my lap which outlines > > everything I need to write and where (given I adhere to things > > as I should of course) I won't have any issues getting that accepted later on... > > I don't think such manna is likely to fall from heaven any time soon. > If it was that easy to spec, we would have been done by now. > > If you're looking for something better specified, try finishing off > gdiplus. That's a somewhat well defined graphics package, > and Wine's implementation has a few missing bits yet, last > I checked. Ok, then judging from the last few posts i'll leave DIB be for now seeing how there still seems to be some figuring out to do and I'll check into gdiplus missing bits sometime next week. :) Thanks, Stephan

May 31, 2009

Re: Its Alive! Patchwatcher is reborn.

by Kai Blin

On Sunday 31 May 2009 09:05:36 Zachary Goldberg wrote: > All, > > As you may have noticed in the last WWN I have been working on getting > patchwatcher back up on a rather nice server whose cpu time is > graciously donated by STWing (stwing.org) I've got it running at the > moment at > > http://winepatch.stwing.upenn.edu/results2/ The most notable issue is that most patches fail to apply and apply claims they're reversed patches. Are you sure you're using git am the right way? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

May 31, 2009

Its Alive! Patchwatcher is reborn.

by Zachary Goldberg

All, As you may have noticed in the last WWN I have been working on getting patchwatcher back up on a rather nice server whose cpu time is graciously donated by STWing (stwing.org) I've got it running at the moment at http://winepatch.stwing.upenn.edu/results2/ There are still many, many kinks to be worked out before I would use this as reliable and/or before I even think about enabling sending to patch authors. But if you're curious thats where the results are going and will likely be in the future. -Zach p.s. Kudos to Dan Kegel for a great walkthrough in the PW readme.txt, and of course for putting patchwatcher together in the first place!

May 31, 2009

Re: WIne DIB

by James McKenzie

Ben Klein wrote: > Stop making new threads about this! We've already had too many DIB > Engine threads! > > > +1. Please keep all of the traffic on the DIB engine to one thread. James McKenzie

May 31, 2009

Re: WIne DIB

by Ben Klein

Stop making new threads about this! We've already had too many DIB Engine threads!

May 31, 2009

Re: DIB engine

by David Gerard

2009/5/30 Dan Kegel <dank(a)kegel.com>: > If you're looking for something better specified, try finishing off > gdiplus. That's a somewhat well defined graphics package, > and Wine's implementation has a few missing bits yet, last > I checked. OH YES PLEASE. (lots of apps missing bits of this - check over bugzilla and everything in it that's been stubbed) - d.

May 30, 2009

re: DIB engine

by Dan Kegel

Stephan Rose wrote: > My ears perked up when the two words DIB and spec were put > together in the same sentence. One frustration I encountered > when wanting to contribute to wine a little over two years ago > was that nobody seemed to be able to say "Hey, this is what > we are missing/need, here are the specs, go implement". >... > So if anyone can drop a full spec into my lap which outlines > everything I need to write and where (given I adhere to things > as I should of course) I won't have any issues getting that accepted later on... I don't think such manna is likely to fall from heaven any time soon. If it was that easy to spec, we would have been done by now. If you're looking for something better specified, try finishing off gdiplus. That's a somewhat well defined graphics package, and Wine's implementation has a few missing bits yet, last I checked. - Dan

May 30, 2009

WIne DIB

by chris ahrendt

On 05/30/2009 12:59 PM, wine-devel-request(a)winehq.org wrote: > Ben Klein ha scritto: > >> >> You would be surprised at how much of Wine is NOT a hack internally. >> Wine doesn't do hacks, > > Well, well.... there are some, indeed. > Of course, it's better not add new ones :-) > > hence AJ's reluctance to include the current >> DIB proposal in Wine (to make it "correct" later will require a lot of >> hacking, as Max has objected). > > Again, my engine isn't a hack. Nor you'll need hacks to embed it on > gdi32. > Even more, some parts will be simplified because of direct access to > internal > gdi32 structures, which can't be done (without hacks....) in current > implementation. > The *only* semi-hack is the direct access of gdifont struct from > inside winedib.... > it could also be avoided, but with much useless code added. > Useless because it will be so once embedded in gdi32. >> >>> Do we even have an architectural document or guidelines to reference? >> >> This was also raised on the existing thread. No. This is a problem. >> The best we have so far is "DIB engine should be integrated into >> GDI32". This is not a problem, because both Max and AJ share this >> goal, but if I understand correctly, Max doesn't want to invest the >> effort (which is a lot) until the current design is validated by >> inclusion into upstream source. > > You got exactly the point :-) > To be precise, the effort isn't so huge, but summed with the effort of > maintaining > all in sync with current tree the global effort would be great (and > dumb, imho). >> >> >> Welcome aboard! I suggest that if you'd like to help out with the DIB >> engine (with the goal of getting it included to Wine upstream source), >> that you take a look at the code on bugzilla page #421 and talk to >> Massimo about how you might adapt it for integration into GDI32. >> > There's not too much to adapt.... moving the engine inside gdi32 is > (IMHO) > not complicated at all. More a writing effort than a coding one. > But, *before*, I guess winex11.drv (and any possible driver that does > DIBs internally) > should be patched stripping DIB handling *and* adding some stuffs for > mixed transfers. > Again, not an huge work, for somebody that knows well drivers internals. > It could also be done later, if wished... but logically that would be > the first step. > > Ciao > > Max > > Ok Max then document what you think the effort would be and what is needed to migrate your DIB engine into GDI32 Then We could send it to AJ for approval and go from there. This would be documenting the Delta which should allow AJ to go line item by line item and say yes or no to each or what needs to do. How long would that take you to do Max? Once that is done we would have a defined plan etc and going forward it would be documented. Chris

May 30, 2009

Re: Wineconf 2009 and funding

by Steven Edwards

On Sat, May 30, 2009 at 11:30 AM, Austin English <austinenglish(a)gmail.com> wrote: > Like Steven/Roderick said, we can increase that quite a bit if we > start fundraising early (now). I and Aleksey Bragin will be attending to represent ReactOS. I've asked their developers, users and advocates to contribute a little change to both projects donation links. I think this is a good chance for those of us with relationships to other projects that directly affect or benefit from Wine to contribute something back. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 30, 2009

Re: d3d10: Improve parse_fx10.

by Henri Verbeet

2009/5/30 Stefan Dösinger <stefandoesinger(a)gmx.at>: > > Am 30.05.2009 um 07:24 schrieb Dmitry Timoshkov: > >> "Rico Schüller" <kgbricola(a)web.de> wrote: >> >>> - /* version info? */ >>> - skip_dword_unknown(&ptr, 2); >>> + /* Compiled target version (e.g. fx_4_0=0xfeff1001, >>> fx_4_1=0xfeff1011). */ >>> + read_dword(&ptr, &e->version); >>> + TRACE("Target: %#x\n", e->version); >> >> 0xfeff/0xfffe is a unicode byte order mark, could it serve the same >> purpose here? > > On top of my head I think it is the shader type marker - pixel shader, > vertex shader, geometry shader. I don't have the headers atm, so I can't > check to be sure. > Yes, but for effects. SM1-3 version tokens are 0xfffexxyy/0xffffxxyy for vertex and pixel shaders resp. SM4 version tokens look like 0x000000xy/0x000100xy/0x000200xy for PS/VS/GS. I don't remember what the version token for d3d9 effects looks like, but this is consistent with MS's general scheme for D3D/shader file formats.

May 30, 2009

Re: Wineconf 2009 and funding

by Austin English

On Sat, May 30, 2009 at 10:21 AM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> What is the status of the Wine Party Fund this year, to help with the >> cost of transportation/lodging? I remember quite a bit of it was used >> up last year... >> > > I see no reason to change the practice of providing travel sponsorships. > > I believe the WPF is lower this year than last, so we may be more restrained > in what we can offer, but folks should definitely ask me if they're > interested. Like Steven/Roderick said, we can increase that quite a bit if we start fundraising early (now). -- -Austin

May 30, 2009

Wineconf 2009 and funding

by Jeremy White

> What is the status of the Wine Party Fund this year, to help with the > cost of transportation/lodging? I remember quite a bit of it was used > up last year... > I see no reason to change the practice of providing travel sponsorships. I believe the WPF is lower this year than last, so we may be more restrained in what we can offer, but folks should definitely ask me if they're interested. Cheers, Jeremy

May 30, 2009

Re: d3d10: Improve parse_fx10.

by Stefan Dösinger

Am 30.05.2009 um 07:24 schrieb Dmitry Timoshkov: > "Rico Schüller" <kgbricola(a)web.de> wrote: > >> - /* version info? */ >> - skip_dword_unknown(&ptr, 2); >> + /* Compiled target version (e.g. fx_4_0=0xfeff1001, >> fx_4_1=0xfeff1011). */ >> + read_dword(&ptr, &e->version); >> + TRACE("Target: %#x\n", e->version); > > 0xfeff/0xfffe is a unicode byte order mark, could it serve the same > purpose here? On top of my head I think it is the shader type marker - pixel shader, vertex shader, geometry shader. I don't have the headers atm, so I can't check to be sure.

May 30, 2009

Re: DIB engine

by Massimo Del Fedele

Ben Klein ha scritto: > > You would be surprised at how much of Wine is NOT a hack internally. > Wine doesn't do hacks, Well, well.... there are some, indeed. Of course, it's better not add new ones :-) hence AJ's reluctance to include the current > DIB proposal in Wine (to make it "correct" later will require a lot of > hacking, as Max has objected). Again, my engine isn't a hack. Nor you'll need hacks to embed it on gdi32. Even more, some parts will be simplified because of direct access to internal gdi32 structures, which can't be done (without hacks....) in current implementation. The *only* semi-hack is the direct access of gdifont struct from inside winedib.... it could also be avoided, but with much useless code added. Useless because it will be so once embedded in gdi32. > >> Do we even have an architectural document or guidelines to reference? > > This was also raised on the existing thread. No. This is a problem. > The best we have so far is "DIB engine should be integrated into > GDI32". This is not a problem, because both Max and AJ share this > goal, but if I understand correctly, Max doesn't want to invest the > effort (which is a lot) until the current design is validated by > inclusion into upstream source. You got exactly the point :-) To be precise, the effort isn't so huge, but summed with the effort of maintaining all in sync with current tree the global effort would be great (and dumb, imho). > > > Welcome aboard! I suggest that if you'd like to help out with the DIB > engine (with the goal of getting it included to Wine upstream source), > that you take a look at the code on bugzilla page #421 and talk to > Massimo about how you might adapt it for integration into GDI32. > There's not too much to adapt.... moving the engine inside gdi32 is (IMHO) not complicated at all. More a writing effort than a coding one. But, *before*, I guess winex11.drv (and any possible driver that does DIBs internally) should be patched stripping DIB handling *and* adding some stuffs for mixed transfers. Again, not an huge work, for somebody that knows well drivers internals. It could also be done later, if wished... but logically that would be the first step. Ciao Max

May 30, 2009

Re: d3d10: Improve parse_fx10.

by Dmitry Timoshkov

"Rico Schüller" <kgbricola(a)web.de> wrote: > - /* version info? */ > - skip_dword_unknown(&ptr, 2); > + /* Compiled target version (e.g. fx_4_0=0xfeff1001, fx_4_1=0xfeff1011). */ > + read_dword(&ptr, &e->version); > + TRACE("Target: %#x\n", e->version); 0xfeff/0xfffe is a unicode byte order mark, could it serve the same purpose here? -- Dmitry.

May 30, 2009

Re: DIB engine

by Dmitry Timoshkov

"Stephan Rose" <kermos(a)somrek.net> wrote: > So if anyone can drop a full spec into my lap which outlines everything > I need to write and where (given I adhere to things as I should of course) > I won't have any issues getting that accepted later on, I'd be more than > willing to take on something like this. Anyone needing a full spec can start here: http://msdn.microsoft.com/en-us/library/dd183562(VS.85).aspx If that's not enough just do it the way most of us are doing it every day: 1. write a test case 2. make the test pass under Wine -- Dmitry.

May 30, 2009

Re: DIB engine

by Ben Klein

2009/5/30 chris ahrendt <celticht32(a)yahoo.com>: > > Question on this debate: > > Has AJ documented anywhere what the architectural issues are so they can > be addressed? This did not need a new thread. You should have posted it on the existing one. > I have not seen this in the thread and was just wondering. > If we have them documented then its a relatively easy task to address > each of them. > Yes it may be a hack but you would be surprised at how much of Windows > is a hack internally. You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks, hence AJ's reluctance to include the current DIB proposal in Wine (to make it "correct" later will require a lot of hacking, as Max has objected). > Do we even have an architectural document or guidelines to reference? This was also raised on the existing thread. No. This is a problem. The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source. This leads me to my second point. 2009/5/30Z Stephan Rose <kermos(a)somrek.net>: > My ears perked up when the two words DIB and spec were put together in the same sentence. One frustration I encountered when wanting to contribute to wine a little over two years ago was that nobody seemed to be able to say "Hey, this is what we are missing/need, here are the specs, go implement". Essentially, that's how I work and how I work well. Trying to fix random bugs in random applications in a codebase completely unfamiliar to me seemed to be rather futile so at that point in time I abandoned those efforts and just stuck to using wine. =P > > So that said, I've got a decent amount of experiences dealing with graphics, including full 24/32-bit color on embedded devices. Considering the environment, performance has always been a priority as well. Plus, I also really like working with graphics related code. So from where I'm standing right now, this seems to be right in my neighbourhood. > > So if anyone can drop a full spec into my lap which outlines everything I need to write and where (given I adhere to things as I should of course) I won't have any issues getting that accepted later on, I'd be more than willing to take on something like this. Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32.

May 30, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Dan Kegel

On Fri, May 29, 2009 at 10:51 AM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: >>> Why do we have versions on Mac OS X? How about we combine them all? >> >>It can make a big difference in the bug. The X.org version in OS X >>(partially?) depends on what OS X version you have. ... > > As far as OS/2 goes, it is still a viable operating system, but I think, for Wine purposes, it should be dropped as an available OS for bugzilla and for the AppDB. OK. Last time we looked at this, their bodies hadn't quite decomposed enough, but now they're most sincerely dead. I've simplified our bug OS and System fields accordingly. Of MacOSX, I removed 10.0 and 10.1. There were some real 10.2 bugs, so it's probably not appropriate to remove that one (yet...). - Dan

May 30, 2009

Re: DIB engine

by chris ahrendt

On 05/29/2009 12:28 PM, James Mckenzie wrote: >> As was said in the other thread, just designing it alone would take a >> few months work. AJ is really busy with other things, and a few months >> work is both a lot of money and a lot of wasted productivity. No one >> is stepping up to sponsor the work, so it's a bit hard for him to take >> that on. >> > Who is asking AJ to do all of the work. Huw Davies and Max have worked out what is needed to get this into Wine. All we need is guidance on what is acceptable and how we should proceed. This seems to be a serious shortcoming on AJs part. Without this, any further work would be futile and could end up being very frustrating. I've seen this from Huw and it is starting to come from Max. AJ needs to get some time together and write up what is and is not acceptable as far as code style, fashion and what he expects out of the development efforts for the DIB engine. Making a statement > after months of work is IHMO very unacceptable. > > Also, I don't see this as circular, but the 'snake' of getting AJ to accept code into the codebase is. > > Very respectfully submitted, > > James McKenzie > > > > Agreed James, this is the exact point I am getting at I guess... what exactly is acceptable and what is not... It seems we have a working solution for DIB. I do not think that it would take that long for AJ to sit down and say here.. this is what I want or this is what is acceptable then its up to the development people to come back and say ok here is our solution and then rectify the delta's in between. If Huw and Max have a solution then what is the delta? Chris

May 29, 2009

Re: Announcing WineConf 2009

by Austin English

On Fri, May 29, 2009 at 4:26 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Fri, May 29, 2009 at 5:17 PM, Austin English <austinenglish(a)gmail.com> wrote: >> What is the status of the Wine Party Fund this year, to help with the >> cost of transportation/lodging? I remember quite a bit of it was used >> up last year... > > This also provides a good time for us to publicly seek donations. On a related note, I noticed when installing TortiseSVN on windows, that the installer has a donation button. Well, two actually, one with installing files on the progress screen, and one at the final 'finish' screen, asking for a donation. When you click it, it goes to http://tortoisesvn.tigris.org/donate.html. So, two things: A) We really need a donation page. Currently, the donate button on http://www.winehq.org redirects you to paypal, without sending you to a WineHQ page first explaining what the donation is for, saying thanks, etc. It's a bit hard/tacky to send a donation request out if we don't have a page to send them to, other than paypal. B) We could add a button to winecfg for donating (under the 'Name'/'Company' fields in the 'About' tab). It's unobtrusive, non-invasive, and gives quite a bit of exposure (curious users check out all the tabs and would see it). The donate tab may be a bit controversial, and I'm not proposing putting it in without gathering some opinions first. But I do think it's a really neat idea. There are often times I want to donate to a project, but I'm lazy and don't want to search through the site to find it. A button making it easier for me to do so => $ in their pocket. -- -Austin

May 29, 2009

Re: Announcing WineConf 2009

by Roderick Colenbrander

On Fri, May 29, 2009 at 11:26 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Fri, May 29, 2009 at 5:17 PM, Austin English <austinenglish(a)gmail.com> wrote: >> What is the status of the Wine Party Fund this year, to help with the >> cost of transportation/lodging? I remember quite a bit of it was used >> up last year... > > This also provides a good time for us to publicly seek donations. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > > Yep and we might also want donations for some other things e.g. DIB engine and other things (it shouldn't bite with CW). Further remember as of Wineconf 2008 it is not Wine Party Fund but Wine Development Fund but it was discussed on saturday morning .... ;) Roderick

May 29, 2009

Re: Announcing WineConf 2009

by Steven Edwards

On Fri, May 29, 2009 at 5:17 PM, Austin English <austinenglish(a)gmail.com> wrote: > What is the status of the Wine Party Fund this year, to help with the > cost of transportation/lodging? I remember quite a bit of it was used > up last year... This also provides a good time for us to publicly seek donations. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 29, 2009

Re: Announcing WineConf 2009

by Austin English

On Fri, May 29, 2009 at 2:52 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > Dear Wine developers, > > You may recall that I volunteered to help host WineConf in the Netherlands > in 2007 when, after a vote, an offer by Dan Kegel to host at Google's offices > in Zurich won the bid. > > Last year WineConf went across the pond to Minnesota, so it seems natural > that this year's WineConf will be hosted in the country with the highest > number of Wine developers per capita ;-) > > At Twente University Campus to be precise, near the city of Enschede: > http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=1047705954276368339… > > From November 6-8 (Friday to Sunday). > > I chose this place because of its good facilities and relatively low > costs; we want to make the conference accessible for as many developers > as possible. > > Directions, agenda, etc. will be made available on this page: > > http://wiki.winehq.org/WineConf > > Please e-mail me at wineconf(a)meelstraat.net if you intend to come, so we > can make a better estimation of the number of attendees. > > See you there! > > -Hans What is the status of the Wine Party Fund this year, to help with the cost of transportation/lodging? I remember quite a bit of it was used up last year... -- -Austin

May 29, 2009

Re: DIB engine

by Stephan Rose

>>As was said in the other thread, just designing it alone would take a >>few months work. AJ is really busy with other things, and a few months >>work is both a lot of money and a lot of wasted productivity. No one >>is stepping up to sponsor the work, so it's a bit hard for him to take >>that on. > >Who is asking AJ to do all of the work. Huw Davies and Max have worked out >what is needed to get this into Wine. All we need is guidance on what is >acceptable and how we should proceed. This seems to be a serious shortcoming >on AJs part. Without this, any further work would be futile and could end up >being very frustrating. I've seen this from Huw and it is starting to come >from Max. AJ needs to get some time together and write up what is and is not >acceptable as far as code style, fashion and what he expects out of the >development efforts for the DIB engine. Making a statement >after months of work is IHMO very unacceptable. > >Also, I don't see this as circular, but the 'snake' of getting AJ to accept >code into the codebase is. This is where I figured I'd wake up and chime in a bit. None of you all know me I suppose but I've been primarily just listening in on this list for the better part of two years now. :) My ears perked up when the two words DIB and spec were put together in the same sentence. One frustration I encountered when wanting to contribute to wine a little over two years ago was that nobody seemed to be able to say "Hey, this is what we are missing/need, here are the specs, go implement". Essentially, that's how I work and how I work well. Trying to fix random bugs in random applications in a codebase completely unfamiliar to me seemed to be rather futile so at that point in time I abandoned those efforts and just stuck to using wine. =P So that said, I've got a decent amount of experiences dealing with graphics, including full 24/32-bit color on embedded devices. Considering the environment, performance has always been a priority as well. Plus, I also really like working with graphics related code. So from where I'm standing right now, this seems to be right in my neighbourhood. So if anyone can drop a full spec into my lap which outlines everything I need to write and where (given I adhere to things as I should of course) I won't have any issues getting that accepted later on, I'd be more than willing to take on something like this. Thanks, Stephan

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Ken Thomases

On May 29, 2009, at 12:18 PM, Austin English wrote: > On Fri, May 29, 2009 at 12:14 PM, Dmitry Timoshkov > <dmitry(a)codeweavers.com> wrote: >> "Austin English" <austinenglish(a)gmail.com> wrote: >> >>>> Why do we have versions on Mac OS X? How about we combine them all? >>> >>> It can make a big difference in the bug. The X.org version in OS X >>> (partially?) depends on what OS X version you have. Some bugs will >>> only show up in Tiger, because Leopard has them fixed on Apple's >>> end. >>> (Someone correct me if I'm wrong here, this is based off of what >>> I've >>> seen on wine-users). >> >> By that logic we neeed to have all versions of Ubuntu, Fedora, etc. >> listed as well. > > I'd say the analogy is closer to having Linux 2.4/2.6, but I get > your point. > > I'm fine with combining those. One big difference is that upgrading from Tiger to Leopard costs money, unlike upgrading Linux. So, it's not as simple to just tell a user to upgrade to fix their problem. (I don't interact with Bugzilla much, so I'm not weighing in on what suits the needs of bug wranglers. Just raising a point.) -Ken

May 29, 2009

Re: DIB engine

by Massimo Del Fedele

James Mckenzie ha scritto: > Luke: >> Heh, I wonder if someone should approach Autodesk and say, "Give us >> sponsorship and we'll get Autocad running on Linux" they surely have >> deep pockets :) >> > If Autodesk were interested in making AutoCad work with Linux, they would make a native version, not try to get it working with Wine. Sorry, but them's the facts. Well, not exactly, I'm afraid. M$ did all possible (and even all almost impossible) to prevent simple porting of windows apps to other OS. DotNet is a good example of useless stuff, directx is another example. IMHO any app written using one of both of them will need an huge effort to port and an even greater effort to maintain on both platforms. Writing Autocad using a portable toolkit isn't an option, as most windows users (I guess 90% of autocad users, even if wi'd have a native version...) *want* to have their app looking as a native one. The only feasible stuff they could do is an effort to build it with winelib. Or, of course, help wine to make Autocad working perfectly on it. But I guess for them it isn't worth the money. Max

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by James Mckenzie

> >> Why do we have versions on Mac OS X? How about we combine them all? > >It can make a big difference in the bug. The X.org version in OS X >(partially?) depends on what OS X version you have. Some bugs will >only show up in Tiger, because Leopard has them fixed on Apple's end. >(Someone correct me if I'm wrong here, this is based off of what I've >seen on wine-users). > Very much correct. MacOSX 10.5.7 with XQuartz 2.3.3 or higher correctly utilize all OpenGL features present in Wine. MacOSX 10.4.x or MacOSX 10.5.6 or MacOSX 10.5.7 without XQuartz 2.3.3 applied will not. Since I am running MacOSX 10.5.7 with XQuartz 2.3.3.2 applied, I do not know the status of backporting the fixes to the 10.4 (Tiger) baseline or even if it is possible. As far as OS/2 goes, it is still a viable operating system, but I think, for Wine purposes, it should be dropped as an available OS for bugzilla and for the AppDB. James McKenzie

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Austin English

On Fri, May 29, 2009 at 12:14 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Austin English" <austinenglish(a)gmail.com> wrote: > >>> Why do we have versions on Mac OS X? How about we combine them all? >> >> It can make a big difference in the bug. The X.org version in OS X >> (partially?) depends on what OS X version you have. Some bugs will >> only show up in Tiger, because Leopard has them fixed on Apple's end. >> (Someone correct me if I'm wrong here, this is based off of what I've >> seen on wine-users). > > By that logic we neeed to have all versions of Ubuntu, Fedora, etc. > listed as well. I'd say the analogy is closer to having Linux 2.4/2.6, but I get your point. I'm fine with combining those. -- -Austin

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Dmitry Timoshkov

"Austin English" <austinenglish(a)gmail.com> wrote: >> Why do we have versions on Mac OS X? How about we combine them all? > > It can make a big difference in the bug. The X.org version in OS X > (partially?) depends on what OS X version you have. Some bugs will > only show up in Tiger, because Leopard has them fixed on Apple's end. > (Someone correct me if I'm wrong here, this is based off of what I've > seen on wine-users). By that logic we neeed to have all versions of Ubuntu, Fedora, etc. listed as well. -- Dmitry.

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Austin English

On Fri, May 29, 2009 at 12:02 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Fri, May 29, 2009 at 9:58 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >>> I don't suppose you've changed your mind on also removing the obsolete >>> OS's (BSDI, AIX, IRIX, HP-UX, SunOS, OS/2, Mac OS X < 10.3)? >> >> Did he say he wasn't for it? I didn't catch that. Dan, here's a vote >> for removing those. I can't comment on all of them, but SunOS has >> been obsolete for a decade, OS/2 nearly as long. > > He's referring to an old discussion we had. I'm ok with deleting > any that have zero valid instances in the bug tracker and are obsolete. > All the SunOS instances should really be Solaris, I think. Yes, they should be. They're all mine, I've moved them. > So IRIX, SunOS, and OS/2 can go now. We do have one (abandoned > but recent) real bug against HP-UX and HP, so maybe it's not quite > time to delete those (but we should rename HP as HP-PA to keep > people with HP PCs from choosing it). If it's worth keeping an extra platform/OS for one bug, I suppose. Could simply set it to 'other'. > Why do we have versions on Mac OS X? How about we combine them all? It can make a big difference in the bug. The X.org version in OS X (partially?) depends on what OS X version you have. Some bugs will only show up in Tiger, because Leopard has them fixed on Apple's end. (Someone correct me if I'm wrong here, this is based off of what I've seen on wine-users). -- -Austin

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Dan Kegel

On Fri, May 29, 2009 at 9:58 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >> I don't suppose you've changed your mind on also removing the obsolete >> OS's (BSDI, AIX, IRIX, HP-UX, SunOS, OS/2, Mac OS X < 10.3)? > > Did he say he wasn't for it? I didn't catch that. Dan, here's a vote > for removing those. I can't comment on all of them, but SunOS has > been obsolete for a decade, OS/2 nearly as long. He's referring to an old discussion we had. I'm ok with deleting any that have zero valid instances in the bug tracker and are obsolete. All the SunOS instances should really be Solaris, I think. So IRIX, SunOS, and OS/2 can go now. We do have one (abandoned but recent) real bug against HP-UX and HP, so maybe it's not quite time to delete those (but we should rename HP as HP-PA to keep people with HP PCs from choosing it). Why do we have versions on Mac OS X? How about we combine them all? - Dan

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Austin English

On Fri, May 29, 2009 at 11:58 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >> I don't suppose you've changed your mind on also removing the obsolete >> OS's (BSDI, AIX, IRIX, HP-UX, SunOS, OS/2, Mac OS X < 10.3)? > > Did he say he wasn't for it? I didn't catch that. Dan, here's a vote > for removing those. I can't comment on all of them, but SunOS has > been obsolete for a decade, OS/2 nearly as long. It was in a thread a few months ago: http://www.winehq.org/pipermail/wine-devel/2008-November/070494.html He removed several, but those few I mentioned are still there. -- -Austin

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Juan Lang

> I don't suppose you've changed your mind on also removing the obsolete > OS's (BSDI, AIX, IRIX, HP-UX, SunOS, OS/2, Mac OS X < 10.3)? Did he say he wasn't for it? I didn't catch that. Dan, here's a vote for removing those. I can't comment on all of them, but SunOS has been obsolete for a decade, OS/2 nearly as long. --Juan

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Austin English

On Fri, May 29, 2009 at 11:43 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >> The only use of these platforms was three mistaken >> bug reports that probably wanted PC. I don't see >> any reason to keep these old system types around >> any more. >> OK to remove? >> (Suggested in http://bugs.winehq.org/show_bug.cgi?id=13363 ) > > Please. > --Juan I don't suppose you've changed your mind on also removing the obsolete OS's (BSDI, AIX, IRIX, HP-UX, SunOS, OS/2, Mac OS X < 10.3)? -- -Austin

May 29, 2009

Re: Time to remove obsolete platforms HP, SGI, and DEC?

by Juan Lang

> The only use of these platforms was three mistaken > bug reports that probably wanted PC. I don't see > any reason to keep these old system types around > any more. > OK to remove? > (Suggested in http://bugs.winehq.org/show_bug.cgi?id=13363 ) Please. --Juan

May 29, 2009

Time to remove obsolete platforms HP, SGI, and DEC?

by Dan Kegel

The only use of these platforms was three mistaken bug reports that probably wanted PC. I don't see any reason to keep these old system types around any more. OK to remove? (Suggested in http://bugs.winehq.org/show_bug.cgi?id=13363 )

May 29, 2009

Re: DIB engine

by James Mckenzie

Luke: > >Heh, I wonder if someone should approach Autodesk and say, "Give us >sponsorship and we'll get Autocad running on Linux" they surely have >deep pockets :) > If Autodesk were interested in making AutoCad work with Linux, they would make a native version, not try to get it working with Wine. Sorry, but them's the facts. Now, if you were to speak up with your wallet and donate to the effort, that is a vastly different story. Sadly, we are on our own to get AutoCad fully working with Wine. I don't expect any assistance from AutoDesk nor any of the major Linux players. James McKenzie

May 29, 2009

Re: DIB engine

by James Mckenzie

>As was said in the other thread, just designing it alone would take a >few months work. AJ is really busy with other things, and a few months >work is both a lot of money and a lot of wasted productivity. No one >is stepping up to sponsor the work, so it's a bit hard for him to take >that on. Who is asking AJ to do all of the work. Huw Davies and Max have worked out what is needed to get this into Wine. All we need is guidance on what is acceptable and how we should proceed. This seems to be a serious shortcoming on AJs part. Without this, any further work would be futile and could end up being very frustrating. I've seen this from Huw and it is starting to come from Max. AJ needs to get some time together and write up what is and is not acceptable as far as code style, fashion and what he expects out of the development efforts for the DIB engine. Making a statement after months of work is IHMO very unacceptable. Also, I don't see this as circular, but the 'snake' of getting AJ to accept code into the codebase is. Very respectfully submitted, James McKenzie

May 29, 2009

Re: DIB engine

by Luke Benstead

2009/5/29 Austin English <austinenglish(a)gmail.com>: > On Fri, May 29, 2009 at 10:50 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >> Right Austin, >> I have... thats why I asked the question why not sit down and say >> here is what we want from the DIB engine here is the Spec do this .. >> I have seen the here is what I don't like. But nothing showing what >> exactly is needed. This would be the first step in resolving this >> circular argument / discussion which is what I am trying to >> facilitate =D. Until that is done all we can do is have this same >> circular argument / discussion =D > > As was said in the other thread, just designing it alone would take a > few months work. AJ is really busy with other things, and a few months > work is both a lot of money and a lot of wasted productivity. No one > is stepping up to sponsor the work, so it's a bit hard for him to take > that on. > > -- > -Austin > > > Heh, I wonder if someone should approach Autodesk and say, "Give us sponsorship and we'll get Autocad running on Linux" they surely have deep pockets :) Luke. P.S. Must learn to reply to all, sorry Austin

May 29, 2009

Re: DIB engine

by Austin English

On Fri, May 29, 2009 at 10:50 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: > Right Austin, > I have... thats why I asked the question why not sit down and say > here is what we want from the DIB engine here is the Spec do this .. > I have seen the here is what I don't like. But nothing showing what > exactly is needed. This would be the first step in resolving this > circular argument / discussion which is what I am trying to > facilitate =D. Until that is done all we can do is have this same > circular argument / discussion =D As was said in the other thread, just designing it alone would take a few months work. AJ is really busy with other things, and a few months work is both a lot of money and a lot of wasted productivity. No one is stepping up to sponsor the work, so it's a bit hard for him to take that on. -- -Austin

May 29, 2009

Re: DIB engine

by chris ahrendt

On 05/29/2009 11:14 AM, Austin English wrote: > On Fri, May 29, 2009 at 10:10 AM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> Question on this debate: >> >> Has AJ documented anywhere what the architectural issues are so they can >> be addressed? >> I have not seen this in the thread and was just wondering. >> If we have them documented then its a relatively easy task to address >> each of them. >> Yes it may be a hack but you would be surprised at how much of Windows >> is a hack internally. >> >> Do we even have an architectural document or guidelines to reference? >> > If you read the entire thread, you'll see that the DIB design is not a > puzzle that can be carved out and dropped in. The DIB engine must be > designed from scratch. Designing the DIB architecture is half of the > work itself, since that involves planning a lot of the code/testing, > etc. > > He pointed out a few things he didn't like about Massimo's design, but > not a full 'here's the spec, do this exactly'. > > For more details, read the full thread and past discussions. > > -- > -Austin > > > Right Austin, I have... thats why I asked the question why not sit down and say here is what we want from the DIB engine here is the Spec do this .. I have seen the here is what I don't like. But nothing showing what exactly is needed. This would be the first step in resolving this circular argument / discussion which is what I am trying to facilitate =D. Until that is done all we can do is have this same circular argument / discussion =D chris

May 29, 2009

Re: DIB engine

by Austin English

On Fri, May 29, 2009 at 10:10 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: > > Question on this debate: > > Has AJ documented anywhere what the architectural issues are so they can > be addressed? > I have not seen this in the thread and was just wondering. > If we have them documented then its a relatively easy task to address > each of them. > Yes it may be a hack but you would be surprised at how much of Windows > is a hack internally. > > Do we even have an architectural document or guidelines to reference? If you read the entire thread, you'll see that the DIB design is not a puzzle that can be carved out and dropped in. The DIB engine must be designed from scratch. Designing the DIB architecture is half of the work itself, since that involves planning a lot of the code/testing, etc. He pointed out a few things he didn't like about Massimo's design, but not a full 'here's the spec, do this exactly'. For more details, read the full thread and past discussions. -- -Austin

May 29, 2009

DIB engine

by chris ahrendt

Question on this debate: Has AJ documented anywhere what the architectural issues are so they can be addressed? I have not seen this in the thread and was just wondering. If we have them documented then its a relatively easy task to address each of them. Yes it may be a hack but you would be surprised at how much of Windows is a hack internally. Do we even have an architectural document or guidelines to reference? Chris

May 29, 2009

Re: PowerPC MacOSX work...

by mghughes＠embarqmail.com

On May 28, 2009, at 01:49 AM, Ben Klein wrote: > So you also know you can't run x86 apps on PPC platforms without > emulation, just like you can't run z80 code on x86 without emulation. > Also, where is this PPC code in Wine exactly? What source file > exactly? Files containing PPC specific related code: tools/relay.c lib/wine/port.c lib/port/interlocked.c dlls/ntdll/signal_powerpc.c server/context_powerpc.c iirc: include/ntdll.h Next contain code Macintosh/MacOSX/Darwin specific PPC/x86 generic dlls/winecoreaudio/* dlls/kernel32/locale.c dlls/ntdll/cdrom.c I am sure there are other files with PPC parts too. > Winelib would be good if you had the source code for your Win32/Win16 > apps and wanted to produce PPC binaries of them. Sounds like that's > not what you're trying to do though. > The particular program I wish to run is close source.

May 29, 2009

Announcing WineConf 2009

by Hans Leidekker

Dear Wine developers, You may recall that I volunteered to help host WineConf in the Netherlands in 2007 when, after a vote, an offer by Dan Kegel to host at Google's offices in Zurich won the bid. Last year WineConf went across the pond to Minnesota, so it seems natural that this year's WineConf will be hosted in the country with the highest number of Wine developers per capita ;-) At Twente University Campus to be precise, near the city of Enschede: http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=1047705954276368339… >From November 6-8 (Friday to Sunday). I chose this place because of its good facilities and relatively low costs; we want to make the conference accessible for as many developers as possible. Directions, agenda, etc. will be made available on this page: http://wiki.winehq.org/WineConf Please e-mail me at wineconf(a)meelstraat.net if you intend to come, so we can make a better estimation of the number of attendees. See you there! -Hans

May 29, 2009

Re: patch wined3d

by James McKenzie

Pavel Prochazka wrote: >static HRESULT WINAPI IWineGDISwapChainImpl_Present(IWineD3DSwapChain *iface, CONST RECT *pSourceRect, CONST RECT *pDestRect, HWND hDestWindowOverride, CONST >RGNDATA *pDirtyRegion, DWORD dwFlags) { > IWineD3DSwapChainImpl *This = (IWineD3DSwapChainImpl *) iface; >- IWineD3DSurfaceImpl *front, *back; >+ IWineD3DSurfaceImpl *front, *back,*hlp1,*hlp2;; You need to keep the same spacing as the remainder of the line. - { - HDC tmp; - tmp = front->hDC; + { Get rid of the trailing whitespace, it is not needed nor necessary. - - tmp = front->resource.allocatedMemory; + Same here. You should go through your additions and make sure that no trailing whitespace exists on any line. Also, you should combine all of your fixes into one patch until it is accepted. Lastly, a description should describe what your patch does: [wine3d] Create swapchains to eliminate problems with backbuffers (bug XXX {there are at least five bugs with backbuffer problems}) Also, provide test cases to prove that your patch actually does something that Windows(TM) does and to show that you did your homework. Again, as one of the people with the backbuffer problem causing FPS slowness, I am very interested in these patches. However, they need to be cleaned up so that we can use them. James McKenzie

May 29, 2009

Re: [PATCH] _Present

by Stefan Dösinger

Am Donnerstag, 28. Mai 2009 13:01:23 schrieb Pavel Prochazka: Don't send patches on top of unapplied patches - just always send the a patch against the current wine git code. Besides that, Henri and I pointed out a few other problems in the first version of the patch. Things won't get better if you just resend the same code without addressing the issues that were pointed out.

May 29, 2009

Re: DIB Engine : passing all tests

by Mike Kaplinskiy

On Thu, May 28, 2009 at 6:58 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Hi Max, > > From what I understand, the problem is not your design. I don't want > to put words in anyone's mouth, but to me it seems you and AJ agree on > the final goal; Alexandre just doesn't want the "intermediary step" in > the master tree (there could be many reasons for this). > As you said, starting the move to gdi32 right now would be a huge > waste of time (in maintenance and more), and prone to hell-knows how > many regressions. You should get the DIB engine uploaded to its own > repo or wine-hacks (http://repo.or.cz/w/wine/hacks.git) > It's also been mentioned, but getting some documentation up and > running on the wiki would be of great help. Maybe the authors of the > previous DIB engine attempts could also give a shot at helping with > that. People will also want (need) to know what they should test, how > to test it, where to give feedback, what's still in the works, ... > > You've done a great job so far, here's hoping it gets sorted :) > > J > > On Thu, May 28, 2009 at 10:46 PM, Steven Edwards <winehacker(a)gmail.com> wrote: >> On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele <max(a)veneto.com> wrote: >>> IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 >>> whithout proper guidelines would be crazy. I mean, I'd never do it :-) >>> The intermediate step was made (among other reasons) to check if the >>> upcoming driver had the chance to be accepted. >>> Moving it *now* inside gdi32 would mean a big loss of time with almost no >>> hopes to see it in mainstream, added to the above effort of keeping it >>> in sync with changing gdi32. >>> OTOH, if winedib would be embedded as-is or with some minor mods, I could >>> od course take the job of moving it stepwise into gdi32. >> >> It seems to me the best course is keep developing it outside of the >> tree until the remaining glitches are resolved and then try to >> resubmit it by moving in to gdi32. At least if Alexandre still wants >> to reject it due to remaining design issues, we have a good enough >> alternative. >> >> Thanks >> -- >> Steven Edwards >> >> "There is one thing stronger than all the armies in the world, and >> that is an idea whose time has come." - Victor Hugo >> >> >> > > > > -- > Jerome Leclanche > > > I completely agree with Jerome, and would like to add that tests of the DIB engine would probably be accepted into the tree. Since Max knows the finer notches of the DIB engine, taking the time to write some tests would seem to be a good idea - both to speed up the future migration and to make sure we're not missing any quirks. It may also help pinpoint certain bugs within the implementation. Mike.

May 28, 2009

Re: DIB Engine : passing all tests

by Jerome Leclanche

Hi Max, >From what I understand, the problem is not your design. I don't want to put words in anyone's mouth, but to me it seems you and AJ agree on the final goal; Alexandre just doesn't want the "intermediary step" in the master tree (there could be many reasons for this). As you said, starting the move to gdi32 right now would be a huge waste of time (in maintenance and more), and prone to hell-knows how many regressions. You should get the DIB engine uploaded to its own repo or wine-hacks (http://repo.or.cz/w/wine/hacks.git) It's also been mentioned, but getting some documentation up and running on the wiki would be of great help. Maybe the authors of the previous DIB engine attempts could also give a shot at helping with that. People will also want (need) to know what they should test, how to test it, where to give feedback, what's still in the works, ... You've done a great job so far, here's hoping it gets sorted :) J On Thu, May 28, 2009 at 10:46 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele <max(a)veneto.com> wrote: >> IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 >> whithout proper guidelines would be crazy. I mean, I'd never do it :-) >> The intermediate step was made (among other reasons) to check if the >> upcoming driver had the chance to be accepted. >> Moving it *now* inside gdi32 would mean a big loss of time with almost no >> hopes to see it in mainstream, added to the above effort of keeping it >> in sync with changing gdi32. >> OTOH, if winedib would be embedded as-is or with some minor mods, I could >> od course take the job of moving it stepwise into gdi32. > > It seems to me the best course is keep developing it outside of the > tree until the remaining glitches are resolved and then try to > resubmit it by moving in to gdi32. At least if Alexandre still wants > to reject it due to remaining design issues, we have a good enough > alternative. > > Thanks > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > > -- Jerome Leclanche

May 28, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Nikolay Sivov

Sergey Khodych wrote: > Nikolay Sivov пишет: > >>> If a band has an empty string, wine allocates a padding space in >>> lpBand->rcCapText that causes an offset in a band. >> It looks like a workaround, if get/set text behaves ok now (no tests >> exist I suppose) then >> the only place to be changed is this rectangle dimensions. >> > Why does wine need to keep an empty string when native realization > doesn't distinguish "" and NULL (according to tests)? If it's indistinguishable at all - invisible for get/set and has no side effect on drawing for example - we don't need to store it of course. That's why I'm asking you about tests. Just add 2 tests as a first patch: - set/get (to prevent regressions here if somebody will try later to adjust rectangle and still store empty strings); it should include both InsertBand and SetBandInfo. - dimension check. And a fix for them as a second patch. Nikolay S.

May 28, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Sergey Khodych

Nikolay Sivov пишет: >> If a band has an empty string, wine allocates a padding space in >> lpBand->rcCapText that causes an offset in a band. > It looks like a workaround, if get/set text behaves ok now (no tests > exist I suppose) then > the only place to be changed is this rectangle dimensions. > Why does wine need to keep an empty string when native realization doesn't distinguish "" and NULL (according to tests)?

May 28, 2009

Re: Changing default severity in Bugzilla to Normal

by John Klehm

>>On Thu, May 28, 2009 at 1:40 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: >>> "It seems the default severity, enhancement, invites people to select a >>> REALLY >>> SEVERE sounding level instead. I suggest changing the default severity to >>> normal in the hopes of cutting down on the yelling." >>> http://bugs.winehq.org/show_bug.cgi?id=13363 >>> Makes sense to me.

May 28, 2009

Re: DIB Engine : passing all tests

by Steven Edwards

On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele <max(a)veneto.com> wrote: > IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 > whithout proper guidelines would be crazy. I mean, I'd never do it :-) > The intermediate step was made (among other reasons) to check if the > upcoming driver had the chance to be accepted. > Moving it *now* inside gdi32 would mean a big loss of time with almost no > hopes to see it in mainstream, added to the above effort of keeping it > in sync with changing gdi32. > OTOH, if winedib would be embedded as-is or with some minor mods, I could > od course take the job of moving it stepwise into gdi32. It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 28, 2009

Need a temporary list moderator

by Luke Bratch

Hi all In a couple of weeks I'm going to be travelling around India for about a month, from 14th June - 17th July, so I'll need somebody to cover list moderation during that period. It's a simple task; you just need to bring up a web page for each list a couple of times per day, and single out any genuine messages that are awaiting approval, discarding the rest. You'll need to do it almost every day for the whole month, otherwise people will start to wonder where their mail is getting to... :) If you are interested, please email me directly. Thanks, Luke.

May 28, 2009

Re: [1/2] comctl32:rebar: Don't store an empty string in REBAR_InsertBandT. (try 2)

by Nikolay Sivov

Sergey Khodych wrote: > From 37cd774e71f8d260d94bd672715b1eab879c4b2d Mon Sep 17 00:00:00 2001 > From: Sergey Khodych <khodych(a)gmail.com> > Date: Thu, 28 May 2009 04:52:45 +0300 > Subject: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT. > > --- > dlls/comctl32/rebar.c | 12 ++++++++---- > dlls/comctl32/tests/rebar.c | 9 +++++++++ > 2 files changed, 17 insertions(+), 4 deletions(-) Commented already. You're testing one part and changing another. Add simple get/set text tests first.

May 28, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Nikolay Sivov

Sergey Khodych wrote: > Nikolay Sivov пишет: > >> >> It looks like you need to add a simple test like that: >> - add band with empty string and RBBIM_TEXT mask of course; >> - query band data back with RB_GETBANDINFO and check this lpText field. >> >> If it's really NULL (e.g. your buffer didn't change) instead of empty >> string you should test >> RB_SETBARINFO for the same case. >> > It returns an empty string in both case. So adding a band with NULL text OR empty string always returned empty string to getter? Provide a test case for that please. If it already returns empty when needed there's no point to change storing code. >> What you mean saying extra space? Some offset during drawing or what? >> > > If a band has an empty string, wine allocates a padding space in > lpBand->rcCapText that causes an offset in a band. It looks like a workaround, if get/set text behaves ok now (no tests exist I suppose) then the only place to be changed is this rectangle dimensions.

May 28, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Sergey Khodych

Nikolay Sivov пишет: > > It looks like you need to add a simple test like that: > - add band with empty string and RBBIM_TEXT mask of course; > - query band data back with RB_GETBANDINFO and check this lpText field. > > If it's really NULL (e.g. your buffer didn't change) instead of empty > string you should test > RB_SETBARINFO for the same case. > It returns an empty string in both case. > What you mean saying extra space? Some offset during drawing or what? > If a band has an empty string, wine allocates a padding space in lpBand->rcCapText that causes an offset in a band.

May 28, 2009

Re: Changing default severity in Bugzilla to Normal

by James Mckenzie

Austin English wrote about Re: Changing default severity in Bugzilla to Normal > >On Thu, May 28, 2009 at 1:40 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: >> "It seems the default severity, enhancement, invites people to select a >> REALLY >> SEVERE sounding level instead. I suggest changing the default severity to >> normal in the hopes of cutting down on the yelling." >> http://bugs.winehq.org/show_bug.cgi?id=13363 >> >> Any thoughts on this? >> >> >> > >+1 > +1 James McKenzie

May 28, 2009

Re: Changing default severity in Bugzilla to Normal

by Austin English

On Thu, May 28, 2009 at 1:40 PM, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > "It seems the default severity, enhancement, invites people to select a > REALLY > SEVERE sounding level instead. I suggest changing the default severity to > normal in the hopes of cutting down on the yelling." > http://bugs.winehq.org/show_bug.cgi?id=13363 > > Any thoughts on this? > > > +1 -- -Austin

May 28, 2009

Changing default severity in Bugzilla to Normal

by Ken Sharp

"It seems the default severity, enhancement, invites people to select a REALLY SEVERE sounding level instead. I suggest changing the default severity to normal in the hopes of cutting down on the yelling." http://bugs.winehq.org/show_bug.cgi?id=13363 Any thoughts on this?

May 28, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

HI Ben, Ben Klein ha scritto: > Of course, it also makes it more difficult to maintain, with any > change in gdi32 needing to be mirrored in the forked DIB engine, but > that's where git cherry-picking can come in handy :) Done for about 3 monthes, no more time for it :-) > > What I was trying to say with my post was not to rehash old ideas, but > to say "here's where I feel you need to be going". AJ doesn't seem to > like the intermediary driver which forwards non-DIB requests, so in > order to get this into the upstream tree, what needs to be done is an > integration with gdi32, as in replacing the DIB-related methods with > the DIB-engine, instead of doing (what can be seen as a hack) > redirection of selected methods. > > I believe that if the majority of the intermediary design (with the > intermediary driver) has been implemented and is working, it's time to > start thinking of integrating it into gdi32 so that it is suitable for > upstream inclusion. > IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32. Ciao Max

May 28, 2009

Re: [PATCH] _Present

by Francois Gouget

On Thu, 28 May 2009, Pavel Prochazka wrote: > > + IWineD3DSurfaceImpl *front,*hlp1,*hlp2; > + IWineD3DSurfaceImpl back; //must be copy of struct C++ comments are not allowed in Wine. There are a few others further down. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

May 28, 2009

How to fix some oleaut32:vartest tests?

by Paul Vriens

Hi, It looks like I have two boxes (W98 and NT4) that produce test failures every now and then for the mentioned tests: vartest.c:5514: Test failed: VarCat: VT_BSTR concat with VT_DATE returned inncorrect result vartest.c:5530: Test failed: VarCat: VT_DATE concat with VT_BSTR returned inncorrect result It boils down to the result of the VarCat which is either a 2-digit or a 4-digit year but again intermittently. If I run the same test right after each other I get either 0, 1 or 2 failures. The only way I can see fixing this is by having a broken() with the 2 digit date for sz12_date and date_sz12. I mean having an explicit broken() is better then a broken() for anything but the correct result. Anyone? (I'll start with sending a patch for that spelling mistake in the output ;) ). -- Cheers, Paul.

May 28, 2009

Re: winehq.org page importance / website statistics

by André Hentschel

Austin English schrieb: > On Thu, May 28, 2009 at 11:19 AM, Maik Schulz <maik.schulz(a)gmail.com> wrote: >> Does that make it safe to assume that winehq.org should concentrate on users >> and wiki.winehq.org on (potential) developers? If that's the direction then >> it's more clear which content to translate. > > Sounds reasonable. > i think we should focus on users, because developers should be able to read english. they have to correspondend here in english, so i guess they can.

May 28, 2009

Re: winehq.org page importance / website statistics

by Austin English

On Thu, May 28, 2009 at 11:19 AM, Maik Schulz <maik.schulz(a)gmail.com> wrote: > Does that make it safe to assume that winehq.org should concentrate on users > and wiki.winehq.org on (potential) developers? If that's the direction then > it's more clear which content to translate. Sounds reasonable. -- -Austin

May 28, 2009

Re: winehq.org page importance / website statistics

by Maik Schulz

On 28 May 2009, at 17:10, Austin English wrote: > On Thu, May 28, 2009 at 10:06 AM, Maik Schulz > <maik.schulz(a)gmail.com> wrote: >> Hi Paul, >> >> it's a good pointer to start, thanks. >> >> For the other two points: Does anybody have an opinion on the >> importance of >> pages as well as which ones should be moved to the Wiki? > > Please bottom post on wine mailing lists. > > As for your questions, importance is a bit hard to say. Important to > users, or to potential developers? > > For the wiki, a lot of it should be eventually, but some have objected > doing so until the wiki's theme is updated to match WineHQ's. > > -- > -Austin NP. Importance to whom is a good question--who is the target group for winehq.org? Or who benefits most from it? Importance to that latter group is what I'm after. Looking at the webalizer output, the most popular pages are the start page, the download page, the news, the site search, the about page, and the help page (taken from the top 10 URLs). From this I gather that it's mostly users that frequent winehq.org. The latest patch to the developer page actually put the link to the wiki as the topmost with the comment that it typically has more recent information than the web pages. Does that make it safe to assume that winehq.org should concentrate on users and wiki.winehq.org on (potential) developers? If that's the direction then it's more clear which content to translate. Cheers, -Maik

May 28, 2009

valgrind mac now on trunk!

by Dan Kegel

http://blog.mozilla.com/nnethercote/2009/05/28/mac-os-x-now-supported-on-th… So for those of you developing wine on the mac, now you have one fewer excuse not to run your changes through valgrind before sending patches :-)

May 28, 2009

Re: winehq.org page importance / website statistics

by Austin English

On Thu, May 28, 2009 at 10:06 AM, Maik Schulz <maik.schulz(a)gmail.com> wrote: > Hi Paul, > > it's a good pointer to start, thanks. > > For the other two points: Does anybody have an opinion on the importance of > pages as well as which ones should be moved to the Wiki? Please bottom post on wine mailing lists. As for your questions, importance is a bit hard to say. Important to users, or to potential developers? For the wiki, a lot of it should be eventually, but some have objected doing so until the wiki's theme is updated to match WineHQ's. -- -Austin

May 28, 2009

Re: winehq.org page importance / website statistics

by Maik Schulz

Hi Paul, it's a good pointer to start, thanks. For the other two points: Does anybody have an opinion on the importance of pages as well as which ones should be moved to the Wiki? Cheers, -Maik On 28 May 2009, at 10:13, Paul Vriens wrote: > Maik Schulz wrote: >> Hi, >> for translation (to German) purposes I wonder which pages of the >> winehq.org website are most frequented (are there HTTP request >> statistics?) and which are deemed most important so I can focus on >> them in order. >> It would also be interesting to know which pages are going to be >> moved to the Wiki eventually so I don't waste effort translating >> these. >> Everything that is shown on the start page plus some other pages >> are done and I'm looking for direction on where to continue. >> Cheers, >> -Maik > Not sure if this will help you: > > http://www.winehq.org/webalizer/index.html > > -- > Cheers, > > Paul.

May 28, 2009

Re: winebrowser: Fix unicode recognition

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > I put tests for the mixed conditions in test/dde.c quite a while ago: Then it should be obvious where the fix should be added, with removing todo_wine in appropriate places. -- Dmitry.

May 28, 2009

Re: winebrowser: Fix unicode recognition

by Jeff Latimer

May 28, 2009

Problem with async. comm from Wine to a USB->Serial-converter

by Henrik Jacobsson

Hi. I just got myself a USB-GPS (GlobalSat BU-353) and wanted to run SeaClearII, a navigation-program with it. Turns out that Wine got confused when the USB->Serial-driver wasn't acting like a real serial-device though. The app does what it's supposed to do, but Wine consumes 100% of the available CPU. After some googling I found a patch that resolved this issue perfectly, and I'm curious why it never made it into trunk. The patch: http://www.nabble.com/serial-04-04%3A-fix%3A-WaitCommEvent()-does-not-work-… I only managed to apply this patch to 1.1.17. Later releases had changed too much for my non-programmer-brain to cope with.. I would really appreciate if someone in the know could check the patch out and if possible apply it to wine-proper.. Thanks in advance.. /Henrik

May 28, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Emmanuel Maillard

I think Doom use the MIDI Synth not an external MIDI instrument. so no log about MOD_MIDIPORT but eventually MOD_MIDISYNTH (or something like that) Emmanuel Le 26 mai 09 à 02:08, James McKenzie a écrit : > Emmanuel Maillard wrote: >> Does notes play well when playing ? >> Correct duration, correct tempo or other kind of timing issue ? >> >> Have you see fixme about MOD_MIDIPORT in log ? > Emmanuel: > > Pardon my barging into this conversation, but music does not play > correctly with Doom. Not the CD Music, but the background music. I > get > no error messages in the log file either about MOD_MIDIPORT. > > MacOSX 10.5.7 > > James McKenzie >

May 28, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Emmanuel Maillard

Le 25 mai 09 à 20:54, Steve Schow a écrit : > > it seems like what happens is that i select an IAC or virtual midi > port from > some windows host inside Wine and everything looks ok, but no events > are > sent. Nothing. But sometimes it works and sometimes it doesn't. > Once it > is working it works fine. Sometimes I have started it up and it was > not > working, then I forgot that i had set it up and 5-10 minutes later > suddenly > it would start sending the data across. > > Seems like somehow the windows host was not flushing the buffer or > something. I had this problem with Reaper and the latest version of > Reaper > seems to be working ok, so maybe this was a Reaper problem, not wine. How does it work on linux ? Did you take a look to AppDB ? > I didn't see that fixme you mentioned. Where can I find that? I'm > actually using CrossOverGames for this, I was never able to get Wine > to work > with JackOSX. > > > Emmanuel Maillard-3 wrote: >> >> Does notes play well when playing ? >> Correct duration, correct tempo or other kind of timing issue ? >> >> Have you see fixme about MOD_MIDIPORT in log ? >> >> Emmanuel >> >> Le 25 mai 09 à 17:59, Steve Schow a écrit : >> >>> >>> Thanks for responding. I'm just sending midi notes around, no >>> sysex. >>> Sometimes the ports work and sometimes they don't. I may be finding >>> that >>> the problem is more related to Reaper bugs, I'm not sure yet. Seems >>> like it >>> will not work and then sometimes after a few minutes, it will >>> suddenly start >>> working. Seems possibly related to flushing, but I'm not sure. >>> >>> I'm not a wine developer, so I will just note your comments about >>> MIDIClientCreate and keep testing from my end. >>> >>> >>> >>> >>> Emmanuel Maillard-3 wrote: >>>> >>>> Hi, >>>> >>>> Sorry for the late answer. >>>> The MIDI driver is very rudimentary : (by memory) it doesn't handle >>>> SysEx, doesn't handle notification from MIDIServer, >>>> and poorly tested : just testing by reading few MIDI files, and few >>>> In/ >>>> Out tests with 2 virtuals application. >>>> >>>> I think you first need is to add MIDINotifyProc, in >>>> MIDIClientCreate >>>> to track your MIDI setup changes. >>>> >>>> Cheers >>>> Emmanuel >>>> >>>> Le 7 mai 09 à 06:20, Dewdman42 a écrit : >>>> >>>>> >>>>> Does anyone know if Darwine can be fixed to handle virtual midi >>>>> ports >>>>> correctly? They work very sporadically right now. It seems to be >>>>> related >>>>> to getting the ports flushed or initialized or something. When >>>>> there is a >>>>> virtual midi port present (under OSX), Wine seems to see it and >>>>> lists it as >>>>> an available midi port, but I have not been able to consistently >>>>> get >>>>> that >>>>> port to function correctly. Sometimes it does and sometimes it >>>>> doesn't and >>>>> it seems to related to switching it on and off in some fashion >>>>> makes >>>>> it >>>>> work, though I can't seem to find a pattern that will work >>>>> consistently. >>>>> >>>>> All I can figure is that somehow Wine is not handling midi ports >>>>> in >>>>> a way >>>>> that is compatible with OSX virtual midi ports. >>>>> >>>>> Anyone have any experience or knowledge in this area? >>>>> >>>>> Thanks >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… >>>>> Sent from the Wine - Devel mailing list archive at Nabble.com. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… >>> Sent from the Wine - Devel mailing list archive at Nabble.com. >>> >>> >>> >> >> >> >> >> > > -- > View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… > Sent from the Wine - Devel mailing list archive at Nabble.com. > > >

May 28, 2009

Re: winebrowser: Fix unicode recognition

by Dmitry Timoshkov

"André Hentschel" <nerv(a)dawncrow.de> wrote: >> Please add a test case which uses mixed ansi/unicode DDE client/server >> and only then start fixing the code. >> > For winebrowser? Do we test any of our programs? Or for DDE? Quoting above: "mixed ansi/unicode DDE client/server". -- Dmitry.

May 28, 2009

Re: winebrowser: Fix unicode recognition

by André Hentschel

Dmitry Timoshkov schrieb: > "André Hentschel" <nerv(a)dawncrow.de> wrote: > >> This converts the DDE-Callbackfunction to Unicode. >> After days of winebrowser-hacking i turned it down to this clean code. >> It uses the function IsTextUnicode instead of guessing.(IsTextUnicode >> is guessing too, but in a cleaner way) > > Please add a test case which uses mixed ansi/unicode DDE client/server > and only then start fixing the code. > For winebrowser? Do we test any of our programs? Or for DDE? I think it is an important fix. We can have bugs in wine, but not in our programs we serve with it.

May 28, 2009

Re: winehq.org page importance / website statistics

by Paul Vriens

Maik Schulz wrote: > Hi, > > for translation (to German) purposes I wonder which pages of the > winehq.org website are most frequented (are there HTTP request > statistics?) and which are deemed most important so I can focus on them > in order. > > It would also be interesting to know which pages are going to be moved > to the Wiki eventually so I don't waste effort translating these. > > Everything that is shown on the start page plus some other pages are > done and I'm looking for direction on where to continue. > > Cheers, > -Maik > > Not sure if this will help you: http://www.winehq.org/webalizer/index.html -- Cheers, Paul.

May 28, 2009

winehq.org page importance / website statistics

by Maik Schulz

Hi, for translation (to German) purposes I wonder which pages of the winehq.org website are most frequented (are there HTTP request statistics?) and which are deemed most important so I can focus on them in order. It would also be interesting to know which pages are going to be moved to the Wiki eventually so I don't waste effort translating these. Everything that is shown on the start page plus some other pages are done and I'm looking for direction on where to continue. Cheers, -Maik

May 28, 2009

Re: DIB Engine : passing all tests

by Ben Klein

2009/5/27 Massimo Del Fedele <max(a)veneto.com>: > 1) Huw's starting engine *was* a driver's one, and many people told it was > the right way. Worse, it forked driver from inside gdi32, which was awful > to maintain. I can understand AJ preferring a fork of gdi32 to the intermediary driver given what he's said on this thread. He wants DIB to be integrated into gdi32 (which as I pointed out is also the way Windows does it). This is much easier to do if the DIB-enabled gdi32 can be used as a drop-in replacement for regular gdi32. Of course, it also makes it more difficult to maintain, with any change in gdi32 needing to be mirrored in the forked DIB engine, but that's where git cherry-picking can come in handy :) > 2) My engine insertrs itself between gdi32 and the display driver; I begins > to be tired repeating that it's a step through the final design on where > DIB are handled fully inside gdi32. The step is, imho, necessary to split > DIB handling from DDB without having to rewrite at once half of gdi32 + half > of winex11.drv and maybe others. > It is *not* the final step, now it wants to be. It's made so to prepare > the switching in a painless way, *if* accepted. > If not, just prepare to have the sampe problems we had with mshtml > switching on each gecko change. In my case that broke a lot of stuffs. What I was trying to say with my post was not to rehash old ideas, but to say "here's where I feel you need to be going". AJ doesn't seem to like the intermediary driver which forwards non-DIB requests, so in order to get this into the upstream tree, what needs to be done is an integration with gdi32, as in replacing the DIB-related methods with the DIB-engine, instead of doing (what can be seen as a hack) redirection of selected methods. I believe that if the majority of the intermediary design (with the intermediary driver) has been implemented and is working, it's time to start thinking of integrating it into gdi32 so that it is suitable for upstream inclusion.

May 28, 2009

Re: DIB Engine : passing all tests

by Reece Dunn

2009/5/28 John Klehm <xixsimplicityxix(a)gmail.com>: > On Wed, May 27, 2009 at 8:47 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: >> So what say all, shall we try to make coding better and as Max stated, >> fun. Most of the folks here do not support this project for a living >> and we should not restrict this project to those who do. However, it >> appears that a vast majority of the patches are coming from those who >> either are long time Wine 'hackers' or those whose living depends on >> this project's survival. >> > > I'm not sure why it's a strange thing that the people that spend the > most time with wine code have the most patches committed. To try and > make an accusation that the project is restricted to paid peoples is > both false and pointlessly inflammatory. > > If there was a glut of manpower there'd be plenty of time to give full > reviews of every patch. As it is everyone gives the time they can. It also depends where your experience lies. I am predominantly a UI developer, and having spent a long time writing UI code that is where I feel most comfortable working in. That does not mean that I know the behaviour of every Windows control inside and out, just that this is an area I feel capable of working on. I am in awe of what the DirectX developers have done. I doubt I would be able to work in that area. Especially as I don't understand either DirectX or OpenGL. Same goes for the GDI/DIB engine code, the crypto code or a hundred other areas of the Windows API that Wine implements. To work on an area of Wine, you need to have a deep understanding of how the Windows API works. For some areas (such as implementing the different Windows controls), you can do that purely through the Windows API. For other areas, you also need an understanding of how Linux/BSD/Mac/OpenSolaris/others implement that domain. Wine has some very talented developers working on it. The problem comes when you have some functionality (like the DIB engine) that cuts across a large number of areas and requires a very deep understanding of both Windows and Linux/etc to grasp what needs to be done. And yes, that requires a lot of time and effort. - Reece

May 28, 2009

Re: PowerPC MacOSX work...

by Ben Klein

Please bottom-post on wine mailing lists. 2009/5/26 <mghughes(a)embarqmail.com>: > No No No People... Please read the messages before replying. > > I know the difference betweeen my 6502, 6800, Z80, 68k, x86, 7400. I know > Wine is focused on running MSWindows based software on x86 processors. I > also know there exists PowerPC code in the wine project because people were > interested in bridging the gap to running x86 code via emulation... So you also know you can't run x86 apps on PPC platforms without emulation, just like you can't run z80 code on x86 without emulation. Also, where is this PPC code in Wine exactly? What source file exactly? > For the record... I am not looking to run another full out emulation. The > best example of what I have in mind is what Apple did when they moved their > processor base from 68K to PPC. And I am wondering if the same could be > done for Wine. By the looks of things some of the framework to make that > happen are already there in the form of thunk code... Apple used what they > called trampolines iirc. I believe 68k and PPC are architecturally quite similar, along the lines of the 80386 (which has 16bit and 32bit modes). With Windows programs being x86 apps, the translation between the two architectures is very tricky (as has been previously noted on this thread). > I am not sure that WineLib is what I am looking to use as the wine script & > loader seems to achieve much of what I am already looking to do. Winelib would be good if you had the source code for your Win32/Win16 apps and wanted to produce PPC binaries of them. Sounds like that's not what you're trying to do though.

May 28, 2009

Re: PowerPC MacOSX work...

by Gert van den Berg

On Thu, May 28, 2009 at 04:00, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > The question is: Were there any programs written for WindowsNT for the > PPC? I don't know of any, off hand. > A few seem to exist... Probably nothing without a x86 versions though. Compatibility with PowerPC NT applications might at least give a few programs, even if just MS's applications that got bundled with PPC NT, to test with. It would probably not have much (if any) real-world uses, but it might point out portability issues that might affect other architectures, which might have more applications available, such as x86_64 and Itanium.

May 28, 2009

Re: PowerPC MacOSX work...

by Saulius Krasuckas

* On Tue, 26 May 2009, mghughes(a)embarqmail.com wrote: > > Download link did not work... Would have been good to look > at/try/experiment with, but not what I am looking/aiming for. You could probably want to google for Programmer's File Editor v0.07.001 (file pfe0701p.zip), for example this link: [1]. Quoting [2]: | This is the 0.07.001 release of Programmer's File Editor, a | large-capacity multi-file programming oriented editor for Windows 95, | Windows NT 3.51 and 4.0 on Intel and PowerPC platforms, and Windows 3.1x [1] http://128.40.77.181/ccp/web-mirrors/pfe/people/cpaap/pfe/pfe0701p.zip [2] http://www-personal.engin.umd.umich.edu/~nnarasim/courses/ece373/hc11/pfe32…

May 28, 2009

Re: DIB Engine : passing all tests

by John Klehm

On Wed, May 27, 2009 at 8:47 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > So what say all, shall we try to make coding better and as Max stated, > fun. Most of the folks here do not support this project for a living > and we should not restrict this project to those who do. However, it > appears that a vast majority of the patches are coming from those who > either are long time Wine 'hackers' or those whose living depends on > this project's survival. > I'm not sure why it's a strange thing that the people that spend the most time with wine code have the most patches committed. To try and make an accusation that the project is restricted to paid peoples is both false and pointlessly inflammatory. If there was a glut of manpower there'd be plenty of time to give full reviews of every patch. As it is everyone gives the time they can. --John Klehm

May 28, 2009

Re: winebrowser: Fix unicode recognition

by Dmitry Timoshkov

"André Hentschel" <nerv(a)dawncrow.de> wrote: > This converts the DDE-Callbackfunction to Unicode. > After days of winebrowser-hacking i turned it down to this clean code. > It uses the function IsTextUnicode instead of guessing.(IsTextUnicode is guessing too, but in a cleaner way) Please add a test case which uses mixed ansi/unicode DDE client/server and only then start fixing the code. -- Dmitry.

May 28, 2009

Re: PowerPC MacOSX work...

by James McKenzie

mghughes(a)embarqmail.com wrote: > No No No People... Please read the messages before replying. > > I know the difference betweeen my 6502, 6800, Z80, 68k, x86, 7400. I > know Wine is focused on running MSWindows based software on x86 > processors. I also know there exists PowerPC code in the wine project > because people were interested in bridging the gap to running x86 code > via emulation... > > For the record... I am not looking to run another full out > emulation. The best example of what I have in mind is what Apple did > when they moved their processor base from 68K to PPC. And I am > wondering if the same could be done for Wine. By the looks of things > some of the framework to make that happen are already there in the > form of thunk code... Apple used what they called trampolines iirc. The question is: Were there any programs written for WindowsNT for the PPC? I don't know of any, off hand. The real problem is that most, if not all, Windows based programs were written for the X86 platform. The makes the use of a CPU emulator necessary. I know of only on FOSS project that is working on this, and that is the Qemu (?) project. The Darwine project was trying to combine the PPC->X86 emulator with Wine. Again, this project has stopped progress and probably needs help getting restarted. The Darwine project does exist on SourceForge and could be revived with someone displaying interest in getting it running again. I do have PPC Mac here, but I think I messed up the power port on it and thus batteries are not fully charging. I stopped working on another FOSS project because running the test suite takes over a day and I could not trust the power supply to last that long. James McKenzie

May 28, 2009

Re: DIB Engine : passing all tests

by James McKenzie

Massimo Del Fedele wrote: > Alexandre Julliard ha scritto: >> >> The last time I rejected a simple patch from Massimo, he basically said >> that he didn't have time to fix the patch and just dropped it. That >> doesn't encourage me to spend more effort on reviewing his more complex >> stuff. >> > > Hi again :-) > > Well, to be precise those were some patches rejected, one with some > explanation > and others not. > Former was about adding page size support to wineps.drv. I haven't > dropped it, > but you told me that an almost complete rewrite of cups printers > handling was > foreseen and preferred, so I kept it on my tree. I have really not > enough skills > nor time to do such a complex job. My patch was just sending the > missing page size > string to lpr along as printer name, which is by now the only stuff sent. > I can understand, of course, that going through lpr is not a very nice > way. > I'm using the patch for my daily job, it's not dropped. > > Latters were one testcase (which was meant preparing some gdiplus > patches....) which > was rejected because "too long" and "with meaningless comments" and a > couple of > gdiplus functions that were missing (and are still missing) needed by > autocad to > run with builtin gdiplus, rejected because "contains errors" > (possible, but which ?) and > were "a pain to review" (hmmmm....). > BTW, about comments, I'm sorry but my memory is not perfect and I tend > to forget what I did > and why after a couple of monthes, so the reason of maybe > over-commenting all my code :-) I tend to disagree with your self evaluation of 'too many'. There is NO such thing in coding. I've seen code with too little comments and then had to figure out what the heck the coder was trying to do inside the code. Of course, talking to the coder resulted in a "I know what I'm doing" conversation that resulted in no forward movement on a fixable problem that may have resulted in the company's demise. > I must say that the must difficult part of writing my engine was to > try to figure out what > gdi32/winex11 code does, and some comments more woul have been of > great help ! > This is very true. Code should at a minimum point out where the examples can be found. MSDN is very frustrating when it comes to how a piece of code is supposed to work. What I see here is a lack of assistance from those who grade the code. This is what I consider unacceptable and has resulted in the stoppage of fixes being submitted by folks who 'code for food', that is they write code for a living. I evaluate and support programs for a living. Guess what? I don't recommend that folks use Wine on Macs for production level work. It just is not 'there'. Sadly, these same folks want to walk away from using Microsoft Software because, pardon the phrase, it just plain sucks. It is poorly written and full of bugs (and some of those bugs have been there for years.) I appreciate AJs efforts to keep the code base 'clean'. In the process, however, you have to tell folks what to do in order to keep the base clean. That is just plain being nice and is good ettiquitte. Otherwise, all you are doing is attempting to shoo away those who could really help move the project along and fix long standing problems. It does not take more time to state: Your code does not meet Wine standards because it has tabs in it", then to say "You can do better". Adding comments to what a certain chunk of code does is not expensive and it does make troubleshooting code much easier at a later time by a different person. One line comments are best. So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival. James McKenzie

May 28, 2009

Re: AppDB - Incorrect entry

by Austin English

On Wed, May 27, 2009 at 2:01 PM, Danila Sentiabov <dsent.zen(a)gmail.com> wrote: > Hi. I've found incorrect AppDB entry that needs to be merged with another > one. App maintainer could not do that. > Could someone (with admin access to AppDB) help? > > http://appdb.winehq.org/objectManager.php?sClass=version&iId=7641 Done. -- -Austin

May 27, 2009

AppDB - Incorrect entry

by Danila Sentiabov

Hi. I've found incorrect AppDB entry that needs to be merged with another one. App maintainer could not do that. Could someone (with admin access to AppDB) help? http://appdb.winehq.org/objectManager.php?sClass=version&iId=7641 -- Best regards, Danila Sentiabov aka dsent

May 27, 2009