[Allegro] war: import.exe und sehr große dateien (2GB-grenze) -> nachbeobachtungen -> kein qrix-problem, es ist nur MULTIX

[Thomas Berger]

Hallo Herr Lehmann,

> ich begreife nicht, warum qrix keine datei fassen kann, die größer als 
> "unsere" magische grenze ist??!! alle(?) programme unter win32, 
> sowieso unter win64 können dateien fassen größer als 2,1GB
> warum das 32bit qrix.exe nicht???? eine ernsthafte frage!

Ich habe in den letzten Tagen mehr ueber das Problem gelernt,
als ich mir je haette traeumen lassen dass es da zu lernen gab.

Die relevanten Normierungen fuer die diversen Programmiersprachen
ANSI-C und C++ aus verschiedenen Jahren und abstrakten
Betriebsystemschnittstellen (POSIX etwa oder die Gnu Library) sollte
man fuer moeglichst portierbare Programme naturgemaess moeglichst
wenig verlassen. Fuer Dateien sind da etwa fopen() und fseek() der
recht portable Standard, das heisst aber, dass hier nicht nur die
Namen der Funktionen sondern auch die Datentypen ihrer Argumente
und Rueckgabewerte ebenfalls spezifiziert sind. Und zwar als "long".

Auf fast allen 32bit-Plattformen (das geht ja auf den Intel 386
zurueck bzw. auf den MC 68020, Prozessoren, die Mitte der 1980er
Jahre auf den Markt gekommen sind) ist long ein 32bit Integer.
Vorzeichenbehaftet, da man in Dateien ggfls. auch zurueckspulen
koennen will. Daher stammt dann die Grenze von 2GB fuer einzelne
Dateien.

Auf einer 64bit-Plattform "funktionieren" diese Standards auch
heute noch ganz problemlos, dort ist ein "long" typischerweise
64 Bit breit, das versagt also erst bei einer Dateigroesse von
8 Exabyte (wofuer momentan noch Millionen der groessten
handelsueblichen Platten zusammengeschaltet werden muessten).
Reale Dateisysteme und Betriebssysteme moegen das derzeit noch
staerker einschraenken: FAT32 (durchaus noch relevant fuer Speicher-
karten) erlaubt etwa nur 4GB grosse Dateien, NTFS immerhin 16TB,
Linux-Kernels auf 32bit-Systemen ohne die Setzung "CONFIG_LBD" (gibt
es solche Systeme noch?) erlauben nur Platten und Dateien bis 2TB.
Jedenfalls: 64bit-Programme auf 64bit-Betriebssystemen koennen
identischen Quellcode mit ihren 32bit-Pendants haben und das 2GB-
Problem loest sich dennoch automatisch in Luft auf.

Fuer die 32bit-Plattformen gab es bereits in den 1990er-Jahren diverse
Anstrengungen, auch auf 32bit-Plattformen das Nadeloehr "long" zu
ueberwinden und die sind eigentlich auch seit 10 Jahren ueberall
implementiert, aber eben jenseits der Standards (man konnte ja fseek()
etc. nicht um-standardisieren). Microsoft bietet __fseeki64() an,
unter Linux (bzw. glibc) gibt es zwei Ansaetze: open() und lseek()
arbeiten eher low-level und haben nicht "long"-Argumente, sondern
einen eigenen Typ off_t, der ueber einen Compiler-Schalter "transparent"
von 32 auf 64 bit umgeschaltet werden kann; alternativ gibt es
mit fseeko() einen Ersatz fuer fseek().

Existierende Programme fuer 32bit-Plattformen muessen jedenfalls
in Bezug auf I/O 1.) komplett umgeschrieben werden, damit sie mit Dateien
groesser 2GB umgehen koennen, und es gibt 2.) a priori keine Art, sie
so umzuschreiben dass sie weiterhin identisch auf M$ und Linux-
oder Solaris-Plattformen laufen: Man muss daher also selber eine
geeignete Abstraktionsschicht zwischenschalten.

