Typ "File Of Byte" in einer DLL (Delphi 7)

[DXler]

Also es ist nicht direkt eine Frage, sondern vielmehr ein Tipp für alle diejenigen, die eine Datei byteweise auslesen und/oder schreiben wollen und dies in einer DLL realisieren wollen.


Meine Erfahrung:

Das Verhalten von Delphi 7 diesbezüglich war für mich sehr überraschend, denn der Compiler compiliert die DLL ohne (sichtbare) Probleme.

Allerdings stellte ich beim Test fest, das der Dateizugriff nicht mitcompiliert wurde. Eine genaue Überprüfung des Quelltextes ergab: fehlerfrei!

Das Problem ist Delphi 7, denn wenn man die ".dof"-Datei (Delphi 7) mit einer alten ".dof" (Delphi 6: gleiche Projekt) überschreibt, dann wird die DLL komplett compiliert und funktioniert einwandfrei. Bei der Compilierung wird allerdings ausgegeben, das "File Of Byte" ein unsicherer Typ ist.

Warum das so ist, wird wohl nur Borland wissen.


Wie dem auch sei: das Problem gehe ich so an, das ich das über TStream lösen werde.


Zu dem "Vorfall" mit Delphi 7 kann ich nur sagen: "It's a bug or a feature!"

[scp]

Das dies funktioniert, hängt wohl damit zusammen das sich die Standard-Einstellungen der Kompileroptionen in der .dof geändert haben, welche genau kann ich dir auch nicht sagen.

Das "file of byte" ein unsicherer Typ ist, heisst "nur", das es Probleme geben wird, falls du vorhast das ganze in .Net (Delphi 8 oder 2005) zu übernehmen.

[DXler]

Danke für die schnelle Antwort!

Geändert hat sich:

Version (von "6.0" auf "7.0")


Die folgenden Zeilen sind dazu gekommen:

NamespacePrefix=
SymbolDeprecated=1
SymbolLibrary=1
SymbolPlatform=1
UnitLibrary=1
UnitPlatform=1
UnitDeprecated=1
HResultCompat=1
HidingMember=1
HiddenVirtual=1
Garbage=1
BoundsError=1
ZeroNilCompat=1
StringConstTruncated=1
ForLoopVarVarPar=1
TypedConstVarPar=1
AsgToTypedConst=1
CaseLabelRange=1
ForVariable=1
ConstructingAbstract=1
ComparisonFalse=1
ComparisonTrue=1
ComparingSignedUnsigned=1
CombiningSignedUnsigned=1
UnsupportedConstruct=1
FileOpen=1
FileOpenUnitSrc=1
BadGlobalSymbol=1
DuplicateConstructorDestructor=1
InvalidDirective=1
PackageNoLink=1
PackageThreadVar=1
ImplicitImport=1
HPPEMITIgnored=1
NoRetVal=1
UseBeforeDef=1
ForLoopVarUndef=1
UnitNameMismatch=1
NoCFGFileFound=1
MessageDirective=1
ImplicitVariants=1
UnicodeToLocale=1
LocaleToUnicode=1
ImagebaseMultiple=1
SuspiciousTypecast=1
PrivatePropAccessor=1
UnsafeType=0
UnsafeCode=0
UnsafeCast=0


Folgende sind weggefallen:

[HistoryLists\hlUnitAliases]
Count=1
Item0=WinTypes=Windows;WinProcs=Windows;DbiTypes=B DE;DbiProcs=BDE;DbiErrs=BDE;

Zitat:

Das "file of byte" ein unsicherer Typ ist, heisst "nur", das es Probleme geben wird, falls du vorhast das ganze in .Net (Delphi 8 oder 2005) zu übernehmen.

Da ich nicht vorhabe die DLL in .NET einzubinden, brauche ich mir, streng genommen, darum keine Sorgen machen!

hmmmm.... Komisch ist nur, das die DLL mit der "original" .dof genau 1024 Byte kürzer ist als die "alte" Delphi 6-Version. Scheinbar sind in diesem 1 KB genau die Routinen drin die für die Dateieingabe/-ausgabe zuständig sind.


Die Delphi-Hilfe gab folgendes zurück:

"Sie haben einen Datentyp verwendet oder einen Vorgang ausgeführt, der möglicherweise Speicher überschreibt. In einer gesicherten Ausführungsumgebung wie beispielsweise .NET wird solcher Code als unsicher und potentiell gefährlich betrachtet."

Für mich sieht es so aus, als ob der Compiler mit den "neuen" Projektoptionen diesen "unsicheren" Code gar nicht erst compiliert hat (.NET-Anlehnung). Damit gehört, in meinen Augen, Delphi 7 schon zu stark zu .NET... Und das, obwohl ich die .NET-Funktionalität, die im eingeschränkten Maße bei Delphi 7 Pro dabei ist, nicht installiert habe!