От Win32 до Какао: Ще бъде потребител на Windows преобразуване в Mac OS, част II

Как можеше Питър Брайт да се изхвърли всичко това за минимализма на MacOS? Той обича твърде много лилавия цвят, за да го направи, нали?Увеличи / Как можеше Питър Брайт да се откаже от всичко това за минимализма на MacOS? Той обича твърде много лилавия цвят, за да го направи, Етан Милър / Гети изображения Преди десет години около това много време – от април до юни 2008 г. – нашия безстрашен гуру на Майкрософт Питър Брайт очевидно имаше криза на идентичността. Може ли този компютър през целия живот потребител наистина са били избутани до ръба? Обмисляше ли преминете към … Mac OS?!? Докато нашият персонал се надява да се радва на по-малко стресов ден на паметта тази година, през уикенда сме възобновяване на тази серия от три части, която се удвоява като екзистенциал дилема на операционната система около 2008. Част втора се проведе на 4 май 2008 г., и по-долу изглежда нередактиран.

Миналия път описах как Apple обърна неуспеха си да разработи модерна ОС в голям успех. Покупката на Neх T даде на Apple a съвместима с buzzword ОС със здравословна екосистема с високо качество приложения на трети страни. Междувременно, Microsoft продължаваше да се занимава с Windows XP. Макар и технически надежден, той е прострелян с решенията mademore от десетилетие по-рано 16-битов Windows.

През 2001 г., когато беше пуснат XP, това не беше толкова голяма работа. Най- първите две или три версии на Mac OS X бяха проблемни, да кажа най-малкото. Изпълнението беше слабо, имаше проблеми със стабилността и версия 10.0 може би дори функцията не е завършена. Едва тогава в началото на 2002 г., че Apple дори направи Mac OS X по подразбиране ОС на нова Mac-ове; през първите няколко месеца от живота си XP беше против “Класически” Mac OS 9.

Допълнителна информация

От Win32 до Какао: Преобразуването на потребител на Windows в Mac OS X

Но OS X не стоя неподвижно. Apple пусна поредица от актуализации в бърза последователност, укрепвайки платформата с нови функции като Core Audio, Core Image, Core Data и Quartz Extreme, и осигуряване на висококачествени приложения, които използваха тези способности. През цялото това време самият XP стоеше неподвижно. Основната Windows платформа не се промени между 2001 г. и края на 2006 г.

Въпреки че самият XP е по същество непроменен, Microsoft се опита да се създаде модерна, привлекателна платформа за бъдещо развитие. Тази платформа, разбира се, беше .NET и наблюдатели ще прочетат забелязах, че не го споменах в първа част. Това беше не случайност, тъй като цялата .NET история заслужаваше по-задълбочена Преглед.

Microsoft опитва модерността

През 2002 г. Microsoft пусна .NET Framework. Мрежата Рамката беше нова марка. Той е проектиран и внедрен от земята нагоре. Можеше да е чисто и последователно и ортогонални и с ясен дизайн и мощни концепции. Може би са изход от труса, който е Win32.Това можеше са осигурили спасение – среда без 16-битово наследство решения, с мощни API, наравно с това, което Apple имаше developed.Най-  .NET Framework stackEnlarge / The .NET FrameworkstackWikimedia Commons

Със сигурност беше популяризиран като такъв. .NET беше натиснат като бъдещето, начинът, по който ще се случи цялата разработка на Windows в бъдеще. Плановете станаха доста агресивни; в ОС, която трябваше да успее Windows XP, новата функционалност ще бъде достъпна не чрез Win32 но чрез .NET, което означава, че всеки разработчик, който иска да използва най-новите и най-добрите функции на ОС трябва да се впуснат в това смел нов свят.

Така че .NET можеше да бъде крачка в 21 век. Може би са били, но не е било. Технически. .NET беше добре. Виртуалното машинната инфраструктура беше доста здрава, представянето беше разумен, а C # беше адекватен (ако не е точно новаторски) език. Но библиотеката – .NET “API”, използвана за толкова разнообразни задачи като писане на файлове, четене на данни от бази данни, изпращане информация по мрежа, анализиране на XML или създаване на GUI – the библиотеката е съвсем друга история.

