Спасаем стек

Продолжим тему о микроконтроллерах с малым объёмом памяти. Я обычно подразумеваю под таковыми те, у которых ОЗУ 512-1К. Есть, конечно и со 128, и 256 байтами, но там уже не до СИ. При использовании ОС, которая умеет в переключение нитей, возникает проблема памяти для стека, тем более, что у каждой нити он свой. Стек расходуется в основном на две вещи (помимо контекста при переключении нитей): сохранение регистров и выделение фрейма при вызове функций. Соответственно, чем глубже вложенность вызовов, тем больше расходуется стек. Неприятные сюрпризы могут вылезти при использовании библиотечных функций, таких как printf (лол, никогда не знаешь, что там внутри, хотя, можно и посмотреть для интереса).


printf("%d\t%d\tsec=%d\tT=%d\tP=%d\n", i, g_cnt, krn_timer_cnt / KRN_FREQ, j, k);

Вот как был израсходован стек:

А вот такой же по функционалу фрагмент, в нём выводится и HEX и DEC представление числа. Я не стал писать парсер форматированного вывода, уменьшив этим вложенность вызовов. Деление на 10 по алгоритму *0.8/8 сдвигами можно написать самому, но я взял готовый код из этой статьи.

int8_t kout_u8h(char *s, uint8_t x)
{
  uint8_t t;
  t = x >> 4;
  t += 6;
  t += (t & 0x10) ? 0x31 : 0x2A;
  *(s++) = t;
  t = x & 0xF;
  t += 6;
  t += (t & 0x10) ? 0x31 : 0x2A;
  *(s++) = t;
  *(s++) = 0;
  return 2;
}

int8_t kout_u16h(char *s, uint16_t x)
{
  kout_u8h(s, x >> 8);
  s += 2;
  kout_u8h(s, x & 0xFF);
  return 4;
}

int8_t kout_u32h(char *s, uint32_t x)
{
  kout_u8h(s, x >> 24);
  s += 2;
  kout_u8h(s, (x >> 16) & 0xFF);
  s += 2;
  kout_u8h(s, (x >> 8) & 0xFF);
  s += 2;
  kout_u8h(s, x & 0xFF);
  return 8;
}

typedef struct
{
  uint32_t quot;
  uint8_t rem;
} ltkrn_divmodu10struc;


inline static ltkrn_divmodu10struc divmodu10(uint32_t n)
{
  uint32_t qq;
  ltkrn_divmodu10struc r;
  r.quot = n >> 1;
  r.quot += r.quot >> 1;
  r.quot += r.quot >> 4;
  r.quot += r.quot >> 8;
  r.quot += r.quot >> 16;
  qq = r.quot;
  r.quot >>= 3;
  r.rem = (uint8_t)(n - ((r.quot << 1) + (qq & ~7ul)));
  if(r.rem > 9)
    {
        r.rem -= 10;
        r.quot++;
    }
  return r;
}

char * utoa_builtin_div(uint32_t value, char *buffer)
{
  ltkrn_divmodu10struc r;
  buffer += 11; 
  *--buffer = 0;
  do
  {
     r = divmodu10(value);
      *--buffer = r.rem + 0x30;
      value = r.quot;
   }
   while (value != 0);
   return buffer;
}

void kout_uart(char *s)
{
  krn_mutex_lock(&mutex_printf);
  while (*s) uart_putchar(*(s++));
  krn_mutex_unlock(&mutex_printf);
}

и далее,

kout_u32h(g_str, f);
kout_uart("f=");
kout_uart(g_str);
kout_uart(" sec=");
kout_uart(utoa_builtin_div(krn_timer_cnt / KRN_FREQ, g_str + 12));
kout_uart("\n");

Вот расход стека в этом случае:

Почувствуйте разницу!
P.S. Островок T посередине — это временный стек, используется однократно при запуске операционки.
  • +1
  • 22 декабря 2012, 14:31
  • scaldov

Комментарии (353)

RSS свернуть / развернуть
Раньше я тоже занимался подобными оптимизациями. Но теперь решил, что вытеснялкам не место на слыбых МК, проблем только прибаляет.
+4
«Мисье знает толк в извращениях!»

На кой черт в мелкие мк засовывать ОС
+4
Странные какие-то рассуждения. Если можно впихнуть вытеснялку, то почему бы и не впихнуть? Или надо из принципа е#аться с SM?
0
Для начала называй все своими именами… А то тут есть любители попетросянить и Linux называют Lunux… Если нужна RTOS то для начала выбери нужный камень.
0
ты хочешь поговорить со мной про линукс?? ну-ну.
-2
еще один религиозный фанатик…
0
Как раз после многопоточных умников всё тормозит, зависает, глючит.
0
Точно, после многопоточных, когда приходят однопоточные, именно так все и происходит.
-1
Хватит передразнивать. Вытесняющая многозадачность приносит множество проблем и если можно обойтись без неё, то обязательно нужно от неё отказаться.
+1
Хватит передразнивать.
Не будьте столь категоричными в своих заявлениях и пропадет необходимость в подколках.
Вытесняющая многозадачность приносит множество проблем и если можно обойтись без неё, то обязательно нужно от неё отказаться.
Многозадачность сама по себе приносит множество проблем, но, почему-то, никто не торопится от нее отказываться. Видимо потому, что она позволяет и решить некоторое количество проблем. Разные виды многозадачности делают это по разному в разных ситуациях. В итоге мир не делится на черное и белое, существует много комбинаций и в каждом конкретном случае можно выбрать наиболее подходящее сочетание, оптимальное для конкретной задачи. А любой экстремизм типа «ОС — зло» или «вытесняющая многозадачность — зло» воняет религиозным фанатизмом и зашореностью.
-1
главный троль атакуэ… ща будет столько срача… :)
+1
главный троль атакуэ…
Не знал, что вы тут главный троль…
0
и заверте…
0
А потом спутники в океан падают.
+1
  • avatar
  • ks_
  • 22 декабря 2012, 18:16
умей в логику.
очевидно, что простая многопоточная прога гораздо проще, и значит, надёжнее в проектировании, нежели менее фаршированная функционалом SM.
-2
1 просто ошибки при реализации перемудреных алгоритмов могут дорого обойтись
2 и не дай бог кому потому разбираться в исходниках
0
простая многопоточная прога гораздо проще

сотрудники NASA олуху. Они ведь утверждают обратное. Чем сложнее чем тем меньше надежность.
0
В зависимости от конкретной задачи проще может быть написать и так и так.
+1
не в зависимости а всегда.
0
Не понял вашего утверждения. То, что писать надо так, как проще это, как бы, очевидно.
0
ОС в любой форме не является упрощением.
+1
Любая абстракция создается для упрощения понимания работы системы в целом. В том числе и ОС в любой форме. Если вы начнете писать, скажем, в любом месте, где вам нужен доступ к периферии, код непосредственно выполняющий нужную задачу вместо того, что бы вызвать однажды написанную функцию, то это не будет способствовать ни уменьшению размера кода, ни упрощению написания, ни упрощению сопровождения кода, не говоря уже о простоте чтения/понимания кода. Но как только вы такую функцию напишете, это будет крошечный шаг в сторону ОС. Собственно, именно из таких применений ОС и родились как самостоятельное явление. А категорические заявления типа вашего лишь свидетельствуют об отсутствии понимания того, чем же, по сути, является ОС.
-1
Бггг. В который раз убеждаюсь, что ты не разбираешься в ОС-х. Можешь сходить на электроник в 100й раз спросить почему все ОС не надежны или поднять тему. Там почти каждый месяц кото-то создает подобную тему. Уже предлагали банить за такое. А еще лучше почитай теорию.
0
Бггг. В который раз убеждаюсь, что ты не разбираешься в ОС-х.
Куда уж мне до вас. Это ж надо стереть из мозга все знания об операционках, что бы разбираться на таком же уровне как и вы. И, для надежности, выключить мозг совсем, а то, не ровен час узнаю что-нибудь и перестану соответствовать.
Можешь сходить на электроник в 100й раз спросить почему все ОС не надежны или поднять тему.
Спасибо за предложение, но я не думаю, что люди так же плохо понимающие о чем идет речь, как и вы, настолько распространены в соответствующих кругах. Такое предположение выглядит несколько не правдоподобно. Скорее всего вы не поняли того, что там писали. Этому я бы совсем не удивился.

P.S. в следующий раз, собираясь перейти на личности, вам стоит покормить ваше ЧСВ болеутоляющим заблаговременно.
-1
тебе в очередной раз заняться нечем.
0
тебе в очередной раз заняться нечем.
Есть чем, но вы так слезно упрашивали полечить ваше ЧСВ, что я не смог отказать.
-1
Наверное ты сейчас хочешь привести пример где ОС используют для повышения надежности?.. Но ты решил утаить эту информацию ибо боишься полечить мое ЧСВ.
0
Наверное ты сейчас хочешь привести пример где ОС используют для повышения надежности?
Наверное я хочу повторно толсто намекнуть, что даже там, где, якобы, «нет операционной системы», в большинстве случаев она таки есть.
Но ты решил утаить эту информацию ибо боишься полечить мое ЧСВ.
«Утаиванием» можно счесть, разве что, нежелание повторять вам и третий раз, если со второго до вас не дойдет простая мысль, написанная выше. Но я сильно сомневаюсь, что подобное «утаивание» поможет лечению вашего ЧСВ.

P.S. для некоторых встраиваемых операционных систем проведена формальная верификация правильности. как не сложно догадаться, применение таких ОС вместо самописного аналога на прерываниях или FSM действительно может повысить надежность.
-1
Где пример? Че, даже одного примера не в состоянии привести?
0
Где пример?
А я обещал? Да и вы как-то не утруждали себя хоть какими-то обоснованиями той чуши, которую вы несете. Впрочем, для тех, кому действительно интересно, я пример приведу — вот.

P.S. будете продолжать «чьокать» или, наконец, попробуете что-то сказать по делу? если в состоянии, конечно.
0
В качестве примера ты привел микроядра?? Где-то тут гулял facepalm
0
Какой у вас замечательный ответ. Вы в одном предложении умудрились продемонстрировать а) изменение правил на ходу, б) отсутсвие способности говорить по делу, в) отсутствие у вас собственных примеров. Я, почему-то не удивлен. Ладно, приходите, когда у вас будут собственные примеры, тогда продолжение обсуждения этой темы приобретет хоть какой-то смысл.
0
while(1) {//код}


Литературу слабо почитать)
0
Литературу слабо почитать)
Вам, судя по всему да.

P.S. гранаты не той системы ваш пример к вашим утверждениям никакого отношения не имеет.
0
P.S. гранаты не той системы ваш пример к вашим утверждениям никакого отношения не имеет.

Это уже просто пиз***ц
0
Это уже просто пиз***ц
Угу. Впрочем, попытки обсуждать с вами технические темы, как правило, к этому состоянию и приходят.
+1
ещё раз напомню про логику. путин разоблачил братьев навальных.
0
Не из сколково часом? Любая ОС безжалостным образом жрет ресурсы процессора. Даже с ARM нужно 100 раз подумать, прежде чем лепить туда ОС. МК с развитой системой прерываний прекрасно обходится без ОС. Проблема лишь в криворукости программеров. Вот это очевидно.
0
Любая ОС безжалостным образом жрет ресурсы процессора.
Любая либа, хоть как-то абстрагирующая железо, по своей сути является примитивной ОС.
МК с развитой системой прерываний прекрасно обходится без ОС.
Нет, ее просто приходится писать каждый раз заново.
Проблема лишь в криворукости программеров.
Которая произрастает из недостатка знания предмета.
0
Готовую, универсальную, хорошо отлаженную функцию заменяем на самописную плохо протестированную и неуниверсальную.
+1
  • avatar
  • m0xf
  • 23 декабря 2012, 00:16
Нет, не так. Функцию, требующую больше 100 с лишним байт, заменяем не функцию, которая расходует в 3 раза меньше стека.
0
Не, не так. Вместо одной функции со множеством параметров вызываем много функций с одним параметром и делаем изумленное лицо увидев расход стека))) Даже и не знаю как так и выходит… магия.
0
1) не много функций, а сколько надо.
2) изумлённое лицо наверное, толко у вас. типа, «нахрена он это написал».
3) магия не в расходе стека, а в том, что многие упёрто юзают printf на таких мелких контроллерах.
0
О боги…

Наверное такому опытнуму разработчику известны функции вида
void func(char * str, ...);

И наверное ты знаешь как они вызываются… И наверное разрабы clib ниразу не предумотрели вариант с малым стеком.

2) изумлённое лицо наверное, толко у вас. типа, «нахрена он это написал».

Это в точку)) Действительно не понял что это.
0
лол. а теперь расскажи-ка нам, как и где в элипсисе передаются аргументы.
-1
лол. а теперь расскажи-ка нам, как и где в элипсисе передаются аргументы.

