mboost-dp1

Shutterstock

Studerende ved ikke, hvad filer og mapper er, siger professorer

- Via Slashdot -

En generation, som er vokset op med Google, tvinger professorer til at gentænke deres lektionsplaner. Flere universitetsstuderende skal undervises i, hvordan filer og mapper fungerer på en computer, da de er vant til bare at søge efter dem.

Det skriver Slashdot, som først rapporteret af The Verge.

“Jeg har en tendens til at tro, at en bestemt fil bor i en bestemt mappe. Den bor ét sted, og jeg skal gå til det sted for at finde den,” lyder det fra astrofysiker Catherine Garland. “De [studerende] ser det som en stor spand, og alt er i spanden.”

Det kan opfattes som atypisk for ældre generationer af computerbrugere, som er vokset op med at holde styr på samlinger af mapper, undermapper og dertilhørende filer, men takket være forbedrede søgefunktioner, som nu er standardiseret i operativsystemer, samt måden smartphones og tablets skjuler deres filstruktur, ser vi nu en generation af studerende, som har en anderledes tilgang til filsystemet.

“Jeg er en lidt besat organisator, men de [studerende] har ikke noget problem med at have 1.000 liggende filer i det samme bibliotek,” sagde Peter Plavchan, professor i fysik og astronomi ved George Mason University til The Verge. “Jeg tror, at det grundlæggende skyldes et skift i, hvordan vi får adgang til vores filer.”

Eller som The Verge påpeger, “blev de første søgemaskiner på internettet brugt omkring 1990, mens funktioner som Windows Search og Spotlight på macOS begge er produkter fra begyndelsen af 2000’erne.”

Hvor mange af nutidens professorer voksede op uden disse søgefunktioner på deres telefoner og computere, kan de fleste af nutidens studerende ikke mindes en tid, hvor det ikke var muligt at søge efter en bestemt fil eller mappe for at finde den.





Gå til bund
Gravatar #1 - larsp
29. sep. 2021 09:31
Velkommen til en generation af IT analfabeter. At have alle filer i en mappe er fint nok i mindre målestok, men det skalerer bare ikke. Disse unge mister magten over deres data og er fuldstændig håbløst i diverse cloud udbyderes magt.

JA! lær de stakkels unge om filer og mapper. Hvis de vil noget der bare nærmer sig software udvikling er evnen til at organisere filer i mapper vel på niveau med at lære plus og minus inden for regning.
Gravatar #2 - JesperBentzen
29. sep. 2021 10:37
Incitamentet til at rydde op på mit fysiske skrivebord, er at jeg ikke kan finde det jeg leder efter når jeg skal bruge det (udover at det ser kaotisk ud). Hvis folk kan finde det de skal bruge, så kan jeg ikke se problemet. Jeg er selv softwareudvikler, og roder en del både fysisk og på mine computere. Er man et ordensmenneske, så er alt pakket fint ned i skrivebordsskuffer med labels eller i foldere på ens PC. Man lærer hvad man har brug for. Jeg vil ikke kalde unge IT-analfabeter – de ved godt hvordan en smartphone og PC skal anvendes. Det være sagt, hvis en ingeniør eller fysik studerende ikke aner hvad er folder er, så er der noget helt galt, da man må kunne forvente lidt mere viden på det niveau. Spændende!
Gravatar #3 - AppleSheep
29. sep. 2021 10:40
De unge ser computere som en simpel ting som et tv apparat. Man trykker bare på en knap, og så gør computeren det bare uden at kræve at brugeren skal hjælpe den.

Jeg bruger selv den metode ret tit. Men man mister bare ret hurtigt sine data, hvis man ikke har en solid backup løsning, hvis computeren går ned.
Gravatar #4 - Athinira
29. sep. 2021 11:10
larsp (1) skrev:
Velkommen til en generation af IT analfabeter. At have alle filer i en mappe er fint nok i mindre målestok, men det skalerer bare ikke. Disse unge mister magten over deres data og er fuldstændig håbløst i diverse cloud udbyderes magt.

JA! lær de stakkels unge om filer og mapper. Hvis de vil noget der bare nærmer sig software udvikling er evnen til at organisere filer i mapper vel på niveau med at lære plus og minus inden for regning.


Kan ikke se hvorfor det specifikt er et Cloud-udbyder-problemet. Hvor mange mennesker har du ikke set miste magten eller overblikket over data på deres egne computere, fordi de ikke kan finde ud af at organisere tingene?

