Discussion :

[pucenet]

bonjour je suis à la recherche de documentation sur les prefixes segments programmes soit ( psp )

si quelqu'un connait une url merci

[Laurent Dardenne]

Salut,
Ralf Brown's Interrupt List en HTML (Faut chercher l'interrupt adéquate ) :
http://www.ctyme.com/rbrown.htm

Version Zip ( recherche sur mot clé + facile ) :
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html
Par curiosité que souhaites tu faire avec ?

[pucenet]

Dans un premier temps je te remercie d'avoir pris le temps de me répondre

dans un second temps pour répondre à ta question je souhaiterais faire un désassembler/débuggeur nouvelle génération en prenant compte des paramètre et module de le génération 8086 de chez Intel ainsi que de chez AMD et par la même occasions développer dans un autre temps sur la nouvelle génération de processeur 64 Bit Réel donc l’archi risque de changer de chez Intel qui ne vas pas tarder à sortir je pence septembre début octobre et pour finir pour l'adapter à linux et l'optimiser à fond cet à dire regarder tout les programme de même type qu'il existe regarder les pluging qui sont adapter et les recoder avec une optimisation native dans le logiciel mais pour commencer comme tu t'en doute il me faux les ( psp ) voila

Question :
=======

Tu n'est pas intéresser je cherche du monde

Salut,
Ralf Brown's Interrupt List en HTML (Faut chercher l'interrupt adéquate ) :
http://www.ctyme.com/rbrown.htm

Version Zip ( recherche sur mot clé + facile ) :
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html
Par curiosité que souhaites tu faire avec ?

[Laurent Dardenne]

Tu n'est pas intéresser je cherche du monde

Non merci, j'ai fort à faire en tant que rédacteur sur DVP et puis ayant goûté à l'objet j'ai désormais un peu de mal avec l'assembleur.
Bonne continuation .

[/dev/null]

En théorie, l'architecture IA64 (qui n'est pas encore au point effectivement) ne devrait pas être compatible nativement avec IA32 mais de façon emuler... comme sur les itanium.

AMD64, qui rique fort d'être la nouvelle norme, n'apporte pas de modification significative dans l'architecture...

Et c'est quoi ces PSP... ça me parle pas du tout comme truc !!!

[pucenet]

À mon avis je pence fort que AMD risque d'être très loin derrière je suis pas pour Intel comme pour AMD mais une chose qui est sure c'est que IA64 ne seront pas émuler mais seront devenus des vrais 64 Bit et pas des 32 qui émule du 64 à causse des problème de compatibilité sa c chez AMD !!! il faudra attendre la fin de l'année pour être fixer

Mais je ne veux pas être pro Intel mais qu'as fait AMD ?? Rien il copie Intel mais il innove rien jusqu'as présent oui ya 6mois en arrière ils ont pris le dessus c vrais mais un truc qui et sur c que la réponse d'Intel vas arriver et elle vas faire mal

Quand pence tu ?


et le PSP c prefixes segments programmes ( psp ) quand tu ouvre un fichier .exe dans un editeur hexadécimal sa correcpond au 256 premier Octet pourquoi 256 , 16 puissance 16 . voila

[/dev/null]

En fait, je supporte les inovations... Intel en a un bon nombre à sont actif, et je trouve domage qu'il dédaigne certainne composante des AMD qui lui permetrait d'être optimal. On devrais être fixé effectivement en fin d'anné... mais AMD64 n'émule pas du 64bit avec du 32 ... ça voudrait dire que IA32 est émulé par x86 .
J'espaire qu'Intel feras pas une cagade en fait parce que sont architectue 64 et pas mauvaise en elle même... mais elle a le malheur de pas arrivé à étre compatible IA32... verifie L'architecture Itanium... tu comprendras ceux que je veux dire .

Depuis deux ans Intel a des démarches que j'aime moyen... au lieu d'optimiser sont microcode comme AMD a été obliger de le faire, car incapable de suivre au niveau frequence, il on augmenter les optimizations secondaire . Je trouve ça trés domage... Il veule faire du bi-corp... ce qui est une trés bonne idée (surtou avec un bi-corp HT ). Mais s'il faisait pareille avec refonte des microcode... on peut s'attendre a une tuerie !

Le domainde de predilection d'Intel, qui était sa superbe FPU, est tombé... maintenant c'est le multi-tache... heureusement !!! Je te dirait... ça m'ennuyrais de voir partir Intel (casiment impossible, mais regarde IBM !). Il est à l'orgine de l'architecture super-scalaire, des liaisons croisé dans les cache, le mode protéger (trés mal exploité à sa naissance), les SIMD, etc... et ça... ça joue en ça faveur pour mes préférences. Mais... trop de foutage de gueuel ces dernières années... Intel s'essouflerait il ? J'espaire pas en tout cas .

Heu... le PSP fait partie de l'entête PE ?

[/dev/null]