Эклипс это язык программирования или компилятор?
0
Эклипс это язык программирования или компилятор?
Вы не пробовали читать то, на что отвечаете?
-1
лол. а теперь расскажи-ка нам, как и где в элипсисе передаются аргументы.
0
«элипсис» — не эклипс, а «многоточие» по английски (ellipsis).
0
Ага, а давайте русские слова заменять на английские. Так ведь будет круче и понятней… А еще лучше писать их на русском.
0
Ну, это уже не ко мне претензии.
0
Да я понимаю…

Но в любом случае. Как автор написавший
printf("%d\t%d\tsec=%d\tT=%d\tP=%d\n", i, g_cnt, krn_timer_cnt / KRN_FREQ, j, k);


ответил на это
void func(char * str, ...);


вот так
лол. а теперь расскажи-ка нам, как и где в элипсисе передаются аргументы.

??
0
по-моему, вы не понимаете, о чём пишете. man va_list, va_arg, va_copy, va_start, va_end. и там по ходу дела читаете, как оно устроено внутри.
-1
Ну не доходит.

printf — это функция с переменным количеством аргументов. Из-за этого у нее более высокие накладные расходы на оперативку и на флеш. Если эти расходы не приемлемы, то используют ее аналоги с фиксированным количеством аргументов либо со списком.
0
элипсис это греческое слово. И поэтому, как термин, используется в научной литературе. Да-да, записанное русскими буквами.
0
Эклипс это очень популярная IDE. И под этим словом эмбеддеры подразумевают ее.
0
А ты не заметил, что «элипсис» и «эклипс» — два совершенно разных слова?
0
та я думал он букву пропустил.
0
та я думал он букву пропустил.
Забавно. С таким уровнем знаний вы даже об операционках беретесь рассуждать, хотя вам впору, разве что, учебник по С зубрить.
0
Ну и как, прочитали, наконец? Судя по читате, вторая попытка прочесть тоже оказалась неудачной.
0
Советую автору почитать о реентрантных (неентерабельных) функциях, и тогда разговор о «нитях» и применения в них printf приобретет правильное звучание. Дело в том, что не в размере стека там дело :)
0
Простите, надо читать «реентерабельных»…
0
что за лол. вы хотите сказать, что printf вызывает сам себя??
кстати, в данной статейке разковор не о нитях, а о стеке.
и потом, у вас кавычки лишние.
-1
вы хотите сказать, что printf вызывает сам себя
Когда функция вызывает сама себя — это рекурсия.
Реентерабельность — возможность вызова той же функции из разных мест программы одновременно.
0
и что? ткните носом, в каком месте мой вариант не реентерабелен?
0
Пожалуй нет такого места…

PS С чем не согласен в статье — на процах с 128-256 вполне есть место Си. Даже для tiny10 можно на Си писать.
0
можно, но уже про ОС тут можно забыть.
и потом, есть проекты, где столько функционала, что уже каждый байт и такт на счету.
довелось как-то потрахаться с AT8253, точнее, с его нашим аналогом. И приём по UART с расчётом CRC8 на ходу, и эмуляция 4х uart'ов программно, связь со вторым контроллером на плате, разруливание пакетов по портам, считывание температуры и прочее.
Си там не влезет совершенно точно.
0
можно, но уже про ОС тут можно забыть.
Набор функций/методов для работы с железом вполне тянет на примитивную ОС. Собственно, именно так операционки, в свое время, и появились.
0
Ну, в эмбеде обычно под ОС подразумевают мультизадачность, а не HAL.
+2
Тс… А то evsi тебя затролит :)
0
Ага, и про DOS ни кто не слышал…
0
Ну, в DOS насколько я помню вообще почти ничего не было, кроме шелла, ФС и загрузчика программ.
0
Отчего же, необходимый минимум там вполне был.
0
Ну расскажи хоть, что там было. Я DOS уже не застал. Знаю только что HAL там практически не было и дрова на все приходилось писать самому (хотя, возможно, это относится только к аудио/видеовыводу). Ну и многозадачности тоже. Только загрузчик программ, вроде.
0
Так DOS и сейчас активно используется и процветает. Но его используют как и Linux в Android.
0
Но его используют как и Linux в Android.
Где, например?
0
RTKernel
0
Насколько я вижу из описания, DOS оно использует только как загрузчик. Ведро же скорее шелл, чем ОС.
0
С адройдом весьма мудро поступили. Linux портировали на все, что угодно. А вот адройд портировать на вот это все весьма накладно и долго. Легче запустить его под линуксом, а то что ресурсов жрет больше так это особо никого не волнует.
0
Весело говорить с оппонентом вроде тебя, который отвечает не на мою реплику/вопрос, а на что-то из собственных мыслей.
0
Разве где-то был вопрос?
0
EMM386 и всякие DPMI — это вполне себе DOS'овые операционки операционки (если тут кто вообще в курсе, что это такое). Там уже всё на уровне эмулятора (реального режима).
0
Файловые операции + запуск программ + управление памятью + некоторое количество сервисных вызовов.
Под файловыми операциями подразумеваются не только операции над файлом, но и операции над ФС, то есть создать/удалить файл/каталог, перейти в подкаталог и так далее.
Да, штатной поддержки аудио-видео не было, но самому досу она и не нужна, а прикладной софт ставил драйвера и пользовался.
0
Шелл, ФС, лоадер и память. Забавно, что там нет ни HAL, ни планировщика задач, который в эмбеде обычно и понимается под RTOS.
0
Причем шелл это просто прикладная программа, ничего больше.
0
Ну это типично для шелла. Хотя в DOS AFAIK все работало в режиме ядра.
0
ДОС и его предшественники разрабатывались для процов, где защищенного режима не было в принципе, так что там все выполнялось в режиме ядра.
0
Ага, но в результате некоторые программы для DOS были сами себе операционкой. Так что «просто прикладная программа» для доса может быть не так уж проста.
0
Конечно. Та же нетварь, например, стартовала как досовский бинарь.
0
Да и винда тоже, до четвертой (или даже пятой).
0
В DOS хотя-бы есть ядро и объекты ядра…
0
В DOS хотя-бы есть ядро и объекты ядра…
Досовское «ядро» не более чем набор функций + некоторое количество общих данных. Что от традиционной сишной либы отличается, разве что, специфическим способом вызова и все.
0
Досовское «ядро» не более чем набор функций + некоторое количество общих данных. Что от традиционной сишной либы отличается, разве что, специфическим способом вызова и все.

О бля… Давай еще.

В досе имеется загрузчик. В досе есть ядро, есть объекты ядра.
В HAL этого нет и никогда не будет.

Мне б очень хотелось посмотреть на HAL где:
— Начальная программа загрузчик передает управление HAL
— В HAL происходит инициализация «не знаю как такое называется»
— После HAL не имея ядра передает управление на пользовательский уровень и предоставляет сервисы пользовательскому уровню.
0
В досе имеется загрузчик.
Который, вообще говоря, не является частью системы.
В досе есть ядро, есть объекты ядра.
«Ядро» не более чем термин объединяющий группу компонентов под одной «крышей». Так же как «HAL» объединяет наборы функций для работы с разной периферией. И это тоже сугубо термин для удобства, не более того.
По поводу «объектов ядра» вам стоило бы рассказать подробнее.
Мне б очень хотелось посмотреть
Хочется — сделайте. Ничего из перечисленного вами, в том числе мифические «объекты ядра» не делает операционку операционкой.

P.S. ну прочтите же, наконец, определение. лучше сразу раза три-четыре, учитывая ваши навыки чтения.
+1
Который, вообще говоря, не является частью системы.
ОС без загрузчика не существует. HAL без загрузчика существует.

Про ядро и HAL феерический бред.

По поводу «объектов ядра» вам стоило бы рассказать подробнее.
Простейшее. Процесс. В досе это есть. В HAL существовать не может.

Далее снова попер бред который мне не понятен.
0
ОС без загрузчика не существует.
Гут. Найдете загрузчик во FreeRTOS? Заодно можете рассказать что и откуда он грузит.
Про ядро и HAL феерический бред.
Да, в вашем исполнении.
Простейшее. Процесс. В досе это есть.
Не вижу, что может вам помешать назвать какую-нибудь структуру, с которой работает HAL «объектом ядра». Результат будет ровно такой же, как и в случае с досовскими «процессами».
Далее снова попер бред который мне не понятен.
Вы не понимаете собственного бреда? Или все, в чем вы ничего не понимаете, вы называете «бредом»?

P.S. интересно, с какой попытки удастся уговорить вас прочитать определение…
+2
Гут. Найдете загрузчик во FreeRTOS? Заодно можете рассказать что и откуда он грузит.

Очередной перл))) BIOS не не слышали.

Не вижу, что может вам помешать назвать какую-нибудь структуру, с которой работает HAL «объектом ядра». Результат будет ровно такой же, как и в случае с досовскими «процессами».
В ОС процесс запускается ядром. В HAL кто запустит этот «процесс»? Как я понимаю пользовательский код который «ядро»? Т.е. мы делаем зависимыми от железа «процессы HAL» и «ядро» от задачи. И вот это все в купе называем «ОС»? И «ядро» предоставляет сервисы «HAL»?
-1
Очередной перл)))
Да, в вашем исполнении:
ОС без загрузчика не существует.
Так вы расскажете о загрузчике для FreeRTOS или как?
BIOS не не слышали.
О! Во FreeRTOS теперь не только загрузчик, но и биос появился? Как интересно…

В ОС процесс запускается ядром.
Внимательное прочтение вот этого обычно помогает. В вашем случае рекомендуется минимум трехкратное чтение.
+3
О! Во FreeRTOS теперь не только загрузчик, но и биос появился? Как интересно…

Кто получает управление самым первым???? В микроконтроллерах это main. Он и выполняет роль BIOS. Какая функция запускает FreeRTOS ?? Почему эта функция «no return» ??

Если не доходит, то по трасеруй простейшую кооперативку. Там пиз*** как загрузчик незаметен.

Внимательное прочтение вот этого обычно помогает. В вашем случае рекомендуется минимум трехкратное чтение.

И где же там утверждается обратное?
-2
Кто получает управление самым первым????
Э нет, отмазка не канает. Вы сказали «загрузчик», вот я и хочу узнать кто, кого и куда грузит в случае FreeRTOS. Да, код инициализации это не загрузчик. Почему именно так, вы тоже можете узнать, прочитав определение.
Если не доходит,
… то поучите теорию.
И где же там утверждается обратное?
В истории появления. Думаю, вам особенно интересно будет узнать о том, что в ранних операционках были «задания» и никаких «процессов». Впрочем, в не сильно ранних тоже, например, OS/360.
0
Э нет, отмазка не канает. Вы сказали «загрузчик», вот я и хочу узнать кто, кого и куда грузит в случае FreeRTOS. Да, код инициализации это не загрузчик. Почему именно так, вы тоже можете узнать, прочитав определение.

main и есть загрузчик. Он передает управление.

Значит поменяли название и это уже доказательство?
-3
main и есть загрузчик.
Повторю вопрос: кто, кого и куда грузит?
Значит поменяли название и это уже доказательство?
Загрузчик и инициализация — две разные вещи, а не просто смена названия.
+2
Ты изменил название «процесс» и на этом начал доказывать свою правоту.

Во FreeRTOS main загружает систему.
-1
Во FreeRTOS main загружает систему.
Не загружает, а запускает. Несколько разные вещи. Загрузчик нужен в тех случаях, когда ОС находится в памяти, из которой невозможно ее исполнение, и его задача — загрузить систему оттуда в память, из которой она может исполняться.
Да и не является он частью ОС. У тоже же линуха загрузчики — отдельные проекты, причем разные для разного железа (U-boot и куча аналогов для NAND и иже с ней, LILO, GRUB и прочие для ПК).
+1
P.S. Да и те, как правило, stage2-загрузчики. Самый первый обычно в биосе или непосредственно процессоре и предоставляется вендором.
0
main выполняет роль загрузчика. То, что уже что-то находиться в памяти не имеет значения. Потому что main может производить загрузку и оперативку и тогда это будет загрузчик?
-2
Может ты еще и JMP @startup в RESET VECTOR загрузчиком main'а назовешь? Это не загрузчик, это стартап-код. Без него ни одна программа не обойдется, даже main(){while(1);}.
+1
JMP @startup

Это простой переход. Как он может стать загрузчиком?

Ты хоть интересовался, что происходит в main во FreeRTOS/scmRTOS прежде чем это написать?
0
Это простой переход. Как он может стать загрузчиком?
Так с чего же загрузчиком становится не менее простой переход в main в виде вызова чего-то вроде osStart()?
Ты хоть интересовался, что происходит в main во FreeRTOS/scmRTOS прежде чем это написать?
Нет. Я говорю о операционках в общем, а не о частных примерах. Скорее всего там производится инициализация структур OS и передача ей управления.
+1
Как бы во всех происходит одно и тоже.

