Microsoft переходит на XML

 
1 2 3 4 5 6

Bobo

опытный

Bobo>> То, что без переноса СОМ реализовать полноценную переносимость этих форматов невозможно.
Balancer> Кстати. Вот в OOo есть OLE. можно легко электронную таблицу засунуть в документ, документ - в презентацию и т.п. Как это они с этой фигнёй переносимость умудрились реализовать? :) [»]

Гы, ну и что они с внедренными объектами будут делать на линуксе? :D
Весь в белом /© Vale/  

Balancer

администратор
★★★★★
Bobo> Гы, ну и что они с внедренными объектами будут делать на линуксе? :D [»]

Это переносимые объекты. Документ, созданный с OLE под Linux также окроется и под Windows.
 

Bobo

опытный

Balancer> Это переносимые объекты. Документ, созданный с OLE под Linux также окроется и под Windows. [»]

Какой-же OLE под Линуксом? Там такого нет.
Весь в белом /© Vale/  

Balancer

администратор
★★★★★
Bobo> Какой-же OLE под Линуксом? Там такого нет. [»]

А откуда в "Object Linking and Embedding" появилось слово Windows? :)
Прикреплённые файлы:
 
 
RU Дм. Журко #16.06.2005 21:54
+
-
edit
 

Дм. Журко

опытный

Здравствуйте, уважаемый Balancer.

Balancer> А можно пример конкурента, который проиграл, изначально сделав выбор переносимости за счёт функциональности?

OOO? Большинство реализаций Tex? Нет? Надо всё-таки сначала б возможности, а после думать о переносе.

Дмитрий Журко
 
RU Дм. Журко #16.06.2005 21:58
+
-
edit
 

Дм. Журко

опытный

Здравствуйте, уважаемый Татарин.

Татарин> Дмитрий, Вы настолько увлеклись голословными утверждениями, и при этом настолько неправы, что Вас нельзя не поправить.

Надо поправлять!

Татарин> Тот же МС-офис (и ворд) подразумевает интенсивное OLE, со всеми последствиями для формата. Надеюсь, Вы (как человек "знающий языки программирования") понимаете, что это значит?

Надеюсь, понимаю, впрочем, тут недостаточно «знать языки программирования» и это видно в нашем обсуждении.

Татарин> Невозможно перетащить куда-нибудь OLE, который весь построен на COM. А чтобы перетащить куда-то СОМ, Вам нужно перетащить с собой пол-винды... которая работает сейчас на паре процессоров (из пары десятков, активно живущих на рынке).

Давайте так, для простоты: процессоры, на которых нет «пол-винды», не могут «жить активно на рынке». К счастью, на подавляющую часть процессоров «перетащено пол-винды», исключений нет почти. И это простой и наглядный пример образцовой переносимости, best portability, если понятнее.

Вопрос, сколько времени потребуется MS, чтоб внедрить OLE в Linux, когда там появятся приложения, достойные OLE?

Татарин> Это не "переносимость", это совершенно строгое наоборот .

Вы, как и многие, путаете хорошее и лучшее. Понятная трудность, надо медитировать! Простой вопрос: лучшее хорошо? Мой ответ: кому — как, но я ценю лучшее. Всюду, где есть OLE службы, есть .DOC. Кое-где, где нет OLE, можно использовать .DOC.

Татарин> При этом функциональность OLE можно организовать и без самого OLE. Но и при наличии сходной функциональности , Вы не сможете полноценно прочитать DOC на системе без COM.
Татарин> Одного этого момента вполне достаточно, чтобы ответить на вопрос о переносимости вполне однозначно.

Так думал я году в 1995, когда компьютерная пресса «тёрла тему». После пересмотрел своё заёмное «всезнайство», стал больше обращать внимание на то, что происходит, а не на то, о чём говорят.

Дмитрий Журко
 
RU Дм. Журко #16.06.2005 22:17
+
-
edit
 

Дм. Журко

опытный

Здравствуйте, уважаемый Vale.

Vale> Потому что 99.9% возможностей Word-а использует 0.01% его пользователей. Еще 1% использует 90% возможностей, еще 90% юзеров криво пользуются теми возможностями, которые они знают (и в жизни ни одного стиля абзаца не поменяли)... а те, кто остался - им достаточно тех 20% возможностей, которы реально нужны
Vale> Цифры "от балды", разумеется

Беда в том, что в OOO нет важных свойств даже для самого непритязательного русского пользователя. Согласен, что MSWord слишком мощен для тех, кто плохо им владеет. Совершенно согласен, потому надо учить. Вообще, Ваше радение «за юзеров» несколько цепляет... Ладно.

