Здравствуйте, niXman, Вы писали:
X>привет!
X>собираю прогу при помощи MinGW-W64, которая использует Qt5, которая, в свою очередь, собрана там же MonGW`ом.
X>открываю свой exe`шник в dependency walker и вижу такое: X>Image: image.png
X>ни одна из этих dll`ок не является прямой зависимостью ни моей exe`шки, ни моих dll`ок.
X>вопроса у меня два: X>1. раз уж эти dll`ки не являются моими зависимостями, должен ли я их поставлять с программой? X>2. откуда брать все эти dll`ки?
они живут в системе, но настоящее название у них другое
X>спасибо.
здесь коротко расписан сам механизм и зачем он им понадобился здесь чуть подробнее с тех деталями которые вам скорее всего не нужны
Здравствуйте, rumit7, Вы писали:
R>здесь коротко расписан сам механизм и зачем он им понадобился R>здесь чуть подробнее с тех деталями которые вам скорее всего не нужны
И ради чего всё это затевалось. Что бы повысить энтропию? Разобрать ядро на часть что бы потом сделать всё как было?
Re[3]: зависимости типа api-ms-win-core-winrt-*.dll
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, rumit7, Вы писали:
R>>здесь коротко расписан сам механизм и зачем он им понадобился R>>здесь чуть подробнее с тех деталями которые вам скорее всего не нужны
_>И ради чего всё это затевалось. Что бы повысить энтропию? Разобрать ядро на часть что бы потом сделать всё как было?
кажись чтобы ядро собирать как лего под разные платформы, убирая лишнее, ставя где-то заглушки..
вот что написано про это в Windows Internals:
API Sets
While SwitchBack uses API redirection for specific application-compatibility scenarios, there is a
much more pervasive redirection mechanism used in Windows for all applications, called API Sets. Its
purpose is to enable fine-grained categorization of Windows APIs into sub-DLLs instead of having
large multipurpose DLLs that span nearly thousands of APIs that might not be needed on all types of
Windows systems today and in the future. This technology, developed mainly to support the refactoring
of the bottom-most layers of the Windows architecture to separate it from higher layers, goes
hand in hand with the breakdown of Kernel32.dll and Advapi32.dll (among others) into multiple,
virtual DLL files.
...
In splitting functions across discrete files, two objectives are achieved: first, doing this allows future
applications to link only with the API libraries that provide the functionality that they need, and
second, if Microsoft were to create a version of Windows that did not support, for example, Localization
(say a non-user-facing, English-only embedded system), it would be possible to simply remove
the sub-DLL and modify the API Set schema. This would result in a smaller Kernel32 binary, and any
applications that ran without requiring localization would still run.
With this technology, a “base” Windows system called “MinWin” is defined (and, at the source level,
built), with a minimum set of services that includes the kernel, core drivers (including file systems,
basic system processes such as CSRSS and the Service Control Manager, and a handful of Windows
services). Windows Embedded, with its Platform Builder, provides what might seem to be a similar
technology, as system builders are able to remove select “Windows components,” such as the shell, or
the network stack. However, removing components from Windows leaves dangling dependencies—
code paths that, if exercised, would fail because they depend on the removed components. MinWin’s
dependencies, on the other hand, are entirely self-contained.
Здравствуйте, rumit7, Вы писали:
R>Здравствуйте, kov_serg, Вы писали:
_>>Здравствуйте, rumit7, Вы писали:
R>>>здесь коротко расписан сам механизм и зачем он им понадобился R>>>здесь чуть подробнее с тех деталями которые вам скорее всего не нужны
_>>И ради чего всё это затевалось. Что бы повысить энтропию? Разобрать ядро на часть что бы потом сделать всё как было?
R>кажись чтобы ядро собирать как лего под разные платформы, убирая лишнее, ставя где-то заглушки..
Разные платформы: от WindowsX.нищеброд до WindowsX.дляреальныхпацанов ?
R>вот что написано про это в Windows Internals:
R>
R>API Sets
R>While SwitchBack uses API redirection for specific application-compatibility scenarios, there is a
R>much more pervasive redirection mechanism used in Windows for all applications, called API Sets. Its
R>purpose is to enable fine-grained categorization of Windows APIs into sub-DLLs instead of having
R>large multipurpose DLLs that span nearly thousands of APIs that might not be needed on all types of
R>Windows systems today and in the future. This technology, developed mainly to support the refactoring
R>of the bottom-most layers of the Windows architecture to separate it from higher layers, goes
R>hand in hand with the breakdown of Kernel32.dll and Advapi32.dll (among others) into multiple,
R>virtual DLL files.
R>...
R>In splitting functions across discrete files, two objectives are achieved: first, doing this allows future
R>applications to link only with the API libraries that provide the functionality that they need, and
R>second, if Microsoft were to create a version of Windows that did not support, for example, Localization
R>(say a non-user-facing, English-only embedded system), it would be possible to simply remove
R>the sub-DLL and modify the API Set schema. This would result in a smaller Kernel32 binary, and any
R>applications that ran without requiring localization would still run.
R>With this technology, a “base” Windows system called “MinWin” is defined (and, at the source level,
R>built), with a minimum set of services that includes the kernel, core drivers (including file systems,
R>basic system processes such as CSRSS and the Service Control Manager, and a handful of Windows
R>services). Windows Embedded, with its Platform Builder, provides what might seem to be a similar
R>technology, as system builders are able to remove select “Windows components,” such as the shell, or
R>the network stack. However, removing components from Windows leaves dangling dependencies—
R>code paths that, if exercised, would fail because they depend on the removed components. MinWin’s
R>dependencies, on the other hand, are entirely self-contained.
"enable fine-grained categorization of Windows API" -- и кому это надо? для классификации обязательно что-то разбивать?
"allows future applications to link only with the API libraries that provide the functionality that they need" -- а теперешним приложением что мешает это делать? runtime который использует то о чем вы даже не подозреваете.
Напоминает анекдот
— Вам пицу разрезать на 6 кусков или на 12.
— На 6. 12 я не съем.
Чтобы уменьшить количество физических DLL, которые необходимо загружать при старте, многие DLL в MinWin стали содержать в себе наборы функций из разных API, а это усложняло дальнейшую разработку системы. Чтобы избежать такой проблемы, наборы функций из родственных API были объединены в так называемые Виртуальные DLL.
И помимо виртуальных, остаются и обычные dll где всё это лежит. И на них ссылаться никто не мешает.
И как обычно это позволяет уменьшить объём операционки, например выкидываем какой-нибудь не нужный Localization и получаем ужоснах.
Re[5]: зависимости типа api-ms-win-core-winrt-*.dll
Здравствуйте, kov_serg, Вы писали:
_>>>И ради чего всё это затевалось. Что бы повысить энтропию? Разобрать ядро на часть что бы потом сделать всё как было?
R>>кажись чтобы ядро собирать как лего под разные платформы, убирая лишнее, ставя где-то заглушки.. _>Разные платформы: от WindowsX.нищеброд до WindowsX.дляреальныхпацанов ?
Windows 10 Mobile — Windows 10 IoT — Windows 10 PC
думаю такая задача для лего самое то, по крайней мере другого объяснения для этого "переусложнения на ровном месте" я для себя не нашел
R>>здесь коротко расписан сам механизм и зачем он им понадобился R>>здесь чуть подробнее с тех деталями которые вам скорее всего не нужны _>И ради чего всё это затевалось. Что бы повысить энтропию? Разобрать ядро на часть что бы потом сделать всё как было?
Yet another способ решить проблему dll hell, после того что осознали что предыдущий способ (sxs) — громоздкий и не гибкий.
Вобщем захотели отвязать имена функций от имен длл. Но чтото не получилось, и в результате получилось просто много новых длл.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, rumit7, Вы писали:
R>Windows 10 Mobile — Windows 10 IoT — Windows 10 PC R>думаю такая задача для лего самое то, по крайней мере другого объяснения для этого "переусложнения на ровном месте" я для себя не нашел
Судя по убитому GUI в последних виндах, что-то пошло не так
