Adventure: Syberia 2

[KlyX]

Letzter Beitrag der vorhergehenden Seite:

/me bleibt definitiv einfach bei VisualBasic... Hab mich mal ein paar Tage mit C++ rumgeschlagen und habs dann aufgegeben

[Juluck]

Juchu, das klappt ja ausgezeichnet! Vielen Dank!!

[TheSearcher]

@Marck:
Danke für die Bugmeldung. Du hast recht. Das free(act_filename); gehört in die Umgebung von fclose(output_file);

Ich habe es über diese Zeile gesetzt.

Ich werde auch in Kürze damit beginnen, die Details über das Dateiformat im Wiki zu veröffentlichen. Außerdem will ich, wenn ich wirklich Zeit habe noch ein paar kleinere Erweiterungen vornehmen (entpacken in neu zu erstellenden Ordner), sowie einen dazu passenden Packer schreiben (dies würde es ermöglichen MODs für Syberia zu erstellen). Ich mache halt einfach ungern halbe Sachen.

[KlyX]

Hihi... Könnte man Kate mal anders anziehen oder Oscar ne Wollmütze aufsetzen oder so... Das wäre nett

[Marck]

Das free(act_filename); gehört in die Umgebung von fclose(output_file);

Ich habe es über diese Zeile gesetzt.

Damit hast du aber wieder Speicherlecks, wenn das Tool in die Fehlerbehandlung beim Lesen oder Schreiben einer Datei gerät. Dann wird das Programm nämlich mit 'return' beendet, ohne dass der Speicher freigegeben wird (auch die File-Handles werden dann nicht geschlossen).

[TheSearcher]

@KlyX
Zu deinem Vorhaben, die 3D-Modelle zu editieren. Zumindest die ersten 8 Zeichen dieser Dateien ist ein nullterminierter String mit dem Text "Nemo Fi". Das lässt mich vermuten, dass ein 3D-Programm namens "Nemo" verwendet wird. Weiß jemand näheres über ein derartiges Programm?

@Marck
Danke, man, wenn wir dich nicht hätten. Obgleich ich dazu folgendes sagen muss: bei Beendigung des Programms wird, wenn ich mich nicht täusche doch sowieso sämtlicher mit malloc allokierter Speicher wieder freigegeben. Oder irre ich mich da? Ich will nicht bezweifeln, dass das Nichtfreigeben des Speichers am Ende ein sehr schlechter Programmierstil ist. Aber führt das zum Speicherleck?

Das mit den Filehandles ist in der Tat ein Bug. Das Programm wurde von mir halt sehr schnell zusammengecodet. Was passiert, wenn man Filehandles beim Beenden offen lässt, weiß ich nicht. Werde ich besser schnell beseitigen.

[KlyX]

Nemo 3D sagt mir in der Tat etwas... Und google lässt mich nur nicken:
http://www.openchannelfoundation.org/projects/NEMO_3D

Mehr weiss ich aber auch nicht

[TheSearcher]

Habe aber trotzdem mal alle Bugs beseitigt.

Neuer Sourcecode:

#include <cstdio>
#include <cstdlib>
#include <cstring>

const unsigned long identifier=0x47425856;