Выхода два: 1 — учиться, 2 — ждать, пока выйдет совершенная программа взамен самой лучшей.

Vale> И того, что умеет OpenOffice - более чем достаточно для двух последних категорий пользователей Ворда

По крайней мере русскоязычные пользователи будут сильно ущемлены. По-сути, отказ от овладения MSWord будет означать утрату одной из важнейших задач, ради которых приобретается компьютер.

Vale> И что?
Vale> Например, в нашей лабе поводом для перехода с Win 3.11+WinWord 2 на Win95/WinWord 95 были длинные имена файлов. А поводом для перехода на Word 2000 было то, что нам присылали файлы в WinWord 2000.
Vale> Вопрос: где здесь спряталась фраза "новые крутые возможности Word"?

Понять разницу, можно только попробовав. Мой опыт в том, что всякий раз, переходя на новый выпуск MSO, разницы почти не ощущаю. Сложности там же, где были раньше, меняются не слишком... Возможно, это даже хорошо! Разницу можно почувствовать только поработав в новом выпуске, а после, перейдя на старый. Вот тут и начинается забава. Много раз только тогда понимал тех, кто ругает MSO.

Потому работаю в MSO XP и не желаю обратно. С оценкой уместности OLE тоже почти согласен, но тут есть грань меж использованием и злоупотреблением. Надо учиться, а не придумывать причины, чтоб этого не делать!

Дмитрий Журко
 
+
-
edit
 

Balancer

администратор
★★★★★
Balancer>> А можно пример конкурента, который проиграл, изначально сделав выбор переносимости за счёт функциональности?
Д.Ж.> OOO? Большинство реализаций Tex? Нет? Надо всё-таки сначала б возможности, а после думать о переносе.

Чтобы проиграть - нужно изначально быть сильно популярнее конкурентов. Даже, пусть и не в тему, но пример с Netscape - как раз может быть примером проигрыша. Но когда, например, OOo был популярнее MS Office?

 

Zeus

Динамик

Balancer> Дык, я потому и интересуюсь :) В смысле - что да, это обычно на проц повязано. И потому интересно, на чём Зевс сидит.

Это не я сижу, это мне файл дали в юни, со Спарковского Соляриса вроде. Кончено, я проц имел в виду.

Balancer> Зато их порядок и число от архитектуры не зависят :) [»]

Еще как зависит! Вспоминаем CR/LF :D
И животноводство!  
RU Balancer #17.06.2005 09:25  @Balancer#15.06.2005 22:00
+
-
edit
 

Balancer

администратор
★★★★★
Zeus> Это не я сижу, это мне файл дали в юни, со Спарковского Соляриса вроде. Кончено, я проц имел в виду.

Ну, тем хуже для формата. Ненужная усложнённость :)

Balancer>> Зато их порядок и число от архитектуры не зависят :) [»]
Zeus> Еще как зависит! Вспоминаем CR/LF :D [»]

Это уже не порядок и число байтов, а разные форматы. То же самое, что сравнивать .doc под Win32 с каким-нибудь .tex под Linux :D
 

Bobo

опытный

Bobo>> Какой-же OLE под Линуксом? Там такого нет. [»]
Balancer> А откуда в "Object Linking and Embedding" появилось слово Windows? :) [»]

Потому, что OLE — это технология МС, и то, что ОО изобразил ЭТО в линуксе говорит о том, что парни из ОО нагло врут. Никакого отношения ЭТО к той технологии, которую мы назывем OLE, нет.

Ваш скриншот наглядный пример того, как ОО пудрит мозги пользователям.
Весь в белом /© Vale/  
+
-
edit
 

Balancer

администратор
★★★★★
Bobo> то, что ОО изобразил ЭТО в линуксе говорит о том, что парни из ОО нагло врут.

Эти "парни", вообще-то, изначально Sun Microsystems. Учитывая их постоянные на той или иной почве судебные тяжбы с MS, если бы они так нагло врали, MS их бы давно прищучила :D

Вообще, прежде, чем лезть в спор, было бы хорошо бы, если б ты хоть одним глазком взглянул на продукт, о котором идёт речь :) Ибо незаметить логотип Sun на сплеше - это нужно очень сильно постараться :D
 

Zeus

Динамик

Zeus>> Это не я сижу, это мне файл дали в юни, со Спарковского Соляриса вроде. Кончено, я проц имел в виду.
Balancer> Ну, тем хуже для формата. Ненужная усложнённость :)

