Keskustelu: Yleinen keskustelu: Jännä tietorakenne

Minkähänlainen tietorakenne näyttää muistissa tältä? Tuo "30 33 5A 02" on pointteri tuon rakenteen alkuun. Rakenne on suht kookas ja sisältää aika paljon tyhjää. Siihen on tallennettu sekä pointtereita, että ihan tekstiä (stringeinä): se vaikuttaisi olevan aika yleiskäyttöinen. Noita samanlaisia on kyseisessä ohjelmassa ainakin pari-kolme kappaletta, olen siis tutkinut vain osan sen ohjelman rakenteesta. Data vaikuttaisi olevan järjestettynä taulukkomaisesti eli kaikki jäsenet ovat samankokoisia (kuvassa yksi jäsen sattuu olemaan yksi rivi). Lisäksi vaikuttaisi siltä, että rakennetta myös käsiteltäisiin taulukkomaisesti. Laitoin breakpointin yhteen jäseneen ja tähän käskyyn se pysähtyi: MOV ECX, DWORD PTR[EBX+ECX*4].

Omiin silmiini tuo rakenne vaikuttaisi tavalliselta taulukolta, jonka joka neljäs jäsen on pointteri taulukon alkuun. Juurikin tuo on se, mikä minua hämää: miksi tuhlata tilaa siihen, että tallentaa pointterin joka väliin? Lisäksi taulukko on erittäin suuri ja vaikuttaisi sisältävän todella erilaista dataa. Tavalliselta taulukolta odottaisin, että se tallentaa vain johonkin tiettyyn yksittäiseen juttuun liittyvää dataa. Kyseinen rakenne kuitenkin tuntuu tallentavan vähän mitä sattuu. Lisäksi siinä on todella paljon tyhjää tilaa.

Olen siis varsinaisen ongelmani jo ratkaissut, mutta jäi vain vaivaamaan, että mikä ihmeen rakenne tuo oikein on. :)

Olisiko RANDOMina luotu tiedosto? Siellä on usein paljon tyhjää kun tilavaraus tehdään varmuuden vuoksi suuremmaaksi kuin heti on tarpeen.

Eiköhän tuo taulukko ole, jossa on 0x10 kokoisia tietueita. Villi arvaus että taulukkoa käytetään tekstinkäsittelyssä tai -muotoilussa, sillä struktuurin DWORD sarakkeissa 0x8-0xB sisältää vain ASCII-merkkejä: vb, tps, \r\n. Noi ei-taulukon-alkuun osoittavat pointterit on jänniä, ja olisi kiva tietää mitä niiden takaa löytyy.

Toki tuo pointteri taulukon alkuun on hieman turha, mutta jos jollekin funktiolle välitetään osoitin yhteen alkioon, niin funktio pystyy selvittämään sen pointterin perusteella mihin taulukkoon alkio kuuluu. Voisi sen tehokkaamminkin toteuttaa.

Yksittäisen heksadumpin perusteella on paha sanoa mitään.

Jotain tämän kaltaista ehkä:

struct node {
	node*   p_a;  // Osoitin toiseen soluun. Voi olla myös 0 tai 1.
	void*   p_b;  // Osoitin jonnekkin taulun ulkopuolelle (esim 0x03AEEE18) Voi olla myös 0 tai 2.
	char[4] c;    // "tps", "vb", "\r\n" (maks. 3 merkkiä + zerobyte)
	node*   p_first; // Osoitin alkuun
};
node* taulu = 0x025A3330; /* 30 33 5A 02 */

Paha sanoa muuta yhden screenin pohjalta.

Deffi kirjoitti:

Eiköhän tuo taulukko ole, jossa on 0x10 kokoisia tietueita. Villi arvaus että taulukkoa käytetään tekstinkäsittelyssä tai -muotoilussa, sillä struktuurin DWORD sarakkeissa 0x8-0xB sisältää vain ASCII-merkkejä: vb, tps, \r\n.

Hyvä huomio. Täytyypä kiinnittää huomiota siihen, miten ne ASCII-merkit on aseteltu niissä muissa samantyylisissä taulukoissa.

Tuota taulukkoa käytetään ainakin tallentamaan dataa, joka liittyy TStringGridiin. Se on siis taulukko, jonka jokainen solu on hajautettu ympäri muistia ja rivi-rakenteessa on sitten pointteri, jolla tietyn solun data löydetään. Lisäksi rivit on vielä hajautettu samalla tavalla. Mutta tuossa taulukossa on niin paljon sellaista dataa, mikä ei liity siihen TStringGridiin, joten sitä käytetään myös muuhun. Sen takia se mielestäni vaikuttaisi yleiskäyttöiseltä taulukolta. Projektini kannalta siis vain sen TStringGridin sisältö oli olennaista.

Deffi kirjoitti:

Noi ei-taulukon-alkuun osoittavat pointterit on jänniä, ja olisi kiva tietää mitä niiden takaa löytyy.

Osa niistä osoittaa toisiin pointtereihin, jotka ovat tallennettuna vastaavanlaiseen taulukkoon. Se pointteri sitten osoittaa merkkijonoon. Osa pointtereista osoittaa suoraan merkkijonoon, joka on tallennettu vastaavaan taulukkoon. Tuo "tps" on esimerkki merkkijonosta, joka on yhden TStringGrid solun sisältö. Siellä saattaa olla pointtereita, jotka osoittavat muuallekin, mutta olen tutkinut vain niitä, jotka liittyvät TStringGridiin. Niistäkin muodostuu jo aikamoinen viidakko. :)

Deffi kirjoitti:

Toki tuo pointteri taulukon alkuun on hieman turha, mutta jos jollekin funktiolle välitetään osoitin yhteen alkioon, niin funktio pystyy selvittämään sen pointterin perusteella mihin taulukkoon alkio kuuluu. Voisi sen tehokkaamminkin toteuttaa.

Tuo käy kyllä järkeen, koska niitä yksittäisiä alkioita todennäköisesti pyöritellään aika paljon ympäriinsä.

Deffi kirjoitti:

Yksittäisen heksadumpin perusteella on paha sanoa mitään.

Tiedän, mutta ajattelin, että se saattaisi olla jokin ihan yksinkertainen asia jota en vain ole tajunnut.

@Petrinm:
Aika hyvin analysoitu yhden kuvan perusteella. Tuo voisi oikeasti olla aika lähellä. :)

Tutkin asiaa vielä, ja ehkä palailen asiaan lisätietojen ja kuvien kanssa.