osStart()
Перед этим загрузчик выделяет место под процессы, и инициализирует контексты. Если требуется то будет произведена загрузка системы в оперативку, это зависит от микроконтроллера. Также вызывается HAL инициализации системного таймера.
Вызов функции это передача управления с перепланировкой процессов в ходе которой будет включен системный таймер и прерывания.

В случае с инициализацией мы вызываем только функцию. А загрузчик отдает управленние.
-2
А что, RESET VECTOR управление отдает не насовсем?
И тебе уже сказано, инициализация и загрузка разные вещи. Загрузчик не инициализирует ОС, он только загружает ее в память и передает управление. Инициализируется ОС уже своими силами.
Если требуется то будет произведена загрузка системы в оперативку, это зависит от микроконтроллера.
Вот это — уже загрузчик. Но ты только что сказал, что он нужен далеко не всегда.
+2
Загрузчик не инициализирует ОС, он только загружает ее в память и передает управление. Инициализируется ОС уже своими силами.

Как я понимаю загрузчик Windows/Linux не инициализирует эти системы? ;) evsi у тебя два ника?

А что, RESET VECTOR управление отдает не насовсем?


Это вектор сброса. Он передаст управление загрузчику.

Инициализируется ОС уже своими силами.


Буду знать))
-2
Как я понимаю загрузчик Windows/Linux не инициализирует эти системы?
Который из них? BIOS — нет. MBR — нет. NTLDR — хрен его знает, оно закрытое и вообще кусок винды, а это система весьма комплексная и включает в себя очень много чего, в том числе и HAL, и он является вполне неотъемлемой частью ядра. GRUB/LILO/Uboot? Только передаст строку параметров, AFAIK.
evsi у тебя два ника?
Полагаю, если поизучать наши публикации, то станет ясно, что мы — два совершенно разных человека.
Это вектор сброса. Он передаст управление загрузчику.
В МК в подавляющем большинстве случаев загрузчика нет. Так что передаст управление в OS, через некоторое количество startup-кода.
0
Этап загрузки ядра
Ядро при загрузке обычно имеет вид файла-образа, сжатого в формат zImage или bzImage с помощью zlib. В нём содержится головная программа, которая проводит минимальную настройку оборудования, распаковывает образ целиком в верхнюю память и монтирует RAM-диск, если он предусмотрен.[5] После этого она выполняет запуск ядра посредством ./arch/i386/boot/head и процесса startup_32() (для процессоров семейства x86).

Это из простейшего. Ядро перед загрузкой должно быть в обязательном порядке про инициализировано. Загрузчик Linux никогда не загрузит Windows, т.к. он незнает как инициализироватье его ядро. Максимум он может передать управление другому загрузчику.

Так работают все загрузчики.
Функции инициализации возвращают управление, загрузчики отдают управление.

Так что передаст управление в OS, через некоторое количество startup-кода.
Не в ОС загрузчику ОС если он имеется.
-1
Судя по описанию — оно как раз загружает ядро в ОЗУ, распаковывает его и передает управление.
В нём содержится головная программа, которая проводит минимальную настройку оборудования, распаковывает образ целиком в верхнюю память и монтирует RAM-диск, если он предусмотрен
Судя по этой фразе, программа инициализации ядра таки в ядре. Загрузчик ее только загружает и передает управление.
Загрузчик Linux никогда не загрузит Windows, т.к. он незнает как инициализироватье его ядро.
Нет, он не знает как загрузить ее ядро, поэтому загрузит загрузчик винды (NTLDR в случае WinXP и еще некоторых). Но загрузчик линукса — далеко не первый загрузчик. До него, как минимум (на ПК) отработают загрузчик BIOS'а и загрузчик MBR. Этим без разницы что грузить, лишь бы имело ожидаемый интерфейс.
Так работают все загрузчики.
Да неужели? Что инициализирует загрузчик BIOS'а? Или загрузчик MBR?
Функции инициализации возвращают управление, загрузчики отдают управление.
Это одно и то же, передавая управление никогда не знаешь, получишь ли его обратно. К тому же, нынче загрузкой ОС часто занимаются гипервизоры. Они вообще никогда не отдадут ей управление. А ОС вроде FreeRTOS как правило запускаются в виде обычной функции.
0
Судя по этой фразе, программа инициализации ядра таки в ядре. Загрузчик ее только загружает и передает управление.

Хорошая шутка. Но исходные коды открыты. Инициализация в ядре происходит. На эту тему есть статьи по написанию загрузчиков.

Да неужели? Что инициализирует загрузчик BIOS'а? Или загрузчик MBR?

Перед загрузкой BIOS происходит инициализация ядра процессора.

Это одно и то же, передавая управление никогда не знаешь, получишь ли его обратно.
Загрузчик всегда знает, что управление он не получит.

А ОС вроде FreeRTOS как правило запускаются в виде обычной функции.

Windows тоже обычная функция. Просто очень большая. Значит размер функции определяет, что есть ОС?
-1
Перед загрузкой BIOS происходит инициализация ядра процессора.
Э не, не уводи. Что инициализирует загрузчик в BIOS в загружаемой им ОС? И что инициализирует MBR в загружаемой им ОС?
Инициализация в ядре происходит
Вот видишь. Сам говоришь что в ядре, а не загрузчике.
Загрузчик всегда знает, что управление он не получит.
И что? Это относится не только к загрузчику. Так что даже если опустить те случаи, когда загрузчик не отдает исполнение полностью (гипервизоры, например) — это будет условием необходимым, но не достаточным для признания некоего кода загрузчиком (а на самом деле оно и необходимым не является).
Значит размер функции определяет, что есть ОС?
Нет, это определяет не размер функции, а ее функциональность.
Но мы говорим не об этом, а о том, что управление FreeRTOS передается точно так же, как и любой другой функции. Загрузкой это не является, соответсвенно и main() загрузчиком не является. Startup-кодом — да, но не загрузчиком.
0
Э не, не уводи. Что инициализирует загрузчик в BIOS в загружаемой им ОС? И что инициализирует MBR в загружаемой им ОС?

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

Вот видишь. Сам говоришь что в ядре, а не загрузчике.

Это я слова перепутал. Я уже задолбался писать одно и тоже по сто раз.

Я неразбираюсь в виртуальных машинах. Так, что не знаю как там это все работает. Но загрузчик там один хер будет работать также.

Но мы говорим не об этом, а о том, что управление FreeRTOS передается точно так же, как и любой другой функции.
Отдается а не передается.

Загрузкой это не является, соответсвенно и main() загрузчиком не является. Startup-кодом — да, но не загрузчиком.

Является. Происходит начальная инициализация с последующей передачей управления.
-1
И где я утверждал, что инициализация является обязательной частью загрузчика?
Да вот же:
Ядро перед загрузкой должно быть в обязательном порядке про инициализировано.

Так работают все загрузчики.
Обязательный момент как видно это отдать управление.
На самом деле, обязательный момент — это загрузить, а уже потом передать управление. Передача управления без загрузки загрузчиком не является.
Перед MBR уже за него все, что нужно проинициализированно.
Напротив, на момент работы MBR вообще ничего не инициализировано. Его задача — найти на диске следущий загрузчик (или сразу ядро ОС, ему без разницы — лишь бы его можно было загрузить и передать управление), загрузить его и передать управление. Аналогично для загрузчика в BIOS, только его задача найти MBR (или иной загрузчик аналогичного уровня, или сразу ОС — биосу точно так же без разницы, что грузить и запускать), загрузить его и передать управление.
Я неразбираюсь в виртуальных машинах. Так, что не знаю как там это все работает. Но загрузчик там один хер будет работать также.
Это не виртуальные машины. Во многих реальных машинах ОС работает под управлением гипервизора, он же ее и грузит.
Отдается а не передается.
Это синонимы.
Является. Происходит начальная инициализация с последующей передачей управления.
Это работа стартап-кода, а не загрузчика. Работа загрузчика — загрузить и запустить. «И», а не «и/или».
0
Ядро перед загрузкой должно быть в обязательном порядке про инициализировано.

Так работают все загрузчики.

Слово «Ядро» ниразу не заметно? Капец ниразу не видно? Вместо ядра не может быть загрузчика или программы? Не Бля только ядро? А нда ядро мы уже невидим.

Напротив, на момент работы MBR вообще ничего не инициализировано.
Датышо. Регистры не проинициализированны. А регистр PC тоже не проинициализирован?

Это синонимы.
ru.wiktionary.org/wiki/%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%D0%B0%D1%82%D1%8C
ru.wiktionary.org/wiki/%D0%BE%D1%82%D0%B4%D0%B0%D1%82%D1%8C

Русский не мой язык. Но у меня это не синонимы.

Это работа стартап-кода, а не загрузчика. Работа загрузчика — загрузить и запустить. «И», а не «и/или».

Да ну. Распаковать ядро не нужно. Нужно его только загрузть)) Статьи по загрузчикам нах ненужны… В них глупости пишут.
0
Слово «Ядро» ниразу не заметно? Капец ниразу не видно? Вместо ядра не может быть загрузчика или программы?
Я тебя не понимаю. Я о том и говорю, что ты утверждаешь, что инициализация ядра — обязательный этап работы загрузчика. Я с этим не согласен — как минимум не обязательный, как максимум это вообще работа не загрузчика.
Датышо. Регистры не проинициализированны. А регистр PC тоже не проинициализирован?
Мы говорим о инициализации ОС. Причем тут регистры процессора? На момент работы MBR ОС еще даже в памяти-то нет, даже инициализировать нечего.
Русский не мой язык. Но у меня это не синонимы.
Про контекст не забывай. Синонимы не слова «отдать» и «передать», а понятия «отдать управление» и «передать управление».
Распаковать ядро не нужно. Нужно его только загрузть))
Распаковка — часть загрузки. Но ты пытаешься выдать за загрузку инициализацию.
0
Я тебя не понимаю. Я о том и говорю, что ты утверждаешь, что инициализация ядра — обязательный этап работы загрузчика. Я с этим не согласен — как минимум не обязательный, как максимум это вообще работа не загрузчика.

Загрузчика ОС! Или ты уже хочешь прировнять загрузчик к загрузчику ОС. И это ты хочешь назвать синонимами?

Мы говорим о инициализации ОС
Забавно, MBR уже загрузчик ОС?

Функция MBR — «переход» в тот раздел жёсткого диска, с которого следует исполнять «дальнейший код» (обычно — загружать ОС). На «стадии MBR» происходит выбор раздела диска, загрузка кода ОС происходит на более поздних этапах алгоритма.

MBR не обязан загружать ОС.

Про контекст не забывай. Синонимы не слова «отдать» и «передать», а понятия «отдать управление» и «передать управление».
даже из контекста понятно что это не одно и тоже.

Распаковка — часть загрузки. Но ты пытаешься выдать за загрузку инициализацию.

Я говорил о том, что происходит потом или перед.

курсив
зачеркнутый
подчеркнутый
— цитировать
0
Загрузчика ОС! Или ты уже хочешь прировнять загрузчик к загрузчику ОС.
Поскольку мы говорим о загрузчиках ОС, то под словом «загрузчик» я понимаю исключительно «загрузчик ОС». Я не перескакиваю на «А регистр PC тоже не проинициализирован?», когда разговор идет о инициализации ОС.
Забавно, MBR уже загрузчик ОС?
Разумеется.
даже из контекста понятно что это не одно и тоже.
Лично мне как раз из контекста понятно, что это одно и то же.
MBR не обязан загружать ОС.
Он обязан загрузить следущую стадию, которая должна иметь ожидаемый им интерфейс. Это может быть хоть ОС, хоть следущий загрузчик, хоть что угодно.
Я говорил о том, что происходит потом или перед.

курсив
зачеркнутый
подчеркнутый
— цитировать
Просто бред.
0
Он обязан загрузить следущую стадию, которая должна иметь ожидаемый им интерфейс. Это может быть хоть ОС, хоть следущий загрузчик, хоть что угодно.
Этот загрузчик это делать не обязан. Он может сразу загрузить ОС. Если загрузчик ОС влезет в MBR.

курсив
зачеркнутый
подчеркнутый
— цитировать

Это чудоредактор сообщества.

Поскольку мы говорим о загрузчиках ОС