Cloud-udbyderne tilbyder faktisk i visse tilfælde en forenkling for brugerne som kun er positiv. Tag fx iCloud Photos eller Google Photos. Begge dele er en langt bedre løsning end at have fotos i mapper, fordi det er langt nemmere at søge, alt er arrangeret efter dato, og de har AI der gør at du fx kan søge efter "Vandmelon" hvis du har taget et billede af en vandmelon du gerne vil vise. Og backup-delen er også ekstremt simpel. Og da det hele er specialiseret omkring fotos og videoer, så slipper du for alt det overflødige der intet har med disse ting at gøre.

Det korte og det lange i min verden er at folk er nogle rodehoveder - det som er problemet er at de har mistet evnen til at rydde op og har mistet overblikket.
Gravatar #5 - Winnick
29. sep. 2021 13:06
At lægge ting i mapper begrænser deres tilgængelighed.
At kunne sætte flere labels på det samme dokument øger tilgængeligheden

Problemet med mapper er at medmindre du vil
1)bruge genveje
2)have doubletter

så er et dokument begrænset til at have én placering.
Med labels kan jeg sørge for at jeg får præsenteret dokumentet i flere relevante sammenhænge.

Så længe du har filtre og søgefunktioner - så er den reelle placering irrelevant
Gravatar #6 - larsp
29. sep. 2021 13:36
#5 Jeg har projekter af alle mulige størrelser, musik, foto albums og alt, alt muligt tilbage fra... 1998 agtigt i mine digitale gemmer. Der kan snildt være millioner af filer. Langt de fleste ganske irrelevante ift. hvad jeg laver nu, men stadig filer jeg ikke vil smide ud.

Okay, jeg lægger bare det hele i en folder. Not.
Gravatar #7 - arne_v
29. sep. 2021 13:42
De har ret.

IT kendskab er stærkt faldende i Danmark og formentligt i det meste af vesten.

De fleste bruger IT men for de fleste så er IT black box. Man taster eller siger hvad man vil og så sørger noget software for resten.

Der er 2 problemer ved det:
1) det bliver vanskeligere at skaffe dygtige IT folk
2) ikke-IT folk bliver noget handicappet fordi selvom de kan bruge IT systemerne så forståe de ikke hvordan IT systemerne fungerer og kan derfor have svært ved at forudse og opdage problemer
Gravatar #8 - arne_v
29. sep. 2021 13:46
#5

Indeksering udelukker ikke en god struktur.

Indeksering gør at at problemerne med manglende struktur ikke føles umiddelbart.

Gravatar #9 - Hack4Crack
29. sep. 2021 21:00
larsp (1) skrev:
Velkommen til en generation af IT analfabeter. At have alle filer i en mappe er fint nok i mindre målestok, men det skalerer bare ikke. Disse unge mister magten over deres data og er fuldstændig håbløst i diverse cloud udbyderes magt.

Staklerne er jo vant til at deres instagram billeder er sorteret efter dato i en lang pærevælling. Det kan nok fungere fint andre steder.

Er det ikke også den metode Generation Google arbejder med og også ses i windows 10 start menuen/Apple/Android? smid lortet et sted, og så søg efter det du skal bruge.
Gravatar #10 - sirius09
30. sep. 2021 01:15
Fedt, så der er også et arbejde til mig om 30 år.
Lige nu er det generelt de ældre generationer jeg hjælper med IT problemer. Men allerede nu ser jeg også personer der er langt yngre end mig, ikke kunne finde ud af simple ting. Nogle gange kan jeg undre mig over hvordan en person har formået at tænde enheden, når de ringer og spørg hvordan man laver en genvej / bogmærke til en hjemmeside.
Gravatar #11 - fiskebenet
30. sep. 2021 05:50
#1 larsp

Du skal vist til at læse op på sammenhængende ord.
Gravatar #12 - AppleSheep
30. sep. 2021 09:36
Hack4Crack (9) skrev:
larsp (1) skrev:
Velkommen til en generation af IT analfabeter. At have alle filer i en mappe er fint nok i mindre målestok, men det skalerer bare ikke. Disse unge mister magten over deres data og er fuldstændig håbløst i diverse cloud udbyderes magt.

Staklerne er jo vant til at deres instagram billeder er sorteret efter dato i en lang pærevælling. Det kan nok fungere fint andre steder.

Er det ikke også den metode Generation Google arbejder med og også ses i windows 10 start menuen/Apple/Android? smid lortet et sted, og så søg efter det du skal bruge.


Den har faktisk været sådan længe med macOS / OS X. Jeg kan huske over ti år tilbage hvor der var DTP programmer som gemte filerne et sted, men man havde ikke selv nogen ide om hvor det var. Men det virkede fint nok. Men jeg kan godt forstå at det er en skæv måde at gøre tingene på i nogle sammenhænge. Men andre gange var det bare befriende let ikke at skulle bekymre sig om filer og stier (for det virkede bare). Folk med OCD neuroser vil nok ikke kunne leve med den slags.

