Nyt kävi heikosti. Ikivanha Visual Basic-ohjelma on kateissa. Exe vain löytyy.
Pitäisi tehdä ohjelmaan muutos, kun laskennan raja tuli vastaan.
Ohjelmaa voisi samalla hieman muutenkin kehitellä.
Mutta tallessa on vain exe. Miten siitä saisi pohjan uuden version tekemiseen.
Jos oikein googlettelin, sellaisia ohjelmia on, jolla exen voi koodata takaisinpäin?
Pitäisi tehdä ohjelmaan muutos, kun laskennan raja tuli vastaan.
Ohjelmaa voisi samalla hieman muutenkin kehitellä.
Mutta tallessa on vain exe. Miten siitä saisi pohjan uuden version tekemiseen.
Jos oikein googlettelin, sellaisia ohjelmia on, jolla exen voi koodata takaisinpäin?
Vastaukset 6
Vanhimmat
Jollakin tasolla, kyllä. Mitä et saa takaisin on mm. muuttujien nimet - ne eivät ole tallessa. Funktioden nimet voi olla osittain tallessa - en ole varma onko VB:ssä niiden pituutta rajoitettu, mm. Pascal:ssa on 32 merkin raja eli ensimmäisten 32 merkin on erottava toisistaan: Mangle:a ei ollut vielä keksitty.
Taaksepäin käännös ei ole välttämättä yksikäsitteinen: Esim. eri silmukkarakenteet voi olla hankala erottaa toisistaan. Muitakin rakenteita on, joita ei pystytä kääntämään taaksepäin, esim. unionien tunnistaminen voi olla hankalaa. Et saa mistään include-tietoja ts. mitä kirjastoja on mukaan otettu. Myöskään koodia ei pysty jakamaan automaattisesti loogisesti tiedostoihin. Jos ohjelma sisältää data-lohkoja, ne voi näkyä outoina koodilohkoina, jotka tuottavat kyseisen datan. Samoin käy kohdille, joita koodista ei tunnisteta.
Useinkaan nuo kääntämisen purkajat ei tuota ajettavaa koodia, koska kaikkea ei saada käänettyä. Niistä voi olla hyötyä jos aiemmin mainitut epäkohdat ei haittaa, esim. jonkin algoritmin pelastaminen koodista voi onnistua, jos se on yksittäisenä funktiona toteutettu matemaattinen lauseke.
Siihen löytyy neuroverkkoratkaisuja, että tunnistetaan vaikka map, filter, sort, reverse, min, max jne. tyyppisiä rakenteita mutta ne varmaan tajuaa itsekin kun ymmärtää mikä se ratkaistava ongelma on.
Joka tapauksessa lähtökohta olisi kaikissa tilanteissa se, että kirjoittaa ajettavat testit. Helposti ratkaistavaan ongelmaan löytyy valmiit rakennuspalikat jostain frameworkista että voi sitten kieltäkin valita sen mukaan.
Visual Basic teki kahdenlaisia käännöksiä:
1. Bytecode käännös jota tulkilla ajettiin
2. Prosessorin natiiviksi tehty käännös
Tuota ensimmäistä käytettiin kehittäessä ja oli helpommin ajettavissa rivi kerrallaan ja debuggaus helpompaa, jälkimmäinen sitten se tuotantokäännös.
Bytecode oli jossain määrin purettavissa, siihen löytyy ohjelmia ja olen käyttänytkin mutta lopputulos oli melko ripulia.
Jälkimmäieen tarvitsee disassembleria ja on erittäin työlästä saada mitään selvää siitä.
Jos se on bytecodea niin etsi ohjelma ja pura että saat vähän selville mitä se on syönyt, siitä voi olla apua.
Mutta noin muuten sitten suositeltava toimintatapa on seuraava:
1. Mieti uusi ohjelmointikieli millä ratkaiset ongelman. Mikä on sopiva kieli tähän riippuu ongelmasta.
2. Kirjoita testejä ohjelmointikielellä, kun syöte on jotain ja tehdään jotain niin lopputulos on jotain. Tämä on helposti tehtävissä kun sinulla on vanha ohjelma ajokunnossa että voit ottaa syötteitä ja lopputuloksia joilla tehdä kattava testipatteri.
3. Kirjoita ohjelma uusiksi. Voit testeillä varmistaa että olet ratkaissut laskennan oikein.
Koodin takaisinkoodasohjelmat on nykyään loistavia. Mutta absoluutista palautusta ne ei tee, vaan koko koodi pitää käydä läpi.
Visual Basic on ongelmallinen koska nää on suuniteltu pääasiassa tunnetuimmille kielille.
EXE ei ole oikeeta koodia vaan vaatii vb kääntäjän.
Edellisistä vastauksista paistaa asian tuntemus, sinun vastauksesta tunnistaa ettei vastaajalla ole luettua eikä omakohtaisia kokemuksia asiasta, miksi yrität päteä tuntematta asiaa ollenkaan.
Jäljille on päästy. Koodia ei ole tarpeen tehdä 100%, tosiaan, ohjelmointikieli vaihtuu. Helpottaa vain syntaksin tekoa, kun on jotain vinkkiä. Datalla on isompi arvo kuin ohjelmalla.