*.idl: Use correct type for BSTR strings in the defaultvalue() statements.

[Nikolay Sivov]

On Friday, 6 November 2015, Dmitry Timoshkov <dmitry at baikal.ru> wrote:

> Nikolay Sivov <bunglehead at gmail.com <javascript:;>> wrote:
>
> > > This matches midl/PSDK syntax, and allows to use Wine headers for
> compiling
> > > applications with a C++ win32/win64 compiler. In order to be usable by
> C++
> > > unix compilers widl needs to emit appropriate statically initialized
> WCHAR
> > > strings, but that's a different problem, currently the generated Wine
> headers
> > > with default(BSTR) statements can't be used with C++ at all.
> > >
> >
> > Where do you see this? Mshtml.idl from Windows 10 SDK doesn't use this
> > notation, and in fact only fsrm*.idl files do, so it's not a common
> > practice.
>
> midl has a built-in "magic" for handling defaultvalue() for BSTR strings,
> that's why PSDK headers are not consistent in that regard: some of them
> use defaultvalue("") while others use defaultvalue(L""). But using this
> magic is not necessary if the header uses appropriate type for the default
> value. So fixing an .idl should be preferrable IMO to adding support for
> magic behaviour to widl.

All headers except about 4 we don't have, use it like we do. All the magic
is to add a prefix during header generation, it doesn't look that hard, and
will get consistent result for idls that don't cone with wine.

>
> > Generated headers should use L"", like you said. But only in
> > case of empty strings.
>
> midl always generates L"" syntax, regardless whether it's an empty string
> or not.


I don't see this in mshtml.h when default value is not an empty string.

>
> > Also leaving this broken for everything that's
> > not PSDK compiler doesn't sound right.
>
> mingw/borland/any other wine32 compiler also benefit from this change.
> It doesn't make sense to have it broken at all, but at least fixing
> the .idl side of breakage should be considered as the first step, and
> make the generated headers actually usable for the win32 platform.
>
> Since it only affects cpp case, that we don't use, how does it help
building wine?

And more importantly what will happen to gcc if you try to build with this
addition?

> --
> Dmitry.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20151106/74481daa/attachment.html>