4

How can I generate the code for both x86 and x64 using MIDL?

I've created an IDL file in Visual Studio 2010, and when I compile the product as in x86 mode and afterwards in x64 I've got to "touch" the IDL file so it will regenerate the code relevant for x64. Can I somehow tell MIDL to generate both codes into the same file?

Dig
  • 3,850
  • 3
  • 27
  • 33
  • I'm not sure if I unterstood your question right, but if you talk about .net and the target system try to use AnyCPU than the assambly works on every platform. – rekire Aug 25 '12 at 19:26
  • I'm talking about c/c++ code. Not .net. – Dig Aug 25 '12 at 19:31
  • Just create a x86 and 64bit configurations and build your project[s] in both. You will get separate set of binaries for every configuration. Artifacts produced by midl itself (.c, .h, .tlb etc), are not bound to CPU. However, there is a command line key for midl: `/env win32 | x64` – tuxSlayer Sep 04 '12 at 22:24
  • Ah.. sorry.. just read the question once more ;) Try to put x86 | x64 output into different dirs :) this shall help – tuxSlayer Sep 04 '12 at 22:25
  • I have a similar problem ... did you find any solution? The answers below are not useful at all. – Richard Anthony Hein Jan 28 '14 at 15:44
  • This may be the only practical solution: http://stackoverflow.com/q/221254/13131 – Richard Anthony Hein Jan 28 '14 at 15:48

3 Answers3

1

An IDL file defines an interface, that interface could use 64-bit platform features or 32-bit platform features. An IDL can be used to generate a stub; if an interface doesn't have 32-bit-platform-specific definitions or 64-bit-platform-specific definitions, supposedly on stub can be generated (i.e. one IDL file). But, that depends on the interfaces that you're exposing. Short answer: if you define you interfaces to be 32-bit and 64-bit compatible you shouldn't need two different IDL files--otherwise you need two different IDL files.

Without knowing what "touch" (which generally means updating the date/time of a file, w.r.t. software engineering) means, it's hard to say specifically what you need to do.

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • By touch, he means delete, move, rename, whatever, to force a rebuild of the *.c output. The problem is proxies, they are not the same between 32-bit and 64-bit. – Richard Anthony Hein Jan 28 '14 at 15:47
0

If you're referring to the files under the Generated Files folder, you won't see them change if all you change is the target platform (well, unless you've placed #ifdef blocks in the IDL that use platform-specific defines). Remember, the output of MIDL is source code, not binaries. The names of the datatypes used in the generated code won't change, so the output from MIDL will be the same even though the machine architecture the compiler is targeting is different.

You can verify this by making copies of the XXX_i.h and XXX_i.c files and comparing them between platforms. To do this, Build, make copies, Rebuild, then compare the files; the only thing that should be different is the timestamp.

So, to get back to your original question: you're already doing it!

Andy Hopper
  • 3,618
  • 1
  • 20
  • 26
  • The *_i.c files may differ only by timestamp, but proxies are a different story, they are very different and the linker fails when you switch configurations unless you rebuild, or delete the *.c files which forces a rebuild. This is bad. – Richard Anthony Hein Jan 28 '14 at 15:46
0

I know this is an old question, but should anyone else hit this here is how I solved it.

In the project containing the IDL file, I added a pre-build event to all platforms and configurations that deleted the MIDL output files like this...

if exist $(ProjectName).h del $(ProjectName).h
if exist $(ProjectName)_i.c del $(ProjectName)_i.c
if exist $(ProjectName)_p.c del $(ProjectName)_p.c

I could have gotten away with just deleting the proxy (_p) file as that's the only platform specific MIDL generated file.

If your proxy stub source files have different names or extensions, use those.

TheSteveMadden
  • 1