1

salut, je veux savoir s'il y a possibilité de récupérer la date système sans utiliser l'interruption int 21h et son service 2AH.MERCI.

2

depuis quelques dizaines d'années on utilise des APIs pour ça.

windows:
http://msdn.microsoft.com/en-us/library/w4ddyt9h%28VS.71%29.aspx

linux:
http://linux.die.net/man/2/time
http://linux.die.net/man/3/localtime

si tu es sous linux et que tu veux forcément utiliser des interruptions, tu peux chercher comment on fait un appel système linux en assembleur

3

Les appels systèmes se font via syscall et sysenter, mais ça dépend du processeur utilisé (amd ou intel), ou bien via une interruption pourrie (0x80 pour linux, 0x2E pour windows) mais en général tu ne veux pas les effectuer toi même car c'est un API à priori non public.
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

4

sisi. je chercherai demain, j'ai un exemple pour write()

5

GoldenCrystal (./3) :
mais ça dépend du processeur utilisé (amd ou intel)

Tu es sûr ? Ca m'étonne.
GoldenCrystal (./3) :
car c'est un API à priori non public.

Non, c'est public. C'est même l'une des API les plus stable que je connaisse.

6

PpHd (./5) :
GoldenCrystal (./3) :
mais ça dépend du processeur utilisé (amd ou intel)
Tu es sûr ? Ca m'étonne.
Certain oui sad
GoldenCrystal (./3) :
car c'est un API à priori non public.

Non, c'est public. C'est même l'une des API les plus stable que je connaisse.
Donc les numéros attribués pour linux sont fixes et définitifs ? Oo
Pour Windows en tout cas, ce n'est pas le cas.
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

7

8

GoldenCrystal (./6) :
PpHd (./5) :
GoldenCrystal (./3) :
mais ça dépend du processeur utilisé (amd ou intel)
Tu es sûr ? Ca m'étonne.
Certain oui frown.gif


Sous windows, sous linux ou sous les 2 ?

9

Les deux ^^
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

10

Les exemples donnés pas Squalyl pour Windows sont en fait des fonctions de la bibliothèque C. Une API indépendante du langage, c'est par exemple GetLocalTime().

Sinon, la façon dont sont effectués les appels API pour les applications n'est pas la même sous Linux et sous Windows. Néanmoins le but est le même : faire que les anciennes applications compilées continuent à fonctionner sur un système plus récent (oui, c'est aussi possible avec Linux, par exemple en faisant une compilation statique pour ne pas avoir de problème de dépendances : on demande d'inclure le code de toutes les bibliothèques utilisées dans l'exécutable, les seuls liens dynamiques restant étant les fonctions du noyau comme write()) :

- sous Linux, les numéros des fonctions du noyau sont définis une fois pour toutes, et les appels se font effectivement avec l'interruption 0x80 ou l'instruction SYSENTER.

- sous Windows, les appels de fonctions API se font comme des appels de sous-routines ordinaires, mais le linker laisse un "blanc" à la place de l'adresse de la fonction, et le nom en clair de la fonction est inclus dans une table dans l'exécutable. Au chargement du programme, le système remplit ces blancs avec les adresses des fonctions correspondant à chaque nom. (on peut aussi utiliser un numéro à la place du nom de la fonction, mais ceux-ci changent à chaque version de Windows, donc la compatibilité n'est pas assurée).

Tout ceci concerne uniquement les applications, pour les drivers et le fonctionnement interne c'est potentiellement différent (par exemple, sous Win9x, les VxD utilisaient une instruction int, avec patchage du code à chaud pour le remplacer par une instruction call après la première exécution de l'appel, histoire d'améliorer les perfs -- oui oui, du code noyau automodifiant hehe)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

Zerosquare (./10) :
Sinon, la façon dont sont effectués les appels API pour les applications n'est pas la même sous Linux et sous Windows. Néanmoins le but est le même : faire que les anciennes applications compilées continuent à fonctionner sur un système plus récent (oui, c'est aussi possible avec Linux, par exemple en faisant une compilation statique pour ne pas avoir de problème de dépendances : on demande d'inclure le code de toutes les bibliothèques utilisées dans l'exécutable, les seuls liens dynamiques restant étant les fonctions du noyau comme write()) :
Non en fait, c'est la même.
- sous Linux, les numéros des fonctions du noyau sont définis une fois pour toutes, et les appels se font effectivement avec l'interruption 0x80 ou l'instruction SYSENTER.
ou SYSCALL embarrassed
- sous Windows, les appels de fonctions API se font comme des appels de sous-routines ordinaires, mais le linker laisse un "blanc" à la place de l'adresse de la fonction, et le nom en clair de la fonction est inclus dans une table dans l'exécutable. Au chargement du programme, le système remplit ces blancs avec les adresses des fonctions correspondant à chaque nom. (on peut aussi utiliser un numéro à la place du nom de la fonction, mais ceux-ci changent à chaque version de Windows, donc la compatibilité n'est pas assurée).
Tu viens de décrire le fonctionnement des DLL... Sous linux les libraries dynamique fonctionnent pareil...
Tout ceci concerne uniquement les applications, pour les drivers et le fonctionnement interne c'est potentiellement différent
Oui, les drivers en mode système ont directement accès à l'API natif vu qu'ils sont en mode système...

Pour le reste, tout comme sous linux les appels systèmes ont un wrapper dans glibc (ou autre similaire), les appels système sous Windows ont un wrapper dans NTDLL. Après effectivement, j'avais pas tenu compte que linux n'avait pas vraiment d'API en dehors de ses appels systèmes donc effectivement c'est logique que les numéros d'appels système soient fixes...

En résumé
Linux <=> Noyau Windows
glibc <=> ntdll
.dll <=> .so

Y'a rien de plus. tongue
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

12

J'en ai bien conscience, mais j'ai basé ma comparaison sur le niveau le plus bas qu'une appli pouvait utiliser de manière "portable" (d'une version à l'autre du même OS). Tu ne trouves pas d'applis Windows qui appellent directement le noyau (du moins, je ne crois pas), et une appli Linux qui utilise des libs dynamiques n'est pas portable.

Après, on est d'accord, les fonctions du noyau Linux sont grosso modo au même niveau que celles du noyau Windows, pas à celui des API Windows.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo