ჩინებული ახალი სამყარო

Windows-ის სემდეგ ვერსიაში იქნება პროგრამული კოდის შესრულების ორი გარემო — .Net-ის ახალი ვერსია (ჯერ-ჯერობით აღინიშნება ნომრით 4.5) და კლასიკური C++ გარემო (ტექნიკური თვალსაზრისით, ეს არის COM, ან მისი ერთგვარი წარმოებული), ახალი სახელწოდებით WinRT. ასევე ვინდოუსის ახალ ვერსიაში გამოჩნდება ჩადგმული ბიბლიოთეკა სამომხმარებლო ინტეფეისების შექმნისათვის — DirectUI — რომელიც დაფუძნებულია Direct2D და DirectWrite API-ზე, რომლებიც უკვე წარმოდგენილია Windows 7-ში. Silverlight-ის ახალი ვერსია (კოდური სახელწოდება Jupiter), როგორც ჩანს, იმუშავებს DirectUI-ს დახმარებით. WinRT-ს და DirectUI-ს პირდაპირ .Net-იდან იქნება ხელმისაწვდომი.

WinRT წარმოადგენს თანამედროვე API-ს მრავალი ფუნქციისათვის, რომლებიც ადრე Win32 API-ს წარმოადგენდა. უხეშად რომ ვთქვათ, WinRT — ეს არის ახალი Win32, რომელიც დაპროექტებულია თანამედროვე C++-იდან გამოყენებისათვის და აგრეთვე იმისათვის, რომ ლამაზად ჩაჯდეს .Net-ის კონცეფციაში. რათქმაუნდა ნაკლებ სავარაუდოა, რომ WinRT მთლიანად შეცვლის Win32-ს, რომელიც იმდენად დიდია, რომ ადვილად არ ექვემდებარება მოდერნიზაციას, მაგრამ შემდგომ ვერსიებში ეს სრულიად შესაძლებელია. WinRT-ს პოზიცია ყოველი ახალი ანწყობის შემდეგ სულ უფრო მყარდება.

WinRT არა მარტო Win32-ის გაუმჯობესებული ვერსიაა — მაიკროსოფტი ასევე აფართოებს ფუქნციების რაოდენობას. მაგალითად, დაემატება ასინქრონული ოპერაციების ყოვლის მომცველი მხარდაწერა ფონურ პროცესებში ხანგძლივი ოპერაციების მარტივად შესრულებისათვის, ხოლო გაცვლის ბუფერის API გახდება კიდევ ურო მოქნილი და ადვილად გამოსაყენებელი.

DirectUI ეფუძნება WPF/Silverlight-ის მიმდინარე ტექნოლოგიის ქვესიმრავლეს და უზრუნველყოფს სამომხმარებლო ინტერფეისის დაკაბადონების მრავალფეროვან შესაძლებლობებს, რომლებიც Win32-ში არც არასოდეს ყოფილა. პროგრამები, რომლებიც დაწერილია C++-ზე, შეძლებენ DirectUI-ს გამოყენებას და ეს იქნება იგივე ხელსაწყო, რომელიც ექნებათ .Net-დეველოპერებს.

Jupiter — ფაქტობრივად Silverlight 6 — ხელსაწყოების სრულფუქნციური მოქნილი ნაკრებია აპლიკაციების შესაქმნელად. როგორ შეეთავსება ერთმანეთს DirectUI და Jupiter, ჯერ-ჯერობით უნცობია, შესაძლოა ისინი ასრულებენ ერთი და იგივე ფუნქციებს და DirectUI განვითარდება, სანამ არ მიაღწევს Silverlight-ის დონეს, შესაძლოა აგრეთვე, რომ DirectUI შითავსებს მხოლოდ საბაზო ფუნქციებს უფრო რთული ფრეიმვოკრებისათვის. ასევე შესაძლებელია სიტუაცია, რომ Jupiter-ი განკუთვნილია მხოლოდ სრულეკრანიანი, შეხებაზე ორიენტირებული აპლიკაციებისათვის.

