ცოტა ხნის წინ Microsoft-მა დაშოკა Windows-დეველოპერები: პლათფორმა .Net-ი, რომელსაც კომპანია რეკლამას უკეთებდა ბოლო ათწლეულის განმავლობაში, აღარ იქნება გამოყენებული Windows 8-ში ახალი ინტერფეისის შესაქმნელად. ამის მაგივრად დეველოპერებმა უნდა გამოიყენონ HTML5 და JavaScript-ი. ბევრმა საკუთარ თავს კითხვა დაუსვა, რომლეზეც პასუხი ჯერ არ ჩანს: „როგორ შევძლებ ჩემი გამოცდილების გამოყენებას ახალი აპლიკაციების შექმნისას?“ მაიკროსოფტი სდუმს და არ ჩქარობს გვაცნობოს რაიმე BUILD-კონფერენციამდე, რომელიც სექტემბერში გაიმართება. მაგრამ ალბათ ყველაფერი ასე მძიმედ არ არის, როგორც ბევრი ფიქრობს. Windows 8-ის ადრეულ ი ანაწყობები უკვე გაიპარა ინტერნეტში და საკმაო დრო დაიხარჯა იმისათვის, რომ გაეგოთ, თუ როგორ მუშაობს იგი. რა უნდა ვთქვათ, ყველაფერი ისე გამოიყურება, თითქოს Windows 8-ზე დეველოპინგი არა თუ საშინელებაა, არამედ როგორც იქნა შეძლებს ააცილოს დეველოპერებს მრავალი გამაღიზიანებელი წინააღმდეგობა მათ გზაზე. თუ მაიკროსოფტს გამოუვა ყველაფერი დაგეგმილი, ვინდოუსის შემდეგი ვერსია იმდენადვე მნიშვნელოვანი გახდება, როგორი მნიშვნელოვანიც უნდა გამხდარიყო Windows Longhorn-ი.

ცოტა ისტორია

