-
Notifications
You must be signed in to change notification settings - Fork 0
/
template — копия.html
2521 lines (1954 loc) · 224 KB
/
template — копия.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description" content="">
<meta name="author" content="">
<title>Starter Template for Bootstrap</title>
<link href="./css/bootstrap.css" rel="stylesheet">
<style>
body {
padding-top: 50px;
}
.starter-template {
padding: 40px 15px;
text-align: left;
}
</style>
<!--[if lt IE 9]><script src="../../docs-assets/js/ie8-responsive-file-warning.js"></script><![endif]-->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
<![endif]-->
</head>
<body>
<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="#">My blog</a>
</div>
<div class="collapse navbar-collapse">
<ul class="nav navbar-nav">
<li><a href="./index.html">Main</a></li>
<li><a href="./about.html">About</a></li>
<li><a href="./contact.html">Contact</a></li>
</ul>
</div>
</div>
</div>
<div class="container">
<div class="starter-template">
<h1>Bootstrap starter template</h1>
<H2><A name="ES"></A></H2>
<P>Формат исполняемого файла операционной системы в значительной степени отражает
встроенные в операционную систему предположения и режимы поведения. Хотя освоение всех
деталей формата исполняемого файла и не является одной из главных задач обучения
программированию, тем не менее, из этого можно почерпнуть немало ценной информации об
операционной системе. Динамическая компоновка, поведение загрузчика и управление памятью —
это только три примера специфических свойств операционной системы, которые можно понять по
мере изучения формата исполняемых файлов.</P>
<P>В этой главе мы совершим экскурс в переносимый исполняемый (РЕ — Portable Executable)
формат файла, который фирма Microsoft разработала для использования во всех ее операционных
системах Win32 (Windows NT, Windows 95, Win32s).</P>
<P>Возможно, читатель удивится тому, что я рассказываю о РЕ-формате в этой книге, тогда как
несколько описаний этого формата можно найти на CD-ROM Microsoft Developer Network. Главная
причина, по которой я решил описать РЕ-формат, — это тот факт, что внутри самой Windows 95
используются те же ключевые структуры данных, что и в файлах РЕ-формата. Так, например,
Windows 95 отображает заголовок РЕ-файла в память и использует его для представления
загружаемого модуля. Для того чтобы понять, как работает ядро Windows 95, необходимо
разобраться с РЕ-форматом. Гарантирую, что это достаточно просто.</P>
<P>Другой причиной, по которой я решил описать РЕ-формат, является то, что описание РЕ-формата
фирмы Microsoft, как и остальная документация этой фирмы, предполагает, что пользователь живет
и дышит исполняемым форматом файла. Не будет преувеличением назвать документацию Microsoft
отрывочной. Так что моей задачей в этой главе является "оживление" этой документации и
соотнесение ее с привычными для каждого пользователя понятиями. По ходу дела я указал ряд
способов, посредством которых РЕ-формат влияет на реализацию операционной системы и наоборот.</P>
<P>РЕ-формат играет и будет играть в обозримом будущем ключевую роль во всех операционных
системах Microsoft, включая Cairo. Даже если вы программируете в Windows 3.1, используя Visual
C++, вам все равно придется пользоваться РЕ-файлами (32-разрядные расширенные компоненты DOS в
Visual C++ используют этот формат). А если вы собираетесь заняться любой работой, связанной с
системным программированием низкого уровня в Windows 95, практические знания по РЕ-файлам просто
необходимы.</P>
<P>При обсуждении РЕ-формата я не собираюсь тщательно перебирать груды шестнадцатеричных кодов
или без конца объяснять назначения отдельных битов. Вместо этого я хочу изложить концепции,
заложенные в РЕ-формат, и связать их с понятиями, которые ежедневно встречаются при
программировании в Win32. Например, концепция локальных переменных для цепочек (а-ля
__declspec (thread)) выводила меня из терпения до тех пор, пока я не увидел, с какой простотой
и изяществом она реализована в исполняемом файле. Учитывая, что многие программисты имеют опыт
работы в Win 16, я покажу, как связаны конструкции в РЕ-формате с их эквивалентами в
16-разрядных файловых форматах.</P>
<P>Вместе с новыми форматами исполняемых файлов Microsoft также ввела новые форматы объектных
модулей и библиотек, создаваемые ее собственными компиляторами и ассемблерами, (Новый файловый
формат LIB, по существу, представляет собой просто связку объектных файлов, упорядоченных с
помощью индекса; когда в дальнейшем я ссылаюсь в этой книге на объектные файлы, я буду иметь в
виду как COFF-объектные, так и LIB-файлы.) Эти новые объектные и LIB-файловые форматы имеют
немало общих концепций с форматом РЕ. До настоящего времени не существовало общедоступного
источника информации об объектных и LIB-файлах фирмы Microsoft, и даже к моменту написания
этой книги информация очень скудна. Поэтому стоит осветить также форматы объектных файлов и
LIB-файлов.</P>
<P>Общеизвестно, что Windows NT (первая из операционных систем Win32) унаследовала многое от
VAX VMS и UNIX. Многие ведущие разработчики NT перед своим приходом в Microsoft программировали
и работали именно над этими системами. Вполне естественно, что, когда им пришлось создавать NT,
чтобы сохранить свое время и силы, они использовали ранее написанные и опробованные средства.
Исполняемый формат и формат объектного модуля, который эти средства создавали и с которым они
работали, называется COFF (Common Object File Format — стандартный формат объектного файла).</P>
<P>Относительно устаревшую (по компьютерным меркам) сущность COFF можно усмотреть в том, что
некоторые поля в файлах имеют восьмеричный формат. COFF-формат был сам по себе неплохой
отправной точкой, но нуждался в расширении, чтобы удовлетворить потребностям новых операционных
систем, таких как Windows NT или Windows 95. Результатом такого усовершенствования явился
РЕ-формат (не забывайте: РЕ означает Portable Executable — переносимый исполняемый). Этот формат
называется переносимым, так как все реализации Windows NT в различных системах (Intel 386,
MIPS, Alpha, Power PC и т.д.) используют один и тот же исполняемый формат. Конечно, имеются
различия, например, связанные с двоичной кодировкой команд процессора. Нельзя запустить на Intel
исполняемый РЕ-файл, откомпилированный в MIPS. Тем не менее существенно, что нет нужды
полностью переписывать загрузчик операционной системы и программные средства для каждого нового
процессора.</P>
<P>Microsoft стремилась усовершенствовать Windows NT, и это хорошо иллюстрируется тем, что
Microsoft отказалась от своих существующих 32-разрядных средств и файловых форматов. Драйверы
виртуальных устройств, написанные для Windows З.х, использовали другой 32-разрядный формат файла
(LE-формат) задолго до появления NT на свет. Следуя принципу "Если не поломано, не надо и
чинить", заложенному в Windows, Windows 95 использует как РЕ-, так и LE-формат. Это позволило
Microsoft широко использовать существующие программы под Windows 3-х.</P>
<P>Вполне естественно ожидать совершенно другого исполняемого формата для совершенно новой
операционной системы (какой является Windows NT), но другой вопрос— форматы объектных модулей
(.OBJ и LIB). До появления 32-разрядной версии 1.0 Visual C++ все компиляторы Microsoft
пользовались спецификацией Intel OMF (Object Module Format — формат объектного модуля).
Компиляторы Microsoft для реализации Win32 создают объектные файлы в формате COFF. Некоторые
конкуренты Microsoft, например Borland, отказались от формата COFF объектных файлов и продолжали
придерживаться формата OMF Intel. В результате компании, производящие объектные и LIB-файлы,
рассчитанные на использование с несколькими компиляторами, будут вынуждены возвратиться к
системе поставок различных версий их продуктов для различных компиляторов (если они не сделали
этого до сих пор).</P>
<P>Те пользователи, которые любят усматривать во всех действиях Microsoft скрытность, могут
увидеть в смене объектных форматов стремление Microsoft воспрепятствовать своим конкурентам.
Чтобы гарантировать "совместимость" с Microsoft вплоть до уровня объектных файлов, другие
фирмы будут вынуждены конвертировать все свои 32-разрядные средства в форматы COFF OBJ и LIB.
Подводя итог, можно сказать, что объектные и LIB-файловые форматы являются еще одним примером
отказа Microsoft от существующих стандартов при выборе приоритетов развития этой фирмы.</P>
<P>Вместе с некоторыми определениями структур для объектных файлов формат COFF РЕ-формат
задокументирован (в самом размытом смысле этого слова) в файле заголовка WINNT.H. (Я буду
пользоваться именами полей из WINNT.H позже в этой главе.) Примерно посредине WINNT.H находится
секция, озаглавленная "Image Format". Эта секция начинается с небольших фрагментов из старых
добрых заголовков форматов DOS MZ и NE перед переходом к новой информации, связанной с РЕ.
WINNT.H дает определения структур исходных данных, используемых РЕ-файлами, однако содержит всего
лишь прозрачный намек на полезные комментарии, объясняющие назначение структур и флагов. Автор
заголовочного файла для РЕ-формата (некий Michael J. O'Leary) определенно питает склонность к
длинным, описательным именам, а также к глубоко вложенным структурам и макросам. Программируя
с использованием WINNT.H, нередко можно встретить, например, такое выражение:</P>
<DIV id="EOB"><TABLE class="code" width="98%"><TR><TD><PRE>
pNTHeader->OptionaIHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG].VirtualAddress;
</PRE></TD></TR></TABLE></DIV>
<P>Вы, вероятно, захотите не просто прочесть о том, из чего состоят РЕ-файлы, но и самим
просмотреть несколько РЕ-файлов, чтобы на практике увидеть, как реализуются представленные
здесь концепции. Если вы используете средства Microsoft для Win32, то программу DUMPBIN из
Visual C++, а также Win32 SDK, можно применить для того, чтобы "препарировать" файлы РЕ и
COFF OBJ/LIB и представить их в удобоваримом виде. DUMPBIN даже имеет замечательный параметр
для дизассемблирования программных секций изучаемого файла. Интересно отметить, что фирма
Microsoft, которая запрещает пользователям дизассемблировать свои программы, в данном случае
предоставила средство для простого дизассемблирования программ и библиотек динамической
компоновки (DLL). Если бы возможность дизассемблировать ЕХЕ и объектные файлы не была бы
полезна, зачем понадобилось бы Microsoft снабжать этим DUMPBIN? В этом случае можно
сказать: "Делай, как мы говорим, а не так, как мы делаем".</P>
<P>Пользователи Borland могут использовать TDUMP, чтобы просматривать РЕ-файлы, однако TDUMP
не воспринимает объектные файлы формата COFF. Здесь нет ничего страшного, так как компилятор
Borland вообще не создает объектные файлы формата COFF. Бросая свой вызов, я тоже написал
программу просмотра РЕ- и COFF-OBJ/LIB-файлов (PEDUMP), которая, на мой взгляд, осуществляет
более наглядный вывод, чем DUMPBIN. Несмотря на то, что моя программа не может дизассемблировать,
во всем остальном она полностью функционально эквивалентна DUMPBIN и, кроме того, содержит
некоторые новые черты, делающие ее достойной внимания. Исходный текст программы PEDUMP
находится на специальной дискете — вот почему я не привожу ее здесь полностью. Вместо этого я
предоставляю образец вывода PEDUMP, чтобы проиллюстрировать концепции по мере их изложения.</P>
<H2>Программа PEDUMP<A name="EVB"></A></H2>
<P>Программа PEDUMP является служебной, запускаемой из командной строки и предназначена для
вывода РЕ-файлов и файлов формата COFF OBJ/LIB. Она использует возможности терминала Win32,
чтобы обойтись без кропотливой работы с интерфейсом пользователя. PEDUMP имеет следующий
синтаксис: <I>PEDUMP [ключи] имя файла</I>. Имеющиеся ключи можно увидеть, запустив PEDUMP без
аргументов. PEDUMP использует следующие ключи:</P>
<DIV id="E4B"><TABLE class="code" width="98%"><TR><TD><PRE>
/A выводить все (по существу, активизируются все ключи)
/Н включить шестнадцатеричный вывод каждой секции в конце дампа
/I включить адреса переходников из Import Address Table
/L включить информацию о количестве строк (как для РЕ-, так и для COFF-объектных файлов)
/R показать смещения относительно базы (только для РЕ-файлов)
/S показать таблицу символов (как для РЕ-, так и для COFF OBJ-файлов)
</PRE></TD></TR></TABLE></DIV>
<P>По умолчанию ни один из ключей не активизирован. В этом случае большая часть необходимой
информации будет доступна и не будет слишком громадного объема выведенных данных.</P>
<P>PEDUMP осуществляет вывод в стандартный выходной файл (например, на экран), так что этот
вывод можно переадресовать в какой-либо файл с помощью знака ">" (больше), введенного в
командной строке.</P>
<P>Исходные файлы для PEDUMP включены вместе с ней. PEDUMP была создана с помощью компилятора
Microsoft Visual C++ 2.0, хотя я также компилировал эту программу по мере ее
усовершенствования, пользуясь Borland C++ 4.x.</P>
<H2>Основные сведения о форматах Win32 и РЕ<A name="EGC"></A></H2>
<P>Перед тем как начать обсуждение формата РЕ-файла, я хотел бы рассмотреть несколько новых
основных идей, позволивших создать такой формат. В процессе этого обсуждения я буду
использовать понятие модуль, подразумевая под ним текст программ, данные и ресурсы исполняемого
файла или DLL, которые были загружены в память. Помимо текста программы и данных, которые
использует непосредственно программа, модуль также включает вспомогательные данные, используемые
Windows для того, чтобы определить, где расположены в памяти текст программы и данные. В Win 16
вспомогательные структуры данных находятся в базе данных модуля (сегмент, на который ссылается
HMODULE). В Win32 эта информация содержится в заголовке РЕ-файла (структура IMAGE_NT_HEADERS),
о котором вскоре я подробно расскажу.</P>
<P>Самое важное из того, что следует знать о РЕ-файлах, это то, что исполняемый файл на диске
и модуль, получаемый после загрузки, очень похожи. Причиной этого является то, что загрузчик
Windows должен создать из дискового файла исполняемый процесс без больших усилий. Точнее
говоря, загрузчик попросту использует отображенные в память файлы Win32, чтобы загрузить
соответствующие части РЕ-файла в адресное пространство программы. Здесь уместна аналогия со
строительством сборных домиков. У вас есть относительно немного элементов, расставляя их по
своим местам и скрепляя стандартными соединениями, вы достаточно быстро собираете целый дом,
— вся работа состоит из простого защелкивания таких стандартных соединений. И такой же простой
задачей, как подключение электричества и водопровода к сборному домику, является соединение
РЕ-файла с внешним миром (т.е. подключение к нему DLL и т.д.).</P>
<P>Так же просто загружается и DLL. После того как ЕХЕ или .DLL модуль загружены, Windows
обращается с ними так же, как и с другими отображенными в память файлами. Совершенно иная
ситуация в 16-разрядной Windows. 16-разрядный NE-загрузчик файла считывает файл в память
порциями и создает отдельные структуры данных для представления модуля в памяти. Когда
необходимо загрузить сегмент программы или данных, загрузчик должен выделить новый сегмент из
общей кучи, обнаружить, где хранятся исходные данные в исполняемом файле, отыскать это место,
считать исходные данные и применить любой подходящий крепеж. Кроме того, каждый 16-разрядный
модуль обязан запоминать все используемые в данный момент селекторы, независимо от того,
выгружен ли сегмент.</P>
<P>В Win32, напротив, память, используемая под программы, данные, ресурсы, таблицы ввода,
таблицы вывода и другие элементы, представляет собой один сплошной линейный массив адресного
пространства. Все, что достаточно знать в этом случае, — это адрес, в который загрузчик
отобразил в памяти исполняемый файл. Тогда для того, чтобы найти любой элемент модуля,
достаточно следовать указателям, которые хранятся как часть отображения.</P>
<P>Другим важным понятием, о котором необходимо знать, является RVA (Relative Virtual
Address — относительный виртуальный адрес). Многие поля в РЕ-файлах задаются именно с
помощью их RVA. RVA — это просто смещение данного элемента по отношению к адресу, с которого
начинается отображение файла в памяти. Пусть, к примеру, загрузчик Windows отобразил РЕ-файл
в память, начиная с адреса 0х400000 в виртуальном адресном пространстве. Если некая таблица
в отображении начинается с адреса 0х401464, то RVA данной таблицы 0х1464:</P>
<DIV id="ETC"><TABLE class="code" width="98%"><TR><TD><PRE>
(виртуальный адрес <SPAN class="NUMBER">0х401464</SPAN>) - (базовый адрес <SPAN class="NUMBER">0х400000</SPAN>) = RVA <SPAN class="NUMBER">0х1464</SPAN>
</PRE></TD></TR></TABLE></DIV>
<P>Чтобы перевести RVA в указатель памяти, просто прибавьте RVA к базовому адресу, начиная с
которого был загружен модуль. Термин базовый адрес представляет еще одно важное понятие, о
котором следует помнить. Базовый адрес — это адрес, с которого начинается отображенный в
память ЕХЕ-файл или DLL. Для удобства Windows NT и Windows 95 используют базовый адрес модуля
в качестве дескриптора образца модуля (HINSTANCE — instance handle). To, что в Win32 базовый
адрес называется HINSTANCE, может вызвать недоразумения, так как термин дескриптор образца
происходит из 16-разрядной Windows. Каждая копия приложения в Win16 получает свой собственный
сегмент данных (и связанный с ним глобальный дескриптор), который отличает эту копию приложения
от других; отсюда и название дескриптор образца.</P>
<P>В Win32 нет нужды различать отдельные копии приложений, так как у них нет общего адресного
пространства. Однако термин HINSTANCE сохранен, чтобы отразить преемственность Win32 по
отношению к Win16. В случае Win32 существенно то, что можно вызвать GetModuleHandle() для любой
DLL, которая используется в процессе, и получить указатель, который можно использовать для
доступа к компонентам модуля. Под компонентами модуля я подразумеваю его импортируемые и
экспортируемые функции, его перемещения, его программные секции и секции данных и т.п.</P>
<P>Еще одним понятием, с которым следует ознакомиться для того, чтобы исследовать РЕ- и COFF
OBJ-файлы, является секция. Секция в файлах РЕ или COFF OBJ примерно эквивалентна сегменту или
ресурсам в 16-разрядном NE-файле. Секции содержат либо код программ, либо данные. Некоторые
секции содержат код и данные, непосредственно объявляемые и используемые программами, тогда
как другие секции данных создаются компоновщиками и библиотекарями специально для пользователя
и содержат информацию, необходимую для работы операционной системы. В некоторых описаниях
формата РЕ фирмы Microsoft секции также называются объектами. Однако этот последний термин
имеет так много (возможно, противоречащих друг другу) значений, что я решил придерживаться
термина секции для обозначения им областей программного кода и данных. Секции рассмотрены
более подробно в этой главе, в разделе "Часто встречающиеся секции"; пока что читателю
достаточно просто знать, что такое секция.</P>
<P>Перед тем как погрузиться в детали РЕ-файла, советую изучить рис. 8.1, представляющий общий
формат РЕ-файла. Несмотря на то, что я буду объяснять каждый элемент отдельно, полезно для
начала рассмотреть их все вместе.</P>
<P style="text-align: center;"><IMG src="pe_coff/pe-img1.gif"></IMG><BR /><I style="font-face: verdana; font-size:x-small;">Рис. 8.1. Общий формат РЕ-файла</I></P>
<H2>Заголовок РЕ-файла<A name="EJD"></A></H2>
<P>Первым пунктом, на котором мы остановимся в нашем путешествии по РЕ-формату, будет заголовок
РЕ-файла. Как и всякий другой исполняемый формат файла Microsoft, РЕ-файл имеет набор полей,
расположенных в легко доступном (по крайней мере, легко находимом) месте файла; эти поля
определяют, как будет выглядеть остальная часть файла. Заголовок РЕ-файла содержит такую
важную информацию, как расположение и размер областей кода программ и данных, указание на то,
с какой операционной системой предполагается использовать данный файл, а также начальный размер
стека.</P>
<P>Как и в других исполняемых форматах от Microsoft, заголовок не находится в самом начале
файла. Вместо этого несколько сотен первых байтов типичного РЕ-файла заняты под заглушку DOS.
Эта заглушка представляет собой минимальную DOS-программу, которая выводит что-либо вроде: "Эта
программа не может быть запущена под DOS". Все это предусматривает случай, когда пользователь
запускает программу Win32 в среде, которая не поддерживает Win32, получая при этом приведенное
выше сообщение об ошибке (звучит разочаровывающе, конечно). После того как загрузчик Win32
отобразил в память РЕ-файл, первый байт отображения файла соответствует первому байту заглушки
DOS. И это не так уж плохо. С каждой запускаемой Win32 программой пользователь получает
дополнительную DOS-программу, загруженную просто так! (В Win 16 заглушка DOS не загружается в
память.)</P>
<P>Как и в других исполняемых форматах Microsoft, настоящий заголовок можно обнаружить, найдя
его стартовое смещение, которое хранится в заголовке DOS. Файл WINNT.H содержит определение
структуры для заголовка заглушки DOS, что делает очень простым нахождение начала заголовка
РЕ-файла. Поле e_lfanew собственно и содержит относительное смещение (или, если хотите, RVA)
настоящего заголовка РЕ-файла. Чтобы установить указатель в памяти на заголовок РЕ-файла,
достаточно просто сложить значение в поле с базовым адресом отображения:</P>
<DIV id="ESD"><TABLE class="code" width="98%"><TR><TD><PRE>
<SPAN class="COMMENT">//Пренебрегаем для ясности преобразованием типов и указателей...</SPAN>
pNTHeader = dosHeader + dosHeader->e_lranew;
</PRE></TD></TR></TABLE></DIV>
<P>Настоящее веселье начинается, когда указатель установлен на основной заголовок РЕ-файла.
Основной заголовок РЕ-файла представляет структуру типа IMAGE_NT_HEADERS, определенную в файле
WINNT.H. Структура IMAGE_NT_HEADERS в памяти — это то, что Windows 95 использует в качестве
своей базы данных модуля в памяти. Каждый загруженный ЕХЕ-файл или DLL представлены в Windows
95 структурой IMAGE_NT_HEADERS. Эта структура состоит из двойного слова и двух подструктур,
как показано ниже:</P>
<DIV id="EZD"><TABLE class="code" width="98%"><TR><TD><PRE>
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER OptionalHeader;
</PRE></TD></TR></TABLE></DIV>
<P>Поле Signature (сигнатура — подпись), представленное как ASCII код, — это РЕ\0\0 (два
нулевых байта после РЕ). Если поле e_lfanew в заголовке DOS указало вместо обозначения РЕ
обозначение NE в этом месте, значит, вы работаете с файлом Win 16 NE. Аналогично, если указано
обозначение LE в поле Signature, то это файл VxD (VirtualDeviceDriver— драйвер виртуального
устройства). Обозначение LX указывает на файл старой соперницы Windows 95 — OS/2.</P>
<P>За двойным словом — сигнатурой РЕ, в заголовке РЕ-файла следует структура типа
IMAGE_FILE_HEADER. Поля этой структуры содержат только самую общую информацию о файле.
Структура не изменилась по сравнению с исходными COFF-реализациями. Эта структура является
частью заголовка РЕ-файла, кроме того, появляется в самом начале объектных COFF-файлов,
создаваемых компиляторами Microsoft Win32. Далее приводятся поля IMAGE_FILE_HEADER.</P>
<DIV id="E6D"><TABLE class="code" width="98%"><TR><TD><PRE>WORD Machine</PRE></TD></TR></TABLE></DIV>
<P>Это центральный процессор, для которого предназначен файл. Определены следующие
идентификаторы процессоров:</P>
<DIV id="EDE"><TABLE class="code" width="98%"><TR><TD><PRE>
Intel I386 0х14С
Intel I860 0xl4D
MIPSR3000 0х162
MIPS R4000 0х166
DEC Alpha AXP 0х184
PowerPC 0x1F0 (little endian)
Motorola 68000 0х268
PA RISC 0х290 (Precision Architecture)
</PRE></TD></TR></TABLE></DIV>
<H4>WORD NumberOfSections</H4>
<P>Количество секций в ЕХЕ- или OBJ-файле.</P>
<H4>DWORD TimeDateStamp</H4>
<P>Время, когда файл был создан компоновщиком (или компилятором, если это OBJ-файл). В этом
поле указано количество секунд, истекших с 16:00 31 декабря 1969 года.</P>
<H4>DWORD PointerToSymbolTable</H4>
<P>Файловое смещение COFF-таблицы символов. Это поле используется только в OBJ- и РЕ-файлах с
информацией COFF-отладчика. РЕ-файлы поддерживают разнообразные отладочные форматы, так что
отладчики должны ссылаться ко входу IMAGE_DIRECTORY_ENTRY_DEBUG в каталоге данных (будет
определен позднее).</P>
<H4>DWORD NumberOfSymbols</H4>
<P>Количество символов в COFF-таблице символов. См. предыдущее поле.</P>
<H4>WORD SheOfOptionalHeader</H4>
<P>Размер необязательного заголовка, который может следовать за этой структурой. В исполняемых
файлах — это размер структуры IMAGE_OPTIONAL_HEADER, которая следует за этой структурой. В
объектных файлах, по утверждению Microsoft, это поле всегда содержит нуль. Однако при просмотре
библиотеки вывода KERNEL32.LIB можно обнаружить объектный файл с ненулевым значением в этом
поле, так что относитесь к высказыванию Microsoft с некоторым скептицизмом.</P>
<H4>WORD Characteristics</H4>
<P>Флаги, содержащие информацию о файле. Здесь описываются некоторые важные поля (другие поля
определены в WINNT.H).</P>
<DIV id="EIF"><TABLE class="code" width="98%"><TR><TD><PRE>
0х0001 Файл не содержит перемещений.
0х0002 Файл представляет исполняемое отображение (т.е. это не OBJ- или LIB-файл).
0х2000 Файл является библиотекой динамической компоновки (DLL), а не программой.
</PRE></TD></TR></TABLE></DIV>
<P>Третьим компонентом заголовка РЕ-файла является структура типа IMAGE_OPTIONAL_HEADER.
Для РЕ-файлов эта часть является обязательной. Формат COFF разрешает индивидуальные реализации
для определения структуры дополнительной информации, помимо стандартного IMAGE_FILE_HEADER. В
полях в IMAGE_OPTIONAL_HEADER разработчики РЕ-формата поместили то, что они посчитали важным
дополнением к общей информации в IMAGE_FILE_HEADER.</P>
<P>Для пользователя не является критическим знание всех полей в IMAGE_OPTIONAL_HEADER, Наиболее
важными полями являются поля ImageBase и Subsystem. По желанию читатель может бегло просмотреть
или пропустить следующее описание полей.</P>
<H4>WORD Magic</H4>
<P>Слово-сигнатура, определяющее состояние отображенного файла. Определены следующие
значения:</P>
<DIV id="EUF"><TABLE class="code" width="98%"><TR><TD><PRE>
0х0107 Отображение ПЗУ
0х010В Нормальное исполняемое отображение (Значение для большей части файлов)
</PRE></TD></TR></TABLE></DIV>
<H4>BYTE MajorLinker Version; BYTE MinorLinker Version</H4>
<P>Версия компоновщика, который создал данный файл. Числа должны быть представлены в десятичном
виде, а не в шестнадцатеричном. Типичная версия компоновщика 2.23.</P>
<H4>DWORD SizeOfCode</H4>
<P>Суммарный размер программных секций, округленный к верхней границе. Обычно большинство
файлов имеют только одну программную секцию, так что это поле обычно соответствует размеру
секции .text.</P>
<H4>DWORD sizeOfInitializedData</H4>
<P>Предполагается, что это общий размер всех секций, состоящих из инициализированных данных
(не включая сегменты программного кода.) Однако не похоже, чтобы это совпадало с размером
секций инициализированных данных в файле.</P>
<H4>DWORD SizeOfUninltializedData</H4>
<P>Размер секций, под которые загрузчик выделяет место в виртуальном адресном пространстве,
но которые не занимают никакого места в дисковом файле. В начале работы программы эти секции
не обязаны иметь каких-либо определенных значений — отсюда название <I>неинициализированные
данные (Uninitialized Data)</I>. Неинициализированные данные обычно находятся в секции под
названием .bss.</P>
<H4>DWORD AddressOfEntryPoint</H4>
<P>Адрес, с которого отображение начинает выполнение. Это RVA, который можно найти в секции
.text. Это поле применимо как для ЕХЕ-файла, так и для DLL.</P>
<H4>DWORD BaseOfCode</H4>
<P>RVA, с которого начинаются программные секции файла. Программные секции кода обычно идут в
памяти перед секциями данных и после заголовка РЕ-файла. Этот RVA обычно равен 0х1000 для
ЕХЕ-файлов, созданных компоновщиками Microsoft. Для TLINK32 (Borland) значение этого поля равно
0х10000, так как по умолчанию этот компоновщик выравнивает объекты на границу в 64 Кбайт в
отличие от 4 Кбайт в случае компоновщика Microsoft.</P>
<H4>DWORD BaseOfData</H4>
<P>RVA, с которого начинаются секции данных файла. Секции данных обычно идут последними в
памяти, после заголовка РЕ-файла и программных секций.</P>
<H4>DWORD ImageBase</H4>
<P>Когда компоновщик создает исполняемый файл, он предполагает, что файл будет отображен в
определенное место в памяти. Вот именно этот адрес и хранится в этом поле. Знание адреса
загрузки позволяет компоновщику провести оптимизацию. Если загрузчик действительно отобразил
файл в память по этому адресу, то программа перед запуском не нуждается ни в какой настройке.
Я расскажу об этом немного подробнее при обсуждении перемещений относительно базы. В исполняемых
файлах NT 3.1 адрес отображения по умолчанию равен 0х10000. В случае DLL этот адрес по
умолчанию равен 0х400000. В Windows 95 адрес 0х10000 нельзя использовать для загрузки
32-разрядных файлов ЕХЕ, так как он лежит в пределах линейной области адресного пространства,
общего для всех процессов. Поэтому для Windows NT 3.5 Microsoft изменила для исполняемых файлов
Win32 базовый адрес по умолчанию, сделав его равным 0х400000. Более старые программы, которые
были скомпонованы в предположении, что базовый адрес равен 0х10000, загружаются Windows 95
дольше, потому что загрузчик должен применить базовые поправки. Я опишу базовые поправки
немного позже.</P>
<H4>DWORD SectionAlignment</H4>
<P>После отображения в память каждая секция будет обязательно начинаться с виртуального адреса,
кратного данной величине. С учетом подкачки страниц минимальная величина этого поля 0х1000
используется компоновщиком Microsoft по умолчанию. TLINK в Borland C++ использует по умолчанию
0х10000 (64 Кбайт).</P>
<H4>DWORD FileAlignment</H4>
<P>В случае РЕ-файла исходные данные, которые входят в состав каждой секции, будут обязательно
начинаться с адреса, кратного данной величине. Значение, устанавливаемое по умолчанию, равно
0х200 байт и, вероятно, выбрано так для того, чтобы начало секции всегда совпадало с началом
дискового сектора (0х200 байт — это как раз размер дискового сектора). Это поле эквивалентно
размеру выравнивания сегмента/ресурса в NE-файлах. В отличие от NE-файлов, РЕ-файлы не состоят
из сотен секций, так что память, теряемая при выравнивании секций файла, обычно очень
незначительна.</P>
<H4>WORD MajorOperatingSystemVersion; WORD MinorOperatingSystemVersion
</H4>
<P>Самая старая версия операционной системы, которая может использовать данный исполняемый
файл. Назначение этого поля не совсем ясно, так как поля подсистемы (приведены ниже), похоже,
имеют такое же предназначение. В большей части файлов Win32 в этом поле содержится значение,
соответствующее версии 1.0 .</P>
<H4>WORD MajorImageVersion; WORD MinorImageVersion</H4>
<P>Определяемое пользователем поле. Это поле позволяет иметь различные версии ЕХЕ-файлов и DLL.
Эти поля устанавливаются с помощью ключа компоновщика /VERSION, например:</P>
<DIV id="EDAAC"><TABLE class="code" width="98%"><TR><TD><PRE>LINK/VERSION:2.0 myobj.obj</PRE></TD></TR></TABLE></DIV>
<H4>WORD MajorSubsystem Version; WORD MinorSubsystem Version</H4>
<P>Это поле содержит самую старую версию подсистемы, позволяющую запускать данный исполняемый
файл. Типичное значение в этом поле 4.0 (обозначает Windows 4.0, что равносильно Windows 95).</P>
<H4>DWORD Reserved</H4>
<P>Это поле, по-видимому, всегда равно нулю.</P>
<H4>DWORD SizeOfImage</H4>
<P>Представляет общий размер всех частей отображения, находящихся под контролем загрузчика.
Эта величина равна размеру области памяти, начиная с базового адреса отображения и заканчивая
адресом конца последней секции. Адрес конца секции выровнен на ближайшую верхнюю границу секции.</P>
<H4>DWORD SizeOfHeaders</H4>
<P>Размер заголовка РЕ-файла и таблицы секции (объекта). Исходные данные для секций начинаются
сразу после всех составляющих частей заголовка.</P>
<H4>DWORD Checksum</H4>
<P>Предположительно отвечает контрольной сумме контроля циклическим избыточным кодом
(CRC-контроль) для данного файла. Как и для других исполняемых форматов Microsoft, это поле
обычно игнорируется и устанавливается в нуль. Однако для всех DLL драйверов, DLL, загруженных
во время загрузки ОС, и серверных DLL эта контрольная, сумма должна иметь правильное значение.
Алгоритм для контрольной суммы можно найти в IMAGEHLP.DLL. Исходники IMAGEHLP.DLL поставляются
в WIN32 SDK.</P>
<H4>WORD Subsystem</H4>
<P>Тип подсистемы, которую данный исполняемый файл использует для своего пользовательского
интерфейса. WINNT.H определяет следующие значения:</P>
<DIV id="EJBAC"><TABLE class="code" width="98%"><TR><TD><PRE>
NATIVE == 1 Подсистема не требуется (например, для драйвера устройства)
WINDOWS_GUI = 2 Запускается в подсистеме Windows GUI
WINDOWS_CUI = 3 Запускается в подсистеме Windows character (терминальное приложение)
OS2_CUI = 5 Запускается в подсистеме OS/2 (только приложения OS/2 1.x)
POSIX_CUI = 7 Запускается в подсистеме Posix
</PRE></TD></TR></TABLE></DIV>
<H4>WORD DllCharacteristics (обозначен как вышедший из употребления в NT 3.5)</H4>
<P>Набор флагов, показывающий, при каких обстоятельствах будет вызываться функция инициализации
DLL (например, DllMain()). Эта величина, по-видимому, всегда должна устанавливаться в нуль,
однако операционная система вызывает функцию инициализации DLL для всех четырех случаев.
Определены следующие значения:</P>
<DIV id="ERBAC"><TABLE class="code" width="98%"><TR><TD><PRE>
1 — Вызов, когда DLL впервые загружена в адресное пространство процесса
2 — Вызов, когда цепочка заканчивает работу
4 — Вызов, когда цепочка начинает работу
8 — Вызов при выходе из DLL
</PRE></TD></TR></TABLE></DIV>
<H4>DWORD SizeOfStackReserve</H4>
<P>Объем виртуальной памяти, резервируемой под начальный стек цепочки. Однако не вся эта
память выделяется (см. следующее поле). По умолчанию это поле устанавливается в 0х100000 (1
Мбайт). Если пользователь указывает 0 в качестве размера стека в CreateThread(), получившаяся
цепочка будет иметь стек того же размера.</P>
<H4>DWORD SizeQfStackCommit</H4>
<P>Количество памяти, изначально выделяемой под исходный стек цепочки. Это поле по умолчанию
равно 0х1000 байт (1 страница) для компоновщиков Microsoft, тогда как TLINK32 делает его равным
0х2000 (2 страницы).</P>
<H4>DWORD SizeOfHeapReserve</H4>
<P>Объем виртуальной памяти, резервируемой под изначальную кучу программы. Этот дескриптор
кучи можно получить, вызвав GetProcessHeap(). Однако не вся эта память выделяется (см. следующее
поле).</P>
<H4>DWORD SizeOfHeapCommit</H4>
<P>Объем виртуальной памяти, изначально выделяемой под кучу процесса. По умолчанию компоновщик
делает это поле равным 0х1000 байт.</P>
<H4>DWORD LoaderFlags (обозначен как вышедший из употребления в NT 3.5)</H4>
<P>Как следует из WINNT.H, эти поля, по-видимому, связаны с поддержкой отладчика. Мне никогда
не приходилось видеть исполняемый файл, у которого хотя бы один из этих битов был активизирован.
Мне также неясно, как с помощью компоновщика устанавливать их. Определены следующие
значения:</P>
<DIV id="ERCAC"><TABLE class="code" width="98%"><TR><TD><PRE>
1 — Запускать ли команду прерывания перед запуском процесса?
2 — Запускать ли отладчик программы после процесса?
</PRE></TD></TR></TABLE></DIV>
<H4>DWORD NumberOfRvaAndShes</H4>
<P>Количество входов в массиве DataDirectory (см. описание следующего поля). Современные
программные средства всегда делают это значение равным 16.</P>
<H4>IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]</H4>
<P>Массив структур типа IMAGE_DATA_DIRECTORY. Начальные элементы массива содержат стартовый
RVA и размеры важных частей исполняемого файла. В настоящее время некоторые элементы в конце
массива не используются. Первый элемент массива — это всегда адрес и размер экспортированной
таблицы функций (если она присутствует). Второй элемент массива — адрес и размер
импортированной таблицы функций и т.д. Для того чтобы увидеть полный перечень определений
элементов массива, см. IMAGE_DIRECTORY_ENTRY_xxx директивы #define в WINNT.H.</P>
<P>Этот массив предназначен для того, чтобы загрузчик мог быстро найти определенную секцию
отображения (например, импортированную таблицу функций) без последовательного перебора всех
секций отображения, чтобы каждый раз не сравнивать имена.</P>
<P>Большая часть элементов массива описывает все данные в секции. Тем не менее элемент
IMAGE_DIRECTORY_ENTRY_DEBUG охватывает только небольшую часть байтов в секции .rdata. За более
подробной информацией по этому вопросу обращайтесь к разделу "Секция .rdata" в этой главе.</P>
<H2>Таблица секций<A name="EFDAC"></A></H2>
<P>Между заголовком РЕ-файла и исходными данными для секций отображения находится таблица
секций. Эта таблица содержит информацию о каждой секции отображения. Секции в отображении
упорядочены по их стартовому адресу, а не в алфавитном порядке.</P>
<P>К настоящему моменту необходимо четко разъяснить, что же такое секция. В NE-файле программный
код и данные хранятся в различных <I>сегментах</I> в файле. Часть заголовка NE-файла представляет собой
массив структур — по одной для каждого сегмента, используемого программой. Каждая структура
массива содержит информацию об одном сегменте. Хранимая информация включает тип сегмента
(программа или данные), его размер и его расположение, где бы он ни находился в файле. В
РЕ-файле таблица секций аналогична таблице сегментов в NE-файле.</P>
<P>Однако, в отличие от таблицы сегментов NE-файла, таблица секций РЕ-файла не хранит значение
селектора для каждого куска программного кода или данных. Вместо этого каждый элемент таблицы
секций хранит адрес, по которому исходные данные файла были отображены в память. Несмотря на
то, что секции аналогичны 32-разрядным сегментам, они на самом деле не являются индивидуальными
сегментами. Вместо этого секция просто отвечает диапазону памяти виртуального адресного
пространства процесса.</P>
<P>Другим отличием РЕ-файлов от NE-файлов является то, как они управляют вспомогательными
данными, которые используются не программой, а операционной системой. В качестве двух примеров
можно привести перечень DLL, используемых исполняемыми файлами, и местонахождение таблицы
привязки (fixup). В NE-файлах ресурсы не считаются сегментами. И хотя они имеют приписанные им
селекторы, информация о ресурсах не хранится в таблице сегментов заголовка NE-файла. Вместо
этого ресурсы сведены в отдельную таблицу в конце заголовка NE-файла. Информации об
импортированных и экспортированных функциях тоже не гарантируется выделение своего собственного
сегмента, она накапливается в пределах заголовка NE-файла.</P>
<P>Другая ситуация в случае РЕ-файла. Все, что считается важным программным кодом или данными,
хранится в полнокровной секции. Таким образом, информация об импортированных функциях хранится
в своей собственной секции так же, как и таблица экспортируемых модулем функций. То же самое
справедливо и для данных настройки. Любая программа или данные, которые могут понадобиться
программе или операционной системе, получают свою собственную секцию.</P>
<P>Вскоре я начну рассматривать отдельные секции, но сначала мне нужно описать данные, с
помощью которых операционная система работает с секциями. Сразу после заголовка РЕ-файла в
памяти следует массив из IMAGE_SECTION_HEADER. Количество элементов этого массива задается в
заголовке РЕ-файла (поле IMAGE_NT_HEADER.FileHeader.NumberOfSections). Программа PEDUMP выводит
таблицу секций, все поля и атрибуты секций. Рис. 8.2 показывает вывод с помощью PEDUMP таблицы
секций для типичного ЕХЕ-файла. Рис. 8.3 показывает вывод с помощью PEDUMP таблицы секций для
типичного OBJ-файла.</P>
<DIV id="EXDAC"><TABLE class="code" width="98%"><TR><TD><PRE>
01 .text VirtSize: 00005AFA VirtAddr: 00001000
raw data offs: 00000400 raw data size: 00005C00
relocation offs: 00000000 relocations: 00000000
line # offs: 00009220 line #'s: 0000020C
characteristics: 60000020
CODE MEM_EXECUTE MEM_READ
02 .bss VirtSize: 00001438 VirtAddr: 00007000
raw data offs: 00000000 raw data size: 00001600
relocation offs: 00000000 relocations: 00000000
line # offs: 00000000 line #'s: 00000000
characteristics: C0000080
UNINITIALIZED_DATA MEM_READ MEM_WRITE
03 .rdata VirtSize: 0000015C VirtAddr: 00009000
raw data offs: 00006000 raw data size: 00000200
relocation offs: 00000000 relocations: 00000000
line # offs: 00000000 line #'s: 00000000
characteristics: 40000040
INITIALIZED_DATA MEM_READ
04 .data VirtSize: 0000239C VirtAddr: 0000A000
raw data offs: 00006200 raw data size: 00002400
relocation offs: 00000000 relocations: 00000000
line # offs: 00000000 line #'s: 00000000
characteristics: C0000048
INITIALIZED_DATA MEM_READ MEM_WRITE
05 .idata VirtSize: 0000033E VirtAddr: 0000D000
raw data offs: 00008600 raw data size: 00000400
relocation offs: 00000000 relocations: 00000000
line # offs: 00000000 line #'s: 00000000
characteristics: C0000040
INITIALIZED DATA MEN_READ MEM_WRITE
06 .reloc VirtSize: 000006CE VirtAddr: 0000E000
raw data offs: 00008A00 raw data size: 00000800
relocation offs: 00000000 relocations: 00000000
line # offs: 00000000 line #'s: 00000000
characteristics: 42000040
INITIALIZED DATA MEM_DISCARDABLE MEM_READ
</PRE></TD></TR></TABLE></DIV>
<P>Рис. 8.2. Типичная таблица секций ЕХЕ-файла</P>
<DIV id="E2DAC"><TABLE class="code" width="98%"><TR><TD><PRE>
01 .drectve PhysAddr: 00000000 VirtAddr: 00000000
raw data offs: 000000DC raw data size: 00000026
relocation offs: 00000000 relocations: 00000000
line # offs: 00000080 line #'s: 00000000
characteristics: 00100A00
LNK_INFO LNK_REMOVE
02 .debug$S PhysAddr: 00000026 VirtAddr: 00000000
raw data offs: 00000102 raw data size: 000016D0
relocation offs: 000017D2 relocations: 00000032
line # offs: 00000080 line #'s: 00000000
characteristics: 42100048
INITIALIZED_DATA MEM_DISCARDABLE MEM_READ
03 .data PhysAddr: 000016F6 VirtAddr: 00000000
raw data offs: 000019C6 raw data size: 00000D87
relocation offs: 0000274P relocations: 00000045
line # offs: 00000000 line #'s: 00000000
characteristics: C0480048
INITIALIZED_DATA MEM_READ MEM_WRITE
04 .text PhysAddr: 0000247D VirtAddr: 00000000
raw data offs: 000029FF raw data size: 000010DA
relocation offs: 00003AD9 relocations: 000000E9
line # offs: 000043F3 line #'s: 000000D9
characteristics: 60500020
CODE MEM_EXECUTE MEM_READ
05 .debug$T PhysAddr: 00003557 VirtAddr: 00000000
raw data offs: 00004909 raw data size: 00000030
relocation offs: 00000008 relocations: 00000000
line # offs: 00000000 line #'s: 00000000
characteristics: 42100048
INITIALIZED_DATA MEM_DISCARDABLE MEM_READ
</PRE></TD></TR></TABLE></DIV>
<P>Рис. 8.3 Типичная таблица секций объектного файла</P>
<P>Каждый IMAGE_SECTION_HEADER представляет собой полную базу данных об одной секции файла ЕХЕ
или OBJ и имеет следующий формат.</P>
<H4>BYTE Name[IMAGE_SIZEOF_SHORT_NAME]</H4>
<P>Это 8-байтовое имя в стандарте ANSI (не Unicode), которое именует секцию. Большинство имен
секций начинается с точки (например, .text), но это не обязательно, вопреки тому, в чем пытаются
вас уверить отдельные документы по РЕ-файлам. Пользователь может давать имена своим собственным
секциям с помощью либо сегментной директивы в ассемблере, либо с помощью директив #pragma
data_seg и #pragma code_seg компилятора Microsoft C/C++. (Пользователи Borland C++ должны
использовать #pragma codeseg.) Необходимо отметить, что, если имя секции занимает 8 полных
байтов, отсутствует завершающий байт NULL. (Программа TDUMP в Borland C++ 4.Ox упускает из виду
это обстоятельство и изрыгает последующий мусор из некоторых РЕ ЕХЕ-файлов.) Если вы
приверженец printf(), то можете использовать "%.8s", чтобы не копировать строку-имя в другой
буфер для завершения ее нулевым байтом.</P>
<DIV id="EGEAC"><TABLE class="code" width="98%"><TR><TD><PRE>
<SPAN class="KEYWORD">union</SPAN> {
DWORD PhysicalAddress
DWORD VirtualSize
} Misc;
</PRE></TD></TR></TABLE></DIV>
<P>Это поле имеет различные назначения в зависимости от того, встречается ли оно в ЕХЕ- или
OBJ-файле. В ЕХЕ-файле оно содержит виртуальный размер секции программного кода или данных.
Это размер до округления на ближайшую верхнюю границу файла. Поле SizeOfRawData дальше в этой
структуре содержит это округленное значение. Интересно, что Borland TLINK32 меняет местами
значение этого поля и поля SizeOfRawData и, тем не менее, остается правильным компоновщиком.
В случае OBJ-файлов это поле указывает физический адрес секции. Первая секция начинается с
адреса 0. Чтобы получить физический адрес следующей секции, надо прибавить значение в
SizeOfRawData к физическому адресу данной секции.</P>
<H4>DWORD VirtualAddress</H4>
<P>В случае ЕХЕ-файлов это поле содержит RVA, куда загрузчик должен отобразить секцию. Чтобы
вычислить реальный начальный адрес данной секции в памяти, необходимо к виртуальному адресу
секции, содержащемуся в этом поле, прибавить базовый адрес отображения. Средства Microsoft
устанавливают по умолчанию RVA первой секции равным 0х1000. Для объектных файлов это поле не
несет никакого смысла и устанавливается в 0.</P>
<H4>DWORD SizeOfRawData</H4>
<P>В ЕХЕ-файлах это поле содержит размер секции, выровненный на ближайшую верхнюю границу
размера файла. Например, допустим, что размер выравнивания файла 0х200. Если поле VirtualSize
указывает, что длина секции Ох35А байт, то в данном поле будет указано, что размер секции
0х400 байт. Для OBJ-файлов это поле содержит точный размер секции, сгенерированной компилятором
или ассемблером. Другими словами, для OBJ-файлов оно эквивалентно полю VirtualSize в
ЕХЕ-файлах.</P>
<H4>DWORD PointerToRawData</H4>
<P>Это файловое смещение участка, где находятся исходные данные для секции. Если пользователь
сам отображает в память РЕ- или COFF-файл (вместо того, чтобы доверить загрузку операционной
системе), это поле важнее, чем поле VirtualAddress. Причиной является то, что в этом случае
получится абсолютно линейное отображение всего файла, так что данные для секций будут находиться
по этому смещению, а не по RVA, указанному в поле VirtualAddress.</P>
<H4>DWORD PointerToRelocations</H4>
<P>В объектных файлах это файловое смещение информации о поправках для данной секции. Информация
о поправках в любой секции объектного файла следует за исходными данными для этой секции. В
ЕХЕ-файлах это (и следующее) поле не несет смысловой нагрузки и устанавливается в нуль. Когда
компоновщик создает ЕХЕ-файл, он разрешает большинство привязок, а во время загрузки остается
разрешить только базовые адресные поправки и импортированные функции. Информация о базовых
поправках и импортированных функциях хранится в секциях базовых поправок и импортированных
функций, так что нет необходимости в ЕХЕ-файле помещать данные поправок для каждой секции после
исходных данных секции.</P>
<H4>DWORD PointerToLinenumbers</H4>
<P>Файловое смещение таблицы номеров строк. Таблица номеров строк ставит в соответствие номера
строк исходного файла адресам, по которым можно найти код, сгенерированный для данной строки.
В современных отладочных форматах, таких как формат CodeView, информация о номерах строк
хранится как часть информации отладчика. В отладочном формате COFF, однако, информация о
номерах строк концептуально отлична от информации о символьных именах/типах. Обычно только
секции с программным кодом (например, .text или CODE) имеют номера строк. В ЕХЕ-файлах номера
строк собраны в конце файла после исходных данных для секций. В объектных файлах таблица
номеров строк для секции следует за исходными данными секции и таблицей перемещений для этой
секции. Я рассматриваю формат таблиц номеров строк позже, в разделе "Информация
COFF-отладчика".</P>
<H4>WORD NumberOfRelocations</H4>
<P>Количество перемещений в таблице поправок для данной секции (поле PointerToRelocations
приведено выше). Это поле используется, по-видимому, только в объектных файлах.</P>
<H4>WORD NumberOfLinenumbers</H4>
<P>Количество номеров строк в таблице номеров строк для данной секции (поле
PointerToLinenumbers приведено выше).</P>
<H4>DWORD Characteristics</H4>
<P>То, что большая часть программистов называет флагами (flags), формат COFF/PE называет
характеристиками (characteristics). Это поле представляет собой набор флагов, которые
указывают на атрибуты секции (программа/данные, предназначен для чтения, предназначен для
записи и т.п.). За полным перечнем всех возможных атрибутов секции обращайтесь к
IMAGE_SCN_XXX_XXX defines в файле заголовка WINNT.H. Некоторые из самых важных флагов
приведены в табл. 8.1.</P>
<TABLE border="0" cellspacing="2" cellpadding="5">
<TH>Флаг</TH><TH>Использование</TH>
<TR><TD>0х00000020</TD><TD>Эта секция содержит программный код. Как правило, устанавливается
вместе с флагом (0х80000000)</TD></TR>
<TR><TD>0х00000040</TD><TD>Данная секция содержит инициализированные данные. Почти для всех
секций, кроме исполняемых и .bss секций, этот флаг установлен</TD></TR>
<TR><TD>0х00000080</TD><TD>Данная секция содержит неинициализированные данные (например, .bss
секции)</TD></TR>
<TR><TD>0х00000200</TD><TD>Данная секция содержит комментарии или какой-нибудь другой вид
информации. Типичное использование такой секции — это секция .drectve,
создаваемая компилятором и содержащая команды для компоновщика</TD></TR>
<TR><TD>0х00000800</TD><TD>Содержимое данной секции не должно быть помещено в конечный
ЕХЕ-файл. Такая секция используется компилятором/ассемблером для передачи
информации компоновщику</TD></TR>
<TR><TD>0х02000000</TD><TD>Данную секцию можно отбросить, так как она не используется
программой, после того как последняя загружена. Чаще всего встречается
отбрасываемая секция — это секция базовых поправок (.reloc)</TD></TR>
<TR><TD>0х10000000</TD><TD>Данная секция является совместно используемой. При использовании с
DLL данные в такой секции используются совместно всеми процессами,
использующими эту DLL. По умолчанию секции данных не являются совместно
используемыми, т.е. каждый процесс, использующий DLL, имеет свою собственную
отдельную копию такой секции данных. Говоря более техническим языком,
совместно используемая секция дает указание менеджеру памяти устанавливать
отображение страниц для этой секции так, что все процессы, использующие DLL,
ссылаются на одну и ту же физическую страницу в памяти. Чтобы сделать секцию
совместно используемой, установите атрибут SHARED во время компоновки.
Например: LINK/SECTION:MYDATA,RWS... указывает компоновщику, что секция с
названием MYDATA должна быть доступной для чтения, записи и совместно
используемой. По умолчанию сегменты данных DLL Borland C++ имеют атрибуты
совместного использования</TD></TR>
<TR><TD>0х20000000</TD><TD>Данная секция является исполняемой. Этот флаг обычно устанавливается
каждый раз, когда устанавливается флаг "Программа" (Contains Code)
(0х00000020)</TD></TR>
<TR><TD>0х40000000</TD><TD>Данная секция предназначена для чтения. Этот флаг почти всегда
установлен для секций ЕХЕ-файлов</TD></TR>
<TR><TD>0х80000000</TD><TD>Данная секция предназначена для записи. Если этот флаг не установлен
в секции ЕХЕ-файла, загрузчик должен отметить отображенные в память страницы
как предназначенные только для чтения или только для исполнения. Типичные
секции с этим атрибутом — это .data и .bss</TD></TR>
</TABLE>
<P>Таблица 8.1. Флаги COFF-секций</P>
<P>Интересно отметить, чего не хватает в информации, хранящейся в каждой секции. Во-первых,
следует обратить внимание на отсутствие любых атрибутов PRELOAD. Файловый формат NE позволяет
пользователю определять атрибуты PRELOAD для сегментов, которые должны быть загружены сразу во
время загрузки модуля. Файловый формат OS/2 2.0 LX имеет нечто похожее, что позволяет
пользователю давать указание о том, что предварительно должно быть загружено до восьми страниц.
РЕ-формат, напротив, не имеет ничего подобного. Исходя из этого, приходится заключить, что
Microsoft абсолютно уверена в исполнимости требований загрузки страниц для своих реализаций
Win32.</P>
<P>В РЕ-формате также отсутствует таблица поиска промежуточных страниц. Эквивалент
IMAGE_SECTION_HEADER в файловом формате OS/2 LX не указывает непосредственно, где находятся в
файле данные и программный код секции. Вместо этого файл формата OS/2 LX содержит таблицу
поиска страниц, определяющую атрибуты и расположение в файле определенных диапазонов страниц
внутри секции. РЕ-формат обходится без всего этого и гарантирует, что данные из секции будут
храниться непрерывно в файле. Сравнивая два формата, можно сказать, что LX-метод более гибок,
тогда как стиль РЕ намного проще в работе. Имея опыт написания программ просмотра файлов и
дизассемблеров для обоих форматов, я могу лично поручиться за это!</P>
<P>Другим благоприятным отличием РЕ-формата от более старого NE-формата является то, что
расположения элементов хранятся в виде простых смещений типа DWORD. В NE-формате расположение
практически любого элемента хранилось в виде величины сектора. Чтобы посчитать действительное
файловое смещение, нужно было сначала найти размер выравнивания в заголовке NE-файла и
перевести его в размер сектора (обычно 16 или 512 байт). Затем нужно было умножить размер
сектора на указанное смещение сектора, чтобы получить действительное файловое смещение. Если
что-нибудь по случайности не хранится в виде секторного смещения в NE-файле, оно, вероятно,
хранится как смещение относительно заголовка NE-файла. Ввиду того, что заголовок NE-файла не
находится в начале файла, пользователю приходится привлекать в свою программу файловое
смещение заголовка NE-файла. В противоположность этому РЕ-файлы определяют положение различных
элементов, используя простые смещения относительно того положения, в которое файл был
отображен в памяти. В общем, с РЕ значительно проще работать, чем с форматами NE, LX или LE
(при условии, что можно использовать отображаемые в память файлы).</P>
<H2>Часто встречающиеся секции<A name="EVHAC"></A></H2>
<P>После того как читатель получил общее представление о том, что такое секция и как секции
размещаются, можно перейти к более глубокому изучению секций, часто встречающихся в ЕХЕ- и
объектных файлах. И хотя этот перечень ни в коем случае нельзя назвать исчерпывающим, он, тем
не менее, включает секции, с которыми пользователь сталкивается ежедневно (даже если он об этом
и не подозревает). Секции представлены в порядке важности и в соответствии с вероятной частотой
их появления.</P>
<H3>Секция .text<A name="E1HAC"></A></H3>
<P>В этой секции собран весь программный код общего назначения, генерируемый компилятором или
ассемблером. Поскольку РЕ-файлы работают в 32-разрядном режиме и не привязаны к 16-разрядным
сегментам, нет необходимости разбивать программный код из разных исходных файлов по разным
секциям. Вместо этого компоновщик объединяет все секции .text из различных объектных файлов в
одну большую секцию .text в ЕХЕ-файле. Компилятор Borland C++ помещает весь программный код в
сегмент с названием CODE. Таким образом, РЕ-файлы, созданные с помощью Borland C++, имеют
секцию с названием CODE вместо секции .text. (См. в этой главе раздел "Секции CODE и .icode
Borland" для уточнения деталей.)</P>