Re: cmd: mkdir should complain if directory already exists
On Sun, Jul 24, 2011 at 20:58, Dan Kegel wrote:
> Fixes bug 27383.
There's trailing whitespace on the line preceding "if
(!create_full_path(param1)) {"
Seems ok otherwise
Re: [PATCH 1/4] server, ntdll: get rid of the blocking parameter for ioctls. blockingness depends on the overlapped flag for
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12776 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12778 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: [PATCH 2/4] kernel32, ntdll, server: implement permission checks for named pipes
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12777 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/22/2011 08:35 AM, Andrew Eikum wrote: This is really crude, but does seem to work. I tested it correct with just ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0. This lets us attempt to load the OSS driver, and if that fails, then try the ALSA driver. Automatic driver selection! You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry. The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem. Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for. Vitaliy.
Re: po: Use non-breaking spaces where required by the French typography rules.
2011/7/23 Francois Gouget : > > Except where they may be sent to a command line terminal. > --- > > I did some tests and non-breaking spaces don't seem to cause any issue > in the GUI. Did you use thin/normal non-breaking spaces? Keep in mind that the space "width" and breakability rules change slightly between e.g. France and French-speaking Canada, and that some (most?) translation tools don't allow you to easily view/enter those characters. TBH I'm not quite sure it's worth the trouble ATM Frédéric
Re: Statur of DIB Engine
Il 24/07/2011 19:32, James McKenzie ha scritto: On 7/24/11 10:14 AM, Massimo Del Fedele wrote: Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Max: It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work. It would give you a good start if Huw decides that your code is better than his! James Hi James, I guess that would be almost impossible to rebase my code there... For the few I've seen, the approach taken by Huw is too different from mine to have both coexistent, and the infrastructure changes would make the porting quite complicated and, which is worse, too dependent on code base changes to be maintainable by me. The only stuff that could be done would be to submit patches to enhance current graphics primitives but I guess Huw has already something in mind, and I've got too few spare time :-) Again, for what (very few indeed) I've understood from patches titles, some low-level primitives were exported from winex11 - gdi32 drivers, a stuff that was told me "impossible" when I developed my engine and that will make easy to solve the biggest problem remaining on it, the mixed DIB-DDB conversions in an efficient way. So, I'll wait to see what happens to Huw engine. A pity because latest progress in wine solved many other problems unrelated to DIB. Autocad users can just hope that fonts primitives will be embedded soon :-) Ciao Max
Re: Statur of DIB Engine
On 7/24/11 10:14 AM, Massimo Del Fedele wrote: Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Max: It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work. It would give you a good start if Huw decides that your code is better than his! James
Re: Statur of DIB Engine
Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Thank you for your answer waiting for better times, so :-) Max
Re: Statur of DIB Engine
On Sun, Jul 24, 2011 at 4:11 PM, Massimo Del Fedele wrote: > Having seen many patches related to DIB engine lately, I built latest > sources and tried it No speed enhancements on AutoCAD, my test app. > So, I wonder if the engine is already working, at least partially, or not. > If yes, there's some switch/environment variable to enable it ? Hello, Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better. Most of the work so far was at an architectural level -- creating the infrastructure to support the incremental development of the DIB engine (see dlls/gdi32/dibdrv/). The new DIB engine is enabled by default, and is activated automatically (pushed onto the driver stack) if you pass a DIB to SelectObject. If the DIB engine doesn't implement some functions, they are forwarded to the next driver on the stack. If some features are not supported (eg. specific pixel formats; pen, or brush styles), it again falls back to the next driver on the stack each time those features need to be used (eg. drawing a line when current pen is not supported). Current status is: - most pixel formats are supported, if not all (1bpp is a bit special and still has some issues though); - most pens are implemented (except geometric pens, or pens with width greater than 1); - brush support looks pretty much complete; - most graphics primitives are NOT implemented yet. In fact, the only primitives that are currently implemented are LineTo, Rectangle, PaintRgn, and PatBlt (see [1]), the minimum to test that pens and brushes are working properly; no blits; no polygons, nor other weird shapes; no font rendering; not even get/set pixel. That's probably why Autocad doesn't show any improvements yet. On the other hand, the tricky architectural bits are mostly done, so I'm guessing visible speed improvements are not too far off. Octavian [1] http://source.winehq.org/git/wine.git/blob/8c850a82d440786ca4f83e5e061d6b3d323f5161:/dlls/gdi32/dibdrv/dc.c#l434
Statur of DIB Engine
Having seen many patches related to DIB engine lately, I built latest sources and tried it No speed enhancements on AutoCAD, my test app. So, I wonder if the engine is already working, at least partially, or not. If yes, there's some switch/environment variable to enable it ? Sorry for asking here but, besides of git commits I've seen no explanation about what's happening. Also some users of my old engine, which are blocked to an old wine version (it is no more applicable to git tree since some time, because of recent changes) would like to know what's going on. Ciao Max
Re: [docs] winedev: Update code columns limit (resend)
Am 24.07.2011 00:02, schrieb Francois Gouget: > On Mon, 4 Jul 2011, André Hentschel wrote: > [...] >> -Code is usually limited to 80 columns. This helps prevent >> -mailers mangling patches by line wrap. Also it generally >> +Code is usually limited to 100 columns. It generally > > I'd prefer to keep the 80 columns recommandation. > > With 80 columns one can nicely fit files side by side on a laptop with a > typical 1024 horizontal resolution whereas with 100 colums one would end > up with the hair comb effect thus making the code unreadable. Also 100 > seems close enough to 80 that I'm not sure it actually provides any of > the benefits that longer lines are supposed to provide (if they are > supposed to provide any). I see your point, but looking at the code it's already quite often around 100 and AJ also stated that 100 is more or less the actual limit. Otherwise i wouldn't have sent the patch. -- Best Regards, André Hentschel
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On Sun, Jul 24, 2011 at 12:18 AM, Stefan Dösinger wrote: > I just started reading this, I'll write more once I am done. Just a quick > question: What do you mean with "built in function" in the comment above > color_to_vector? I wanted to ask if there was a DirectX function or macro that can convert a D3DCOLOR, which is four bytes in the range 0-255, to four floats in the range 0-1 or a D3DXVECTOR4? Reading this again I think color_to_vector should probably accept a D3DCOLOR instead of "BYTE color[4]"? Thanks, Michael