რათა გავიგოთ ზოგიერთი ჩახლართული მომენტი, ისტორიული ექსკურსის გაკეთება მოგვიწევს. სანამ სცენაზე .Net-ი გამოვიდოდა, Windows-აპლიკაციების შექმნა ორი სხვადასხვა გზით ხდებოდა. „დიდი“ აპლიკაციები, როგორიცაა ოფისი, ფოტოშოპი, ბრაუზერები და ა.შ. იწერებოდა Win32 API-სა და C++-ის საშუალებით. Win32 API გახლავთ ფუქნციების დიდი ნაკრები, რომლებიც ქვედა დონეზე გაძლევენ წვდომას ისეთ რამეზე, როგორიცაა სამომხმარებლო ინტერფეისის გრაფიკული გამოსახვა, მონაცემთა გადაცემა ქსელში, ფაილურ სისტემასთან წვდომა და მრავალი სხვა. Win32 API წყვეტდა მრავალ საკითხს, მაგრამ ზოგიერთ მათგანს მთლად კარგად ვერა, ზოგიერთს კი საერთოდ ვერ წყვეტდა. მგალითად, მონაცემთა ბაზებთან წვდომა, მიუხედავად იმისა, რომ მას ამის საშუალება ჰქონდა, ძალიან მოუხერხებლად იყო გადაწყვეტილი. მაგრამ კიდევ უფრო აქტუალური გახლდათ ის, რომ Win32 API-ს მხოლოდ საბაზისო ნაკრები ჰქონდა ვიზუალური ინტერფეისის ასაგებად და მასში არ იყო წარმგოდგენილი დაკაბადონების რაიმე საშუალება. თითოეული ღილაკის, ველის და ხელსაწყოთა ზოლის განთავსება ხელით ხდებოდა. თუ დეველოპერს სურდა ელემენტების მდებარეობის შეცვლა ფანჯრის ზომის შეცვლის გამო, მას უბრალოდ ხელახლა უნდა განეტავსებინა ისინი ყოველი ცვლილებისას. რათქმაუნდა, დროთა განმავლობაში გაჩნდა მრავალი ბიბლიოთეკა, რომლებიც ემსახურებოდნენ როგორც დამატებითი ფენა პროგრამისტსა და ოპერაციულ სისტემას შორის (მათ შორის MFC მაიკროსოფტისაგან), მაგრამ Win32 API-ში ჩაღრმავება ფრიად საჭირო იყო, თუ გინდოდათ რომ ყველაფერს ემუშავა. დეველოპინგის მეორე მეთოდი გახლდათ Visual Basic-ი. მისი დახმარებით ზოგიერთი საკითხი ძალიან ადვილად გადასაწყვეტი იყო — კერძოდ, მონაცემთა ბაზებთან წვდომა და სამომხმარებლო ინტერფეისის შექმნა. ყველაფერი ამის გამო Visual Basic-ი კორპორატიული სამყაროს მეფე გახდა, რომლისაგანც ბევრს არ ითხოვდნენ, მთავარია ბაზას მიერთებოდა, წამოეღო ჩანაწერები და ასევე დაემატებინა ახალი ჩანაწერები. ამ ყველაფერს Visual Basic-ი გადასარევად ართმევდა თავს. ყველა დანარჩენისთან მას პრობლემა ჰქონდა. ჰო, ისიც ნუ დაგავიწყდებათ, რომ Visual Basic-ს არ ჰქონდა OOP-ის მხარდაჭერა. და ამ დროს სცენაზე გამოჩნდა .Net-ი და ყველაფერი შეცვალა. .Net-მა დეველოპერებს მისცა Visual Basic-ის გამოყენების სიმარტივე, მაგრამ არასასიამოვნო ნაკლოვანებების გარეშე. ანალოგიურად ბეისიკისა, .Net-მა უზრუნველყო პროგრამისიტი მოსახერხებელი ხელსაწყოებით სამომხმარებლო ინტერფეისის შესაქმნელად და მონაცემთა ბაზებთან დასაკავშირებლად, ანუ ძალიან მოსახერხებელი იყო კორპორატიული აპლიკაციების შექმნისას. მაგრამ Visual Basic-ისაგან განსხვავებით, .Net-მა Win32-სთან წვდომა ერთ-ერთ ფუქნციად გაიხადა. ახალი პლათფორმა სწრაფად იკრებდა ძალებს კორპორატიულ სფეროში და მრავალი ახალი კომერციული პროექტი ზუსტად რომ მასზე დაფუძნდა. ოცნება, რომელსაც Longhorn ჰქვია Windows XP, რომელიც .Net-ის გაჩენამდე ერთი წლით ადრე გამოვიდა, არ იყენებდა ამ ტექნოლოგიას. მაგრამ PDC-ზე 2003 წლის ოქტომბერში მაიკროსოფტმა პირობა მისცა დეველოპერებს, რომ გამოასწორებდა სიტუაციას Windows Longhorn-ის გამოშვებით. ვინდოუსის ამ ვერსიას უნდა ჰქონოდა .Net-ი ბრითვის დონეზე, რაც თავის მხრივ ფართო გზას უხსნიდა ახალ პლათფორმას WinFX-ს — Windows Framework. ყველაფრის გარდა, WinFX-ი შეიცავდა თავის თავში ვექტორული, მაშტაბირებადი, აპარატურულად აჩქარებული სამომხმარებლო ინტერფეისების შექმნის ახალ მეთოდს, სახელად Avalon. თვითონ ვინდოუსიც უნდა დაწერილი ყოფილიყო WinFX-ის მეშვეობით სისტემური აპლიკაციებს დონეზე, როგორიცაა Windows Explorer, კალკულატორი და ა.შ., ხოლო .Net-ი უნდა გამხდარიყო აპლიკაციების შექმნის მთავარი საშუალება. Win32 დარჩებოდა უკუთავსებადობისათვის, მაგრამ გაიყინებოდა და დავიწყებას მიეცემოდა. Longhorn-ს უნდა დაესამარებინა პროგრამების დაწერის ყველა ძველი ხერხი და დაეწყო დეველოპინგის ახალი ერა, რომელიც არ იქნებოდა დამძიმებული მოძველებული არქიტექტურული გადაწყვეტილებებით. როგორც ვიცით, Longhorn-მა ვერ იხილა მზის შუქი. პროექტი გადაიქცა უზარმაზარ და მოუქნელ მონსტრად. ამასთან ერთად დაიწყო Windows XP-ზე თავდასხმები და მაიკროსოფტმა მთელი თავისი ძალები მიმართა XP-ის გაძლიერებაზე, რის შედეგადაც მივიღეთ Windows XP SP2, ხოლო შემდეგ დაიწყო სემდეგი ოპერაციული სისტემის შექმნა, სახელად Windows Vista. კურსის ცვლილების ერთ-ერთი მთავარი მხსვერპლი გახლდათ .Net-ი. Windows Vista, თუმცა შეიცავდა რამოდენიმე რადიკალურ ცვლილებას, WinFX-ის კონცეფცია არ გაიზიარა. Avalon-ი დაემატა სისტემას, მაგრამ არ გახდა ბირთვის შემადგენელი ნაწილი. .Net-კოდის ერთადერთი მნიშვნელოვანი მატარებელი გახდა Media Center-ი. ყველა დანარჩენი — Win32-ია, თანაც განახლებული და გაფართოებული. მასში დაემატა მრავალრიცხოვანი ქვედა დონის ფუქნციები, აგრეთვე ცვლილებები გრაფიკულ ქვესისტემაში. არცერთი ეს ფუქნცია ნორმალურად არ მუშაობდა. ამ ყველაფრის მიზეზი რამდენიმე გახლდათ და უპირველესად ის, რომ მაიკროსოფტი დაყოფილია ჯგუფებად. Windows-ი იქმნება ჯგუფში Windows Division (WinDiv), ხოლო .NET — ჯგუფში Developer Division (DevDiv), რომელიც თავის მხრივ არის ჯგუფის Server and Tools business ნაწილი. და მართალია ლოგიკურია ვიმსჯელოთ, რომ ეს ორი ჯგუფი მოქმედებდა შეთანხმებულად, მაგრამ ეს ასე არ ხდებოდა. რის ან ვის გამო კი არა — უბრალოდ მათ სხვადასხვა პრიორიტებები ჰქონდათ.

