Komprimeringalgoritme i Windows begrenses stadig av støtten for en «eldgammel» prosessor

[Harald Brombach (digi.no)]

Mer enn 15 år etter at støtten egentlig ble nedlagt.

Komprimeringalgoritme i Windows begrenses stadig av støtten for en «eldgammel» prosessor

[nebrewfoz]

Så, hvor mye mindre ville de komprimerte filene ha blitt dersom man skrev om koden og droppet støtten for disse gamle CPU-arkitekturene?

 

Jeg vil gjerne vite det før jeg finner fram høygaffelen, tenner faklene og organiserer protesttoget mot Microsofts onde borg.

[Frobe]

Jeg husker filsystemkomprimering var spennende da det ble lanser med DOS 6.2 på begynnelsen av 90-tallet, men jeg droppet det fort da fordelene ikke var store nok i forhold til å kjøpe en større harddisk.

https://en.wikipedia.org/wiki/DriveSpace

[Horten Market]

Høres ut som en "quick and dirty"-løsning fordi man ikke orket å bruke tid på å skrive kode som sjekket mulighetene til CPU. Kanskje det var morsommere å kode Minesveiper.

 

Ellers bør Chen ta en titt på hvordan Windows har eset ut noe helt enormt, som egenhendig gjør en komprimeringsfunksjon på systemnivå aktuell igjen.

[Emancipate]

Høres ut som en "quick and dirty"-løsning fordi man ikke orket å bruke tid på å skrive kode som sjekket mulighetene til CPU. Kanskje det var morsommere å kode Minesveiper.

Som det står, det hjelper ikke om CPU A har muligheten til å komprimere bedre, fordi fila fra CPU A skal kunne dekomprimeres på CPU B.

[Horten Market]

Som det står, det hjelper ikke om CPU A har muligheten til å komprimere bedre, fordi fila fra CPU A skal kunne dekomprimeres på CPU B.

Men det kan den jo, det er bare snakk om hvor lang tid den bruker. Dessuten, dette er altså komprimering på systemnivå, ikke enkeltfiler. Det dreier seg altså ikke om filer som sendes hit og dit, men filer som dekomprimeres i det samme systemet som de ble komprimerert i. Da oppstår problemet kun ved bytte av CPU-arkitektur. Normale forsiktighetsregler tilsier da uansett at man dekomprimerer før så inngripende endringer gjøres.

Endret 3. november 2016 av Horten Market

[Emancipate]

Men det kan den jo, det er bare snakk om hvor lang tid den bruker.

Og hvis de gjorde det på en mer effektiv måte, så ble tidsbruken uakseptabel.

 

Normale forsiktighetsregler tilsier da uansett at man dekomprimerer før så inngripende endringer gjøres.

Man har normalt ikke plass til å dekomprimere, det er derfor man har komprimert. Og problemet er ikke at man bytter cpu-arkitektur på PCen, men bruker disken i en annen PC. Det kan være mer eller mindre eksterne disker som ikke er system-disken.

[Horten Market]

Tror ingen forventer at en disk som er systemkomprimert i Linux skal fungere i Windows.

[Emancipate]

Nå var det snakk om Windows og Windows. Men ærlig talt skulle jeg gjerne sett at disker funker sømløst mellom OS også.

[G]

Utover detaljene om hvorfor, så synes jeg dette er noe av det minst oppsiktsvekkende jeg har lest om på lenge.

 

Alle som er litt logisktenkende og brukere som har fulgt med bittelitt og som har lang Windows-brukerfartstid, vil forstå at Windows er bloat. De har til og med lest at Windows fremdeles bærer på mye gammel kode, og om saker som f.eks. hvor Microsoft påstår at IE er såpass tett integrert mot OS'et at de ønsket helst ikke å etterkomme EU sine krav om endringer.

 

 

 

Nå har Microsoft kommet med en forklaring på hvorfor komprimeringen i Windows ikke er mer effektiv. Årsaken er ganske oppsiktsvekkende. 

 

 

Jeg tør nesten å kalle slikt sludderpåstander for agurknytt. Velbekomme.

 

Så det er ikke oppsiktsvekkende et sted, for en leser som har liknende brukererfaring og litt interesse for å lese om IT-nyheter her og der.

Endret 3. november 2016 av G

[Bob2]

Så, hvor mye mindre ville de komprimerte filene ha blitt dersom man skrev om koden og droppet støtten for disse gamle CPU-arkitekturene?

 

Jeg vil gjerne vite det før jeg finner fram høygaffelen, tenner faklene og organiserer protesttoget mot Microsofts onde borg.

 

Det er veldig avhengig av hvilke typer filer det er snakk om. Filer som allerede er komprimert, som for eksempel stillbilder lagret som .jpg, musikk lagret som .mp3, filmer lagret som .avi, .mpg eller lignende, andre typer filer som er lagret som .zip, og flere andre typer også, vil ikke bli nevneverdig komprimert i det hele tatt med teknikkene som er nevnt i artikkelen, hverken i nåværende eller mulige framtidige utgaver.

[nebrewfoz]

Så den "begrensningen" det er snakk om er ukvantifiserbar, med andre ord.

Vel, jeg bruker ikke 'disk compression' uansett.

[Sandormen]

Det her er vel eeegentlig ikke så oppsiktsvekkende. -Er jo faktisk en av grunnene til at 'vi' har i mange år håpa at M$ ville forkaste gammel kode og lage et nytt OS...

[Sandormen]

Nå var det snakk om Windows og Windows. Men ærlig talt skulle jeg gjerne sett at disker funker sømløst mellom OS også.

 

Disker i dag fungerer sømløst. Kan fint kjøre en windowsdisk på en linuxmaskin. -Kan bare ikke lese filer direkte, med mindre man poengterer at noen filer skal automatisk i tilsvarende 'linuxprogrammer'...

Kan godt lese din viruskræsja windowsdisk i linux for å ta backup av det 'DU' burde gjort 3 år sida... ...tilogmed backup av krypterte filer... ...-de må kanskje åpnes i et windowssystem, men har du linux har du sikkert windows på en anna partisjon...

 

Hmm. Unnskyld. Temaet var vel egentlig bakoverkompatibilitet mot drittprosessorer...

...ignorer kommentarene.

Endret 4. november 2016 av Sandormen

[Emancipate]

Kan fint kjøre en windowsdisk på en linuxmaskin.

Men ikke omvendt, uten å installere ekstra programvare. Noe som er upraktisk ved dual-boot.

[G]

Går det ikke an å delvis aksessere disker gjennom nettverket da? Selv om det kan ha detrimentale effekter på filnavn og diverse mellom ymse diskoperativsystemer ved kopieringsoperasjoner og slikt, alt etter hvilke OS man forsøker å få til å dele disker seg i mellom da..

Endret 5. november 2016 av G

[Horten Market]

Disker i nettverk er en ressurs som må tilbys av noe, og dette noe er et OS. Det vil si at filene egentlig leses av dette OSet som deler ut ressursen.