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

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

O>> Давно задаюсь вопросом, почему в отечественной литературе
O>>так мало внимания уделяется низкоуровневому программированию
O>>Windows. Создается такое впечатление, что это никому не надо
O>>и вовсе неактуально. Но, на мой взгляд, низкая популярность
O>>Kernel Mode Programming связана предже всего с недостаточным
O>>количеством русскоязычной документации и литературы. Кроме того,
O>>я думаю, что навыки программирования в режиме ядра должен иметь
O>>каждый программист, ибо техники, применяемые там, требуют аккуратности
O>>и тем самым прививают качественный стиль программирования. Судите сами,
O>>если вы функцией ExAllocatePool выделите блок памяти и забудете освободить
O>>его при помощи ExFreePool, система вполне может показать синий экран. В то же
O>>время прожужжавшая уши парадигма managed code технологии .NET остается для меня,
O>>магко говоря, непонятной, т.к. сама подталкивает программиста к набрежному расходу ресурсов, тем самым воспитывая неряшливый стиль. Кроме того, на данный момент она остается крайне ресурсоемкой и практически непригодной для разработки критичный по скорости приложений.
O>> Господа посетители RDSN, хочу узнать ваше мнение на этот счет.

VD>Блин, еще один! Держите меня семеро, а то ведь покусаю.

VD>Как достали эти неофиты каменного века? Мы тут о высоких материях. Об управляемых ОС, об типобезопасности, надежности... А они... ааааааааааааааааа...........

Для создания полноценной управляемой ОС необходима поддержка концепции managed code
на аппаратном уровне. А пока основой всех ОС являются микропроцессоры Intel и AMD с их
ассемблером, любые "высокие материи" будут только ухудшать производительность. По предварительным данным, требования Vista к железу сильно возросли. А это может означать, что там, где "летала" ХР, Vista будет чудовищно тормозить.

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

O>Для создания полноценной управляемой ОС необходима поддержка концепции managed code на аппаратном уровне.
Нет не нужно. Болие того когда управляемые ОС станут доминировать произвордители железа смогут выпускать процессоры без обратной совместимости ибо эту совместимость будет осуществлять ОС.
O>А пока основой всех ОС являются микропроцессоры Intel и AMD с их ассемблером, любые "высокие материи" будут только ухудшать производительность.
Ошибаешся. Singularity работает очень шустро благодоря тому что может инлайнить системные вызовы. И это при том что Singularity иследовательский проект и его по скорости никто не оптимизировал.
O>По предварительным данным, требования Vista к железу сильно возросли. А это может означать, что там, где "летала" ХР, Vista будет чудовищно тормозить.
А какое отношения имеет Vista к управляемым ОС? Чтоб ты знал Vista это доработаная Win2003.

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

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

O>>Для создания полноценной управляемой ОС необходима поддержка концепции managed code на аппаратном уровне.
WH>Нет не нужно. Болие того когда управляемые ОС станут доминировать произвордители железа смогут выпускать процессоры без обратной совместимости ибо эту совместимость будет осуществлять ОС.
O>>А пока основой всех ОС являются микропроцессоры Intel и AMD с их ассемблером, любые "высокие материи" будут только ухудшать производительность.
WH>Ошибаешся. Singularity работает очень шустро благодоря тому что может инлайнить системные вызовы. И это при том что Singularity иследовательский проект и его по скорости никто не оптимизировал.
O>>По предварительным данным, требования Vista к железу сильно возросли. А это может означать, что там, где "летала" ХР, Vista будет чудовищно тормозить.
WH>А какое отношения имеет Vista к управляемым ОС? Чтоб ты знал Vista это доработаная Win2003.