Не понял. Чем хуже? И как это ненужная, если именно что нужная? Взял в одном месте и свободно прочитал в любом другом. А так и XML легко обвинить в "переусложненности".

Zeus>> Еще как зависит! Вспоминаем CR/LF :D [»]
Balancer> Это уже не порядок и число байтов, а разные форматы. То же самое, что сравнивать .doc под Win32 с каким-нибудь .tex под Linux :D [»]

Ну здрасьте! Это особенности "простого текстого формата", на котором очень многие и базируются. Тот же ТеХ, например. Вот по идее он совершенно переносимый, но ведь тоже на основе голого текста. А если этот "голый текст" разный - возможны потенциальные проблемы. Ну, допустим, можно в указном порядке потребовать (в спецификации того же ТеХ, скажем), чтобы ему тексты шли строго с CR. Тогда формат полностью определен. Но тогда же не будет возможности создать и редактировать его исходник в Виндовсе (штатными средствами). А можно потребовать чтения любого окончания строки. Но все равно остается проблема переноса исходников. А еще есть пресловутые проблемы с кодировками, которые тоже платформо-зависимые и могут попортить жизнь даже изначально переносимому формату.
И животноводство!  

Bobo

опытный

Balancer> Эти "парни", вообще-то, изначально Sun Microsystems. Учитывая их постоянные на той или иной почве судебные тяжбы с MS, если бы они так нагло врали, MS их бы давно прищучила :D

Вы хотите сказать, что ОО содержит переносимый OLE, совместимый с МС-овским? Гы много раз.

Balancer> Вообще, прежде, чем лезть в спор, было бы хорошо бы, если б ты хоть одним глазком взглянул на продукт, о котором идёт речь :) Ибо незаметить логотип Sun на сплеше - это нужно очень сильно постараться :D [»]

Да какая разница какая там лейбочка? Главное, что пасаны гонят :D

Я внимательно изучал в свое время ОО, и расчитывал на него — думал использовать на своем хилом ноутбуке. Не получилось :)

Весь в белом /© Vale/  

Balancer

администратор
★★★★★
Zeus> Не понял. Чем хуже? И как это ненужная, если именно что нужная? Взял в одном месте и свободно прочитал в любом другом.

Если в формате порядок байтов может быть и таким, и эдаким, то ещё, как минимум, в него нужно включать признак, описывающий этот формат, анализировать его при парсинге и т.п. Куда проще в стандарте последовательность байт жёстко задать, или вообще от неё отказаться :)

Zeus> Ну здрасьте! Это особенности "простого текстого формата", на котором очень многие и базируются. Тот же ТеХ, например. Вот по идее он совершенно переносимый, но ведь тоже на основе голого текста. А если этот "голый текст" разный - возможны потенциальные проблемы.

Это всё самодурство времён CP/M и DOS :) Кривая ориентация на принтер, а не на экран. И, в любом случае, с платформой прямо не связано :)

>Ну, допустим, можно в указном порядке потребовать (в спецификации того же ТеХ, скажем), чтобы ему тексты шли строго с CR. Тогда формат полностью определен. Но тогда же не будет возможности создать и редактировать его исходник в Виндовсе (штатными средствами).

Ты не поверишь, но я с этой проблемой сталкиваюсь почти ежедневно :D Но решение её примитивное - при каждом прочтении файла - "s/\r//g;" И всё :)

>А можно потребовать чтения любого окончания строки.

В Perl или Forth, например, признак окончания строки задаётся явно. Очень удобно когда нужно прочитать весь файл как строку, или разобрать CSV-данные :)

>А еще есть пресловутые проблемы с кодировками, которые тоже платформо-зависимые и могут попортить жизнь даже изначально переносимому формату. [»]

Для переносимых форматов давно утвердили UTF-8. Всё остальное - от лукавого :)
 

Balancer

администратор
★★★★★
Bobo> Вы хотите сказать, что ОО содержит переносимый OLE, совместимый с МС-овским? Гы много раз.

Я хочу сказать, что если, при всей напряжённости, MS до сих пор не придралась к Sun и OOo на тему термина OLE, то это термин явно "широкого профиля" :)

Bobo> Я внимательно изучал в свое время ОО, и расчитывал на него — думал использовать на своем хилом ноутбуке. Не получилось :) [»]

Хм. По-моему и без всякого изучения понятно, что Java-based продукты куда как более ресурсоёмкие, чем на native-code :)
 

Bobo

опытный

