wine-devel July 2010

114 participants
459 discussions

Re: (Resent) Documentation - Reference to MSDN?

by James Mckenzie

Alexandre Julliard <julliard(a)winehq.org> wrote: > >Erich Hoover <ehoover(a)mines.edu> writes: > >> Alright, well then I won't do it. Is the existing documentation going >> to be stripped at some point? It seems to me like we would benefit >> from more-detailed function descriptions in the auto-generated API >> documentation. I think it would save a lot of time for new developers >> to get their feet wet if they were able to see directly in the source >> what the different functions are supposed to do (as best as we know) >> and exactly what applications will trigger known edge cases (or if >> there's a test for a given situation). > >That's what the source code and test cases are for. If you rely on the >function documentation you are in trouble anyway, nobody bothers to >update it when new behaviors are discovered. > >If you really want to write good API documentation, as opposed to the >current useless one-sentence-per-parameter description, you'd need >probably a text 10 times the size of the source code for each >function. That can't go in the source files. > How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. James McKenzie

13 years, 10 months

Re: [1/2] wined3d: unbound texture units should sample black instead of white.

by Stefan Dösinger

Am Donnerstag 01 Juli 2010 16:54:08 schrieb Fabian Bieler: > - glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, 1, 1, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, &white); > + glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 1, 1, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, &black); This will only work if the shader samples 2D textures, or is a 1.x pixel shader. I am afraid you'll have to add bit for no texture being bound to a sampled sampler to the ps_compile_args structure and replace the TEX statement with reading a constant instead. Or explicitly bind dummy 2D, 3D, Cube and RECT textures to unused samplers. (and e.g. a dummy 2D, 3D and RECT sampler if a volume texture is used)

13 years, 10 months

Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)

by James Mckenzie

Tuomo Mattila <tuomom(a)ee.oulu.fi> wrote: Why not just do the check and then pass it as a Wide to the 'W' function? Simpler and less code to maintain/update? >+ >+ >+ FIXME("(%s, %p, %d, %p), stub!\n", debugstr_a(volumename), volumepathname, buflen, returnlen); If this is not a full implementation, you need to state so, otherwise this goes.... >+ >+ if (volumename == 0 || volumepathname == 0 || returnlen == 0) >+ { >+ SetLastError(RPC_X_NULL_REF_POINTER); >+ return FALSE; >+ } At this point you should convert to Wide/UNICODE and pass to the W function. Pass the return from the W call back to the caller. >+ >+ return TRUE; >+} >+ >+/*********************************************************************** > * GetVolumePathNamesForVolumeNameW (KERNEL32.@) > */ > BOOL WINAPI GetVolumePathNamesForVolumeNameW(LPCWSTR volumename, LPWSTR volumepathname, DWORD buflen, PDWORD returnlen) >-- >1.7.1 > > >

13 years, 10 months

Documentation - Reference to MSDN?

by Max TenEyck Woodbury

I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?

13 years, 10 months

(Resent) Documentation - Reference to MSDN?

by Max TenEyck Woodbury

13 years, 10 months

Creating tests with additional binary modules

by Mariusz Pluciński

Hi, wine-devel I'm working on implementation of Windows Game Explorer interfaces for Wine. The work is in advanced stage now, but I have problem with implementation of conformance tests. Thing I want to test is loading and parsing so-called Game Definition Files. GDF are not separate files, but stored as resources in binary modules (usually in game's main executable). Using GE interfaces, programmer only needs to pass path to binary, and GE automatically loads and process embedded GDF(s). Checking results of routines execution is not problem for me. But thing I test is parser, so I need to pass various GDF files to routine. And, as GDFs are stored in binaries, I will need to create many binaries. They should be created in compile time and available for test's executable while running it. The problem is that I don't know how to do this using wine's mechanisms. How should Makefile.in file look to build additional executable files properly (they should be probably always native win32 executables, even if parameter "crosstest" wasn't specified)? How should I guarantee that these additional executables will be copied into winetest directory (to make them accessible while executing tests)? Thanks in advance Mariusz Pluciński

13 years, 10 months

Re: Add support for arguments to -fprofile-* functions.

by André Hentschel

Hi, sorry, but your patch is a bit ugly... please look at the code below /* determine if tihs switch is followed by a separate argument */ in winegcc.c and understand what it does. specially with next_is_arg, is_linker_arg, .... Also the following is senseless: +int strstartswith(const char * str, const char * start) +{ + return strstr(str, start) == str; +} -- Best Regards, André Hentschel

13 years, 10 months

Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)

by André Hentschel

Using "quick and dirty" in the subject while code freeze is most likely not to be commited :) -- Best Regards, André Hentschel

13 years, 10 months

updating spec files - which windows version to use?

by Austin English

Howdy, I was looking at http://bugs.winehq.org/show_bug.cgi?id=23421, and wanted to add a stub for it. Using winedump on a Windows 7 shlwapi.dll gives different exports than Windows XP SP3 shlwapi.dll. Which dll should the spec file be updated to match? I'm assuming the latest and greatest, since eventually applications will head that direction. An additional related question. Some of the functions that are ordinals in previous Windows versions are now exported (e.g., ParseUrlA/W seems to have been documented/exported since Vista). Should the spec file be adjusted to match the newer behavior? I'm assuming this will have to wait until after 1.2 to be applied... Thanks! Austin

13 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2010