Тыж под загрузчиком понимаешь, то что тебе удобней. Ядро то выкидываешь, то вставляешь.
0
Он может сразу загрузить ОС. Если загрузчик ОС влезет в MBR.
ОС в таком случае — и есть следущая стадия. Вариант, когда вся ОС влезла в MBR и ее загрузил BIOS довольно маловероятен, хотя в случае загрузки с CD бывает и такое.
Тыж под загрузчиком понимаешь, то что тебе удобней. Ядро то выкидываешь, то вставляешь.
Нет, под загрузчиком я понимаю программу (в принципе необязательно, но обычно это программа), которая загружает операционную систему в память и передает ей управление. Вместо операционной системы может находиться и следущий загрузчик, но это ничего не меняет.
Ядро — да, тут есть некоторая неконсистентность терминологии. Уточню, что под «ядром» следует понимать «ОС».
0
Вариант, когда вся ОС влезла в MBR и ее загрузил BIOS довольно маловероятен, хотя в случае загрузки с CD бывает и такое.
Раньше вообще-то так и было. Это используется даже сейчас. В MBR может находиться загрузчик ОС.

которая загружает операционную систему в память и передает ей управление.
Без инициализации ядра? Интересно значит системный контекст должен быть инициализирован ядром? Но какже это возможно когда во время работы ядра используется этот самый контекст? Под контекстом я подразумеваю контекст. Или у ядро нет своего контекста? А если нет, то используется контекст процесса? А если используется контекст процесса, то кто этот контекст инициализировал?

Ядро не ОС. И никогда им не являлось и не собиралось являться. По оной банальной причине. Ядро часть ОС!
-1
В MBR может находиться загрузчик ОС.
Он там всегда находится за исключением случая, когда в MBR находится вся ОС.
Интересно значит системный контекст должен быть инициализирован ядром?
Да, разумеется. Особенно учитывая, что контексты — это абстракции самого ядра, им же и создаваемые.
Ядро не ОС. И никогда им не являлось и не собиралось являться. По оной банальной причине. Ядро часть ОС!
Во первых, ОС вполне может только из ядра и состоять. Во вторых, можешь считать, что я выразился неправильно, назвав ОС ядром.
0
Да, разумеется. Особенно учитывая, что контексты — это абстракции самого ядра, им же и создаваемые.
Контекст это регистры которые используются. Как эти регистры могут использоваться если в них мусор? Мусор без инициализации там будет всегда. А если его там нет, то откуда взялись эти правильные значения?

Во первых, ОС вполне может только из ядра и состоять. Во вторых, можешь считать, что я выразился неправильно, назвав ОС ядром.
Ядро значит содержит в себе HAL ??
-1
Контекст это регистры которые используются.
Контекст — это структура ядра, а не регистры. При инициализации ядро (точнее, плаинировщик) создает себе контекст и далее сохраняет/восстанавливает из него состояние регистров, принадлежавшее ему (если оно вообще ядру требуется, простейшие операционки вполне могут обойтись без контектса для ядра).
Если же речь о аппаратных контекстах (таких, как кольца защиты в x86), то они выделяются ядру вышележащей программой, например загрузчиком, стартапом или гипервизором.
Ядро значит содержит в себе HAL ??
Зависит от ОС. Может содержать (тогда это ОС с монолитным или гибридным ядром, такие как линукс и виндоус), может не содержать (это микроядерные ОС), наконец ОС может вообще не содержать HAL либо ядра (это, впрочем, зависит от того, что понимать под ядром).
0
Контекст — это структура ядра, а не регистры.
Эм… Чего? А как-же называются состояния системных регистров?

При инициализации ядро (точнее, плаинировщик) создает себе контекст и далее сохраняет/восстанавливает из него состояние регистров, принадлежавшее ему (если оно вообще ядру требуется, простейшие операционки вполне могут обойтись без контектса для ядра).

Как такое вообще возможно? Это нереально. Что в эти регистры должно быть записанно? Куда это все должно быть сохранено? Это все равно, что курица создаст себя же.

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

Кольца защиты контекс? И этот контекст предоставляется загрузчиком? Вау. Значит ОС знает о регистрах которые передает ей загрузчик? А не проще инициализировать это в загрузчике?

Зависит от ОС.

Чито? HAL в ядре!

Может содержать (тогда это ОС с монолитным или гибридным ядром, такие как линукс и виндоус), может не содержать (это микроядерные ОС), наконец ОС может вообще не содержать HAL либо ядра (это, впрочем, зависит от того, что понимать под ядром).


Windows и Linux основаны на микроядрах. Теперь буду знать.
-1
Эм… Чего? А как-же называются состояния системных регистров?
Контекст — это принадлежащее задаче состояние регистров. Создается и обеспечивается планировщиком, обычно — как сохранение ресурсов предыдущей задачи в память и восстановление из памяти контекста следущей задачи. Поскольку всем рулит ОС — для нее не составляет проблемы прежде чем передавать управление прочим задачам создать себе контекст и сохраниться в него.
Эта задача может быть делегирована отдельной функции инициализации, но к загрузке она все равно никакого отношения иметь не будет. Это часть ОС, ее инициализация.
Как такое вообще возможно? Это нереально. Что в эти регистры должно быть записанно? Куда это все должно быть сохранено? Это все равно, что курица создаст себя же.
Очередной бред.
Кольца защиты контекс? И этот контекст предоставляется загрузчиком?
Да, разумеется.
Значит ОС знает о регистрах которые передает ей загрузчик?
Нахрен ей это надо? Она получает контекст и заполняет его на свое усмотрение. О сохранности этого контекста нехай вышележащая ОС заботится, нижележащая даже не знает, получила она контекст или работает с регистрами монопольно.
Чито? HAL в ядре!
Ты впервые об этом узнал? И еще поучаешь? Печально, печально.
Windows и Linux основаны на микроядрах. Теперь буду знать.
Windows и Linux основаны на гибридных ядрах, и я это прямо написал. Ты вообще читаешь что я пишу или просто бредишь?
0
Контекст — это структура ядра, а не регистры.
Контекст — это принадлежащее задаче состояние регистров.
О как

Поскольку всем рулит ОС — для нее не составляет проблемы прежде чем передавать управление прочим задачам создать себе контекст и сохраниться в него.
Когда управление забирается, то у ОС значит контекст создается заново? Контекс ОС создает загрузчик.

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

Если ее это неволнует, то в каких регистрах храниться информация о свободной памяти?

Я то читаю, что ты пишешь… И меня очень удивляет политика делать ядро зависимым от HAL. Так не делают.
0
О как
Именно так. И эти два утверждения друг другу не противоречат. Просто первое описывает реализацию контекста со стороны ОС, а второе — суть контекста со стороны задачи.
Когда управление забирается, то у ОС значит контекст создается заново?
Кем забирается? Ее собственной задачей? Задачами рулит ОС, она же и озадачивается сохранением своего контекста и восстановлением контекста задачи перед передачей управления. Забирается вышестоящей задачей? Тогда это уже забота вышестоящей задачи, как сохранить контекст ОС, чтобы та ничего не заметила. Но к этому контексту сама ОС уже доступа не имеет.
Контекс ОС создает загрузчик.
Загрузчик ничего не создает. Он только загружает ОС и передает ей управление. С остальным ОС разбирается сама.
Если ее это неволнует, то в каких регистрах храниться информация о свободной памяти?
ОС принадлежит вся память, она сама хранит информацию о том, что, где и кем занято. Если же ОС принадлежит не вся память — то о не принадлежащей ей памяти она даже не знает и доступа к ней не имеет.
И меня очень удивляет политика делать ядро зависимым от HAL. Так не делают.
Именно так и делают. В винде и линуксе HAL непосредственно в ядре. Чистых микроядерных ОС для ПК вообще крайне мало. Точнее, один миникс. Даже QNX на самом деле, AFAIK, гибридный.
0
Именно так. И эти два утверждения друг другу не противоречат. Просто первое описывает реализацию контекста со стороны ОС, а второе — суть контекста со стороны задачи.
Не выдумывай определения. Контекст не может быть частью ядра. Т.к. у ядра есть тоже контекс.

Кем забирается? Ее собственной задачей? Задачами рулит ОС, она же и озадачивается сохранением своего контекста и восстановлением контекста задачи перед передачей управления.
У ядра какой контекст? Он что из вохдуха появляется?

Тогда это уже забота вышестоящей задачи, как сохранить контекст ОС, чтобы та ничего не заметила. Но к этому контексту сама ОС уже доступа не имеет.
ОС не имеет доступа к контексту?

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

ОС принадлежит вся память, она сама хранит информацию о том, что, где и кем занято.
Чито? Только то что дали.

Если же ОС принадлежит не вся память — то о не принадлежащей ей памяти она даже не знает и доступа к ней не имеет.
Чито? Тыж вверху сказал обратное. А как она должна узнать, что ей что-то не принадлежит? Может это несозданный контекст во время инициализации?

Именно так и делают. В винде и линуксе HAL непосредственно в ядре.
Откуда такая информация?
-1
Контекст не может быть частью ядра. Т.к. у ядра есть тоже контекс.
У ядра какой контекст? Он что из вохдуха появляется?
Оно само себе его и создает.
ОС не имеет доступа к контексту?
Тому, который контролируется слоем выше? Нет конечно.
Если он его не создает, то откуда берется контекст ядра? В регистрах сами появляются нужные значения во время старта? Во время старта они уже должны быть там.
Оттуда же, откуда и во всех программах — ядро само пишет туда нужные ему данные.
Чито? Только то что дали.
Ты о чем вообще? Всей принадлежащей ОС памятью заведует она сама (если в ОС вообще есть менеджер памяти, конечно).
Тыж вверху сказал обратное. А как она должна узнать, что ей что-то не принадлежит?
Это альтернативный вариант. ОС даже не узнает о том, что есть что-то, ей не принадлежащее — у нее туда просто нет доступа.
Откуда такая информация?
Из многих источников. Хотя бы той же вики, но не только. РТОС я может и не особо изучал, а вот десктопными осями интересовался.
0
В самом низу литература. Там ответ про загрузчик.

Также приведи четкий источник где будет дано подтверждение того, что ты говоришь.
0
Господа, вы в своюё сраче забыли, что у биоса тоже есть загрузчик, который загружает BIOS из serial eeprom (обычно по протоколу SPI) в ОЗУ, находится он в чипсете. Лол. как можно было пропустить такую очевидную вещь!
0
Так это не загрузчик ОС.
0
Есть и такой, да. И еще неизвестно сколько до него отработало загрузчиков. Тоже вполне равноправный, BIOS вполне себе ОС (хотя современные ОС в большинстве своем пользуются его услугами только в качестве загрузчика).
0
уже и BIOS ОС. Она рулит ресурсами системы… Да вокруг только одни ОС.
-1
Вполне себе ОС. Она управляет аппаратными ресурсами и предоставляет сервисы для вышележащего слоя. Правда, пользуется ими только DOS, более новые операционки его отпихивают и работают с аппаратурой напрямую.
Во многих компьютерах до IBM, кстати, ОС нередко была синонимом BIOS'а или же состояла из двух частей — BIOS'а и подгружаемой. А в игровых консолях и сейчас понятия OS и BIOS являются синонимами.
0
Какими ресурсами управляет BIOS? Какие ресурсы он распределяет? Если BIOS это ОС. Значит в BIOS понимает, что такое «процесс»?
-2
Какими ресурсами управляет BIOS?
Аппаратными. Доступ к дискам, например.
Если BIOS это ОС. Значит в BIOS понимает, что такое «процесс»?
Нет. Но понятие «процесс» не является обязательным для ОС. В DOS, например, процессов нет. Есть только исполняемая программа. Даже если назвать это процессом, то для биоса таким процессом будет запущенная им операционка (или иная запущенная им программа, скажем тот же memtest86 работает напрямую поверх биоса, без дополнительных ОС).
0
Аппаратными. Доступ к дискам, например.

Управление = предоставление…

не является обязательным для ОС.

меняем слово «процесс» на: программа, поток, нить, функция, и т.п. Далее выдаем это за доказательство истины.

Даже если назвать это процессом, то для биоса таким процессом будет запущенная им операционка

Linux это тоже программа. Значит в нем нет процессов. BIOS не может быть процессом т.к. он программа.
-1
меняем слово «процесс» на: программа, поток, нить, функция, и т.п.
Это все разные понятия. Причем далеко не ко всем ОС эти понятия применимы. Для DOS, например, осмысленно только понятие программы. Как и для BIOS.
Linux это тоже программа. Значит в нем нет процессов. BIOS не может быть процессом т.к. он программа.
Что за бред ты несешь? Я тебя не понимаю.
Линукс — программа.
Процессы в нем — есть, почему же нет?
BIOS не процесс потому, что процесс — это абстракция вышележащей ОС, а BIOS работает вне ОС. Хотя, если он будет работать под контролем другой ОС в качестве процесса — то будет процессом.
0
Нет. Но понятие «процесс» не является обязательным для ОС. В DOS, например, процессов нет. Есть только исполняемая программа. Даже если назвать это процессом, то для биоса таким процессом будет запущенная им операционка (или иная запущенная им программа, скажем тот же memtest86 работает напрямую поверх биоса, без дополнительных ОС).