le PSP c prefixes segments programmes ( psp ) quand tu ouvre un fichier .exe dans un editeur hexadécimal sa correcpond au 256 premier Octet[...]

Si je ne me trompe pas, les 256o d'un exe... a peut prés parceque c'est pas sur a chauque fois (sa depend du code compiler a l'interieur)... corresponde surtout a la stucture MSDOS (MZ) et y'a, peut être, à peine le Debut de l'en tête PE...

y'a pas un bug

Puis

[...]pourquoi 256 , 16 puissance 16 . voila

Ok... je connais mes puissance de 2... donc cher moi 2 puissance 8 ça fais bien 256... mais 16 puissance 16 ça revien a (2^3)^16, soit 2^48... ce qui dépasse de sur les 4M du 2^32...
J'imagine que tu voulais dire 16*16... mais ça m'aide pas ce genre de réponse

[Sub0]

Euh... Veuillez m'excuser, mais que vient faire ce sujet dans le forum Delphi au juste ?

[/dev/null]

J'avais pas fait gaffe... ta pas tord Sub0
L'abitude j'imagine...

[Sub0]

Sujet déplacé dans le bon forum (du moins j'espère ^^)

à+

[pucenet]

Bref oui pour les puissance perso je les connait de tete desoler par contre tu veut savoir quoi exatement au niveau du psp ? car je vois pas , tu me dit que sa te parle pas c quoi qui ne te parle pas??

le PSP c prefixes segments programmes ( psp ) quand tu ouvre un fichier .exe dans un editeur hexadécimal sa correcpond au 256 premier Octet[...]

Si je ne me trompe pas, les 256o d'un exe... a peut prés parceque c'est pas sur a chauque fois (sa depend du code compiler a l'interieur)... corresponde surtout a la stucture MSDOS (MZ) et y'a, peut être, à peine le Debut de l'en tête PE...

y'a pas un bug

Puis

[...]pourquoi 256 , 16 puissance 16 . voila

Ok... je connais mes puissance de 2... donc cher moi 2 puissance 8 ça fais bien 256... mais 16 puissance 16 ça revien a (2^3)^16, soit 2^48... ce qui dépasse de sur les 4M du 2^32...
J'imagine que tu voulais dire 16*16... mais ça m'aide pas ce genre de réponse

[/dev/null]

J'aurais mis en Asm plutôt ... mais bon... de toute façon... l'avais qu'a le mettre ou il fallait de basse

[/dev/null]

En gros, le PSP est censé contenir quoi ? Et à quoi est-il censé servir ?
Voilà

[Sub0]

J'aurais mis en Asm plutôt...

J'ai aussi hésité pour l'asm... Va pour le forum Assembleur.

[Laurent Dardenne]

La gestion des PSP c'est du dev système, que ce soit sous C sous assembeur ou sous Delphi.
J'ai trouvé ceci pour info

Offset Size Description (Table 01378)
00h 2 BYTEs INT 20 instruction for CP/M CALL 0 program termination
the CDh 20h here is often used as a signature for a valid PSP
02h WORD segment of first byte beyond memory allocated to program
04h BYTE (DOS) unused filler
(OS/2) count of fake DOS version returns
05h BYTE CP/M CALL 5 service request (FAR CALL to absolute 000C0h)
BUG: (DOS 2+ DEBUG) PSPs created by DEBUG point at 000BEh
06h WORD CP/M compatibility--size of first segment for .COM files
08h 2 BYTEs remainder of FAR JMP at 05h
0Ah DWORD stored INT 22 termination address
0Eh DWORD stored INT 23 control-Break handler address
12h DWORD DOS 1.1+ stored INT 24 critical error handler address
16h WORD segment of parent PSP
18h 20 BYTEs DOS 2+ Job File Table, one byte per file handle, FFh = closed
2Ch WORD DOS 2+ segment of environment for process (see #01379)
2Eh DWORD DOS 2+ process's SS:SP on entry to last INT 21 call
32h WORD DOS 3+ number of entries in JFT (default 20)
34h DWORD DOS 3+ pointer to JFT (default PSP:0018h)
38h DWORD DOS 3+ pointer to previous PSP (default FFFFFFFFh in 3.x)
used by SHARE in DOS 3.3
3Ch BYTE DOS 4+ (DBCS) interim console flag (see AX=6301h)
Novell DOS 7 DBCS interim flag as set with AX=6301h
(possibly also used by Far East MS-DOS 3.2-3.3)
3Dh BYTE (APPEND) TrueName flag (see INT 2F/AX=B711h)
3Eh BYTE (Novell NetWare) flag: next byte initialized if CEh
(OS/2) capabilities flag
3Fh BYTE (Novell NetWare) Novell task number if previous byte is CEh
40h 2 BYTEs DOS 5+ version to return on INT 21/AH=30h
42h WORD (MSWindows3) selector of next PSP (PDB) in linked list
Windows keeps a linked list of Windows programs only
44h WORD (MSWindows3) "PDB_Partition"
46h WORD (MSWindows3) "PDB_NextPDB"
48h BYTE (MSWindows3) bit 0 set if non-Windows application (WINOLDAP)
49h BYTE unused by DOS versions <= 6.00
4Ch WORD (MSWindows3) "PDB_EntryStack"
4Eh 2 BYTEs unused by DOS versions <= 6.00
50h 3 BYTEs DOS 2+ service request (INT 21/RETF instructions)
53h 2 BYTEs unused in DOS versions <= 6.00
55h 7 BYTEs unused in DOS versions <= 6.00; can be used to make first FCB
into an extended FCB
5Ch 16 BYTEs first default FCB, filled in from first commandline argument
overwrites second FCB if opened
6Ch 16 BYTEs second default FCB, filled in from second commandline argument
overwrites beginning of commandline if opened
7Ch 4 BYTEs unused
80h 128 BYTEs commandline / default DTA
command tail is BYTE for length of tail, N BYTEs for the tail,
followed by a BYTE containing 0Dh
Notes: in DOS v3+, the limit on simultaneously open files may be increased by
allocating memory for a new open file table, filling it with FFh,
copying the first 20 bytes from the default table, and adjusting the
pointer and count at 34h and 32h. However, DOS will only copy the
first 20 file handles into a child PSP (including the one created on
EXEC).
in an OS/2 DOS box, values of D0h-FEh in the open file table indicate
device drivers
network redirectors based on the original MS-Net implementation use
values of 80h-FEh in the open file table to indicate remote files;
Novell NetWare also uses values from FEh down to 80h or one more than
FILES= (whichever is greater) to indicate remote files (except on
OS/2, where is uses CFh down to 80h)
MS-DOS 5.00 incorrectly fills the FCB fields when loading a program
high; the first FCB is empty and the second contains the first
parameter
some DOS extenders place protected-mode values in various PSP fields
such as the "parent" field, which can confuse PSP walkers. Always
check either for the CDh 20h signature or that the suspected PSP is
at the beginning of a memory block which owns itself (the preceding
paragraph should be a valid MCB with "owner" the same as the
suspected PSP).
Novell NetWare updates the fields at offsets 3Eh and 3Fh without
checking that a legal PSP segment is current; see AH=50h for further
discussion
for 4DOS and Windows95, the command tail may be more than 126
characters; in that case, the length byte will be set to 7Fh (with
an 0Dh in the 127th position at offset FFh), and the first 126
characters will be stored in the PSP, with the entire command line
in the environment variable CMDLINE; under at least some versions
of 4DOS, the byte at offset FFh is *not* set to 0Dh, so there is no
terminating carriage return in the PSP's command tail.

Format of environment block:
Offset Size Description (Table 01379)
00h N BYTEs first environment variable, ASCIZ string of form "var=value"
N BYTEs second environment variable, ASCIZ string
...
N BYTEs last environment variable, ASCIZ string of form "var=value"
BYTE 00h
---DOS 3.0+ ---
WORD number of strings following environment (normally 1)
N BYTEs ASCIZ full pathname of program owning this environment
other strings may follow

[Edit]
C'est un post baladeur
[/edit]

[/dev/null]

ça ne me dit pas trop encore ce qu'es le PSP... ça m'a l'air d'être une entête MS-DOS... un peut vielle
mais ça n'a rien a voir avec l'architecture ni les actuelle entête PE ça...
J'vois pas trop l'age de la technologie dont on parle ? ça datte d'hier ou de 1975 ?

[Nico*3-3]

Le PSP ne sert que pour les programmes DOS (si tu veux émuler ça... ).
C'est un peu comme le 'format' des éxecutables DOS lorsqu'ils sont chargés en mémoire : une en-tête pour que le DOS sache où sont situés les segments etc...

Mais le PSP n'existe qu'en mémoire !
Le exe DOS sur le disque ont une en-tête mais ce n'est pas le PSP, il faut faire attention, j'ai l'impression que tu n'as pas distingué clairement les deux...

Mais ça datte de l'âge de pierre ces trucs...

Si tu veux émuler des programmes d'autres plates-formes, il va falloir que tu regardes pour les autres formats...

Je sais que les en-têtes des PE de Windows sur le disque font 1024 octets (je crois...) dont une en-tête pour le DOS pour être compatible...

[/dev/null]

PE = taille variable...
L'entête peut avoir plusieur section, de taille differente... la seul chose est quelle est arondie au 4Ko...

Maintenant je vois de quoi on parle, et pourquoi je savais pas de quoi on parlai ...

[Nico*3-3]

L'en-tête déclare les sections je crois...
Ainsi que leurs attributs, leur taille etc...

Les sections elles-même sont arrangées pour que leur taille soit multiple de 4 Ko à cause du paging (un truc du mode protégé) qui permet de voir la mémoire comme une sorte de 'répertoire' (mais les OS ne l'utilise pas forcément, apparemment Windows oui...).

PE != Taille Variable
PE = Portable Executable