August 2010 - Wine-Devel - list.winehq.org

Re: wined3d: separate driver info from GPU info (try3)

by Henri Verbeet

On 31 August 2010 00:46, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > In the previous version of this patch, no version info was returned > for Windows versions which were not in the table. I verified on > Vista/Win7 what version numbers, gpu names and driver strings are > returned to applications running in 9x/2k/xp compatibility mode. It > appears that by default (perhaps the shim database can override it?) > these applications receive information about the current drivers > instead of fake information. For now I'm returning XP driver info if > no match was found. > > Future patches will add the 9x/Vista/Win7 info. When we reach that > stage and a user uses a Geforce 8800 and winver=win98, it will behave > the same as Windows (I assume XP is the default version number). > No. This will simply break currently working functionality. Regardless, I think it's a design flaw anyway to require separate entries for different Windows versions even though they're using the same driver model.

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > http://source.winehq.org/patches/data/65442 > > According to http://source.winehq.org/patches/ this patch causes a build > error (or maybe a new warning). However here (gcc 4.4) I see no warning > at all. > > Does this patch cause warnings / errors for anyone? > (it would be nice if the patches website could include the build error log<g>). It's an undefined reference, probably you don't have OpenAL so that code doesn't get compiled. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/31/2010 11:20 AM, Dmitry Timoshkov wrote: > Windows uses an older Unicode specification, that's pretty normal that > unicode.org and Windows data differ in some places. There is no need > to change the mapping unless there is an application that depends on it Thanks for your answer. You've done great things on wine for a long time and fixed plenty of bugs (again, thanks) but ... how can you say that (the last sentence) ? I don't want to offense you, I'm no one, and I don't say that just to be mean .. but there won't be any problem until an application rely on it. And that's wine is for : provide an implementation of win32 API, mimic windows behavior (and its bugs). I can't help wine with crypto/gdi/d3d stuff so I'm looking for todo_wine I can solve and I can fix this one. As always, I understood what was wrong and proposed a patch to 1) remove todo_wine (statistically, wine is now more windows-compliant ) 2) correct wine behavior 3) prevent (maybe close) bugs Why do you want me not to fix a potential bug ? Anyway, I'll try to read cpmap.pl and try to understand what I can do with it. I'm open-minded and ready to discuss / understand and change if needed.

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Francois Gouget

http://source.winehq.org/patches/data/65442 According to http://source.winehq.org/patches/ this patch causes a build error (or maybe a new warning). However here (gcc 4.4) I see no warning at all. Does this patch cause warnings / errors for anyone? (it would be nice if the patches website could include the build error log<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Aug. 31, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Henri Verbeet

I think you want these to show up in your editor while writing the code, not after the fact. "set list listchars=tab:»·,trail:·" for vim, but I'm sure any other half-decent editor will have equivalent functionality.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Dmitry Timoshkov

GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > > --- a/libs/wine/c_1361.c > > +++ b/libs/wine/c_1361.c > > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > > uni2cp_low, > > uni2cp_high, > > { > > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > > } > > }; > > > May I ask some guidance to make this [1] patch accepted ? > Tests prove that the values above needs to be modified. > Actually, I don't know if "uni2cp_high" is generated from the Internet > or cpmap.pl (maybe both) > Anyway, I don't understand perl. > > May > http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT > be wrong ? > Or may Windows doesn't fully comply with unicode ? Windows uses an older Unicode specification, that's pretty normal that unicode.org and Windows data differ in some places. There is no need to change the mapping unless there is an application that depends on it. -- Dmitry.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/28/2010 02:12 PM, Alexandre Goujon wrote: > I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!"). > However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified according tests > [...] > diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c > index b424cb1..50d2c47 100644 > --- a/libs/wine/c_1361.c > +++ b/libs/wine/c_1361.c > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > uni2cp_low, > uni2cp_high, > { > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > } > }; > May I ask some guidance to make this [1] patch accepted ? Tests prove that the values above needs to be modified. Actually, I don't know if "uni2cp_high" is generated from the Internet or cpmap.pl (maybe both) Anyway, I don't understand perl. May http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT be wrong ? Or may Windows doesn't fully comply with unicode ? Thanks --- [1] : http://source.winehq.org/patches/data/65550

Aug. 31, 2010

Re: Wine 1.4 plans?

by Tom Wickline