Ну так это умным понятно, а я-же дебил :)
Весь в белом /© Vale/  

Zeus

Динамик

Balancer> Если в формате порядок байтов может быть и таким, и эдаким, то ещё, как минимум, в него нужно включать признак, описывающий этот формат, анализировать его при парсинге и т.п. Куда проще в стандарте последовательность байт жёстко задать, или вообще от неё отказаться :)

А я разве сказал, что в файле разного рода представления? Я вообще-то сам не знаю, как там именно устроено. Скорее всего именно строго заданный порядок. Я и имел в виду, что порядок (и многое прочее; насколько я понимаю, там IEEE float и т.п. стандарт) именно жестко стандартизирован. А для пользователя это вообще неважно, факт в том, что файл корректно читается и на тех, и на этих платформах. Это ли не переносимость? :)

Balancer> Это всё самодурство времён CP/M и DOS :)

Ну, какая разница. Проблема-то реальная. С нынешней точки зрения можно сказать, что вообще все однобайтные кодировки - самодурство :) Но тогда-то были свои причины (у некоторых, по крайней мере).

Balancer> Ты не поверишь, но я с этой проблемой сталкиваюсь почти ежедневно :D Но решение её примитивное - при каждом прочтении файла - "s/\r//g;" И всё :)

Правильным решением было бы, имхо, чтобы все текстовые редакторы понимали все форматы (благо их всего-то 3 штуки :)). А то, блин, проблему из воздуха сделали...

Balancer> Для переносимых форматов давно утвердили UTF-8. Всё остальное - от лукавого :) [»]

Тот же ТеХ появился много раньше UTF-8 и до сих пор активно используется :) И большинство значков там было тоже задолго до универсальных кодировок. Ну, вместо ё пишешь \"e, чем не способ :) А так он понимает любые кодировки с помощью подключаемых пакетов.

P.S. Что-то вспомнил по поводу конца строки самую первую олимпиаду по информатике, класс 8, наверное. В одном из заданий надо было посимвольно читать текстовый файл. Не помню, из-за чего, но пришлось идти на апелляцию, а там исходники смотрели. Препод как увидел, что я конец строки корректно по eoln определяю, а не как все поголовно по #13#10, сразу 3 балла накинул :D Что, кстати, выбило меня из плотной кучи немного наверх :)

P.P.S. Что-то цитаты не обрабатываются...
И животноводство!  
+
-
edit
 

-exec-

опытный

не c случаем? c сам определяет какой на платформе конец строки, афаир, так что там можно всегда смело пользовать '\n'. ы?
 

Balancer

администратор
★★★★★
Zeus> А я разве сказал, что в файле разного рода представления?

Я по "У меня читаются файлы, записанные на юниксе с другим порядком байтов в слове" так подумал. Т.е. - "записанные с другим порядком байтов". Протормозил, расслабило то, что в наше время народ массово пропускает запятые :)

Zeus> Правильным решением было бы, имхо, чтобы все текстовые редакторы понимали все форматы (благо их всего-то 3 штуки :)). А то, блин, проблему из воздуха сделали...

Это не Unix-way :)

Zeus> P.P.S. Что-то цитаты не обрабатываются... [»]

Угу, перевожу систему, по возможности поэтапно, на новый движок :)
 

Zeus

Динамик

Balancer> Это не Unix-way :)

Снобы B) Впрочем, именно Юниксовские #13 мне кажется наиболее нормальным вариантом :) Даже мой старенький 9-игольчатый Роботрон сам умел подставлять LF (#10) при встрече CR. И наоборот. И не подставлять. Управлялось микропереключателем :) В общем, во времена появления DOS этой проблемы практически не существовало, и зачем было городить два символа, непонятно... Но факт - теперь приходится бороться, как и с однобайтными кодировками...
И животноводство!  
+
-
edit
 

Balancer

администратор
★★★★★
Zeus> Снобы B)

Не снобы. Это, действительно, грамотный подход. Жаль только, в том же Linux'е используется всё реже.

Zeus> Впрочем, именно Юниксовские #13 мне кажется наиболее нормальным вариантом :)

#10 :) Точнее - "\n"
#13 ("\r") в чистом виде - это на Маках

Zeus>Даже мой старенький 9-игольчатый Роботрон сам умел подставлять LF (#10) при встрече CR. И наоборот. И не подставлять.

А это он зря :D Т.к. именно из-за принтеров эта путаница и возникла. CR по Epson-стандарту переводил головку в начало этой же строки, LF - в это же положение следующей строки. Собственно, в DOS сделали как в принтерах, отсюда и путаница :)

