Re: Documentation - Reference to MSDN?
Vitaliy Margolen wrote: 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. They have learned well from IBM. I have links that I use at work that change on an almost weekly basis. 2) Would enumerating coded values and flags be allowed? That's what headers are for. Correct. However, if a flag is used in more than one place, it would be 'nice' to annotate that the flag/enumeration does exist. Saves embarrassing and unnecessary patch submissions 3) Where should data structures be documented? On MSDN. Wine is an implementation of API not the spec. I agree. The functions and their calls/results are what we are interested in. We don't care how M$ got there, we are on a different path. James McKenzie
Re: (Resent) Documentation - Reference to MSDN?
Dmitry Timoshkov wrote: Max TenEyck Woodbury 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. Dmitry: I think you completely miss what this is all about. We are NOT creating an MSDN 'clone'. Maybe a cleaned up duplicate of soared.org. We do need to annotate, in one location, the project's findings and code that is pending implementation that was acquired through research of existing resources and validation through blackbox testing. It is NOT our purpose to provide sample code or anything like it. That is what MSDN is there for. To assist Microsoft Developers working with Windows products to produce Windows programs. Not to assist or aid any others in the pursuit of a 'look alike' API that just happens to run on UNIXy operating systems. I agree with Alexandre, we don't need to hijack the wiki for Wine to do this. Maybe we do need another wiki site that is separate from but equal to the current wiki, but for Wine developers/hackers only and their efforts to improve upon current Wine project efforts. James McKenzie
Re: (Resent) Documentation - Reference to MSDN?
On Fri, Jul 2, 2010 at 7:35 AM, Octavian Voicu wrote: > > PS: there are other resources except MSDN; for example, osronline.com > has very good documentation for windows driver developers, including > some undocumented APIs. > I don't know if this is worth mentioning or not, Geoff Chappell maintains a website with some in depth information covering Windows internals, granted the methods used to discover the information may not be in line with what a Wine contributor is allowed to do, but in the same spirit of quality information he has proposed an initiative "producing an Opened Windows Library (OWL) as an alternative to Microsoft’s MSDN Library". Maybe this could be what you're looking for. http://geoffchappell.com/viewer.htm?doc=index.htm http://www.soared.org/ http://www.soared.org/plan/index.htm http://www.soared.org/plan/faq.htm PS. The idea of publishing this information to a wiki seems a little ad-hoc, wouldn't it be better to put things under a dvcs (like git) and then publish based on that?
Changing sizes of templates in comdlg32
I've found the following warning the the file comdlg32: /* * WARNING: DO NOT CHANGE THE SIZE OF THE STANDARD DIALOG TEMPLATES. */ Does that mean that I can't correct the size of the buttons or strings that are wrong in the Portuguese template file? Or is that only a warning for the English file? The "Find" and "Replace" dialogs are specially ugly in Portuguese, I would appreciate to be able to change that.
Re: (Resent) Documentation - Reference to MSDN?
On Thu, Jul 1, 2010 at 8:06 PM, Erich Hoover wrote: > 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 Why would we want to help Micro$oft with that? How did they ever contribute to the open source community to deserve that? As I see it, Wine's primary goal is to aid in the migration from Windows, a closed platform, to an open platform like Linux. There is enough to do already (kernel, system dlls, many many libraries, installer, directx, command line tools, various programs and tools, testing infrastructure, translations, etc), if we spread ourselves too thin we won't get anywhere with anything. Imho there are very few cases in which better documentation would benefit our cause, but I'm pretty sure that devoting that time to writing wine code instead of winapi documentation would have a much greater impact. Octavian PS: there are other resources except MSDN; for example, osronline.com has very good documentation for windows driver developers, including some undocumented APIs.
Re: Creating tests with additional binary modules
Am 01.07.2010 21:55, schrieb Alexandre Julliard: > None of that, of course. The resources are built at compile time, at run > time you create a PE header and copy the needed resource data. You may > even be able to use UpdateResource to make things easier. Do we have existing tests creating PE header? -- Best Regards, André Hentschel
Re: Creating tests with additional binary modules
W dniu 1 lipca 2010 21:55 użytkownik Alexandre Julliard napisał: > Mariusz Pluciński writes: > >> W dniu 1 lipca 2010 21:27 użytkownik Alexandre Julliard >> napisał: >>> You can't do that in the Makefile, you need to generate the files at run >>> time. >> >> Huh, so while executing the test, I need to run at least resources >> compiler and linker, right? It looks really more complicated way, and >> I admit that I completely don't know how to do it. Which tools >> should I use? Can I use Mingw? Can I assume that these tools are >> installed on system where test is running? Or maybe I should use >> some tools provided by wine? And, of course, how to make it working >> on Windows? > > None of that, of course. The resources are built at compile time, at run > time you create a PE header and copy the needed resource data. You may > even be able to use UpdateResource to make things easier. > All right, now it's more clear for me. I'm not so familiar with working on resources, and I didn't know there's API call which can modify resources in existing binary. I'll try to make it this way, thanks.
Re: Creating tests with additional binary modules
Mariusz Pluciński writes: > W dniu 1 lipca 2010 21:27 użytkownik Alexandre Julliard > napisał: >> You can't do that in the Makefile, you need to generate the files at run >> time. > > Huh, so while executing the test, I need to run at least resources > compiler and linker, right? It looks really more complicated way, and > I admit that I completely don't know how to do it. Which tools > should I use? Can I use Mingw? Can I assume that these tools are > installed on system where test is running? Or maybe I should use > some tools provided by wine? And, of course, how to make it working > on Windows? None of that, of course. The resources are built at compile time, at run time you create a PE header and copy the needed resource data. You may even be able to use UpdateResource to make things easier. -- Alexandre Julliard julli...@winehq.org
Re: Creating tests with additional binary modules
W dniu 1 lipca 2010 21:27 użytkownik Alexandre Julliard napisał: > You can't do that in the Makefile, you need to generate the files at run > time. Huh, so while executing the test, I need to run at least resources compiler and linker, right? It looks really more complicated way, and I admit that I completely don't know how to do it. Which tools should I use? Can I use Mingw? Can I assume that these tools are installed on system where test is running? Or maybe I should use some tools provided by wine? And, of course, how to make it working on Windows?
Re: Creating tests with additional binary modules
Mariusz Pluciński writes: > That's true on Wine, but I also want to make my tests runnable > under Windows, so in this case I need to create native PE modules. > > And as I said, my main problem is that I don't know how to > write rules in Makefile.in to build what I need. You can't do that in the Makefile, you need to generate the files at run time. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)
Tuomo Mattila 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
>
>
>
Re: Creating tests with additional binary modules
> Do they really need to be separate binaries? Unfortunately yes. To the function I pass only the path to binary, and it unpacks data internally, so I cannot select actual resource. One binary can contain multiple GDFs only if they are translations of the same file in few languages. And I don't know is there any way to force library to load specified language version (and it is, in my opinion, not "clean" way of testing). > 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. That's true on Wine, but I also want to make my tests runnable under Windows, so in this case I need to create native PE modules. And as I said, my main problem is that I don't know how to write rules in Makefile.in to build what I need.
Re: Add support for arguments to -fprofile-* functions.
> strncmp(arg, str, sizeof(str)-1) looks ugly. Am I expected to accept that as an axiom? IMO, your strstr wrapper is much uglier, in addition to being needlessly complex. --Juan
Re: Add support for arguments to -fprofile-* functions.
> What's wrong with strncmp? strncmp(arg, str, sizeof(str)-1) looks ugly. Peter
Re: Why some gdi32 calls aren't caught in relay while some are caught?
> Wine doc says relay supports user32, ntdll, etc, but not gdi32. > However when I run wine, some gdi32 calls are caught, e.g, CreateBitmap() > But some aren't caught, e.g, CreateBitmapIndirect() IIRC, calls across dlls are caught by +relay, but calls within the same dll are not. --Juan
Why some gdi32 calls aren't caught in relay while some are caught?
Hi, all I found that WINEDEBUG=+relay works by dlls/ntdll/relay.c and I'm trying to catch function call of dlls. Wine doc says relay supports user32, ntdll, etc, but not gdi32. However when I run wine, some gdi32 calls are caught, e.g, CreateBitmap() But some aren't caught, e.g, CreateBitmapIndirect() - $ WINEDEBU+relay wine notepad.exe trace:bitmap:CreateBitmapIndirect 8x8, 2 colors returning 0x220 [relay_call:12] 000d:Ret gdi32.CreateBitmap() retval=0220 ret=68849be9 - Both are gdi32 export function. Do you know why? I want to catch all gdi32 function calls. Thanks in advance. Hayan
Re: [1/2] wined3d: unbound texture units should sample black instead of white.
On Thursday 01 July 2010 17:19:42 Stefan Dösinger wrote: > 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) I hoped that OpenGL took care of those cases. According to the spec samplers with incomplete textures bound to them should return (0, 0, 0, 1), too. Wouldn't sampling from a texture unit to which the binding of matching dimensionality is 0 count as incomplete? (At least as long as no one uploads an image to it, I'm not sure if it's legal to use texture name 0) Anyhow, I just did some testing and found out that nvidia returns (0, 0, 0, 0) for incomplete textures and 'unbound' texture units i.e. bound to 0. Maybe it does that on windows for D3D, too. I only tested on AMD and the reference rasterizer (which both return (0, 0, 0, 1)) and bug 14942 only depends on the rgb components. My suggestion would be to drop the test for the alpha channel, leave the patch as it is and report the issue to nvidia. Also: If you want to work around the issue with more dummy textures, wouldn't you also have to bind dummy textures to all available texture units (and not just the ones exposed to the fixed-function-pipeline)? Fabian
Re: Add support for arguments to -fprofile-* functions.
> Are you objecting to function or the implementation? It is a simple > function that clarifies the code by making it self documenting, > implemented fairly efficiently in a performance wise undemanding > program. What's wrong with strncmp? --Juan
Re: Add support for arguments to -fprofile-* functions.
> 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,
I could set option_arg for semantic correctness.
> Also the following is senseless:
> +int strstartswith(const char * str, const char * start)
> +{
> + return strstr(str, start) == str;
> +}
Are you objecting to function or the implementation? It is a simple
function that clarifies the code by making it self documenting,
implemented fairly efficiently in a performance wise undemanding
program.
Peter
Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)
Using "quick and dirty" in the subject while code freeze is most likely not to be commited :) -- Best Regards, André Hentschel
Re: Add support for arguments to -fprofile-* functions.
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
Re: (Resent) Documentation - Reference to MSDN?
Am 01.07.2010 19:26, schrieb Peter Davies: >> My primary concern here is >> participation I think http://wiki.jswindle.com would also be a good place if he would cooperate... BTW: we should slowly come to an end with that discussion on wine-devel IMO -- Best Regards, André Hentschel
Re: (Resent) Documentation - Reference to MSDN?
On 07/01/2010 04:34 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury 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
Re: (Resent) Documentation - Reference to MSDN?
> My primary concern here is > participation Count me in! I think it would be a great way to learn the wine/windows internals. Peter
Re: (Resent) Documentation - Reference to MSDN?
Erich Hoover 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 julli...@winehq.org
Re: (Resent) Documentation - Reference to MSDN?
On Thu, Jul 1, 2010 at 7:56 AM, Alexandre Julliard wrote: > > Max TenEyck Woodbury 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 ehoo...@mines.edu
Re: [1/2] wined3d: unbound texture units should sample black instead of white.
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)
Re: Creating tests with additional binary modules
> 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
Re: updating spec files - which windows version to use?
> 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
Re: Creating tests with additional binary modules
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
Re: (Resent) Documentation - Reference to MSDN?
Max TenEyck Woodbury 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 julli...@winehq.org
Re: Documentation - Reference to MSDN?
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.
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:13 PM, Alexandre Julliard wrote: Erich Hoover 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. 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. Erich Hover's tree structure sounds like the right way to go. Formatting guidelines and templates to tag the article contents so the information can be easily extracted will be needed, but that belongs on the wiki, although issues should be discussed and decided on this mailing list.