Я так понимаю это ты писал?

Даже если назвать это процессом, то для биоса таким процессом будет запущенная им операционка
А для того кто запустил BIOS, чем является BIOS? Значит BIOS не ОС.
0
Я так понимаю это ты писал?
И что тебя тут не устраивает? Процессы — понятие многозадачных ОС, DOS к ним не относится. Впрочем, если и относится — то операционка такой же процесс для BIOS, как какой-нить command.com или digger.exe для DOS.
А для того кто запустил BIOS, чем является BIOS?
Тоже процессом.
Значит BIOS не ОС.
Да неужели? Windows — ОС? А если мы запустим ее на железе — она ОС? А если мы ее запустим на виртуалке, которая является процессом для хостовой ОС, винда перестанет быть ОС? А если мы запустим ее под гипервизором, у которого на том же железе параллельно еще десяток ОС крутится они тоже все разом из ОС будут разжалованы в не ОС?
0
С такой логикой ОС не существует в природе. Это просто плод воображения.
0
С такой логикой ОС не существует в природе. Это просто плод воображения.
Ага. Поэтому эта логика неверная. Но она твоя, а не моя :)
0
Нет. Но понятие «процесс» не является обязательным для ОС. В DOS, например, процессов нет. Есть только исполняемая программа. Даже если назвать это процессом, то для биоса таким процессом будет запущенная им операционка (или иная запущенная им программа, скажем тот же memtest86 работает напрямую поверх биоса, без дополнительных ОС).

Это развитие твоей мысли. Ведь кто-то запускает ОС. А кто-то еще и запускает процессор.
0
И что с того?
0
BIOS, например, управляет железом в специальных режимах, таких как SMM и NMI, внутри своего контекста, куда даже работающая в данный момент операционка не может влезть. Так что можно сказать, BIOS вполне себе ОС.
0
вангую: все пошли смотреть, что такое SMM и NMI.
0
где об этом сказано?
0
и где именно там сказано, что этим управляет BIOS?
0
Windows тоже обычная функция. Просто очень большая.
Да и не является она функцией с точки зрения интерфейса. Скорее подпрограммой, у которой определена только точка входа.
0
Нужно и мне доказывать все в стиле.

Процесс != задача
Функция != подраграма
Файл != фотография.
0
Ну а что поделать, если ты путаешь или подменяешь понятия?
+1
Забавно это делаешь как раз ты.
0
Где?
0
передать= отдать
-1
Нет, не так. «Передать управление» = «отдать управление». Это действительно одно и то же. Если нет — изволь подкрепить ссылками на определения. Причем крайне желательно — на отдельные определения этих двух понятий в одном источнике.
0
Это вообще из другой оперы. Причем для «переключения контекста» варианты «отдать управление» и «передать управление» тоже являются синонимами.
0
Речь идет о ОС. Но это из другой оперы.
Передают, то что получили. Отдают, то что уже имеют. При этом если забирают, то это не получили а значит нельзя передать, можно только отдать.
-1
Речь идет о ОС. Но это из другой оперы.
Речь шла о передаче управления в процессе запуска ОС, где это конструкции flow control. А ты внезапно приводишь понятие из управления задачами. Это разные вещи.
Передают, то что получили. Отдают, то что уже имеют
Это одно и то же. Любой код откуда-то получил управление и может отдать/передать управление только если его имеет.
0
Ну раз это одно и тоже. То маршрутизаторы все отдают пакеты)) А передачей они нихера не заниамаються.
Это не синонимы. Это разные слова.
-1
Еще раз, разговор строго про термины «передача управление» и «отдача управления». Не о словах «отдать» и «передать». И эти термины идентичны.
0
Я всегда знал, что загрузчик передает. А ОС получает, иногда правда отдает и передает.
0
Все эти термины, кроме «получает» — одно и то же.
0
та лучше уже заменить на дает. И тогда вообще словарь можно урезать.
0
загрузчик не является частью ОС. Без него ОС не может существовать. А вот HAL может. Именно поэтому не может уже по определению быть ОС.
-1
Ну почему же, HAL тоже не будет работать, если никто не передаст ему управление. Для него «загрузчиком» в твоем понимании можно считать само пользовательское приложение. Которое в свою очередь будет «загружено» main'ом.
0
пользовательской приложение не отдает управление.
-1
Программа в дос тоже не отдает управление. Считать все программы для дос операционками, а саму дос загрузчиком?
0
Если не отдает, то как оно может быть загрузчиком?
0
Что «оно»? Загрузчиком оно не может быть просто потому, что ничего никуда не грузит. Но ты же называешь загрузчиком код, который просто передает управление. А программа на МК передает управление HAL'у (плюс он его получает и непосредственно от процессора, в прерываниях). Возвращается оно или нет — это уже отдельный вопрос. Из main, вообще говоря, управление тоже не возвращается. Будем считать main операционкой, а RESET-VECTOR загрузчиком? Можно, но это именно то, о чем говорит evsi и с чем ты споришь)
0
передать и отдать это совершенно разные слова.
-1
Только означают в данном применении одно и то же.
+1
директива «no return» всегда однозначна.
0
Это не директива, а комментарий в документации (а если и директива, то всего лишь рекомендация для оптимизатора).
К тому же, main() сама по себе в 99% случаев no return. Записываем ее в ОС, а RESET_VECTOR: jmp @startup в загрузчик?
0
Я так понимаю ты main хочешь наделить функциями ядра?
0
Нет, я всего лишь делаю выводы из твоих утверждений. Это такой прием, называется «доказательство от противного». Принимаешь опровергаемые предпосылки за верные и делаешь из них выводы, пока не упрешься в противоречие.
Так вот из твоих утверждений следует, что RESET_VECTOR: jmp @startup — загрузчик. Причем независимо от наличия RTOS.
0
Ок. AVR. После сброса первым вызвался бут. Он установил прошивку и передал управление main. Произошла загрузка OS. RESET_VECTOR уже стал загрузчиком?
-1
Произошла загрузка OS
Где? В какой момент? Если ты о загрузке прошивки бутлоадером — да, это загрузка. Так никто и не спорит с тем, что бутлоадер — загрузчик.
RESET_VECTOR уже стал загрузчиком?
Это тебя надо спросить. По твоей логике RESET_VECTOR — загрузчик. По моей это обычная точка входа. Точно так же, как и osStart(). Точно так же, как main(). Ничто из этого к загрузчикам отношения не имеет.
0
main загрузил ОС. При этом не было вызова RESET_VECTOR. Как произошла загрузка без загрузщика?
-1
main загрузил ОС
Откуда и куда? Без ответа на этот вопрос следущие два смысла не имеют.
0
что значит куда? Он проинициализировал ядро и отдал ему управление. Если нужно то загрузит его в оперативку.
0
Он проинициализировал ядро и отдал ему управление.
Это не загрузка. Вот если он загрузит его в оперативную память — тогда и только тогда он будет загрузчиком. Ну а исходя из этого ответа:
Как произошла загрузка без загрузщика?
Никакой загрузки и не было.
При этом не было вызова RESET_VECTOR.
Он в любом случае был — оттуда к main приходит управление.
0
ОК. Если Windows запустить из постоянной памяти, то значит он не загружен. А значит MBR не нужен. А значит загрузчиков нет.
0
Что есть «постоянная память»? Если это память в пространстве процессора, откуда код и будет исполняться — да, загрузка не требуется. Требуется только инициализация.
+1
ПЗУ это и есть ПЗУ. ОЗУ никогда небыла нужна. Ее используют только от безвыходности. Иначе всем придется смириться с очень медленными ПК. В микроконтроллерах этой проблемы частично уже нет. Досих пор не решили проблему с записью.

Загрузка будет происходить всегда. Начальные данные нужно загрузить. И неважно в какую память. Системный контекст должен быть всегда загружен. Но в случае с ПЗУ он будет слабо отличаться с инициализацией.
0
ох лол. на быстрых МК есть проблема с пропуском тактов при выполнении из флеша. не слышали? А в FPGA конфигурация по-вашему, почему в ОЗУ заливается?
«проблемы частично нет» — как-то странно звучит. проблема — она как мёд. либо есть, либо нет.
0
а зачем вообще нужна ОЗУ ?? Ты историю компов почитай. ОЗУ нахрен не нужна. Но технические реалии заставляются ее использовать.
0
мне кажется, толще некуда. ну правда, зачем нужна ОЗУ??
+1
ОЗУ нужна для хранения данных, с которыми работает процессор. Вот все остальные типы памяти не нужны, это да. Но реалии заставляют их использовать.
Для справки: ОЗУ есть Оперативное Запоминающее Устройство, а вовсе не энергозависимая память.
+1
Так если ее сделать энергонезависимой, то это будет революцией. Но этого еще не достигли.
0
Эм, вообще-то давно уже есть с десяток-два технологий энергонезависимой ОЗУ. Одна из них даже использовалась — память на магнитных сердечниках. Более новая технология — FRAM — тоже уже внедряется.
Вот только пока по совокупности характеристик на роль ОЗУ лучше всего подходит энергозависимая память — она дешевле, компактнее, быстрее, давно проработана, не изнашивается при перезаписи. Но в разработке уже куча технологий, которые сохраняют большинство этих преимуществ и при этом энергонезависимы.
0
Так об этом и говорю такие режимы как «Спящий» и «гибернация» бесполезны. Без энергозависимой памяти их можно заменить на «Выкл/Вкл».
0
Так и было. На IThappens'е даже история есть про такой компьютер, который можно вырубить рубильником, а затем врубить и он продолжит считать оттуда, где прервался.
0
ПЗУ это и есть ПЗУ
ПЗУ бывает разное.
ОЗУ никогда небыла нужна
Напротив, не нужно ПЗУ. Его используют только от безысходности — используемые технологии ОЗУ теряют содержимое при потере питания. Но уже есть варианты энергонезависимого ОЗУ (да и раньше были, кстати — скажем, на ферритовых сердечниках).
Загрузка будет происходить всегда. Начальные данные нужно загрузить.
Да, только для МК в большинстве случаев загрузчиком ОС является программатор, и загрузка производится всего один раз.
Системный контекст должен быть всегда загружен
Во первых, системный контекст — абстракция самой операционки. Ей же и создается. Во вторых — далеко не все ОС вообще имеют такое понятие.
0
Во первых, системный контекст — абстракция самой операционки. Ей же и создается. Во вторых — далеко не все ОС вообще имеют такое понятие.

Регистры абстрактны…
0
Как раз регистры — вполне определенная сущность процессора, в отличие от контекста, который является абстракцией ОС, предназначенной для того, чтобы каждая нить/задача считала, что регистры находятся в ее безраздельном владении.
Ты опять путаешь понятия.
0
Ну не яже ввожу удобные термины и меняю их смысл по ходу общения.
0
Как раз ты этим и занимаешься.
0
Ты выдумал два определения контекста которые перечат друг другу.
0
Где это? Те, что я давал, друг другу не перечат. Они лишь раскрывают суть контекста с разных сторон.
0
Откуда взяты эту определения контекстов?
0
Скомпилированы из разных источников.
0
источники. Я как вижу по другому общение не возможно.
0
Википедия, книги и статьи. Сформулировано мной на основе подчерпнутых сведений.
Кстати, ты тоже не спешишь обосновывать свои слова цитатами из источников.
0
Уже начал с цитатами. Так, что тоже подтверждай свои слова.
0
Я так понимаю, что если в будущем программы будут выполнятся с жесткого диска, то загрузчики не будут существовать?
0
Примерно так, да. Но это крайне маловероятно.
0
А какже «запускаторы»? Или системы запускаются сами по себе? Это не маловероятно а то к чему идут. На данный момент это сложно реализовать, т.к. ПЗУ еще медленная. ОЗУ вообще бесполезная вещь, ее достоинство только скорость работы.
0
«Запуск» и «загрузка» — разные понятия. Запускатор будет, если только ОС не будет сама по себе расположена там, откуда процессор при запуске начинает исполнять программу.
Это не маловероятно а то к чему идут
На самом деле уходят. Если раньше в ROM-памяти была вся ОС и выполнялась прямо оттуда, то теперь даже из флеша операционка грузится и грузится в несколько стадий. МК пожалуй последнее, где ОС запускается напрямую, без загрузки.
Ну и я говорил конкретно про выполнение напрямую с жесткого диска (это такой вполне определенный носитель информации на основе магнитной записи).
0
Кто получает управление самым первым???? В микроконтроллерах это main.
Кстати, это не так. В микроконтроллерах это код, лежащий по определенному адресу. Туда, обычно, попадает стартовый код рантайма, а вовсе не main.
+3
Кстати, это не так. В микроконтроллерах это код, лежащий по определенному адресу. Туда, обычно, попадает стартовый код рантайма, а вовсе не main.