Zeus> В общем, во времена появления DOS этой проблемы практически не существовало

См. выше :) Для ускорения печати на принтерах и терминалках, требовался символ перехода на следующую строку без сдвига положения головки - Line Feed. Вместе с тем, безусловно, требовался и символ перевода к началу текущей строки Carrige Return. Эти символы должны быть обязательно. Но как быть с переводом курсора в начало следующей строки? Можно вводить новый символ, можно, для дисплея, переопределять семантику символов, можно выводить их пару. В Unix пошли по пути переопределения, в DOS - на вывод двух символов :)

Zeus> и зачем было городить два символа, непонятно... Но факт - теперь приходится бороться, как и с однобайтными кодировками...

Я одну команду в полудюжину символов за борьбу не считаю :D Это в том случае, если нужно таки оба варианта предусмотреть. Обычно же - у меня даже под Windows давно файлы с Unix-строками хранятся :)
 

Zeus

Динамик

Zeus>> Снобы B)
Balancer> Не снобы. Это, действительно, грамотный подход. Жаль только, в том же Linux'е используется всё реже.

Что грамотный подход? Забивать на положение де факто?

Zeus>> Впрочем, именно Юниксовские #13 мне кажется наиболее нормальным вариантом :)
Balancer> #10 :) Точнее - "\n"
Balancer> #13 ("\r") в чистом виде - это на Маках

Да? Значит, я уже забыл. Мне почему-то файлы с #13 больше попадались, да и на других системах (да хоть на том же Спектруме :)) был именно он. В общем, я за #13 :)

Zeus>>Даже мой старенький 9-игольчатый Роботрон сам умел подставлять LF (#10) при встрече CR. И наоборот. И не подставлять.
Balancer> А это он зря :D Т.к. именно из-за принтеров эта путаница и возникла. CR по Epson-стандарту переводил головку в начало этой же строки, LF - в это же положение следующей строки. Собственно, в DOS сделали как в принтерах, отсюда и путаница :)

Разумеется, не зря. Оба символа нужны, на принтере надо и то, и то раздельно. Но именно из-за того, что во многих системах есть только один символ для новой строки, сам же принтер можно переключить в режим, когда он будет подставлять недостающую пару. И это позволяло выводить файлы напрямую. Зачастую в то время переключить принтер было проще, чем ковыряться с драйверами и системой.

Разумеется, тут уже с принтером возникала проблема - у программы (скажем, при выводе графики) нет способа узнать, как принтер сконфигурирован. Но у принтера есть куча кодов-заменителей, чем и пользовались. Скажем, ESC J (если правильно помню) позволяет подавать бумагу на нужное расстояние.

Balancer> См. выше :) Для ускорения печати на принтерах и терминалках, требовался символ перехода на следующую строку без сдвига положения головки - Line Feed. Вместе с тем, безусловно, требовался и символ перевода к началу текущей строки Carrige Return. Эти символы должны быть обязательно.

Не для ускорения, а просто это два физически разных действия, и удобно иметь их раздельно. Особенно возврат каретки. В отличие от экрана, на котором курсор можно свободно позиционировать (мотать бумагу назад далеко не все принтеры умели, да и не всегда это возможно, особенно в конце листа).

> Но как быть с переводом курсора в начало следующей строки? Можно вводить новый символ, можно, для дисплея, переопределять семантику символов, можно выводить их пару. В Unix пошли по пути переопределения, в DOS - на вывод двух символов :)

Да и в ДОСе не так просто. Для дисплея все равно #13 - это полный CR/LF (попробуй вывести ^М). А LF просто глотается.

Zeus>> и зачем было городить два символа, непонятно... Но факт - теперь приходится бороться, как и с однобайтными кодировками...
Balancer> Я одну команду в полудюжину символов за борьбу не считаю :D Это в том случае, если нужно таки оба варианта предусмотреть. Обычно же - у меня даже под Windows давно файлы с Unix-строками хранятся :) [»]

Ну, с комарами тоже бороться надо :)
И животноводство!  
Это сообщение редактировалось 20.06.2005 в 10:51
+
-
edit
 

Mishka

модератор
★★★
У, бравые спорщики. \n появился гораздо раньше, чем мысли о ДОС появились. Bell Lab и машины DEC были началом вместе с родителями языка С и Униха.
 
EE Татарин #20.06.2005 04:09
+
-
edit
 

Татарин

