Здравствуйте IT, Вы писали:

IT>А в твоём случае разве не нужно этого делать?
В том то и дело, что не надо. Надо просто добавить в тело функции два макроса.

Был у меня обычный код:

void CClass::Func()
{
  не_важный_код;
  важный_код;
  не_важный_код;
}

Если мы кодируем на уровне функции, то это превратиться во что-то такое:

#pragma code_seg("Func0c")
void Func0c(куча_входных_параметров, куча_выходных_параметров)
{
  важный_код;
}
#pragma code_seg()

void Func0(куча_входных_параметров, куча_выходных_параметров)
{
  расшифровать(Func0c);
  Func0c(куча_входных_параметров, куча_выходных_параметров);
  зашифровать(Func0c);
}

void CClass::Func()
{
  не_важный_код;
  Func0(куча_входных_параметров, куча_выходных_параметров);
  не_важный_код;
}

Что конечно не улучшает читаемость, сопровождаемость и безошибочность кода.

А так же надо как-то сказать внешнему паковщику, что Func0c надо зашифровывать, а Func0 — не надо. Но эту проблему можно победить, если давать хитрые имена, типа, Func0_Crypt_It.

DG>>2. Писать внешнюю прогу которая будет разбираться с map-ом, code-seg-ментами и т.д.

IT>По-моему, это проще, чем лепить асемблерные вставки :)
Так программер вставляет только два макроса, все остальное не его дело.

А если не нравится что увеличивается exe-шник, то на это есть 2 возражения:
1. В нынешних приложениях бОльшую часть занимает не код, а ресурсы: картинки, текст, музыка, мультфильмы. Да и в целом не важно, сколько занимает приложение 20М или 40М. Все равно его по dial-up-у не выкачаешь. А все остальные причины уменьшения размера кода не понятны. Вон Microsoft совсем отказалась от разделяемого кода, теперь для каждого приложения свои версии общих dll-ек.

2. В крайнем случае, ассемблерные вставки индикации кодируемого блока заменять внешним пакером на код динамической распаковки/запаковки.