Библиотеката е изключително лоша. Тя е опростена и негъвкава и в много отношения доста ограничен. Вижте, .NET има голям проблем: целевата му аудитория. .NET беше предназначена да бъде обединена платформа, която всички разработчици биха използвали – в края на краищата, ако се изискват нови функции на ОС .NET, широко напречно сечение на разработчиците биха го използвали. Проблемът е, че не всички разработчици са създадени равни. Като гледам различните видове разработчици там, можем да разберем защо .NET е такъв, какъвто е. Това, което следва, не е изчерпателна таксономия от всички странни и прекрасни породи програмист, но по-скоро а груба таксономия на някои от ключовите видове.

Нашият любим вид  стар суинг кампания. Our favorite kind ofold campaign swag.

Таксономия на разработчиците

На едно ниво имате хора, които основно са бизнес анализатори; те използват Access или Excel или VB6 за писане на данни анализиране / численост на приложения. Тези неща са огромни важен в света на бизнеса, напълно неразбиращ за всеки друг, и хората, които ги пишат, всъщност не са „програмисти“. Имам предвид, те са в смисъл, че пишат програми, но те са не се интересува особено от програмиране или нещо подобно. Те не се интересуват наистина от качеството на библиотеките и инструментите те използват; те просто искат нещо достатъчно просто, което могат вземете го без много трудности. Никога няма да напишат най-добрият код или най-добрите програми в света; те няма да са елегантни или добре структурирана или красива за гледане. Но те ще работят. В исторически план, както казах, това са хората, които имат достъп направено за. Достъпът е чудесен инструмент, доста несравним. Разбира се, това е отвратен двигател на базата данни с отвратителен език за програмиране, но властта, която дава на тези хора е огромна. Така че Access и VB6 и Excel макросите са там, където е за тези момчета.

На следващото ниво имате разработчиците на пътешественици. Сега тези хората не са “бизнес” хора – те са правилни програмисти. Но това е просто работа и те ще са склонни да се придържат към това, което знаят а не да се опитвате да направите нещо по-добро. Може да са малко повече взискателни за техните инструменти от видовете бизнес, но те са няма да излизат от пътя си, за да наберат нови умения и да се учат нови неща. Те могат да използват VB6 или Java или C # или каквото и да е; itвсъщност няма значение за тях, тъй като те ще използват каквото им предложи най-добрите възможности за заетост във всеки даден момент. Техният код вероятно ще изглеждат повече или по-малко еднакви, независимо какво. Те са няма да научите идиомите на какъвто и да е конкретен език използване, защото няма нужда, така че просто не е за тях.

Основна характеристика на тези разработчици е, че през повечето време, те пишат софтуер за “предприятие”. Това не е софтуер ще седне на рафт в магазин за някой, който да купи; това е обичай приложения за подпомагане на някакъв бизнес процес или друг. Истина да бъде казано, вероятно няма да е нужно да изглежда много хубаво или да работи много добре; просто трябва да свърши работата. Със софтуера на предприятието, често можеш да се измъкнеш с тромава програма, защото хората които го използват, всички са обучени какво да правят. Ако правите X прави приложението срив, това е добре – те могат просто да бъдат обучени да не правя повече X.

Въпреки често посредственото качество на софтуера хората пишат, те са група, която е изключително важна Microsoft. Тези програми са ключова част от блокирането на платформата че Microsoft жадува. Ако една компания има някои критични за бизнеса потребителско приложение, написано на Visual Basic 6, тази компания не е ще въведе Linux на своите настолни компютри; тя е в капан Windows.

На крайно ниво имате съвестните разработчици. тези са хора, които се интересуват от това, което правят. Може да пишат бизнес приложения някъде (въпреки че вероятно го мразят, освен ако те са в екип от съмишленици), но вероятно повече вероятно те пишат програми по свое време. Те искат научете какво е готино и ново; те искат да направят правилното нещо техните платформи; те искат да научат нови техники и по-добре решения на съществуващите проблеми. Може да използват необичайно платформи за разработка или може да използват C ++, но те ще бъдат писане на добър код, подходящ за техните инструменти. Ще внимават Указания за потребителския интерфейс (и ги разбивате само когато е подходящо) те ще използват нови функции, които платформата може да предложи; ще тласкат нещата към лимитът. По добър начин, разбира се.