Кстати это не так. Сначала запускается ядра микроконтроллера. Кстати это не так сначала подается питание. Кстати это не так ток возникает из…
-3
Вы путаетесь в базовой терминологии, но «вы позволяете себе давать советы вселенского масштаба и вселенской же глупости» (С) М. Булгаков.
+1
прекращай корчить из себя опозиционера.
-2
прекращай корчить из себя опозиционера.
Не из себя, а из вас. Да, вобщем, и корчить-то ничего не нужно, достаточно вам не сильно мешать, дальше вы сами демонстрируете глубину ваших глубин…
+2
В голом DOS ядра нет как такового, поскольку после передачи управления пользовательскому приложению, DOS полностью теряет управление. Запущенное пользовательское приложение полностью и безраздельно становится хозяином положения, и единственное, что может вывести его из этого состояния, это сработка ранее запущенного TSR-а. Приложение в DOS может без ограничения получить доступ к любой области памяти и к любому порту, может свободно завернуть вектора прерываний на себя, лишить TSR-ы возможности получить управление, изменить код в области памяти, в которую загружена сама DOS и еще может натворить кучу разного беспредела. Его выполнением никто не управляет. Приложение, запущенное из под DOS может вообще отказаться от вызовов функций не только DOS, но и BIOS.
Как по мне, DOS — это такой себе BIOS extender, поскольку вызов любой файловой, например, функции из INT21h, когда дело доходило до секторного доступа к носителю, заканчивался вызовом INT13h, а это уже BIOS. Напрямую сама DOS оборудованием не управляла. Драйвера мыши и т.п. — обычные TSR-приложения.
+1
В голом DOS ядра нет как такового, поскольку после передачи управления пользовательскому приложению, DOS полностью теряет управление.

В DOS ядро монолитное. И во всех ОС ядро теряет управление и получает его только по системному событию.

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

Отсутствие защищенного режима делает возможным отсутствие ядра?

Приложение, запущенное из под DOS может вообще отказаться от вызовов функций не только DOS, но и BIOS.
Использование системных сервисов является обязательным для приложения? Если под Windows запустить приложение не используещее его сервисы, то винда потеряет статус ОС?

Как по мне, DOS — это такой себе BIOS extender, поскольку вызов любой файловой, например, функции из INT21h, когда дело доходило до секторного доступа к носителю, заканчивался вызовом INT13h, а это уже BIOS. Напрямую сама DOS оборудованием не управляла. Драйвера мыши и т.п. — обычные TSR-приложения.
Если это BIOS extender то ты признаешь, что у BIOS есть драйвера, файловая система, файлы?
0
И во всех ОС ядро теряет управление и получает его только по системному событию.
В Windows пользовательское приложение может препятствовать вызову этого события? Нет. А в DOS система получит управление только тогда, когда этого пожелает приложение.
Отсутствие защищенного режима делает возможным отсутствие ядра?
Речь не о возможности или не возможности, а о конкретном случае. От ядра (в нынешнем его понимании) в ДОСе только менеджер памяти, да и то не с монопольными правами. Ядро оси, ИМХО, в первую очередь — диспетчер, хотя тут я могу и ошибаться.
Если под Windows запустить приложение не используещее его сервисы...
Интересно, как Вы этого добьетесь? К чему Вы сможете достучаться в обход Windows? И даже это приложение постоянно будет прерываться диспетчером.
Если это BIOS extender то ты признаешь, что у BIOS есть драйвера, файловая система, файлы?
Файловой системы и файлов — нет, а вот драйверов — хоть отбавляй, она вся из драйверов состоит. И поэтому в ДОСе не было драйверов жесткого диска (Smartdrv — не в счет, это кэш и с оборудованием он все равно через BIOS работал), клавиатуры, пищалки, видеокарты. Да, BIOS — приличный кусок ОСи. И то, что современные оси ею не пользуются — это уже их проблемы.
0
В Windows пользовательское приложение может препятствовать вызову этого события? Нет. А в DOS система получит управление только тогда, когда этого пожелает приложение.
В кооперативках тоже самое. Но в них ядро почемуто есть.

Речь не о возможности или не возможности, а о конкретном случае. От ядра (в нынешнем его понимании) в ДОСе только менеджер памяти, да и то не с монопольными правами. Ядро оси, ИМХО, в первую очередь — диспетчер, хотя тут я могу и ошибаться.
Microsoft эпично врет о монолитном ядре. А проект FreeDOS на это еще и купился.

Интересно, как Вы этого добьетесь? К чему Вы сможете достучаться в обход Windows? И даже это приложение постоянно будет прерываться диспетчером.
Драйвер это отдельное приложение. Находясь в нем мы находимся на уровне ядра но не в самом ядре.

Файловой системы и файлов — нет, а вот драйверов — хоть отбавляй, она вся из драйверов состоит.
Вот этот момент подробней. Где находится информация о драйверах в BIOS?
0
В кооперативках тоже самое. Но в них ядро почемуто есть.
В кооперативках нет диспетчера очереди? А в ДОСе его нет. Тут вопрос возникает, что Вы подразумеваете под понятием «ядро»?
Драйвер это отдельное приложение. Находясь в нем мы находимся на уровне ядра но не в самом ядре.
Т.е. драйвер не использует сервисы оси? И ядро не никак не влияет на его работу?
Где находится информация о драйверах в BIOS?
А чем по Вашему является INT13h, как не драйвером дисковых накопителей? Или это не стандартизированный API для обращения к оборудованию? На заре появления жестких дисков в персоналках, винчестеры шли в комплекте с контроллером, на котором была своя ПЗУ, которая расширяла этот самый INT13h, поскольку те персоналки еще ничего не знали о винчестерах. Если для Вас не очевидно, что BIOS — это набор драйверов плюс функция загрузки и запуска загрузчика ОС, то я не вижу смысла в продолжении этой дискуссии.
0
Если для Вас не очевидно, что BIOS — это набор драйверов плюс функция загрузки и запуска загрузчика ОС, то я не вижу смысла в продолжении этой дискуссии.
Это должно быть очевидно любому, кто удосужился прочитать расшифровку аббревиатуры «BIOS». Сначала хотел написать «хоть раз прочитать», но потом вспомнил, что некоторым одного раза мало…
+2
В кооперативках нет диспетчера очереди? А в ДОСе его нет. Тут вопрос возникает, что Вы подразумеваете под понятием «ядро»?
В кооператвках диспетчер есть. Ядро это как минимум диспетчер и системный обработчик событий, также и сервисы. Если в досе всего один процесс, то это неозначает что диспетчера на этот один процесс нет.

Т.е. драйвер не использует сервисы оси? И ядро не никак не влияет на его работу?

Я чуть ниже книгу привел. Драйвер это делать не обязан. Ядро может отдавать указания, я вот драйвер и решит, что сделать с этими указаниями.

А чем по Вашему является INT13h, как не драйвером дисковых накопителей?
Эта функция находиться вне BIOS? И почему ее не назвали драйвером.

Если для Вас не очевидно, что BIOS — это набор драйверов плюс функция загрузки и запуска загрузчика ОС, то я не вижу смысла в продолжении этой дискуссии.
Откуда взята эта информация? Источники ее появления.
0
Откуда взята эта информация? Источники ее появления.
Origin of BIOS:

B(asic) I(nput)/O(utput) S(ystem)
.
0
В этом определении есть упоминания драйверов?
-1
Весь биос и есть набор драйверов для некоторого набора периферии + вспомогательный код + загрузчик. А то, что в самой аббревиатуре отсутствует слово «драйвер», вовсе не означает, что драйверов там нет.
+2
В определении нет. Нигде это не указано. Это секретная информация?
-1
В определении нет.
Именно в определении это и есть. Открытым текстом, никаких секретов — «базовая система ввода-вывода» это именно оно.
0
Тогда почему нет слова драйвер? Забыли дописать…
-1
Тогда почему нет слова драйвер?
А без этого слова драйвер не драйвер?
+1
Ядро это как минимум диспетчер и системный обработчик событий, также и сервисы. Если в досе всего один процесс, то это неозначает что диспетчера на этот один процесс нет.
Да вот нету его. Shell (command.com) или NC вызывает функцию 4bH INT21h, тот же Shell или NC получает управление обратно после завершения приложения. В процессе выполнения приложения, это выполнение никак не диспетчеризируется. Прервать его могут только прерывания.
А большинство указателей на обработчики аппаратных прерываний даже после загрузки ДОС продолжают смотреть в BIOS.
Ядро может отдавать указания, я вот драйвер и решит, что сделать с этими указаниями.
Но для своей работы драйвер должен взаимодействовать с ядром. Хотя бы получить эти указания. Т.е. без ресурсов ОСи ни фига не выходит.
Эта функция находиться вне BIOS? И почему ее не назвали драйвером.
Она выполняет те же функции, что и драйвер, один в один, т.е. предоставляет стандартизированный API для обращения к оборудованию. Почему ее так не назвали — вопрос четвертый.
Откуда взята эта информация?
Из дизассемблированного листинга AMI BIOS c 386DX.
0
Но для своей работы драйвер должен взаимодействовать с ядром. Хотя бы получить эти указания. Т.е. без ресурсов ОСи ни фига не выходит.
В общем случае, драйвер частью ядра не является. Но реально это так только в микроядерных ОС, которых практически нет. В монолитных все драйверы входят в состав ядра, в гибридных в дополнение к встроенным в ядро могут подгружаться user-space драйверы. Windows и Linux как раз относятся к гибридным, ранние версии Linux и вовсе к монолитным.
0
В общем случае, драйвер частью ядра не является.
Ну это само-собой разумеется.
0
В монолитных все драйверы входят в состав ядра
Подтверди. Где и как он входит в состав.
-1
Неоднократно упоминавшийся Linux Kernel вообще на 95% состоит из драйверов.
0
цифра выдумана только что?
0
Прогулка по сорсам линуха вам поможет убедиться в этом самостоятельно.
0
Примерная прикидка. Скорее всего заниженная.
0
Кстати о гибридном ядре в Windows. В приведено книге дано описание. Таки монолит.
0
Ну, если монолит, то там вообще весь HAL — кусок ядра. Впрочем, в последних версиях оно таки гибридное, ближе к монолитному.
0
В книге есть огромная глава по ядру. Почему то хал там не в ядре. Более того он находится на более низком уровне и существует без ядра.
0
Если посмотреть на их схемы, то там вообще обнаружится такая прелесть, как микроядро. Которого в винде отродясь не было.
0
Если посмотреть на их схемы, то там вообще обнаружится такая прелесть, как микроядро. Которого в винде отродясь не было.
В какой схеме указанно наличие микроядра?
0
Врут, безбожно врут…
0
Да вот нету его. Shell (command.com) или NC вызывает функцию 4bH INT21h, тот же Shell или NC получает управление обратно после завершения приложения. В процессе выполнения приложения, это выполнение никак не диспетчеризируется. Прервать его могут только прерывания.
А большинство указателей на обработчики аппаратных прерываний даже после загрузки ДОС продолжают смотреть в BIOS.
Если нет, то вам следует обратиться в FreeDOS и сказать им чтоб больше не обманывали людей.

Но для своей работы драйвер должен взаимодействовать с ядром. Хотя бы получить эти указания. Т.е. без ресурсов ОСи ни фига не выходит.
Внизу указан источник и глава. Драйвер может работать без ядра.

Она выполняет те же функции, что и драйвер, один в один, т.е. предоставляет стандартизированный API для обращения к оборудованию. Почему ее так не назвали — вопрос четвертый.
Значит эта функция существует без BIOS?

Из дизассемблированного листинга AMI BIOS c 386DX.
Который трактовал кто?
0
Если нет, то вам следует обратиться в FreeDOS и сказать им чтоб больше не обманывали людей.
С FreeDOS не сильно разбирался, если не трудно, то ссылочку дайте, где описан их диспетчер. Где он в находится в пределах аналогов IO.SYS, MSDOS.SYS и COMMAND.COM. Приблуд, типа Dos/4GW не предлагать.
Значит эта функция существует без BIOS?
Нет, а зачем ей существовать без BIOS, когда она ее часть?
Который трактовал кто?
Я. Мне этого достаточно.
0
ru.wikipedia.org/wiki/FreeDOS
www.freedos.org/
www.fdos.org/kernel/#freedos

Вот с диспетчером таки да. Запуск одной программы не описан. Это уже нужно колупать исходники ядра
sourceforge.net/projects/freedos/files/Kernel/2041/