Nu ved jeg ikke lige hvordan Android virker, men der gemmer man vel også bare det man har lavet uden egen at have kendskab til filer og foldere? (Spørger bare)
Gravatar #13 - Winnick
30. sep. 2021 12:59
larsp (6) skrev:
#5 Jeg har projekter af alle mulige størrelser, musik, foto albums og alt, alt muligt tilbage fra... 1998 agtigt i mine digitale gemmer. Der kan snildt være millioner af filer. Langt de fleste ganske irrelevante ift. hvad jeg laver nu, men stadig filer jeg ikke vil smide ud.

Okay, jeg lægger bare det hele i en folder. Not.


Hvis dit arkiv-system understøtter labels, så er det langt mere fleksibelt at du bruger labels end du opbygger mappe-struktur. Et dokument kan med labels "ligge flere steder" samtidig, mens i en mappe struktur kan den kunne ligge ét sted.

og ja, hvis labelling ikke er en mulighed så bliver en mappe-struktur alfa og omega for at holde styr på store mængde af filer af forskellige typer.

Og jeg ser ingen ulemper ved at bruge begge dele.


Gravatar #14 - Stallemanden
30. sep. 2021 18:27
Det ene udelukker vel ikke det andet?

Hvis jeg alligevel skal give mine filer/dokumenter labels, så kan man vel ligeså godt ved samme lejlighed gemme dokumentet i en relevant folder?
Indekseringen bør virke ligeså godt.

Det være sagt, så kæmper jeg en kamp med, at få folk i min organisation til at forstå, at når man har referencer til dokumenter, så må de ikke skifte navn. Det redder hverken vedvarende folder struktur eller labels.
Og når alle dokumenter har automatisk versionering, giver det ikke mening at filnavnet skal skifte navn, når man laver en ny version/rettelse.

Uagtet.

Fan af folderstruktur, men også meget glad for indeksering...som bliver bedre og bedre.
Gravatar #15 - nwinther
4. okt. 2021 12:29
arne_v (7) skrev:
De har ret.

IT kendskab er stærkt faldende i Danmark og formentligt i det meste af vesten.

De fleste bruger IT men for de fleste så er IT black box. Man taster eller siger hvad man vil og så sørger noget software for resten.

Der er 2 problemer ved det:
1) det bliver vanskeligere at skaffe dygtige IT folk
2) ikke-IT folk bliver noget handicappet fordi selvom de kan bruge IT systemerne så forståe de ikke hvordan IT systemerne fungerer og kan derfor have svært ved at forudse og opdage problemer


Men er det ikke en konsekvens af al teknologi? Det er de færreste som ved, hvordan en forbrændingsmotor virker, men de kan sagtens køre en bil alligevel.

Og det bliver ikke stort bedre, med elbilen.

Jeg aner ikke, hvordan en computer EGENTLIGT virker, og jeg fik min første Amiga 500 i 1988 i en alder af 9 år.
Men det er noget med nogle integrerede kredsløb (som jeg også er uvidende om, hvordan de egentligt fungerer) som sender nogle 1 og 0'er rundt til hinanden, og noget med en hukommelse, hvor data kan hentes og lagres, og så kan det vises på en skærm gennem en modulator (som jeg heller ikke ved, hvordan virker).

Jeg tænker nogen gange på, når jeg ser en PC starte op, at den lille hvide rektangel (cursor), der står og blinker kortvarigt i øverste venstre hjørne: Hvem mon har tegnet den? Hvordan gjorde de? Hvad skal maskinen vide, for at placere den dér og hvordan fortæller man maskinen de mest basale, første input og hvordan og hvor ofte skrives de om? Alle de oplysninger der står i BIOS - hvorfra ved maskinen, at den skal spørge BIOS om, hvad der er hvor og hvor kender den begreberne fra?

Jeg har engang læst en artikel (måske herinde?), at der ikke er nogen som fundamentalt set ved, hvordan alle komponenterne på et motherboard fungerer, at nogen af chipdesignerne kun ved, hvad output fra BUS (eller noget andet) er, men hvordan output bliver genereret i BUS, ved de faktisk ikke - de skal bare bruge output til at sende ind i déres IC og videre ud til noget andet.

Om det er rigtigt, ved jeg ikke.
Gravatar #16 - arne_v
4. okt. 2021 13:22
#15

Det er en risiko ved al teknologi.

Og det er aldeles umuligt at forstå alt i en moderne computer. Der er billioner af transistorer i en moderne computer og hundrede af millioner af linier software.

Men nogle ting er det godt at forstå:
- hardware vs styresystem vs applikationer vs data
- disk versus hukommelse
- username/password check
- lokal storage vs cloud storage
etc.