სამომხმარებლო ინტერფეისების შექმნა XAML-ის, WPF-ისა და Silverlight-ის მსგავსი ხელსაწყოებით წარმოადგენს პრიორიტეტს Microsoft-ისათვის მომავალში. ამის დასტურია კომპანიის სტრუქტურული რეორგანიზაცია, რომელიც გასულ კვირაში დაიწყო. XAML-ის დეველოპერების ჯგუფი, რომლებიც ადრე DevDiv-ში იყვნენ შეყუჟულები, სამ ნაწილად გაიყო — Windows-ის XAML-ის ჯგუფი გადავიდა WinDiv-ში, ხოლო Windows Phone, XBox-ის ჯგუფი — Windows Phone-ში. თანამშრომელთა მხოლოდ ის ჯგუფი, რომლებიც უშუალოდ მუშაობდნენ ისეთ პროდუქტზე, როგორიცაა Visual Studio და Expression Blend-ი, დაჩნენ DevDiv-ში. მაიკროსოფტის შიდა წერილი განმარტავს, რომ XAML-ის ჯგუფი მუშაობდა WinDiv-თან წლების მანძილზე Windows 8-ზე და მიმდინარე ცვლილებებმა უბრალოდ ამ საკითხის ფორმალიზება მოახდინა.

ერთიანი, თანამედროვე, უნიფიცირებული Windows API

თუ ახლა Win32/C++ და .NET-ი სრულიად სხვადასხვა პლათფორმებია, თითეული მათგანი საკუთარი შესაძლებლობებით, ახლო მომავალში ისინი ერთნაირი უნდა გახდეს. თუ მაიკროსოფტი დაამატებს ახალ API-ს Windows-ის ბირთვში, ისინი ხელმისაწვდომი გახდება კოდიდან, რაც C++-ის ნიველირებას მოახდენს .Net-თან შედარებით. მეორე მხრივ არსებული აპლიკაციები, რომლებიც დაწერილია C++-ზე, შეძლებენ გამოიყენონ ახალი სამომხმარებლო ინტერფეისი ზედმეტი დაძაბვის გარეშე. ეს აქტუალურია აგრეთვე მაიკროსოფტისათვის: ორი პლათფორმის გათანაბრება კარს უღებს .Net-აპლიკაციებს, რომლებიც სისტემაში დაემატება.

მაგალითად ჩვენ შევძლებთ Office-ის ვერსიის ნახვას, რომლის ინტერფეისი პირვალდ ათწლეულის განმავლობაში დაწერილი იქნება Windows-ის სტანდარტული კომპონენტების გამოყენებით.

ჯერ-ჯერობით სრულად არ არის ცნობილი, თუ რა ბედი ელის WPF-ს. WPF-ი და Silverlight-ი მუშავდება ადამიანების ერთი ჯგუფის მიერ, მაგრამ ბაზარი Silverlight-ს აღიქვამს უფრო უკეთ, ვიდრე მის უფროსს ძმას. WPF-ს შეუძლია გააკეთოს ის, რაც არ შეუძლია silverlight-ს და სამწუხარო იქნება, თუ მის შესაძლებლობებს არ გამოიყენებენ Windows 8-ში. WPF და Silverlight ძალიან გაქვს ერთმანეთს და შესაძლოა Jupiter-მა გაერთიანოს მათი შესაძლებლობები.

მაიკროსოფტის ეკოსისტემის გათვალისწინებით WPF-ის მნიშვნელობის შემცირება და Silverlight-ის წინ წამოწევა სრულიად გამართლებულია. Silverlight-ი გამოიყენება Windows Phone-ის აპლიკაციების შექმნისას და არსებობს დაბეჯითებითი დამამტკიცებელი საბუთები იმის შესახებ, რომ Silverlight-ის ვერსია XBox-ისათვის უკვე წარმოებაშია. Silverlight-ის არსებობა Windows-ზე, Windows Phone-ზე და XBox-ზე ქმნის მაიკროსოფტის იდეოლოგიას „სამი ეკარნი და ღრუბელი“, რომელიც უზრუნველყოფს ერთიან გამოცდილებას.

თუმცა ჯერ არ არის ინფორმაცია იმის შესახებ, თუ რამდენად კარგად იმუშავებს ეს იდეოლოგია Windows 8-ში. Windows Phone-ის დეველოპერები ჯერ არ არიან დარწმუნებულები, რომ მათი პროდუქტები ადვილად გადავა Windows-პლანშეტებზე, განსხვავებით iOS და Android დეველოპერებისა. Windows-იც და Windows Phone-ის მხარს უჭერს Silverlight-ს, მაგრამ მობილური ტელეფონის სპეციფიკა მოითხოვს დამატებითი ფუქნციონალის არსებობას, რაც ჯერ არ არის დამატებული.

