Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
Получается ДОС=заведомо неудобная разработка и как следствие... 19.04.07 12:57 Число просмотров: 2180
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 19.04.07 13:00 Количество правок: 5
|
[moved from humor]
> Более УДОБНАЯ разработка ВСЕГДА приводит к менее
> забаженному коду при равных затратах. Это закон такой.
> Затем и использовать.
Получается ДОС=заведомо неудобная разработка и, как следствие, забаженность?
> ????
> Ты сейчас о чем? Все мэйнлайновые многозадачные ОС-и сейчас
> используют преемптивную (вытесняющую) многозадачность. Если
> какой-то процесс (все его потоки) пытается работать слишком
> должно и не уходит в wait сам - его просто вытеснит
> шедулер. Процесс ничего не может с этим поделать.
О том, если наша задача обрабатывает события и при этом (вдруг :-) кушает много ЦПУ, то если какой-то другой задачке потребуется ЦПУ, то ОС передаст ей управление, причем с еще бОльшим приоритетом, поскольку она до этого находилась в состоянии ожидания, а наша прога не вовремя ореагирует на событие. Я уж не говорю о сервисах и драйверах, которые так и наравят перебить работу непрерываемой программы.
> Большинство многозадачных ОС тоже не лохи писали :-)
> Краткая справка: если поток добровольно отдал свой квант
> времени например вызовом WaitForSingleObject (в случае
> винды), то в случае перехода ожидаемого объекта в signalled
> state управление СРАЗУ ЖЕ передается ожидавшему потоку. Не
> дожидаясь даже выхода из функции SetEvent (например). Да
> еще и с возможным priority boost-ом (приоритет несколько
> повышается). Кстати о приоритетах. Система приоритетов сама
> по себе в значительной мере решает проблему, которая тебе
> видится в многозадачных ОС, а ведь в той же винде есть еще
> и реалтаймовые потоки. Они НЕ ВЫТЕСНЯЮТСЯ. Ни один
> нереалтаймовый поток не получит управление пока хоть один
> реалтаймовый находится в состоянии ready (то есть готов к
> исполнению). И это только юзермод. В драйвере ты вообще
> можешь поставить свой обработчик прерываний на устройство и
> получать управление со скоростью с которой процессор в
> принципе может обработать это прерывание.
Помню инструкцию по разработке драйверов для RSX-11, звучало примерно так: "Не забывайте, что при обработке прерывания нельзя выполнять более N инструкций. Если этого мало, то нужно понизить приоритет обработки до X уровня (уровня устройства), чтобы дать возможность быть обработаными не менее важные прерывания. Если же в этом режиме обработка продолжается более M инструкций, то необходимо продолжить обработку в режиме отложенных прерываний".
Интересно, писатели под винды придерживаются каких-либо правил? Я заранее в это не верю.
> Ровно наоборот. В досе писать сложнее как раз таки из-за
> отсутствия нормальных средств разработки.
Кому как. Хотя дело и не в том, в чем писать, а в том, под чем работать будет.
> Ровно наоборот. Я хочу не сам отрисовывать курсор мыши и
> кнопки во фреймбуфере, а просто сказать системе, что мне
> нужна кнопка с такой то надписью и получать от системы
> сообщения о ее нажатии.
Речь идет не о пользовательских задачах, а о спецоборудовании, построеном на базе ПК, а может даже о процессе разработки такового.
> Вряд ли какое периферийное устройство обеспечит тебе такую
> точность. Разве что сядешь напрямую на процессорную шину.
Да, типовые устройства дают микросекундные точности. Наносекунды даст только прямое подключение к процессору, но на процессорную шину сесть сложно.
> А вот еще один пример (на этот раз реальный): несколько
> десятков людей переоблучились (как минимум пятеро погибло)
> из-за бага в программе обслуживающей рентген-аппарат.
> http://en.wikipedia.org/wiki/Therac_25
Осторожно надо быть с такими опасными аппаратами. А на "Першинги" PDP-11 ставили.
> Неоттестированный (плохо оттестированный) кусок софта
> гораздо опаснее, чем просто не успевающий вовремя но в 100%
> случаев (хотя и это не проблема многозадачных ОСей).
Думается, что в винде обработчик таймерного прерывания все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит достаточную погрешность так, что с ним приходится бороться.
|
|
<miscellaneous>
|
|
Народ, может пора двигать ветку в миск? Тема-то опять оказалась серьезной... 19.04.07 15:03
Автор: Fighter <Vladimir> Статус: Elderman
|
[moved from humor]
|
|
SEGV - segment violation, вероятно, то есть либо попытка... 17.04.07 10:56
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
[moved from humor]
> Снято мной во франкфуртском аэропорту.
> http://killprog.com/pics/ph3.jpg
> http://killprog.com/pics/ph2.jpg
>
> ЗЫ В недоумении. SIGSEGV и C:\MN32 - это что такое? Дос с
> чем?
SEGV - segment violation, вероятно, то есть либо попытка записи в РО сегмент, либо выход за пределы сегмента, либо вообще использование недопустимого сегмента.
MN32 - каталог с прогой, которая написана с каким-то DOS_PM_EXTENTION. Может что-то и популярное, но я не сталкивался.
Удивляться нечего. Если дома и в офисах есть потребность в новейших виндах или линуксах, то в спецсистемах вполне хватает, мало того, даже необходимо пользоваться ДОСом.
|
| |
Ага - банкомат работающий под ДОСом или Нетварью это жесть. 17.04.07 13:45
Автор: AntonK Статус: Незарегистрированный пользователь
|
[moved from humor]
|
| | |
Годы последней активной жизни (лет 10 назад( ДОС использовался в основном как загрузчик. А дальше загружалось или вин3.11 или другое многозадачное. 17.04.07 16:11
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 17.04.07 16:12 Количество правок: 1
|
[moved from humor]
|
| | | |
Я не о том. В принципе если нужно - пользуйте ДОС как... 18.04.07 17:04
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.04.07 17:06 Количество правок: 1
|
[moved from humor]
Я не о том. В принципе если нужно - пользуйте ДОС как загрузчик Вин_3.11 или Новэля_4.11. Но,
1. Если для решения задачи хватает ДОСа, то зачем использовать что-то более монстрическое.
2. Есть такие задачи, которые нельзя решить в многозадачных системах. Например главную программу может не устроить, что какая-то другая программа может использовать процессорный ресурс достаточно длительное время, тем самым главная программа на некоторое время "зависнет".
3. ДОС позволяет добиться реалтаймовости и мгновенного реагирования на события.
4. В принципе можно и без ДОСа, но тогда реализовать задачу будет чуть сложнее. Ведь в большинстве случаев, используя ДОС, задачу проше запускать (иначе через перезагрузку), задаче проще сохранять информацию в файл, задаче проще работать с вводом/выводом (экран и кнопки, например).
Вот пример: используем компьютер в качестве диагностического оборудования. Используем именно то свойство компа, что он может реагировать на электрические импульсы и с тосностью до наносекунд определять интервалы между ними, а так же накапливать эту информацию для статистической обработки, результаты которой и будут "диагнозом". Точной работе не нужна многопользовательность, а многозадачность будет только мешать. Скажу откровенно, даже в ДОСе приходится бороться с "помехами", а именно запрещать прерывания от таймера, а потом корректировать системное время.
|
| | | | |
Более удобная разработка всегда приводит к менее... 19.04.07 11:30
Автор: amirul <Serge> Статус: The Elderman
|
[moved from humor]
> 1. Если для решения задачи хватает ДОСа, то зачем
> использовать что-то более монстрическое.
Более УДОБНАЯ разработка ВСЕГДА приводит к менее забаженному коду при равных затратах. Это закон такой. Затем и использовать.
> 2. Есть такие задачи, которые нельзя решить в многозадачных
> системах. Например главную программу может не устроить, что
> какая-то другая программа может использовать процессорный
> ресурс достаточно длительное время, тем самым главная
> программа на некоторое время "зависнет".
????
Ты сейчас о чем? Все мэйнлайновые многозадачные ОС-и сейчас используют преемптивную (вытесняющую) многозадачность. Если какой-то процесс (все его потоки) пытается работать слишком должно и не уходит в wait сам - его просто вытеснит шедулер. Процесс ничего не может с этим поделать.
> 3. ДОС позволяет добиться реалтаймовости и мгновенного
> реагирования на события.
Большинство многозадачных ОС тоже не лохи писали :-)
Краткая справка: если поток добровольно отдал свой квант времени например вызовом WaitForSingleObject (в случае винды), то в случае перехода ожидаемого объекта в signalled state управление СРАЗУ ЖЕ передается ожидавшему потоку. Не дожидаясь даже выхода из функции SetEvent (например). Да еще и с возможным priority boost-ом (приоритет несколько повышается). Кстати о приоритетах. Система приоритетов сама по себе в значительной мере решает проблему, которая тебе видится в многозадачных ОС, а ведь в той же винде есть еще и реалтаймовые потоки. Они НЕ ВЫТЕСНЯЮТСЯ. Ни один нереалтаймовый поток не получит управление пока хоть один реалтаймовый находится в состоянии ready (то есть готов к исполнению). И это только юзермод. В драйвере ты вообще можешь поставить свой обработчик прерываний на устройство и получать управление со скоростью с которой процессор в принципе может обработать это прерывание.
> 4. В принципе можно и без ДОСа, но тогда реализовать задачу
> будет чуть сложнее. Ведь в большинстве случаев, используя
Ровно наоборот. В досе писать сложнее как раз таки из-за отсутствия нормальных средств разработки.
> ДОС, задачу проше запускать (иначе через перезагрузку),
> задаче проще сохранять информацию в файл, задаче проще
> работать с вводом/выводом (экран и кнопки, например).
Ровно наоборот. Я хочу не сам отрисовывать курсор мыши и кнопки во фреймбуфере, а просто сказать системе, что мне нужна кнопка с такой то надписью и получать от системы сообщения о ее нажатии.
> Вот пример: используем компьютер в качестве
> диагностического оборудования. Используем именно то
> свойство компа, что он может реагировать на электрические
> импульсы и с тосностью до наносекунд определять интервалы
Вряд ли какое периферийное устройство обеспечит тебе такую точность. Разве что сядешь напрямую на процессорную шину.
> между ними, а так же накапливать эту информацию для
> статистической обработки, результаты которой и будут
> "диагнозом". Точной работе не нужна многопользовательность,
> а многозадачность будет только мешать. Скажу откровенно,
> даже в ДОСе приходится бороться с "помехами", а именно
> запрещать прерывания от таймера, а потом корректировать
> системное время.
А вот еще один пример (на этот раз реальный): несколько десятков людей переоблучились (как минимум пятеро погибло) из-за бага в программе обслуживающей рентген-аппарат.
http://en.wikipedia.org/wiki/Therac_25
Неоттестированный (плохо оттестированный) кусок софта гораздо опаснее, чем просто не успевающий вовремя но в 100% случаев (хотя и это не проблема многозадачных ОСей).
|
| | | | | |
Получается ДОС=заведомо неудобная разработка и как следствие... 19.04.07 12:57
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 19.04.07 13:00 Количество правок: 5
|
[moved from humor]
> Более УДОБНАЯ разработка ВСЕГДА приводит к менее
> забаженному коду при равных затратах. Это закон такой.
> Затем и использовать.
Получается ДОС=заведомо неудобная разработка и, как следствие, забаженность?
> ????
> Ты сейчас о чем? Все мэйнлайновые многозадачные ОС-и сейчас
> используют преемптивную (вытесняющую) многозадачность. Если
> какой-то процесс (все его потоки) пытается работать слишком
> должно и не уходит в wait сам - его просто вытеснит
> шедулер. Процесс ничего не может с этим поделать.
О том, если наша задача обрабатывает события и при этом (вдруг :-) кушает много ЦПУ, то если какой-то другой задачке потребуется ЦПУ, то ОС передаст ей управление, причем с еще бОльшим приоритетом, поскольку она до этого находилась в состоянии ожидания, а наша прога не вовремя ореагирует на событие. Я уж не говорю о сервисах и драйверах, которые так и наравят перебить работу непрерываемой программы.
> Большинство многозадачных ОС тоже не лохи писали :-)
> Краткая справка: если поток добровольно отдал свой квант
> времени например вызовом WaitForSingleObject (в случае
> винды), то в случае перехода ожидаемого объекта в signalled
> state управление СРАЗУ ЖЕ передается ожидавшему потоку. Не
> дожидаясь даже выхода из функции SetEvent (например). Да
> еще и с возможным priority boost-ом (приоритет несколько
> повышается). Кстати о приоритетах. Система приоритетов сама
> по себе в значительной мере решает проблему, которая тебе
> видится в многозадачных ОС, а ведь в той же винде есть еще
> и реалтаймовые потоки. Они НЕ ВЫТЕСНЯЮТСЯ. Ни один
> нереалтаймовый поток не получит управление пока хоть один
> реалтаймовый находится в состоянии ready (то есть готов к
> исполнению). И это только юзермод. В драйвере ты вообще
> можешь поставить свой обработчик прерываний на устройство и
> получать управление со скоростью с которой процессор в
> принципе может обработать это прерывание.
Помню инструкцию по разработке драйверов для RSX-11, звучало примерно так: "Не забывайте, что при обработке прерывания нельзя выполнять более N инструкций. Если этого мало, то нужно понизить приоритет обработки до X уровня (уровня устройства), чтобы дать возможность быть обработаными не менее важные прерывания. Если же в этом режиме обработка продолжается более M инструкций, то необходимо продолжить обработку в режиме отложенных прерываний".
Интересно, писатели под винды придерживаются каких-либо правил? Я заранее в это не верю.
> Ровно наоборот. В досе писать сложнее как раз таки из-за
> отсутствия нормальных средств разработки.
Кому как. Хотя дело и не в том, в чем писать, а в том, под чем работать будет.
> Ровно наоборот. Я хочу не сам отрисовывать курсор мыши и
> кнопки во фреймбуфере, а просто сказать системе, что мне
> нужна кнопка с такой то надписью и получать от системы
> сообщения о ее нажатии.
Речь идет не о пользовательских задачах, а о спецоборудовании, построеном на базе ПК, а может даже о процессе разработки такового.
> Вряд ли какое периферийное устройство обеспечит тебе такую
> точность. Разве что сядешь напрямую на процессорную шину.
Да, типовые устройства дают микросекундные точности. Наносекунды даст только прямое подключение к процессору, но на процессорную шину сесть сложно.
> А вот еще один пример (на этот раз реальный): несколько
> десятков людей переоблучились (как минимум пятеро погибло)
> из-за бага в программе обслуживающей рентген-аппарат.
> http://en.wikipedia.org/wiki/Therac_25
Осторожно надо быть с такими опасными аппаратами. А на "Першинги" PDP-11 ставили.
> Неоттестированный (плохо оттестированный) кусок софта
> гораздо опаснее, чем просто не успевающий вовремя но в 100%
> случаев (хотя и это не проблема многозадачных ОСей).
Думается, что в винде обработчик таймерного прерывания все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит достаточную погрешность так, что с ним приходится бороться.
|
| | | | | | |
Всё нормально получается при грамотном подходе. 19.04.07 14:08
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 20.04.07 11:08 Количество правок: 1
|
[moved from humor]
> Помню инструкцию по разработке драйверов для RSX-11,
> звучало примерно так: "Не забывайте, что при обработке
> прерывания нельзя выполнять более N инструкций. Если этого
> мало, то нужно понизить приоритет обработки до X уровня
> (уровня устройства), чтобы дать возможность быть
> обработаными не менее важные прерывания. Если же в этом
> режиме обработка продолжается более M инструкций, то
> необходимо продолжить обработку в режиме отложенных
> прерываний".
> Интересно, писатели под винды придерживаются каких-либо
> правил? Я заранее в это не верю.
Придерживаются... В ядре несколько уровней, в котором работает драйвер... И вот, во время обработки прерывания много "виндовозного" там недоступно и сразу приводит к синему экрану... Поэтому хочешь-нехочешь быстро обрабатываешь там прерывание, чтобы отпустить устройство, и отдаёшь полученный низкоуровненвый кусок информации от устройства своему же обработчику, и он уже с ним возюкается не вредя особо другим -))
> Думается, что в винде обработчик таймерного прерывания
> все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит
> достаточную погрешность так, что с ним приходится бороться.
А вот и не надо бороться с вендой, пусть она своими делами занимается, а ты своими. Все хотят какого-то магического контроля и всеведения, хотя это всё иллюзия. Оно красиво конечно... сперва. До ухода из конторы основного разработчика, к примеру -)
|
| | | | | | | |
Разработчиков обычного пользовательского софта значительно... 19.04.07 14:28
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
[moved from humor]
> А вот и не надо бороться с вендой, пусть она своими делами
> занимается, а ты своими. Все хотят какого-то магического
Разработчиков обычного пользовательского софта значительно больше, чем спецнаправленных.
Пусть разработчики баз данных, бухгалтерских программ, игрушек и прочего пишут под винды.
> контроля и всеведения, хотя это всё иллюзия. Оно красиво
> конечно... сперва. До ухода из конторы основного
> разработчика, к примеру -)
Ну не всегда же винда существовала. Работали раньше и под ДОСом. И разработчики уходили, так же как и сейчас. И было это таким же ударом, как и сейчас.
|
| | | | | | | | |
Сейчас изменились векторы разработки. Не как ранее, предложение формировало спрос (бизнесу надо было выбирать из худшего наименнее худшее),... 19.04.07 14:54
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 19.04.07 15:25 Количество правок: 1
|
[moved from humor]
...а разработчики ПО подстраиваются под требования бизнеса.
И появляются и развиваются ITSM, BSM и прочая.
Поддержка сервисов дорогого стоит. Зачастую проще отказаться от негибкого, не подстраиваемого под требования, а иногда тормозящего решения, чем его поддерживать.
Ныненшние тенденции - установка конструктора и кастомизация под специфику бизнеса заказчика.
Заказное ПО как бизнес сервисы или приложения сейчас не актуальны.
Бизнес хочет сейчас не только удовлетворение своих потребностей (анализ требований), но и внедрение бестпрактикс бизнес процессов (управление требованиями), а тут заказники не сильны, тк они реализуют "узкий" практикс, а он по дефолту не оптимален. Мало кто хочет, что бы на его основе откатывались решения, все хотят получить уже готовые оптимальные решения. Разве что госсектор не высокого уровня, банки (не западные), учитывая низкую стоимость ресурсов, могут себе позволить "эксперименты":)
Применение человекозависимой разработки при разработке серийной автоматики также не оптимально. Коллективная работа позволяет сократить разработку и использовать библиотеки (повторное использование модулей) и модули сторонней разработки (в тч и коммерческие). Причем практически неограничено расширять штат разработки и удаленную разработку.
Пример ПЛМ- программируемые логические матрицы. Куда можно заливать практически любой функционал (отлаженый на эмуляторах и стендах) базовых инструментов автоматизации. Сетевые интерфейсы, клиенты СУБД, АЦП,ЦАП, кодинг/декодинг и тд).
ДОС (как дисковая ОС) не умер. Ее части юзаются в бюджетных МП3 плеерах и мобилках. Там же базовый ФАТ12 втречается:)
ЗЫ: во какая умная аналитика в раздел юмор попала:)
|
| | | | | | |
Да. Можно сформулировать по другому: для достижения... 19.04.07 13:21
Автор: amirul <Serge> Статус: The Elderman
|
[moved from humor]
> Получается ДОС=заведомо неудобная разработка и как
> следствие забаженость?
Да. Можно сформулировать по другому: для достижения одинакового уровня забаженности на менее удобном интрументарии придется затратить больше ресурсов (в том числе и временнЫх), чем на более удобном.
> О том, если наша задача обрабатывает события и при это
> (вдруг :-) кушает много ЦПУ, то если какой-то другой
> задачке потребуется ЦПУ, то ОС передаст ей управление,
> причем с еще бОльшим приоритетом, поскольку она до этого
Ага. А вот теперь нам поведают о том как подобные проблемы (необходимость одновременной обработки двух разных событий) с легкостью решаются в ДОС-е :-)
> находилась в состоянии ожидания, а наша прога не вовремя
> ореагирует на событие. Я уж не говорю о сервисах и
> драйверах, которые так и наравят перебить работу
> непрерываемой программы.
Никто не норовит. Сервисы - являются обычными процессами. А драйверы вообще не ни при чем. Единицей исполнения является поток. Драйвер конечно может создать рабочий поток, но это будет такой же поток как и все остальные потоки в системе: со своим приоритетом и возможностью вытеснить.
> Помню инструкцию по разработке драйверов для RSX-11,
> звучало примерно так: "Не забывайте, что при обработке
> прерывания нельзя ваполнять более N инструкций. Если этого
> мало, то нужно понизить приоритет обработки до X уровня
> (уровня устройства), чтобы дать возможность быть
> обработаными не менее важные прерывания. Если же в это
> режиме обработка продолжается более M инструкций, то
> необходимо продолжить обработку в режиме отложенных
> прерываний".
> Интересно, писатели под винды придерживаются каких-либо
> правил? Я заранее в это не верю.
Зря не веришь. Есть рекомендация не задерживаться в обработчике прерывания больше N микросекунд. Всю остальную работу производить в DPC (deferred procedure call). Как раз именно потому, что прерывания от девайсов маскируют прерывания с более низким IRQL. Надо вычитать всю неотложную информацию из портов и поставить DPC - дальше вся работа будет производиться на DISPATCH_LEVEL-е.
"Because ISRs must execute as quickly as possible, drivers must usually postpone the completion of servicing an interrupt until after the ISR returns. Therefore, the system provides support for deferred procedure calls (DPCs), which can be queued from ISRs and which are executed at a later time and a lower IRQL than the ISR."
> Кому как. Хотя дело и не в том, в чем писать, а в том, под
> чем работать будет.
Дело именно в средствах разработки. Писать под винду во многом даже проще, чем под дос (например, работа с памятью)
> Речь идет не о пользовательских задачах, а о
> спецоборудовании, построеном на базе ПК, а может даже о
> процессе разработки такового.
Не вижу проблем для общения со спецоборудованием.
> Думается, что в винде обработчик таймерного прерывания
> все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит
> достаточную погрешность так, что с ним приходится бороться.
Прикол в том, что даже если это и скажется на работе, оно скажется сразу же - при первом же тестировании. А вот другие (неявные) проблемы (которые могут быть и при досовой и при "многозадачной" разработке) лечге тестить и отлавливать при наличии хороших средств разработки.
|
| | | | | | | |
Пора подвести итог: 19.04.07 14:20
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
[moved from humor]
> Да. Можно сформулировать по другому: для достижения
> одинакового уровня забаженности на менее удобном
> интрументарии придется затратить больше ресурсов (в том
> числе и временнЫх), чем на более удобном.
Пора подвести итог:
Одно следствие не вытекает из другого, они имеют совершенно разную тематику. Баги не считал, но мне удобнее разрабатывать под ДОСом. Считаю, что забаженность может зависеть от удобства в значительно меньшей степени, чем от самого программиста.
> Ага. А вот теперь нам поведают о том как подобные проблемы
> (необходимость одновременной обработки двух разных событий)
> с легкостью решаются в ДОС-е :-)
С удовольствием поведаю о том, что под ДОСом можно запретить все прерывания, при необходимости разрешив только те, что нужно.
Ага. А вот теперь нам поведают, что под виндой удобно запретить таймерные прерывания.
> Зря не веришь. Есть рекомендация не задерживаться в
Очень рад за винду, что есть такая рекомендация. А не верю в то, что все ее придерживаются.
> Дело именно в средствах разработки. Писать под винду во
> многом даже проще, чем под дос (например, работа с памятью)
Что-то я в библиотечке не нашел функцию coreleft().
> Не вижу проблем для общения со спецоборудованием.
Неужели кому-то в голову придет мысть о том, чтоб поставить винду на крылатые ракеты.
|
| | | | | | | | |
Нет, я еще расскажу о реалтаймовых потоках и о том, что не... 19.04.07 14:50
Автор: amirul <Serge> Статус: The Elderman
|
[moved from humor]
> С удовольствием поведаю о том, что под ДОСом можно
> запретить все прерывания, при необходимости разрешив только
> те, что нужно.
> Ага. А вот теперь нам поведают, что под виндой удобно
> запретить таймерные прерывания.
Нет, я еще расскажу о реалтаймовых потоках и о том, что не стоит ставить на критичные системы всякое third party говно.
> > Зря не веришь. Есть рекомендация не задерживаться в
> Очень рад за винду, что есть такая рекомендация. А не верю
> в то, что все ее придерживаются.
Но это не проблема винды. Не ставь дрова таких производителей и все.
> > Дело именно в средствах разработки. Писать под винду
> во
> > многом даже проще, чем под дос (например, работа с
> памятью)
> Что-то я в библиотечке не нашел функцию coreleft().
Не понял.
> > Не вижу проблем для общения со спецоборудованием.
> Неужели кому-то в голову придет мысть о том, чтоб поставить
> винду на крылатые ракеты.
Вряд ли (хотя проблем все равно не вижу). Но и доса там даже рядом не будет.
|
| | | | | | | | | |
Если посмотреть на винду средней степени загажености, то... 20.04.07 15:47
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 20.04.07 15:47 Количество правок: 1
|
> Нет, я еще расскажу о реалтаймовых потоках и о том, что не
> стоит ставить на критичные системы всякое third party
> говно.
Если посмотреть на винду средней степени загажености, то исконно микрософтовые продукты будут составлять всего какий-то процент. Если только железо взять, то сколько различных фирм-производителей. Драйвер к каждому написать надо и к продаваемому устройству приложть. Я уж не знаю, кто может озадачить этим "не third party" программистов, а именно микрософтовских.
> Но это не проблема винды. Не ставь дрова таких
> производителей и все.
А девайсы для красоты покупать.
> > > Дело именно в средствах разработки. Писать под
> винду
> > во
> > > многом даже проще, чем под дос (например, работа
> с
> > памятью)
> > Что-то я в библиотечке не нашел функцию coreleft().
>
> Не понял.
Это к тезису о том, что писать под винды во многом проще, чем под ДОС (например работа с памятью)
Так вот в VC 8 ("Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x8") не обнаружена полезная стандартная по Ричи и Кернигану, АНСИ и Стаустрапу функция coreleft(). malloc() есть, free() есть, другие есть кроме этой.
|
| | | | | | | | | | |
А зачем ставить вендорские скажем дрова на видеокарту?... 20.04.07 16:34
Автор: amirul <Serge> Статус: The Elderman
|
> Если посмотреть на винду средней степени загажености, то
> исконно микрософтовые продукты будут составлять всего
> какий-то процент. Если только железо взять, то сколько
А зачем ставить вендорские скажем дрова на видеокарту? Дженериковые отлично справятся. Большая часть остального железа тоже нормально работает на чисто майкрософтовских дровах (хотя чаще всего и со сниженным performance-ом). Но мы ж компьютер ставим не для того чтобы в сталкера на максимальных настройках на нем резаться.
> > Но это не проблема винды. Не ставь дрова таких
> > производителей и все.
> А девайсы для красоты покупать.
В описанном тобой случае - да. Ну не нужна критичной системе крутая видюха и HD Audio 5.1
> Это к тезису о том, что писать под винды во многом проще,
> чем под ДОС (например работа с памятью)
Я ведь даже не о выделении/освобождении (в общем то stdlib есть всегда и это его проблемы). Я о сегментации памяти и как следствие невозможности иметь объекты больше 64 килобайт.
> Так вот в VC 8 ("Microsoft (R) 32-bit C/C++ Optimizing
> Compiler Version 14.00.50727.42 for 80x8") не обнаружена
> полезная стандартная по Ричи и Кернигану, АНСИ и Стаустрапу
> функция coreleft(). malloc() есть, free() есть, другие есть
> кроме этой.
Не обманывай. coreleft никогда не была СТАНДАРТНОЙ (по крайней мере в ANSI станарте) функцией библиотеки C. То что borland ее тулит в качестве расшрения - проблемы борланда, а не стандарта. У майкрософта тоже куча расширений, но мне и в голову не придет обвинять разработчиков какого нибудь другого компилятора в том, что они не поддерживают MSVC-шные экстеншены.
|
| | | | | | | | | | | |
Для ebedded win драйвера не ставятся, а интегрируются в образ. А поддержка железа - именно задача разрабочиков железа. грубо говоря это поддержка хардваре зависимых интерфейсов, а это не задача ОС. 23.04.07 15:43
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | | | | | | | |
Кроме видеокарты есть еще много других устройств. Если для... 23.04.07 15:24
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> А зачем ставить вендорские скажем дрова на видеокарту?
Кроме видеокарты есть еще много других устройств. Если для таких устройств, как видеокарта, СиДиРом, модем, таймер, ПКП, ПДП, и подобных действительно можно и не думать о других драйверах, кроме как микрософтовских, то для таких устройств как принтеры, сканеры, подавляющее количество УСБ устройств (кроме мышки и флешдиска) а именно фотокамеры, мобильники, УСБ сетевые адаптеры, УСБ2СОМ преобразователи, УСБ модемы, УСБ саундбластеры, не только УСБ ВайФай, БлюТуф, и прочие. А если купили свеженький сервак, то к дисковому контроллеру точно дрова от производителя потребуются.
> В описанном тобой случае - да. Ну не нужна критичной
> системе крутая видюха и HD Audio 5.1
Если мы вообще об микрософтовских дровах, то читаем выше, а если о критичных системах, то там как раз наличие экзотического устройства о котором микрософтовские драйверописатели и не слышали наиболее вероятно.
> Я ведь даже не о выделении/освобождении (в общем то stdlib
> есть всегда и это его проблемы). Я о сегментации памяти и
> как следствие невозможности иметь объекты больше 64
> килобайт.
Сегментация там совсем другая, 16 байтная, да и то это не проблема ДОСа, а интеловской архитектуры. И объекты можно заводить более 64К, используя 20 разрядную адресацию. А если воспользоваться любым из множества расширителей до 32 разрядности, то спокойно можно работать с объектами любого размера.
> Не обманывай. coreleft никогда не была СТАНДАРТНОЙ (по
Ну ладно, разогнался я. Хотя функция была бы довольно полезна.
|
| | | | | | | | | | | | |
Вот и возюкайся со всем этим хозяйством из-под ДОСа (updated) 23.04.07 15:34
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 23.04.07 15:46 Количество правок: 1
|
> Кроме видеокарты есть еще много других устройств. Если для
> таких устройств, как видеокарта, СиДиРом, модем, таймер,
> ПКП, ПДП, и подобных действительно можно и не думать о
> других драйверах, кроме как микрософтовских, то для таких
> устройств как принтеры, сканеры, подавляющее количество УСБ
> устройств (кроме мышки и флешдиска) а именно фотокамеры,
> мобильники, УСБ сетевые адаптеры, УСБ2СОМ преобразователи,
> УСБ модемы, УСБ саундбластеры, не только УСБ ВайФай,
> БлюТуф, и прочие. А если купили свеженький сервак, то к
> дисковому контроллеру точно дрова от производителя
> потребуются.
Вот и возюкайся со всем этим хозяйством из-под ДОСа ;-)))))))))
Слава богам, в своё время я её знал, и сейчас ещё могут поковырять автоэкзеки с конфигсисами, ну программировать там не пришлось :-)
А о сложном досковом софте, действительно сложном, к примеру тот же СупермагУКМ, это такая хрень, ставится на торговые терминалы, которые стоят хренову тучу бабок только из-за того, что для барыг, а на самом деле обычный писюк ящиком для денег, фискальной платой и чековым принтером... Разработчики его сами наверное прокляли тот день, когда разработали его для ДОС, а не для нормальной оси... Такой костыль на костыле и костылём погоняет... И нету дня, чтобы в крупном магазине что-нибудь с ними не происходило...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
