Noyau 64 bits : appel aux béta-testeurs.

A Jack de répondre.

Mais je sais qu'en 64 bits, les entiers de 32 bits existent, dans certains langages (Delphi, C, ...), tout comme les entiers de 16 bits, de 8 bits ET de 64 bits.

Ce qui est certain, c'est que les handle et les adr() sont obligatoirement sur 64 bits. Et comme en Panoramic, il faut les stocker dans des endiers x%, je suppose que les entiers Panoramic sont systématiquement sur 64 bits. A moins que Jack introduise un nouveau type de données, ce dont je doute.

Est-ce que tu arrives à faire marcher tes dll en 32 bits avec AutoIt?

Il y a 10 minutes, j'ai réussi à faire marcher KGF.dll fonction KGFdllVersion avec AutoIt. Voici le code du script:

Code:

Local $dll, $ver, $sver
$sver = "1234567890123456789012345"

$dll = DllOpen("KGF.dll")

$ver = DllCall($dll, "int", "KGFdllVersion", "str*", $sver)
$sver = $ver[1]
;  la valeur de retour $ver est un tableau.
;  indice 0: valeur numérique retournée pr la formule
; indice n : valeur du paramètre n

MsgBox(0,"","A: result=" & $ver[0] & @crlf & "param1=" & $ver[1] & "  $sver=" & $sver)

DllClose($dll)

Je vais maintenant creuser plus loin. Mais ce code est censé marcher également en 64 bits...

Il y en a un qui va être content cette nuit:


Par contre la version 32 bits ne marche pas.
et maintenant

Gratulation
congratulations
Félicitations

YES !!!!! Merci pour ce test en 64 bits ! Cela prouve que je peux produire, sur mon système XP Proo SP3 en 32 bits, des DLLs pour un système 64 bits ! Le pied ! Maintenant, il ne me reste plus qu'à intégrer les fonctions, les unes après les autres. Un gros boulot, mais le chemin est tracé.

Je ferai prochainement un post détaillé pour expliquer la démarche.

Pour la version 32 bits: es-tu sûr d'avoir essayé avec un AutoIt en 32 bits pour appeler KGF.dll en 32 bits ?

La séparation des deux versions est absolument stricte: aucun programme 64 bits ne peut appeler une DLL 32 bits, et vice-versa ! Chez moi, ce script marche très bien avec mon AutoIt 32 bits et ma DLL de 32 bits.

Non c'est la version 64 bits qui s'est installé. Je ne vois pas l'intérêt de chercher à mettre la version 32 bits. Tu le fais sur ton ordi, donc je laisse ainsi.
Bravo et bonne nuit!

@Klaus

Eine Bitte, könntest du die DLL so benennen:

Für 32BIT = KGF032.dll
Für 64BIT = KFG064.dll

und wenn es keine Umstände macht,
die Beschreibung für DLL als reine Textdatei.

Wie DOCK.TXT für Windows EDITOR,
ist leichter zu Übersetzen.

Danke

@Cosmos70:
OK. Ceci explique cela. Dont acte.

@Severin:
Dein Vorschlag ist sinnvoll. Aber man sollte auch die andere Spur verfolgen: Alles, was 32 bit ist, sollte in dem WOWxxx Zweig untergebracht sein, und alles was 64 bits ist, im Standard_Windows-Zweig. Ich werde das noch genauer untersuchen.

Ja, die Aufteilung von Windows 7 ist genau so.

Aber ich habe alle DLL für Panoramic in einem
eigenen Verzeichnis, damit ich diese von den
Originalen getrennt halten kann. Bisher kein
Problem, neue Version einfach überkopieren.

Da ich 4 Computer habe, könnte die Pflege
schwierig werden. Jetzt verschiebe ich 1 Verzeichnis
auf alle Computer.

Ich müsste dann 2 Verzeichnisse mit gleichen
Dateinamen anlegen.

Das war der Grund meiner Bitte.

Verstehe. Werd's mir überlegen.

Voici un script AutoIt pour Windows 32 bits, capable de lire KGF.dll. Pour le moment, c'est la fonction KGFdllVersion qui est utilisée. Je suis en train de voir cela pour d'autres:

Code:

Local $dll, $ver, $sver
$sver = "1234567890123456789012345"

Local $stString = DllStructCreate("char v[25]")
DllStructSetData($stString, 1, $sver)

$dll = DllOpen("KGF.dll")              ; my full Delphi 6 DLL