On Tue, Aug 31, 2010 at 9:45 AM, Austin English <austinenglish(a)gmail.com>wrote: > On Mon, Aug 30, 2010 at 4:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > > I suppose we'll hear what the goals for 1.4 are at Wineconf, but > > here's my little wish list: > > > > Bug 6971, the mouse problem affecting many FPS-style games (Alexandre > > thinks it would take a month of his time?) > > Solving Wine's problems with Pulseaudio (bug #10495) > > Mono integration similar to the current Gecko integration (go Vincent!) > > Finishing d3dx9_36 and friends (i.e. getting rid of the need to run > > winetricks to load bits of Direct3D9) > > Excellent continuous build and test services at winehq.org, including > > performance tests (ok, this isn't really a wine feature) > > Move away from using 2D graphics acceleration, as Windows has done > > (this is both a superset and a subset of the DIBEngine idea) (heard > > this from Roderick) > > Arabic/Hebrew/other RTL left languages support is improving, that may > be a good candidate. > > Also, complete msvcr/mvscp and friends would be nice. > Rich Edit bugs and performance fixes would also be a nice, Ive not benchmarked it lately but Native Rich Edit use to be about 80% faster then builtin. Tom > -- > -Austin > > > -- Wine is not a conclusion but a process...

Aug. 31, 2010

Re: Wine 1.4 plans?

by Austin English

On Mon, Aug 30, 2010 at 4:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > I suppose we'll hear what the goals for 1.4 are at Wineconf, but > here's my little wish list: > > Bug 6971, the mouse problem affecting many FPS-style games (Alexandre > thinks it would take a month of his time?) > Solving Wine's problems with Pulseaudio (bug #10495) > Mono integration similar to the current Gecko integration (go Vincent!) > Finishing d3dx9_36 and friends (i.e. getting rid of the need to run > winetricks to load bits of Direct3D9) > Excellent continuous build and test services at winehq.org, including > performance tests (ok, this isn't really a wine feature) > Move away from using 2D graphics acceleration, as Windows has done > (this is both a superset and a subset of the DIBEngine idea) (heard > this from Roderick) Arabic/Hebrew/other RTL left languages support is improving, that may be a good candidate. Also, complete msvcr/mvscp and friends would be nice. -- -Austin

Aug. 30, 2010

Chinese translation of key pages on wiki.winehq.org?

by Dan Kegel

Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. - Dan

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Andrew Eikum

