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

Re: (Resent) Documentation - Reference to MSDN?

by Peter Davies

> My primary concern here is > participation Count me in! I think it would be a great way to learn the wine/windows internals. Peter

July 1, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > Obviously this is a big task and it's not something that is going to > happen overnight, but I think that such a wiki could provide a useful > service to the Wine community. My primary concern here is > participation, since if there's little or no participation it will > never grow to the magnitude that's necessary for it to be a helpful > resource. So, I guess I'm saying that if there's at least some chance > of embedding URLs in the source that will direct people to this > documentation then I'd feel much more comfortable investing my free > time in setting something up. We can have pointers on the website or the README, and we can probably find a way to have doc links in the lxref source browser. We certainly don't want a URL in front of each function in the source, it will be a major pain when they change (and trust me, they will). Just make sure that your pages are properly indexed by Google. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Erich Hoover

On Thu, Jul 1, 2010 at 7:56 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Max TenEyck Woodbury <max(a)mtew.isa-geek.net> writes: > > > So, would it be OK with you to extract the current documentation and > > put it in the wiki where it can be more easily maintained? Wikis are > > supposed to be good for exactly that kind of thing. > > > > Once the wiki is populated with the initial information from the source > > code, the source code could then be cleaned up by having links to the > > wiki in place of the current cruft. > > That's fine, but please don't hijack the Wine wiki for this, start a > separate one. > If we mock up an example, and it is deemed acceptable, would we be permitted to make patches replacing the in-code documentation with the URL for the appropriate function? The idea here would be to accomplish several goals: 1) Give new Wine developers somewhere to look for documentation to help them get started 2) Give current Wine developers investigating something outside of their expertise some information to help familiarize them with another area of the API 3) Provide unchanging URLs that can legitimately be used in the source code without fear of them changing every week (or being lost forever in the case of some older functions) 4) Document the ever-growing list of unexpected behaviors that MSDN will never tell you about Obviously this is a big task and it's not something that is going to happen overnight, but I think that such a wiki could provide a useful service to the Wine community. My primary concern here is participation, since if there's little or no participation it will never grow to the magnitude that's necessary for it to be a helpful resource. So, I guess I'm saying that if there's at least some chance of embedding URLs in the source that will direct people to this documentation then I'd feel much more comfortable investing my free time in setting something up. Erich Hoover ehoover(a)mines.edu

July 1, 2010

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)

July 1, 2010

Re: Creating tests with additional binary modules

by Peter Davies

> Wine can load and parse resources just from > winelib (dll.so/exe.so) binaries. I assume that dll.so/exe.so are for all practical purposes identical to .dll/.exe except they can't be run on windows. Peter

July 1, 2010

Re: updating spec files - which windows version to use?

by Peter Davies

> 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 If there are no conflicts, add everything. If any version of windows exports something, export it. Exporting ParseUrlA/W by name will work with both XP and post-vista programs, not exporting it by name will break post-vista programs. If a function was removed after a certain version, it wouldn't be removed in wine. Peter

July 1, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Jakob Eriksson

On 07/01/2010 04:34 AM, Dmitry Timoshkov wrote: > Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: > > >> I created the top page as a table and populated it with all the >> directory entries in the 'dll' directory. Somebody immediately deleted >> it. WTF? >> > Creating a MSDN clone does not belong to the Wine project. > > But maybe it should? MSDN is famous for being pretty good, but incomplete, incorrect and changing URLs all the time. // Jakob

July 1, 2010

Re: Creating tests with additional binary modules

by Vitaliy Margolen

On 06/30/2010 09:52 AM, Mariusz Pluciński wrote: > 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. Do they really need to be separate binaries? Can't it be multiple resources in one binary? And if so, just add resources to the test. And no, it doesn't have to be a pure win-pe binary. Wine can load and parse resources just from winelib (dll.so/exe.so) binaries. Vitaliy

July 1, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Alexandre Julliard

Max TenEyck Woodbury <max(a)mtew.isa-geek.net> writes: > So, would it be OK with you to extract the current documentation and > put it in the wiki where it can be more easily maintained? Wikis are > supposed to be good for exactly that kind of thing. > > Once the wiki is populated with the initial information from the source > code, the source code could then be cleaned up by having links to the > wiki in place of the current cruft. That's fine, but please don't hijack the Wine wiki for this, start a separate one. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2010

Re: Documentation - Reference to MSDN?

by Vitaliy Margolen

On 06/30/2010 09:22 AM, Max TenEyck Woodbury wrote: > 1) Would including the URL of the MSDN article be useful/a good idea? No. Microsoft in all these years haven't figured out how to create permanent links. All, and I really mean it _ALL_ URLS on MSDN had changed at least once a year. > 2) Would enumerating coded values and flags be allowed? That's what headers are for. > 3) Where should data structures be documented? On MSDN. Wine is an implementation of API not the spec. Vitaliy.

July 1, 2010