$ver = DllCall($dll, "int", "KGFdllVersion", "ptr*", DllStructGetPtr($stString))
MsgBox(0,"","Return value: " & $ver[0] & @CRLF _
      & "Structure pointer: " & $ver[1] & @CRLF _
     & "Data from structure: " & DllStructGetData($stString,"v") )
DllClose($dll)

Cela marche sur 64 bits.
Je m'étais demandé comment javais une installation sur 64 bits, je ne me souvenais pas de l'avoir installé.

En réalité AutoIt est copié depuis une clé USB dans C, et c'est au lancement que le choix du 64 bits se fait.

Tant mieux ! Cela marche chez moi en 32 bits, avec KGF.dll qui est en 32 bits. Et si le même script marche en 64 bits, c'est super !

J'ai mis en ligne une nouvelle version de KGF.dll en 64 bits: KGF64.dll. Elle contient maintenant 2 fonctions opérationnelles:
- KGFdllVersion
- SearchListBox

J'ai surtout pensé à Severin enchoisissant SearchListBox comme seconde fonction migrée en 64 bits.

@Severin: Eine neue KGF64.dll ist auf MyDrive. Si hat die zwei oben aufgeführten Functionen - es müsste mit 64 bit laufen. Ich habe speziell an Dich gedacht, als ich diese Funktion als zweites Migrationsbeispiel auswählte. Du sagtest, Du vervendest nur diese Funktion. Sowie eine 64 bit Version von Panoramic.exe zur Verfügung steht, kannt Du damit testen.

Voici un programme de démo, à exécuter avec un éventuel Panoramic.exe en 64 bits:

Code:

' Lazarus_test_KGF.bas

dim i%, s$, crit$
list 1 : top 1,200 : left 1,10
font_names_load 1

dll_on "KGF64.dll"

s$ = string$(255," ")
i% = dll_call1("KGFdllVersion",adr(s$))
print str$(i%)
print trim$(s$)

 crit$ = "Arial"
 i% = dll_call3("SearchListBox",handle(1),0,adr(crit$)) : ' chercher une police qui débute avec crit$
'  i% = dll_call3("SearchListBox",handle(1),1,adr(crit$)) : ' chercher une police qui s'appelle crit$
 print ""
 print "Indexe de Arial = "+str$(i%)

end

EDIT

J'ai légèrement épuré le code du programme Panoramic de test.

Pour ma part, à moins que tu veuilles avoir un résultat j'attendrais pour faire des essais. 64 bits, c'est juste pour AutoIt. Panoramic n'est pas vraiment au point en 64 bits, et il n'y a pas urgence. Que toi tu te prépares, c'est autre chose.

Voici une nouvelle version de KGF64.dll, avec 4 nouvelles fonctions portées en mode 64 bits. Les fonctions disponibles sont donc:
- KGFdllVersion
- SearchListBox
- KGFDelimitedTextExtract
- KGFDelimitedTextReplace
- KGFDelimitedTextInsert
- KGFDelimitedTextRemove

4 fonctions supplémentaires portées en 64 bits:
- KGFdllVersion
- SearchListBox
- KGFDelimitedTextExtract
- KGFDelimitedTextReplace
- KGFDelimitedTextInsert
- KGFDelimitedTextRemove
- GetScrollBarInfo
- GetWindowByTitle
- CopyToClipboard
- CopyObject

@Klaus

eine Frage zu KFG.DLL und LoadProgram.dll.

Bei der LoadProgram.dll ist folgender Code erforderlich:

dll_on "LoadProgram.dll"
ancien% = dll_call3("SetFormParent",PARENTNUMMER1%,PARENTNUMMER2%,1)
dll_off

Ist bei KFG.DLL der gleiche Code beziehungsweise Die parameter gleich ?
Kann ich einfach LoadProgram.dll durch KFG.DLL ersetzen ?
Wenn ich die DLL umbenene erhalte ich eine Fehlermeldung.
Sind die Aufrufe zwischen KFG.DLL und KFG64.DLL gleich ?

When LoadProgram.dll following code is required:

dll_on "LoadProgram.dll"
ancien% = dll_call3 ("SetFormParent" PARENTNUMMER1% PARENTNUMMER2%, 1)
dll_off

KFG.DLL at the same code or the parameter is equal to?
Can I simply replace LoadProgram.dll KFG.DLL?
If I umbenene the DLL I get an error message.
Are the calls between KFG.DLL and KFG64.DLL equal?

