July 2010 - Wine-devel - list.winehq.org

Re: (Resent) Documentation - Reference to MSDN?
by James Mckenzie 02 Jul '10

02 Jul '10

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

6 7

Re: [1/2] wined3d: unbound texture units should sample black instead of white.
by Stefan Dösinger 02 Jul '10

02 Jul '10

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)

3 3

Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)
by James Mckenzie 02 Jul '10

02 Jul '10

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 > > >

2 1

Documentation - Reference to MSDN?
by Max TenEyck Woodbury 02 Jul '10

02 Jul '10

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?

3 2

(Resent) Documentation - Reference to MSDN?
by Max TenEyck Woodbury 01 Jul '10

01 Jul '10

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?

9 17

Creating tests with additional binary modules
by Mariusz Pluciński 01 Jul '10

01 Jul '10

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

5 8

Re: Add support for arguments to -fprofile-* functions.
by André Hentschel 01 Jul '10

01 Jul '10

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

3 4

Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)
by André Hentschel 01 Jul '10

01 Jul '10

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

1 0

updating spec files - which windows version to use?
by Austin English 01 Jul '10

01 Jul '10

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

2 1