Re: How to link to older C code without IDL conflicts?
From: Ronald Laeremans [MSFT] (ronaldl_at_online.microsoft.com)
Date: 02/17/04
- Next message: Hendrik Schober: "Re: I wasn't expected that !"
- Previous message: Ronald Laeremans [MSFT]: "Re: post vs. pre incrementation"
- In reply to: TOM: "How to link to older C code without IDL conflicts?"
- Next in thread: TOM: "Re: How to link to older C code without IDL conflicts?"
- Reply: TOM: "Re: How to link to older C code without IDL conflicts?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 17 Feb 2004 01:04:03 -0800
Compile with /d1PrivateNativeTypes to get back to the VC 2002 behavior in
this respect. There is a KB article describing the issue (googling for the
flag name should find it) along with a few posts by myself. In the Whidbey
version of VC we will be providing a method to control visibility of native
types individually.
Ronald Laeremans
Visual C++ team
"TOM" <noname@noprovider.nodomain> wrote in message
news:eLOmzlx8DHA.2404@TK2MSFTNGP12.phx.gbl...
> I am using C++.NET 2003. The appplication requires calling a device (a USB
> driver) that was compiled under C++ 6.0, and distributed as a binary (a
.sys
> file) by the manufacturer. Some of the data structures are fairly
complex,
> and a couple header files from the Windows DDK are needed to establish the
> variable types and structures needed to call the USB functions.
>
> The problem is that an #include of the necessary DDK headers within C++
> auto-generated Windows forms modules fails to compile due to numerous
> conflicts between the (new) and the (old) IDLs.
>
> In .C++.NET 2002 I was able to hold the structures as part of the wrapper
> module, as long as they were not part of a function or method interface.
> This broke in .NET 2003, and now I have to hide the offending data
> structures inside the methods as automatic variables so that they never
are
> exposed outside the module. I cannot make them part of the wrapper
> interface, since that requires that auto-generated modules to have to
> #include the DDK headers. Within the wrapper module, I use P/Invoke to
call
> the low level USB calls in the .SYS module.
>
> So, it works, but the wrapper is very unelegant. It cannot save device
state
> between calls since that would require declaring a structure and #includes
> which would then break all the other modules.
>
> Is there another approach that would allow use of these proprietary USB
data
> structures (and the necessary #includes from the DDK) that would allow
> static varables that are not exposed outside the wrapper module?
>
> -- Tom
>
>
>
>
>
- Next message: Hendrik Schober: "Re: I wasn't expected that !"
- Previous message: Ronald Laeremans [MSFT]: "Re: post vs. pre incrementation"
- In reply to: TOM: "How to link to older C code without IDL conflicts?"
- Next in thread: TOM: "Re: How to link to older C code without IDL conflicts?"
- Reply: TOM: "Re: How to link to older C code without IDL conflicts?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
