2. Межплатформенные возможности. Хотя первые реализации среды .NET Compact Framework предназначаются для операционных систем Pocket PC, Windows CE и Microsoft Smartphone, сама она была спроектирована таким образом, чтобы при необходимости ее можно было переносить на другие платформы. Одним из практических следствий такого проектного решения является тот факт, что все вызовы из .NET Compact Framework, затрагивающие базовую операционную систему, осуществляются через единый интерфейс — PAL (platform abstraction layer — уровень абстракции платформы). Это упрощает учет зависимостей базовой операционной системы в процессе проектирования и облегчает задачу переноса среды времени выполнения и библиотек в другие операционные системы. Отсюда вовсе не следует, что перенос программного обеспечения в другую операционную систему не будет представлять никакой сложности лишь по той единственной причине, что этот аспект был учтен в процессе проектировании .NET Compact Framework. Например, в некоторых операционных системах часть функциональных средств, на которые отображается PAL, может отсутствовать, в связи с чем необходимо, чтобы PAL для этой платформы реализовал такие возможности, как многопоточное выполнение, управление памятью, создание графических объектов или иную функциональность, которую целевая операционная система предоставить не может. Решение подобной задачи может оказаться весьма непростым, но оно сводится к хорошо известному и проверенному процессу, который не был упущен из виду в процессе проектирования .NET Compact Framework.
3. Мощные возможности клиентской стороны, включая поддержку рисования и форм, выполнение функций клиента Web-служб и предоставление модели доступа к данным, обладающей широкими возможностями. Мы пришли к выводу, что для того, чтобы среда времени выполнения для устройств воспринималась разработчиками прикладных программ как конкурентоспособная, она должна удовлетворять нескольким ключевым требованиям. Прежде всего, требовалось, чтобы она обеспечивала создание пользовательских интерфейсов с широким набором возможностей, предоставляющих современные элементы управления, к которым разработчики уже успели привыкнуть (например, сетки, списки и древовидные представления). Далее, она должна была обеспечивать ту же простоту использования Web-служб приложениями, что и в случае .NET-приложений, выполняющихся на настольных компьютерах (то есть делать эту задачу тривиальной) Кроме того, она должна была предоставлять современную, расширяемую модель для работы с базами данных (ADO.NET), обеспечивающую самые широкие возможности. Поддержка всех вышеперечисленных средств была реализована в библиотеке объектов .NET Compact Framework.
4. Низкие требования к объему установленной на устройстве и занимаемой платформой памяти. Для того чтобы иметь практические шансы пробиться на массовый рынок устройств с типичными размерами образов ПЗУ (ROM images), наша система должна была занимать не более 2 Мбайт памяти. Возможность размещения в образе ПЗУ с типичным для массовых устройств объемом рассматривалась нами как неотъемлемая характеристика платформы для мобильных устройств. Чтобы облегчить решение этой задачи, не менее важно было обеспечить возможность установки платформы в файловых системах ОЗУ существующих устройств таким образом, чтобы оставалось еще достаточно много места для приложений и данных. Для решения обеих задач требовалось, чтобы необходимый для платформы объем памяти, используемой на устройстве, не превышал 2 Мбайт. Кроме того, .NET Compact Framework должна была сохранять работоспособность и в средах, в которых действуют жесткие ограничения в отношении доступных объемов ОЗУ. Эти цели значительно отличаются от тех, которые ставились при разработке платформы .NET Framework для настольных компьютеров и серверов, ориентированной на выполнение в условиях сред с достаточными запасами ресурсов, когда достижение максимальной пропускной способности имело намного более высокий приоритет по сравнению с минимизацией объема памяти, занимаемого платформой.
5. Требовалось предоставить практическую поддержку, по крайней мере, двух языков .NET — С# и Visual Basic .NET. Хотя с теоретической точки зрения коды на любом из языков программирования, ориентированных на стандартизированное подмножество байтовых кодов IL и стандартизированное множество библиотек программ .NET Compact Framework (ЕСМА и ISO), должны быть способными к компиляции для выполнения на платформе .NET Compact Framework, это необходимо было подтвердить на практике путем фактической реализации нескольких языков. Мы выбрали языки С# и Visual Basic, поскольку они являются наиболее популярными языками .NET. Как и в случае варианта реализации для настольных компьютеров и серверов, это подразумевало включение в .NET Compact Framework библиотеки времени выполнения Microsoft.VisualBasic.DLL.
6. Платформа должна была служить удобной заменой собственных кодов для большинства приложений коммерческого, научного, производственного и развлекательного характера. Было очень важно, чтобы разработчики программного обеспечения для настольных компьютеров и серверов не испытывали никаких неудобств в работе или ограничений с точки зрения синтаксиса при переходе к платформе .NET Compact Framework. Если бы эта цель не была достигнута, то количество разработчиков указанной категории, пожелавших совершить такой переход, было бы значительно меньше, нежели то, на которое мы рассчитывали. Такой урок можно было извлечь из предыдущих попыток создания сред времени выполнения, ориентированных на устройства, которым не удалось достигнуть "критической массы". Как проект Embedded Visual Basic компании Microsoft, так и аналогичные проекты других компаний не оправдали ожиданий, поскольку в них не был предусмотрен ряд ключевых возможностей, которые обычно используются при создании программного обеспечения для настольных компьютеров и серверов или в случае применения собственных кодов при разработке программного обеспечения для устройств. Мы исходили из того, что при любой успешной замене подхода, основанного на использовании собственных кодов, любой другой предлагаемый подход должен поддерживать следующие возможности:
• Арифметические операции с плавающей точкой, вычисление тригонометрических и трансцендентных функций. С точки зрения разработчиков для настольных компьютеров и серверов включение этих средств представляется само собой разумеющимся, но с позиций разработки программного обеспечения для устройств это отнюдь не самоочевидно. В силу причин, обусловленных факторами размеров, стоимости и энергопотребления, процессоры многих мобильных устройств не имеют встроенной поддержки арифметических операций с плавающей запятой. Вместо этого данная функциональность обеспечивается библиотеками программ, выполняющимися поверх процессоров. Мы пришли к выводу, что хотя большинство алгоритмов основаны на целочисленной арифметике, почти для любого реального приложения всегда найдутся случаи, когда без операций с десятичными числами обойтись невозможно. Рассмотрение всего того, что может потребоваться для проведения финансовых расчетов (например, с целью определения размеров процентных ставок или построения диаграмм), научных расчетов или же расчетов, связанных с играми, убедило нас в том, что попытка заменить использование собственных кодов для мобильных устройств подходом, основанным на управляемом коде, может быть успешной лишь в том случае, если при этом будет обеспечена поддержка операций с плавающей запятой.
• Все базовые элементы языков программирования и широко используемые библиотеки программ. Мы не могли исключить ни такие предоставляемые любым современным объектно-ориентированным языком программирования возможности, как механизм наследования или обработка структурных исключений, ни такие низкоуровневые библиотечные функции, как функции ввода-вывода файлов, основанные на потоках. Разработчик рассчитывает на то, что эти средства программирования будут всегда находиться у него под рукой, и в случае их отсутствия у него возникает чувство, будто его лишили самого необходимого, тогда как он должен всегда работать в комфортных условиях и быть во всеоружии.
7. Возможность доступа к средствам базовой операционной системы, если в этом возникает необходимость. Осознав всю важность фактора межплатформенной переносимости, мы поняли, что разработчики не должны быть ограничены доступом только к тем средствам, которые были нами первоначально запланированы. Наша основная задача заключалась в том, чтобы предоставить разработчикам удобное подмножество средств платформы .NET Framework, предназначенной для настольных компьютеров, которое было бы пригодным для создания тех видов приложений, о которых говорили сами разработчики, однако можно было предполагать, что неизбежно возникнут случаи, когда предусмотренной нами функциональности разработчикам окажется мало. Какой смысл в том, чтобы предоставлять разработчику возможность создать 90 процентов мобильного приложения с использованием управляемого кода, если он зайдет в тупик из-за недостатка необходимых средств при создании остальных 10 процентов приложения. Поэтому предоставление разработчикам удобного способа, обеспечивающего возможность вызова собственных кодов, было сочтено важным фактором, позволяющим разработчикам обойти трудности, связанные с отсутствием в .NET Compact Framework той или иной функциональности. Вот четыре примера: в настоящее время вызовы собственных кодов (или поставляемых независимыми разработчиками библиотечных функций, служащих оболочками для вызовов собственных кодов) нужны для явного управления сетевыми соединениями, набора телефонных номеров, воспроизведения звука и доступа к API-интерфейсам шифрования; эти функциональные возможности требуются далеко не каждому разработчику, но те, кому они действительно необходимы, будут чувствовать себя стесненными в своих действиях, если не смогут получить доступ к указанным средствам из-за невозможности использования вызовов собственных кодов
