Преобразование кода Win16 C в Win32

Question

В общем, что нужно сделать для преобразования 16-битной программы Windows в Win32? Я уверен, что я не единственный, кто наследует кодовую базу и ошеломлен, обнаружив, что 16-битный код скрывается в углах.

Код, о котором идет речь, - C.

Answer 1

1. Значения wParam и lParam изменились во многих местах. Я настоятельно советую вам быть параноиком и максимально конвертировать, чтобы использовать взломщики сообщений . Они избавят вас от головной боли. Если бы я мог дать вам только один совет, это был бы он.
2. Пока вы используете взломщики сообщений, также включите STRICT. Это поможет вам перехватить кодовую базу Win16, используя int, где она должна использовать HWND, HANDLE или что-то еще. Преобразование их очень поможет с # 9 в этом списке.
3. hPrevInstance бесполезен. Убедитесь, что он не используется.
4. Убедитесь, что вы используете дружественные Юникоду звонки. Это не означает, что вам нужно конвертировать все в TCHAR с, но означает, что вам лучше заменить OpenFile, _lopen и _lcreat на CreateFile, чтобы назвать очевидное
5. LibMain теперь DllMain, а формат библиотеки и соглашения об экспорте отличаются
6. В Win16 не было VMM. GlobalAlloc, LocalAlloc, GlobalFree и LocalFree должны быть заменены более современными эквивалентами. Когда закончите, уберите звонки LocalLock, LocalUnlock и друзьям; теперь они бесполезны. Не то чтобы я мог представить, что ваше приложение делает это, но убедитесь, что вы не зависите от WM_COMPACTING, пока вы там.
7. Win16 также не имел защиты памяти. Убедитесь, что вы не используете SendMessage или PostMessage, чтобы отправлять указатели на окна вне процесса. Вам нужно будет переключиться на более современный механизм IPC, такой как каналы или отображенные в память файлы.
8. В Win16 также отсутствовала вытесняющая многозадачность. Если вы хотите получить быстрый ответ из другого окна, было бы здорово позвонить по номеру SendMessage и дождаться обработки сообщения. Это может быть плохой идеей сейчас. Подумайте, не лучше ли PostMessage.
9. Изменение указателя и целочисленных размеров. Не забывайте проверять, где бы вы ни читали или записывали данные на диск - особенно, если это структуры Win16. Вам нужно будет вручную переделать их, чтобы обработать более короткие значения. Опять же, наименее болезненным способом борьбы с этим будет использование взломщиков сообщений, где это возможно. В противном случае вам придется вручную выследить и преобразовать int в DWORD и т. Д., Где это применимо.
10. Наконец, когда вы прибегли к очевидному, рассмотрите возможность включения 64-битных проверок компиляции. Многие проблемы, возникающие при переходе с 16 на 32 бита, такие же, как при переходе с 32 на 64, и Visual C ++ на самом деле довольно умный в наши дни. Вы не только поймете некоторые проблемы; Вы также подготовитесь к возможной миграции на Win64.

---

РЕДАКТИРОВАТЬ : Как указывает @ChrisN, официальное руководство по переносу приложений Win16 на Win32 по-прежнему доступно, и оба излагаются и дополняют мои пункты выше.

Answer 2

Помимо правильного построения среды сборки, вот несколько особенностей, которые вам нужно будет рассмотреть:

1. структуры, содержащие целые числа, должны будут измениться на короткие или расширены с 16 до 32 бит. Если вы измените размер структуры, и она будет загружена / сохранена на диск, вам потребуется записать код обновления файла данных.

2. Данные для каждого окна часто сохраняются с помощью дескриптора окна, используя GWL_USERDATA. Если вы расширите некоторые данные до 32 бит, ваши смещения изменятся.

3. Структуры POINT & SIZE в Win32 являются 64-битными. В Win16 они были 32-битными и могли быть возвращены как DWORD (вызывающая сторона делит возвращаемое значение на два 16-битных значения). Это больше не работает в Win32 (то есть Win32 не возвращает 64-битные результаты), и функции были изменены, чтобы принимать указатели для хранения возвращаемых значений. Вам нужно будет отредактировать все это. Это влияет на такие API, как GetTextExtent. Эта же проблема относится и к некоторым сообщениям Windows.

4. Использование файлов INI не рекомендуется в Win32 в пользу реестра. Пока функции файла INI все еще работают, вам нужно быть осторожным с проблемами Vista. 16-битные программы часто сохраняют свой INI-файл в системном каталоге Windows.

Это лишь некоторые из проблем, которые я могу вспомнить. Прошло уже более десяти лет с тех пор, как я занимался портированием Win32. Как только вы входите в это, это довольно быстро. Каждая кодовая база будет иметь свое «чувство», когда дело доходит до портирования, к которому вы привыкнете. По пути вы, вероятно, даже найдете несколько ошибок.

Answer 3

В статье есть полное руководство Перенос 16-битного кода на 32-битную Windows в MSDN.

Answer 4

Исходный win32 sdk имел инструмент, который сканировал исходный код и помечал строки, которые нужно было изменить, но я не могу вспомнить название инструмента.

Когда мне приходилось делать это в прошлом, я использовал технику грубой силы, т.е. 1 - обновить make-файлы или среду сборки, чтобы использовать 32-битный компилятор и компоновщик. По желанию, просто создайте новый проект в вашей IDE (я использую Visual Studio) и добавьте файлы вручную.

2 - сборка

3 - исправить ошибки

4 - повторяйте 2 и 3, пока не закончите

Трудность процесса зависит от приложения, которое вы переносите. Я конвертировал 10 000 строчных программ за час и 75 000 строчных программ менее чем за неделю. У меня также было несколько небольших утилит, от которых я только что отказался и переписал (в основном) с нуля.

Answer 5

Договорились, что компилятор, вероятно, отлавливает большинство ошибок. Также, если вы используете указатели «ближний» и «дальний», вы можете удалить эти обозначения - указатель - это просто указатель в Win32.

Answer 6

Я согласен с Аланом, что метод проб и ошибок, вероятно, лучший способ.

Вот несколько хороших советов .