Я. Мне этого достаточно.
Источник понятен.
0
Спорить на эту тему можно до бесконечности, поскольку понятие «ядро» весьма расплывчато. Для меня, повторюсь, ядро — это диспетчер, сообщения, события. Ничего этого в ДОСе нет. ИМХО, ДОС — ФС, диспетчер памяти, shell и API. За FreeDOS спорить не буду, не изучал, мало-ли чего они там реализовали. А то, что они IO.SYS и MSDOS.SYS в один файл объединили и назвали его KERNEL.SYS, то некоторые жигули ракетой называют.
0
Единственное более-менее четкое разделение — это kernel-mode и user-mode. В остальном — кому что вздумалось ядром назвать, то и назвали.
0
Ядро оси, ИМХО, в первую очередь — диспетчер, хотя тут я могу и ошибаться.
Зависит от архитектуры самой операционки. Я бы сказал, что для типичной гибридной оси ядро это набор обработчиков прерываний (в первую очередь по исключениям защиты, NMI и таймеру) + переключение контекстов. У микроядерных это, во многих случаях система обмена сообщениями (но, опять-таки, зависит от архитектуры). У кооперативки ядро это тот самый любимый a9d while(1) {} или бродилка по состояниям в FSM. Это все тоже IMHO, конечно.
0
Ну я же написал, что могу ошибаться. Просто определение ядра — довольно расплывчатая штука.
0
Да и я, вобщем, об этом же.
0
Ядро оси, ИМХО, в первую очередь — диспетчер, хотя тут я могу и ошибаться.
Ну, по принципам микроядерных ОС ядро — это система процессов, их изоляции и взаимодействия. В гибридных и монолитных туда же добавляется HAL и вообще все, что авторы пожелают.
0
ядро — это система процессов, их изоляции и взаимодействия.
Что и требовалось доказать. Ни одного, ни другого, ни третьего в ДОСе нет.
0
HAL, кстати, в ДОСе тоже нет. :)
0
Ну, некоторые зачатки есть. Нужные для работы консоли и ФС. Традиционно для однозадачных систем вызываются через софтовые прерывания (собственно, HAL из BIOS'а дергается точно так же).
0
Если под Windows запустить приложение не используещее его сервисы, то винда потеряет статус ОС?
А вы попробуйте создать такое приложение. Так что бы совсем не пользовалось, ни напрямую, ни окольными путями (через рантайм). Функционально вполне можно ограничиться банальным «Hello World!».
+2
А в ДОСе я это мог сразу в видеопамять выгрузить, ни ДОСа тебе, ни БИОСа. :)
0
driver. Я так полагаю о системном программировании ты много читал…
0
driver
Шикарно. Драйвер уже стал пользовательским приложением? Не хотите рассказать, куда и как он напишет этот самый «Hello World»?
Я так полагаю о системном программировании ты много читал…
И не только читал. Впрочем, вам пока от этого проку никакого, вы еще в терминологии путаетесь, так что даже объяснить вам что-либо довольно проблематично.
0
Использование системных сервисов является обязательным для приложения? Если под Windows запустить приложение не используещее его сервисы, то винда потеряет статус ОС?

Шикарно. Драйвер уже стал пользовательским приложением? Не хотите рассказать, куда и как он напишет этот самый «Hello World»?

Дописывать мои посты удумал?

И не только читал. Впрочем, вам пока от этого проку никакого, вы еще в терминологии путаетесь, так что даже объяснить вам что-либо довольно проблематично.

Лутиратурку укажите где подтверждаются слова.
-1
Дописывать мои посты удумал?
Ни в коем случае, только напоминаю текст своего:
А вы попробуйте создать такое приложение. Так что бы совсем не пользовалось, ни напрямую, ни окольными путями (через рантайм). Функционально вполне можно ограничиться банальным «Hello World!».
Ничего не делающее приложение, как не сложно догадаться, не интересно, поскольку возникает вопрос, является ли оно приложением (и соответственно, может ли оно доказывать, что винда не ОС). Если вы в состоянии решить описанную выше задачу драйвером — дерзайте, хотя вопрос о том, можно ли считать драйвер приложением останется, но его можно будет обсудить позже.

Лутиратурку укажите где подтверждаются слова.
Слова подтверждаются в орфографическом словаре.
0
Ты даписал слово «пользовательское». Не отбрехивайсся.

Ничего не делающее приложение, как не сложно догадаться, не интересно, поскольку возникает вопрос, является ли оно приложением (и соответственно, может ли оно доказывать, что винда не ОС).

Драйвер находится вне ядра. Графический драйвер находится тоже внеядра. Более того он находится на уровне HAL, а значит он еще ниже. Зачем использовать сервисы ОС когда можно обратиться на прямую? Или более того встроить нужные функции в сам драйвер. При этом драйвер часть чистемы и он будет находиться под Windows.

Слова подтверждаются в орфографическом словаре.
Ни одного названия указать не в состоянии?
-1
Ты даписал слово «пользовательское».

Я дописал его себе, а не вам. Как-то не приходила в голову мысль, что «Hello World!» можно написать в виде драйвера. Впрочем, можете это слово вычеркнуть.
Не отбрехивайсся.
Нет необходимости.
Драйвер находится вне ядра. Графический драйвер находится тоже внеядра. Более того он находится на уровне HAL, а значит он еще ниже. Зачем использовать сервисы ОС когда можно обратиться на прямую? Или более того встроить нужные функции в сам драйвер. При этом драйвер часть чистемы и он будет находиться под Windows.
Зачем все эти словеса? Вам ничего не мешает продемонстрировать работающее приложение, выводящее «Hello World» в работающей винде и не использующее вообще никаких сервисов операционки, прямо или косвенно. Под «сервисами операционки» понимаются, в том числе, сервисы предоставляемые ядром или любой его частью (в том числе другими драйверами, раз уж драйвера часть системы).
Ни одного названия указать не в состоянии?
Отчего же, в состоянии. Толку вам от этого, правда, никакого. Вот на вскидку то, что еще сохранилось в моей библиотеке:
Л. Бек, Введение в системное программирование
С. Кейслер, Проектирование операционных систем для малых ЭВМ
С. Краковяк, Основы организации и функционирования ОС ЭВМ
0
Зачем все эти словеса? Вам ничего не мешает продемонстрировать работающее приложение, выводящее «Hello World» в работающей винде и не использующее вообще никаких сервисов операционки, прямо или косвенно.
Делаешь перезагрузку Windows и смотришь, что появляется на экране. Это наглядный факт моих слов. Также это подтверждается в литературе и главе которую я привел. Как видно драйвера выводят информацию даже без загрузки ядра.

Л. Бек, Введение в системное программирование
С. Кейслер, Проектирование операционных систем для малых ЭВМ
С. Краковяк, Основы организации и функционирования ОС ЭВМ
После слива таки приел. А теперь в какой главе подтверждается твои высказывания о HAL как ОС.
0
Делаешь перезагрузку Windows и смотришь, что появляется на экране. Это наглядный факт моих слов.
Это наглядный факт того, что они что-то выводят, не более того. Ваши слова никаким образом они не подтверждают.
Также это подтверждается в литературе и главе которую я привел. Как видно драйвера выводят информацию даже без загрузки ядра.
А с чего вы решили, что в этот момент ядра еще нет?
После слива таки приел.
После вашего окончательного слива таки привел. Вдруг кому-то будет полезно (на вас надежды мало).
А теперь в какой главе подтверждается твои высказывания о HAL как ОС.
Как прочитаете — узнаете.
0
Это наглядный факт того, что они что-то выводят, не более того. Ваши слова никаким образом они не подтверждают.
очередной слив.

А с чего вы решили, что в этот момент ядра еще нет?
еще один слив. Читаем главу которую я привел. Книга открыта и бесплатна.

Как прочитаете — узнаете.
третий слив.
0
очередной слив.
Да, в вашем исполнении.
еще один слив. Читаем главу которую я привел. Книга открыта и бесплатна.
Цитату об отсуствии ядра и каких-либо сервисов приведете или так и будете юлить?
третий слив.
Ну точного подсчета я не вел, но это явно не третий ваш слив. Скорее тридцать третий или около того.
+2
Если диск, содержащий загрузочный или системный том, яв
ляется SCSIустройством и недоступен через BIOS, Ntldr загружает файл
Ntbootdd.sys и использует его функции доступа к диску вместо аналогичных
функций загрузочного кода. Ntbootdd.sys — это экземпляр минипортдрай
вера SCSI, применяемый Windows для полноценного доступа к загрузочно
му диску. (О дисковых драйверах см. главу 10.) Затем Ntldr с помощью встро
енного кода файловой системы считывает из корневого каталога файл
Boot.ini. В отличие от кода загрузочного сектора код Ntldr способен читать
и подкаталоги

Очередной твой слив.
0
А это вообще драйвер не винды, а ее загрузчика. Опять же мимо кассы.
0
Ок. Цитуту с этим утверждением в студию.
0
Ntldr загружает файл
Ntbootdd.sys и использует его функции доступа к диску
Вот же она.
0
Ntbootdd.sys — это экземпляр минипортдрай
вера SCSI, применяемый Windows для полноценного доступа к загрузочному диску.

далее глава
Драйвер класса дисков, порт- и минипорт-драйверы
0
Это всего лишь означает, что загружая этот драйвер NTLDR сама предоставляет ему сервисы, обычно предоставляемые ядром. Драйвер же все равно работает под Windows, а под NTLDR. Так что если он что-то и делает — то не под управлением Windows и как пример программы, что-то делающей в Windows без участия Windows не годится.
0
Очередной твой слив.
Никакого слива и близко нет. Вы пока не дошли до момента, когда ваше приложение (драйвер) сможет вывести надпись.
0
Прочитай главу троль.
-1
Повторяю:
Вы пока не дошли до момента, когда ваше приложение (драйвер) сможет вывести надпись.
0
Делаешь перезагрузку Windows и смотришь, что появляется на экране.
То, что там выводится — пишется либо биосом (POST, таблица оборудования), либо уже после загрузки ntoskrnl. Исключением является Windows 9x — там после биоса кучу информации вываливает DOS, до того как загрузит винду и та его отпихнет.
0
То, что там выводится — пишется либо биосом (POST, таблица оборудования), либо уже после загрузки ntoskrnl.

BIOS часть или сервис ядра Windows?
0
BIOS часть или сервис ядра Windows?
Биос не является и приложением винды, так что не катит.
0
Речь шла о ядре. Склероз?
0
Речь шла о ядре.
Речь шла о виндовом приложении не использующем сервисы винды.
Склероз?
У вас, судя по всему, да.
0
Речь шла о виндовом приложении не использующем сервисы винды.

Использование системных сервисов является обязательным для приложения? Если под Windows запустить приложение не используещее его сервисы, то винда потеряет статус ОС?

Склероз?
-1
Если под Windows запустить приложение не используещее его сервисы, то винда потеряет статус ОС?
Под Windows Вы не запустите приложение, не использующее сервисы ОСи. Оно даже завершиться без этих сервисов не сможет.
0
Ок. Загрузчик загружает драйвера, некоторые даже использует. Я ведь ядро то еще не работает. Загрузчик ведь не завершил работу.
0
Так и драйверы эти не в винде работают. А задача была — приложение, работающее в винде без использования ее сервисов. А ты принялся ссылаться на приложения, работающие не в винде.
+2
А что есть «не в винде»? Т.е. после старта ядра винды?

Событие может запускать драйвер. Событие возникает во время прерывания. Значит по событию можно запустить драйвер который воспользуется BIOS.

Ядро различает прерывания и исключения: прерывание(interrupt) явля
ется асинхронным событием (т. е. оно может произойти в любой момент
независимо от текущих команд, выполняемых процессором). Прерывания в
основном генерируются устройствами вводавывода и таймерами.


