Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Vyšlo vývojové Wine 1.1.13. Obsahuje spoustu oprav v podpoře 64-bitových aplikací, různá zlepšení v Richedit, lepší podporu grafiky v Internet Exploreru a různé opravy chyb.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
_ _ ___ _____ _
| \ | |_ _| ____| |
| \| || || _| | |
| |\ || || |___|_|
|_| \_|___|_____(_)
16.1.2009 19:01
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
Co s Noem?
A ověřil sis to? :)
Sakra v pátek a 13tka. Radši to lidi nezkoušejte.
Ale Wine vychází skoro vždycky v pátek 
preco sa hrnu do 64bit aplikacii? Ved ani s 32bit to nie je ruzove...
No to je naozaj blbost! Osobne pouzivam Vistu Business 64b a 64b aplikacie idu tak ako maju a takisto 32b aplikacie idu bez problemov, respektive ak nejaky problem nastane, tak nastane aj na 32b viste... Samozrejme, ze unix/lkinux je na tom o poznanie lepsie s klasickymi aplikaciami, pretoze uz davno existuju aj v 64b, kdezto na windows nie je kazda aplikacia 64b.
No, to je prosím úplná blbost, veliké většině aplikací 32 bitů bude stačit taky klidně navždy.
Svata pravda ...
takova Transmeta uz pred nekolika rokmi uvedla 256bitovy procesor, tak at se jdou Intel a AMD se svymi 64 zahrabat :D
640K of memory should be enough for anybody
Kdopak to řekl? To se vážně nedokážete poučit z historie? 
Podle všeho nikdo.
Potíž je v tom, že 4 GB skutečně hodně je. Do 640 Kb paměti se vám ve skutečnosti nevejde ani obsáhlejší kniha, a pokud byste chtěli UCS-4, tak je to dost zoufalé. 4 GB samozřejmě nejsou dost pro nemálo aplikací, ale pro drtivou většinu ano. Na vlastní data tolik nepotřebují a ani kódu do paměti sotva kdy bude potřeba tolik mapovat.
Nejpoužívanější věci ve Wine[1] nikdy 64bitové verze nebudou potřebovat a neměly by pro ně žádný smysl. On i ten Photoshop bych neviděl tak žhavě. Nadto, kdo z vás v tuhle chvíli více jak řekněme 3 GB skutečně má? To nebude nějak významná část světa, zatím. (Jo, to nemusí platit více jak dva roky, nicméně…)
A která drtivá většina aplikací potřebuje mapovat do paměti gigabajtové soubory?
No, to sice může, ale pochybuju, že jediné co s tím ty editory dělají je, že by namapovaly soubor do paměti, nejspíš velkou část té paměti skutečně i budou potřebovat, a pak to stejně není reálné.
Krom toho tyhle aplikace musí umět 32bitové systémy ještě hodně dlouho, takže to stejně musí být naprogramované.
Aplikační programátor si to samozřejmě psát nebude, neb by byl tak trošku vůl, kdyby psal jenom v céčku s unixovým API.
Zoufalý anachronismus bych tomu neříkal (pokud teda vlastně ještě uvážíme, že typicky používáme rozdělení 3/1, tak je to ještě horší), třeba já ani 64bitový procesor vůbec nemám a ještě dlouho si ho koupit (na laptopu) neplánuju, protože to pro mne prostě není důležité. A ještě hodně dlouho nebude, takže teď se s Wine soustředit jen na 64bitové aplikace by byl holý nerozum, to ještě hezkou řádku let nebude třeba.
A ještě hodně dlouho nebude, takže teď se s Wine soustředit jen na 64bitové aplikace by byl holý nerozum, to ještě hezkou řádku let nebude třeba.Lepší se probudit dřív než zaspat…
To ano, ale priznejme si, ze vyvojari Wine maji pred sebou jeste hodne jine prace ... a pak uz zalezi jen na prioritach ...
IMHO vhodny zacatek snahy o 64bitove Wine je proste psat novy kod s vedomim, ze by mel jednou fungovat i na 64bitech.
třeba já ani 64bitový procesor vůbec nemám […] takže teď se s Wine soustředit jen na 64bitové aplikace by byl holý nerozum, to ještě hezkou řádku let nebude třebaTudy ne, přátelé
Jinak Wine mi přijde v tomhle ohledu celkem nezajímavé (a souhlasím s tím, že je přinejmenším podivné pokoušet se o 64 bitů, když jim ještě pořádně nefunguje ani 32 ), ale jakmile budu chtít spustit jednu jedinou 64bitovou aplikaci, potřebuju mít 64bitový procesor i systém. Tak například mne by zajímala 64bitová Java :-P
No, tak pozor, já Wine nepoužívám prakticky vůbec, hlavně. Já usuzuju podle té statistiky co jsem odkazoval, že nemá smysl volat po 64bitovém Wine, když co potřebujeme teď (a ještě dlouho potřebovat budeme) je spolehlivé fungování aplikací 32bitových. A že to ani nepřinese žádný pokrok.
No a pokud nemluvíme o Wine, tak asi těžko něco komentovat. Žádné aplikace které by skutečně potřebovaly adresovat více jak 4 GB paměti asi nepoužívám, a myslím, že nějakou dobu nebudu. Ani když beru v potaz to mapování souborů -- jak tu i z jiného příspěvku vyplynulo, ta aplikace pak (celkem logicky) má tendence tu paměť skutečně využívat a potřebovat, a já fyzicky stejně více jak gigabajt nemám (pravda, tady bych asi něco přidat mohl, už v dohledné době, ale taky to nijak nehoří).
Jinak já samozřejmě nepopírám, že potřeba 64bitových aplikací existuje (a i příklady bych znal), ale nebál bych se zpochybnit, že to není případ desktopů většiny diskutujích (a většiny uživatelů wine). Honba po 64bitovém flashi mi například přijde zcela malicherná, když stejně ty procesory 32bitové režimy umí (ty pro které flash je). Ano, samozřejmě, další procesor co si koupím už 64bitový docela určitě bude (stejně už se nejspíš ani nebudou prodávat žádné jiné), ovšem nekoupím si ho asi proto, že bude 64bitový, ale proto, že budu potřebovat z nějakého důvodu prostě nový počítač. A kdoví co to bude za krám… Možná to ani nebude nic Intel-like a s Wine stejně ostrouhám, ať už bude 32bitové či jaké chce.
Je to divný. Moje zkušenost (na widlích) byla taková, že i sekvenční přístup od začátku do konce byl při namapování o dost rychlejší. Při náhodném přístupu bude namapování ještě efektivnější, protože cachování je podporováno operačním systémem (resp. OS ví, že to je vlastně disková cache) a dokonce hardwarem.
Jediný důvod zpomalení, který mě napadá, je držet v tomto prostoru rychle se měnící data. Ta jsou pak samozřejmě ukládána na disk a pomalejší.
(Jinak to [1] měl být odkaz na http://appdb.winehq.org/votestats.php, aby bylo zřejmé co myslím, jenom jsem to tam zapomněl napsat. )
17.1.2009 11:12
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Protože 32bit není budoucnost
Důvod?
17.1.2009 11:15
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Osobne pouzivam aj 16b aplikacie a su to jedni z najlepsie napisanych softov. Stabilne a rychle... Dnesny svet okolo pocitacov sa nesustredi na rychlost a stabilitu ale na vyzor a efekty... 
Desktopový Atomy (230 a 330) mají taky 64b
Na bežné browsenie po internete a počúvanie hudby je to možno strašne veľa, ale napríklad u vecí ako editovanie obrázkov vo vysokom rozlíšení, hry, virtuálne mašiny a plno iných vecí ramky nikdy nie je dosť...
"640kB ought to be enough for anybody"
Ja som hovoril o potrebe viac než 4GB všeobecne, nie vo wine...
A je logické, že dnes taká hra nie je, totiž by si ju nikto nekúpil, lebo len málo ľudí má na to stroj. Je ale viac než jasné, že za pár rokov budú také hry bežné, tie veľké a veľmi detailné prostredia musia byť niekde uložené, a neustále Loading... obrazovky nie sú práve najlepšie riešenie...
Takisto photoshop a podobné progarmy toľko pamäte určite využijú...
Proste prechod na 64bit architektúru na desktopoch je skôr či neskôr nevyhnutný, s Windows 7 to asi ešte taký veľký podiel nebude, ale imho už pri ďalšej verzii win budú výrobcovia hw predávať pc predinštalované s x86_64 verziou...
17.1.2009 18:59
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
editovanie obrázkov vo vysokom rozlíšení
Nevím kolik má obrázek ve vysokém rozlišení, ale připomínám, že 4GB je pro rozpakovaný klasický 24-bitový RGB obraz místo asi o velikosti 1431 Megapixelů(samozřejmě mínus operační systém, editovací program a podobné smetí a mínus provedené změny v obrázku).
hry
Ještě jsem neviděl hru která by si alokovala pro svůj proces 4GB paměťového prostoru. Jinak znovu připomínám, že herní data(textury,modely,zvuky,…) patří buď do VIDEORAM nebo na harddisk.
virtuálne mašiny
Nezlobte se na mě, ale spouštět Visty a v nich VirtualPC 2007 a v jednom VM mít linuxovou distribuci pro routovaní a v druhé mašině mít Debian pro serverové služby jen protože to jinak neumím a celé to ještě nazývat serverem…
a plno iných vecí
A také uznávám, že takové věci existují.
ramky nikdy nie je dosť...
Pokud ji někdo jen alokuje, ale pak neuvolňuje, tak mi nezbývá než téže souhlasit. Stejně jako se vším(z.B. diskové místo).
Nevím kolik má obrázek ve vysokém rozlišení, ale připomínám, že 4GB je pro rozpakovaný klasický 24-bitový RGB obraz místo asi o velikosti 1431 Megapixelů(samozřejmě mínus operační systém, editovací program a podobné smetí a mínus provedené změny v obrázku).
Lenže pri bežnej práci v pamäti nie je len samotný obrázok, ale viac vrstiev, buffer úprav pre rýchle undo/redo/manipulácie, a podobné veci, a to často zaberá viac miesta než samotný hotový obrázok...
Nevím kolik má obrázek ve vysokém rozlišení, ale připomínám, že 4GB je pro rozpakovaný klasický 24-bitový RGB obraz místo asi o velikosti 1431 Megapixelů(samozřejmě mínus operační systém, editovací program a podobné smetí a mínus provedené změny v obrázku).
Tohle platí pokud ten obrázek jenom otevřeš. Stačí pár úprav a hned se to vyhoupne nahoru.
Jen tak mimochodem. Kdybych si teď kupoval počítač, tak do něj koupím alespoň 8GB paměti (ono totiž desek s podporou více ram není tolik a jsou dost drahé). Protože při tvorbě trochu větších panoramat je to sakra znát. Jednou mi takové panorama sežralo 6 GB virtuální paměti, nakonec jsem ho smazal, protože jsem ho nemohl otevřít. Bylo totiž moc velké (přece jenom panorama, které má ve zkomprimované podobě 300 MB se blbě vejde do 512 MB RAM.
Nevím kolik má obrázek ve vysokém rozlišení, ale připomínám, že 4GB je pro rozpakovaný klasický 24-bitový RGB obraz místo asi o velikosti 1431 Megapixelů(samozřejmě mínus operační systém, editovací program a podobné smetí a mínus provedené změny v obrázku).Je to už několik roků (nevím, odhadem tak tři, pět?), co jsem kdesi četl rozhovor s Ladislavem Kamarádem (předpokládám nemusím představovat), který už v té době měl počítač s 8 GB paměti. Ptáte se proč?
... Kdo potřebuje víc paměti, a to je v dnešní době hodně lidí, tak je nucen přejít na 64bit, aby jí byl schopen celou pěkně alokovat bez různých emulací, které jen onu alokaci zpomalují.
18.1.2009 00:24
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Hmm, ten obrázek byl předpokládám jen takový náznak.
Byl.
Vážně si myslíš, že si někdo hraje jen s jedním obrázkem najednou? A nehledě na aplikaci různých efektů na ty obrázky, jenž žerou paměť jak zběsilý.
Uznávám…např. chvilku si edituju dva obrázky o rozlišení 1280x1024 v GIMPu a 140MB alokovaných. Na druhou stranu je dobré si uvědomit co ty data vlastně jsou a kolik z nich skutečně bude potřeba a je jich tam jen z toho důvodu, že mohou být v budoucnu potřebné a přitom se nikdy nemusí použít. Je to přibližně stejné jako diskový kešovací mechanismus jádra až na ten detail, že chybí zařízení pro zpětný zápis. A IHMO pokud už nějaký program počítá s tím, že dovolí editovat obrázky o takových rozměrech, tak by měl trošku zlepšit mechanismus udržování těch dat v paměti. Třeba udržováním v paměti pouze rozdílů dvou akcí, nějakou rychlou kompresí v paměti(držet 20Megapixelový bílý flek v paměti asi také není jen tak) a nebo prostě dovolit editovat obrázek v menším rozlišení a výsledek/požadavek nějaké oblasti nakonec vyrendrovat až jako výsledný soubor.
A to jsem jen u obrázků. Teď si vem, že takový člověk nemá otevřený jen nějaký program na úpravu obrázků.
Že ty si na PC vystačíš se dvouma gigama paměti ještě neznamená, že víc GB je pro ostatní zbytečnost.
Neříkám, že jsou víc jak 4GB pro ostatní zbytečnost, ale 4294967296 bytů jsou prostě 4294967296 bytů a ne jen nějaké plácnutí do vody. A určitě to není jen nějaké místo pro bastl a bordel jak se snaží naznačit Jarda.(To, že bez 64-bitu si nebudu moct zítra dovolit vstát ani z postele radši ani neberu v úvahu).
Mám otevřený dva dokumenty v ooo, ke kterým přistupuji permanentně. Mám otevřen thunderbird s několika tisíci emaily, ve kterých se věčně hrabu. K tomu firefox se standardními 6 záložkami (nutné k práci, když browsím a něco hledám, je jich samozřejmě mnohem více). Dále dosta často gimp a v něm několik obrázků, dřív jsem i zároveň hodně používal dia. Dále několik ssh session v yakuake, VirtualBox a v něm winxp na programy typu VisualFoxPro, Helios CLA IQ, ESXi konzoli apod. programy okolo. Několik session s rdesktop, vncviewer, 2x vmware server, se kterými jsi pernamentně připojen na vzádelné servery, pidgin, amarok apod. drobnosti. Mohu ti říci, že toto je má každodenní obyčejná práce a nechtěj vědět, co mám doma na desktopu
Aneb normální pracovní den normálního uživatele. Asi opravdu někdy nahraju co celý den dělá takový normální uživatel jako je moje ségra nebo můj otec, kterému nejvíce zabírají v paměti všechny ty nezbytné pixmapy a imbecilní animované figurky z ICQ6 bez kterých se prostě nejde obejít.
Jen blbé kancelářské stroje v naší práci si vemou skoro gigo paměti
Tak to asi něco bude špatně.
Zřejmě si určitě ani nedovedeš představit domácího uživatele, jenž si chce třeba upravovat video z dovolených apod.
A to to video celé rozbaluje do paměti?
Podle mně jsi slepý a zahleděný jen do sebe a nevidíš, že jde dělat hafo jiných věcí.
Nepopírám a rád si to nechám osvětlit a třeba nad tím i popřemýšlím a nebudu to hned popírat jen tak z principu(nebo můžu alespoň slíbit, že se o to budu snažit), takže směle
Kolikrát už tu bylo toto téma a stále se objevují lidé, kteří tvrdí, že víc jak určité množství paměti (věčinou takové, které sami používají) je plně dostačující.
Souhlasím, že je plně dostačující, ale pro tebe
, podle sebe soudím tebe. Jen by mě zajímalo zda-li je to opravdu taková nutnost a není to prostě jen důsledek toho, že lidi jsou čím dál tím línější(O tom případovi co si nainstaloval Widle a na ně dvě virtuální mašiny aby dosáhl serveru i routeru na jednom stroji z toho důvodu aby se nemusel pustit myši a nedejbože snad něco naučit jsem nekecal…pokud bude nejvyšší potřeba tak mám nachystaný i link) a hlavně když vývojářův čas je drahý. Samozřejmě pro někoho kdo jen alokuje/ukládá a přitom neuvolňuje/nemaže jsou 4GB paměti/1TB diskového místa málo stejně tak jako jakékoliv množství, protože ho časem nevyhnutelně zaplní. A to asi i pro toho kdo nemůže seriózně pracovat běž všech těch coolovějších, animovanějších a plastičtějších tlačítek a efektů. Prostě žádám trochu sebereflexe(,když už je teda ta krize) a ne modé z nebe proboha…a nebo jsem opravdu jen zaslepenec zahleděný do sebe.
PS: myslím si, že už ani nemáš představu, jak vypadá takový domácí uživatel a stále vidíš jen někoho z 98, co minutu hledá na klávesnici písmeno "T"
Co pozoruju na lidech které znám já, tak je to rok co rok horší a někteří už se snad radši ani nesnaží, byť jen náznakem ,pokoušet hledat klávesnici, natož písmeno "T".
Gimp to takhle řeší. Minimálně v řadě 2.6.x ano. Zkuste si vyzkoušet nějakou starší verzi a to teprve něco uvidíšUznávám…např. chvilku si edituju dva obrázky o rozlišení 1280x1024 v GIMPu a 140MB alokovaných. Na druhou stranu je dobré si uvědomit co ty data vlastně jsou a kolik z nich skutečně bude potřeba a je jich tam jen z toho důvodu, že mohou být v budoucnu potřebné a přitom se nikdy nemusí použít. Je to přibližně stejné jako diskový kešovací mechanismus jádra až na ten detail, že chybí zařízení pro zpětný zápis. A IHMO pokud už nějaký program počítá s tím, že dovolí editovat obrázky o takových rozměrech, tak by měl trošku zlepšit mechanismus udržování těch dat v paměti. Třeba udržováním v paměti pouze rozdílů dvou akcí, nějakou rychlou kompresí v paměti(držet 20Megapixelový bílý flek v paměti asi také není jen tak) a nebo prostě dovolit editovat obrázek v menším rozlišení a výsledek/požadavek nějaké oblasti nakonec vyrendrovat až jako výsledný soubor.
. Mimochodem, historie se dá v gimpu smazat, je na to tlačítko v "Undo history dialog".
) a ve finále je pak zmenšuji jako ukázku ostatním apod... Word 2007 si veme ve windows XP přes 100MiB (na Vistách si veme 2MiB), AVG7.5 si veme 20MiB, když zapneš antispyware, tak si veme 150MiB. Informační systém, explorer, x otevřených dokumentů a je to tam jak nic ...Já ale needituji dva obrázky v nějakém rozlišení 1280x1024. Ale několilk obrázků najednou a to v rozlišení...Ono to ani nemusí být několik obrázků najednou. Stačí jeden s 10 maskovanými vrstvami…
a pak 32bit aplikace mají většinou ubohé optimalizace (i386-i686), kdežto 64bit aplikace mají lepší a jsou rychlejšíPočkej pár let a ono se i IA64 rozdělí na jednotlivé verze
.
4GB je totiž zatraceně málo (vím, že existuje PAE, ale to stejně aplikaci neumožní použít víc než 4GB paměti)4GB na jednu aplikaci je teda pro obecné použití dost hodně, pokud nemáš celý systém v RAMDISKu
.
Tak ono stačí bohatě dnes například rozdíl ve verzi SSE instrukcí, se kterými se kompiluje amd64 v Linuxu. Standardně se používají pouze do verze SSE2, přitom jsou dnešní procesory o dost dál a SSE2 je záležitost celkem stará. Přičemž zrovna nasazení lepších SSE je celkem vidět třeba u operací s multimédii, pokud je tedy podpora i v aplikaci...a pak 32bit aplikace mají většinou ubohé optimalizace (i386-i686), kdežto 64bit aplikace mají lepší a jsou rychlejšíPočkej pár let a ono se i IA64 rozdělí na jednotlivé verze
.
17.1.2009 12:46
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
4GB je totiž zatraceně málo
Já mam 2GB RAMky a ještě se mi je nepodařilo zaplnit. A to ani nevypínám zbytečné služby a aplikace,nevyhazuju zbytečné moduly a nekompiluju si jádro na míru. Věřím, že kdybych něco takového udělal, tak nebude problém se dostat hluboko pod 100MB využití paměti při startu.
a pak 32bit aplikace mají většinou ubohé optimalizace (i386-i686)
Existuje něco jako -march a -mtune, ale uznávám, že pro ty co si věci nekompilují sami je x86_64 lepší volba a to prostě protože je to následovník mikroarchitektury i686.
kdežto 64bit aplikace mají lepší a jsou rychlejší (pokud jsou tedy napsané správně a né prasáckým způsobem).
Je možno trochu rozvést?
Dneska už mají snad všechny počítače 64bit CPU
A všechny tyto procesory jsou zpětné kompatibilní až do dob 16-bitů.
A všechny tyto procesory jsou zpětné kompatibilní až do dob 16-bitů.Možná i 8-bitů (pokud podporují úplně všechny x86 instrukce):
mov ah,bh
17.1.2009 16:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Horní a dolní polovina 16-bitového registru je tam také z toho důvodu aby se daly používat 8-bitové datové typy a zbytečně se neplýtvalo. To o čem se bavím já je stav ve které se nacházejí dnešní nejmodernější osmi jádrové, 64-bitové, třemi kusy suchého ledu chlazené procesory po zapnutí a co mě také pěkně tlačí do žeber aneb zpětná kompatibilita s Intel 80186. (viz. Real Mode)
. Nicméně i ta 8-bitová část se používala z důvodů aspoň malé kompatibility (třeba 8088 -> 8080).
17.1.2009 19:15
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Jasně už si rozumíme, ty jsi myslel architekturu, já myslel nejmenší datový typ, s kterým se dají dělat datové operace
Vzhledem k tomu, že v céčku existuje něco jako bitové pole(ne že by se snad dnes nějak hromadně využívaly, ale stačí že ta možnost existuje), tak něco jako nejmenší datový typ neřeším.
Nicméně i ta 8-bitová část se používala
Se nepoužívala, ale se dnes používá. Třeba datový typ char, i když nevím jak se zarovnávájí. Neznám nikoho kdo by třeba pro enumy používal plných 64-bitů.
zpětná kompatibilita s Intel 80186nechci byt hnidopich, ale nemyslels 8086/8088? 80186 se v PC moc nepouzivala, pokud vubec...
16.1.2009 19:29
16.1.2009 22:43
17.1.2009 01:23
17.1.2009 02:41
19.1.2009 07:20
18.1.2009 09:46
18.1.2009 17:07
17.1.2009 20:01
17.1.2009 12:27
17.1.2009 22:52
18.1.2009 13:01
18.1.2009 14:26