Tilsvarende med biler så er det godt hvis folk har lidt forståelse for:
- bremser og dæk
- betydningen af olie og kølevæske
- alle de elektroniske "assist" som hjælper til og deres begrænsninger


Gravatar #17 - arne_v
4. okt. 2021 14:23
#16

Med hensyn til bil analogi.

For mange år siden blev redaktøren af FDM's medlemsblad spurgt hvad det dummeste spørgsmål han havde modtaget var. Han henviste til følgende: hvor kan jeg købe en længere oliepind fordi den nuværende kan ikke nå ned til olien.

:-)
Gravatar #18 - nwinther
5. okt. 2021 06:41
arne_v (16) skrev:
#15

Det er en risiko ved al teknologi.

Og det er aldeles umuligt at forstå alt i en moderne computer. Der er billioner af transistorer i en moderne computer og hundrede af millioner af linier software.

Men nogle ting er det godt at forstå:
- hardware vs styresystem vs applikationer vs data
- disk versus hukommelse
- username/password check
- lokal storage vs cloud storage
etc.

Tilsvarende med biler så er det godt hvis folk har lidt forståelse for:
- bremser og dæk
- betydningen af olie og kølevæske
- alle de elektroniske "assist" som hjælper til og deres begrænsninger




Helt enig.

Det var mere en kommentar til, at ikke-IT folk ikke ved, hvordan det fungerer. Dertil kan man sige, at IT-folk, selv de dygtigste, reelt kun ved, hvordan deres eget lille hjørne af computeren/systemet fungerer. At der måske er risiko for et potentielt læk et sted på en computer, når data flyder igennem en vilkårlig chip - mens man selv har en opfattelse, af at det software man har lavet, er skudsikkert, for man forstår det (og kun dét) til bunds.

For nogle år siden blev Huawei lagt "død" af amerikanerne, fordi de mente, at teknologien ikke var sikker (for amerikanerne), at der var (risiko for at) der var indbygget bagdøre mv. i hardware.

Jeg har ofte tænkt på, når man hører om et eller andet firma, som frigiver kildekoden på et stykke software, at hvordan kan en programmør ikke læse kildekode, når nu computeren kan læse kildekode? (ellers kan den vel ikke køre software?).
Jeg afslører nok min egen uvidenhed, da jeg er usikker på, om jeg egentligt forstår, hvad kildekode er (jeg tror det er den grundlæggende programkode til et stykke software - svarende lidt til teksten til en bog).
Gravatar #19 - larsp
5. okt. 2021 09:05
nwinther (15) skrev:
Jeg har engang læst en artikel (måske herinde?), at der ikke er nogen som fundamentalt set ved, hvordan alle komponenterne på et motherboard fungerer, at nogen af chipdesignerne kun ved, hvad output fra BUS (eller noget andet) er, men hvordan output bliver genereret i BUS, ved de faktisk ikke - de skal bare bruge output til at sende ind i déres IC og videre ud til noget andet.

Om det er rigtigt, ved jeg ikke.

Det er rigtigt nok. Jeg tror ikke der findes et individ som forstår alt inde i alle komponenterne på et motherboard. Det er derfor man er nød til at dele komplekse systemer op i undersystemer og definere grænsefladerne mellem komponenterne. F.eks. er DDR RAM interfacet (=grænseflade) grundigt specificeret så producenten af RAM ikke behøver forstå resten af motherboardet. Tilsvarende er grænsefladerne (busser og protokoller) mellem de andre chips også grundigt specificeret, så chip producenterne ikke behøver at forholde sig til en masse andet end lige deres bid af kagen.

Jeg har ofte tænkt på, når man hører om et eller andet firma, som frigiver kildekoden på et stykke software, at hvordan kan en programmør ikke læse kildekode, når nu computeren kan læse kildekode? (ellers kan den vel ikke køre software?).

En computers måde at "læse" kildekode er meget anderledes end et menneske. Når computeren oversætter kildekoden er det som en robot der utrætteligt oversætter hver operation uden at forstå den overordnede mening med det hele. En programmør der læser kildekode derimod, vil starte med den overordnede mening og så dykke ned i de enkelte operationer efter behov. Det betyder også at man ofte vil overse detaljer. Menneskehjernen kan ikke kapere at læse alle instruktionerne og forudse hvad der vil ske i et stort program.
Gravatar #20 - nwinther
5. okt. 2021 09:42
larsp (19) skrev:
En computers måde at "læse" kildekode er meget anderledes end et menneske. Når computeren oversætter kildekoden er det som en robot der utrætteligt oversætter hver operation uden at forstå den overordnede mening med det hele. En programmør der læser kildekode derimod, vil starte med den overordnede mening og så dykke ned i de enkelte operationer efter behov. Det betyder også at man ofte vil overse detaljer. Menneskehjernen kan ikke kapere at læse alle instruktionerne og forudse hvad der vil ske i et stort program.