Т.е. хотите сказать, что весь UserMode (Я уж не говорю о ядре. Поначалу думал, что с выходом Vista смогу писать дрова на С#, ан нет...) будет обслуживать функционал WinAPI, а не .NET Framework. А я то думал, что WinAPI будут оставлены лишь для обратной совместимости. Вот, как говорится, и приехали. Так что теория теорией, а факты весчь упрямая — .NET Framework продолжает оставаться фикцией.

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

O>Т.е. хотите сказать, что весь UserMode (Я уж не говорю о ядре. Поначалу думал, что с выходом Vista смогу писать дрова на С#, ан нет...) будет обслуживать функционал WinAPI, а не .NET Framework.
Похоже ты просто не понимаешь что такое управляемая ОС. Читай про Singularity до просветления.
O>А я то думал, что WinAPI будут оставлены лишь для обратной совместимости.
Нет это всеще основной API однако некоторые вещи будут доступны только из .NET.
O>Вот, как говорится, и приехали. Так что теория теорией, а факты весчь упрямая — .NET Framework продолжает оставаться фикцией.
А мужики то и незнали... и от этого незнания написали гигабайты кода на C#, а оказывается это все фикция...

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


O>Т.е. хотите сказать, что весь UserMode (Я уж не говорю о ядре. Поначалу думал, что с выходом Vista смогу писать дрова на С#, ан нет...) будет обслуживать функционал WinAPI, а не .NET Framework. А я то думал, что WinAPI будут оставлены лишь для обратной совместимости. Вот, как говорится, и приехали. Так что теория теорией, а факты весчь упрямая — .NET Framework продолжает оставаться фикцией.


Это что же получается, что последние 3 года наша контра занимается фикцией? И еще тысячи других контор.

Я достаточно программировал и под Win32 на голом С, и под MFC и на билдере пришлось и на дельфи. Так вот если понадобиться писать GUI, богатый функциональностью я скорее возьму .NET Framework и решу задачу на нем за неделю, чем буду 2 недели только проектировать интерфес на чистом Win32.

Если мне надо будет написать что то, что плотно работает Win32API, то я напишу библиотеку на С++ и оформлю ее скорее всего в виде СОМ( или МС++ ) и буду с успехом использовать ее из .NET. И делать это буду на VS2005 потому что это удобней и быстрее, а не потому что это круче и модно.

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

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

O>Для создания полноценной управляемой ОС необходима поддержка концепции managed code на аппаратном уровне. А пока основой всех ОС являются микропроцессоры Intel и AMD с их ассемблером, любые "высокие материи" будут только ухудшать производительность. По предварительным данным, требования Vista к железу сильно возросли. А это может означать, что там, где "летала" ХР, Vista будет чудовищно тормозить.

По предварительным данным, Vista — это следующая версия ОС семейства NT. Она не содержит в себе ни строчки управляемого кода. 100% кода Vista является неуправляемым и не безопасным.

По подтвержденным данным, Singularity содержит 98% управляемого управляемого кода причем более 70% кода является полностью безопасным упаравляемым кодом.

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

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


O>Для создания полноценной управляемой ОС необходима поддержка концепции managed code
O>на аппаратном уровне. А пока основой всех ОС являются микропроцессоры Intel и AMD с их
O>ассемблером, любые "высокие материи" будут только ухудшать производительность. По предварительным данным, требования Vista к железу сильно возросли. А это может означать, что там, где "летала" ХР, Vista будет чудовищно тормозить.

Ещё, как следствие, в управляемой ОС должны быть каие-нить "делегаты" на interrupt-handlers

PS Но я себе это плохо представляю, может годку к 2099 все прояснится

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

S>Ещё, как следствие, в управляемой ОС должны быть каие-нить "делегаты" на interrupt-handlers
S>PS Но я себе это плохо представляю, может годку к 2099 все прояснится
Читай про Singularity до просветления. (С)Я

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

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

S>>Ещё, как следствие, в управляемой ОС должны быть каие-нить "делегаты" на interrupt-handlers
S>>PS Но я себе это плохо представляю, может годку к 2099 все прояснится
WH>Читай про Singularity до просветления. (С)Я

Если не сложно то цитату плз оттуда, где про обработчики прерываний грится.

Уже блин ЗАДОЛБАЛИ с этой ЭКСПЕРЕМЕНТАЛЬНО Сверхсекретной ОС.

Если она вся компилится до загрузки, то причем здесь managed ?
Что делать при закачке ПО из инета ? Перегружаться ?

Вот когда можно будет её пощупать — тогда и буду просвящаться, годку так в 2099

ЗЫ Ставьте минусы, но уже задолбали разговоры .Net чиков про эту мифическую мегаОсь, не на ней ли Земля крутится ??????

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

S>Если не сложно то цитату плз оттуда, где про обработчики прерываний грится.

An interrupt from a device is serviced by the kernel, which masks the interrupt, and then signals the appropriate driver’s IoIrq. Each driver process has a thread waiting on its Irq event, which starts processing the interrupt and re-enables the interrupt line through a kernel ABI. The scheduler runs immediately after the interrupt handler and signals all events in this queue.

Легче стало? Для того чтбы понять как оно работает надо прочитать доку. С моей точки зрения чтиво весьма полезное ибо показывает весьма другие взгляды как на ОС так и на софт вобще.
Причем в отличии от ОберонОС эту операционку можно довести до рабочего состояния.
S>Уже блин ЗАДОЛБАЛИ с этой ЭКСПЕРЕМЕНТАЛЬНО Сверхсекретной ОС.
Спокойствие только спокойствие.(С)

S>Если она вся компилится до загрузки, то причем здесь managed ?
Это где написано? Полностью компилируется только процесс но не вся операционка.
S>Что делать при закачке ПО из инета ? Перегружаться ?
Может не надо говорить глупости о том о чем и представления не имеешь?

S>Вот когда можно будет её пощупать — тогда и буду просвящаться, годку так в 2099
Я думаю это случится гораздо раньше.

S>ЗЫ Ставьте минусы, но уже задолбали разговоры .Net чиков про эту мифическую мегаОсь, не на ней ли Земля крутится ??????
Пока нет но зная Билла...

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

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

WH>

An interrupt from a device is serviced by the kernel, which masks the interrupt, and then signals the appropriate driver’s IoIrq. Each driver process has a thread waiting on its Irq event, which starts processing the interrupt and re-enables the interrupt line through a kernel ABI. The scheduler runs immediately after the interrupt handler and signals all events in this queue.

Я говорил именно об обработчиках прерывания, а не об апи, которое накручено над нимим

WH>Легче стало? Для того чтбы понять как оно работает надо прочитать доку. С моей точки зрения чтиво весьма полезное ибо показывает весьма другие взгляды как на ОС так и на софт вобще.
WH>Причем в отличии от ОберонОС эту операционку можно довести до рабочего состояния.

Тут спорить трудно, я только ЗА.


S>>Если она вся компилится до загрузки, то причем здесь managed ?
WH>Это где написано? Полностью компилируется только процесс но не вся операционка.
Singularity — первожу на русски

Автор: mihailik
Дата: 12.01.06

Из перевода:

.NET Framework? Нет!

В отличие от распространённой сказки, на самом деле в Singularity нет никакого CLR. Singularity не может запускать IL-код.

Ещё раз для тех, кто сомневается в правильности букв: НЕ МОЖЕТ ЗАПУСКАТЬ IL-КОД.

Да, всё написано на C#. Но это не значит, что в Singularity есть JIT. Его нет. Код C# компилируется заранее и в момент загрузки системы все приложения уже скомпилированы в машинных кодах.

Это очень важный момент для понимания!

Для установки приложения, или драйвера в Singularity, код C# будет скомпилирован в конечный бинарный машинный код. И это должно произойти ДО загрузки.

Таким образом, здесь мы не имеем традиционной дотнетовской философии JIT, Assembly binding. Приложение компилируется целиком, со всеми библиотеками. При этом происходит полная оптимизация — компилятор знает о всех использованиях всех классов. Может выкидывать ненужный код даже из системных библиотек. Может делать виртуальные вызовы невиртуальными, если известно, что у класса больше нет наследников. Доступны очень "злые" инлайны...

Может переводчик и ошибся, но маловероятно.

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

S>Я говорил именно об обработчиках прерывания, а не об апи, которое накручено над нимим
В том то и весь смысл. Драйверы работают только через безопасный API, а компилятор при компиляции драйвера проверяет все что может (а он может проверить очень много) после чего происходит (или будет происходить об этом точно не сказано) инлайн всего чего можно и работа идет непосредственно с железом. Компиляция драйвера/программы происходит при инсталяции после проверки на совместимость с окружением.

S>Может переводчик и ошибся, но маловероятно.
Переводчик полностью переврал статью. Вернее слова те но смысл совсем не тот.
Смысл в том что монолитно компилируется процесс, а не вся операционка. Каждый драйвер и программа работает в своем полностью изолированном процессе(или процессах).
Процессы общаются между собой только через строготипизированные каналы.
Тяжолые данные пересылают через

3.3.2 Exchange Heap
The Exchange Heap, which underlies efficient communication in Singularity, holds data passed between processes (Figure 2). The Exchange Heap is not garbage collected, but instead uses reference counts to track usage of blocks of memory called regions. A process accesses a region through a structure called an allocation.
Allocations also reside in the Exchange Heap, which enables them to be passed between processes, but each is owned and accessible by a single process at a time. More than one allocation may share read-only access to an underlying region. Moreover, the allocations can have different base and bounds, which provide distinct views into the underlying data. For example, protocol processing code in a network stack can strip the encapsulated protocol headers off a packet without copying it. A region tracks the number of allocations that point to it, and it is deallocated when this reference count falls to zero. The Singularity compiler hides the extra level of indirection through an allocation record by strongly typing references into a region and automatically generating code to dereference through the record.

Причем через Exchange Heap и каналы (которые вобщемто через Exchange Heap и работают) могут передоваться только value типы или массивы которые прямо или косвенно не содержат ссылок.
Что гарантирует изоляцию объектных пространств различных процессов. А это в свою очередь дает возможность творить в каждом процессе то что хочется например в ядре использован concurrent mark-sweep garbage collector у которого пауза порядка 100 микросекунд, а в пользовательских процессах использован просто mark-sweep garbage collector у него накладные расходы меньше. А если программе вероятнее всего драйверу не нужна динамическая память то ГЦ для этого процесса можно вобще отключить.

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

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

S>Ещё, как следствие, в управляемой ОС должны быть каие-нить "делегаты" на interrupt-handlers

S>PS Но я себе это плохо представляю, может годку к 2099 все прояснится

Вольфаунд дело говорит. Прочти статью. Там все написано. В том числе приведен API (они называют его ABI) ядра из которого все ясно.

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

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

WH>В том то и весь смысл. Драйверы работают только через безопасный API, а компилятор при компиляции драйвера проверяет все что может (а он может проверить очень много) после чего происходит (или будет происходить об этом точно не сказано) инлайн всего чего можно и работа идет непосредственно с железом. Компиляция драйвера/программы происходит при инсталяции после проверки на совместимость с окружением.
Ещё раз подчеркну — я вел речь не об апи, а о тех самых хендерах которые находятся в таблице прерываний, про АПИ и так понятно, практически любая ОС наворачивает свои АПИ с котороыми и взаимодействую дрова, если же нет, то имеются хелперы.

S>>Может переводчик и ошибся, но маловероятно.
WH>Переводчик полностью переврал статью. Вернее слова те но смысл совсем не тот.

Дык а отчего же не налепить минусов на эту статью, тем кто владеет вопросом ?
Человек( я, например ) смотрит, статья по модной нынче на РСДН теме, стоят положительные баллы, какжне не поверить в правдивость ?


WH>Вобщем дизайн операционки выполнен с особым цинизмом, а документ всетки стоит прочитать там много чего интересного.

+1

Убедили, скачал я его, сегодня буду дома изучать

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

Я только одного не понял в этой фигне... А как я смогу сменить, скажем, текущий рендерер для своего GUI? (предположим, у меня скины можно менять). Я же не смогу загрузить другую DLL?

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

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

V>Я только одного не понял в этой фигне... А как я смогу сменить, скажем, текущий рендерер для своего GUI? (предположим, у меня скины можно менять). Я же не смогу загрузить другую DLL?
Это действительно самое спорное место во всей архитектуре. Но у этого решения есть как минусы так и плюсы.
В данном случае выносишь рендер в отдельный процесс.

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

V>Я только одного не понял в этой фигне... А как я смогу сменить, скажем, текущий рендерер для своего GUI? (предположим, у меня скины можно менять). Я же не смогу загрузить другую DLL?

Тут один момент, мне кажется, выпал из рассмотрения — Барток это не компилятор C#!!! Барток это компилятор из MSIL в х86. Т.е. те процессы генерации и верификации типа CTR (Compile Time Reflection) производятся не в момент компиляции, а в момент инсталляции сборки (или, что возможно, в момент первого использования). Таким образом динамическая загрузка кода возможна.
Теперь что действительно невозможно — невозможно добавление нового кода в процесс. Т.е. в момент запуска процесса весь код (в том числе и куски ядра ОС!) собирается в единый монолит. Что же предлагается для динамической подгрузки — предлагается для каждого плагина создавать новый процесс (SIP). Учитывая, что межпроцессная коммуникация в Сингулярити штука дешевая и удобная, предполагается что таким образом будет достигнута высокая степень изоляции без значительного программного и аппаратного оверхеда.
Вот что говорят об этом авторы:

Software creators rarely anticipate the full functionality demanded by users of their system
or application. Rather than trying to satisfy everyone with a monolithic system, most non-trivial
software provides mechanisms to load additional code. For example, Microsoft Windows
supports over 100,000 third party device drivers, which enable it to control almost any hardware
device. Similarly, countless browser add-ons and extensions augment a browser’s interface and
components for web pages. Even open source projects—although theoretically modifiable—
5
provide “plug-in” mechanisms, since extensions are easier to develop, distribute, and combine
than new versions of software.
An extension usually consists of code that is dynamically loaded into its parent’s address
space. With direct access to the parent’s internal interfaces and data structures, extensions can
provide rich functionality. However, flexibility comes at a high cost. Extensions are a major
cause of software reliability, security, and backward compatibility problems. Although extension
code is often untrusted, unverified, faulty, or even malicious, it is loaded directly into a program’s
address space with no hard interface, boundary, or distinction between host and extension. The
outcome is often unpleasant. For example, Swift reports that faulty device drivers cause 85% of
diagnosed Windows system crashes [49]. Moreover, because an extension lacks a hard interface,
it can use unexposed aspects of its parent’s implementation, which can constrain evolution of a
program and require extensive testing to avoid incompatibilities.
Dynamic code loading imposes a second, less obvious tax on performance and correctness.
Software that can load code is an open environment in which it is impossible to make sound
assumptions about the system’s states, invariants, or valid transitions. Consider the Java virtual
machine (JVM). An interrupt, exception, or thread switch can invoke code that loads a new file,
overwrites class and method bodies, and modifies global state [47]. In general, the only feasible
way to analyze a program running under such conditions is to start with the unsound assumption
that the environment cannot change arbitrarily between any two operations.
One alternative is to prohibit code loading and isolate dynamically created code in its own
environment. Previous attempts along these lines were not widely popular because the isolation
mechanisms had performance and programmability problems that made them less appealing than
the risks of running without isolation. The most common mechanism is a traditional OS process,
but its high costs limit its usability. Memory management hardware provides hard boundaries and
protects processor state, but it also makes inter-process control and data transfers expensive. On
an x86 processor, switching between processes can cost hundreds to thousands of cycles, not
including TLB and cache refill misses [25].
More recent systems, such as the Java virtual machine and Microsoft Common Language
Runtime (CLR), are designed for extensibility and use language safety, not hardware, as the
mechanism to isolate computations running in the same address space. Safe languages, by
themselves, do not guarantee isolation. Shared data can provide a navigable path between
computations’ object spaces, at which point reflection mechanisms can subvert data abstraction
and information hiding. As a consequence, these systems incorporate complex security
mechanisms and policies, such as Java’s fine grain access control or the CLR’s code access
security, to limit access to system mechanisms and interfaces [40]. These mechanisms are
difficult to use properly and impose considerable overhead.
Equally important, computations that share a run-time system and execute in the same
process are not isolated upon failure. When a computation running in a JVM fails, the entire JVM
process typically is restarted because it is difficult to isolate and discard corrupted data and find a
clean point to restart the failed computation [11].
Singularity uses SIPs to encapsulate. Every device driver, system process, application, and
extension runs in its own SIP and communicates over channels that provide limited and
appropriate functionality. If code in a SIP fails, it terminates, which allows the system to reclaim
resources and notify communication partners. Since these partners did not share state with the
extension, error recovery is entirely local and is facilitated by the explicit protocols on channels.
Another run-time source of new code is dynamic code generation, commonly encapsulated
in a reflection interface. This feature allows a running program to examine existing code and data,
6
and to produce and install new methods. Reflection is commonly used to produce marshalling
code for objects or parsers for XML schemas. Singularity’s closed SIPs do not allow run-time
code generation.
Instead, Singularity provides compile-time reflection (CTR), which provides similar
functionality that executes when a file is compiled. Normal reflection, which has access to runtime
values, is more general than CTR. However, in many cases, the class to be marshaled or the
schemas to be parsed are known ahead of execution. In these cases, CTR produces code during
compilation. In the other cases, Singularity will support a mechanism for generating code and
running it in a separate SIP.

P.S. Лично меня пока их идеи не воодушевляют, но окончательное суждение я пока не составил за недостаточностью информации.

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

WH>В данном случае выносишь рендер в отдельный процесс.

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