Вопрос

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

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

Это было полезно?

Решение

  1. Значения wParam и lParam изменились во многих местах.я сильно призываем вас быть параноиками и стараться как можно больше использовать взломщики сообщений.Они избавят вас от головной боли.Если бы я мог дать вам только один совет, то это был бы он.
  2. Если вы используете программы для взлома сообщений, также включите STRICT.Это поможет вам уловить базу кода Win16, используя int где его следует использовать HWND, HANDLE, или что-то другое.Их преобразование очень поможет номеру 9 в этом списке.
  3. hPrevInstance бесполезно.Убедитесь, что он не используется.
  4. Убедитесь, что вы используете вызовы, поддерживающие Юникод.Это не значит, что вам нужно конвертировать все в TCHARs, но означает, что вам лучше заменить 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 все еще доступен, и оба они уточняют и дополняют мои замечания выше.

Другие советы

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

  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.Как только вы вникнете в это, это произойдет довольно быстро.Каждая база кода будет иметь свои собственные ощущения при портировании, к которым вы привыкнете.Вероятно, по пути вы даже обнаружите несколько ошибок.

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

В исходном пакете Win32 SDK был инструмент, который сканировал исходный код и помечал строки, которые необходимо изменить, но я не могу вспомнить название этого инструмента.

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

2 - построить

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top