Men vil kildekoden ikke altid være tilgængelig (computeren skal jo læse et eller andet)?
Så hvorfor er det noget særligt, når Microsoft har udgivet kildekoden til Windows NT eller noget?
Gravatar #21 - Athinira
5. okt. 2021 10:58
nwinther (20) skrev:
Men vil kildekoden ikke altid være tilgængelig (computeren skal jo læse et eller andet)?
Så hvorfor er det noget særligt, når Microsoft har udgivet kildekoden til Windows NT eller noget?

Fordi kildekode ikke er det samme som kompileret kode. Computere læser ofte pre-kompileret kode. Kode køres ofte (men ikke altid) gennem en compiler, som omdanner koden til noget der kan køre på et specifikt system.

Når du kører kode gennem en kompiler sker der flere ting:

1) Alle kommentarer (og noter) fjernes - dvs. alle små hints mm. fra programmørerne der skal hjælpe både dem selv og andre med at forstå koden forsvinder.

2) Funktioner mm. som har fået menneskelige navne der er lette at forstå vil ofte miste deres navne og i stedet få et nummer eller lignende.
Så en funktion der fx hedder GetURLFromCache() i kildekoden vil miste dette navn, og det bliver sværere at gennemskue hvad formålet er.

3) Koden brydes ned og oversættes til det specifikke system eller chipdesign det kompileres til. Hvis du kompilerer kildekode til fx både x86 og ARM, så vil det færdige resultat se vidt forskelligt ud.

Det er derfor at det er utroligt svært at lave reverse-engineering på computer-programmer. Det er faktisk en form for kunstform, og meget få programmører kan faktisk finde ud af at skille et pre-kompileret program ad og forstå opbygningen og de enkelte deles funktion.

Det er dog ikke alle computerprogrammer som distribueres kompileret. På Android distribueres apps fx som APK-filer med Java kildekode - og derfor kan du læse kildekoden. I stedet bliver kildekoden kompileret af selve telefonen når du installerer appen (AOT - Ahead-of-time compilation) - dette er med til at sikre at appen fungerer på alle Android-telefoner, selv hvis deres arkitektur varierer en smule.

Tidligere benyttede Android JIT (Just-in-time compilation). Dette er hvor kildekoden kompileres hver gang du åbner/benytter en app. Problemet med dette er at det suger batteri hver gang du starter appen og gør appen langsommere i brug. Så Android skiftede til AOT - dette gør at apps fylder mere på telefonen, men til gengæld er de hurtigere til at starte, og det dræner mindre batteri.
Gravatar #22 - nwinther
5. okt. 2021 11:51
@21 - Tak for den forklaring. +1
Gravatar #23 - fastwrite_1
5. okt. 2021 15:42
Er jeg den eneste der pludselig føler mig gammel over at læse sådan en nyhed at generationer af unge mennesker ikke ved hvad en folder er !?...

suk... (mens jeg kigger over på min paranoia mappe-struktur)

voidtools' everything er for øvrigt et genialt søg efter fil program. Derfor gemmer jeg nu mine filer med nogle obskurt lange filnavne så jeg er sikker på at kunne finde dem igen.

Hvornår bliver labels en normal del af Windows?
Gravatar #24 - arne_v
5. okt. 2021 15:57
#21

Beskrivelsen af Android er ikke korrekt. En APK indeholder ikke Java kilde kode.

Processen er:

udviklings maskine:

.java file with source code---(Java compiler)--->.class file with Java byte code---(dx utility)--->.dex file with Dalvik byte code---(zip)--->.apk file

telefon:

.apk file---(unzip & AOT compile / ART)--->executable

Så en .apk med embedded .dex indeholder ikke Java kildekode.

Men det er ikke det samme som at den ikke kan reverse engineeres.

Virtuelle maskiner som JVM, CLR, Dalvik/ART er noget mere høj niveau end rigtige CPU'er (x86-64, ARM etc.) så de er nemmere at dekompilere.

Typisk vil man få OK kode ud af en dekompilering - bare uden kommentarer og med tilfælde navne på lokale variable (men kun lokale).
Gravatar #25 - arne_v
5. okt. 2021 17:34
Hvis nogen vil se et eksempel.

Et lille stykke C kode som enhver programmør bør kunne forstå.


#include <stdio.h>

long long int fac(int n)
{
if(n <= 1)
{
return 1;
}
else
{
return n * fac(n - 1);
}
}

