Vlákno názorů k článku
Trolltech portuje Qt na Windows CE od LO - Otázka je, jestli má smysl na PDA portovat...

Nemam pocit ze C++ je zastaraly jazyk - preco si myslite, ze .NET a managed kod je jedina buducnost? Mimochodom, aplikacie pre Windows CE sa v managed kode nepisu - zariadenia na ktorych to bezi casto nestihaju ani C++ - stale sa bojuje s pamatovou narocnostou a CPU su pomale s malou cache.

Mám za to, že managed kód postupně převládne. Je vhodnější pro překlenutí té obrovské propasti v úrovni abstrakce strojového kódu a designu aplikace, přináší řadu výhod. .NET je marketingový název jedné z těchto technologií. Netvrdím, že je to technologie jediná, ale zatím nic srovnatelného na obzoru není. On rozvoj technologií chce dost zdrojů. MS má peníze, lidi i vůli.

Aplikace pro Windows CE se píší v .NETu již řadu let. Samozřejmě tak zatím nelze psát všechno (třeba device drivery).

Mám za to, že managed kód postupně převládne. Je vhodnější pro překlenutí té obrovské propasti v úrovni abstrakce strojového kódu a designu aplikace, přináší řadu výhod.

Je absolutne nesporne, ze velka cast aplikacii ktore su dnes napisane v C/C++ bude v buducnosti napisana .NET/Java/... presne rovnako ako sa dnes dyamicke web aplikacie pisu v PHP/Python/... a nie v jazyku C. To vsak neznamena ze rodina jazykov C/C++ straca zmysel a bude plne nahradena technologiami beziacimi pod VM tak ako sa nam to snazite naznacit. Tam kde bude rychlost, real-time vlastnosti a pamatova narocnost dolezita, prip. nutnost low-level pristupu - tam sa C/C++ udrzia a nevidim momentalne ziadne dovody aby tomu tak nebolo. C/C++ sa tiez neustale zdokonaluju a musite si uvedomit, ze tieto jazyky "by design" sleduju trochu ine zamery ako napr. Java a C#.

Aplikace pro Windows CE se píší v .NETu již řadu let. Samozřejmě tak zatím nelze psát všechno (třeba device drivery).

V oblasti vyvoja embedded aplikacii sa pohybujem uz niekolko rokov a mozem vam zodpovedne povedat, ze vsetky komplexne aplikacie pre Windows CE su napisane v C alebo C++. Zakaznici su dnes tak narocni, ze ich predstavy o funkcionalite je velmi tazko naplnit v danych HW obmedzeniach. .NET je tu absoltune mimo. Jednoduchu hru alebo "yet another task manager" v tom sice napisete a nepredate to.

Hm, tak jsem asi oborove mimo misu. Posledni 3 nebo 4 roky pisu merici aplikace pro PDA s WinCE a pisu to v C# za pouziti .NET Frameworku. Jednoduse jsme si to zkusili psat v cistem a managed kodu, srovnali vyhody a nevyhody a ten managed vyhral. Ta rezie na systemu neni ani zdaleka tak vysoka, jak se obvykle veri a nejen ze programovani je o neco snazsi, ale hlavne ladeni je mnohem jednodussi. Pritom ty aplikace nejsou ani uplne primitivni, ani se neda rict, ze by byla pomale. Jedine co mi vadi je nekdy kostrbaty pristup k funkcim zarizeni, ktere nejsou primo v .NET pristupne.

Vy jste pane LO opravdu vtipálek. Qt chudý příbuzný ? To vše co uvádíte zřejmě jako výhody jsou většinou problematické málo jisté technologie, kvalitní mají pouze marketing to uznávám. Uvádět jako argument barvy nebo Managed DirectX to je opravdu síla. Tušíte vůbec co je to QT a čím disponuje ? Další perla je to o buffer overflow. To že lze buffer overflow jde realizovat prakticky v jakémkoli jazyce jisté téměř absolutně. Možná jen prostě berete příliš vážně marketigové a reklamní brožurky a máte příliš málo vědomostí o tom proti čemu flejmujete. Prosím o trošku racionální argumenty a ne pohádky.

Vím, co je Qt, a čím disponuje. A buďme upřimní, je to slabé.

Co se vám nelíbí na argumentaci typu správa barev, Managed DirectX, typografické features apod.?