მომავლის არ გვეშინია

რამდენიმე კვირის წინ Windows 8-ის პრეზენტაციის შემდეგ ბევრს გაუჩნდა შეგრძნება, რომ აპლიკაციების შექმნა ახალი პლათფორმისათვის შესაზლებელი იქნება მხოლოდ HTML5 და JavaScript-ის მეშვეობით, რამაც შესაბამისად გამოიწვია მღელვარება Silverlight-დეველოპერებს შორის. Silverlight-ის ოფიციალურ ფორუმზე წარმოიქმნა რამოდენიმე თემა მრავალი მილიონი ნახვით. დეველოპერებს სურთ ახალი აპლიკაცების შექმნა ახალი ინტერფეისებისათვის, მაგრამ არ სურთ HTML5 და JavaScript-ის გამოყენება.

და მათ არც მოუწევთ. გსურთ ახალი აპლიკაციების წერა C++-ზე? უპრობლემოდ. გსურთ C# და Silverlight? ასევე ეს ტექნოლოგიებიც მხარდაჭერილია. იმის მაგივრად, რომ გადავყაროთ დეველოპინგის მთელი გამოცდილება წარსულში — ზუსტად ასეთი შთაბეჭდილება დარჩა ბევრს — Windows 8 გადააქცევს C++ და C# დეველოპინგის პირველხარისხოვან საშუალებებად.

რაც შეეხება HTML5 და JavaScript-ს, ისინიც იქნება მხარდაჭერილი. თუ კარგად გახსოვთ, მაიკროსოფტმა უკვე მოსინჯა ნიადაგი თავისი ტექნოლოგიით HTA (HTML Application). შესრულებადი HTA-ფაილები შედგება HTML, JavaScript, CSS და სხვა სახის შიგთავსისაგან და ეშვება განსაკუთრებულ სანდო რეჟიმში. ამის ხარჯზე ის შეზღუდვები, რაც ჰქონდა HTML-გვერდს (მაგალითად კომპიუტერის ლოკალურ რესურსებზე წვდომის შეზღუდვა), არა აქვს HTA-ს.

ახალი HTML5-აპლიკაციები არ ეფუძნება HTA-ს, მაგრამ პრინციპები ძალიან მსგავსია. როგორც HTA, HTML5-აპლიკაციები მიიღებენ უფრო მეტ შესაძლებლობას ჰქონდეთ ურთიერთქმედება ოპერაციულ სისტემასთან, ვიდრე ეს შეუძლიათ ჩვეულებრივ ვებ-გვერდებს — მათ შეეძლებათ გამოიყენონ Windows API და ჰქონდეთ ინტერფეისი, ძალიან მსგავსი ჩვეულებრივი აპლიკიციისა. საუკეთესო შემთხვევაში ისინი უნდა იყვნენ .Net-ისა და კლასიკური აპლიკაციების დონეზე, იმ განსხვავებით, რომ გამოიყენებენ HTML5-სა და JavaScript-ს დაკაბდონებისა და პროგრამირების ენად. შედეგად მივიღებთ პროგრამირების სახეს, რომელიც ზალზედ ნაცნობია ვებ-დეველოპრესებისათვის, მაგრამ ფუქნციური შეზღუდვების გარეშე.

Windows 8 — სულაც არ არის დეველოპერის კოშმარი, პირიქით, წინ გადადგმული ნაბიჯია: ნაბიჯი, რომელიც დეველოპინგს მოხერხებულს გახდის როგორც C++ და C#-ისტებისათვის, აგრეთვე ვებ-დეველოპერებისათვის. .Net-ისა და კლასკური კოდის უნიფიკაცია, სრული აპარატურული აჩქარება, თანამედროვე API, Avalon-ი, როგორც Windows-ის ინტერფეისის შექმნის ძირთადი გადაწყვეტილება — ეს ის ყველაფერია, რაც უნდა მიგვეღო Longhorn-ში და რაც შეიძლება, რომ მივიღოთ Windows 8-ში.

ცოტა ხნის წინ 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 ამ ყველაფერს ბოლოს მოუღებს. (გაგრძელება იქნება…)