Newsgroup: it.comp.programmare.win32
Titolo: Funzione API che prende l'indi dove parte.....

Ciao,
una domanda ai bravi prograkmatori di WIN32:esiste una funzione API,tipo che
so...GET..QUALCOSA.....,,, che ritorni l'indirizzo dove parte il mio
programma ,o dove parta il primo byte del mio propgramma caricato ?
Grazie1000.
Equinox
--
-- RPG--->#gameprog-ita

programma ,o dove parta il primo byte del mio propgramma caricato ?
Si: 0.
Luc.


Se non viene specificato un indirizzo diverso in fase di link, il programma 
viene mappato all'indirizzo 0x00400000.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)


Qualsiasi sia il tipi di programma?
Grazie ancora.
Equinox

 viene mappato all'indirizzo 0x00400000.
Ah,dimenticavo: c'è una funzione per prendere questo indirizzo?
Grazie ancora.
Equinox

 caricato ?
Ti basta leggere il valore HINSTANCE passato al WinMain() all'inizio
dell'esecuzione: contiene l'indirizzo di caricamento di base del modulo
(che e` vero, e` quasi sempre 0x00400000, ma non e` detto che lo sia per
forza).
Altrimenti anche GetModuleHandle( NULL).
---
Bye! Lorenzo Lutti
http://antani.virtualave.net/

 viene mappato all'indirizzo 0x00400000.
ma se è sempre uguale non è qualcosa di reale, o no?
o è riferito al programma stesso?

: 

E' l'indirizzo in cui viene mappato l'eseguibile.
Può essere cambiato con un parametro del linker e letto con GetModuleHandle
(NULL) o dall'HINSTANCE passato a WinMain (come ricordava giustamente 
Lorenzo Lutti), visto che in Win32 HMODULE e HINSTANCE corrispondono (a 
differenza di quanto accadeva a 16bit).
Non vorrei sbagliarmi (è parecchio che non maneggio l'asm...), ma in 
modalità protetta gli indirizzi fisici in RAM vengono rimappati per ogni 
processo (con la gestione della paginazione ed eventuale swap) e quindi più 
processi possono fare riferimento allo stesso indirizzo e leggere dati 
diversi.


 diversi.
grazie, era questo che volevo sapere.
ciao
xaero

Si: 0.
Risposta piuttosto ermetica e apparentemente inesatta.
Puoi spiegarti meglio ?
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

diversi.
Certo, e' cosi'.


Puoi spiegarti meglio ?
Valter Minute ha detto con molte (e corrette) parole quello che io ho
detto con una sola cifra.
Luc.

detto con una sola cifra.
Mah.... continuo a non capire che cosa volessi dire.
0, inteso come indirizzo, visto che non lo specifichi, e' errato.


0, inteso come indirizzo, visto che non lo specifichi, e' errato.
Ogni processo, in modalità protetta, ha un suo spazio di
indirizzamento che parte "logicamente" da 0x00000000.
Luc.

indirizzamento che parte "logicamente" da 0x00000000.
Lo *spazio di indirizzamento* e' lo spazio indirizzabile dal processo
ed e' chiaro che parte da 0x00000000 per ogni processo.  Ma questa NON
e' la locazione alla quale inizia il codice di programma !


e' la locazione alla quale inizia il codice di programma !
Certo, anche sul C64 i programmi iniziavano dalla loc. 2049. ma gli
indirizzi da 0 ^___^
PS: non sapevo quella dell'indirizzo di partenza a 0x40000...
Luc.

e' la locazione alla quale inizia il codice di programma !
non vi azzuffate =)
tecnicamente parlando avete sia ragione che torto entrambi: 
lo spazio di indirizzamento lineare  e' un concetto che pertiene piu'
all' HW che ad un "processo" od al modello di memoria in uso.. un
indirizzo logico (le cpu IA32 under the hood utilizzano sempre e cmq
la segmentazione) puo' tradursi immediatamente in un indirizzo lineare
e da questo ad un indirizzo fisico.. oppure nel caso di paginazione
passare attraverso un ulteriore meccanismo di indirezione (il cui
funzionamento controllabile da altre variabili: page size,etc) che
permette di implementare c.d virtual memory con relativi spazi di
indirizzamento virtuali (e privati).
Sia win9x che winNt/2k sono S.O. che implementano (con sostanziali
differenze l'uno dall'altro) il c.d. protect flat model..  garantendo
ad ogni "processo" un virtual private address space: quello che
normalmente viene passato alle API di win32 e' ,come del resto mamma
M$ riporta, un virtual address (VA) privato e come tale legato al
memory context del processo.
Saluti,
            Walker Boh

Luc.
Per quel che concerne il c.d. preferred base address (imagebase) a cui
viene mappato un modulo PE la distizione e' fra .exe e "generic" .dll:
x gli .exe il PE loader di win32 e' si aspetta che il linker abbia
impostato il base address a 0x40000 (che x win9x coincide con l'inizio
del private address space; x Nt/2k questo e' 0x10000, infatti gli .exe
NT 3.5x avevano imagebase impostato a tale valore)  xche' puo
utilizzare codice "hardcoded" piu' veloce x il fixup delle import,etc
senza dovere ricorrere a dispendiose operazioni di rilocazione.. del
resto essendo il mem context creato ex-novo x il nuovo processo la
possibilita' di una collisione e' nulla, tant'e' che oramai si tende a
strippare la sez. .reloc.
x le DLL il discorso e' diverso: essendo mappate in seconda istanza,
ed essendo possibile che siano mappate nelle arene shared, esiste la
la possibilita' concreta di collisone, x cui il loader non fa alcuna
assunzione (tranne che per le DLL di sistema che sono mappate ad addr.
hardcoded e top->down).. se la DLL puo e' essere mappata al suo
preferred base address tanto meglio, altrimenti passera' a rilocarla..
in genere a link time la preferred viene impostata ad un medesimo
valore x ogni DLL, cosa che come si puo intuire non e' il max.. meglio
effettuare un rebase (cmq se vuoi approfondire gli articoli di Pietrek
sull'MSDN sono assai esaustivi).
Saluti,
            Walker Boh

tecnicamente parlando avete sia ragione che torto entrambi: 
L'indirizzo 0x00000000 non e' quello da cui inizia il codice di
programma.  Credo che questa sia una verita' incontrastabile sotto
Win32.


Win32.
era mia intenzione affermare, salomonicamente, che _tecnicamente_
indirizzo 0x00000000 vuol dire tutto vuol dire nulla.. indirizzo
fisico , logico,  lineare, virtual, in modalita' PM32, PM16, V86...
ma se vogliamo proprio fare diettrologia, anche in win32, indirizzo
0x00000000, senza specificazione alcuna, non ha significato di per se'
nemmeno parlando di EIP.. omettendo modalita', seg sel, PTE, mode,
ecc.. che poi sia un virtual address e che siamo in PM32 con PG=1, e
che l'esistenza di un code flat_sel nasconda l'arcano e'
circostanziale.. ma nessuno vieta di creare degli alias..... ma
vogliamo davvero fare diettrologia ? personalmente non mi interessa e
sono certo nemmeno a te... xche' entrambi, suppongo, abbiamo di meglio
da fare....so... peace & love =)
[ethical flames on]
io mi chiedo perche' i programmatori abbiano la tendenza ad assumere
che ogni affermazione in apparente contrasto con cio' che sostengono
sia rivolta esclusivamente a :
1) renderli ridicoli
2) metterne in dubbio la professionalita'
3) asserirne l'ignoranza
4) qualche fantomatico complotto
5) ....
"Non prendete la vita troppo sul serio, comunque vada non ne uscirete
vivi."  ,  
J. R. Hoppenheimer
[ethical flames off]
Saluti,
 Walker Boh

sia rivolta esclusivamente a :
Non sono affermazioni in contrasto con cio' che SOSTENGO.
Sono affermazioni in contrasto con cio' che C'E' SCRITTO SUI LIBRI.
E' molto diverso.
Le ramanzine etiche valle a fare a qualcun altro.


Sono affermazioni in contrasto con cio' che C'E' SCRITTO SUI LIBRI.
va bene, constato che preferisci irrigidirti su posizioni del tipo
"ipse dixit"...quali libri ? mi piacerebbe che citassi dove,
possibilimente riportando l'affermazione, si smentisce cio' che ho
scritto relativamente al significato di "indirizzo" per i S.O. win32:
e' forse il Ritcher ? qualche testo di Pietrek ?  i vari "Inside
Window.." , piuttostoche'  i testi di Hazzaz, Viscalora o cosa.. forse
qualche testo dell' MSCE ? non e' che forse in questi testi si parla
_sempre_ di virtual address ?  non e' che forse non ti e' chiara la
distinzione fra linear ,  logical address e virtual address ? allora
temo che tu debba approfondire l'argomento.. in tal caso ti consiglio
di ripassare il #3 vol. sull'archittettura IA32 di Intel, cap.3 e 9, e
quindi passare ad approfondire l'argomento su Pietrek / Hazzaz per
win9x e sul Salomon e Pdabak per NT/2k. 
Cmq sia, credi davvero che basti leggere un libro come il Ritcher per
poter fare affermazioni sull'archittettura win32 ? 
Sono conscio che nel 90% conoscenze, diciamo "system" level,
dell'archittettura sottostante, non sono affatto necessarie, anzi la
ditocotima fra sviluppatori "syslevel" e "general" e' e sara' sempre
piu' marcata (frameworks come .NET non faranno che accentuarla)... ma
onestamente hai mai provato a scontrarti "veramente" con le
problematiche del MM.. chesso' scrivendo un driver che sfrutti
traferimenti DMA (non importa che sia un vecchio .386/sys static od un
WDM, VxD..) ? 
Sara' forse la mia patologica curiosita' o la diffidenza verso la
superficialità rimastami dall'univ,  ma preferisco tastare con mia
propria mano cio' che sui libri si scrive, e non a basarmi solamente
su affermazioni altrui, seppur autorevolissime: mi ha sempre fatto
riparmiare molto tempo sia in fase coding e, soprattutto, di bug
tracking. Prova a disassemblarti il codice del kernel di win9x e di
NT/2k ed iniziare a studiarteli, con pazienza e dovizia negli anni,
chissa' che tu non scopra che forse sui libri che sin'ora hai letto
non c'e' proprio tutto.
Quanto  alle paternali: quella non era ne rivolta a te, ne
circostanziale a questo thread: e' una constatazione generale che
puntualmente vedo confermata nei fatti. Non ho alcuno scopo
evangelico, non interessa far filosofia, e men che meno diettrologia,
sono pragamatico per DNA.
Ultima considerazione: non mi interessa minimamente passare per
l'esperto/tuttologo di turno.. se hai avuto la sventura di leggere i
mei post, avrai notato che non parlo di MFC,VB,ASP,ecc.. io mi
interesso e mi occupo solo di aspetti syslevel
(drivers,security,debug,ecc.) e solo su quello continuero' a
rispondere sino a quando avro' la consapevolezza di poter dire
qualcosa di utile e, soprattutto, corretto.
Per quel che mi riguarda la questione e' chiusa.
Saluti e buon lavoro,
          Walker Boh