February 2006 - Wine-Devel - list.winehq.org

Re: dlls/shell32/shfldr_unixfs.c breaks non-GNU/Linux platforms

by Coleman Kane

Perhaps build a configurable option to use canonicalize_file_name if it exists, and fall back on realpath if it doesn't... realpath is supposed to be safe if you use necessary precautions... On Wed, 2006-02-01 at 17:45 +0100, Michael Jung wrote: > Hi Gerald, > > On Wednesday 01 February 2006 16:25, you wrote: > > The following patches to dlls/shell32/shfldr_unixfs.c break FreeBSD > > and other non-GNU platforms: > > <snip> > > > The reason is that canonicalize_file_name() is not found during linking. > > > > The man page for this function states "The function is a GNU extension", > > so this clearly kills portability. :-( > > We could fall back to "realpath", if "canonicalize_file_name" is not > available. However the man page on "realpath" states: > "Never use this function. It is broken by design" > > Do you know of a function on BSD, which can be applied here? If all else > fails, we'll have to re-implement path-canonicalization. But I would prefer > to use a library function. > > Bye,

Feb. 1, 2006

Re: Yeah - our RichEDit needs some work

by Dan Kegel

On Dec 25 2003, Subhobroto Sinha wrote: > IMHO, one of the best tests are Steve Gibson's > (http://www.grc.com) freeware tools - this guy writes in pure ASM. > and thus we can be sure that his code will be the least messy (lesser MS stuff..) > However, if you try his 'Wizmo' or 'DCOMObulator', > you will see that the RichEdit textareas as blank ! OK, I finally tried Wizmo :-) Wine's riched20 works a lot better now, but it still has a scrolling bug, so I filed http://bugs.winehq.org/show_bug.cgi?id=4458 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Feb. 1, 2006

Re: dlls/shell32/shfldr_unixfs.c breaks non-GNU/Linux platforms

by Michael Jung