int main(int argc, char** argv)
{
FILE* act_file;
FILE* output_file;

if (argc<2)
{
printf("Usage: sybdecode filename.syb\n");
return 1;
}

for (int i=1; i<argc; i++)
{
unsigned long read_identifier;

unsigned long body_adress;
unsigned long header_adress;
unsigned long act_file_length;
unsigned long header_read_end;

act_file=fopen(argv, "rb");

if (act_file==NULL)
{
fprintf(stderr, "Could not open file %s\n", argv);
fclose(act_file);

return 1;
}

if(!fread(&read_identifier, sizeof(unsigned long), 1, act_file))
{
fprintf(stderr, "Unexpected EOF while reading; line=%u\n", __LINE__);
fclose(act_file);

return 1;
}

if (read_identifier!=identifier)
{
printf("Invalid file: identifier must be VXBG\n");
}

if(!fread(&header_read_end, sizeof(unsigned long), 1, act_file))
{
fprintf(stderr, "Unexpected EOF while reading; line=%u\n", __LINE__);
fclose(act_file);

return 1;
}

header_read_end+=4; // The first 4 bytes (identifier) do not count

body_adress=header_read_end+4; // The last 4 bytes of the header are
// the size of the last file in the body

header_adress=8;

while (header_adress<header_read_end)
{

fseek(act_file, header_adress, SEEK_SET);

char* act_filename=NULL;

long act_pos=ftell(act_file);
int act_string_length=0;

char act_char=0;

while (true)
{


if(!fread(&act_char, sizeof(char), 1, act_file))
{
fprintf(stderr, "Unexpected EOF while reading; line=%u\n", __LINE__);
fclose(output_file);
fclose(act_file);

return 1;
}

if (act_char!=0)
act_string_length++;

else
break;
}

act_filename=(char*) malloc(sizeof(char)*(act_string_length+1));

fseek(act_file, act_pos, SEEK_SET);

for (int j=0; j<=act_string_length; j++)
{
if(!fread(act_filename+j, sizeof(char), 1, act_file))
{
fprintf(stderr, "Unexpected EOF while reading; line=%u\n", __LINE__);
free(act_filename);
fclose(output_file);
fclose(act_file);

return 1;
}
}



if(!fread(&act_file_length, sizeof(unsigned long), 1, act_file))
{
fprintf(stderr, "Unexpected EOF while reading; line=%u\n", __LINE__);
free(act_filename);
fclose(output_file);
fclose(act_file);

return 1;
}

header_adress=ftell(act_file);

output_file=fopen(act_filename, "w+b");

if (output_file==NULL)
{
fprintf(stderr, "Could not open file %s\n", act_filename);
free(act_filename);
fclose(output_file);
fclose(act_file);

return 1;
}

printf("filename: %s\n", act_filename);

act_pos=ftell(act_file);

// Reading and outputting the file
fseek(act_file, body_adress, SEEK_SET);

for (unsigned long l=0; l<act_file_length; l++)
{
char act_byte;

if(!fread(&act_byte, sizeof(char), 1, act_file))
{
fprintf(stderr, "Unexpected EOF while reading; line=%u\n", __LINE__);
free(act_filename);
fclose(output_file);
fclose(act_file);

return 1;
}

if(!fwrite(&act_byte, sizeof(char), 1, output_file))
{
fprintf(stderr, "Could not write to file:%s; line=%u\n",
act_filename, __LINE__);
free(act_filename);
fclose(output_file);
fclose(act_file);

return 1;
}
}

// End outputting file

fseek(act_file, act_pos, SEEK_SET);

body_adress+=act_file_length;

free(act_filename);

fclose(output_file);
}

fclose(act_file);

}
}

[Marck]

bei Beendigung des Programms wird, wenn ich mich nicht täusche doch sowieso sämtlicher mit malloc allokierter Speicher wieder freigegeben. Oder irre ich mich da? Ich will nicht bezweifeln, dass das Nichtfreigeben des Speichers am Ende ein sehr schlechter Programmierstil ist. Aber führt das zum Speicherleck?

Ein Speicherleck entsteht eigentlich durch folgende Situation. Man weist einer Zeigervariablen einen dynamisch allozierten Speicherbereich zu (also z.B. mit malloc()). Wie jede andere Variable hat diese Zeigervariable einen Gültigkeitsbereich ("Scope"), der - grob gesagt - durch die geschweiften Klammern begrenzt wird, in der die Variable deklariert wurde. Wenn dieser Gültigkeitsbereich verlassen wird, ohne den Speicherbereich vorher freizugeben, dann ist dieser Speicher für das laufende und alle anderen aktiven Programme nicht mehr verwendbar, weil das Betriebssystem diesen Speicher immer noch dem Programm zugeordnet hat. Ohne die Zeigervariable kannst du diesen Bereich aber auch nicht mehr nutzen oder nachträglich freigeben.

In dem konkreten Fall mit sybdecode ist das nicht weiter tragisch, weil das Programm nach verlassen des Gültigkeitsbereiches der Zeigervariablen act_filename sowieso bald beendet wird. Bei der Beendigung eines Programms wird jeder von ihm angeforderte Speicher tatsächlich automatisch wieder freigegeben.

Relevant wird das Problem aber dann, wenn du deinen Dekodierer später einmal als Teil eines größeren Programms verwenden möchtest und die Dekodier-Routine darin möglicherweise mehrmals aufrufst.

Was passiert, wenn man Filehandles beim Beenden offen lässt, weiß ich nicht.

Gewöhnlich erfolgt der Zugriff auf Dateien gepuffert, es wird also ein Abschnitt der Datei in den Speicher geladen, damit man schneller damit arbeiten kann. Wenn dieser Puffer nach einer Änderung nicht wieder in die Datei zurückgeschrieben wird, dann gehen die Änderungen verloren. Das Schließen einer Datei (bzw. dessen File-Handle) sorgt nun dafür, dass die Puffer ordentlich aufgeräumt werden. Für sybdecode könnte sich das so auswirken, dass ein Teil der gerade extrahierten Datei fehlt und diese dadurch unbrauchbar wird.

Je nach Betriebssystem, Laufzeitumgebung oder Compiler werden aber Dateien nicht unbedingt mit Puffern bearbeitet oder werden bei der Beendigung eines Programms automatisch geschlossen. Aber man kann sich nicht darauf verlassen.

