Bővülő média támogatás

Bekerült az mkv videó formátum, illetve az srt, ssa, ass feliratok külső szoftverek nélküli támogatása!

Reklámok

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.