Кого-нибудь интересует формат файлов Оракла или дибиту кроме их разработчиков?
Не знаю, как в настоящее время, но в конце90-х того API, что IBM предоставлял разработчикам, было более, чем достаточно. Не помню, чтобы возникали какие-нибудь вопросы в связи с недостатком информации. Мало кто так подробно и тщательно подавал информацию не только тогда, но и сегодня. Да, был децел «недокументируемых» вещей, но в подавляющем большинстве своем это были депрекаты, удаление которых на тот момент было нецелессообразным. Причем эти «недокументированные» просто не находились в онлайн-системе электронной подсказки visual age из ide по хоткею. Тем не менее, информация о них присутствовала на каком-нибудь сиди из комплекта документации или была откомментирована в заголовочном файле.
Зачем и кому может понадобиться информация о формате файлов, можно только пофантазировать — физический формат данных вообще в рамках среды IBM ничего не значил — поддерживалась настоящая объектная модель в том самом виде, в котором она изначально была задумана. Все вопросы совместимости и переносимости, включая межплатформенный обмен, решались на уровне абсолютно открытых решений и стандартов — в рамках среды IBM это был SOM (System Object Model), вне ее — CORBA. То, что позже появилось у микрософт под названием COM, это крайне криво реализованное подмножество технологий SOM. Причем спецом реализованное так, чтобы огородиться от остальных.
Только на уровне некоторых концепций. NT была микроядерной, полуось — монолитной. NT была 32-разрядной, OS/2 была 32-разрядной только выше ядра — все драйвера аппартного уровня были 16-разрядными начиная от варпа 3.0 вплоть до авроры 4.5. Даже термин был такой «thunking» — передача управления между 16- и 32-разрядными сегментами кода. Хорошо это или плохо, не ясно до сих пор — код закрыт, все засекречено. Тем не менее современные процессоры 16-разрядный режим поддерживают, судя по форматам дескрипторов шлюзов.
В конце 90-х начали использовать Lotus Notes, из приложений которого выбросили возможность форматирования текста поль зователем, и развили в мощное корпоративное приложение. Вы просто набираете тексты в формах, решаете, что выделить, и не заботитесь, как он будет выглядеть на бумаге. В отчете, который выполняется по определенным стандартам, не требуется пользовательское форматирование — достаточно текста, а формой занимаются специально обученные люди.
Когда ставили задачу, одним из требований было, чтобы документ, прошедший двумя путями правок через полсотни человек, выглядел на выходе абсолютно одинаково.
Мало каши ели. Хотя soffice такое же дерьмо, как и винворд. IBM в свое время на корпоративном уровне отказались вообще от использования вордпроцессоров — заманало форматирование документов через задницу — каждый жук и жаба считает своим дологом что-нибудь выделить в тексте, который он скопипастил или набрал, и ткнуть в одну из трех кнопок по своему разумению.
Все, что на xml, не более, чем раскрученная мода. У этой «технологии» нет абсолютно никаких преимуществ над джейсон-подобными форматами, даже наоборот — попробуйте распаковать odt или docx и что-нибудь поправить, да хотя бы найти.
xml планировался вместо flex+bison, которые нынешние «програмизды» не в состоянии освоить в силу массовой необразованности.
Ее практически с нуля делали, в отличие от Win'9x. Она и называлась «Виндовс-новые технологии» поэтому. Там контейнер полностью свой, внешне похож на тот, что был у Win'3 но совершенно беспонтовый. Даже драг-н-дроп толком не поддерживался.
Вы нам тут расскажите еще, что микрософт разработал ексель. Последняя коза знает, что она его купила уже готовый и практически ничего нового за все это время туда не добавила. Куплен эксель был в рамках многоходовки по отжатию ништяков — приватизации прибылей и национализации убытков, которую провернула команда под крышей конгресса. В те времена конкурент экселя 123 был куда производительнее и функционально мощнее. Умел на 386/486 машине через дос-экстендер заюзать всю доступную память — 16 Мбайт. Потом микрософт купила ексель, айбиэм купил лотус. Потом айбиэм убил 123, передав все наработки в микрософт, как это было и с полуосью. Вклад микрософт в эксель состоит в засовывании туда OLE. Чтобы таблицы можно было курочить не вылезая из мсворда.
Масштабировав на порядки методику ибм-микрософт по приватизации прибылей/национализации убытков, НАСА передала свои технологии вместе с несколькими тысяч живых инженеров Илоне Маск. В результате вся инженерная братия была поставлена перед выбором — перейти к Илоне в частную контору и лишиться государственной пенсии, либо уволиться по сокращению.
В случае ибм-микрософт колическтво людей ограничивалось парой сотен. Кстати, если кто забыл, разработчик, который работал над контейнером в PM и GDI остался в IBM, в резульате чего вплоть до 98 включительно виндовсы были 16-разрядными — исходников не передали, поэтому приходилось линковать виндовысы со старым 16-разрядным объектным кодом от виндовсов 3.11.
Прологи и эпилоги для процессов, которые Вы внезапно обнаружили, существуют со времен первых мультизадачных ОС. Обычно о том, для чего это нужно, студенты соответсвующих специальностей изучают в курсе осперационных систем и системного программирования. Если посещать лекции по теории этих самых ОС, вопросов такого рода не возникнет. Дело в том, чтобы понять, что там и для чего, нужно изучить код планировщика. Без этого обсуждать crt никакого смысла не имеет. Всю эту «телеметрию» планировщик использует, чтобы принимать решения сугубо по Вашей программе, поэтому нет никакого смысла ее держать в ядре — достаточно юзерспейса.
Относительно MSVC — при разработке на C/C++ для виндовсов это наихудший вариант выбора. Стандарты поддерживаются слабо, куча расширений, ухудшающих переносимость, очень неудобная IDE, скрывающая детали процесса компиляции и сборки, куча особенностей, потакающих программистам в их желаниях не комментировать изменения, плохая поддержка юникода, несогласованность в локалях даже в пределах этой самой MSVC.
При этом в мире виндовсов есть отличные компиляторы, системы сборки проектов и редакторы исходных кодов, обладающие функциональностью, превышающей дешевое IDE MSVC кратно. Предоставляя крайне низкий уровень вхождения, свойственный основной массе школоты, MSVC выполняет главную роль в процессе огораживания и сегрегации программистов на индусов и гуру.
Даже на одной аппаратной платформе, например x86_64 (ia32e), разные ОС по разному интерпретируют резиновые целочисленные типы, введенные в С/C++ в качестве базовых. Резиновые они потому, что стандарт не определяет их длины, он только вводит отношения
sizeof(short int) \le sizeof(int) \le sizeof(long int) \le sizeof(long long int)
Это значит, что не исключается случай, когда все эти типы будут иметь одинаковую длину.
Разумеется, использовать эти типы можно лишь в том случае, если программа ничего не выводит и не выводит, потому что даже одна и та же программа, скомпилированная на разных платформах и/или разными компиляторами не сможет ввести данных, которые она вывела. Чтобы преодолеть это были введены жесткие типы, которые определены в stdint.h (). Эти типы локально настраиваются на соответсвующие резиновые в каждом конкретном случае установки компилятора на конкретную платформу, если таковые там присутствуют.
Как только возникает необходимость в бинарном выводе/вводе, эти типы должны использоваться безусловно. Они обладают абсолютной переносимостью, поскольку описываются в обязательной части стандарта.
Кстати, аналогичная ситуация может случиться при выводе/вводе символов — байт, вопреки расхожему мнению, это не 8 бит, а минимальная порция данных в адресуемой оперативной памяти. Так что запросто может случиться, что char может занимать, например, 12 бит.
В этой связи гораздо более полезно читать стандарт, чем толстые книги, переиздаваемые чуть ли не каждый год. Кстати, стандарт нужно читать не весь, а только до приложений, поскольку в приложения попадают ангажированные тексты спонсоров, пытающиеся возглавить то, что не удается разрушить.
Не знаю, как в настоящее время, но в конце90-х того API, что IBM предоставлял разработчикам, было более, чем достаточно. Не помню, чтобы возникали какие-нибудь вопросы в связи с недостатком информации. Мало кто так подробно и тщательно подавал информацию не только тогда, но и сегодня. Да, был децел «недокументируемых» вещей, но в подавляющем большинстве своем это были депрекаты, удаление которых на тот момент было нецелессообразным. Причем эти «недокументированные» просто не находились в онлайн-системе электронной подсказки visual age из ide по хоткею. Тем не менее, информация о них присутствовала на каком-нибудь сиди из комплекта документации или была откомментирована в заголовочном файле.
Зачем и кому может понадобиться информация о формате файлов, можно только пофантазировать — физический формат данных вообще в рамках среды IBM ничего не значил — поддерживалась настоящая объектная модель в том самом виде, в котором она изначально была задумана. Все вопросы совместимости и переносимости, включая межплатформенный обмен, решались на уровне абсолютно открытых решений и стандартов — в рамках среды IBM это был SOM (System Object Model), вне ее — CORBA. То, что позже появилось у микрософт под названием COM, это крайне криво реализованное подмножество технологий SOM. Причем спецом реализованное так, чтобы огородиться от остальных.
Когда ставили задачу, одним из требований было, чтобы документ, прошедший двумя путями правок через полсотни человек, выглядел на выходе абсолютно одинаково.
xml планировался вместо flex+bison, которые нынешние «програмизды» не в состоянии освоить в силу массовой необразованности.
Масштабировав на порядки методику ибм-микрософт по приватизации прибылей/национализации убытков, НАСА передала свои технологии вместе с несколькими тысяч живых инженеров Илоне Маск. В результате вся инженерная братия была поставлена перед выбором — перейти к Илоне в частную контору и лишиться государственной пенсии, либо уволиться по сокращению.
В случае ибм-микрософт колическтво людей ограничивалось парой сотен. Кстати, если кто забыл, разработчик, который работал над контейнером в PM и GDI остался в IBM, в резульате чего вплоть до 98 включительно виндовсы были 16-разрядными — исходников не передали, поэтому приходилось линковать виндовысы со старым 16-разрядным объектным кодом от виндовсов 3.11.
Относительно MSVC — при разработке на C/C++ для виндовсов это наихудший вариант выбора. Стандарты поддерживаются слабо, куча расширений, ухудшающих переносимость, очень неудобная IDE, скрывающая детали процесса компиляции и сборки, куча особенностей, потакающих программистам в их желаниях не комментировать изменения, плохая поддержка юникода, несогласованность в локалях даже в пределах этой самой MSVC.
При этом в мире виндовсов есть отличные компиляторы, системы сборки проектов и редакторы исходных кодов, обладающие функциональностью, превышающей дешевое IDE MSVC кратно. Предоставляя крайне низкий уровень вхождения, свойственный основной массе школоты, MSVC выполняет главную роль в процессе огораживания и сегрегации программистов на индусов и гуру.
sizeof(short int) \le sizeof(int) \le sizeof(long int) \le sizeof(long long int)
Это значит, что не исключается случай, когда все эти типы будут иметь одинаковую длину.
Разумеется, использовать эти типы можно лишь в том случае, если программа ничего не выводит и не выводит, потому что даже одна и та же программа, скомпилированная на разных платформах и/или разными компиляторами не сможет ввести данных, которые она вывела. Чтобы преодолеть это были введены жесткие типы, которые определены в stdint.h (). Эти типы локально настраиваются на соответсвующие резиновые в каждом конкретном случае установки компилятора на конкретную платформу, если таковые там присутствуют.
Как только возникает необходимость в бинарном выводе/вводе, эти типы должны использоваться безусловно. Они обладают абсолютной переносимостью, поскольку описываются в обязательной части стандарта.
Кстати, аналогичная ситуация может случиться при выводе/вводе символов — байт, вопреки расхожему мнению, это не 8 бит, а минимальная порция данных в адресуемой оперативной памяти. Так что запросто может случиться, что char может занимать, например, 12 бит.
В этой связи гораздо более полезно читать стандарт, чем толстые книги, переиздаваемые чуть ли не каждый год. Кстати, стандарт нужно читать не весь, а только до приложений, поскольку в приложения попадают ангажированные тексты спонсоров, пытающиеся возглавить то, что не удается разрушить.