On Fri, 2007-04-05 at 13:34 +0200, Michael Stefaniuc wrote: > Bill Medland wrote: > > On Thu, 2007-03-05 at 07:29 -0700, Bill Medland wrote: > > > >>On Thu, 2007-03-05 at 07:49 +0200, Marcus Meissner wrote: > >> > >>>On Wed, May 02, 2007 at 03:32:59PM -0700, Bill Medland wrote: > >>> > >>>>Does anyone know where a call to OLE2A is going to enter wine? > >>>>Presumably OLE2A returning null means that the thread ran out of stack > >>>>space? > >>> > >>>What is OLE2A? I do not see it mentioned anyewhere in the Wine source. > >>> > >>>Any more debugging output? > >>> > >>>Ciao, Marcus > >> > >>Hi Marcus, thanks for taking interest. > >> > >>A little late now, I think. The problem is not where I thought it was. > >> > >>OLE2A is a Microsoft macro used to convert e.g. a BSTR to a char *, > >>allocating memory on the stack and calling one of the wide-to-narrow > >>conversions. > >> > >>Our program was behaving quite strangely, throwing an exception from > >>some code that should not throw an exception. > >> > >>I traced it down to some code that did an OLE2A on a BSTR, called strlen > >>on the return and then passed the same narrow string to a function. > >>The problem occurred when the OLE2A returned a null pointer. Due to an > >>oversight I thought the BSTR was non-null and assumed that somehow the > >>underlying alloca must be returning null (i.e. was detecting out-of- > >>stack-space). > >> > >>Now I discover that the BSTR itself was also NULL so that makes sense. > >> > >>I presume what happens is all that magic that traps the segment > >>violation on strlen(0) didn't quite handle whatever optimised code was > >>being generated for our case. > >> > >>However what I am also investigating is where the original NULL BSTR > >>came from; possibly a defect in VariantChangeTypeEx. > >> > > > > > > Actually VariantChangeType was returning E_INVALIDPARAM and a VT_EMPTY > > and the caller wasn't checking the result. > > > > However I think VariantChangeType was wrong in this case. > > > > > >>Bill > >> > >> > >> > > > > > > So. > > > > 1. Am I misunderstanding something about the tests these days? > > > > (I am about to add two edge tests on SystemTimeToFileTime in time.c and > > GetDateFormatW in locale.c) > > > > I go into dlls/kernel32/tests and make tests and it fails (change.c, > > locale.c) > Did you try to run make test a second time? Sometimes that makes it go > further.
Yes. Even make clean. > > > Should that disconcert me? > Yes and no. The theory says that the tests should run on everybodies > computer out of the box. The practice disagrees with this and afair only > on Alexandre's computer all tests succeed. We should fix that and from > time to time somebody tries to do it but it's no sexy work so that > effort dies pretty soon. > What i do is to run the tests on an origin Wine checkout and then on my > modified tree and see if i get any additional failures/successes. > That's what I figured. > > 2. How to fix the VarBstrFromDate? > > > > VarBstrFromDate(-657434.0 (DATE_MIN), 0x409, 0x80000000, wherever) > > fails because VariantTimeToSystemTime successfully converts that to > > 1/1/100 but then VarBstrFromDate tries to format that using > > GetDateFormat, which is not feasible because the SystemTime is out of > > range. > > > > Is there an existing low level routine that can handle the conversion > > for such a small date > Add a test for the VarBstrFromDate(-657434.0 ... call and see how > Windows handles that. When you know the outcome you'll know how to fix it. Invalid assumption. Knowing the problem doesn't automatically give us the answer. > I know the outcome; for the flags and lcid I was using it is 1/1/100 (n.b. 3 digit year). That is in the patch I submitted yesterday. What I am after is the most efficient way to implement the fix while maintaining compatibility and not messing up the code base. How does this sound? Add an argument to NLS_GetDateTimeFormatW/A to flag whether the systemtime should be constrained to >= 1/1/1601 and add a "wine" routine that calls it with that flag set to NO. and use that. In that way we can keep the formatting code in one place and still get the extended date range that oleaut32 needs. > bye > michael > Bill
