Windows Runtime újdonságok

Elérhetővé vált az alkalmazások közötti és az asztal és alkalmazás közötti fogd és vidd (drag-and-drop), amit a webes email fiók csatolásoknál vagy webes OneDrive fájlfeltöltésnél már megszokhattunk.
Az InkCanvas és a hozzá kapcsolódó osztályok a kézírás és rajzolási felületnek adnak egyszerű, de nagy tudású vezérlőt, mely nem csak a bevitelre szolgál, hanem a feldolgozásra és a renderelésre is.
A MediaProcessingTrigger API lehetőséget ad a háttérben való transzkódolásra. Ez azért fontos, mert korábban nagyon sok megkötés volt a háttérben való futási lehetőségekre.

Természetesen még nagyon sok más újítás is érkezik, de most ezeket találtam érdekesnek.

 

Alkalmazkodás a beviteli lehetőségekhez

Futásidőben. Az előzetes Windows 10 SDK alapján úgy néz ki, a felhasználói felületen elhelyezett vezérlők futásidőben fogják eldönteni, hogy milyen beviteli mód várható a felhasználótól, és annak megfelelően jelennek meg a képernyőn.
A vezérlők automatizmusa mellett az új “API contracts” lesz a fejlesztők segítségére. Ezzel például futásidőben lekérdezhető, hogy az eszköz, amin fut az alkalmazás milyen hardveres gombokkal rendelkezik, már ha rendelkezik, így mindig a maximális felhasználói élmény garantálható. Az API contracts jóval több lehetőséget ad a fejlesztők kezébe, mint csupán az operációs rendszer kiadásának lekérdezése (telefon, IoT, asztali).

 

Egyszerűbb fejlesztés a gyártóknak

A felhasználók csábítása az egyik fontos szempont egy termék felfuttatásánál, de sosem feledkezhetünk meg a gyártókról. Ők terveznek és készítenek új eszközöket, amelyeken a Windows 10 a felhasználók elé kerül, ők készítik a drivereket, hogy az eszközeik megfelelően működjenek, ők adják el közvetve az opreációs rendszert!
Hogy megkönnyítse a dolgukat, a Microsoft négy fő célt tűzött ki:

  1. Egyszerűsíteni kell a driver fejlesztést,
  2. Csökkenteni kell egy eszköz fejlesztési és gyártási költségeit,
  3. Támogatni kell a hardverek Windowson való fejlesztését és tesztelését,
  4. Támogatni kell az alacsony erőforrású célhardverekre való telepítést.

A driver fejlesztést a Windows Driver Kit és a Device Driver Interface segíti elő, melyek minden eszközön egységes részét képezik a Windows 10-nek. Tehát egy univerzális driverrel lefedhető a teljes Windows eszközcsalád. További segítség a Windows Device Framework, mely egyaránt elősegíti a kernel – és felhasználói módban futó driverek készítését. (Ez a keretrendszer a GitHubon is elérhető)
A Fast Flash Update-tel egy olyan image formátumot alkottak, ami lehetővé teszi a biztonságos, szektor szintű telepítést. A WDK segítségével tudjuk konfigurálni az image fájlt, illetve alkalmazások előtelepítését is megtehetjük vele. Egyszerre nyolc USB-s eszköz telepítését támogatja ez a formátum, illetve későbbi beszerelésre szánt háttértárak teljes előkészítését (partícionálás, formázás, telepítés).
A fejlesztői panelek támogatására a Windows 10 Board Support Packages szolgál, amely csomagokat az univerzális driverek segítségével fejlesztenek. Jelenleg a legismertebb ilyen eszközök az Intel Sharks Cove és MinnowBoard MAX, a Raspberry Pi 2, és a Qualcomm Dragonboard 410C.
Az alacsony erőforrással rendelkező cél eszközök ugyan a motorháztető alatt ugyanazt a Windowst kapják, amit a telefonok és asztali gépek, de hiányoznak a beépített alkalmazások és más megszokott programok. Mindezek amúgy is szükségtelenek lennének, és ezzel is csökkenthető a hardver igény. A működést a már említett univerzális driverek és univerzális alkalmazások futtathatósága segíti. Egy ilyen eszközt használó cég az általa fejlesztett univerzális alkalmazása fogja a felhasználói élményt nyújtani, mivel beállítás után a rendszer automatikusan az “alkalmazásba” fog bootolni.

Forrás: Windows Blog.

 

Miért igényel kisebb tárkapacitást a Windows 10?