On 08/30/2010 05:44 PM, Octavian Voicu wrote: > 1. You set color.ui to always and you're using less or another pager > that doesn't support color. You don't need to use a pager in git diff. > Normally, if you set color.ui to auto (or true), then color escape > sequences are only enabled when output is a terminal (not a pipe or > file). > > Instead of `git diff | less' just use `git diff'. If you really want > to use less, `git diff | less -r' should work with colors (-r enables > interpreting color escape codes in less). Git automatically invokes a pager, as given by your 'core.pager' setting (see 'man git-config'). It defaults to 'less'. If you're not getting color, check your LESS environment variable. Unset it to use Git's default settings (which should work with color escape sequences), or set it to something like "-R". See 'man less' for more options, obviously. If the above all seems correct, try a different or newer terminal emulator to help diagnose the problem. Andrew

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 9:25 PM, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Does not work for me :crying: I voluntary added trailing space to my file. > Nothing appears in red. I obtain in white and black > testcooperativelevels_normal();ESC[m > ESC[32m+ESC[mESC[32m testcooperativelevels_normal_other_ddraw();ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > releasedirectdraw();ESC[m > > I use kconsole. Maybe it is the problem ?? Something that starts with ESC[ is an escape sequence, it clearly shows that git is coloring the output, but your terminal isn't interpreting this. I also use kconsole (konsole actually, KDE terminal emulator right?). I see two possible causes: 1. You set color.ui to always and you're using less or another pager that doesn't support color. You don't need to use a pager in git diff. Normally, if you set color.ui to auto (or true), then color escape sequences are only enabled when output is a terminal (not a pipe or file). Instead of `git diff | less' just use `git diff'. If you really want to use less, `git diff | less -r' should work with colors (-r enables interpreting color escape codes in less). 2. Your terminal is not properly configured and colors don't work. Do you have colors in other commands, like in ls? Maybe this helps: https://bbs.archlinux.org/viewtopic.php?pid=511623 I have $TERM set to xterm. What distribution are you using? Maybe you can google for an answer on how to configure your terminal emulator to work with colors. Octavian

Aug. 30, 2010

Wine 1.4 plans?

by Dan Kegel

I suppose we'll hear what the goals for 1.4 are at Wineconf, but here's my little wish list: Bug 6971, the mouse problem affecting many FPS-style games (Alexandre thinks it would take a month of his time?) Solving Wine's problems with Pulseaudio (bug #10495) Mono integration similar to the current Gecko integration (go Vincent!) Finishing d3dx9_36 and friends (i.e. getting rid of the need to run winetricks to load bits of Direct3D9) Excellent continuous build and test services at winehq.org, including performance tests (ok, this isn't really a wine feature) Move away from using 2D graphics acceleration, as Windows has done (this is both a superset and a subset of the DIBEngine idea) (heard this from Roderick)

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Juan Lang

> Yeah, I'm not really sure how this is supposed to work. load_mono() > ensures that mono is loaded, so mono_handle should be set if it > succeeds. Unless someone calls CorExitProcess in another thread and > unloads it before we can grab the critical section again. > > Maybe load_mono should return without releasing the critical section, > thus preventing that race? The caller will almost always want to > proceed to create an AppDomain afterwards.. Ah, I see, you really did mean that. No, I don't think leaving the critical section open is the best thing. I expect someone calling CorExitProcess should expect problems if they continue to call mscoree functions after that. --Juan

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Vincent Povirk

> Hi Vincent, > > + EnterCriticalSection(&mono_lib_cs); > + if (!mono_handle) > + { > + ERR("CorExitProcess called on another thread?\n"); > + return -1; > you don't release mono_lib_cs here. Doh, thanks. > Similarly, in patch 3, > STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void > **ppObject) > (snip) > + EnterCriticalSection(&mono_lib_cs); > + if (!mono_handle) > + { > + ERR("CorExitProcess called on another thread?\n"); > + return E_FAIL; > > you don't release mono_lib_cs here, and the error message looks suspicious. > --Juan Yeah, I'm not really sure how this is supposed to work. load_mono() ensures that mono is loaded, so mono_handle should be set if it succeeds. Unless someone calls CorExitProcess in another thread and unloads it before we can grab the critical section again. Maybe load_mono should return without releasing the critical section, thus preventing that race? The caller will almost always want to proceed to create an AppDomain afterwards..

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Juan Lang

Hi Vincent, + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return -1; you don't release mono_lib_cs here. Similarly, in patch 3, STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void **ppObject) (snip) + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return E_FAIL; you don't release mono_lib_cs here, and the error message looks suspicious. --Juan

Aug. 30, 2010

Re: DIB clarification

by Ken Thomases

On Aug 29, 2010, at 8:49 PM, Jeff Cook wrote: > To clarify, it's not about having secret DIB engine code, it's about > saying "I guess we just won't find time to provide useful feedback > until some company sponsors it...", as I saw several times during the > old threads. What Jeremy neglected to say (although he's made this point before) is that Alexandre has, as a matter of contract, _complete_ independence as Wine maintainer. If, hypothetically, Jeremy wanted to and did "order" Alexandre to slow-walk the DIB engine (or anything else), Alexandre could and would simply ignore him. If Jeremy fired Alexandre for refusing such an order, Alexandre would have excellent grounds to sue CodeWeavers into the ground. Not that either of them is so inclined. As far as Alexandre's famed terseness, you're completely mistaken if you imagine he's any less terse or more forthcoming with us CodeWeavers than he is with any other Wine contributor. In public or behind the scenes. It's just his nature. :) Cheers, Ken

Aug. 30, 2010

Re: DIB clarification

by Roderick Colenbrander

On Sun, Aug 29, 2010 at 2:18 PM, Jeff Cook <jeff(a)deserettechnology.com> wrote: > I hate to stir the pot, especially as an unknown in the community, but > I've spent the last few hours reading WINE's history regarding DIB > engines and it is pretty distressing. > > I have seen expressions of frustration from many regarding the > handling of the mostly-functional DIB engine that Massimo wrote. AJ's > terseness on the issue is puzzling. I find it really weird that such a > major and long-standing thing would just be left to languish without > any detailed reasons. Though I do not believe it, you can start to see > why the slashdotter described Codeweavers' corporate agenda as "evil"; > it almost feels like Codeweavers is holding DIB hostage, just waiting > for someone to get fed up and fork over the cash for it. This wouldn't > be a problem of course if it appeared that Alexandre was willing to > work with external developers on the DIB engine, but he has given very > sparse criticism. > > Should we all just accept that Massimo's engine is yet another DIB > engine gone to waste and there is no future hope for it at all? Max's > statements to that effect can be confusing out of context because of > his non-native English, but everything I have seen indicates that he > is totally willing to work on upstream merging if Alexandre is willing > to cooperate. All cases of saying "it won't get merged" etc. by Max > seem to reference AJ's reluctance to provide useful criticism on the > code that gets posted. > > It is not my intention to start another huge flamewar or thread on the > matter. I just want to promote a reliable roadmap and help resolve > this -- it seems like a total shame that there have been multiple DIB > engines written and no parts of any of them were deemed worthy of > inclusion in WINE. Max at least has indicated a desire to modify the > code as necessary if a useful road map or ideation were provided, so > why is it so hard to get the road map? Alexandre is right that the > architecture is a lot of work, but I am not asking for him to write > out a complete spec, and I don't think the community is, either; the > main thing, as far as I can tell, is that the interaction and feedback > on a major step forward for WINE has been minimal. > > People are still reporting major speedups on bug #421 so I don't think > this is a lost cause unworthy of effort as some suggest. > > The most feedback I was able to find from Alexandre was on May 2009's > DIB engine passing all tests thread at > http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 > . Alexandre's single major standing complaints seem to be a lack of > test cases and Massimo not establishing a good record with simple > patches. Are those still valid reasons? > > The complaint regarding driver loading was addressed, but it sounds > like Alexandre wants it in the opposite direction (forwarding calls > from winex11.drv (or whatever driver) to winedib.drv instead of the > other way around). Is that a very serious problem? > > So, if we can, let's get a few points down on what needs to be > modified for DIB to make it into WINE, even as an experimental branch: > > 1) Write more gdi32 and any other relevant test cases to prove that > the DIB engine is generally well-behaved > 2) Reverse the DIB ordering and call winedib.drv only as needed, > instead of passing everything through winedib.drv first. > 3) ? > > Or, in the case that Max's DIB is gone forever and is considered > irreparable, why don't we discuss what's needed for a different DIB > engine? > > 1) Write more gdi32 and any other relevant test cases to prove that > the DIB engine is generally well-behaved > 2) Works well with any wine display driver. (already in Max's code) > 3) Applied and developed cooperatively and incrementally with the WINE community > 4) Easily disabled / non-disruptive (already in Max's code) > 5) ? What else needs to go here? > > Is this accurate? > > Others mentioned that benchmarks that prove the usefulness of a DIB > engine might help. Do those still need to be performed? > > Thanks for reading. > From > Jeff > Let me give my stance on the DIB engine but before I do that lets give a rough summary what the DIB engine is about because not everyone has a good idea what it is, some people think it is something magical. A DIB(Section) is a type of surface you can draw to using GDI calls but you can also directly mess with its bits. On Windows DIB rendering is all done in software ('using the DIB engine'). In Wine we cheat by delegating most of the work to X11. This causes various challenges and some cause performance issues (though various of them are fixable even without a DIB engine). Two of the challenges: - A copy of the DIB exists on the X-server and in system memory and both copies have to be synced. You don't always want to have them in sync (it might cause unneeded x11->sysmem copies). The syncing is done using memory protection tricks. If the system memory copy is not up to date, a segmentation fault is triggered on access to the bits and during that time the DIB is copied back from the X-server. This causes an issue for some bad applications which directly mess with the stack pointer while they are playing with the DIB. - Depth conversion. When the DIB is at a different color depth (lets say it is 8-bit) than the X-server, the DIB is first converted to the depth of the X-server and afterwards it is converted back. Depending on the color depth this can be a heavy operation (various old games like Age of Empires are quite slow due to this). This used to be a big problem but due to XRender work for Wine, the conversion is not needed anymore for 16-bit/24-bit/32-bit DIBSections. It is still an issue for 8-bit and some other depths but for a big part it can be fixed (Alexandre also said it is more correct if a DIB is 8-bit, to just pass it as 8-bit to X). Do we really need a DIB engine? For a part, 'time' has made the need for a DIB engine less important. Systems have become faster, X11 has become faster, XRender has helped and so on. There are applications which can really profit from a DIB engine but some of them can be made happy by improving the current code (e.g. don't perform color conversion and let X11 work at the depth of the DIB). Personally I think the requirements for a DIB engine have changed and if we add one it should be part of a big Wine 2D rendering rewrite. In previous threads about a Wine quartz/cocoa driver, I mentioned that in Vista/Win7 Microsoft drastically changed their 2D engine and I think we should do something similar. The best way to summarize the changes is that their 'DIB engine' takes care of most tasks of the 'DDB engine'. Except for some common BitBlt ROPs, color filling, font rendering and a few other operations (this are the same calls Cairo/Cocoa/XRender supports) EVERYTHING is software rendered. If we would go the Vista/Win7 way, the DIB engine would be something different from the previously proposed ones. We would move most of our rendering to the shared DIB/DDB engine. The few hw accelerated DDB operations could be implemented using OpenGL/XRender or it could even make sense to use Direct3D. The winex11 driver would implement these DDB options, would handle window management and input. Further it would be a lot easier to write a Cocoa driver for Mac. I'm not sure if we will make such drastic changes at all. It would be a huge project (at least 1 year but likely more) of work. Roderick

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by David Adam

Does not work for me :crying: I voluntary added trailing space to my file. Nothing appears in red. I obtain in white and black testcooperativelevels_normal();ESC[m ESC[32m+ESC[mESC[32m testcooperativelevels_normal_other_ddraw();ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m releasedirectdraw();ESC[m I use kconsole. Maybe it is the problem ?? Thanks for the advices A+ David 2010/8/30 Octavian Voicu <octavian.voicu(a)gmail.com> > Try running: > > git config --global color.ui auto > > This will activate colorful output for all git commands (in particular > for `git diff' too). > > Then, when you run `git diff' from a terminal you will see whitespace > errors (eg. trailing whitespace) highlighted with a red background. > > Hope it helps, > Octavian >

Aug. 30, 2010

Re: user32: Make GetWindowPlacement() work for other process windows. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch fixes the problem reported in the bug 12001. > > This version of the patch uses an internal message to fetch window state > from a foreign thread. Another aproach could be to store the window state in > the server, but that would require to introduce another server call for it. I'd be surprised if GetWindowPlacement required the other thread to be running a message loop on Windows... -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: [PATCH 04/12] [Server]: enhanced the console input object so that it doesn't require a wineconsole to be running

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > + if (tcgetattr(fd, &term) < 0) fprintf(stderr, "Couldn't get termios\n"); > + console_input->termios = term; > + term.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN); > + term.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON); Errors need to be handled properly in the server, you can't just print a message and continue as if nothing happened. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: DIB clarification

by James Mckenzie

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >Now that "that waive with $$$" isn't very likely as the cost/benefit >ratio isn't very good. More likely is that Codeweavers will start >working on a Quartz driver and that work will make the DIB engine >"cheaper" to implement. Again, this is my *personal* opinion. > I would like to add my *personal* comment to the above. Both the DIB engine and implementing Auqa/Quartz on Wine are HUGE projects that will take a lot of time. Huw Davis (sp?) and Max put a lot of time into the DIB project and according to Tom Wickline, Max is still working on it (see Tom's message on in this thread for more information.) Emmanual Mallard and others put in a lot of time on the Aqua/Quartz implementation without a full implementation and Emmanual (to my knowledge) stopped working on it almost two years ago. These both *appear* to be interlinked as the DIB engine has to be implemented before full functionality is available for Aqua/Quartz will work (these are not my words and this was posted here in the Wine Development List.) My words of caution were misread by others here. I was going to work on the Quartz project based upon work that I had participated in another FOSS project, but after looking it over very carefully, I decided to set it aside and work on other much smaller, bigger bang for the time, projects. One I have been working on for two years and that work had to be abandoned as the implementation was not correct (thank you AJ for pointing this out in very blunt words.) What to do about these two 'features' missing? Maybe CodeWeavers will pick them up (they may already have.) Maybe someone or a team will take them over. I will move onto fixing bugs and missing features that are 'important' to me and leave the rest to others who have more time and ambition. Thank everyone here for your words of encouragement and I will continue to work on the three functions I would like to see implemented that will make some of the 'fixmes' go away. James McKenzie

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 2:11 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Can someone add this here > http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 Added this to the wiki. Can't find a way to create links to sections within the page though; the ids of the sections are regenerated on each save.

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 2:11 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Hey, that's pretty cool. > > Can someone add this here > http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 > ? > > Thanks for the tip Octavian ! Well, that's what I love about git the most -- the pretty colored output :P Glad I could help.

Aug. 30, 2010

[PATCH v2] winedbg: gdb proxy mode: support qAttached packet

by Paul Bolle

Add support for the qAttached packet. Main benefit is that gdb now will ask if it should detach from the debuggee if it was attached to a debuggee instead of asking whether the debuggee should be killed. (It still will ask whether the debuggee should be killed if it launched the debuggee itself). Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- On Wed, 2009-11-04 at 21:42 +0100, Eric Pouech wrote: > [...] inclusion in gdbctx is preferred (and storage should rather be an > integer rather than a string pointer) programs/winedbg/gdbproxy.c | 25 +++++++++++++++++++++---- 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c index 4f12481..0f5088c 100644 --- a/programs/winedbg/gdbproxy.c +++ b/programs/winedbg/gdbproxy.c @@ -109,6 +109,8 @@ struct gdb_context struct gdb_ctx_Xpoint Xpoints[NUM_XPOINT]; /* Unix environment */ unsigned long wine_segs[3]; /* load addresses of the ELF wine exec segments (text, bss and data) */ + /* attached or launched? */ + int attached; }; static BOOL tgt_process_gdbproxy_read(HANDLE hProcess, const void* addr, @@ -1794,6 +1796,15 @@ static enum packet_return packet_query(struct gdb_context* gdbctx) return packet_done; } break; + case 'A': + /* Since gdb's multiprocess protocol extensions aren't supported, this + * shouldn't be "qAttached:PID", just "qAttached", but check anyway. */ + if (gdbctx->in_packet_len == 8 && strncmp(gdbctx->in_packet, "Attached", 8) == 0) + { + packet_reply(gdbctx, gdbctx->attached ? "1": "0", 1); + return packet_done; + } + break; case 'C': if (gdbctx->in_packet_len == 1) { @@ -2179,6 +2190,7 @@ static int fetch_data(struct gdb_context* gdbctx) #define FLAG_NO_START 1 #define FLAG_WITH_XTERM 2 +#define FLAG_ATTACHED 4 static BOOL gdb_exec(const char* wine_path, unsigned port, unsigned flags) { @@ -2318,6 +2330,7 @@ static BOOL gdb_init_context(struct gdb_context* gdbctx, unsigned flags) gdbctx->in_trap = FALSE; gdbctx->trace = /*GDBPXY_TRC_PACKET | GDBPXY_TRC_COMMAND |*/ GDBPXY_TRC_COMMAND_ERROR | GDBPXY_TRC_COMMAND_FIXME | GDBPXY_TRC_WIN32_EVENT; gdbctx->process = NULL; + gdbctx->attached = (flags & FLAG_ATTACHED) ? 1 : 0; for (i = 0; i < NUM_XPOINT; i++) gdbctx->Xpoints[i].type = -1; for (i = 0; i < sizeof(gdbctx->wine_segs) / sizeof(gdbctx->wine_segs[0]); i++) @@ -2350,6 +2363,7 @@ static int gdb_remote(unsigned flags) struct pollfd pollfd; struct gdb_context gdbctx; BOOL doLoop; + BOOL kill; for (doLoop = gdb_init_context(&gdbctx, flags); doLoop;) { @@ -2365,8 +2379,8 @@ static int gdb_remote(unsigned flags) { if (gdbctx.trace & GDBPXY_TRC_LOWLEVEL) fprintf(stderr, "Gdb hung up\n"); - /* kill also debuggee process - questionnable - */ - detach_debuggee(&gdbctx, TRUE); + kill = (flags & FLAG_ATTACHED) ? FALSE : TRUE; + detach_debuggee(&gdbctx, kill); doLoop = FALSE; break; } @@ -2412,8 +2426,11 @@ int gdb_main(int argc, char* argv[]) } return -1; } - if (dbg_active_attach(argc, argv) == start_ok || - dbg_active_launch(argc, argv) == start_ok) + if (dbg_active_attach(argc, argv) == start_ok) { + gdb_flags |= FLAG_ATTACHED; + return gdb_remote(gdb_flags); + } + else if (dbg_active_launch(argc, argv) == start_ok) return gdb_remote(gdb_flags); #else fprintf(stderr, "GdbProxy mode not supported on this platform\n"); -- 1.7.2.1

Aug. 30, 2010