int main()
{
int i;
for(i = 0; i < 15; i++)
{
printf("%d %lld\n", i, fac(i));
}
return 0;
}


VSI C 7.4 on VMS 8.4-2L2 on Alpha


.PSECT $CODE$, OCTA, PIC, CON, REL, LCL, SHR,-
EXE, NORD, NOWRT
0000 FAC::
23DEFFE0 0000 LDA SP, -32(SP)
42003DB1 0004 CMPLE R16, 1, R17 ; 001507
47E03400 0008 MOV 1, R0 ; 001509
47E03419 000C MOV 1, R25 ; 001513
B77E0000 0010 STQ R27, (SP) ; 001505
B75E0008 0014 STQ R26, 8(SP)
B45E0010 0018 STQ R2, 16(SP)
B7BE0018 001C STQ FP, 24(SP)
47FE041D 0020 MOV SP, FP
F6200005 0024 BNE R17, L$4 ; 001509
47F00402 0028 MOV R16, n ; R16, R2 ; 001505
42003130 002C SUBL R16, 1, R16 ; 001513
A77B0020 0030 LDQ R27, 32(R27)
D35FFFF2 0034 BSR R26, FAC
4C400400 0038 MULQ n, R0, R0 ; R2, R0, R0
003C L$4:
47FD041E 003C MOV FP, SP ; 001515
A75D0008 0040 LDQ R26, 8(FP)
A45D0010 0044 LDQ R2, 16(FP)
A7BD0018 0048 LDQ FP, 24(FP)
23DE0020 004C LDA SP, 32(SP)
6BFA8001 0050 RET R26
2FFE0000 0054 UNOP
2FFE0000 0058 UNOP
2FFE0000 005C UNOP
0060 __MAIN::
23DEFFB0 0060 LDA SP, -80(SP)
47F00416 0064 MOV R16, p1 ; R16, R22
B75E0038 0068 STQ R26, 56(SP)
B77E0000 006C STQ R27, (SP)
235F2000 0070 MOV 8192, R26
221E0030 0074 LDA R16, argc ; R16, 48(SP)
B7FE0008 0078 STQ R31, __DECC$$HANDLER_DATA_VAR ; R31, 8(SP)
B45E0040 007C STQ R2, 64(SP)
47E13419 0080 MOV 9, R25
B7BE0048 0084 STQ FP, 72(SP)
63FF0000 0088 TRAPB
47FE041D 008C MOV SP, FP
47FB0402 0090 MOV R27, R2
23DEFFE0 0094 LDA SP, -32(SP)
B7FE0000 0098 STQ R31, (SP)
B75D0008 009C STQ R26, __DECC$$HANDLER_DATA_VAR ; R26, 8(FP)
B61E0000 00A0 STQ R16, (SP)
221D0028 00A4 LDA R16, argv ; R16, 40(FP)
A75B0040 00A8 LDQ R26, 64(R27)
A7620048 00AC LDQ R27, 72(R2)
B61E0008 00B0 STQ R16, 8(SP)
221D0020 00B4 LDA R16, envp ; R16, 32(FP)
B61E0010 00B8 STQ R16, 16(SP)
47F60410 00BC MOV p1, R16 ; R22, R16
6B5A4000 00C0 JSR R26, DECC$MAIN ; R26, R26
2362FFB8 00C4 LDA R27, -72(R2)
D3400011 00C8 BSR R26, MAIN
A7420030 00CC LDQ R26, 48(R2)
47E00410 00D0 MOV R0, R16
47E03419 00D4 MOV 1, R25
A7620038 00D8 LDQ R27, 56(R2)
2FFE0000 00DC UNOP
6B5A4000 00E0 JSR R26, DECC$EXIT ; R26, R26
63FF0000 00E4 TRAPB
47FD041E 00E8 MOV FP, SP
A75D0038 00EC LDQ R26, 56(FP)
A45D0040 00F0 LDQ R2, 64(FP)
A7BD0048 00F4 LDQ FP, 72(FP)
23DE0050 00F8 LDA SP, 80(SP)
2FFE0000 00FC UNOP
6BFA8001 0100 RET R26
2FFE0000 0104 UNOP
2FFE0000 0108 UNOP
2FFE0000 010C UNOP
0110 MAIN::
23DEFFD0 0110 LDA SP, -48(SP)
B77E0000 0114 STQ R27, (SP)
B75E0008 0118 STQ R26, 8(SP)
B45E0010 011C STQ R2, 16(SP)
B47E0018 0120 STQ R3, 24(SP)
B49E0020 0124 STQ R4, 32(SP)
B7BE0028 0128 STQ FP, 40(SP)
47FE041D 012C MOV SP, FP
47FB0402 0130 MOV R27, R2
47FF0403 0134 CLR i ; R3 ; 001520
47FF0404 0138 CLR R4 ; 001513
2FFE0000 013C UNOP
0140 L$6: ; 001520
40603DA0 0140 CMPLE i, 1, R0 ; R3, 1, R0 ; 001507
47E03401 0144 MOV 1, R1 ; 001509
40603130 0148 SUBL i, 1, R16 ; R3, 1, R16 ; 001513
2362FFD8 014C LDA R27, -40(R2)
F4000002 0150 BNE R0, L$9 ; 001509
D35FFFAA 0154 BSR R26, FAC ; 001513
4C800401 0158 MULQ R4, R0, R1
015C L$9: ; 001522
A7420028 015C LDQ R26, 40(R2)
47E30411 0160 MOV i, R17 ; R3, R17
40603003 0164 ADDL i, 1, i ; R3, 1, R3 ; 001520
47E07419 0168 MOV 3, R25 ; 001522
22020038 016C LDA R16, 56(R2)
A7620030 0170 LDQ R27, 48(R2)
20840001 0174 LDA R4, 1(R4) ; 001520
47E10412 0178 MOV R1, R18 ; 001522
2FFE0000 017C UNOP
6B5A4000 0180 JSR R26, DECC$GXPRINTF ; R26, R26
4061F9A0 0184 CMPLT i, 15, R0 ; R3, 15, R0 ; 001520
F41FFFED 0188 BNE R0, L$6
47FD041E 018C MOV FP, SP ; 001525
A75D0008 0190 LDQ R26, 8(FP)
A45D0010 0194 LDQ R2, 16(FP)
A47D0018 0198 LDQ R3, 24(FP)
A49D0020 019C LDQ R4, 32(FP)
47FF0400 01A0 CLR R0 ; 001524
A7BD0028 01A4 LDQ FP, 40(FP) ; 001525
23DE0030 01A8 LDA SP, 48(SP)
2FFE0000 01AC UNOP
6BFA8001 01B0 RET R26


