Полное описание Windows изнутри

Привет всем обитателям WASM.ru!

Где можно подробно прочитать(подробнейшая книга,не статья)
про описание KUSER_SHARED_DATA и подобной хрени, имеется куча статей,
понятно, что они все писаны по оригиналу, определенной книге,являющейся
фундаментальной, посоветуйте пока есть в наличии свободное время смогу
прочитать и наконец понять что и как существует, пока знания несколько
пространственные.
Завтра пойду в книжный и по вашему совету потрачу н-ную сумму.

1)Внимание без флуда пожалуйста
2) И не надо говорить что вопросы провоцируют на флуд
3) Просто "сказал" как отрезал и все

 

wrk
wdk
msdn

 

М. Руссинович, Д. Соломон "Внутреннее устройство Microsoft Windows 2000/XP/2003 Server".

 

"Microsoft Windows Internals" уже не кошерно?

 

Aspire
Эх, не успел... )))

 

ohne
исходники винды забыл

 

Coderess
Руссинович,Соломон;

откуда такие выводы?)) мои статьи, например, больше, чем наполовину из результатов реверсинга состоят. а общие слова, действительно, по руссиновичу

 

Выкинь нах, юзоем хидеры:

Код (Text):

1. typedef struct _KUSER_SHARED_DATA {
2.  
3.     //
4.     // Current low 32-bit of tick count and tick count multiplier.
5.     //
6.     // N.B. The tick count is updated each time the clock ticks.
7.     //
8.  
9.     ULONG TickCountLowDeprecated;
10.     ULONG TickCountMultiplier;
11.  
12.     //
13.     // Current 64-bit interrupt time in 100ns units.
14.     //
15.  
16.     volatile KSYSTEM_TIME InterruptTime;
17.  
18.     //
19.     // Current 64-bit system time in 100ns units.
20.     //
21.  
22.     volatile KSYSTEM_TIME SystemTime;
23.  
24.     //
25.     // Current 64-bit time zone bias.
26.     //
27.  
28.     volatile KSYSTEM_TIME TimeZoneBias;
29.  
30.     //
31.     // Support image magic number range for the host system.
32.     //
33.     // N.B. This is an inclusive range.
34.     //
35.  
36.     USHORT ImageNumberLow;
37.     USHORT ImageNumberHigh;
38.  
39.     //
40.     // Copy of system root in unicode.
41.     //
42.  
43.     WCHAR NtSystemRoot[260];
44.  
45.     //
46.     // Maximum stack trace depth if tracing enabled.
47.     //
48.  
49.     ULONG MaxStackTraceDepth;
50.  
51.     //
52.     // Crypto exponent value.
53.     //
54.  
55.     ULONG CryptoExponent;
56.  
57.     //
58.     // Time zone ID.
59.     //
60.  
61.     ULONG TimeZoneId;
62.     ULONG LargePageMinimum;
63.     ULONG Reserved2[7];
64.  
65.     //
66.     // Product type.
67.     //
68.  
69.     NT_PRODUCT_TYPE NtProductType;
70.     BOOLEAN ProductTypeIsValid;
71.  
72.     //
73.     // The NT Version.
74.     //
75.     // N. B. Note that each process sees a version from its PEB, but if the
76.     //       process is running with an altered view of the system version,
77.     //       the following two fields are used to correctly identify the
78.     //       version
79.     //
80.  
81.     ULONG NtMajorVersion;
82.     ULONG NtMinorVersion;
83.  
84.     //
85.     // Processor features.
86.     //
87.  
88.     BOOLEAN ProcessorFeatures[PROCESSOR_FEATURE_MAX];
89.  
90.     //
91.     // Reserved fields - do not use.
92.     //
93.  
94.     ULONG Reserved1;
95.     ULONG Reserved3;
96.  
97.     //
98.     // Time slippage while in debugger.
99.     //
100.  
101.     volatile ULONG TimeSlip;
102.  
103.     //
104.     // Alternative system architecture, e.g., NEC PC98xx on x86.
105.     //
106.  
107.     ALTERNATIVE_ARCHITECTURE_TYPE AlternativeArchitecture;
108.  
109.     //
110.     // If the system is an evaluation unit, the following field contains the
111.     // date and time that the evaluation unit expires. A value of 0 indicates
112.     // that there is no expiration. A non-zero value is the UTC absolute time
113.     // that the system expires.
114.     //
115.  
116.     LARGE_INTEGER SystemExpirationDate;
117.  
118.     //
119.     // Suite support.
120.     //
121.  
122.     ULONG SuiteMask;
123.  
124.     //
125.     // TRUE if a kernel debugger is connected/enabled.
126.     //
127.  
128.     BOOLEAN KdDebuggerEnabled;
129.  
130.     //
131.     // NX support policy.
132.     //
133.  
134.     UCHAR NXSupportPolicy;
135.  
136.     //
137.     // Current console session Id. Always zero on non-TS systems.
138.     //
139.  
140.     volatile ULONG ActiveConsoleId;
141.  
142.     //
143.     // Force-dismounts cause handles to become invalid. Rather than always
144.     // probe handles, a serial number of dismounts is maintained that clients
145.     // can use to see if they need to probe handles.
146.     //
147.  
148.     volatile ULONG DismountCount;
149.  
150.     //
151.     // This field indicates the status of the 64-bit COM+ package on the
152.     // system. It indicates whether the Intermediate Language (IL) COM+
153.     // images need to use the 64-bit COM+ runtime or the 32-bit COM+ runtime.
154.     //
155.  
156.     ULONG ComPlusPackage;
157.  
158.     //
159.     // Time in tick count for system-wide last user input across all terminal
160.     // sessions. For MP performance, it is not updated all the time (e.g. once
161.     // a minute per session). It is used for idle detection.
162.     //
163.  
164.     ULONG LastSystemRITEventTickCount;
165.  
166.     //
167.     // Number of physical pages in the system. This can dynamically change as
168.     // physical memory can be added or removed from a running system.
169.     //
170.  
171.     ULONG NumberOfPhysicalPages;
172.  
173.     //
174.     // True if the system was booted in safe boot mode.
175.     //
176.  
177.     BOOLEAN SafeBootMode;
178.  
179.     //
180.     // The following field is used for heap and critcial sectionc tracing. The
181.     // last bit is set for critical section collision tracing and second last
182.     // bit is for heap tracing.  Also the first 16 bits are used as counter.
183.     //
184.  
185.     ULONG TraceLogging;
186.  
187.     //
188.     // Depending on the processor, the code for fast system call will differ,
189.     // Stub code is provided pointers below to access the appropriate code.
190.     //
191.     // N.B. The following two fields are only used on 32-bit systems.
192.     //
193.  
194.     ULONGLONG TestRetInstruction;
195.     ULONG SystemCall;
196.     ULONG SystemCallReturn;
197.     ULONGLONG SystemCallPad[3];
198.  
199.     //
200.     // The 64-bit tick count.
201.     //
202.  
203.     union {
204.         volatile KSYSTEM_TIME TickCount;
205.         volatile ULONG64 TickCountQuad;
206.     };
207.  
208.     //
209.     // Cookie for encoding pointers system wide.
210.     //
211.  
212.     ULONG Cookie;
213.    
214.     //
215.     // Shared information for Wow64 processes.
216.     //
217.    
218.     ULONG Wow64SharedInformation[MAX_WOW64_SHARED_ENTRIES];
219.  
220. } KUSER_SHARED_DATA, *PKUSER_SHARED_DATA;

 