Lorsque LoadProgram.dll code suivant est nécessaire:

dll_on "LoadProgram.dll"
Ancien% = dll_call3 ("SetFormParent" PARENTNUMMER1% PARENTNUMMER2%, 1)
dll_off

KFG.DLL au même code ou le paramètre est égal à?
Puis-je simplement remplacer KFG.DLL LoadProgram.dll?
Si je umbenene la DLL je reçois un message d'erreur.
Les appels entre KFG.DLL et KFG64.DLL égale?

Die Funktionen von LoadProgramDll sind einfach in KGF.dll integriert. Man braucht LoadProgramDll nicht mehr getrennt von KGF.dll. Und der Aufruf ist natütlich identisch.

J'ouvre un nouveau fil de discussion "KGF.dll 64 bits" dans la rubrique "Le site de Klaus". Toutes les nouveautés se trouveront désormais à cet endroit.

cosmos70 a écrit:

Pour ma part, à moins que tu veuilles avoir un résultat j'attendrais pour faire des essais. 64 bits, c'est juste pour AutoIt. Panoramic n'est pas vraiment au point en 64 bits, et il n'y a pas urgence. Que toi tu te prépares, c'est autre chose.

D'accord avec cosmos...
Surtout qu'on ne sait pas encore comment Jack va définir les formats de variables (unsigned , short unsigned,etc...)

Citation :

Surtout qu'on ne sait pas encore comment Jack va définir les formats de variables (unsigned , short unsigned,etc...)

????????????????

Pour que Panoramic reste compatible, la seule définition de variable est envisageable:
dim n%
et n% étant alors un entier dans le sens des systèmes 64 bits, donc en 64 bits. Tout autre définition rendrait impossible d'écrire
handle% = handle(10)
ou
adresse% = adr(s$)
puisque des handle et des adresses sont en 64 bits en environnement 64 bits. Je parierais gros sur ce que rien ne changera au niveau de la définition du langage, avec simplement on passage automatique de 32 à 64 bits.

Actuellement, (Panoramic 32 bits), les entiers signés codés sur 32 bits vont de :
- 2 147 483 648 à
+2 147 483 647

Ils sont déclarés par exemple par
DIM A%
A% peut prendre toute valeur de la plage ci-dessus indiquée.


Je pense qu’en 64 bits, les variables garderont la même déclaration
DIM A%
Mais dans ce cas, la plage des valeurs possibles sera simplement étendue, de
- 9 223 372 036 854 775 808 à
+9 223 372 036 854 775 807

De cette façon, la compatibilité entre nos programmes dont les entiers sont codés sur 32 bits et ceux qui seront codés sur 64 bits reste assurée.

papydall a écrit:

Actuellement, (Panoramic 32 bits), les entiers signés codés sur 32 bits vont de :
- 2 147 483 648 à
+2 147 483 647

Ils sont déclarés par exemple par
DIM A%
A% peut prendre toute valeur de la plage ci-dessus indiquée.

Je pense qu’en 64 bits, les variables garderont la même déclaration
DIM A%
Mais dans ce cas, la plage des valeurs possibles sera simplement étendue, de
- 9 223 372 036 854 775 808 à
+9 223 372 036 854 775 807

De cette façon, la compatibilité entre nos programmes dont les entiers sont codés sur 32 bits et ceux qui seront codés sur 64 bits reste assurée.

Tu as tout dis Papydall : je parle de compatibilité ascendante qui ne sera (forcement) pas possible si un entier 32 bits et un entier 64 bits sont déclarés de la même manière...

C'est d'ailleurs une des raisons qui font qu'en C par exemple, la déclaration est différente et que le mot clé "short" a été rajouté pour le passage 16 bits <-> 32 bits (et maintenant unsigned long long pour le 64 bits).
J'en sais quelque chose j'avais certains vieux sources qui tournaient avant sur du z80 (16bits) et qui maintenant s’exécutent sur des cartes Pentium (32 bits)... il m'a fallu redéclarer toutes les variables unsigned int en unsigned short int... pour rester compatible au niveau de certains calculs...

Si tu conçois un programme qui utilise la plage 64bits pour des calculs (Klaus, un entier ne sert pas uniquement que pour stocker des adresses ou des handle ) et que le source tu l’exécutes sur un système 32bits, cela risque de ne pas fonctionner comme tu le souhaites...