Re: oleaut32/tests: added tests for negative fractional variant dates.
Oops, those empty parens () were intended to cite the URL for the article. Unfortunately, I can't seem to find it now. However, I found an MSDN page that describes the behavior I am testing here: http://msdn.microsoft.com/en-us/library/system.datetime.fromoadate.aspx This is actually documentation of a .NET method, but see the Remarks section for a description of the format. On Fri, 1 Oct 2010, Jeremy Drake wrote: I recently read an article () mentioning some of the oddities that show up in negative variant dates with non-zero (midnight) times, and I noticed that wine had no test coverage for these cases. Until now. --- dlls/oleaut32/tests/vartest.c | 32 +++- 1 files changed, 23 insertions(+), 9 deletions(-) -- Egotist, n.: A person of low taste, more interested in himself than me. -- Ambrose Bierce, The Devil's Dictionary
Re: oleaut32/tests: added tests for negative fractional variant dates.
On Sat, 2 Oct 2010, James McKenzie wrote: Looks like you got 'bit' by the way that a finite storage method mangles floating information. There was a lengthy discussion on how to 'overcome' this on the Wine-Development list a short while ago. No, those tests aleady account for that. /* When comparing floating point values we cannot expect an exact match * because the rounding errors depend on the exact algorithm. */ #define EQ_DOUBLE(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b)) 1e-14) #define EQ_FLOAT(a,b) (fabs((a)-(b)) / (1.0+fabs(a)+fabs(b)) 1e-7) ok_(__FILE__,line)(r == res (FAILED(r) || EQ_DOUBLE(out, dt)), expected %x, %.16g, got %x, %.16g\n, r, dt, res, out); My understanding is that that algorithm should work to account for floating-point inaccuracies (though technically should be using DBL_EPSILON and FLT_EPSILON instead of 1e-X constants, but they're probably not portable enough for this project), I was simply bit by my own stupidity, not running my last changes against a Windows OS before sending my patch. This has been corrected in my try2. Maybe Dan Kegel can step in and refresh this. James McKenzie -- The older I grow, the less important the comma becomes. Let the reader catch his own breath. -- Elizabeth Clarkson Zwart
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
On Wed, 14 Jan 2009, Alexandre Julliard wrote: Jeremy Drake w...@jdrake.com writes: Is there anything wrong with these two patches? I'd really like to see these tests go in, so hopefully someone will decide to tackle this olepicture stuff. At the very least, putting the stubs in for OleLoadPictureFile (patch 1/2) keeps my app from crashing... Sorry but I'm not going to accept your patches in this area since you looked at the disassembled code. Probably your best bet is to file a bug about the missing function and hope that someone else picks it up. Right. That's why I abandoned writing a patch to implement the functions, and instead focused on writing test cases so others could implement them. Is writing test cases also verboten for someone who has seen disassembly? It was my understanding that that was the acceptable way for me to move forward with this.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
On Wed, 14 Jan 2009, Alexandre Julliard wrote: Yes, it's better to avoid it, because then you may be testing things that you know the function is doing internally but that may not actually matter. Tests have to treat the target dll as a black box, and if you looked inside then it's no longer a true black box. Sorry about that, but we really have to play it safe, for obvious reasons. I understand. But, can we at least get the [1/2] patch in, that adds stubs for OleLoadPictureFile and OleLoadPictureFileEx that just trace FIXMEs and return E_NOTIMPL? There's definitely nothing in there that I could have learned from disassembly, and it would at least keep my app from crashing.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
On Mon, 5 Jan 2009, Jeremy Drake wrote: --- dlls/oleaut32/tests/olepicture.c | 321 ++ 1 files changed, 321 insertions(+), 0 deletions(-) Is there anything wrong with these two patches? I'd really like to see these tests go in, so hopefully someone will decide to tackle this olepicture stuff. At the very least, putting the stubs in for OleLoadPictureFile (patch 1/2) keeps my app from crashing...
Re: oleaut32: add PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render
On Tue, 9 Dec 2008, Nikolay Sivov wrote: + case PICTYPE_NONE: + case PICTYPE_UNINITIALIZED: + /* undocumented code */ + return 0x800A017C; This code looks suspiciously like CTL_E_INVALIDPROPERTYVALUE (from olectl.h) to me...
Re: dlls/oleaut32: add tests for OleLoadPictureFile(Ex)
On Tue, 18 Nov 2008, Michael Karcher wrote: Looks OK to me, but what happened to your finding about INET_E_RESOURCE_NOT_FOUND? Was it a red herring? I saw that on XP, but I couldn't reproduce it on Windows 2000. I need to investigate this further. Is there a mechansim to do windows-version-specific tests? I ended up having to add OleLoadPicutreFile and OleLoadPictureFileEx to the .spec and .c files as actual functions (for now just returning E_NOTIMPL) in order to get the test to even compile. Might be that they don't appear in the ELF export table otherwise, and as we don't crossbuild the tests, the imports are done by the ELF linker/loader. BTW: In general, if you add stubs like this, please add a FIXME call showing the parameters and saying stub. How do I show the VARIANT in the FIXME call? This fragment repeats over and over, sometimes with PICTYPE_BITMAP instead. Might be worth refactoring that into a function. todo_wine works for function boundaries. If you refactor, you should pass that function __LINE__ information and print it in your OK calls to know which of the tests is failing if something fails. You do a lot of tests like this. Setting disp to (void*)0xdeadbeef instead before allows you to differentiate between disp unmodified and disp explicitly set to zero. Good ideas. I'll do that.
spec file syntax for VARIANT parameter
In order to implement OleLoadPictureFile and OleLoadPictureFileEx, it will be necessary to change their entries in oleaut32.spec from stub to stdcall. The stdcall syntax wants a list of parameter types, which puts these functions in an unususal situation: they take a VARIANT (which is a struct, in case anyone is not familiar) by value as their first parameter. There does not seem to be any type defined in the spec file that fits this situation. I have been using ptr in my last couple of patches which add stub implementations for these functions, but when I tried to build this on cygwin I got errors like: undefined reference to [EMAIL PROTECTED]' undefined reference to [EMAIL PROTECTED]' Looking at the functions that are present in the .o file, I see they are really [EMAIL PROTECTED] and [EMAIL PROTECTED] Changing the spec file to list each VARIANT as 4 longs fixes these errors. My question is, should my next version of the patch list the VARIANT as 4 longs, or is there some better way to specify this that I'm not aware of? If not, is there a comment syntax for the spec file where I can explain why there are 4 long params where there should be one VARIANT? Thanks Jeremy
Re: implement OleLoadPictureFile
On Tue, 18 Nov 2008, Michael Karcher wrote: Note that the IDL defines the VARIANT parameter as optional. If the filename is not specified, you should pass a NULL stream to OleLoadPicture. How do I know? I think you shouldn't have told these detail. I might know what happens if I pass in VARIANTs of type VT_ERROR or VT_NULL, like lplpdispPicture is unchanged, set to NULL or Windows crashes. But there seems no legal way for me to find out what happens inside Microsoft's oleaut32.dll. If it were an inter-dll call, relay or snoop might bring me to the conclusion that you are right, but I just pretend I never read that. Just write a couple of tests for different variant types (VT_NULL, VT_ERROR, VT_BSTR). If they crash on Windows, put them in an if(0) block with an appropriate comment. Right. Oops. I may actually have mis-remembered that, so it's good you didn't read that :P. I thought I had read on the MSDN that NULL stream meant that it would create an empty IPicture, but checking again it doesn't. I should have said that the unspecified parameter would result in an empty picture, and let you go from there. BTW, this case is tested in my tests... It may have been the This is equivalent to calling OleCreatePictureIndirect(NULL, ...)followed by IPersistStream::Load from the MSDN page that I was misremembering. Also, there is an OleLoadPictureFileEx, which adds the same 3 additional paramters as OleLoadPictureEx adds over OleLoadPicture. You can probably guess how that works... Do a three-way-merge of OleLoadPicture to OleLoadPictureEx and OleLoadPicture to OleLoadPictureFile and you arrive at OleLoadPictureFileEx, probably. Or call one from the other and save the code duplication. For the non-Ex versions, it may help you to know about the constant LP_DEFAULT in olectl.h, which means do the default thing to the extra params of the Ex version. MSDN documents LP_DEFAULT only for the palette in OleLoadPictureFileEx, but follows your points in the documentation for OleLoadPictureEx. It might have been that the the desired size should be just zero (which LP_DEFAULT happens to be) to get the default. As far as the standard OLE file stream object, if you know of one please let me know. AFAIK, it is a pretty major oversight in the OLE IStream APIs that there is not a function to create an IStream given a file (name or handle). Oops. I just assumed there was one, but you seem to be right. One could try whether the Windows FileMoniker works on objects that don't implement IPersistFile but just IPersistStream and thus IMoniker::BindToObject from the FileMoniker does what we want. But this is a very dangerous approach, as you can't tell BindToObject the CLSID to use, but just the IID you want, and the Wine implementation will happily activate and load *any* file type you pass in, and notice after loading that the object loaded does not support the IPicture interface. I don't know what ugly things can happen on IPersistStream::Load given some CLSIDs no one thinks about in the moment (maybe XML documents that cause an internet access to fetch the DTD), but I think some Media Player/Outlook security vulnerabilities we had some years ago are related to implementing things like this (that was IIRC attachments of the name .WAV that are associated with windows media player; windows media player checked magic numbers in that file, completely forgetting about the file a wave file finding MZ in the beginning and acting appropriately). You will see whether OLELoadPictureFile does that if you do a relay trace with native oleaut32 and builtin ole32, as the CreateFileMoniker call would cross DLL boundaries. Please don't tell me that you know that Microsoft did it another way, even if you probably do. OK, I won't. I've always had to roll my own wrapper around the file APIs, or use a hack like the one in OleLoadPictureFilePath. You probably mean OleLoadPictureFile. I am not going to look at your patch, so I don't know what hack you meant. If the hack was your idea, feel free to describe it. If the hack is inspired by the disassembly, please don't tell any Wine developer how that hack worked. No, I meant a hack in OleLoadPicturePath, as implemented in wine. I surely would not mention a hack I derived from the disassembly. Quite. Also in olectl.h are the error codes that these functions could return. Unfortunately, I think it will be necessary to make some sort of manual translation between the GetLastError returns from the file APIs and these errors. Without spelling out the mappings from the disassembly, it will probably be nearly impossible to get all of the cases exactly right. You shouldn't even have told that the mapping is done directly in OleLoadPictureFile and not some lower layer invoked by OleLoadPictureFile, except if you are sure from a relay trace. Of course, if Wine developers find that *somewhere* error codes seem
Re: implement OleLoadPictureFile
On Thu, 13 Nov 2008, Juan Lang wrote: Any feedback on the spec file or the debug trace? I'm afraid I don't know what substantive difference there is between looking at one small portion of the disassembly (to verify a function is being called) and learning something more substantial. There are certain kinds of reverse engineering that are allowed, but looking at disassembly is not. And now that I know that, I certainly won't be doing it again. I don't think this is going to go in, sorry. Well, I still have an application that won't run under wine because this function is not implemented. So assuming *this* patch doesn't get in, what can I do to help get *a* patch in that implements this function? I can blow away my sandbox and start from scratch, but I suspect you would find that insufficient. Maybe I should find a hypnotist to make me forget what I saw in the debugger :) Would it be acceptable for me to write up a description of what the function needs to do, so that someone else can do a clean-room implementation? It would probably take a reasonably experienced C/COM developer all of about 5 minutes, since this function is really just a wrapper of an already-implemented function. Is there anyone out there who would volunteer to do it if I were to write a description of the function? If I provided a patch to dlls/oleaut32/tests/olepicture.c adding tests that verify the behaviors of the functions, would that be accepted? Or is writing tests for functions you've seen the disassembly for also prohibited? I realize now that I've made a mistake by looking at the function in the debugger, but hopefully there is still a way I can help get this function implemented. Thanks, Jeremy
Re: implement OleLoadPictureFile
On Sun, 16 Nov 2008, Juan Lang wrote: Do you have a bug open? Sorry, I've forgotten. If not, please do open one. You can describe your findings there. No, but a quick search on bugzilla for OleLoadPictureFile turned up bug 10156. A comment on that bug suggests changing the summary to OleLoadPictureFile not implemented, which would exactly sum up my situation. I posted a comment to that bug to that affect. Should that bug be renamed, I could post my findings there... If I provided a patch to dlls/oleaut32/tests/olepicture.c adding tests that verify the behaviors of the functions, would that be accepted? Or is writing tests for functions you've seen the disassembly for also prohibited? In general, writing tests is okay, as they are an exercise in black-box reverse engineering, which is what's allowed. So yeah, tests would be great. I've been looking at writing some tests (I've been compiling using make crosstest and running the exe on windows 2000), and I've found that there must be some sort of mapping between error codes from GetLastError when accessing the file and the HRESULT values returned from OleLoadPicutreFile (and not of the standard HRESULT_FROM_WIN32 variety that I'm familiar with). For instance, CTL_E_FILENOTFOUND is returned when the file does not exist. I'm trying to invoke as many error cases in the test as I can to flesh out this mapping, but I'm not sure I can find all of them in this manner... I think at some point in the next couple of days I'll decide I've got as many as I can and send in a patch to the tests.
Re: implement OleLoadPictureFile
On Mon, 17 Nov 2008, Michael Karcher wrote: The best way to do this is (in my oppinion) submitting the testcase again, but without the implementation, and marking the test todo_wine. A bug might be useful, but wouldn't a mail that contains the testcase as patch and the description in the comment part to wine-patches suffice? Sounds good to me. Be sure to write your findings like (this is hypothetical, as I did not look at your patches and the OlePicture stuff till now): Loads an image from a File. This is just like OleLoadPictureStream, but with a file name instead of a stream as source specification and not like To implement the function, you must create a stream from the file (use the standard OLE file stream object for that), pass the stream to OleLoadPictureStream and finally release the stream. In the error case you should do foo. The second form *is* just publishing what you saw in disassembly, so everyone who reads this mail carefully is in my oppinion everyone reading it carefully is in the same situation as you and shouldn't implement the function. Hmm, looks like I don't really have to. Your detailed description is about 90% accurate :). But the simple version should read This is just like OleLoadPicture... I'll let you extrapolate the change to the detailed version. Note that the IDL defines the VARIANT parameter as optional. If the filename is not specified, you should pass a NULL stream to OleLoadPicture. Also, there is an OleLoadPictureFileEx, which adds the same 3 additional paramters as OleLoadPictureEx adds over OleLoadPicture. You can probably guess how that works... For the non-Ex versions, it may help you to know about the constant LP_DEFAULT in olectl.h, which means do the default thing to the extra params of the Ex version. As far as the standard OLE file stream object, if you know of one please let me know. AFAIK, it is a pretty major oversight in the OLE IStream APIs that there is not a function to create an IStream given a file (name or handle). I've always had to roll my own wrapper around the file APIs, or use a hack like the one in OleLoadPictureFilePath. Testcases on the other hand are fine. They just describe *what* to do, but not *how*. Especially for the error case testcases might be interesting. Quite. Also in olectl.h are the error codes that these functions could return. Unfortunately, I think it will be necessary to make some sort of manual translation between the GetLastError returns from the file APIs and these errors. Without spelling out the mappings from the disassembly, it will probably be nearly impossible to get all of the cases exactly right. The tests I have come up with so far verify the error codes that I've been able to figure out how to trigger. Is there anyone out there who would volunteer to do it if I were to write a description of the function? I would do so, if its just some minutes. I think that, as long as you are familiar with the APIs for dealing with VARIANTs, this should be a very simple task. I would provide details about how to deal with the VARIANT, but it may be misinterpreted as knowledge gained from the disassembler. So I'll just leave you with a couple of links to MS docs. http://msdn.microsoft.com/en-us/library/ms221673.aspx http://support.microsoft.com/kb/238981
Re: implement OleLoadPictureFile
On Wed, 12 Nov 2008, Austin English wrote: Can you add a testcase to show that this behavior is correct? Yeah. I'll do that for the next version of the patch, as well as implement OleLoadPictureFileEx. Any feedback on the spec file or the debug trace? Thanks, Jeremy -- If you cannot convince them, confuse them. -- Harry S Truman
