Re: libpthreads,libmpeg3 -> windows
- From
- Alexander Pevzner ()
- To
- Boris Rudakov ()
- Date
- 2003-06-14T17:21:48Z
- Area
- CARBON.COPY
* Forwarded from area 'RU.UNIX.PROG'
From: Alexander Pevzner <pzz@pzz.msk.ru>
Hello, Boris Rudakov!
Fri, 13 Jun 2003 12:00:02 +0400 you wrote to Alexander Pevzner:
BR> AP> Вообще-то, мы этот O_BINARY именно для вас придумали.
BR> Я удивлен :) Никогда им не пользовался (бо CLib избегаю) и думал что он
BR> - чисто юниксоидная вещь...
Виндузятники вообще в среднем не в курсе, что происходит за
пределами их среды обитания (да и в своей среде знают только
небольшой кусочек) :-)
BR> AP> Чтобы ваши библиотеки могли догадаться, работаем мы с бинарным
BR> AP> файлом или с текстовым. В UNIX'е этой разницы нет, и O_BINARY
BR> AP> просто игнорируется (если вообще определен).
BR> В Реальном WinAPI его тоже нигде нет и в эмулиционых библиотеках он
BR> выставляется "исходя из общих соображений".
Что значит, эмуляционные библиотеки? Ты вообще в курсе, что на
любой платформе есть разница между системными вызовами (которые
более-менее прямо соответствуют сервисам ядра системы, в широком
смысле этого слова), и библиотечными функциями, которые построены
над системными вызовами.
В унихе open(), read(), write(), ..., это системные вызовы, а
stdio.h - библиотечные функции. У нас нет системного вызова fopen() :-)
В форточках то же самое. Разница между бинарными и текстовыми файлами
существенна для работы функций, которые работают с файлом как с
текстом, т.е. понимают разделение строк.
BR> Ааааа... щаз порылся в сырцах RTL и нашел следующее: Борланд юзает его
BR> как команду транслировать ли \n в \r\n, а Мелкософт его видимо раньше
BR> юзал, а щаз вообще забил - хранить-хранит, но использовать...
А что, мелкософт не делает трансляции между \n и \r\n?
BR> AP> Открую тебе секрет: в UNIX'е ты тоже можешь проделать с хендлями
BR> AP> всякие штуки, пользуясь средствами системного API (например,
BR> AP> close(), dup(), dup2()).
BR> Думаш я не в курсе ? :):):):)
Ну и почему в унихе от этого stdio не ломается, я в форточках
ломается? Потому, что плохо сделано, или потому, что им пользоваться
никто не умеет?
BR> Пример: есть у меня сервак. Собран как GUI-приложение, не смотря на то,
BR> что в основном работает как сервис НТи и никаких окон не
BR> создает. Просто при сборке как GUI-модуль проявляется несколько
BR> преимуществ, в частности устраняется ряд совершенно мне не нужных
BR> приседаний:
Одна из проблем форточек заключается в том, что гуевые программы,
консольные программы и системные сервисы это три достаточно разные
штуки, без всякой технической причины для такого разделения.
Я думаю, поддержку этих вещей делали три независимые группы программеров,
и общались между собой они редко, а потом уже все соеденили в одну
систему.
BR> BR>> ЗЫЫ: И виноваты в этом засранстве, как ни странно, именно
BR> BR>> юниксоиды, требующие наличия определенных функций в составе
BR> BR>> стандартизированного CLib. А они полноценно - НЕРЕАЛИЗУЕМЫ.
BR> BR>> Сделать-то их сделали, но только для ЧАСТНЫХ СЛУЧАЕВ
BR> BR>> использования. Вот и получайте головняк при порте :)
BR> AP> Ну если специально проектировать OS так, чтобы она была насколько
BR> AP> возможно несовместима с UNIX'ом, то при определенном умении и
BR> AP> старании можно добиться заметных успехов :-)
BR> Погоди-ка !!!!
BR> А что, по-твоему, другая ОС ОБЯЗАНА быть похожа на юникс ?!?!?! СФИГА
BR> ЛИ ?! ТЫ ЧЕГО ?!
Те места, которые были содраны с Униха, можно было бы содрать и более
аккуратно. На практике же они сделали ровно наоборот, даже где никакой
нужды закладывать несовместимость не было, они сделали несовместимое
решение.
BR> НТя - НЕ юникс. Это даже НЕ Win32. Это могучее ядро, продолжающее
BR> DEC-овские архитектурные традиции (не менее древние и благородные
BR> традиции чем юниксоидные) и оно нисколько не обязано быть похожим на
BR> ваши представления о том "как надо". Придерживающиеся ваших
От того места, где там могучее ядро, и до того места, где видимый
простому человеку API, проложен такой слой всяческих прокладок, что
технически им почти не было разницы, какой API делать, все равно
API, видимый пользователю, это не API системы.
BR> представлений (ничего против них не имею, хотя с некоторыми идеями не
BR> согласен) - пишут именно юниксы. А НТя - НЕ юникс. И мощь ее ядра
BR> такова, что юникс по верх него не просто вполне реализуем, а уже
BR> неоднократно реализован (дай Бог чтобы Мелкософт, загробаставший
BR> OpenNT/Interix, его не испоганил). "Генеральная подсистема" поверх
Уних реализуем даже поверх голого процессора, почему бы ему не быть
реализуемым поверх Win32 API?
BR> НТевего ядра - Win32 susbsystem тоже НЕ юникс и тоже НЕ ОБЯЗАНА быть на
BR> него похожей. Более того, я нахожу что некоторые аспекты ее "религии",
BR> в частности полный отказ от идеи сигналов, отказ от форков, особый упор
BR> на многонитевость/асинхронность и унификация средств синхронизации, SEH
BR> - более концептуальны и современны. Но ведь я же не говорю что юникс
BR> ОБЯЗАН начинать равняться на эти фичи, верно ? Юникс - это юникс, он
BR> таков каков он есть...
Хе-хе, концептуальны и современны. Подумай о том, как будет работать
SEH (это ведь системные exceptions, я не ошибаюсь?), если аппаратное
исключение происходит асинхронно с исполнением кода. Такое может
произойти и в нормальной жизни. Например, исключение от PCI приходит
в момент, когда операция действительно производится, а не в момент,
когда ты ее заказал (между процессором и шиной имеется буфер,
способный откладывать операции).
BR> Ты делаешь существенную логическую ошибку, считая юникс - эталоном, и
BR> оценивая другие системы с позиций их "похожести" на юникс. Это -
BR> контрпродуктивно и логически ошибочно. Другие системы НЕ ОБЯЗАНЫ быть
BR> похожими. Кстати, заметь - существенно НЕпохожее на юникс ядро НТи
Насколько я понимаю, форточки даже ANSI C не реализуют до конца
совместимым образом.
Я согласен не считать Уних эталоном, но зачем ломать совместимость
без осмысленной технической причины? Даже WinSock, содранный с
Berkley Sockets, слишком сильно не совместим с оригиналом, чтобы
даже для простых вещей нелья было обойтись без системно-зависимых
оберток.
BR> имеет такую мощь, что юникс поверх него реализован как минимум дважды:
BR> сначала Мелкософтом, а потом Softway/Interix. И официально признано что
BR> получился НАСТОЯЩИЙ юникс, полностью конформный длинному списку
BR> стандартов.
Ох уж это мне "официальное признание".
BR> А что до "генеральной" Win32 subsystem, то ее API достаточно похож на
BR> юниксоидный, что лишь говорит о разумности подходов, примененных и там
BR> и там. Непохожесть же лишь говорит об отличиях "религий", а отнюдь не
BR> о качестве или злом умысле. Не делай логической ошибки, считая юникс
BR> эталоном, на который нужно равняться - это НЕ ТАК.
Я думаю, Мелкософт вполне сознательно продвигает API, несовместимый
с Унихом. Цель - сделать так, чтобы трудно было писать портабельный
код. Это привязывает пользователей и разработчиков к платформе.
BR> Мне кажется что самое разумное - отдать должное затраченным на это
BR> усилиям, с сожалением констатировать что нерешаемая в общем виде задача
BR> действительно не решена, и иметь это в виду при кроссплатформенной (не
BR> кросс-юниксовой, а именно кроссплатворменной) разработке софта. Ни
BR> Борланд ни Мелкософт ни Макинтошевцы не виноваты в том, что вы требуете
BR> реализовать от них невозможное :) Виноваты вы, но и страдаете больше
BR> всех - вы сами, напарываясь на грабли при порте :):):)
Я не понимаю, чем же мы виноваты? Наш API совместим еще с тех времен,
когда вас и в задумке не было. Скажи еще, что мы виноваты в том бардаке
с русскими кодировками, который мы сейчас имеем :-)
--
Wishes, Alexander Pevzner (pzz@pzz.msk.ru)
--- ifmail v.2.15dev5
* Origin: Private Node of Alexander Pevzner (2:5020/400)