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

A>да. прерывания это тоже API.
A>разве что Вы будете напрямую в видеопамяти символы рисовать

Так рисовали же...

Почти Малевич... но круглый...

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

А>>Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
А>>На то она и ОС.
А>>Даже консольный printf работает через АПИ соответствующей ОС.

_>Даже DOS???

да. прерывания это тоже API.
разве что Вы будете напрямую в видеопамяти символы рисовать

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

А>>Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
А>>На то она и ОС.
А>>Даже консольный printf работает через АПИ соответствующей ОС.

_>Даже DOS???

DOS это не ОС.
DOS это голимый монитор, проклятая Богом и людьми терминалка на микроконтроллере, которая затормозила отрасль на 30 лет.

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

M>

M>Начал изучать великий и могучий С++ и попытался визуально представить структуру языка. Прошу меня поправить, если где-то я ошибаюсь.
Что такое "библиотека пользовательских объектов"?
Как так оказалось что CLR минует Windows API?
Почему язык C++ включает в себя библиотеки ATL,WTL, MFC? Это все-таки не стандартные библиотеки.

Поправочки
— нет такого языка Managed C++. Есть C++/CLI. Это его официальное название.
— язык C++/CLI — это расширение C++, а не антипод. Т.е. C++/CLI включает в себя C++.
— CLR есть надстройка над WinAPI.

M>Зеленым цветом на рисунке указыны места в которых я сомневаюсь и хочу получить разъяснения:
M>1. позволяет ли ОС надстраиваить над собой без использования Windows API пользовательские библиотеки;
Что значит надстраивать над ОС?
Есть куча платформонезависимых библиотек. ОС виндовс позволяет им так или иначе работать. Напрямую эти библиотеки с WinAPI могут не работать, но это не значит что они обходятся без косвенной работы с WinAPI через рантайм, например.

M>2. позволяет ли ОС писать над ядром приложения без использования Windows API.
что значит писать над ядром приложения? Тут "ядро приложения" или "ядро ОС". Если ядро ОС, то да, позволяет без WinAPI. Но там уже пойдет Windows Driver Kit, например.

Попытался визуально представить структуру языка С++ и не смог.

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

M>

M>Начал изучать великий и могучий С++ и попытался визуально представить структуру языка. Прошу меня поправить, если где-то я ошибаюсь.
M>Зеленым цветом на рисунке указыны места в которых я сомневаюсь и хочу получить разъяснения:
M>1. позволяет ли ОС надстраиваить над собой без использования Windows API пользовательские библиотеки;
M>2. позволяет ли ОС писать над ядром приложения без использования Windows API.

Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
На то она и ОС.
Даже консольный printf работает через АПИ соответствующей ОС.

Начал изучать великий и могучий С++ и попытался визуально представить структуру языка. Прошу меня поправить, если где-то я ошибаюсь.
Зеленым цветом на рисунке указыны места в которых я сомневаюсь и хочу получить разъяснения:
1. позволяет ли ОС надстраиваить над собой без использования Windows API пользовательские библиотеки;
2. позволяет ли ОС писать над ядром приложения без использования Windows API.

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

S>Что такое "библиотека пользовательских объектов"?
Под библиотекой пользовательских объектов я подразумевал набор классов, пишушихся пользователями для своих нужд, т.е. это собсвенный каркас пользователя аналогичный MFC.
S>Как так оказалось что CLR минует Windows API?
Да, здесь я явно ошибся!
S>Почему язык C++ включает в себя библиотеки ATL,WTL, MFC? Это все-таки не стандартные библиотеки.
Полностью с вами согласен! Неправильным названием своего топика я ввел вас в заблуждение, но это по понятным для меня и явным для вас причинам
Знакомясь с языком С++, я увидел множество технологий написания Windows-приложений: с помощью библиотек MFC, ATL, Windows Forms. Все вышеуказанные библиотеки строго завязаны на Windows API, т.е. являются надстройками ним. В своем рисунке я это и хотел отразить при этом разделив всю область на две части: Windows-приложения, содержащие неуправляемый код и приложения, код которых управляется средой выполнения CLR. Поэтому и появились на рисунке пометки Managed C++ и C++(т.е. стандартный язык, являющийся предметом написания множества книг, самоучителей).

S>Поправочки
S>- нет такого языка Managed C++. Есть C++/CLI. Это его официальное название.
S>- язык C++/CLI — это расширение C++, а не антипод. Т.е. C++/CLI включает в себя C++.
S>- CLR есть надстройка над WinAPI.
Этот момент переименнования я упустил из виду.


M>>Зеленым цветом на рисунке указыны места в которых я сомневаюсь и хочу получить разъяснения:
M>>1. позволяет ли ОС надстраиваить над собой без использования Windows API пользовательские библиотеки;
S>Что значит надстраивать над ОС?
ОС является второй областью знаний (после самого языка С++ и STL), изучть которую я ставлю себе цель. И в ней у меня еще большие пробелы, поэтому могу использовть неверные термны. (Да,буду благодарен, если можете порекомендовать какую-либо литературу)
S>Есть куча платформонезависимых библиотек. ОС виндовс позволяет им так или иначе работать. Напрямую эти библиотеки с WinAPI могут не работать, но это не значит что они обходятся без косвенной работы с WinAPI через рантайм, например.
Т.Е. библиотеки более высокого уровня (MFC и ATL) я могу заменить собсвенными аналогами, а заменить WinAPI у меня не получится!?

M>>2. позволяет ли ОС писать над ядром приложения без использования Windows API.
S>что значит писать над ядром приложения? Тут "ядро приложения" или "ядро ОС". Если ядро ОС, то да, позволяет без WinAPI. Но там уже пойдет Windows Driver Kit, например.
Да, на рисунке под ОС Windows я полагал именно ядро ОС. А о Windows Driver Kit мне следует почитать, благодарю.

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