В света на pre-.NET това не беше голям проблем. Theпървата група използва макроси на Excel и Access; втората използвана група Visual Basic 6 и последната група могат да използват C ++ или каквото и да е носенето на барети с фънки скриптов език по онова време беше а-ла режим. Всичко това се получи добре, защото едно от малкото хубави неща Win32 е, че е проектиран за C. C в много отношения е много прост език, а също така е и повсеместен език. Като следствие от това, почти всеки друг език за програмиране създадени през последните няколко десетилетия могат, по един или друг начин, да се обадят C API.

„.NET можеше да бъде крачка в 21 век можеше да бъде, но не беше. ”

.NET не е така. Въпреки че .NET може да извиква C API (точно като всичко останало може), истинската цел е всички програмиране да пребивават в .NET света. .NET е предназначена да бъде цялата платформа, с всички различни езици, които хората използват, живеещи вътре в .NET среда. Ето защо .NET има API за задачи като четене и писане на файлове; в света .NET не сте предназначени да използвате Win32 за да направите тези неща, вие сте предназначени да използвате .NET съоръжения за правене тях. Все още е възможно да използвате различни езици с .NET (в всъщност, по-лесно е, отколкото беше в пред-.NET дните). Точно сега всички езици използват общ набор от .NET API за рисуване прозорци на екрана или запазване на файлове или заявка на бази данни и т.н. На.

Защото сега всичко трябва да живее “в” .NET света, .NET трябва да бъде всичко на всички хора. Ами всъщност това не е вярно. Опитва се да бъде достатъчно добър за първия и втория вид програмист. Третият тип – добре, просто ги игнорирайте. Те също са изискване така или иначе. Те са тези, които се грижат за своите инструменти и разстройте се, когато API е лошо проектиран. Те са тези, които забележете несъответствията и пропуските и се захващайте за тях.

.NET библиотеката е проста до степен да бъде напълно изхвърлена надолу; вероятно е добре за първата и втората група, не на последно място защото те не знаят по-добре, но за останалото това е нещо упражнявайте в безсилие. Това безсилие се изостря, когато е в сравнение с големия конкурент на .NET, Java. Java не е панацея; тя също се ориентира грубо към средния вид програмист, който е разбираемо, тъй като те са най-многобройни. Но Java е много повече възвишен. Той е много по-силен в концепциите, което го прави по-лесно уча. Слънцето не се оправя през цялото време, но хората зад Java ясно са направили нещо усилие.

Едно практическо проявление на това е, че .NET отразява много на лошите решения, взети в Win32. Например, .NET предоставя API с име Windows Forms за писане на GUI. Windows Forms е базирани в голяма степен на Win32 GUI API; същите API на GUI, които дължим дизайнът им за Win16. За да напишете правилно програмите на Windows Forms, трябва да знаете как работи Win32, защото има концепции от Win32, които показват присъствието си в Windows Forms. В Win32, всеки прозорец е свързан с конкретна нишка. Може да има множество прозорци, които принадлежат към нишка, но всеки прозорец е собственост на точно една нишка. Почти всяко действие, което актуализира прозорец в по някакъв начин – да го преместите по екрана, да промените някои текст, да анимирате някои графика, нещо подобно – трябва да се изпълнява в нишката който притежава прозореца.

Това ограничение само по себе си не е съвсем рядко. Има много малко наистина многопоточни GUI API, защото това е склонно да прави програми по-сложни без реална полза. Проблемът се крие в това как .NET кара разработчиците да се справят с това ограничение. Има начин да проверете дали трябва да се изпрати актуализация на прозорец към нишката който всъщност е собственик на прозореца или не, заедно с механизъм за изпращане на актуализацията до нишката на прозореца. Само дето този начин не го прави винаги работят. В някои ситуации може да ви каже, че сте използвайки правилната нишка, дори и да не сте. Ако програмата след това продължава и се опитва да извърши актуализацията, тя може да успее или тя може да окачи или срине приложението. Причината за това безполезно поведението е начинът, по който Windows Forms зависи толкова силно от Win32.

Тези малки проблеми са в изобилие. Библиотеката .NET работи. То повече или по-малко има всички основни парчета, от които се нуждаете, но е пълно области, в които трябва да се справите пряко или косвено с остаряла посредственост на Win32. Само по себе си нито един от тези въпроси ще бъде шоу-стоп, но всички те се добавят. Това е смърт на а хиляди съкращения. Има толкова много места, където Win32 основите „блестят“ и омазняват това, което трябва да е било чисто нова платформа.

Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: