ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
26 ноября
77843
Рэйлвэй Каген (12.01.2007 15:01, просмотров: 1238)
Коллеги с толстым каналом на анлимите! Кто-нибудь может перевыложить 54МБ(!) на какой-нибудь хостинг, поддерживающий докачку? Забодался уже на 128кбит рвется зараза на 30-ти метрах :) и докачать не дает. Что интересное нарою - расскажу. http://www.bluebottle.ethz.ch/downloads/crazy/AosCD.zip
Почему Оберон и ему подобные системы могут стать следующими? Рассуждения ламера. Система открытая и расширяемая, без четкого разделения на user applications и sytem, в отличие от закрытых *никсо- и виндоподобных систем с их жестким разделением на user applications и sytem. В закрытых системах user applications и sytem работают каждые в своем адресном пространстве и легальное межпрограммное взаимодействие осуществляется только через системные вызовы. В обероноподобных (открытых) системах общее адресное пространство для всех загруженных на данный момент модулей. Логично предположить, что описать состояние всей системы будет легче в объектных терминах. Отсюда первое требование на безопасность языка программирования с точки зрения обращения к переменным, объектам и методам. Си не подходит сразу, поскольку запросто дает завести нетипизованный указатель на что угодно, а используя приведение типов - обратиться к чему угодно, причем не факт. что там, куда указатель сейчас смотрит будет именно то, ради чего этот указатель заводился :) Да и в дельфях тоже самое прокатывает на ура. Описать закрытую систему (винды, *никс-*нукс) в в терминах объектной модели не удастся, поскольку изначально есть разделение адресных пространств. Поставить, как в паскале, "uses" друг на друга в системных модулях и user applications не удастся, т.к. это будет означать объединенное (общее) адресное пространство, что противоречит принципам закрытых систем. С другой стороны - пусть в user application есть пара потоков, и один из них загрузил *.dll-ку. Просто обратиться к ее методам из второго потока уже не удастся, поскольку есть ограничение, явно не отслеживаемое ни одним компилятором - *.dll-ка должна выполняться в контексте загрузившего ее потока и никак иначе. Получилось, что в пределах собственного адресного пространства приложение ужЕ не из всех своих потоков видит методы загруженного модуля. Ну никак не вписывается винда в объектную модель. Но вызвать все-таки можно - для винды сделали COM и ActiveX. Стоимость вызова метода такого модуля минимум на 2 порядка выше, чем просто вызов функции загруженной *.dll (кому не верится - можете потрассировать). Трудно поверить, что вкладывая бабки в разработку Зоннон, мелкософт откажется от COM и ActiveX. Вот и предположение - зачем Зоннону торчать бестолку в Zonnon.RTL.Barrier по 10-20мкс в каждом time slice виндозного потока, как не для ожидания, пока завершатся все COM-вызовы. Да, еще не забыть бы про DRM - наверное тоже запихнут в какой-нибудь Zonnon.Drm.DisablingFunctionality() :)