M>Знакомясь с языком С++, я увидел множество технологий написания Windows-приложений: с помощью библиотек MFC, ATL, Windows Forms. Все вышеуказанные библиотеки строго завязаны на Windows API, т.е. являются надстройками ним. В своем рисунке я это и хотел отразить при этом разделив всю область на две части: Windows-приложения, содержащие неуправляемый код и приложения, код которых управляется средой выполнения CLR.
Это немного некорректная попытка поделить приложения по такому признаку. Код приложения может не содержать неуправляемых кусков вообще, но во время выполнения приложения значительная часть ВЫПОЛНЯЕМОГО кода будет неуправляемой. Не говоря уже о том что часть кода приложения может быть управляемой, а часть — нет. Может быть уместно говорить о долях (процентном содержании) управляемого и неуправляемого кода в исходниках...
Только смысла в этом немного, т.к. неуправляемый код выполняется полюбому, даже если в исходниках приложения его нет. И если вы озадачились создать приложение на С++, в исходниках которого бы был лишь управляемый код, то лучше возьмите не C++/CLI, а C#.

S>>Что значит надстраивать над ОС?
M>ОС является второй областью знаний (после самого языка С++ и STL), изучть которую я ставлю себе цель. И в ней у меня еще большие пробелы, поэтому могу использовть неверные термны. (Да,буду благодарен, если можете порекомендовать какую-либо литературу)
Могу порекомендовать Windows для профессионалов. Создание эффективных Win32-приложения с учетом специфики 64-разрядной версии Windows. Джеффри Рихтер.

S>>Есть куча платформонезависимых библиотек. ОС виндовс позволяет им так или иначе работать. Напрямую эти библиотеки с WinAPI могут не работать, но это не значит что они обходятся без косвенной работы с WinAPI через рантайм, например.
M>Т.Е. библиотеки более высокого уровня (MFC и ATL) я могу заменить собсвенными аналогами, а заменить WinAPI у меня не получится!?
Все что выполняется под виндовсом, так или иначе, прямо или косвенно, работает через WinAPI. От WinAPI можно абстрагироваться, использовав какую-либо из прокладок (MFC, ATL, WinForms и т.п.). Но совсем отказаться от него в рамках Windows не получится. Процесс приложения ведь как-то должен уметь сообщить ОС что он хочет выделить память, создать окно, написать сообщение в консоль, как-то наследить, что бы был от него какой-то толк. Все это через WinAPI. Даже если упомнянуть приложения, работающие в эмуляторах под виндой, то там именно эмулятор будет взаимодействовать с WinAPI.
Единственный способ миновать WinAPI под виндовсом — писать приложение уровня ядра. Там тоже есть свой API, который тоже от виндовса, но формально это не WinAPI, а глубже.

M>1. позволяет ли ОС надстраиваить над собой без использования Windows API пользовательские библиотеки;
M>2. позволяет ли ОС писать над ядром приложения без использования Windows API.
Ну написать dll ли .exe, юзающие тока ntdll не фокус. Не юзающие — уже фокус, но на уровне "ловкость рук".

А>Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
А>На то она и ОС.
А>Даже консольный printf работает через АПИ соответствующей ОС.

Даже DOS???

А>Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
Дело как бы в том что win32 api и windows NT api — как бы два разных API. Просто об этом в последнее время стали забывать.

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

А>>Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
O>Дело как бы в том что win32 api и windows NT api — как бы два разных API. Просто об этом в последнее время стали забывать.
Не разных. Windows API это надстройка над ядерным NT API, а был надстройкой над DOS вплоть до win98 включительно.

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

M>Начал изучать великий и могучий С++ и попытался визуально представить структуру языка. Прошу меня поправить, если где-то я ошибаюсь.
К C++ эта структура не имеет никакого отношения. с некоторой натяжкой в структуре представлены особенности программирования под Windows

M>Зеленым цветом на рисунке указыны места в которых я сомневаюсь и хочу получить разъяснения:

M>1. позволяет ли ОС надстраиваить над собой без использования Windows API пользовательские библиотеки;
M>2. позволяет ли ОС писать над ядром приложения без использования Windows API.

Обращаться напрямую к ядру Windows можно, но это непереносимый путь. В разных версиях Windows, на разных архитектурах используются разные способы для вызова функций ядра. Более того, эти пути недокументированы и могут меняться в будущем. Так что если этим злоупотреблять, то приложение может быть непереносимо. Та что можно, но бессмысленно.

А>>>Любая ОС ничего не позволяет сделать без своего АПИ ни на каком языке.
O>>Дело как бы в том что win32 api и windows NT api — как бы два разных API. Просто об этом в последнее время стали забывать.
F>Не разных. Windows API это надстройка над ядерным NT API, а был надстройкой над DOS вплоть до win98 включительно.
а clr — надстройка над win32 api и чутарь над NT, значит ли это что clr — тоже самое что win32 api?

неуправляемые приложения

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

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

A>>да. прерывания это тоже API.
A>>разве что Вы будете напрямую в видеопамяти символы рисовать

Ops>Так рисовали же...

Это не означает, что программа не обращалась к прерываниям DOS. Как минимум, вызывались функции управления оперативной памятью (запрос/освобождение блоков). Чтение-запись файлов тоже шли через прерывания DOS, т. к. иначе программе пришлось бы обращаться к диску напрямую через БИОС (а то и через регистры), парсить служебные данные и т. д. И не факт, что в конечном к ДОС не пришлось бы обращаться: любое изменение служебных областей диска минуя ДОС могло привести к рассинхронизации данных в памяти и на диске. Особенно пикантной ситуация становится, если работает утилита типа Stacker'a.