Jak řekněme v Javě způsobíte buffer overflow? Zkuste si naalokovat 100 bytů velký buffer, a zapsat do něj 300kB. Co se v Javě stane? Samozřejmě nic (resp. dojde k výjimce), protože je to managed jazyk. Podobně v C#. A teď to zkuste v C++. Každé hloupé strcpy je potenciální průšvih. Navíc konstrukce typu if (i=1) a podobné jsou v C++ validní. Podobně tupé chyby jsou příčinou většiny problémů. Ale nemá smysl opakovat to, co autoři Javy, .NETu a podobných prostředí tvrdí již léta.

Ještě v krátkosti zopakuji to, co tu občas píšu. Managed jazyk umožňuje validaci kódu (statickou i dynamickou), která umožňuje dát záruky typu "v tento kódu nikdy nemůže dojít k buffer overflow", "tento kód nikdy nezasáhne do obsahu proměnné A", "tento objekt nikdy nehrábne mimo zdroje své instance" apod. Tyto záruky v C/C++ v principu není možné dát. Přitom právě takové záruky umožňují oddělit procesy jinak, než na HW úrovni (s řádově nižší režií). A protože v managed jazycích lze napsat prakticky celý operační systém, je cesta do budoucna jasná. Příští desetiletí zřejma patří tomuto konceptu (pokud někdo nepřijde s něčím lepším).

Bylo by nefér tvrdit, že příliš časté používání editoru vi brání lidem výše popsaný koncept pochopit. Na root.cz je řada lidí, kteří mohou pochopit, že tahle technologie je budoucnost. A možná se i oni pak budou hrozit, proč dnes někdo píše high level aplikace v C/C++.

Samozřejmě i v C++ lze provádět opatření směřující ke zvýšení bezpečnosti a spolehlivosti výsledného kódu. Nicméně v principu to vede k velmi omezeným výsledkům, a dávat na výsledný kód záruku není možné.

Záměna = a == je častý problém (a nejen u if-u). Stejně tak třeba přístup k prvkům mimo hranice pole. Tragičtější ale je, že C++ zkompiluje i velké procento překlepů. A nejtragičtější pak je, že když už není chyba zachycená při kompilaci, chybný kód často pokojně běží, a "prostě" se chová divně, protože si člověk někde něco přepsal. Z hlediska řízení kvality produktu je C/C++ mizerný jazyk. Z hlediska budoucích technologií je C/C++ zabité, protože neumožňuje zaručit vlastnosti kódu.

Představte si třeba, že máte procesy izolované *pouze* tím, že při kompilaci a v běhu máte vlastnostmi jazyka zaručeno, že objekt (proces) nehrabe mimo svůj kontext. Jak takové věci docílíte v C/C++? Nijak. V C# či Javě triviálně.

Ještě v krátkosti zopakuji to, co tu občas píšu. Managed jazyk umožňuje validaci kódu (statickou i dynamickou), která umožňuje dát záruky typu "v tento kódu nikdy nemůže dojít k buffer overflow", "tento kód nikdy nezasáhne do obsahu proměnné A", "tento objekt nikdy nehrábne mimo zdroje své instance" apod. Tyto záruky v C/C++ v principu není možné dát.

Ano, pisete tu tie nezmysly uz dost casto. .NET platforma vam nedava ziadne staticke zaruky nad kodom ktory pisete. Nic take v proceduralnych jazykoch neexistuje a nikdy existovat nebude. K dispozicii su nastroje, ktore taku analyzu pre proceduralny kod v obmedzenej miere robia - a momentalne su najdokonalejsie pre jazyk C. Napr ASTRÉE ktory sa poziva na "Run Time Errors" kontrolu riadacieho software v lietadlach Airbus.

Vy sa tu radi hrate na odbornika, ktory tu vsetkych poucuje o veciach ktorym sam nerozumie. Vsetci uz vieme, ze ste fanusik .NET technologii - tak preco povazujete za nutne nas tu o tom neustale informovat ako pokazena platna bez ziadnej novej alebo relevantnej informacie? Uvedomte si, ze vasa vizia buducnosti programovania je vas osobny nazor. Zda sa mi z vasej strany dost nekriticke nam ho tu podsuvat ako matematicky overenu pravdu.

Statická analýza kódu pod .NETem? Viz třeba http://en.wikipedia.org/wiki/FxCop .