а зачем? ты хочешь пропустить через мозг то, что накодили несколько сотен человек за 10 лет - и не все из них были в здравом уме ...

проще написать свою операционку, наверное... пусть она будет не такая крутая, зато - будешь всё в ней знать - по этой причине до сих пор существует сообщество програмистов в Синклере - тусуются, общаются ...

 

Blackbeam
пожалуйста, не надо на вопросы "как в винде..." отвечать "выкини винду". Ребячество это

 

Great Не. Меня вот его ответ в ступор надолго ввел. Он конечно слишком категоричный, но иногда для того, чтобы что-то понять нужно довести это что-то до абсурда.

 

Изучение даже плохой ОС является неплохим способом набраться опыта: по крайней мере, будешь знать, как можно, но не нужно писать ОС Однако само понятие "плохая ОС" (ну или "плохая программа" вообще) достаточно расплывчато. Например, в плохо спроектированной ОС могут быть фрагменты прекрасно написанного кода, а хорошо спроектированная, наоборот, может быть реализована безобразно.

Что же касается собственно темы, то многое зависит от глубины первоначальных знаний. ОС -- это именно _система_, её надо изучать в комплексе, а для этого нужно иметь представление "верхнего уровня" и постепенно копать вниз. Соломон-Руссинович именно этот "верхний уровень" и дают, и дают весьма неплохо. "Средний уровень" -- это описание API, по большому счёту, но не просто список функций с параметрами, а с объяснениями, к каким последствиям эти вызовы приводят для программы, как функции API между собой связаны и т.д. Ну а как всё реализовано в самом низу -- тут да, нужны (в идеале) исходники и проектная документация на систему. Однако, к примеру, бесполезно пытаться разобраться со структурами данных, используемыми для управления памятью, если не знать, как же вообще ОС управляет этой самой памятью с точки зрения программиста-прикладника (как делится адресное пространство, какие возможности совместного использования памяти присутствуют, как память выделяется-освобождается и т.п.). Именно поэтому нельзя сказать, что книга такая-то является наилучшей: для одного человека на данном историческом этапе наилучшим будет одно, для другого -- другое...

 