Forklaring:
- første kolonne er bytes i hex for den binære kode som den er i EXE filen
- anden kolonne er bare offset fra kode start
- resten er den assembler kode der svarer til den første kolonne aka præcis samme indhold bare i en mere menneske læsbar form (lidt snyd fordi navnene FAC og MAIN vil ikke kunne udledes af EXE filen)

Jeg tror at de fleste vil mene at den kode er praktisk ulæselig. Man kan muligvis kæmpe sig gennem nogle få hundrede linier, men hundrede tusinder af linier vil være håbløst.

GCC 11.1 on Windows 7 on x86-64 med -O3:


.file "fac.c"
.text
.section .rdata,"dr"
.LC0:
.ascii "%d %lld\12\0"
.text
.p2align 4
.def printf.constprop.0; .scl 3; .type 32; .endef
.seh_proc printf.constprop.0
printf.constprop.0:
pushq %rbx
.seh_pushreg %rbx
subq $48, %rsp
.seh_stackalloc 48
.seh_endprologue
movl $1, %ecx
leaq 72(%rsp), %rbx
movq %rdx, 72(%rsp)
movq %r8, 80(%rsp)
movq %r9, 88(%rsp)
movq %rbx, 40(%rsp)
call *__imp___acrt_iob_func(%rip)
movq %rbx, %r8
leaq .LC0(%rip), %rdx
movq %rax, %rcx
call __mingw_vfprintf
addq $48, %rsp
popq %rbx
ret
.seh_endproc
.p2align 4
.globl fac
.def fac; .scl 2; .type 32; .endef
.seh_proc fac
fac:
.seh_endprologue
movl $1, %r8d
cmpl $1, %ecx
jle .L3
movslq %ecx, %rdx
leal -2(%rcx), %r8d
leaq -1(%rdx), %rax
movq %rax, %rcx
subq %r8, %rcx
movl $1, %r8d
jmp .L6
.p2align 4,,10
.p2align 3
.L7:
subq $1, %rax
.L6:
imulq %rdx, %r8
movq %rax, %rdx
cmpq %rcx, %rax
jne .L7
.L3:
movq %r8, %rax
ret
.seh_endproc
.def __main; .scl 2; .type 32; .endef
.section .text.startup,"x"
.p2align 4
.globl main
.def main; .scl 2; .type 32; .endef
.seh_proc main
main:
pushq %r12
.seh_pushreg %r12
pushq %rbp
.seh_pushreg %rbp
pushq %rdi
.seh_pushreg %rdi
pushq %rsi
.seh_pushreg %rsi
pushq %rbx
.seh_pushreg %rbx
subq $32, %rsp
.seh_stackalloc 32
.seh_endprologue
movq $-11, %rbp
movl $1, %edi
xorl %ebx, %ebx
leaq .LC0(%rip), %r12
call __main
movl $1, %r8d
jmp .L9
.p2align 4,,10
.p2align 3
.L10:
cmpq $1, %rdi
je .L18
movq %rdi, %r8
cmpq $1, %rbx
jbe .L13
imulq %rbx, %r8
leal -1(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -1(%rbx), %rax
imulq %rax, %r8
leal -2(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -2(%rbx), %rax
imulq %rax, %r8
leal -3(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -3(%rbx), %rax
imulq %rax, %r8
leal -4(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -4(%rbx), %rax
imulq %rax, %r8
leal -5(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -5(%rbx), %rax
imulq %rax, %r8
leal -6(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -6(%rbx), %rax
imulq %rax, %r8
leal -7(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -7(%rbx), %rax
imulq %rax, %r8
leal -8(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -8(%rbx), %rax
imulq %rax, %r8
leal -9(%rsi), %eax
cmpl $1, %eax
jle .L13
leaq -9(%rbx), %rax
subl $10, %esi
imulq %rax, %r8
cmpl $1, %esi
jle .L13
leaq -10(%rbx), %rax
imulq %rax, %r8
cmpl $1, %ebp
jle .L13
imulq %rbp, %r8
.L13:
addq $1, %rbx
addq $1, %rdi
addq $1, %rbp
.L9:
movl %ebx, %edx
movq %r12, %rcx
movl %ebx, %esi
call printf.constprop.0
cmpq $14, %rbx
jne .L10
xorl %eax, %eax
addq $32, %rsp
popq %rbx
popq %rsi
popq %rdi
popq %rbp
popq %r12
ret
.L18:
movl $1, %r8d
jmp .L13
.seh_endproc
.ident "GCC: (GNU) 11.1.0"
.def __mingw_vfprintf; .scl 2; .type 32; .endef


Her er der kun assembler koden (gcc -S er ikke så god som cc/list/mach)

Det er åbenlyst at x86-64 er forskellig fra Alpha.

Men den er stadig praktisk ulæselig (fac og main vil igen forsvinde i EXE filen)
Gravatar #26 - arne_v
5. okt. 2021 17:55
Nu Java.

Samme kode.


public class Fac {
public static long fac(int n) {
if(n <= 1) {
return 1;
} else {
return n * fac(n - 1);
}
}
public static void main(String[] args) {
for(int i = 0; i < 15; i++) {
System.out.printf("%d %d\n", i, fac(i));
}
}
}


Og javap -c (disassembler) afslører mere:


Compiled from "Fac.java"
public class Fac {
public Fac();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return

public static long fac(int);
Code:
0: iload_0
1: iconst_1
2: if_icmpgt 7
5: lconst_1
6: lreturn
7: iload_0
8: i2l
9: iload_0
10: iconst_1
11: isub
12: invokestatic #2 // Method fac:(I)J
15: lmul
16: lreturn

public static void main(java.lang.String[]);
Code:
0: iconst_0
1: istore_1
2: iload_1
3: bipush 15
5: if_icmpge 44
8: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
11: ldc #4 // String %d %d\n
13: iconst_2
14: anewarray #5 // class java/lang/Object 17: dup
18: iconst_0
19: iload_1
20: invokestatic #6 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
23: aastore
24: dup
25: iconst_1
26: iload_1
27: invokestatic #2 // Method fac:(I)J
30: invokestatic #7 // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
33: aastore
34: invokevirtual #8 // Method java/io/PrintStream.printf:(Ljava/lang/String;[Ljava/lang/Object;)Ljava/io/PrintStream;
37: pop
38: iinc 1, 1
41: goto 2
44: return
}


Koden ser lidt nemmere ud men stadig ret ulæselig fordi stack machine er uvant for de fleste mennesker.

Men computere elsker det, så en decompiler producerer faktisk noget læsbart:


public class Fac {
public static long fac(int paramInt) {
if (paramInt <= 1)
return 1L;
return paramInt * fac(paramInt - 1);
}

public static void main(String[] paramArrayOfString) {
for (byte b = 0; b < 15; b++) {
System.out.printf("%d %d\n", new Object[] { Integer.valueOf(b), Long.valueOf(fac(b)) });
}
}
}


Det er ikke det samme som den originale kode men tæt nok til at man kan læse og forstå koden.
Gravatar #27 - Athinira
6. okt. 2021 16:24
arne_v (24) skrev:
#21

Beskrivelsen af Android er ikke korrekt. En APK indeholder ikke Java kilde kode.

Yes, beklager. Det var ud fra hukommelsen. Som altid er du point når det gælder viden om den slags! :-)
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login