Říká vám něco Model checking? A jak jej spolehlivě a průkazně chcete realizovat v C/C++, kde vám jednoduchý, validní a bezvadný kód nadělá z celého stavového stromu bramboračku? Problém je totiž v tom, že unsafe konstrukce typu strcpy nebo casting intu na pointer může vést k nepředpokládanému výsledku. Jak jste schopen algoritmickou analýzou kódu v C/C++ dokázat, že do proměnné A zapíše vyhradně rutina XYZ, když vám proměnnou A a řadu věcí kolem potenciálně přesmahne jakýkoliv strcpy? Jak si asi vaše analýza poradí s tím, když zapíšete do stringu s + offset 128? Tohle jsou přesně problémy, které v managed jazyku (Java, C#) neexistují, a které umožňují formální verifikaci kódu.

Pokud výše psané nechápete, tak si na odborníka hrajete vy.

Mnou popsaná vize budoucnosti technologie má celkem dobrou teoretickou i praktickou oporu. Je nepopiratelné, že tato vize přináší možnost výrazného zlepšení bezpečnosti a spolehlivosti SW oproti stávajícímu stavu, které v C/C++ nelze dosáhnout. Programátoři totiž chyby dělali, dělají, a dělat budou. Je tedy nutné stavět takové systémy, které si s chybami lépe poradí - odhalí je ve fázi verifikace návrhu, kompilace, nebo v čase běhu.

Statická analýza kódu pod .NETem? Viz třeba http://en.wikipedia.org/wiki/FxCop .

Takato obmedzena analyza sa da robit nad hocijakym kodom - nie je to vlastnost .NET ani VM technologii ako sa to snazite prezentovat. Opat opakujem, ze momentalne podobne nastroje su najdokonalejsie pre jazyk C a nepredpokladam, ze sa na tom nieco zmeni v buducnosti. Vas povodny argument, ze .NET dava vacsie staticke zaruky nad kodom ako nativne jazyky je jednoducho nezmysel.

Říká vám něco Model checking? A jak jej spolehlivě a průkazně chcete realizovat v C/C++, kde vám jednoduchý, validní a bezvadný kód nadělá z celého stavového stromu bramboračku? Problém je totiž v tom, že unsafe konstrukce typu strcpy nebo casting intu na pointer může vést k nepředpokládanému výsledku. Jak jste schopen algoritmickou analýzou kódu v C/C++ dokázat, že do proměnné A zapíše vyhradně rutina XYZ, když vám proměnnou A a řadu věcí kolem potenciálně přesmahne jakýkoliv strcpy? Jak si asi vaše analýza poradí s tím, když zapíšete do stringu s + offset 128? Tohle jsou přesně problémy, které v managed jazyku (Java, C#) neexistují, a které umožňují formální verifikaci kódu.

Opat upakujem, ze vyssia typova bezpecnost nie je vlastnost .NET alebo managed kodu. Je to jednoducho vecou syntaxe, ktora je v nativnych jazykov rovnako dosiahnutelna. C++ je type unsafe by design.

Mnou popsaná vize budoucnosti technologie má celkem dobrou teoretickou i praktickou oporu. Je nepopiratelné, že tato vize přináší možnost výrazného zlepšení bezpečnosti a spolehlivosti SW oproti stávajícímu stavu, které v C/C++ nelze dosáhnout. Programátoři totiž chyby dělali, dělají, a dělat budou. Je tedy nutné stavět takové systémy, které si s chybami lépe poradí - odhalí je ve fázi verifikace návrhu, kompilace, nebo v čase běhu.

Musim vas sklamat, ze ziadnu verifikaciu navrhu vam proceduralne jazyky neposkytuju - mozno sa jedneho dna naucite programovat napr. v F# (stale nie cisto funkcionalny jazyk) alebo napr. jazyk Mercury a potom pochopite kde vo svojich myslienkach momentalne nachadzate. Programovanie komplexnych systemov je narocna cinnosta a drobne vylepsenia syntaxe jazyka neumoznia aby sa zo zleho programatora stal dobry. Robustne programovanie techniky, unit testing a QA maju radovo vacsi vplyv na kvalitu vysledku. Dnes su zlozite softwarove baliky - od aplikacii Autodesku, mentalray, Catia az po WebKit - napisane v C++. Je to ukazka toho, co je mozne dosiahnut ak ludia rozumeju tomu co robia. Ak by ste sa rozhodli to robit napr. v C#, tak nevyhnutne pridete na to, ze zrucnost programatora ma na vysledok vacsi vplyv ako drobne vylepsenia, ktore prichadzaju za cenu nizsej efektivy a pamatovej narocnosti.

Pane LO, váš názor je samozřejmě naprosto pomýlený. To proto, že je .NET tak úžasný pro vývoj OS to Microsoft asi v půlce zabalil a začal psát Vistu od začátku a bez .NETu, že.

Osobně musím říct, že když slyším .NET, tak mě jímá hrůza. Ještě jsem v .NET neviděl napsanou žádnou dobrou desktopovou aplikaci. Bohužel s některými musím denně pracovat a je to utrpení. Ačkoliv mám v práci Pentium 4 3GHz s HT a 1GB RAM, tak při jakékoliv náročnější činnosti musím tyto žrouty systémových prostředků vypínat, aby se s tím počítačem dalo vůbec něco dělat. Ono je sice pěkné, že s .NET se dá rychle vyvíjet, ale já bych spíše dal přednost tomu, kdyby se dalo s aplikací rychle pracovat a to mi bohužel .NET neumožňuje.

Poměrně významné procento kódu Visty je psané v .NETu. Samozřejmě .NET je na typicky zdroje náročnější, než Win32. Nicméně do budoucna se uvažuje o oddělování procesů (coby objektů) přes .NET invarianty, což eliminuje potřebu kernel mode transitions. Už dnes má díky tomu OS napsaný komplet v .NETu slušný výkon. Navíc výkon CPU trvale roste.

Mít v počítači 1GB RAM je dnes poměrně o ničem, když druhý GB vyjde na 540 Kč. Jestli chcete vidět pěknou aplikaci napsanou v .NETu, tak si zkuste bitmapový editor Paint.NET. Je komplet psaný v .NETu, a je velmi rychlý. Viz http://www.getpaint.net/

Ještě tak na okraj, v .NETu lze samozřejmě napsat pomalý kód. Jako kdekoliv jinde, i v .NETu je to o návrhu a optimalizaci.

to je teda vazne argument dokupte si ram vzdyt giga stoji jenom 540 :), mam 50 PC vetsinou s 512MB kdyz budu pocitat jako kdybych mel vsude ten 1G tak pro upgrade na 1G ram budu potrebovat 27000,- ... kdyz se ted kupuje novej pocitac tak dostava 1G automaticky ale proboha proc 2GB? protoze vista? no to snad ne .... opravdu argumenty typu jedete windows tak si kupte nejnovejsi HW aby vam to tak nak bezelo me pripomina vyvoj PC her. V momente kdy hra vyjde existuje jenom minimalni procento lidi co si ji pustej v nevyssim rozliseni s antialiasingem dynamickejma svetlama atd... a pak je tu vetsina lidi ktery sou radi ze se jim to hejbe a je jim jasny ze si budou muset koupit nove PC aby si to zahrali tak jak slibovala reklama a jak si to oni predstavovali. Proste argument ze si mam dokoupit na pc kde bezi outlook excel a word 2GB ram je na ranu pesti. ;) a to nemluvim o tom ze combo winxp+msoffice basic prodrazeji PC temer o jednu tretinu jeho ceny. zaplat panbuh ze pracuju ve firme kde se na takoveto drobnosti dost kouka brzy jiz budu obednavat kancelarska pc bez OS :)