Már régóta probléma, hogy a Windows nagyon megnőtt és sok tárhelyet elfoglal előlünk. Ennek javítására több trükköt is bevetett már a Microsoft, többek között a telepítő médiáról nem mindent másol fel (ezért is fordul bizonyos funkciók bekapcsolásához a Windows Update-hez), illetve nyomtató és egyéb driverek összevonásra kerültek, és a lehető legtöbb eszközt egy közös meghajtóval szolgálnak ki.
A telefonok erőteljesen korlátozott tárhelyei miatt, és mert nagyon sok funkció ott úgy sem érhető el (nem lenne értelme), egy jóval kisebb és tömörített rendszer érhető el.
A Windows 10 érkezésével további javulást ígér a Microsoft a következők szerint. Egyrészt a rendszerfájlok hatékonyabb tömörítésével 1,5 – 2,6 GB megtakarítást attól függően, hogy 32 vagy 64 bites Windows használunk, másrészt ezentúl a helyreállítási funkciókhoz nem fog külön image-t használni, így újabb 4+ GB felszabadulhat. Mivel ez utóbbi a telefonoknál már nagyon jól működik, így ez csak a többi rendszeren lesz újítás.
A helymegtakarítás szépen hangzik, de hogyan hat majd mindez a teljesítményre? A kérdés jogos, hiszen a tömörített fájlokat előbb ki kell csomagolni, és csak utána tudjuk használni. Nos, a válasz az, hogy amikor egy korábi Windows verzióról upgrade-elünk Windows 10-re, akkor telepítéskor automatikusan meg fogja vizsgálni az eszköz RAM mennyiségét és a processzor teljesítményét (más tényezők mellett) és ezek függvényében automatikusan fogja szabályozni a tömörítés mértékét úgy, hogy a felhasználó számára észrevehetetlen legyen a különbség. Új telepítés esetén a gyártónak kell a méréseket és a beállítást elvégeznie.
Hamár a rendszer fájlokra megfelelően be lett állítve a tömörítés, akkor a Store-os alkalmazások is profitálnak belőle, vagyis több hely jut nekik, illetve azok is tömörítésre kerülnek.
Néhányaknak eszébe juthat a WIMBOOT, ami néhány eszközön került bevetésre, és bár nagyon hasznos a kis tárhellyel rendelkezők számára, most nehézzé teszi a Windows 10-e való upgrade-et, hiszen valahogy meg kell oldani, hogy elférjen a telepítő a meglévő rendszer mellé, hogy a telepítés közben bekövetkező esetleges problémák (pl.: áramszünet) esetén a visszaállítás megtörténhessen, és ne legyen adatvesztés.
A helyreállítást a rendszer saját magán (magából) végzi el, ezért nincs szükség újratelepíteni az összes frissítést. Arra az esetre, ha akkora sérülés keletkezne, hogy a refres vagy reset funkciókat nem érjük el, továbbra is készíthetünk saját helyreállító képfájlt.

Forrás: Windows Blog.

 

Windows 10

Az utóbbi időben elhanyagoltam a blogolást, de a Windows 10 írásra sarkalt.
Elérkezett az az időszak a Microsoftnál, ami a Linux világában már elég régóta jelen van: egy rendszer mindenhova! A Windows 8-nál már láttuk, hogy az ARM alapú tabletek sem akadály, sőt a telefonok világában is elindultak a részesedési csatában (a legtöbben talán nem tudják, de ebből is készültek beágyazott rendszerekre szánt kiadások). A kezdeményezés világos volt, mindössze az maradt kérdés, hogy hány lépcsőfok lesz a teljesen azonos rendszerek eljöveteléig. Ha a Windows 8.1 külön lépcsőfoknak számít, akkor a 8-hoz képest a második már a cél. A Windows 10 szó szerint minden eszközön képes lesz futni, a legkisebbtől a legnagyobbig, “bármilyen” architektúráról is legyen szó. Az persze nem elég, hogy fut rajtuk, a felhasználóknak alkalmazások is kellenek, amelyeket a közös Store-ból tölthetnek le. Az “Univerzális” alkalmazások ugyan már egy ideje választhatóak a fejlesztők részéről, hogy kevés munkával telefonra és asztali rendszerre is elérhetővé tegyék, amit készítenek, de az API csak részben volt átfedésben, így a felhasználói felületen kívül is rengeteg dolguk akadt az átírásban. A Windows 10 esetében Nem csak a telefonok, tabletek és PC-k, hanem az XBOX is az Univerzális alkalmazások célterülete, méghozzá teljesen közös API-val, és a felületek kialakításában is nagy segítséget ad a Microsoft azzal, hogy a különböző vezérlőket hozzáigazítja az eszközhöz, így mindenhol olyan felületet kap a felhasználó, amit könnyen tud kezelni. Persze a nem beépített vezérlők esetén egy szinten a fejlesztőnek magának kell gondoskodnia a “reszponziv” design helyes működéséről.
A robotok, vezérlők, és hasonló rendszereknél természetesen nem a közös Store lesz a fő érv, hanem a biztonsági funkciók, új képességek, könnyebb fejlesztés és üzemeltetés, illetve a natív gép – gép kommunikáció és gép – felhő kommunikáció támogatása.