ami igazából idő és energia kérdése, a tudás megvan hozzá a világban.
Vagyis azt akarod mondani, hogy valaki _más_ csessze el az idejét arra, hogy egy senki által nem használt, egy évtizede nem támogatott platformra fordítani képes eszközökre backportolja a mai kódokat azért, hogy _neked_ kényelmes legyen?
Hogy hogyan, meg miként = részletkérdés
Ha részletkérdés, akkor hajrá, ülj le a gép elé és állj neki. Ha küldesz vissza patchet, ami nem túl zavaró, a projektek valszeg be is olvasztják.
media player classic régi verziói
Security risk.
winamp (igen, tud videót)
Ja, 2013-ban befejezték a fejleszték, beszántották sóval a fejlesztők helyét és biztos, ami biztos fel is gyújtották az egészet. Pozitív és előremutató.
[qoute]max. egy kicsit hákolni kell
Továbbra is: hajrá.
Az remélem meg van, hogy a VLC-nél egy olyan megoldást írtam, amit a fejlesztő a saját oldalán feltüntet, mint hivatalos és a legfrissebb verzióra is igaz.
SSL: OpenSSL mindent tud, amit említettél és megfelelő MSVC verzióval le tudod forgatni Windows 98-ra.
És utána minden rendszerkomponenst, ami egyébként az MS crypto API-t használja, újraforgats... oh, ja, nem. Vagyis _minden_, ami nem támogatja expliciten a pre-NT windowsokat, bukó. Többek közt a pre-NT windowsok.
NTFS: van kükön sysinternals driver, ha meg sux, megoldod mással, pl total commander plugin
Read-only support. És csak jó esetben nem lesz destruktív (igen, ezeket a köröket az ntfs3g is végig futotta, amit közben karban is tartanak... mert egyébként az NTFS sem ugyanaz az NTFS egy Win10-ben, mint egy Win2k-ban vagy NT-ben volt.)
a gép hardverileg képes lenne ezeket a formátumokat megnyitni ... Tehát változatlanul szoftveres probléma.
Oké, miről beszélünk. Arról, hogy egy 7zip kilistázza neked, hogy milyen fájlok vannak benne, vagy arról, hogy valami azt helyesen meg fogja jeleníteni? De ha meg csak egyszerű szoftveres probléma az, hogy az MSO fájlok helyesen nyíljanak meg és ezt te ennyire egyszerűen megoldod, akkor hagyd a francba a P3-ast, fizetek neked egy komoly, mai munkaállomást, ülj le, kódolj és oldd meg a szoftveres problémát mondjuk az LO kódbázisában.
----
És akkor egy kicsit komolyabban:
1) tudod, miért nem fut 286-on a Linux kernel? Mert több olyan feature hiányzik belőle, amire épít a kernel. Meg lehetne kerülni (ott van az ELKS project), de nagyon rétegigény, hogy 3-5-686 alatt használja valaki. A legtöbb disztró már 686-ot ért x86 alatt, de vannak x64-only disztrók. Mert van alájuk hardware.
2) és hogy miért van alájuk hardware? Mert a gyártók szeretnek időnként fogni egy-egy filctollat és átfeliratozni a dolgait. Nem, komoly változások (nem feltétlenül javulás, fejlődés) vannak HW szinten. Pl. próbálj meg a P3-assal AES-t kódolni, aztán próbáld meg ugyanezt egy "modern" (2010 körüli - az is hét éves!) CPU-val szerelt gépen.
3) és mivel van alájuk HW és a rajtuk futó kernel miatt már eléggé valószínű, hogy van támogatás egy-egy CPU feature-re/utasításkészletre, a "webdizájnerek" aljas és szemét módon nekiállnak használni.
4) innentől két eset van: hagynak legacy code path-et benne (pl. AES-nél ha HW utasítással nem megy, akkor megoldjuk szoftverből, egy nagyságrenddel lassabban, SSE-nél hasonlóan), ami bloathoz fog vezetni és a támogatási mátrix exponenciális növekedése miatt tesztelési katasztrófa lesz, vagy kidobják a francba a szoftveres implementációt, amikor feleslegessé válik. Ha opensource és úgy támad kedved, backportolhatod, hajrá. Ha nem opensource (pl.: MS Crypto API providerek), ígyjártál.
Az SSE-t egyébként nem ok nélkül írtam: valamikor a 1x (2011-2012 környékén, ha jól emlékszem) verziónál a Flash (hopsz, zárt szoftver) elkezdett dependelni az SSE2-re (Pentium 4 utasításkészlet, 2000-es évek eleje!) - vagyis közel egy évtized után volt képük használni egy CPU-képességet. És igen, zárt szoftver, úgyhogy bukó. Sok Athlon XP tulaj túrta akkoriban a netet.
Az meg, hogy a szoftverek 1) nem mindent írnak újra nulláról, hanem alsóbb rétegek absztrakcióit használják és 2) ezek az alsóbb rétegek sajnos időnként változnak, szintén nem újdonság. A Winnél is mondhatnám mondjuk a grafikus alrendszert (98 óta legalább háromszor lecserélték...) [oh, btw, ez egyben a nyomtató alrendszerre is kihat, mert együtt mozognak...], de egy közelebbi példa: a Wayland-et tudod miért kezdték el fejleszteni? Mert ott volt a szoftveres X11, ami a 80-as években valóban egy state-of-the-art rendszer volt, de 20+ év távlatából kicsit mások voltak az elvárások egy graf. rendszerrel szemben, mint hogy tudjon vonalakat rajzolni, glyhp infókat letölteni, hogy hálózaton állítólag transzparens legyen. Egy modern X kliens véletlenül se küld grafikus primitíveket, nem az X-el rajzoltatja ki a fontokat, hanem megfelelő libbel, és mivel ahhoz, hogy gyors legyen, gyakorlatilag kernel szintig optimális útvonalat kell bejárnia, csak mindenféle legacy kódok miatt lesz network-transparent. Igen, szanaszét lehet ilyenkor taknyolni a dolgokat (és teljesen jól is csinálták meg, mindent szépen modulokba szervezve, amennyire lehet visszafelé kompatibilisen), de van az a pont, amikor az egészet ki kell kukázni, mert a másik megoldás mindenkinek rossz lesz.
És ez a kukázás a Win98-nál 2006-ban jött el.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)