oh melo tam byt pro upgrade na 2Giga RAM

Naprosto s vámi souhlasím, budoucnost patří staticky (a možná i dynamicky) typovaným managovaným jazykům, odvozeným z Pythonu, popř. Smalltalku. Bohužel do doby, než k tomu dojde, je ještě daleko, ale možná už naši vnuci nebudou C++ k životu potřebovat :)

Java ani C# nepřežijí, protože jsou příliš komplikované jazyky s příliš svazujícími pravidly. Oboje je v podstatě C++, kheré kromě opravy chyb v designu a pár hezkých, ale celkem zbytečných vlastností (jako je dost rozsáhlá a složitá implementace SQL NULL) nic nového nenabízí. Spíš naopak. Jejich velmi ukecaný kód a neustálé zanořování ve složeném závorkovém pekle (v C++ je použito jen v nejnutnějších případech) je brzy odnese do míst, kde je Fortran, Cobol a Perl.

Jazyky mohou umírat celkem rychle, zvláště pokud narazí na své limity, a někdo jiný je dál. Přitom právě dnešní bugová a bezpečnostní spoušť je do značné míry problémem C/C++.

Java i C# jsou jazyky odvozené od C/C++. Java byla (když jsem v ní psal) krásný jazyk, ale bohužel mizerná platforma.