Dann gibt es noch ein drittes Problem, das speziell allegro betrifft,
und zwar fuer die U**X-Plattformen, da die Microsoft-Plattformen
standardisierte C-Laufzeitumgebungen besitzen bzw. man dem Benutzer
eher vorschreiben kann, die aktuellen Servicepacks ihrer Betriebssyteme
aufzuspielen (die dann die aktuellen MSCRT.DLL's enthalten) als einem
Solaris-Nutzer, auf die aktuellste Version seines Betriebsystems auf-
zuruesten: Von allegro-Modulen werden Binaries verteilt, fuer alle Windows-
Plattformen genuegt dann eines (oder zwei, wenn man auch 64bit-Binaries
verteilen will). "Nacktes" Unix geht hingegen von Compilation aus Sourcen
auf der Zielplattform aus, Binaries werden fuer spezielle Distributionen
in derem Kontext verteilt (und neue bzw. veraenderte Programme insbesondere
nur fuer solche Distributionen, die noch aktiv gepflegt werden, heute also
z.B. nur fuer RHEL 5 und RHEL 6, nicht mehr fuer RHEL 4). Bislang war das
eigentlich nie ein Problem, ein avanti, der heute auf irgendeinem realen Linux-
System (32bit i386) compiliert worden ist funktioniert auch auf allen anderen,
selbst wenn deren Kernel-Versionsstaende recht stark voneinander abweichen
(und nur darauf kommt es an, die Distribution - Debian, CentOS, OpenSUSE
etc. - ist eher der organisatorische Rahmen fuer die Verteilung, Installation
und Registrierung der individuellen Softwarepakete, die Distribution also ;-).

Benoetigt man nun die erst in den letzten 10 oder weniger Jahren eingefuehrten
Workarounds fuer die 2GB-Grenze und verlaesst damit staerker den Bereich der
seit 15-20 Jahren etablierten Standards, wird das Riskio deutlich groesser,
dass ein Binary auf einer realen, aber schrecklich alten Maschine gar nicht
mehr funktioniert (beim selber Compilieren haette man oft sofort anhand der
einschlaegigen Fehlermeldungen gemerkt, dass es auf der Maschine gar nicht
funktionieren kann).

Fazit: Versucht man fuer *32bit-Plattformen* die 2GB-Grenze zu umschiffen,
muss man recht viel im Code aendern, staerker die unterschiedlichen Welten
von M$ und U**X beruecksichtigen und kommt fuer konkrete Systeme mit
mittel- oder sehr alter Hard- oder Software (FAT32, alte Linux-Kernels ohne
CONFIG_LBD) dennoch u.U. nicht weiter (und deren Besitzer *wollen* ja
wahrscheinlich auch keine 2GB-Monsterdateien mit allegro verarbeiten).

Vermutlich wird es deutlich einfacher sein, die vorhandenen Module so
zu ueberarbeiten, dass sie *auch* auf 64bit-Systemen (nativ) laufen
und begleitend die Ansage zu machen, dass jemand, der Dateigroessen
oberhalb 2GB verarbeiten will, das mit der 64bit-Version zu machen hat.
Das ist ja schon lange keine exotische Technologie, meinen ersten 64bit-
Linux-Server habe ich Ende 2005 beschafft und inzwischen schon wieder
stillgelegt, den Microsoft Server 2008R2 (seit 2010 auf dem Markt?) gibt
es ausschliesslich als 64bit-Version und fuer Desktops sieht es so aus,
dass die beliebten, alten "MS-DOS"-16bit-allegro-Module deshalb rasant
eingemottet werden, *weil* die Anwender zum grossen Teil 64bit-Betriebssysteme
neu beschaffen und einsetzen, einfach *weil* vom Preis-Leistungsverhaeltnis
guenstige Arbeitsspeichergroessen inzwischen so gross sind, dass ein
32bit-System bereits eine minimale Ausstattung nicht ganz nutzen kann...

viele Gruesse
Thomas Berger