Delphi konvertering

Hvorfor ikke gå til Delphi7 (current version) ?

Da vi på nuværende tidspunkt har andre systemer, som benytter sig af delphi5, så har vi et ønske om at samle alle systemer på en delphi platform, før vi tager stilling til yderligere opgradering.

Er det kode konvertering eller projekt konvertering du leder efter
info om.

Jeg kan ikke tro, at der skulle være problemer med koden. Uden at vide
det med sikkerhed, så tror jeg ikke, at de har fjernet API'er.

Men projektet (settings, build etc.etc.) er naturligvis en anden sag.
Har du prøvet at åbnet et 1 projekt med 5 og se hvor mange fejl der kommer ?

Hej Arne.

Jeg har været på nettet og læst flere artikler omkring emnet. Jeg kan hermed informere dig om at der rent faktisk er mange problemer, da vi jo skal skifte fra en 16 api til 32bits api. De 2 api'er er adskildt i windows.

Yderligere info:
* Projekt filerne er ikke ens opbygget.
* ASM kode kan ikke konverteres direkte.
* Den første byte i en streng fortæller i delphi1 længden af strengen.
  Flere forskellige typer kan ikke direkte oversættes.

* DFM filer og res filer som indeholder billeder skal opdateres seperat.

Mvh
Michael

Jeg har prøvet at åbne projektet i delphi5 og kan selvfølgelig bare starte fra en ende af, men systemet er omkring 200.000 linier kode og det vil jo tage sin tid at komme gennem dette. Jeg vil jo gerne finde ud af hvor gæret er lavest.

Du kan stadig benytte den gammeldags stringtype med længden i første byte og max 255 tegn - den hedder ShortString i "moderne" Delphi - i hverfald Delphi 6 og 7, jeg husker ikke om det også er så i Delphi 5.

I Delphi 7 kan man med compilerdirektiver {$H-} angive, at den generiske type string skal opfattes som ShortString.

Du skal også være opmærksom på alignment i records, hvor standarden kan være ændret.  Her er lidt om emnet fra Delphis Help:

When a record type is declared in the {$A+} state (the default), and when the declaration does not include a packed modifier, the type is an unpacked record type, and the fields of the record are aligned for efficient access by the CPU. The alignment is controlled by the type of each field and by whether fields are declared together. Every data type has an inherent alignment, which is automatically computed by the compiler. The alignment can be 1, 2, 4, or 8, and represents the byte boundary that a value of the type must be stored on to provide the most efficient access. The table below lists the alignments for all data types.

Type alignment masks
Type    Alignment
Ordinal types    size of the type (1, 2, 4, or 8)
Real types    2 for Real48, 4 for Single, 8 for Double and Extended
Short string types    1
Array types    same as the element type of the array.
Record types    the largest alignment of the fields in the record
Set types    size of the type if 1, 2, or 4, otherwise 1
All other types    determined by the $A directive.
To ensure proper alignment of the fields in an unpacked record type, the compiler inserts an unused byte before fields with an alignment of 2, and up to three unused bytes before fields with an alignment of 4, if required. Finally, the compiler rounds the total size of the record upward to the byte boundary specified by the largest alignment of any of the fields.
If two fields share a common type specification, they are packed even if the declaration does not include the packed modifier and the record type is not declared in the {$A-} state. Thus, for example, given the following declaration

type
  TMyRecord = record
    A, B: Extended;
    C: Extended;
  end;

A and B are packed (aligned on byte boundaries) because they share the same type specification. The compiler pads the structure with unused bytes to ensure that C appears on a quadword boundary.

When a record type is declared in the {$A-} state, or when the declaration includes the packed modifier, the fields of the record are not aligned, but are instead assigned consecutive offsets. The total size of such a packed record is simply the size of all the fields. Because data alignment can change, it's a good idea to pack any record structure that you intend to write to disk or pass in memory to another module compiled using a different version of the compiler.

Øh.

32 bit Windows API er et superset af 16 bit Windows API.

Der er tilføjet men ike fjernet.

[hoved-regel - jeg skal ikke kunne udelukke at der er undtagelser]

Derfor er der en del "overflødige" argumenter i Win32 kald som
kun er der fordi de blev brugt i 16 bit Windows.

Koden (eksklusiv assembler !!!!) bør ikke give de store problemer.

Medmindre strenge er persisted, så burde det jo være ligegyldigt
hvor megte længden fylder.

[ellers er der jo som tauron beskriver compiler switches til at
kontrollere det]

Det er projekt og build jeg er mest bekymret for. Og jeg er ikke
overrasket over at Delphi 5 ikke kan konvertere det korrekt.

Hvis I har Delphi 1,2,3,4 og 5 så kunen du jo prøve:
1->2->3->4->5 i.s.f. 1->5 og se om konverteringerne
af projekt struktur så går bedre.

Og med hensyn til assembler så er det slemt. Det skal uden tvivl skrives
om. Og måske var det en god lejlighed til at skrive det om til noget
andet end assembler.

Men det kan godt tage lang tid. Og jeg tror ikke, at der er nogle gode
tools til det. Forhåbentligt er det vel-dokumenteret !

Hej Arne.

Beklager at jeg fik sagt at 16 og 32 api er adskildt.

Du har nok ret i at der ikke findes nogen nem løsning.

Jeg havde jo på en eller anden måde håbet på, at der var en utility, som kunne lave hovedparten af konverteringen.

Jeg må vel afsætte tiden og starte fra en ende af.

Mvh
Michael