Ukecané jazyky jsou daleko lepší, než jazyky typu PERL, kde si člověk připadá, že se autorovi kódu zasekl shift. Psaní není moc náročné, protože máme IntelliSense (dozvěděl jsem se, že jisté zárodky podobného mechanismu má už i vim). Také máme generátory kódu a templaty, takže toho člověk nakonec tolik nenapíše. Samozřejmě jednoho dne přijdou lepší jazyky, než C# a Java; nic není věčné.

Ukecané jazyky jsou daleko lepší, než jazyky typu PERL,

Opat tu prezentujete vasu neznalost a obmedzenost. Perl sa hodi na iny typ uloh ako napr. C# rovako ako nakladne auto sa hodi na nieco ine ako sportove coupe. Asi nie je nahoda preco je napr. SpamAssassin napisany prave v Perle.

Utvrdzujete ma len v jednom. Je absolutne jedno na aku temu sa tu diskutuje a ci vobec rozumiete o com pisete - vy jednoducho potrebujete "vyhrat" argumentaciu. Ok - verim, ze pre nic ine ako vytrvalost (a dostatok casu) sa vam to zvacsa podari - ego si tym zrejme posilnite ale realitu nezmenite.

> Ukecané jazyky jsou daleko lepší, než jazyky typu PERL, kde si člověk připadá, že se autorovi kódu zasekl shift.

