Newsgroup: it.comp.programmare.win32
Titolo: Api = Assembly ?

Sfogliando la rete ho trovato un tutorial in cui la prima pagina cioè
la presentazione citava in relazione all'utilizzo di MFC al posto
delle  API questa frase:
"in futuro i programmatori che scriveranno programmi richiamando
direttamente le API del S.O. saranno visti come quelli che oggi
programmano in assembly."
che ne pensate?
rhymes
rhy...@forevergames.net
*************************************
Redattore di Forevergames.net
www.forevergames.net
*************************************

che ne pensate?
non è del tutto sbagliato ... al giorno d'oggi la tecnica + low-level per i
programmatori Win32 consiste nell'utilizzo delle funzioni dell'API di Win32,
tuttavia i vari framework (MFC,VCL etc..) propongono molte funzioni
"alternative" (che in realtà molte volte fanno riferimento alle funzioni
messe a disposizione dal SO) il cui compito è quello di ottenere lo stesso
risultato con una maggiore semplicità e linearità.
Se in futuro per ottenere una lista dei processi dovrai scrivere :
MiaStringList := ListaProcessi;
Vorrà dire che ListaProcessi (dove ListaProcessi è una funzione del tuo
framework) svolge una decina di righe di codice al tuo posto ....
Il paragone fatto dallo scrittore non è ne perfetto ne errato ... a mio
avviso ci può stare!
Ciao!
--
- Carlo -

che ne pensate?
Credo sia vero, ma temo non sia una cosa positiva. :-(
Saluti,
    Mardy

Credo sia vero, ma temo non sia una cosa positiva. :-(
rhymes


 programmano in assembly."
Sono parzialmente d'accordo. C'e` pero` da dire che a tutt'oggi non
esiste ancora un framework che permetta veramente di fare *tutto*, sia
MFC che gli altri hanno le loro lacune ed e` sempre necessario chiamare
qualche API.
---
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

qualche API.
Condivido e dico che dubito esisterà mai un Framework in grado di sostituire
al 100% l'API di Win32 ... i Framework che più "rischiano" di avvicinarsi a
questo primato sono sicuramente quelli Microsoft, ma neppure loro possono
permettersi di modificare i vari Framework ogni qual volta viene
creata/modificata/aggiornata una funzione dell'API.


x'?
Perche' c'e' il rischio di costruire programmi sempre piu' grossi e piu'
lenti, mentre usando le API si riduce il codice al minimo indispensabile.
In realta' ho solo paura di essere sommerso da programmi in Visual Basic.
;-)
Saluti,
    Mardy

;-)
rhymes



Per applicazioni semplici impiegheranno piů tempo  per realizzare i
programmi  che perň saranno piů efficienti e compatti;
per applicazioni corpose ........ utilizzano Visual C++  con MFC o
equivalenti.
Ciao.
Salvo

lenti, mentre usando le API si riduce il codice al minimo indispensabile.
Be', la cosa piu' importante non e' la grossezza del codice, ma la sua
efficienza, e l'efficienza e' assicurata solo utilizzando dei tool
(leggi framework di sviluppo) scritti da persone competenti ;)
--
Andrea Laforgia (UIN 87230455)
----------------------------------------------------------
Non scrivetemi per e-mail, se non richiesto espressamente.
No replies in private e-mail, unless explicitly requested.
----------------------------------------------------------

 che ne pensate?
beh? che c'e' di male a programmare in assembly? ;o) 
Sono dell'idea che chi non conosce almeno a grandi linee l'assembly non sa
veramente cosa sta facendo quando lavora in C.
Il concetto di puntatore, il modificatore register, l'indicizzazione dei
vettori presuppongono che si conosca come funzioni la macchina e quindi,
almeno a grandi linee, come funzioni l'assembly. E' chiaro che non sarebbe
ragionevole sviluppare un programma di contabilita' o un CAD in assembly,
ma delle volte ci puo' togliere dalle rogne.
un esempio banale: voglio inviare o ricevere un carattere sul bus senza
sviluppare un driver (in Win98, WinNT usa i ring)
unsigned char inp_bus(unsigned short port)
{
asm
	{
	mov dx,port
	mov eax,0
	in al,dx
	}
}
void out_bus(unsigned short port,unsigned char ch_out)
{
asm 
	{
	mov dx,port
	mov al,ch_out
	out dx,al
	}
}
vedete un po' se vale la pena di sviluppare un driver...

> che ne pensate?
Che non ha  molto senso. Guarda tutte le volte che  in VB devi mettere
una chiamata a sistema per avere  qualcosa che nessun OCX offre (nè ha
senso  mettere  in  ocx).    Si  programma  troppo  in  maniera  "poco
ecologica" sprecando cicli macchina (e quelli costano energia :) )...
EF> beh? che c'e' di male a programmare in assembly? ;o) 
Niente! Sopratutto quando hai CPU che supportano istruzioni spassose come
la move -(PC), -(PC) del PDP 11 :)
EF> Sono dell'idea che chi non conosce almeno a grandi linee l'assembly non sa
EF> veramente cosa sta facendo quando lavora in C.
C O N C O R D O  appieno. Anche se certe volte gli ottimizzatori combinano
delle cose :)...
EF> ragionevole sviluppare un programma di contabilita'
Allora quel codice assembler 360 che ho visto serviva per il tetris in
pausa pranzo :)
EF> o un CAD in assembly,
EF> ma delle volte ci puo' togliere dalle rogne.
Diciamo che  è dal 1973 che  è stato dimostrato con  esempio che l'uso
dell'assembler in  maniera esplicita non è  necessario.  Oltretutto le
CPU  di oggi  sono talmente  incasinate come  regole  di instradamento
delle  istruzioni che  un ottimizzatore  può battere  un  programma in
assembler -non fatto da un programmatore _esperto_-. 
EF> un esempio banale: voglio inviare o ricevere un carattere sul bus senza
EF> sviluppare un driver (in Win98, WinNT usa i ring)
[... omissis ...]
EF> vedete un po' se vale la pena di sviluppare un driver...
Su un bel tomo di programmazione di sistema di Windows 95 ho letto che
Windows9x ha  in ogni  caso una trap  per istruzione "che  non sarebbe
consentita" dopodiché permette l'esecuzione  della stessa, solo con un
ritardo.
Visto cosa vuole dire creare un VXD - e che si può fare in C! - meglio
spesso è il piccolo ritardo :) :), nonostante la poca ecologia...
+----------------------------------------------------------------+
| Gian Uberto Lauri * "So, are you working on fixing that bug    |
| 
sa...@eng.it
      *  *now* or leaving it until later ?" - YES  |
+----------------------------------------------------------------+
| Attenzione: rispondo ad ogni invio di pubblicità non richiesta | 
| o spam di qualsiasi altro genere con un messaggio al provider  |
| di competenza. Ai sensi della legge sulla privacy NON avete il |
| permesso di utilizzare i miei dati per questi scopi.           |
+----------------------------------------------------------------+


Alcune parti dei driver sono normalmente sviluppate in assembler.
[...]
Comunque questo codice non dovrebbe funzionare sotto NT... E sono 
disponibili soluzioni pre-costruite per relizzare drivers che si limitino a 
in e out.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)