Aspire
Доведение до абсурда - плохое поведение.


SII
Ну в общем да, нужно начинать сверху и спускаться вниз. Так и изучается все обычно.

 

А че бы не снизу? Там загрузочная запись, адресация памяти, переключение режимов, прерывания.. и тд.. потом потоки, синхронизация и прочее?

 

Aspire
Приведу другой пример
Никогда никому не советовал начинать кодить с ассемблера. Большинство ни черта не понимают и так и не поймут, потому что сочтут программирование чрезвычайно сложным занятием.
Все изучают от простого к сложному. От общего к частному. И так далее - это стандартная практика. Не надо переворачивать мир с ног на голову.

 

Aspire

Потому что будет неясно, а на кой ляд это нужно, где и как используется и прочая и прочая. Кроме того, подобные вещи специфичны для конкретной архитектуры. Если человек не знает вообще, что такое виртуальная память, зачем она нужна и как работает при взгляде "с высоты птичьего полёта", нафиг ему сразу забивать голову конкретными форматами управляющих структур, используемыми конкретным процессором? Ему надо сначала понять саму идею, а затем уже, если понадобится, спускаться вниз, к реализации этого механизма на конкретной архитектуре. Или зачем ему сразу погружаться в переключение режимов ИА-32, если он вообще ещё не знает об их существовании и тем более о назначении?

В общем, ассемблер плох тем, что в нём обычно легко понять, что делается, но сложно -- для чего делается. Не надо быть особо гениальным, чтобы запомнить: MOV пересылает данные из одного места в другое, ADD складывает, SUB вычитает... Но вот из мешанины этих и им подобных команд понять, например, идею алгоритма быстрой сортировки куда сложнее, чем при его записи на языке высокого уровня и тем более чем по изложению этого же алгоритма на обычном русском языке -- когда раскрывается именно идея, смысл тех или иных действий, а не всякие низкоуровневые подробности.

 

Прошу прощения за не конструктивную оценку выше(был в вакууме, есчо немного мутно..).
Вобщем Руссиновича доки вполне не плохи, но там весьма поверхностно всё описано. У меня например подход следующий. Необходимо узнать какойто механизм, постепенно разбираются все его нюансы, код и структуры с ним связанные, из сурцов, но по большей части реверсом, некоторые факты берутся из какихто сторонних источников. После накопления множества отдельных фактов всё сложится в одну систему. Изучать очень подробные механизмы по докам просто читая всё подряд думаю не стоит, следует рассматривать интересные вещи.

По сути я когдато с этого и начинал. Ось размещающаяся в 16к ром, где половину её занимал програмный сопроцессор математики, а остальную часть интерпретатор была хороша. И коденг под неё весьма доставлял. Кстати многие идеи оттуда взяты.

 

Clerk
> После накопления множества отдельных фактов всё сложится в одну систему.
> Изучать очень подробные механизмы по докам просто читая всё подряд
> думаю не стоит, следует рассматривать интересные вещи.
согласен, поскольку "от простого к сложному" не отрицает "от сложного к простому", а потому лучше всего двигаться к солотой середине познания с двух направлений. уже виртуальную память можно рассматривать и на уровне общих концепций абстрактной оси и на уровне конкретных структур конкретного процессора. причем, не по очереди, а сразу

эххх.... было же золотое время в эпоху ms-dos, когда после программирования флоповода на уровне портов ввода/вывода мы вытирали пыль с головы, а сейчас все стало действительно очень сложным. учебников по асму нет, а тех что есть начинают сначала с реального режима, потом говорят: забудьте, скомканно объясняют защищенный и дают примеры на асме, сводящиеся к вызову api функций, опустив подробности испорта и подгрузки динамических библиотек.

 

как бы Руссионвич помогает задать направление исследования.
Например, нужно мне было посмотреть как устроено LPC, сначала почитал у Руссиновича, потом посмотрел соответствующие сорцы, и в общем более-менее начал понимать механизм.
А когда написал несколько тестовых програм, то вообще все стало хорошо

 

2 n0name:
И што именно стало то хорошо ? ;(

Кстати, никто не в курсе, а на кой ляд вообще этот LPC нужон то?? Типа чтобы отрисовывать окошки побыстрее ? Дааааcc, это отличная тема в M$-development