Надо кильнуть MFC

Вот переписал прогу с MFC на чистый API (часа за 3 ). Никаких MFC-ных h-файлов. Но прога ни на каплю не уменьшилась в размерах, да и в памяти почти столько-же занимает (2240K по TaskManager). Мож я чего недоубил в настройках проекта??? "No use MFC" стоит.

Глупый вопрос - а stdafx.h поправил?

В первую очередь.
//--------- stdafx.h ---------------
if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
#include <windows.h>
#include <Atlbase.h> //реестр
#include <Winsock2.h> //сокеты
#include <mmsystem.h> //PlaySound()
#include <iostream>
#include <stdio.h>
#include <Ras.h> //RASAPI
#include <Raserror.h> //RASAPI
//--------------------------------

Хе-хе. Вот это прикол! MFC-ный релиз проект весит 720К, а API-ный 774К! А ведь хотелось наоборот...

А ты чего хотел? Повнимательней посмотри в исходники - там почти через строку ассемблерный код!

Так что, никакого выйгрыша в API нет???

upx тебе поможет. хорошо сжимает файлы...
PS
ну и на фига, вот только переписывать MFC под чистый API?
PPS Happy NY

А хрен его знает. Вот тут недавно говорили что сервисы надо исключительно без MFC ваять. Ну так вот я сервис и переделал. CString поубивал, CApp... А толку вроде никакого нет... :|

Happy NY!

Я тоже тут в каком-то топике писал, что API в настоящее время мало что прибавляют. Я тоже поначалу думал, что на них эффективнее, но вот когда попрактиковался и сравнил характеристики проектов на чистых API и MFC dinamic library, то оказалось, что выигрыш весьма сомнителен и явно не стоит овчинка выделки. Тем более, что многие почему-то забывают, что классы MFC реализуют важную концепцию "захвата ресурсов при инициализации", и ещё деструкторы сами освобождают ресурсы. Те, кто уверен, что они на API корректно освобождают свои ресурсы, проверьте любую более-менее сложную прогу с BoundsChecker, и выяснится, что там куча утечек... MFC позволяет избежать этого даже чайникам. Но и здесь ждут подводные камни. Примерчик:
CPaintDC dc(this); // device context for painting

CBrush brBack(RGB(200, 200, 200));
CBrush* pBrOld = dc.SelectObject(&brBack);
dc.SelectStockObject(NULL_PEN);
CRect rc;
GetClientRect(&rc);
dc.Rectangle(rc.left,rc.top,rc.right+1,rc.bottom+1);
HICON hIcon = ((CLCDlg*)(AfxGetApp()->GetMainWnd()))
->CreateLangCorrespondingSystrayIcon();
DrawIconEx(dc.GetSafeHdc(), 1, 1, hIcon, GetSystemMetrics(SM_CXSMICON),
GetSystemMetrics(SM_CYSMICON), 0, 0, DI_NORMAL);
DestroyIcon(hIcon);
//dc.SelectObject(pBrOld);
Вот если pBrOld не учесть, то выйдет приличная утечка ресурсов, через 4 часа работы вешающая 98. А на API ещё больше геморроя!

Код в динамик МФЦ частично упрятан в ДЛЛе. Т.е на чистом АПИ та же прога может весить и поболее...
но меньше, чем статик МФЦ (вопрос)?

Се ля ви, похоже, придётся нам привыкать такскать с собой DLL. Да и MFC42.DLL явно _более_ распространена, чем VCL, тем более там с каждой версией компилеров разные DLL. Начиная с 98 SE нормальная MFC42.dll в комплекте ОС, а кто ещё юзат VC 5, с ней проблем вообще нет.
А статическая компоновка часто ничего не улучшает, в частности, там все DLL типа OLE и т.д. грузятся сразу, в то время как в динамике- по первому использованию функции

Говно вопрос. Я из дистрибутива вообще выкинул _стандартные_ ДЛЛки.