Здравствуйте, Edvard Grieg, Вы писали:
OD>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>А вчем проблема их отдельно прилинковать? EG>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете?
EG>Кстати скринсейвер longhorn-a если кто посмотрит самый обычный PEEXE файл обычнее некуда работает под W2K без всякого NET, но тем неменее meta-данные содержит
Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
RB>Да никто не мешает. Более того, все так и происходит.
RB>PE-шник, генерируемый в ".net" — это самый обычный PE-шник, у которого вначале RB>идет загрузка mscoree и передача управления в эту dll. А та уже подгружает RB>ресурсы из PE-шника, читает байт-код и пр. хрень.
Но это я и так понял:
А гдеж тогда храниться SEH,PEB исполнимого файла .NET?
У обычного PE -процесса fs:[xxx] , там и пеб и цех.
Загрузчик все будет интерпретировать как и раньше?
И еще а как заполняется для .NET PEEXE Import Adress Table загрузчиком или
она уже будет заполнена? Или и так и эдак возможно как и раньше?
Здравствуйте, SiAVoL, Вы писали:
SAV>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Именно так и есть,т.е. .NET я не устанавливал я выше об этом писал. SAV>тогда все ясно EG>>Просто негде мне его взять, SAV>.NET Framework 1.1 SAV>.NET Framework 1.1 SDK SAV>а что бы не гадать на кофеной гуще как это все работает, можно слить еще и Rotor — реализация .NET от микросовта в исходниках, в общем скачай будет интересно. SAV>А что бы посмотреть на другие реализации можно зайти на проект Mono, тоже в исходниках. Кстати у них недавно первый релиз был EG>>Но мне кажется что основа всего этого безобразия mscoree.dll. SAV>основа то основа, но несколько низкоуровневая EG>>Longhorn -поставить негде чтобы расковырять. SAV>для НЕТа его ставить совсем необязательно. Рог он где-то там за горизонтом, а дотНЕТ уже здесь с нами
Большое спасибо
Попробую у когонибудь с хорошим каналом это вытянуть
OD>Кроме того, обратите внимание, что Вы постоянно употребляешь слова "не OD>понимаю", "кажется" и т.д. Так вот — судя по Вашим сообщениям, Вы действительно OD>не понимаете (даже приблизительно), о чём идёт речь, и Вам многое кажется. OD>Наверное, неплохо было бы и "поиграться" с продуктом, а потом делать какие-то OD>выводы (мол, "безобразие"... ). Получается как в известной фразе: "Я Солженицына OD>не читал, но знаю, что он — подлец".
Дык я сюда и зашел чтобы поспрашивать насчет всего этого "безобразия" и понять как это устроено хоть приблизительно. Если к примеру комуто попадется ntoskrnl.exe и hal.dll я предполагаю что этот кто-то сможет сделать выводы относительно win2k в целом,и эти выводы небудут той самой "волосатой змеей".
Что меня интересует:
1) Исчезнут ли win32 api с появлением .net.
2) Изменится ли объкт ядра "process"
3) что станет с system и idle
4) Зачем .NET испозьзует win32 , а не к примеру Native API.
Ответ на эти вопросы для меня многое бы прояснил.
Здравствуйте, OldDino, Вы писали:
OD>Здравствуйте, Edvard Grieg, Вы писали:
OD>>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>>А вчем проблема их отдельно прилинковать? EG>>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
OD>Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете?
Линкер можно и самому написать, впрочем и собрать PEEXE.
EG>>Кстати скринсейвер longhorn-a если кто посмотрит самый обычный PEEXE файл обычнее некуда работает под W2K без всякого NET, но тем неменее meta-данные содержит
OD>Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
Это было не заявление а вопрос вообщето.
я повторюсь что не експерт в .net просто зашел поспрошать.
Но из под dosa как впрочем из под чего угодно можно скомпилировать PEEXE Win32 .
я не заявлял что без .net приложения .net запустяться, я предполагаю что можно создать приложение
на основе обычного PEEXE которое сможет полноценно работать с .NET.
Здравствуйте, Edvard Grieg, Вы писали:
EG>Что меня интересует: EG>1) Исчезнут ли win32 api с появлением .net. EG>2) Изменится ли объкт ядра "process" EG>3) что станет с system и idle EG>4) Зачем .NET испозьзует win32 , а не к примеру Native API. EG>Ответ на эти вопросы для меня многое бы прояснил.
Думаю, Вы делаете ту же ошибку, какую когда-то сделал я, а именно — роетесь в мелочах, не понимая даже предназначения .NET'а. Другими словами, за деревьями не видите леса. Поэтому позволю себе дать Вам совет — постарайтесь всё же понять идеологию .NET в целом. Просто почувствовать её. Многое, наверное, станет на свои места.
OD>>>>Да, разумеется, можно написать и на Delphi 3.0. А, скажем, метаданные будут OD>сгенерированы Святым Духом.
EG>>>А вчем проблема их отдельно прилинковать? EG>>>Или этот кусочек XML кода не прилинкуется к PEEXE обычному?
OD>>Н-да... Значит, по-Вашему, метаданные — это XML? Тяжело... А чем они линкуются, не подскажете? EG>Линкер можно и самому написать, впрочем и собрать PEEXE.
OD>Знаете, Эдвард Григ, здесь Вы просто несёте чушь. Откровенную чушь. После таких заявлений можно сказать, что и Windows-программы под DOS'ом без Windows идут...
Удивительно если бы я эту чушь не нес
Посмотрите название темы, я кажется спрашивал что такое dot.net это значит что я имею весьма слабое об этом представление.
Честно говоря неожидал такой агрессии в свой адресс.
OD>Всё. Наповал! Замолкаю.
я конечно понимаю что новички всегда всех смешат но
Описать секции кода, данных и т.д. соответствующими структурами,
Описать Optional Header со всеми причиндалами.
Заполнить LookUp Table, и т.д.
вот пример того как можно прочитать PEEXE структуры,
ypedef struct _IMPORT_LOOKUP
{
WORD HINT;
char HintName[MAX_PATH];
}IMPORT_LOOKUP, *PIMPORTLOOKUP;
typedef struct _DOS_HEADER { // DOS .EXE çàãîëîâîê
WORD e_magic; // ìàãè÷åñêîå ÷èñëî
WORD e_cblp; // êîëè÷åñòâî áàéò íà ïîñëåäíåé ñòðàíèöå ôàéëà
WORD e_cp; // êîëè÷åñòâî ñòðàíèö â ôàéëå
WORD e_crlc; // Relocations
WORD e_cparhdr; // ðàçìåð çàãîëîâêà â ïàðàãðàôàõ
WORD e_minalloc; // Minimum extra paragraphs needed
WORD e_maxalloc; // Maximum extra paragraphs needed
WORD e_ss; // íà÷àëüíîå ( îòíîñèòåëüíîå ) çíà÷åíèå ðåãèñòðà SS
WORD e_sp; // íà÷àëüíîå çíà÷åíèå ðåãèñòðà SP
WORD e_csum; // êîíòðîëüíàÿ ñóììà
WORD e_ip; // íà÷àëüíîå çíà÷åíèå ðåãèñòðà IP
WORD e_cs; // íà÷àëüíîå ( îòíîñèòåëüíîå ) çíà÷åíèå ðåãèñòðà CS
WORD e_lfarlc; // àäðåñ â ôàéëå íà òàáëèöó ïåðåàäðåñàöèè
WORD e_ovno; // êîëè÷åñòâî îâåðëååâ
WORD e_res[4]; // Çàðåçåðâèðîâàíî
WORD e_oemid; // OEM identifier (for e_oeminfo)
WORD e_oeminfo; // OEM information; e_oemid specific
WORD e_res2[10]; // Çàðåçåðâèðîâàíî
DWORD e_lfanew; // àäðåñ â ôàéëå íîâîãî .exe çàãîëîâêà
} DOS_HEADER, *PDOS_HEADER;
typedef struct _OBJECT_ENTRY
{
char Object_Name[8];
union {DWORD PhisicalAddress;
DWORD VirtualSize;
}Misc;
DWORD VirtualAddress;
DWORD SizeOfRawData;
DWORD PointerToRawData;
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORD NumberOfRelocations;
WORD NumberOfLinenumbers;
DWORD Characteristics;
}OBJECT_ENTRY , *POBJECT_ENTRY;
typedef struct _IMPORT_DIRECTORY_ENTRY
{
DWORD ImportLookUp;
DWORD TimeDateStamp;
DWORD ForwardChain;
DWORD NameRVA;
DWORD AddressTableRVA;
}IMPORT_DIRECTORY_ENTRY , *PIMPORT_DIRECTORY_ENTRY;
typedef struct _PEEXE_header
{
DWORD PE_IDENTIFICATOR;
WORD Machine ; // 4c 01 ; i386
WORD NumberOfSections ; // 00 00 00 00 ; who cares?
DWORD DateTimeStamp;
DWORD PointerToSymbolTable ; // 00 00 00 00 ; unused
DWORD NumberOfSymbols ; // 00 00 00 00 ; unused
WORD SizeOfOptionalHeader ; // e0 00 ; constant
WORD Characteristics ; // 02 01 ; executable on 32-bit-machine
WORD Magic ; //0b 01 ; constant
BYTE MajorLinkerVersion; //00 ; I'm version 0.0 :-)
BYTE MinorLinkerVersion; //00 ;
DWORD SizeOfCode ; //20 00 00 00 ; 32 bytes of code
DWORD SizeOfInitializedData ; //?? ?? ?? ?? ; yet to find out
DWORD SizeOfUninitializedData; //00 00 00 00 ; we don't have a BSS
DWORD AddressOfEntryPoint ; //?? ?? ?? ?? ; yet to find out
DWORD BaseOfCode ; //?? ?? ?? ?? ; yet to find out
DWORD BaseOfData ; //?? ?? ?? ?? ; yet to find out
DWORD ImageBase ; //00 00 10 00 ; 1 MB, chosen arbitrarily
DWORD SectionAlignment ; //20 00 00 00 ; 32-bytes-alignment
DWORD FileAlignment ; //20 00 00 00 ; 32-bytes-alignment
WORD MajorOperatingSystemVersion ; //04 00 ; NT 4.0
WORD MinorOperatingSystemVersion ; //00 00 ;
WORD MajorImageVersion ; //00 00 ; version 0.0
WORD MinorImageVersion ; // 00 00 ;
WORD MajorSubsystemVersion ; // 04 00 ; Win32 4.0
WORD MinorSubsystemVersion ; // 00 00 ;
DWORD Win32VersionValue ; // 00 00 00 00 ; unused?
DWORD SizeOfImage ; // ?? ?? ?? ?? ; yet to find out
DWORD SizeOfHeaders ; // ?? ?? ?? ?? ; yet to find out
DWORD CheckSum ; // 00 00 00 00 ; not used for non-drivers
WORD Subsystem ; // 03 00 ; Win32 console
WORD DllCharacteristics ; // 00 00 ; unused (not a DLL)
DWORD SizeOfStackReserve ; // 00 00 10 00 ; 1 MB stack
DWORD SizeOfStackCommit ; // 00 10 00 00 ; 4 KB to start with
DWORD SizeOfHeapReserve ; // 00 00 10 00 ; 1 MB heap
DWORD SizeOfHeapCommit ; // 00 10 00 00 ; 4 KB to start with
DWORD LoaderFlags ; // 00 00 00 00 ; unknown
DWORD NumberOfRvaAndSizes ; // 10 00 00 00 ; constant
DWORD ExportTableRVA ;
DWORD ExportTableRVASize ;
DWORD ImportTableRVA ;
DWORD ImportTableRVASize ;
DWORD ResourceTableRVA ;
DWORD ResourceTableRVASize ;
DWORD ExceptionTableRVA ;
DWORD ExceptionTableRVASize ;
DWORD SecurityRVA ;
DWORD SecurityRVASize ;
DWORD FixUPRva ;
DWORD FixUPRVASize ;
DWORD DebugTableRVA ;
DWORD DebugTableSize ;
DWORD ImageDescriptionRVA ;
DWORD ImageDescriptionSize ;
DWORD MachineSpecificRVA ;
DWORD MachineDataSize ;
DWORD TlsRva ;
DWORD TlsSize ;
DWORD LoadConfigRVA ;
DWORD ConfigSize ;
BYTE RESERVED0[8] ;
DWORD IATRVA ;
DWORD IATSize ;
BYTE RESERVED1[8] ;
BYTE RESERVED2[8] ;
BYTE RESERVED3[8] ;
}PEHeader, *PPEHeader;
int main(int argc, char* argv[])
{
int LibCount =0;
IMPORT_LOOKUP il;
DOS_HEADER ImageDos;
char LibName[MAX_PATH];
unsigned int ImportCount = 0;
int i = 0;
DWORD Pe;
FILE *f;
PEHeader hpe;
int offset_pe = 0;
int step_next = 0;
ZeroMemory(&Pe,2);
f = fopen(argv[1],"r");
fseek(f,0,SEEK_SET);
fread(&ImageDos,sizeof(DOS_HEADER),1,f);
fseek(f,0,SEEK_SET);
fseek(f,ImageDos.e_lfanew,SEEK_SET);
fread(&hpe,sizeof(PEHeader),1,f);
unsigned long CounterSections = ImageDos.e_lfanew+sizeof(PEHeader);
POBJECT_ENTRY obj_sections = new OBJECT_ENTRY [hpe.NumberOfSections];
ZeroMemory(obj_sections,sizeof(OBJECT_ENTRY)*hpe.NumberOfSections);
for (i=0;i<=hpe.NumberOfSections;i++)
{
fseek(f,0,SEEK_SET);
fseek(f,CounterSections,SEEK_SET);
fread(&obj_sections[i],sizeof(OBJECT_ENTRY),1,f);
CounterSections = CounterSections + sizeof(OBJECT_ENTRY);
}
printf("::Sections Count::\n");
printf("%d\n",hpe.NumberOfSections);
printf("::Sections Names::\n");
for (i=0;i<=hpe.NumberOfSections-1;i++)printf("%s\n",obj_sections[i].Object_Name);
fseek(f,0,SEEK_SET);
fseek(f,hpe.ImportTableRVA,SEEK_SET);
ImportCount = hpe.ImportTableRVASize/sizeof(IMPORT_DIRECTORY_ENTRY);
IMPORT_DIRECTORY_ENTRY *ide = new IMPORT_DIRECTORY_ENTRY[ImportCount] ;
ZeroMemory(ide,hpe.ImportTableRVASize);
fread(ide,hpe.ImportTableRVASize,1,f);
printf("::Library list::\n");
for (i=0;i<=ImportCount-1;i++)
{
if (ide[i].NameRVA)
{
++LibCount;
fseek(f,0,SEEK_SET);
fseek(f,ide[i].NameRVA,SEEK_SET);
fread(&LibName,MAX_PATH,1,f);
printf("%s\n",LibName);
printf("import address table:%d\n",ide[i].AddressTableRVA);
}
}
printf("::Import LookUp ::\n");
DWORD *Addr_Ptr =new DWORD[LibCount];
ZeroMemory(Addr_Ptr,sizeof(DWORD) * LibCount);
for (i=0;i<=LibCount - 1;i++)
{
fseek(f,0,SEEK_SET);
fseek(f,ide[i].ImportLookUp,SEEK_SET);
DWORD Counter_Ptr = ide[i].ImportLookUp;
do{
fseek(f,0,SEEK_SET);
fseek(f,Counter_Ptr,SEEK_SET);
fread(&Addr_Ptr[i],sizeof(DWORD),1,f);
fseek(f,Addr_Ptr[i],SEEK_SET);
ZeroMemory(&il,sizeof(IMPORT_LOOKUP));
fread(&il,sizeof(IMPORT_LOOKUP),1,f);
Counter_Ptr = Counter_Ptr + sizeof(DWORD);
printf("%s :: %d\n ",il.HintName,il.HINT);
}
while (Addr_Ptr[i]);
}
fclose(f);
с помощью этого примитива можно запросто считать OptionalHeader mscode.dll и т.д.
Откомпилировать или слинковать секции и куски можно где угодно, лишь бы компилятор был.
Все что можно прочитать можно и записать.Другое дело что приложение откомпилированное под DOS-oм (для примера) но предназначенное для W2k нельзя будет исполнить и отладить.Но откомпилировать можно.
Здравствуйте, OldDino, Вы писали:
OD>Здравствуйте, Edvard Grieg, Вы писали:
EG>>Что меня интересует: EG>>1) Исчезнут ли win32 api с появлением .net. EG>>2) Изменится ли объкт ядра "process" EG>>3) что станет с system и idle EG>>4) Зачем .NET испозьзует win32 , а не к примеру Native API. EG>>Ответ на эти вопросы для меня многое бы прояснил.
OD>Думаю, Вы делаете ту же ошибку, какую когда-то сделал я, а именно — роетесь в мелочах, не понимая даже предназначения .NET'а. Другими словами, за деревьями не видите леса. Поэтому позволю себе дать Вам совет — постарайтесь всё же понять идеологию .NET в целом. Просто почувствовать её. Многое, наверное, станет на свои места.
Это я и так буду делать. В мелочах роюсь. Всегда. Привычка такая. Просто думаю что в мелочах всегда скрывается чтото важное. Есть ла в нете какиенибудь описания .NET на русском языке? Описания clr pe exe на русском,
самой архитектуры? Есть ли disassembler-ы? Отладчики?
EG>я конечно понимаю что новички всегда всех смешат но EG>Описать секции кода, данных и т.д. соответствующими структурами, EG>Описать Optional Header со всеми причиндалами. EG>Заполнить LookUp Table, и т.д. EG>вот пример того как можно прочитать PEEXE структуры,
EG>с помощью этого примитива можно запросто считать OptionalHeader mscode.dll и т.д. EG>Откомпилировать или слинковать секции и куски можно где угодно, лишь бы компилятор был. EG>Все что можно прочитать можно и записать.Другое дело что приложение откомпилированное под DOS-oм (для примера) но предназначенное для W2k нельзя будет исполнить и отладить.Но откомпилировать можно.
Ну, здесь ты меня точно насмешил. Я тебе уже сбросил линк на свою статью. Посмотри заодно и программу к ней...
OD>Ну, здесь ты меня точно насмешил. Я тебе уже сбросил линк на свою статью. OD>Посмотри заодно и программу к ней...
Спасибо очень классная статья
Действительно классная
А сразу нельзя было ее кинуть?
OD>Ну, здесь ты меня точно насмешил. Я тебе уже сбросил линк на свою статью. OD>Посмотри заодно и программу к ней...
Извините если Вас обидел своим незнанием
Ваша статья просто замечательна
Большое спасибо за статью и за программу
Теперь весь этот топик считаю просто ненужным
Желаю Вам еще больших успехов
Здравствуйте, Edvard_Grieg, Вы писали:
E_G>Извините что беспокою с довольно глупыми вопросами НО: E_G>Мне интнересно следующее: E_G>1) Как мелкомягкие будут отказываться от вин32, если E_G>mscodee.dll в полный рост импортирует в себя:
-- skip -- E_G>Практически все функции kernel32.dll,advapi32.dll ??? E_G>Т.е. не работает в режиме ядра а находится в самом что ненаесть пользовательском режиме , и является лишь надстройкой над kernel32.dll,advapi32.dll. E_G>Я проанализировал формат CLR PE EXE и пришел к выводу что любое net приложение может E_G>запросто работать как с управляемым так и с неуправляемым кодом???? E_G>Кроме всего прочего мне кажется что мелкомягкие библиотеку Runtime включаемую в проекты MSVC просто перенесли в mscoree.dll. E_G>Как мелкомягкие будут избегать работы в "куче" управляемого кода? Они предоставят интерфейс для работы с кучей(инкапсулировать те самые :HeapFree :: 501 E_G> HeapAlloc :: 495 !kernel32.dll) а сама куча будет выполнятся в mscoree.dll? E_G>И еще ведь mscoree.dll будет исполняться в контексте вызвавшего ее процесса а ненаоборот. Какой тогда вообще смысл от этой надстройки. Заранее извиняюсь за глупые вопросы.
E_G>with best regards Edvard Grieg http://www.angelfire.com/rpg2/e_grig
Сразу скажу, что я не претендую на истину, но вот мое ИМХО:
Microsoft .NET является по сути платформенно-независимой средой исполнения. Т.е. программа, написанная под .NET может исполняться на любой системе, где стоит .NET, и это может быть не WIN-система. Если конечно, программа не использует платформенно-зависимые средства (такие как непосредственный импорт или обращение к ситемным библиотекам). Ближайший аналог — JAVA.
Программа для .NET компилируется во внутренний язык (IL) и при запуске компилируется в исполняемый код средой исполнения, что обеспечивает такие возможности как:
кроссплатформенная переносимость кода
оптимизация средой исполнения
вызокая безопасность управляемого кода
и пр.
Естественно, что такая исполняющая среда должна иметь внутри себя интерфейсы к системному API или реализовывать свои Native API. На данный момент Microsoft решили упростить себе жизнь реализовав оболочку для WIN32 API. По моему мнению тут сыграло роль то, что переход сразу к новому API был бы слишком сложен для программистов, т.к. большинству проще воспользоваться чем-то похожим на привычное, чем совсем новым.
Насколько я понимаю, в Longhorn системное API будет новым и для совместимости будет сохранен WIN32 API, который станет оболочкой над системным API Longhorn. Соответственно в .NET системные библиотеки будут реализованы на основе системного API, а не WIN32.
Здравствуйте, SiAVoL, Вы писали:
SAV>Все очень просто Просто никто не будет отказываться от WinAPI (кстати откуда дровишки?). WinAPI жил живет и будет жить. Вот то что в следующей ОС — Longhorn часть возможностей будет доступна только через управляемый код — это да, это есть. Но WinAPI никуда не денется
Не могли бы вы указать первоисточник? Неужели нельзя будет полноценно программировать под Longhorn без управляемого кода? Что-то не верится...
Здравствуйте, Edvard Grieg, Вы писали:
EG>Это я и так буду делать. В мелочах роюсь. Всегда. Привычка такая. Просто думаю что в мелочах всегда скрывается чтото важное. Есть ла в нете какиенибудь описания .NET на русском языке? Описания clr pe exe на русском, EG>самой архитектуры? Есть ли disassembler-ы? Отладчики?
Все есть в Джери Рихтер "Программирование на платформе Microsoft .NET Framework" у меня книжка печатная. А вот электронный вариант видел кажется видел на ftp://ftp.runnet.ru/BOOKS/ но не факт, что русский.