координатор
★★★★☆
Татарин>> Дмитрий, Вы настолько увлеклись голословными утверждениями, и при этом настолько неправы, что Вас нельзя не поправить.
Д.Ж.> Надо поправлять!
Пробуем. :)

Д.Ж.> Давайте так, для простоты: процессоры, на которых нет «пол-винды», не могут «жить активно на рынке».
Нет.
Во-первых, так мы все же не будем, простота такая насквозь фальшива.
Мы говорим пока о переносимости формата, а не о том, насколько эта переносимость актуальна сейчас на рынке или вообще нужна индустрии.

Во-вторых, есть множество замечательных процессоров, на которых нет и в ближайшее время не будет винды, несмотря на то, что они отлично себя зарекомендовали. PowerPC, ARM/xScale, MIPS - все эти семейства отлично живут и развиваются. На них не делают (точнее - почти не делают) десктопов, но делали бы с преогромным удовольствием, буде под них существовал бы соответствующий набор софта... и вот тут мы плавно переходим к востребованности переносимости. Для индустрии.

Архитектура х86/x87, типичный CISC (и система команд, которая из оной вытекала) изжила себя, сдохла, и прогнила до такой невероятной степени, что успела изнутри прорасти другими идеями, изначально к ней ни с сном, ни духом - RISC, VLIW, векторные команды и т.п. Вы только вдумайтесь в глубокий маразм: 64-х-битный процессор на железном уровне вынужден уметь исполнять байтовую команду, которая тащится чуть ли не от 8080 семдесятмохнатого года выпуска. Причем, чтобы это делать, у него внутри наворочен железный транслятор всего этого добра в РИСК-микрокоманды (с конвеером соответствующей длины), кэш микрокоманд и еще хрен знает чего. Или того хлеще - ПРОГРАММНАЯ эмуляция этой системы команд (причем, с приемлимым уровнем быстродействия!). Огромные затраты на разработку, лишние плозади кристалла, охлаждение и энергию, наконец...

И весь этот маразм - следствие чего? Правильно, доминирования винды. И абсолютной непереносимости не только кода, но и документов. Микрософт не только привязал людей к виндам, он привязал их к платформе . На определенном этапе наличие промышленного стандарта - хорошо, но на данном этапе это только тяготит.

Д.Ж.> К счастью, на подавляющую часть процессоров «перетащено пол-винды», исключений нет почти. И это простой и наглядный пример образцовой переносимости, best portability, если понятнее.
Простите? На скольки процессорах сейчас работает винда?

Д.Ж.> Вопрос, сколько времени потребуется MS, чтоб внедрить OLE в Linux, когда там появятся приложения, достойные OLE?
Очевидный ответ - бесконечность. :)

Татарин>> Это не "переносимость", это совершенно строгое наоборот .
Д.Ж.> Вы, как и многие, путаете хорошее и лучшее.
Эээ... ИМХО, это Вы, к сожалению, не совсем адекватно трактуете понятие "переносимость". Это вовсе не когда документ читается на 100% компьютерах одного типа (пусть даже такие компьютеры составляют 95% компьютеров вообще)...

Д.Ж.> Понятная трудность, надо медитировать! Простой вопрос: лучшее хорошо? Мой ответ: кому — как, но я ценю лучшее. Всюду, где есть OLE службы, есть .DOC. Кое-где, где нет OLE, можно использовать .DOC.
"Жигуль"-2101 проедет везде, где есть асфальт и 92-й бензин. Он даже проедет кое-где там, где нет асфальта. :)
Значит ли это, что ВАЗ-2101 - вездеход с прекрасной проходимостью?
(на секунду проигнорируем тему, насколько ему нужна проходимость, сосредоточимся на данном вопросе: "да"? или "нет"?)

Татарин>> При этом функциональность OLE можно организовать и без самого OLE. Но и при наличии сходной функциональности , Вы не сможете полноценно прочитать DOC на системе без COM.
Татарин>> Одного этого момента вполне достаточно, чтобы ответить на вопрос о переносимости вполне однозначно.
Д.Ж.> Так думал я году в 1995, когда компьютерная пресса «тёрла тему». После пересмотрел своё заёмное «всезнайство», стал больше обращать внимание на то, что происходит, а не на то, о чём говорят.
Давайте вместе обратим внимание на то, что происходит. Это ведь на самом деле интересно. А что происходит?
Вы можете прочитать док-файл с картинками из "Корела" под винду на Маке?

...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  
Это сообщение редактировалось 20.06.2005 в 10:51
1 2 3 4 5 6

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru