Как создать код x86 и x64, используя MIDL?

Как я могу сгенерировать код для x86 и x64, используя MIDL?

Я создал файл IDL в Visual Studio 2010, и когда я компилирую продукт в режиме x86, а затем в режиме x64, мне нужно "прикоснуться" к файлу IDL, чтобы он перегенерировал код, соответствующий для x64. Могу ли я каким-то образом указать MIDL сгенерировать оба кода в один и тот же файл?


midl
person Dig    schedule 25.08.2012    source источник
comment
Я не уверен, правильно ли я понял ваш вопрос, но если вы говорите о .net и целевой системе, попробуйте использовать AnyCPU, тогда сборка работает на каждой платформе.   -  person rekire    schedule 25.08.2012
comment
Я говорю о коде c/c++. Не .нет.   -  person Dig    schedule 25.08.2012
comment
Просто создайте конфигурации x86 и 64bit и создайте свой проект в обоих. Вы получите отдельный набор двоичных файлов для каждой конфигурации. Артефакты, создаваемые самим midl (.c, .h, .tlb и т. д.), не привязаны к процессору. Однако для midl есть ключ командной строки: /env win32 | x64   -  person tuxSlayer    schedule 05.09.2012
comment
Ах.. простите.. просто перечитайте вопрос еще раз ;) Попробуйте поставить x86 | вывод x64 в разные каталоги :) это должно помочь   -  person tuxSlayer    schedule 05.09.2012
comment
У меня похожая проблема... Вы нашли какое-то решение? Ответы ниже совершенно бесполезны.   -  person DoctorFoo    schedule 28.01.2014
comment
Это может быть единственным практическим решением: stackoverflow.com/q/221254/13131   -  person DoctorFoo    schedule 28.01.2014

Ответы (3)


arrow_upward
0
arrow_downward

Файл IDL определяет интерфейс, этот интерфейс может использовать функции 64-битной платформы или функции 32-битной платформы. IDL можно использовать для создания заглушки; если интерфейс не имеет определений, специфичных для 32-битной платформы, или определений, специфичных для 64-битной платформы, может быть сгенерирован предположительно на заглушке (т. е. один IDL-файл). Но это зависит от интерфейсов, которые вы предоставляете. Краткий ответ: если вы определяете интерфейсы как 32-битные и 64-битные совместимые, вам не нужны два разных файла IDL - в противном случае вам понадобятся два разных файла IDL.

Не зная, что означает «прикосновение» (что обычно означает обновление даты/времени файла в отношении разработки программного обеспечения), трудно сказать конкретно, что вам нужно сделать.

person Peter Ritchie    schedule 04.09.2012
comment
Под прикосновением он имеет в виду удаление, перемещение, переименование, что угодно, чтобы принудительно перестроить вывод *.c. Проблема в прокси, они не одинаковы между 32-битными и 64-битными. - person DoctorFoo; 28.01.2014

arrow_upward
0
arrow_downward

Если вы имеете в виду файлы в папке «Сгенерированные файлы», вы не увидите, как они изменяются, если все, что вы меняете, — это целевая платформа (ну, если вы не поместили блоки #ifdef в IDL, которые используют специфичные для платформы определения) . Помните, что результатом MIDL является исходный код, а не двоичные файлы. Имена типов данных, используемых в сгенерированном коде, не изменятся, поэтому вывод MIDL будет таким же, даже если архитектура компьютера, на которую ориентируется компилятор, отличается.

Вы можете убедиться в этом, сделав копии файлов XXX_i.h и XXX_i.c и сравнив их между платформами. Для этого Соберите, сделайте копии, Пересоберите, затем сравните файлы; единственное, что должно быть другим, это метка времени.

Итак, возвращаясь к вашему первоначальному вопросу: вы уже это делаете!

person Andy Hopper    schedule 06.09.2012
comment
Файлы *_i.c могут отличаться только отметкой времени, но прокси-серверы — это отдельная история, они очень разные, и компоновщик дает сбой при переключении конфигураций, если вы не перестраиваете или не удаляете файлы *.c, которые вызывают перестроение. Это плохо. - person DoctorFoo; 28.01.2014

arrow_upward
0
arrow_downward

Я знаю, что это старый вопрос, но если кто-то еще ударит по этому поводу, вот как я его решил.

В проекте, содержащем файл IDL, я добавил событие предварительной сборки для всех платформ и конфигураций, которые удаляли выходные файлы MIDL, подобные этому...

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

Я мог бы просто удалить файл прокси (_p), поскольку это единственный файл, созданный MIDL для конкретной платформы.

Если исходные файлы ваших прокси-заглушек имеют другие имена или расширения, используйте их.

person TheSteveMadden    schedule 04.02.2016