klingt vielelicht blöd, aber was auch immer du mit lazarus machst, es ist alles als Quellcode dabei und
kann daher auch alles im Quellcode debugger zur fehlersuche benutzt werden. Ich hab das mal jemand
gezeigt, der innerhalb der Lazarus
IDE einen reproduzierbaren Bug hatte und ihm dann die Lazarus
IDE
in der Lazarus
IDE gestartet und debugging da drin gemacht hab. Da ist natürlich oft das Huhn/Ei Problem
dabei, der Fehler war aber schnell zu finden.
Vieles läuft sehr gut quellcodekompatibel in beiden Welten, aber gerade uralter Delphi Sourcecode,
den man nicht komplett selber geschrieben hat und der deshalb auch oft seltsame Tricksereien
benutzt, deren Grund man oft nicht auf den ersten Blick erkennt, sorgen für solche scheinbar seltsamen
Fehler.
Eine noch so komplette Doku von zB TMemoryStream wird es nicht geben können, aber der Sourcecode ist
komplett, daher die beste Doku.
Wenn es bei deinem Projekt also dabei hakt, würde ich versuchen, den Teil so wie der in dem
alten Projekt realisiert wurde, zu extrahieren, ggf auf eine selbsterstellte
TMyMemoryStream Klasse umzubauen, in der du nur dann die Properties und Methoden public machst, die
dein Quellcode wirklich braucht (das ist oft weniger als man denkt). Auf dem Weg wirst du
vielleicht schneller dir Fehlerursache finden oder einfach im Lazarus Sourcecode irgendwo eine
Implementation finden, die dort gar nicht umgesetzt wurde, weil nur für Windows/Delphi Kompatibilität
dort eingebaut wurde, aber wegen lazarus/fpc Multiplattform Architecktur nicht 1zu1 umsetzbar und
daher oft auch wenig sinnvoll. Das sind oft irgendwelche Windows
API calls, die zwar vielleicht damals
in der Delphi Welt der einzige Weg war und deshalb auch in neueren Delphi versionen möglich sein kann,
aber vielleicht auch anders realisiert.
Oft ist es danach einfacher, die eigene Klasse soweit angepasst zu haben, damit du alle Implementationen
in deinem alten Source dabei per Suchen/Ersetzen darauf umstellen kannst und irgendwann das Ziel
immer näher kommt.