Hi Gerald, On Wednesday 01 February 2006 16:25, you wrote: > The following patches to dlls/shell32/shfldr_unixfs.c break FreeBSD > and other non-GNU platforms: <snip> > The reason is that canonicalize_file_name() is not found during linking. > > The man page for this function states "The function is a GNU extension", > so this clearly kills portability. :-( We could fall back to "realpath", if "canonicalize_file_name" is not available. However the man page on "realpath" states: "Never use this function. It is broken by design" Do you know of a function on BSD, which can be applied here? If all else fails, we'll have to re-implement path-canonicalization. But I would prefer to use a library function. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Feb. 1, 2006

Howto write a Linux application that uses a DLL COM object

by kfa

Hi @, First I hope I didn't overlook something obvious covered in the docs, if so I'd appreciate a pointer. I'd like to write a brokerage application in Linux based on the API provided by the broker, but this API is only available as COM object in a DLL. Is it possible to tell by a quick look whether this is doable at all? Could somebody who has done a similar thing before provide a program stub as a starting point? This is a link to the API: http://www.cmsfx.com/en/platform/VTapi/ Thanks, Klaus

Feb. 1, 2006

dlls/shell32/shfldr_unixfs.c breaks non-GNU/Linux platforms

by Gerald Pfeifer

The following patches to dlls/shell32/shfldr_unixfs.c break FreeBSD and other non-GNU platforms: revision 1.70 date: 2006-01-31 17:24:37 +0000; author: julliard; state: Exp; lines: +1 -1 Michael Jung <mjung(a)iss.tu-darmstadt.de> unixfs: Only append '/' to base path if not already present in UNIXFS_get_unix_path. ---------------------------- revision 1.69 date: 2006-01-31 12:05:30 +0000; author: julliard; state: Exp; lines: +24 -64 Michael Jung <mjung(a)iss.tu-darmstadt.de> unixfs: Only resolve the 'dosdevices' based symbol links in UNIXFS_get_unix_path, but leave all others alone. The reason is that canonicalize_file_name() is not found during linking. The man page for this function states "The function is a GNU extension", so this clearly kills portability. :-( Would you mind having a look? Thanks, Gerald

Feb. 1, 2006

Re: dx9 and shaders

by Molle Bestefich

Stefan Dösinger wrote: > However, I am still stuck on > IWineD3DSurface::GetDC / IWineD3DSurface::ReleaseDC, > and they are show stoppers for d3d7 games. Here's the relevant post. http://article.gmane.org/gmane.comp.emulators.wine.devel/38533/ Unfortunately I'm of no use wrt. that, but thought I'd provide the pointer and maybe someone else can help or comment. OTOH, if you (Stefan) or the other DirectX guys need moral support or a new DirectX game to play with, let me know ;-). (PS. Also searched the archives looking for other IWineD3DSurface::GetDC related stuff. There's this: http://article.gmane.org/gmane.comp.emulators.wine.devel/32994/, but it's of course pretty irrelevant to the question Stefan's asking in the other archive link..)

Feb. 1, 2006

Re: wined3d: Fixed render states

by Molle Bestefich

Stefan Dösinger wrote: > > It would be good if someone with an ATI card could download the > > point_sprite_bug sample mentioned on that page and test it out to see if > > it is still an issue. > > a "GL_ARB_point_parameters extension was not found" error. Same here, Radeon 8500LE and open source drivers.

Feb. 1, 2006

Re: dx9 and shaders

by Tom Wickline

On 2/1/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > Here is a (probably outdated) link: > > > > http://wiki.winehq.org/DirectX-ToDo > In my eyes this list is quite up to date. I need to update the [DirectSound] section to reflect that full duplex support has been added. Other than that I'm not aware of anything that's terribly out of date. Feel free to update, correct or even extend the page if your aware of something that's in need of change. Or send the needed changes to me and ill update the page. Cheers, Tom

Feb. 1, 2006

Re: <DEL> key is sending an extra char when NumLock is ON

by penna＠bb.com.br

zhilla wrote: > > I am going to open a bug at bugzilla and send the WINEDEBUG=+key > > (just the piece where the stuff happens). > > dont, its already opened for a while. > http://bugs.winehq.org/show_bug.cgi?id=2400 > there is a working patch there... but some people claim its not very > good since it hardwires the key to code. > somebody should really look into this already... half of solution is > already there :) Sorry ... I did a search and found nothing so I have already opened a bug. Anyway, they already marked it as duplicated. Well, I was taking a look into it but I am going to need some explanations. If someone could provide (or point me out) I will be very thankful. 1) Does X send two separate sequences of keys for some type of keys (<del> for example)? 2) The translation from keycode to virtual key in wine is a little bit difficult to understand (at a first glance). Is there an email or any documentation explaining that (besides the source code ;-))? Otherwise it will take some weeks just to understand how it works 8-( .... 3) The patch proposed at bug #2400 works very well, however it seems to be not in a correct place (at first glance) .... 4) There is a "gap" in the nonchar_key_scan[] array just at the VK_SEPARATOR equivalent position (0xFFAC) on the nonchar_key_vkey[] position (see the question mark below - as in source code): static const WORD nonchar_key_vkey[256]= { ..... 0, 0, 0, 0, 0, 0, 0, 0, /* FFA8 */ VK_SEPARATOR, VK_SUBTRACT, VK_DECIMAL, VK_DIVIDE, ...... }; static const WORD nonchar_key_scan[256]= { ...... 0x00, 0x00, 0x37, 0x4e, /* ? */ 0, 0x4a, 0x53, 0x135, /*FFA8 */ ...... }; The VK_SEPARATOR is the <del> and/or <,> key at the numeric pad. Any relation with the problem? Thanks. --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 ---------------------------------------------------------

Feb. 1, 2006

Re: opengl: Sync a dibsection to its pixmap before drawing to it via opengl

by Alexandre Julliard

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > --- a/dlls/opengl32/wgl.c > +++ b/dlls/opengl32/wgl.c > @@ -54,7 +54,8 @@ enum x11drv_escape_codes > X11DRV_END_EXPOSURES, /* end graphics exposures */ > X11DRV_GET_DCE, /* get the DCE pointer */ > X11DRV_SET_DCE, /* set the DCE pointer */ > - X11DRV_GET_GLX_DRAWABLE /* get current glx drawable for a DC */ > + X11DRV_GET_GLX_DRAWABLE, /* get current glx drawable for a DC */ > + X11DRV_SYNC_PIXMAP /* sync the dibsection to its pixmap */ It seems to me that GET_GLX_DRAWABLE is already doing pretty much the same thing, couldn't you reuse that instead of adding another escape? -- Alexandre Julliard julliard(a)winehq.org

Feb. 1, 2006