Как видим не обязателен сервис винды для запуска прерывания.
-1
А что есть «не в винде»? Т.е. после старта ядра винды?
Как минимум. Если вести речь не о драйвере, то надо бы еще и загрузки остальной части винды дождаться — графической системы и юзерспейса.
Событие возникает во время прерывания.
Но событие — это сервис Windows. А условия было не использовать сервисы Windows.
драйвер который воспользуется BIOS.
Врядли получится воспользоваться средствами BIOS — во первых, винда отбирает у него руль, а во вторых вполне может и доступ блокировать (хотя драйверу врядли заблокирует).
0
Врядли получится воспользоваться средствами BIOS
За давностью лет запамятовал уже подробности, но, помнится, там и что бы этот сервис вызвать надо очень неслабо потрахаться. Там грабли с режимами работы процессора, переключениями между ними и тем, что сервисы биоса доступны тьлько для реального режима проца (когда защит вообще нет) или режима vm86 (который, если мне память не изменяет, доступен только в 3-м кольце). На это сверху накладывается управление доступом к памяти. Вобщем гемор еще тот.
0
Склероз?
У вас да. Вы пока пример такого приложения работающего под виндой не привели.
0
BIOS — система, заведующая компьютером до загрузки Windows. Никакого отношения к винде и Hello World под виндой, но без использования ее сервисов не имеет.
Ты бы еще упомянул надпись, которая появляется до самого биоса. Их даже две — первую выведет монитор, вторую видеокарта (точнее, ее собственное firmware). К вопросу
Если под Windows запустить приложение не используещее его сервисы, то винда потеряет статус ОС?
это не имеет никакого отношения.
0
Драйвер Windows работает не под Windows? приведи источник.
-1
приведи источник.
С удовольствием. Этот источник — ты.
+2
Это твое а не мое, не приписывай. Подтверди либо сливайся.
-1
Как видно драйвера выводят информацию даже без загрузки ядра.
Да вот хотя бы. Не говоря уже о том, что
Драйвер Windows работает не под Windows? приведи источник.
Явно не является ответом на комментарий. Я так нигде ничего подобного не утверждал. Я утверждал, что выводимые при загрузке винды надписи или не имеют к ней отношения, или выводятся после загрузки ядра.
0
Так драйвер Windos относится к Windows?
0
Какое отношение этот вопрос имеет к данной ветке обсуждения? Строго говоря, мне следовало задать этот вопрос прежде, чем отвечать на это. Так что вернемся к корню вопроса — дай осмысленный ответ на это.
0
BIOS — система, заведующая компьютером до загрузки Windows. Никакого отношения к винде и Hello World под виндой, но без использования ее сервисов не имеет.
Ты бы еще упомянул надпись, которая появляется до самого биоса. Их даже две — первую выведет монитор, вторую видеокарта (точнее, ее собственное firmware). К вопросу

Ты об этом? Так BIOS не относится к Windows. Может его использовать если не нравится сервисы ядра.
0
*драйвер может
0
Так BIOS не относится к Windows.
Ну вот и прекрасно. А значит надписи при загрузке, на которые ты ссылаешься, отношения к задаче тоже не имеют.
Может его использовать если не нравится сервисы ядра.
Насколько я знаю, Windows, как и Linux отстраняют BIOS от управления железом, так что от общения с биосом толку не будет — он сам уже ничего не может.
0
Делаешь перезагрузку Windows и смотришь, что появляется на экране.
Это еще не ОСь, это загрузчик. Вы при загруженном ядре, после того, как лампочки на клаве мигнут, попробуйте что либо без использования ресурсов ОСи сделать.
0
Драйвер не входит в состав ОС? Подтверди.
0
Делаешь перезагрузку Windows и смотришь, что появляется на экране.
На этой стадии драйверами еще и не пахнет, ядро даже еще не загружено.
0
Значит информация о загрузки драйверов и информация предоставленная драйверами вранье? Драйвер находится на уровне ядра а не в ядре. Поэтому ядро не является обязательным условием.
0
ядро не является обязательным условием.
А кто же эти драйвера загружает, позвольте поинтересоваться. Не ядро ли случайно? И не оно ли дает команду на инициализацию этих самых драйверов?

Короче, спор с Вашей стороны дошел до банального передергивания терминов, никакой конкретики. Вашими словами: «Покажи, где в ДОСе ядро или сливайся»

Мужики, харэ кормить этого тролля, а то у него несварение случится.
+1
Мужики, харэ кормить этого тролля, а то у него несварение случится.
Ну это уже его проблемы. Главное, что он вкусный.
0
А кто же эти драйвера загружает, позвольте поинтересоваться. Не ядро ли случайно?

Ниже я привел книгу и главу. Прочитай. Там четко описан момент загрузки драйверов.
0
Л. Бек, Введение в системное программирование
С. Кейслер, Проектирование операционных систем для малых ЭВМ
С. Краковяк, Основы организации и функционирования ОС ЭВМ
А как же Таненбаум?
0
Не сохранился :( Кто-то взял почитать и все вычитал…
0
Драйвер как минимум будет загружаться сервисами Windows, так что уже не катит. К тому же, драйверы работают через механизмы ядра и его API.
0
Драйвер как минимум будет загружаться сервисами Windows, так что уже не катит. К тому же, драйверы работают через механизмы ядра и его API.

Подтверди. Ниже дана книга.
-1
Скорее вам надо подвердить, что драйвера не пользуются сервисами ядра. Вы пока этого так и не сделали.
0
Я тебе привел цитату.
0
Из этой цитаты ваши утверждения никаким образом не следуют.
+1
Нет, драйверы самостоятельно и произвольно возникают в системе и никак с ней взаимодействовать не хотят. Может конденсируются, а может святым духом… :)))))
+1
Тогда тем, кто это подразумевает, самое время почитать учебник по операционкам. Ну или хоть вики осилить. Ан нет, кидаются спорить…
0
Спасибо не знал. Теперь каждую функцию буду называть ОС.

Windows величайшая ОС в мире. Столько параллельных ОС, рекурсивных ОС, и вложенных ОС мир еще не знал.
0
Статья называлась «что-то про стек», и тут один гражданин назвал либу — ОС, и понеслось :)
0
Спасибо не знал.
Это не единственное, чего вы не знаете.
Теперь каждую функцию буду называть ОС.
Я даже не удивлюсь.
Windows величайшая ОС в мире. Столько параллельных ОС, рекурсивных ОС, и вложенных ОС мир еще не знал.
Вам осталось только признаться в любви Биллу Гейтсу. Хотя, насколько я знаю, он традиционной ориентации и может не оценить.
-1
А вот хамить не стоит. Это признак слабоумия.
+1
А вот хамить не стоит.
Я не хамлю, а разговариваю с опонентом на понятном ему языке. Как не сложно заметить, в общении, например, с вами я подобным стилем не пользуюсь, поскольку, не смотря на разногласия по обсуждаемому вопросу, вы не пользуетесь ничем подобным по отношению ко мне.
+2
Мне показалось, что уже на грани. Давайте уважать друг друга :)
0
Позвольте вставить свои 5 копеек.

Касательно того, чем занимается автор статьи

Если можно впихнуть вытеснялку, то почему бы и не впихнуть?

Многозадачность – это один из инструментов, который может использовать программист для написания кода под МК. Но это не панацея, это не значит, что везде, где можно, нужно ее использовать.
На небольшом количестве асинхронных задач вполне нормально работает машина состояний. Но, с ростом количества задач и с ростом сложности реализации каждой задачи (с увеличением количества узлов в гафе состояний) машина состояний сильно разрастается, и код становится нечитаемым. Один из вариантов решения – переход к многозадачности.

Многозадачная ОС – отличный инструмент, но нужно понимать где и когда его следует использовать.

А то что предлагает автор (использование вытесняющей многозадачности на слабых МК) это размен «шило на мыло». Теперь у нас нет проблем с машиной состояний, зато есть проблемы со стеком. Давайте решать теперь их…

Многозадачность это хорошо, я сам часто использую FreeRTOS, но не нужно подходить к вопросу с фанатизмом.

Касательно надежности многозадачной ОС.

У машины состояний есть один плюс, количество состояний фиксировано, следовательно, можно написать тест, который покрывает все возможные варианты (100% покрытия). Но, при большом количестве состояний, поддерживать такой код будет просто нереально. И, в таких условиях, вероятность ошибки в коде резко возрастает (и 100% покрытие тестов не спасает). Поэтому, в таких случаях эффективнее прейти к многозадачной ОС. Тот же Сuriosity работает под VxWorks.

Все вышесказанное — сугубо мое ИМХО.
+7
  • avatar
  • e_mc2
  • 24 декабря 2012, 23:06
проблем со стеком нет. скачайте операционку из предыдущей статьи, там ещё 600+ байт свободно кроме стека, на 4х нитях.
но еесли проблем нет, то не значит, что стеком надо срать направо и налево.
Надёжность МС кончается, начиная с определённого порога, когда код и его нетривиальность сильно увеличивается. Вы сами это написали в последнем абзаце.
0
Я хочу заметить, что в некоторых архитектурах (мной замечено в ARM), с использованием прерываний, очень непросто определить потребности в глубине стека. А некоторые компиляторы, даже за немалые деньги, ваще неправильно оценивают использование стека.
Будьте осторожны.
0
Особо укуренным людям.

Откопал книгу которую в свое время прочитал полностью.
Внутреннее устройство Windows

Я думаю ни у кого из вменяемых людей авторитетность этой книги не вызывает сомнения.

Если кому-то впадлу читать всю книгу. То читаем только
Загрузочный сектор и Ntldr на платформах x86 и x64
После этого не несем охинею по поводу загрузчика. Если в голове остался маргарин, по поводу инициализации в загрузчике, то перечитываем еще раз. Если упоротый линуксойд, то открываем исходники любого загрузчика Linux.

В этой же книги ЧИТАЕМ про устройство ядра. Перестаем пороть чушь в встроенном HAL.
-2
  • avatar
  • a9d
  • 26 декабря 2012, 02:57
Особо укуренным людям.
Послание адресованое самому себе вы могли бы зачитать самостоятельно, даже без того, что бы постить его сюда. При желании вы могли бы сделать это вголос и с выражением.

В этой же книги ЧИТАЕМ про устройство ядра.
Вы не поверите, но операционок гораздо больше, чем версий винды. Причем они существовали задолго до ее появления. Что как бы намекает, что эта книга именно по устройству винды, а не по операционкам вообще и автоматически переносить на другие операционки все, что вы в ней вычитали, мягко говоря, не логично.
+2
Facepalm. Подрепи для начало хотя-бы одно свое слово об ОС литературой или хотя-бы статьей.
-1
Вы статью в вики прочитали достаточное количество раз?

P.S. вас бы в ru.os.cmp на недельку. знатные были бы лулзы…
0
И где там было подтверждение твоих слов?

PS Тебя бы на wasm.ru вот бы были лулзы. Много советов по системному программированию надаешь…
0
И где там было подтверждение твоих слов?
Угу. В истории появления.
PS Тебя бы на wasm.ru вот бы были лулзы
Так вот, оказывается, откуда у вас познания в том, что вы считаете «системным программированием»… Боюсь вас разочаровать, но оно не ограничивается колупанием в потрохах винды и взломом программ.
Много советов по системному программированию надаешь…
Совет научиться читать, который я вам дал, скорее общеобразовательного плана.
0
Угу. В истории появления.
И? Что их там подтвердило?

Так вот, оказывается, откуда у вас познания в том, что вы считаете «системным программированием»… Боюсь вас разочаровать, но оно не ограничивается колупанием в потрохах винды и взломом программ.

Литература. Названия в студию.
-1
И? Что их там подтвердило?
Повторяю еще раз: раздел об истории появления.
Литература. Названия в студию.
А.С. Пушкин, «Евгений Онегин». Подойдет?
0
А.С. Пушкин, «Евгений Онегин». Подойдет?
слив защитан.
0
слив защитан.
Вам — давно. А это я уже так, развлекаюсь.
0
сам дурак
-1
Эк вас распидорасило то тут
+3
Эк вас распидорасило то тут
Ага. Свалили в одну кучу микроконтроллеры, микропроцессоры, IBM PC, загрузчики, операционки, секции операционок, термины и определения, названия и понятия, программы и функции, и все прочее, тщательно все перемешали, и давай доказывать каждый свое, то обобщая несовместимое, то выдавая частности за целое…

Как дети малые. Зацепятся за любое слово, и — понеслось… Не истины для, а спора ради, да «крутость» свою показать на крупицах схваченной где — то и не всегда правильно понятой информации.

Уже давно и забыли, чего обсуждают — то. И повторяют одно и то же. Еле — еле осилил с четверть того, что написали за последние часы, потом все зациклилось и нити потерялись, и, как обычно, все свелось к классике:
«А ты кто такой ?», и — «Сам дурак !».
Сколько воду в ступе не толки — водой и останется.
И знаний не прибавит, только утопит их в шелухе.
+5
и давай доказывать каждый свое, то обобщая несовместимое, то выдавая частности за целое…
Думаю, вы сильно преувеличиваете.
0
Хорошо бы грохнуть этот оффтоп. Пост как-никак паблик, и тролям тут не место.
+1
На чат задротов похоже стало…
0
Ну вас же никто не заставлял участвовать, верно?
0
Та куда уж мне тягаться с троллями 80лвл :)
+3
Неплохо было бы допилить в движок сообщества автоматическое сворачивание веток с более чем N комментариями (N, я думаю, где-то в районе 20-50). Все срачи и холивары туда бы свалились и не мешали.
0
Неплохо бы не разводить срачи и холливары, тогда и автосворачивания не понадобится, и пользователям приятно. Как там? «Зачем плодить лишние сущности»?
Ну чую с вашими почти 10к комментов это невозможно.
+1
Неплохо бы не разводить срачи и холливары
Холивары неизбежны в условиях отсутствия единой «линии партии», поскольку являются следствием того, что все люди разные и могут иметь отличающиеся точки зрения. Карательными и воспитательными мерами можно придать холиварам более-менее цивилизованный вид, но сути это не изменит.
0
Кто бы говорил)
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.