To ano, ale oboje je extrém. Proč proboha musím funkci Main uzavírat do nějaké třídy (C#) nebo modulu (Java)?

Pobavili ste ma. C# je na chyby kodovania nachylny presne rovnako ako C++. V tomto ohlade C# ani Java programovanie nikam neposuvaju. Ak chcete nejaku vyssiu staticku kontrolu kodu, musite siahnut k jazykom ako Haskell, OCaml alebo F# (ten funguje pod .NET).

Ak je v aplikacii chyba, tak je uplne jedno ako sa to sprava v runtime - ta chyba tam proste je a VM ju neopravi. Buffer overflow v skutocnom C++ nie je problem - na to je nachylny C kod a C++ C-like kod. A skuste si tipnut preco sa v C++ stale pouzivaju C-like techniky? Hmm... pre efektivitu (hoci casto aj neznalost). XBox tiez nepoziva ziadny managed kod prave pre efektivitu. .NET ma na MS platforme buducnost pretoze je to Microsoft jednoducho pretlaca ale moznost pisat nativny kod tam zostane.

C# je na chyby náchylné stejně jako C++? Super. Zkuste si v C# napsat if (i=1). Kupodivu vám to neprojde. Zkuste si v C# vytvořit pole o 10 prvcích, a zapsat do jedenáctého prvku. Kupodivu vám to neprojde. Zkuste v C# najít něco typu strcpy, u čeho nejste při analýze kódu schopen jednoznačne říci, do čeho všeho vlastně zapíšete. A pak mi vyprávějte o tom, že managed jazyky programování nikam neposouvají.

V C++ se C-like techniky používají mimo jiné proto, že se používat dají.

Hry pro XBox se píší jednak v C++ (MS psal historicky v C++ v podstatě všechno), a nyní i v .NETu (XNA Framework). Viz http://en.wikipedia.org/wiki/Xna_Framework . Mimochodem v příští verzi Windows už prý Win32 procesy pojedou v sandboxu, a by default nebudou smět ani otevřít port. Frameworky a "velké" aplikace typu SQL Server a Exchange se sice asi ještě nějakou dobu budou psát v C++, ale trend je jasný.

C# je na chyby náchylné stejně jako C++? Super. Zkuste si v C# napsat if (i=1).

C++ kompilator vam na konkretne uvedenu konstrukciu vypise warning - ale inak je to validny zapis, pretoze v inom kontexte: napr. if (a = (b == c)) je to uzitocna vec.

Kupodivu vám to neprojde. Zkuste si v C# vytvořit pole o 10 prvcích, a zapsat do jedenáctého prvku. Kupodivu vám to neprojde. Zkuste v C# najít něco typu strcpy, u čeho nejste při analýze kódu schopen jednoznačne říci, do čeho všeho vlastně zapíšete. A pak mi vyprávějte o tom, že managed jazyky programování nikam neposouvají.

Toto su naozaj drobnosti ktore nepredstavuju ziadnu revoluciu v pisani spravneho kodu. Musite si uvedomit, ze C/C++ su "by design" type unsafe jazyky - nie je to nedokonalost ale vlastnost. VM robi vacsiu run-time kontrolu nad kodom ktory vykonava - avsak toto ma svoju cenu (nizsia efektivita, vacsia pamatova narocnost) a pokial je chyba odhalena v run-time, tak je sice mozne lepsie zadefinovat spravanie (vynimka a nie segfault) avsak faktom zostava, ze chyba v kode je. Vacsia staticka typova bezpecnost nema nic spolocne s managed kodom a je dosiahnutelna aj native jazykoch. Napr. OCaml (vlastne cela ML rodina jazykov), jazyk D a mnohe dalsie.

V C++ se C-like techniky používají mimo jiné proto, že se používat dají.

Ano, a to je zamer. Ani C++0x tato moznost nebude odstranena, pretoze je to vlastnost, nie chyba.

Hry pro XBox se píší jednak v C++ (MS psal historicky v C++ v podstatě všechno), a nyní i v .NETu (XNA Framework). Viz http://en.wikipedia.org/wiki/Xna_Framework . Mimochodem v příští verzi Windows už prý Win32 procesy pojedou v sandboxu, a by default nebudou smět ani otevřít port. Frameworky a "velké" aplikace typu SQL Server a Exchange se sice asi ještě nějakou dobu budou psát v C++, ale trend je jasný.

Nemyslim si, ze XBox prejde na nieco ine ako C++ v blizkej buducnost. Vacsina hier sa dnes pise pre niekolko platforiem napr. PC/XBox/PS2/MacOSX a preto by bol problem to postavit na MS-only technologii. Taktiez rychlost a efektivita bude v hrach vzdy dolezity faktor. Mimochodom, vyvojari hier dnes absolutne neriesia problemy ktore tu naznacujete. Skor sa snazia najst nove techniky ako vyuzit multi-core architektury. Z tohto pohladu by bol prechod pod VM krok spat, pretoze rychly GC je v multi-threaded aplikaciach jednoducho nevyrieseny problem.

Z tohto pohladu by bol prechod pod VM krok spat, pretoze rychly GC je v multi-threaded aplikaciach jednoducho nevyrieseny problem.

Velmi trefna poznamka :-) Ale to není vlastnost VM obecně, ale JVM a dalších single image VM, taková MVM nebo BEAM tím netrpí. Kromě nesrovnatelně vyšší bezpečnosti a spolehlivosti mimo jiné.

MVM je snaha spustat pamatovo izolovane ulohy v jednej VM. Ja som hovoril o aplikaciach, kde viacero vlakien zdiela celu pamat procesu - v takych pripadoch je hocijaky thread-aware GC radovo pomalsi ako rucna sprava pamate, kde je explicitne naprogramovane co sa musi a kedy lockovat a akym sposobom sa ta pamat uvolni.

Windows Mobile 2000 nemají .NET CF, footprint je 1.55MB.
Windows Mobile 2002-2003 a Windows Mobile 5 obsahují .NET CF 1 v ROM, footprint je 1.55MB (na 32-64MB zařízení akceptovatelné).
Windows Mobile 6 obsahují v ROM verzi .NET CF 2.0, které má footprint cca 2.5MB.

Pokud používáte recentní zařízení, není třeba framework instalovat, protože ho máte v ROM. Pokud je aplikace psaná pro novější .NET CF, instalace je holt nutná.

Autorům SW se v .NET CF holt dobře píše, nedá se nic dělat.

Qt to třeba umí tak, že používané části se zakompilují do aplikace. Takhle to dělá např. Opera nebo Skype a nezdá se mi, že by s tím byl takový problém, jako je s instalací nového .NET VM (u kterého stejně naprostá většina jenom zbytečně zabírá místo).