On Friday 02 September 2005 19:53, Dmitry Timoshkov wrote:
> There are 2 problems with this patch: you forgot to provide a definition
> for EXTERN_C,
I "forgot" nothing. It's defined in both basetyps.h and winnt.h, which is
sufficient for it to have built the whole of WINE after a "make clean" a
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> --- include/guiddef.h (revision 26053)
> +++ include/guiddef.h (local)
> @@ -35,12 +35,18 @@
> #undef DEFINE_GUID
>
> #ifdef INITGUID
> +#ifdef __cplusplus
> #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
> +EXTERN_C
On Thu, 1 Sep 2005 14:30, Steven Edwards wrote:
> Well yes some of us do. I work to keep the Wine SDK compatible with
> the PSDK because we have developed a MSVC backend in the ReactOS build
> system and one day (God willing) I will get the ReactOS Project to use
> Wine headers rather than w32api
Hi,
On 8/31/05, Troy Rollo <[EMAIL PROTECTED]> wrote:
> 'extern "C"' on a non-member non-function global is perfectly meaningless to
> most C++ compilers. As far as I am aware, only MSVC++ mangles global
> variables. The 'extern "C"' is thus there to deal with a broken feature of
> the MSVC++ comp
On Wednesday 31 August 2005 19:10, Dmitry Timoshkov wrote:
onst GUID name
>
> PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern
> "C"'. We have to use the same approach.
Why? We have to get the same *result*, but that doesn't mean we have to have
the same *code*.
'extern "
> takes us into more dangerous territory (see Feist Publications v Rural
> Telephone Service).
Correction... Computer Associates v Altai (lesson: don't sent email requiring
some precision before being fully awake).
--
[EMAIL PROTECTED] - Sydney, Australia
pgpXTslsdgefs.pgp
Description: PGP
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> #ifdef INITGUID
> +#ifdef __cplusplus
> #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
> +extern const GUID name = \
> + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
> +#else
> +#define DEFINE_GUID(name, l, w1,
