Нет не даю зуб, уверен, что попортить может. Например можешь сделать свой софт и им полезть в мой софт изменить в нём исполняемый код и тогда мой софт сразу начнёт уменьшать количество моих зубов.
И да, я практически всегда пишу себе софт, практически на все случаи жизни, потому что я постоянно сталкиваюсь с вопросами которые не решаются сторонним софтом. Именно поэтому у меня есть всякие ASAM'ы, MASON'ны, PINTELIN'ы, пакеры, линковщики, конвертеры и куча-куча всякой шняги. Кто делал со мной проекты всё это видел. Я маньяк на тему того, что график должен рисовать свои работы в том, что ему нравится, а моя задача написать конвертер из его удобства в свои потребности. Единственное, что я заставлял Олега писать музыку в MASON'е, по скольку реально нужна высокая скорость и малая память, а рт3 не даёт мне этого. Так что да, я на все случаи жизни делаю себе софт, если бы люди работающие на том же компьютере что и я не пользовались софтом требующим минимум ХР, я бы так и не слазил с 98-ой, мне от винды требуется только попасть в свой софт, дальше плевать что там на заднем плане.
Конечно я мой софт может глючить, и глючит, но не так что бы случилась катастрофа, а глюк будет лишь поводом исправить ошибку. Но при написании софта я потрачу максимальное количество времени, что бы ошибки свести к нулю.
Да, мы слишком извращены и везде видим сарказм и подколки. А минусы оставлю на совести их авторов. В отличие от тебя и Робуса, у них не хватило пороху высказать свое мнение словами и разрешить увиденную двусмысленность.
Отвечу наводящими вопросами.
Ты лично пишешь весь софт, которым пользуешься? Что ты предпочитаешь увидеть- окошко о недопустимой операции в каком-то приложении или зависший/сбросившийся компьютер? А дашь зуб, что твой софт не является «дурным» и не портит память ни при каких условиях?
Так прозвучало, причём не только с моей точки зрения — думаю, за это тебе и понаставили минусов.
Забей короче, спорить не о чем, скриншот у тебя клёвый. Я тоже болел в 1990е окнами, но у меня всё же не до того было всё запущено :)
Елки-палки… Да где ты там увидел разочарование? Да, я потратил тогда довольно много времени на кодинг всех этих макетов (их было несколько, на картинке самый эффектно выглядящий), потратил много времени на чтение книг по ОСям, но жалеть об этом не собираюсь. Это все знания, полезный опыт, в конце концов (в самом прямом смысле, мы в универе на лабах реализовывали многозадачность под досом на таймере, после экспериментов на спеке это было сделать- раз плюнуть, приобщение к миру Linux опять же).
Robus сделал свой вариант потому что у него возникла такая задача и он ее прекрасно решил. У меня ее (задачи) не было (ну не пишу я демы, извините), а встраивать многопоточность в прикладное ПО по принципу «чтоб было» — это довольно глупо.
Но ты же отлаживаешь свой код? Ведь не первый день кодишь. Понятно, что дурак может завалить систему, но почему это должно быть поводом везде, всегда и повсеместно идти только путём нагромождённых моделей с MMU? Отладил ПО… Работает отлично… И забыл… Вот в данный момент этот текст набивается под виндой, где у ядра есть MMU и это кому-то помогает? Ну увижу я на экране «приложение Васи Пупкина выполнило не допустимую операцию», что это сделает приложение лучше работающим? Нет. И если приложение выполнит недопустимую операцию лазя по API процедурам, и завалит соседние приложения, то от этого мне так же не будет никакого счастья, результат будет один — «дурак победил дурака и попортил данные». Конечно можно запретить любые манипуляции, но я же не секретарша набивающая текст регламента в ворде, мне нужен компьютер как инструмент на 100%, и мне всё равно есть ли в системе MMU, мне главное что бы качественно работало. А софт, которые «дурной», и портящий память, я просто не буду ставить.
Вот понимаешь, я смотрю на твою картинку и думаю про себя, что есть 2 типа кодеров. Даже не типа кодеров, а типа кодерского мышления, так что каждый кодер будет знаком с обоими способами думать.
Тип 1: делать код, «чтобы было». Вот прочитывается где-то описание многозадачности или просто интересно поиграть в большие машины — и пишется вот такая программа как у тебя на скриншоте. Это всё замечательно, но конечно у больших машин огромный запас вычислительной мощности + архитектура, которая вообще говоря была продумана для такого использования. И выясняется, что DI делать нельзя, что память не защищена, что машина не приспособлена. И получается какое-то разочарование, вроде прозвучавшего в твоём первом комментарии.
Тип 2: делать код для решения конкретных задач. В старых демах было обычным делом сделать декранч или распаковку с бегущей строкой или просто на чёрном экране. Реализовав двухпоточность, оказывается можно делать дему почти без швов или даже совсем без швов. Конечно, все ограничения выше остаются в силе. Ты забыл ещё упомянуть координацию потоков, чтобы данные одного потока поступали в другой без разнообразных конфликтов. Тем не менее, на выходе мы получаем то, что раньше делать не выходило.
По сути выходит, что в первом случае у тебя стакан наполовину пост, а во втором — наполовину полон.
Данный пример генерирует в 8 страницах (максимум в зависимости от карты и количества написанных объектов) код для каждого объекта игры. Этих объектов от 0 до 127, каждый может иметь логику работы, в зависимости от того, что было придумано при рисовании карты в конкретном уровне. В одном уровне объект номер 3 может быть камнем, а в втором может быть водой, какую графику подставят, и какой напишут код, то и ляжет в страницы. Далее при обработке карты на каждый объект исполняется написанная автором код. Движок игры не знает что это за объект, как его опишут такое и будет поведение.
Всё ООП не более чем описание правил в зависимости от данных, будет правило, что пришедшие данные это код, будет исполняться, просто ссылки в памяти на ссылки в другую память и обвязка тонной «ифов», а не ноль-ли там. Ну правда можно менеджером памяти пользоваться, пытаясь поймать exception'ы, ну тогда это ещё хуже «ифов», ибо скорость ПО резко снижается в разы.
В примере EXE_MAP_ADD_ALL_GROUP и занимается генерацией кодовых блоков в зависимости от данных в карте. Кодовые блоки лежат в таблице PROC_GROUP_TBL, которая генерируется автором уровня, и подгружается с носителя.
Все зависит от задачи. И за все надо платить. За наличие софта- универсальностью инструмента (стандартная ОС против узкоспециализированного ядра). За универсальность — скоростью работы и необходимостью защиты.
А вот если рассматривать «защиту системы от дурака» как право на ошибку (а человек, как известно, к ним весьма склонен), то акцент несколько смещается. И точно такой же сторонник сугубо практического применения может тебе сказать «я не хочу забивать себе голову дурацкими правилами работы с системой, я хочу просто решать задачу».
Это не дисковая утилита. Это я давным-давно увлекался темой многозадачных ОСей, в частности на спеке. Но подхватил вирус мышедрочерства графического интерфейса:)
На скриншоте честно-многозадачно работающие системный монитор, консоль, карта памяти и мегатормозной просмотрщик текста.
Вот она, истина! Точно так, ибо сложных программ не существует. И с самого начала я написал — «Thread'ы очень просты».
На АРМе я вообще не буду использовать модель MMU, не вижу в ней смысла. Меня вообще не интересует путь, где нужно защищаться от того, что автор ПО будет лезть в левые адреса, и простого переключения задач хватит на все случаи жизни. От АРМа мне нужна «молотилка данных», ну или ещё более мне важна обвязка ядра, для практического применения в разработках.
Спасибо, что делишься своими наработками.
И да, я практически всегда пишу себе софт, практически на все случаи жизни, потому что я постоянно сталкиваюсь с вопросами которые не решаются сторонним софтом. Именно поэтому у меня есть всякие ASAM'ы, MASON'ны, PINTELIN'ы, пакеры, линковщики, конвертеры и куча-куча всякой шняги. Кто делал со мной проекты всё это видел. Я маньяк на тему того, что график должен рисовать свои работы в том, что ему нравится, а моя задача написать конвертер из его удобства в свои потребности. Единственное, что я заставлял Олега писать музыку в MASON'е, по скольку реально нужна высокая скорость и малая память, а рт3 не даёт мне этого. Так что да, я на все случаи жизни делаю себе софт, если бы люди работающие на том же компьютере что и я не пользовались софтом требующим минимум ХР, я бы так и не слазил с 98-ой, мне от винды требуется только попасть в свой софт, дальше плевать что там на заднем плане.
Конечно я мой софт может глючить, и глючит, но не так что бы случилась катастрофа, а глюк будет лишь поводом исправить ошибку. Но при написании софта я потрачу максимальное количество времени, что бы ошибки свести к нулю.
Ты лично пишешь весь софт, которым пользуешься? Что ты предпочитаешь увидеть- окошко о недопустимой операции в каком-то приложении или зависший/сбросившийся компьютер? А дашь зуб, что твой софт не является «дурным» и не портит память ни при каких условиях?
Забей короче, спорить не о чем, скриншот у тебя клёвый. Я тоже болел в 1990е окнами, но у меня всё же не до того было всё запущено :)
Robus сделал свой вариант потому что у него возникла такая задача и он ее прекрасно решил. У меня ее (задачи) не было (ну не пишу я демы, извините), а встраивать многопоточность в прикладное ПО по принципу «чтоб было» — это довольно глупо.
Тип 1: делать код, «чтобы было». Вот прочитывается где-то описание многозадачности или просто интересно поиграть в большие машины — и пишется вот такая программа как у тебя на скриншоте. Это всё замечательно, но конечно у больших машин огромный запас вычислительной мощности + архитектура, которая вообще говоря была продумана для такого использования. И выясняется, что DI делать нельзя, что память не защищена, что машина не приспособлена. И получается какое-то разочарование, вроде прозвучавшего в твоём первом комментарии.
Тип 2: делать код для решения конкретных задач. В старых демах было обычным делом сделать декранч или распаковку с бегущей строкой или просто на чёрном экране. Реализовав двухпоточность, оказывается можно делать дему почти без швов или даже совсем без швов. Конечно, все ограничения выше остаются в силе. Ты забыл ещё упомянуть координацию потоков, чтобы данные одного потока поступали в другой без разнообразных конфликтов. Тем не менее, на выходе мы получаем то, что раньше делать не выходило.
По сути выходит, что в первом случае у тебя стакан наполовину пост, а во втором — наполовину полон.
Всё ООП не более чем описание правил в зависимости от данных, будет правило, что пришедшие данные это код, будет исполняться, просто ссылки в памяти на ссылки в другую память и обвязка тонной «ифов», а не ноль-ли там. Ну правда можно менеджером памяти пользоваться, пытаясь поймать exception'ы, ну тогда это ещё хуже «ифов», ибо скорость ПО резко снижается в разы.
В примере EXE_MAP_ADD_ALL_GROUP и занимается генерацией кодовых блоков в зависимости от данных в карте. Кодовые блоки лежат в таблице PROC_GROUP_TBL, которая генерируется автором уровня, и подгружается с носителя.
А вот если рассматривать «защиту системы от дурака» как право на ошибку (а человек, как известно, к ним весьма склонен), то акцент несколько смещается. И точно такой же сторонник сугубо практического применения может тебе сказать «я не хочу забивать себе голову дурацкими правилами работы с системой, я хочу просто решать задачу».
мышедрочерстваграфического интерфейса:)На скриншоте честно-многозадачно работающие системный монитор, консоль, карта памяти и мегатормозной просмотрщик текста.
На АРМе я вообще не буду использовать модель MMU, не вижу в ней смысла. Меня вообще не интересует путь, где нужно защищаться от того, что автор ПО будет лезть в левые адреса, и простого переключения задач хватит на все случаи жизни. От АРМа мне нужна «молотилка данных», ну или ещё более мне важна обвязка ядра, для практического применения в разработках.
Спасибо, что делишься своими наработками.
«Не надо искать в моем комментарии цинизм, сарказм или еще какой негатив»
:))
а так — реально даже часть операционки, чем кусок демо.
Это средство обеспечения надежности системы, в частности многозадачной.
Ваш адмирал Ясен Хуй.