Es ist für mich natürlich einfacher, die Arbeit anderer zu korrigieren als es gleich selbst (und dann auch noch richtig) zu machen. Ich meine es auf keinen Fall böse, sondern bin dir im Gegenteil dankbar dafür, dass du das Dateiformat auseinander klamüsert hast.

Habe aber trotzdem mal alle Bugs beseitigt.

Du meinst wohl, du hast alle bisher bekannten Bugs beseitigt.

[TheSearcher]

@Marck

Danke für deine Kommentare zu den Dateizeigern und Speicherlecks. So im groben wusste ich vieles schon, allerdings waren einige deiner Details eine wertvolle Ergänzung zu meinem Wissen.

Es ist für mich natürlich einfacher, die Arbeit anderer zu korrigieren als es gleich selbst (und dann auch noch richtig) zu machen. Ich meine es auf keinen Fall böse, sondern bin dir im Gegenteil dankbar dafür, dass du das Dateiformat auseinander klamüsert hast.

Da merkt man mal wieder sehr gut in der Praxis den Vorteil von Open Source. Wenn ich den Sourcecode für mich auf der Festplatte behalten hätte, wären die Probleme niemandem aufgefallen. Zum Thema Bugmeldungen: ich sehe das eher wie Donald E. Knuth - Wer in seinem Textsatzsystem TeX einen Bug findet, bekommt von ihm einen Scheck über 100 US$ (fairerweise haben ihn jedoch nur wenige tatsächlich eingelöst) - lediglich mit dem Unterschied, dass ich leider kein Geld übrig habe. Von daher bin ich nur dankbar für die Bugreports.

Das Auseinandernehmen von bislang undokumentierten Dateiformaten ist sowieso, seit ich in der Zeit zwischen Abitur und Studium aus Langeweile damit begann mit einem Hexeditor zu versuchen, einiges aus den Dateien von "Der Druidenzirkel" zu rippen ein privates Hobby von mir geworden. Von daher hat zumindest das Hacken des Formates sowieso Spaß für mich (das Coden eines passenden Entpackers dafür dann Ehrensache).

Du meinst wohl, du hast alle bisher bekannten Bugs beseitigt.

´

Man, so eine Antwort gebe ich doch sonst gerne zurück. Hast aber recht.

@KlyX
Also irgendwie scheint es da mindestens einen Nemo zu viel zu geben, um eindeutig Auskunft über das Programm zu bekommen. Habe mittlerweile die Vermutung, dass es sich um ein Microids-internes Format handelt.

[Thoro]

Das Auseinandernehmen von bislang undokumentierten Dateiformaten ist sowieso, seit ich in der Zeit zwischen Abitur und Studium aus Langeweile damit begann mit einem Hexeditor zu versuchen, einiges aus den Dateien von "Der Druidenzirkel" zu rippen ein privates Hobby von mir geworden. Von daher hat zumindest das Hacken des Formates sowieso Spaß für mich (das Coden eines passenden Entpackers dafür dann Ehrensache).

Mensch, hättste das mal früher gesagt. Da veröffentlich' ich Idiot einfach die Dateiformate für Tiana und du hättest die so gern geknackt.

[The.Modificator]

Das Auseinandernehmen von bislang undokumentierten Dateiformaten ist sowieso, seit ich in der Zeit zwischen Abitur und Studium aus Langeweile damit begann mit einem Hexeditor zu versuchen, einiges aus den Dateien von "Der Druidenzirkel" zu rippen ein privates Hobby von mir geworden. Von daher hat zumindest das Hacken des Formates sowieso Spaß für mich (das Coden eines passenden Entpackers dafür dann Ehrensache).

*zeigt vorsichtig mal auf http://wiki.cobbs.ca/index.php/Prp_files und dann noch deutlicher auf http://wiki.cobbs.ca/index.php/PrpObjectReference...*
(Beim letzteren gibt es noch ne Menge undokumentierter Formate... viel Spaß also! )

Gruß
Modi

[TheSearcher]

@Thoro
Es gibt hinreichend viele andere Formate, die noch unerforscht sind. Außerdem möchte ich damit ein Zeichen gegen die Unsitte der proprietären Formate setzen (Wissen sollte kein Eigentum sein, sondern frei zugänglich), indem ich sie durch meine Forschungen offen lege. Du kannst also ruhig weiter dokumentieren.

@Modi
Würde sicher Spaß machen. Aber mir fehlen bei Uru in vielerlei Hinsicht Kenntnisse über den grundlegenden Aufbau der Dateien, die ich ersteinmal nachholen müsste, bevor ich mich an diese unbekannten Teile der PRPs mache. Da überlasse ich es lieber den alten Hasen von Cobbs und suche mir meine eigenen ökologischen Nischen.