Dan Hipschman wrote:
> This adds the objidl proxy to oleaut32. It also updates DllGetClassObject
> to fall back on OLEAUTPS_DllGetClassObject. This is basically what would
> happen if we had a dlldata.c file for oleaut32, but that's impossible
> since oleaut32 is too special a case.
>
> ---
> .g
Hi,
> I see, I did not notice the _-versions where inlined. But since
> all uses seem to be in the same file (is this correct), can't
> we just mark the regular ones as extern inline?
I didn't put all the functions in the same file, because a) they
split pretty logically into groups of 12-20 func
On Mon, Oct 06, 2003 at 11:51:22AM -0400, Dimitrie O. Paun wrote:
> On Mon, 6 Oct 2003, Jon Griffiths wrote:
>
> > Size and speed.
> >
> > The inlined versions are to meant to be used within the variant code,
> > the biggest user being the coercion functions when I get round to
> > updating them
Hi Dimitrie,
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> We don't seem to pass any additional info to _VarDecFromUI1, why
> not simply get rid of it, and implement stuff in the real
> VarDecFromUI1?
Size and speed.
The inlined versions are to meant to be used within the variant code,
the
On Mon, 6 Oct 2003, Jon Griffiths wrote:
> Size and speed.
>
> The inlined versions are to meant to be used within the variant code,
> the biggest user being the coercion functions when I get round to
> updating them (after the low level stuff). The code for the vast
> majority of conversions is
On Mon, 6 Oct 2003, Jon Griffiths wrote:
> Hi,
>
> Part 3 of oleaut32 updates.
Hi Jon,
Cool stuff, but I don't understand why we have all these forwards:
+HRESULT WINAPI VarDecFromUI1(BYTE bIn, DECIMAL* pDecOut)
+{
+ return _VarDecFromUI1(bIn, pDecOut);
+}
We don't seem to pass any addition