დაძაბულობის წერტილი

ზოგიერთ ამ პრიორიტეტს თავის დროზე განსაზღვრული აზრი ჰქონდა. ასე, WPF-ის გამოყენება შესაძლებელი იყო მხოლოდ .Net-პროგრამებში, რომლებიც C# ან Visual Basic.NET-ის იყო დაწერილი. მთელი მისი API მიუწვდომელი იყო პროგრამებისათვის, რომლებიც დაწერილია C++-ზე, რაც მნიშვნელოვანი წინააღნდეგობაა არსებული აპლიკაციების WPF-ზე გადატანის გზაზე. ამას აზრი ჰქონდა მხოლოდ იმ შემთხვევაში, თუ ყველა ახალი პროგრამა შეიქმნებოდა .Net-ის გამოყენებით, მაგრამ როდესაც გეგმები შეიცვალა და Win32 დაბრუნდა სცენაზე, ეს გახდა დიდი პრობლემა. მაიკროსოფტს არ შეეძლო გამოეყენებინა WPF ელეგანტური ვექტორული და ა.შ. ინტერფეისების შესაქმნელად თავის აპლიკაციებში. სხვა პრიორიტეტები არის შედეგი ბანალური არათავსებადობისა WinDiv-ისა და DevDiv-ის საქმიანობაში. DevDiv-ის მიზანი იყო გაეხადა .Net-ი მაქსიმალურად მოხერხებული დეველოპერებისათვის ახალი ფუქნციების დამატების გზით. WinDiv-ისათვის მნიშვენლოვანი იყო უკუთავსებადობის შენარჩუნება, საიმედოობა, აგრეთვე არსებული ტექნიკური შეცდომების შესწორება. ერთიც და მეორეც რათქმაუნდა მნიშვნელოვანია, მაგრამ DevDiv არ ექვემდებარებოდა WinDiv-ს და არ აქცევდა მას სატანადო ყურადღებას. შედეგად WinDiv-სათვის მოუხერხებელი იყო .Net-თან მუშაობა. .Net-ის შემდგომმა განახლებებმა გააუმჯობესეს სიტუაცია, მაგრამ ზარალი უკვე მიყენებული იყო. WinDiv-მა, უკმაყოფილო DevDiv-ის მუშაობით დააიგნორა ამ უკანასკნელის სამუშაო და Windows 7-ი, ისევე როგორც მისი წინამორბედი, იყენებს .Net-ს მხოლოდ Media Center-ში. ყველა ახალი API Windows 7-ში არის კლასიკური Win32 API და არა აქვს პირდაპირი წვდომა .Net-პროგრამებთან, ხოლო ჩვეულებრივმა Win32 აპლიკაციებმა ვერ მიიღეს შესანიშნავი ფრეიმვორკი სამომხმარებლო ინტერფეისების შესაქმნელად. Windows 8 ამ ყველაფერს ბოლოს მოუღებს. (გაგრძელება იქნება…)