Как стать автором
Обновить

История Visual Studio. Часть II

Время на прочтение 4 мин
Количество просмотров 1.6K
Автор оригинала: Rico Mariani
От переводчика
Это вторая часть повествования Rico Mariani. Начало было здесь и здесь.

Visual C++ 2.0 (кодовое имя Dolphin, Дельфин) был очень амбициозным проектом. Мы были счастливы выпустить Visual C++ 1.0, но там было несколько моментов, которые абсолютно нас не устраивали. Одним из них — наиболее, пожалуй, важным — было то, что работа с окнами являлась сущим кошмаром. Visual C++ 1.0 использовала стандартный многооконный MDI-интерфейс для всех окон, включая такие вещи, как окно регистров, окно отслеживания значений, окно вывода и т.д. В итоге эти ключевые инструменты просто тонули в потоке окон, открытых редактором и отладчиком. Это все было очень неприятно.

Давайте, однако, сперва поговорим о том, что происходило до того, как мы начали с этим бороться.

Команда, разрабатывавшая компилятор Basic выкатила еще один полноценный релиз, но он не был интегрирован с оболочкой Visual C; его основной задачей было создание самостоятельных исполняемых файлов. С другой стороны, команда разработчиков Fortran’а выпустила первую версию Fortran Powerstation, бывшую чудом в своем отношении. Этот продукт по полной использовал знакомый уже механизм «DOS Extension», некоторые трюки, позволявшие отлаживать в GUI-режиме, а так же улучшенную систему проектов. То была вполне современная по тем меркам система разработки. Разработка Cobol продвигалась своим размеренным шагом. И давайте не будем забывать о MASM и о малоизвестном ассемблере под названием ML, у которого, по-моему, был всего один релиз, стоивший, однако, многого. ML был итогом рационализации правил синтаксического разбора MASM, но нам, в конце 1993 года, не так уж был нужен еще один макроассемблер.

Раз уж мы говорим про 1993 год, то стоит упомянуть, что к тому моменту вышли новые версии Microsoft Office с классным нововведением: стыкуемые панели инструментов. Мы решили, что они будут решением всех наших UI-проблем в Visual C: просто добавить панели инструментов и разрешить стыковать окна. Действительно удобно.

Я говорю «мы решили», но на деле основа для этого была заложена командой App Studio. Задумки тех парней шли еще дальше в своей амбициозности.

В прошлом наша IDE была набором интегрированных приложений, но нам хотелось изменить ситуацию. Планировалось, что в рамках единой оболочки будут работать редактор ресурсов и форм, текстовый редактор, система проектов, отладчик и справка. И в довершение все это должно было быть модульным, чтобы другие языки, такие как Fortran, Basic или Cobol, могли встраиваться в эту оболочку. Последняя должна была предоставлять набор базовых служб, а так же обеспечивать поддержку меню, панелей инструментов и прочего. Звучит знакомо, не правда ли?

Но и это еще не все!

Помимо всего прочего, мы хотели иметь средства разработки для Macintosh. Кто-нибудь помнит о WLM? Я сам написал с ее помощью несколько программ. Компиляторы для PowerPC и 680x0, удаленная отладка — не проблема. И да, не забывайте о поддержке MIPS и Alpha.

Если уже вы думаете, что мы сошли с ума, то зря — я еще не закончил.

Пока мы надо всем размышляли, код среды Visual C++, написанный на C, должен был быть предварительно портирован на C++, что и было сделано — и мы исправили кучу ошибок в процессе. Кроме того, из обычного приложения он должен был превратиться в библиотеку MFC, которую можно было бы использовать в новой оболочке. И весь продукт вообще говоря должен был при этом работать, поскольку Visual C++ 2.0 должен был быть в состоянии скомпилировать и отладить сам себя.

И, само собой разумеется, что мы планировали выпустить новые версии библиотек (MFC 3.0, к примеру), поскольку нам все равно надо было править их код для портирования под 32 бита.

И я все еще не закончил.

У нас были большие планы насчет «Edit and Go», «упрощения OLE» и «файлы в сторону!». Последнее подразумевало, что мы планировали как можно сильнее упростить и ускорить цикл разработки, упростить механизм OLE и всего такого, и облегчить навигацию по исходному коду. Я добавил много новых возможностей — на этот раз связанных исключительно в C++ — в систему навигации; мы сделали много интересного в связи с отладкой по каналам OLE RPC, добавили окно «Automatic Watch». В тот момент я был ведущим программистом в команде разработки отладчика, и поэтому так ясно все помню.

Думаете, достаточно для одного релиза? Нет.

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

Для разных языковых версий мы планировали иметь один и тот же бинарник, а локализацию осуществлять ресурсными файлами. Английская и Японская версии были идентичными! Насколько я знаю, до того момента никто ничего подобного не делал.

И, как вишенка на вершине этого «торта нововведений», было следующее. Вы, возможно, слышали о такой операционной системе, как Chicago, вышедшей, однако, под названием Windows 95. Так вот нашему продукту уготована была судьба стать SDK для этой операционной системы. Это означало, что надо было срочно исправлять кучу ошибок, поскольку Windows 95 была гораздо более непростительной по сравнению с Windows NT.

Уфф, все это выглядит как сумасшествие, но на деле мы выполнили гораздо больше работы. Для 16-битных средств мы с тех пор выпускали лишь сервисные релизы, а для 32-битных платформ делали совершенно чумовые демонстрации: у нас же была по-настоящему интегрированная среда разработки!

В то время нам выпала небольшая передышка. 32 бита были горячей новостью, Visual C++ 1.52 была достаточно хорошей сама по себе, тот другой поставщик средств разработки тратил много времени на поддержку OS/2, о которой мы думали как об операционной системе, теряющей свое стратегическое преимущество. Но демонстрации Delphi — это было что-то! Но нам было что противопоставить, поскольку команда Visual Basic тоже не сидела без дела: 32-битные средства разработки и вся эта история с OCX. В итоге получилась классная экосистема.

Я думаю, что Visual C++ 1.0 была самой технически сложной IDE из тех, что нам приходилось выпускать. Сложной она была потому, что нам приходилось творить невероятные вещи, чтобы заставить ее работать на операционных системах того времени. Но Visual C++ 2.0 была столь же, если не более, важной средой — так сильно мы продвинулись в технологическом плане. Мы потратили на разработку много времени, а впереди нас ждали версии 2.1 и 2.2.

Теги:
Хабы:
+20
Комментарии 15
Комментарии Комментарии 15

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн