В тех статьях обсуждался вариант получения водорода из воды в объеме, необходимом для движения автомобиля. Таким образом, снимались проблемы и хранения и безопасности. И нет необходимости переводить водород в жидкое состояние.
Не совсем понял Ваше замечание про КПД. Если речь про получение водорода, то, я так понимаю, там главный вопрос больше в цене катализаторов для обеспечения энергоэффективного процесса. А если, про КПД двигателя, то можно вспомнить, что температура сгорания водорода в 3 раза выше бензина.
То есть, техническое решение существует где-то рядом.
«Если звезды НЕ зажигают — значит — это кому-нибудь нужно?» !(Маяковский)
Куча народа даже не помнит.
Отечественный автопром перестал заниматься водородными двигателями в прошлом веке: Водородный двигатель в СССР
В 70-х годах авторы статей популярных технических журналов намекали, что скоро будем заправляться водой из придорожной канавы.
Но, до сих пор не удается отъехать от бензоколонки на расстояние больше емкости бензобака.
Может, это действительно «невыгодные изобретения»…
Отчего же, я признаю свою ошибку молодости.
Разумеется глупо было рассматривать Event Control Block (ECB) какого-то сетевого драйвера в качестве Process Control Block (PCB) настоящей многозадачной ОС. Это меня не оправдывает, но это Novell спровоцировал меня.
Они реализовали в своем драйвере asynchronous event scheduler (AES) и достаточный набор функций для планирования и исполнения всяких routine.
Да, я не должен был указывать адрес процедуры своей резидентной программы (TSR) в структуре AESECB в поле
AESESR
This field specifies a routine that is to be invoked when the specified time has expired.
This field must point to a valid routine and only needs to be initialized once.
The ESR must complete quickly because it is executing in the context of a timer interrupt.
The ESR can reschedule itself after it resets the MSecondValue, thus creating a simple polling function.
И, да, это было ошибкой передать такую структуру в функцию драйвера ScheduleAESEvent, чтобы вовлечь в мой корыстный процесс таймер и никаким образом не использовать контролеры прерывания и прямого доступа к памяти. И, тем более, использовать сетевой драйвер не по назначению это вообще преступление. Каюсь!
Если бы мне был доступен документ "Novell ODI Specification: NetWare 16-Bit DOS Protocol Stacks and MLIDs", то я, возможно, не сделал бы такой грязный хак.
Хотя, тогда я осознанно выбрал это решение и не стал писать свой планировщик задач.
Так что меня можно судить по всей строгости ;-)
Согласен, в некоторых организациях может быть именно так, как Вы описали. Но, может быть чуть иначе:
1. Ответственность за качество продукта несет руководство компании. (см. семейство стандартов ISO 9000 — толковые документы, если используются не только для формальной сертификации компании и получения золотой таблички на стенку офиса)
2. В компании знают более корректный перевод слова «control» — «управление», соответственно, Quality Control переводят, как Управление качеством. Тогда не возникает ассоциаций с «контролером-вахтером-билетером».
3. QA специалист знает, что управление качеством тесно связано с метрологией, а метрология — с различными измерениями. Поэтому, QA специалист знает и умеет производить различные измерения и несомненно делает это в процессе удостоверения качества программного продукта.
4. В процессе обеспечения качества продукта участвуют все сотрудники организации, вовлеченные в процесс его производства.
Значит у Вас «программисты» просто не вовлечены в процесс обеспечения качества вашего продукта.
Есть же типовые хорошо известные примеры для решения проблемы «занятости», описанной Вами:
— программисты дополнительно пишут автоматизированные тесты, тогда в «мыле» круглосуточно может быть система «непрерывной интеграции\тестирования»
— тестировщик не забивает на забывает про тест план, тогда программисты могут помочь выполнить ручные тесты, причем четко и формально, т.е. без привнесения своей субъективности разработчика!
А, соотношение «2 разработчика и 1 QA инженер хорошей квалификации» является идеальным для большинства случаев.
Конечно, бывают исключения. Например, этап багфиксинга может потребовать бОльшее количество QA инженеров, которое может значительно превышать количество разработчиков, поправивших маленький-маленький баг в ядре системы перед выпуском.
Считаю, что это ценная статья.
Но, её ценность совсем не в «правильности утверждений и выводов», а в том, что эта статья хорошо демонстрирует мировоззрение большой части отечественных разработчиков.
Мой личный опыт НЕ позволяет мне согласиться с большинством(!) утверждений и выводов из этой статьи. И, предполагаю, что мои аргументированные возражения по всем таким пунктам превысят объем самой статьи.
IMHO Не эффективно делать такое в этом комментарии. Тем более, что мои возражения просто будут выражать другую субъективную\мою точку зрения по каждому пункту статьи. И в идеале нужен будет арбитраж по альтернативным мнениям для установления «истины», но принципы демократии принятые Хабре не помогут нам в этом. («большинством голосов установить удобное нам значение числа Пи»).
Поэтому, я избрал другой путь…
Я попытался разобраться почему у меня эта статья вызывает диссонанс и, похоже, нашел ответ:
Существуют различия в культуре производства программного обеспечения в различных компаниях.
Именно эти различия и определяют наше отношение к шаблонам проектирования, процессам разработки и выпуска ПО, к QA процессам и специалистам, и, в конце концов, к самоопределению «разработчика»\«программиста»\«оператора ЭВМ» во всех этих процессах.
Говоря об американских автомобилях, участник тех событий четко выговаривал марки: "Виллис" или "Додж", иногда добавляя к последнему суффикс «три четверти». И, к стати, в «Альбоме американских автомобилей» того времени, которым снабжались советские военнослужащие, автомобиля марки Jeep вообще не было.
Нарицательное слово «джип» скорее всего позже пришло в русский язык. И до 90-х это же просто называлось «козлик».
Был восхищен схемотехникой предшественников этих однокристалок.
Довелось делать систему лазерной подгонки гибридных микросхем с управлением на Intel 8048. В системе использовался газовый лазер, который «стрелял» 100 раз в секунду. Для раскачки лазера подавалось напряжение в десятки киловольт. В момент выстрела в радиусе 5 метров сбоила вся электроника. И это несмотря на все ухищрения по экранировке, гальваническим развязкам и стабилизации напряжений питания. Вообщем жуткие условия, 100 раз в секунду был электромагнитный импульс, как от ядерного взрыва.
Мы искали решение и вдруг выяснилось, что в этих жутких условиях во внутренних регистрах Intel 8048 информация сохранялась! Только благодаря этому техническому чуду удалось сделать работоспособную систему.
За это и многое другое большое спасибо ребятам из Intel!
На эту тему спорить не буду — проиграю. Как минимум потому, что у меня все весомые вещественные доказательства на флоппи-дисках, начиная с 8-ми дюймовых, безвозвратно утрачены. Нам, в таком техническо-историческом споре нельзя будет полагаться на любые «экспертные» или «авторитетные» мнения. А судя по скриншотам в статье, у Вас «все карты на руках».
Согласен, «фоновый режим» для DOS Shell это я некорректно написал. Правильнее было бы мне написать «отложить задачу». Хотя, если пофилосовствовать, то можно рассмотреть «работу» отложенной задачи под DOS Shell, как её выполнение в фоном режиме. Просто она неминуемо будет находится в состоянии простоя из-за недоступности необходимого для её выполнения ресурса под названием CPU.
В просак попасть не страшно, если в душе имеешь железный стержень. Ведь сколько веревочке не виться, а конец-то найдется :-)
Я могу понять ваше возмущение. Причина тому слово «драйвер». А написанное мной, ну никак не ложиться на ваши каноническо-академические знания о драйверах для MS-DOS. Это вполне нормально, если не желать знать о большем…
Если Вам все-таки захочется разобраться в этом вопросе, то взгляните, например, на статью "Рабочая станция NetWare". Там достаточно хорошо описано, во что мог превратиться персональный компьютер с MS-DOS, если в него добавить «драйвер» от Novell.
Когда будете читать пусть Вас смутит и заставит задуматься о чем-то светлом и грандиозном, например, описание конфигурационного параметра:
MAX TASKS — определение максимального количества одновременно запущенных задач (для Windows, DESQview и т. д.);
MS-DOS — это realtime система
Думаю, все-таки это не верное утверждение. В самой MS-DOS не было же никаких механизмов, гарантирующих время исполнения задач и процессов!? Иначе бы в то время F-16 летали бы под управлением MS-DOS, а не QNX :-)
А разве MS-DOS как-то регламентировала устройства сетевых драйверов?
Я в то время натыкался на файл-документ от Microsoft, где подробно описывались принципы построения драйверов под MS-DOS для устройств различных типов: последовательных и блочных. И, если мне не изменяет память, там был отдельный раздел, посвященный драйверам для сетевых устройств. Но, вряд ли уместно говорить от том, что этот и подобные ему документы что-то «регламентировали». Функции ОС были весьма скромны и многие разработчики не воспринимали их, как существенные ограничение. Если что-то требовалось, то это делалось. Например, считалось абсолютно нормальным перехватить программное прерывание INT21 (основные функции DOS) и добавить нужное.
Я и пытался сказать про феномен игнорирования пользователями всех версий 4.x. А переход на следующие версии даже консервативных пользователей в большинстве случаев определялся именно потребностями в свободной памяти для выполнения приложений. И да, даже на фоне существования Windows, следующие версии MS-DOS продолжали широко использоваться.
За давностью лет могло многое конечно забыться и я сам себе уже не доверяю в этих вопросах :-)
Но, постараюсь пояснить. Тот механизм «многозадачности», о котором я упомянул, имел скорее не прямое, а косвенное отношение к процессам сетевого обмена. Конечно точно утверждать не могу. Как Вы можете догадаться, эта реализация изучалась совсем не по спецификациям производителя или с привлечением коллективного разума энтузиастов из Интернет, которые всегда знают правильный ответ. Аппаратные прерывания точно не были завязаны на этот механизм многозадачности. Но, этому механизму можно было поручить выполнение дополнительных фоновых процессов (нескольких!) в режиме разделения времени, которые при «правильной реализации» не оказывали существенного влияния на выполнение процессов основного приложения в MS-DOS.
Надеюсь, нет необходимости доказывать, что перехват управления для выполнения фоновых процессов осуществлялся на основании прерывания от таймера.
Знания о таком механизме у меня появились только потому, что мне нужен был такой механизм. Я его нашел в сетевом драйвере от Novell и успешно использовал тогда в своих корыстных целях на благо клиентам нашей конторы.
Спасибо за статью! Заставили вспомнить таки прошлый век :-)
Может и правильно. И пора уже!?
У меня всё отчетливее возникает ощущение, что развитие компьютерной отрасли пошло на следующий виток спирали развития, но на новом технологическом уровне. И тогда действительно требуется переосмысление предыдущего опыта…
Видели, видели мы этот MS DOS 4.0, но сознательно не использовали по причине глючности (или несовместимости!?) на фоне стабильной работы необходимых приложений в весьма «вылизанной» версии MS DOS 3.30.
И, да, потом ещё была версия 4.01, но с теми же отрицательными эффектами. Все кто мог откладывали переход на эти новые версии. А, по факту могли это отложить практически все. Так как большинство прикладного ПО было всё-таки рассчитано на работу с версией 3.30, которая воспринималась, как некий стандарт де-факто. И возник переломный момент только с появлением принципиально новой платформы Windows 3.1. Именно тогда у многих пришло осознание необходимости обновления OC.
Я понимаю увлеченность историей того времени. Действительно интересно было наблюдать за широкомасштабными и резкими прорывами в компьютерной области.
Тут выше была дискуссия о многозадачности… были упомянуты различные настольные программы и ОС, поддерживавшие переключение задач и многозадачность «различной степени». Все это было круто конечно. Но, по факту мы начали пользоваться этой многозадачностью только с появлением Windows 3.0. Вся многозадачность в MS-DOS воспринималась не более, чем баловство. Например, был большой риск отправить задачу в фоновый режим в этом DOS Shell и не вернуть её оттуда, потеряв результаты.
На фоне этой дискуссии, вспомнилось, что в то время была компания, не упомянутая здесь, которая своими достижениями (в т.ч. в области многозадачности) поражала меня больше, чем все остальные… это Novell. Их сетевая ОС Novell NetWear с примочками типа Novell NetWear Connct воспринимались в доИнтернетовское время, как настоящее техническое чудо. Но самый интересный компонент их сетевого решения, с моей точки зрения, это был драйвер IPX\SPX для MS-DOS. Пришлось с этим драйвером плотно повозиться тогда. Каково же было моё изумление, когда я понял, что этот «драйвер» превращает примитивную (собственно CP\M подобную!) операционную систему MS-DOS в многозадачную. И ведь действительно, как без многозадачности можно было обеспечить полноценный сетевой обмен в однозадачной ОС, если не все, что надо обеспечивалось сетевыми платами на аппаратном уровне. Конечно же переключение задач происходило по таймеру и никакого защищенного режима, но это решение прекрасно работало даже на PC с 8086\88 процессорами.
И все же многозадачность для многих не была тогда потребностью № 1. Основным «двигателем прогресса» была острая нехватка оперативной памяти. Ограничение в 640К, накладываемое ОС, была существенной проблемой для многих прикладных задач. Дополнительная память в любом объеме и любым способом воспринималась, как благо. Именно в этих обстоятельствах появилось большое количество пользователей PC, которые тратили бОльшую часть своего рабочего времени на оптимизацию системы на своем PC для получения дополнительных Кбайт свободной памяти. И это очень раздражало их начальников… Наверно именно из числа таких пользователей возникла гильдия оверклокеров, а их начальники превратились в менеджеров…
У всех разные способности. Если помнить латинский алфавит и знать, что 0x41 это заглавная «A» и 0x61 это прописная «a», то легко можно составить таблицу кодов букв. Это значит что все ключевые слова и имена могут быть дешифрованы без всяких инструментов. Небольшое знание синтаксиса языка позволит восстановить всякие скобочки и кавычки, даже если их коды не в памяти. Конечно, это бесчеловечно мучить коллегу такими упражнениями. Но, услышать подобное описанному выше это вполне реально от многих даже без доступа к компьютеру (я надеюсь).
Правильнее сказать некоторых особенностей языка Java, а не компилятора. Так как это определено в JLS и все правильные реализации компиляторов обязаны воплощать эти особенности. Но, каждый компилятор может быть со своими тараканами, которые естественно желательно, чтобы по породе приближались бы к жукам эталонной реализации компилятора javac из JDK.
Не совсем понял Ваше замечание про КПД. Если речь про получение водорода, то, я так понимаю, там главный вопрос больше в цене катализаторов для обеспечения энергоэффективного процесса. А если, про КПД двигателя, то можно вспомнить, что температура сгорания водорода в 3 раза выше бензина.
То есть, техническое решение существует где-то рядом.
«Если звезды НЕ зажигают — значит — это кому-нибудь нужно?» !(Маяковский)
Отечественный автопром перестал заниматься водородными двигателями в прошлом веке: Водородный двигатель в СССР
В 70-х годах авторы статей популярных технических журналов намекали, что скоро будем заправляться водой из придорожной канавы.
Но, до сих пор не удается отъехать от бензоколонки на расстояние больше емкости бензобака.
Может, это действительно «невыгодные изобретения»…
Разумеется глупо было рассматривать Event Control Block (ECB) какого-то сетевого драйвера в качестве Process Control Block (PCB) настоящей многозадачной ОС. Это меня не оправдывает, но это Novell спровоцировал меня.
Они реализовали в своем драйвере asynchronous event scheduler (AES) и достаточный набор функций для планирования и исполнения всяких routine.
Да, я не должен был указывать адрес процедуры своей резидентной программы (TSR) в структуре AESECB в поле
И, да, это было ошибкой передать такую структуру в функцию драйвера ScheduleAESEvent, чтобы вовлечь в мой корыстный процесс таймер и никаким образом не использовать контролеры прерывания и прямого доступа к памяти. И, тем более, использовать сетевой драйвер не по назначению это вообще преступление. Каюсь!
Если бы мне был доступен документ "Novell ODI Specification: NetWare 16-Bit DOS Protocol Stacks and MLIDs", то я, возможно, не сделал бы такой грязный хак.
Хотя, тогда я осознанно выбрал это решение и не стал писать свой планировщик задач.
Так что меня можно судить по всей строгости ;-)
1. Ответственность за качество продукта несет руководство компании. (см. семейство стандартов ISO 9000 — толковые документы, если используются не только для формальной сертификации компании и получения золотой таблички на стенку офиса)
2. В компании знают более корректный перевод слова «control» — «управление», соответственно, Quality Control переводят, как Управление качеством. Тогда не возникает ассоциаций с «контролером-вахтером-билетером».
3. QA специалист знает, что управление качеством тесно связано с метрологией, а метрология — с различными измерениями. Поэтому, QA специалист знает и умеет производить различные измерения и несомненно делает это в процессе удостоверения качества программного продукта.
4. В процессе обеспечения качества продукта участвуют все сотрудники организации, вовлеченные в процесс его производства.
а в остальном у Вас всё точно :-)
Есть же типовые хорошо известные примеры для решения проблемы «занятости», описанной Вами:
— программисты дополнительно пишут автоматизированные тесты, тогда в «мыле» круглосуточно может быть система «непрерывной интеграции\тестирования»
— тестировщик не
забивает назабывает про тест план, тогда программисты могут помочь выполнить ручные тесты, причем четко и формально, т.е. без привнесения своей субъективности разработчика!А, соотношение «2 разработчика и 1 QA инженер хорошей квалификации» является идеальным для большинства случаев.
Конечно, бывают исключения. Например, этап багфиксинга может потребовать бОльшее количество QA инженеров, которое может значительно превышать количество разработчиков, поправивших маленький-маленький баг в ядре системы перед выпуском.
Но, её ценность совсем не в «правильности утверждений и выводов», а в том, что эта статья хорошо демонстрирует мировоззрение большой части отечественных разработчиков.
Мой личный опыт НЕ позволяет мне согласиться с большинством(!) утверждений и выводов из этой статьи. И, предполагаю, что мои аргументированные возражения по всем таким пунктам превысят объем самой статьи.
IMHO Не эффективно делать такое в этом комментарии. Тем более, что мои возражения просто будут выражать другую субъективную\мою точку зрения по каждому пункту статьи. И в идеале нужен будет арбитраж по альтернативным мнениям для установления «истины», но принципы демократии принятые Хабре не помогут нам в этом. («большинством голосов установить удобное нам значение числа Пи»).
Поэтому, я избрал другой путь…
Я попытался разобраться почему у меня эта статья вызывает диссонанс и, похоже, нашел ответ:
Существуют различия в культуре производства программного обеспечения в различных компаниях.
Именно эти различия и определяют наше отношение к шаблонам проектирования, процессам разработки и выпуска ПО, к QA процессам и специалистам, и, в конце концов, к самоопределению «разработчика»\«программиста»\«оператора ЭВМ» во всех этих процессах.
Да, ладно!? Java на всех SIM-картах в телефонах стандарта GSM.
Нарицательное слово «джип» скорее всего позже пришло в русский язык. И до 90-х это же просто называлось «козлик».
Довелось делать систему лазерной подгонки гибридных микросхем с управлением на Intel 8048. В системе использовался газовый лазер, который «стрелял» 100 раз в секунду. Для раскачки лазера подавалось напряжение в десятки киловольт. В момент выстрела в радиусе 5 метров сбоила вся электроника. И это несмотря на все ухищрения по экранировке, гальваническим развязкам и стабилизации напряжений питания. Вообщем жуткие условия, 100 раз в секунду был электромагнитный импульс, как от ядерного взрыва.
Мы искали решение и вдруг выяснилось, что в этих жутких условиях во внутренних регистрах Intel 8048 информация сохранялась! Только благодаря этому техническому чуду удалось сделать работоспособную систему.
За это и многое другое большое спасибо ребятам из Intel!
Согласен, «фоновый режим» для DOS Shell это я некорректно написал. Правильнее было бы мне написать «отложить задачу». Хотя, если пофилосовствовать, то можно рассмотреть «работу» отложенной задачи под DOS Shell, как её выполнение в фоном режиме. Просто она неминуемо будет находится в состоянии простоя из-за недоступности необходимого для её выполнения ресурса под названием CPU.
Я могу понять ваше возмущение. Причина тому слово «драйвер». А написанное мной, ну никак не ложиться на ваши каноническо-академические знания о драйверах для MS-DOS. Это вполне нормально, если не желать знать о большем…
Если Вам все-таки захочется разобраться в этом вопросе, то взгляните, например, на статью "Рабочая станция NetWare". Там достаточно хорошо описано, во что мог превратиться персональный компьютер с MS-DOS, если в него добавить «драйвер» от Novell.
Когда будете читать пусть Вас смутит и заставит задуматься о чем-то светлом и грандиозном, например, описание конфигурационного параметра:
MAX TASKS — определение максимального количества одновременно запущенных задач (для Windows, DESQview и т. д.);
Думаю, все-таки это не верное утверждение. В самой MS-DOS не было же никаких механизмов, гарантирующих время исполнения задач и процессов!? Иначе бы в то время F-16 летали бы под управлением MS-DOS, а не QNX :-)
Я в то время натыкался на файл-документ от Microsoft, где подробно описывались принципы построения драйверов под MS-DOS для устройств различных типов: последовательных и блочных. И, если мне не изменяет память, там был отдельный раздел, посвященный драйверам для сетевых устройств. Но, вряд ли уместно говорить от том, что этот и подобные ему документы что-то «регламентировали». Функции ОС были весьма скромны и многие разработчики не воспринимали их, как существенные ограничение. Если что-то требовалось, то это делалось. Например, считалось абсолютно нормальным перехватить программное прерывание INT21 (основные функции DOS) и добавить нужное.
Но, постараюсь пояснить. Тот механизм «многозадачности», о котором я упомянул, имел скорее не прямое, а косвенное отношение к процессам сетевого обмена. Конечно точно утверждать не могу. Как Вы можете догадаться, эта реализация изучалась совсем не по спецификациям производителя или с привлечением коллективного разума энтузиастов из Интернет, которые всегда знают правильный ответ. Аппаратные прерывания точно не были завязаны на этот механизм многозадачности. Но, этому механизму можно было поручить выполнение дополнительных фоновых процессов (нескольких!) в режиме разделения времени, которые при «правильной реализации» не оказывали существенного влияния на выполнение процессов основного приложения в MS-DOS.
Надеюсь, нет необходимости доказывать, что перехват управления для выполнения фоновых процессов осуществлялся на основании прерывания от таймера.
Знания о таком механизме у меня появились только потому, что мне нужен был такой механизм. Я его нашел в сетевом драйвере от Novell и успешно использовал тогда в своих корыстных целях на благо клиентам нашей конторы.
Спасибо за статью! Заставили вспомнить таки прошлый век :-)
Может и правильно. И пора уже!?
У меня всё отчетливее возникает ощущение, что развитие компьютерной отрасли пошло на следующий виток спирали развития, но на новом технологическом уровне. И тогда действительно требуется переосмысление предыдущего опыта…
Видели, видели мы этот MS DOS 4.0, но сознательно не использовали по причине глючности (или несовместимости!?) на фоне стабильной работы необходимых приложений в весьма «вылизанной» версии MS DOS 3.30.
И, да, потом ещё была версия 4.01, но с теми же отрицательными эффектами. Все кто мог откладывали переход на эти новые версии. А, по факту могли это отложить практически все. Так как большинство прикладного ПО было всё-таки рассчитано на работу с версией 3.30, которая воспринималась, как некий стандарт де-факто. И возник переломный момент только с появлением принципиально новой платформы Windows 3.1. Именно тогда у многих пришло осознание необходимости обновления OC.
Я понимаю увлеченность историей того времени. Действительно интересно было наблюдать за широкомасштабными и резкими прорывами в компьютерной области.
Тут выше была дискуссия о многозадачности… были упомянуты различные настольные программы и ОС, поддерживавшие переключение задач и многозадачность «различной степени». Все это было круто конечно. Но, по факту мы начали пользоваться этой многозадачностью только с появлением Windows 3.0. Вся многозадачность в MS-DOS воспринималась не более, чем баловство. Например, был большой риск отправить задачу в фоновый режим в этом DOS Shell и не вернуть её оттуда, потеряв результаты.
На фоне этой дискуссии, вспомнилось, что в то время была компания, не упомянутая здесь, которая своими достижениями (в т.ч. в области многозадачности) поражала меня больше, чем все остальные… это Novell. Их сетевая ОС Novell NetWear с примочками типа Novell NetWear Connct воспринимались в доИнтернетовское время, как настоящее техническое чудо. Но самый интересный компонент их сетевого решения, с моей точки зрения, это был драйвер IPX\SPX для MS-DOS. Пришлось с этим драйвером плотно повозиться тогда. Каково же было моё изумление, когда я понял, что этот «драйвер» превращает примитивную (собственно CP\M подобную!) операционную систему MS-DOS в многозадачную. И ведь действительно, как без многозадачности можно было обеспечить полноценный сетевой обмен в однозадачной ОС, если не все, что надо обеспечивалось сетевыми платами на аппаратном уровне. Конечно же переключение задач происходило по таймеру и никакого защищенного режима, но это решение прекрасно работало даже на PC с 8086\88 процессорами.
И все же многозадачность для многих не была тогда потребностью № 1. Основным «двигателем прогресса» была острая нехватка оперативной памяти. Ограничение в 640К, накладываемое ОС, была существенной проблемой для многих прикладных задач. Дополнительная память в любом объеме и любым способом воспринималась, как благо. Именно в этих обстоятельствах появилось большое количество пользователей PC, которые тратили бОльшую часть своего рабочего времени на оптимизацию системы на своем PC для получения дополнительных Кбайт свободной памяти. И это очень раздражало их начальников… Наверно именно из числа таких пользователей возникла гильдия оверклокеров, а их начальники превратились в менеджеров…
Правильнее сказать некоторых особенностей языка Java, а не компилятора. Так как это определено в JLS и все правильные реализации компиляторов обязаны воплощать эти особенности. Но, каждый компилятор может быть со своими тараканами, которые естественно желательно, чтобы по породе приближались бы к жукам эталонной реализации компилятора javac из JDK.