[Vc++] Tutorial !

[rambco]

Vorrei cominciare a programmare in Visual C++ ! Un po di cose in c++ le ho fatte ma adesso vorrei passare ad un'interfaccia stile windows con finestre bottoni etc ! Sapete dove trovare una guida dove spiega passo passo come fare ?

[r0x]

VC++ è un compilatore, non un linguaggio (e diecimila). Non devi imparare nulla, VC++ è un compilatore per C/C++, quindi devi sapere o il C o il C++.

Ciao.

[rambco]

ma io intendevo dei tutorial che mi imparano ad utilizzare bottoni finestre etc !

[r0x]

Se con "bottoni, finestre.." intendi le finestre di dialogo classiche di Windows come quelle che ti appaiono, per esempio, appena apri VB, ci sono due soluzioni, una veloce e una approfondita e in un certo senso più verosimile:

1) creare la finestra di dialogo con l'editor di risorse del VC++ e poi richiamare tale risorsa da codice, usando DialogBox(), e poi assegnarvi una procedura;

2) fare tutto da codice. Per farlo devi creare la classe (non nel senso OOP) che identifica la finestra, creare la finestra con CreateWindow() o CreateWindowEx() e poi mostrarla con ShowWindow(); tutti i controlli vanno creati a runtime sempre con CreateWindow(). Come in 1) devi scrivere poi la procedura di gestione della finestra, ma devi scrivere anche il breve ciclo per lo smistamento dei messaggi da inviare alla procedura, ma niente di difficile. Ci sarebbe tanto da parlare ma questo basta per l'inizio.

La prima è la soluzione più semplice, ma in entrambi i casi devi imparare i fondamenti della programmazione Windows, ovvero il sistema dei messaggi (MSG), le classi (WNDCLASS), le procedure (nello specifico WNDPROC) ecc. ecc. Quindi datti da fare perché anche far solo apparire una finestra può essere ostico. Di sicuro però impari a capire un po' come funziona davvero Windows, e cioè non come VB vuole fare credere. E capirai che non è nemmeno troppo semplice.

Cmq sulla MSDN (che è diciamo l'enciclopedia Microsoft..) dovresti trovare brevi tutorial per iniziare, quindi dacci uno sguardo (Win32 SDK). Tale guida è inclusa nel VC++.

Il tutto vale per qualsiasi compilatore C/C++ per Windows a 32-bit (a parte il C++ Builder, che è penoso).

Ciao.

[lucasp]

Originariamente inviato da r0x

Il tutto vale per qualsiasi compilatore C/C++ per Windows a 32-bit (a parte il C++ Builder, che è penoso).

Di Dev C++, che te ne pare?


P.S: io ho uno zip con su una guida alla API Win32 in italiano per chi sa bene il C++, se vi interessa............... mettete sotto la vostra mail

[r0x]

Dev-C++ va benissimo. Sulla MSDN del VC++ trovi tutto il necessario per programmare in Windows, compresa la Win32 API Reference.

Nota: per programmare in Windows basta conoscere il C, perché l'API è scritta totalmente in C. Anzi, vista la compatibilità con il C, se scrivi programmi per Windows interamente in C (e non C++) puoi creare eseguibili anche di 2kb (non compressi). Questo perché spesso (ma purtroppo non sempre) ciò che trovi nella libreria standard C lo trovi anche nell'API di Windows. Per esempio:

'malloc' -> 'HeapAlloc'
'free' -> 'HeapFree'

'sprintf' -> 'wprintf' (non sempre)

'strcpy' -> 'lstrcpy'
'strcmp' -> 'lstrcmp'

...

Nei casi in cui è possibile fare queste sostituzioni, si può creare un eseguibile che dipende solo da due moduli, kernel32 e user32 (che cmq OGNI programma Windows deve linkare per essere eseguito). Ed è ovvio che tali moduli possono essere linkati dinamicamente, visto che sono alla base di Windows ed è impossibile non averli.

Risultato: programma compattissimo e portabile sulle piattaforme Windows senza bisogno di ALCUN file di runtime.

Per esempio ho fatto Snake in C per Windows, occupa 9.5 kb (riallineato 9.28 kb, quindi davvero leggerissimo) e parte su tutte le versioni di Windows senza runtime!

Ciao.

[lucasp]

interessante...................
Ma nn esiste una refewrence anche in Inglese di tutte le funz C come c'è per il php o l'asp??????????
altra piccolissima domanda: è meglio programmare in DOS o Win32??????

P.S: io ho il VC++, solo che è introductory e nn mi permette di usare progetti in cui farmi pagare perche all'apertura dell'EXE mi compare una pallosa DailogBox

P.P.S: lo so che rompo....... ma ti ringrazio per il tempo che perei con me

[r0x]

Di solito ho trovato reference integrati con i compilatori, vedi MSDN del Visual Studio. Molto probabilmente ce ne sono sulle librerie standard C e C++; di sicuro so solo che la Win32 API Reference ufficiale Microsoft in giro si trova, perché io ce l'ho. Ma riguarda solo Windows. Cmq mi pare che hmesfet avesse postato qualcosa a riguardo di recente, quindi magari fai una piccola ricerca nel forum...

DOS e Windows? Beh sono diversi!

Io da parte mia adoro il DOS perché ti permette di accedere direttamente a memoria e hardware, e quindi ti permette anche di "destreggiarti" con l'assembly in modo proficuo. In Windows accedi a tutto tramite l'API, quindi l'uso dell'assembly è limitatissimo.

C'è da fare tuttavia una grossa differenziazione fra DOS in modalità reale 16-bit (quella naturale) e DOS in modalità protetta 32-bit (accessibile tramite i leggendari DOS-extenders come il DOS4GW, quello di tanti giochi DOS, per intenderci..). Il DOS a 32-bit è molto simile a Windows per certi aspetti, dato che anche Windows gira in modalità protetta 32-bit.

Stesso discorso non vale invece per il DOS reale! A me capitava spessissimo di chiedermi, soprattutto quando provavo a far partire qualche vecchio videogioco per DOS, per quale motivo digitando /mem e avendo ben 16 MB di RAM (un'infinità a quei tempi!) il PC vedesse solo quei miseri 640 kb di memoria! Uno strazio! E allora ci si metteva a smanettare con i DEVICEHIGH nel Config.sys e i LH nell'Autoexec.bat ... e dopo tanto penare il gioco partiva. Il motivo risiedeva nella disposizione della memoria in modalità reale 16-bit: la memoria segmentata.

Già l'80386 aveva registri a 32-bit, eppure il DOS ha sempre sfruttato, di sua natura, la modalità reale 16-bit. In C (e sugli Intel), 16-bit corrispondono ad uno 'short', ovvero un numero che varia da 0 a 65535 (0xFFFF in esadecimale), per un totale di 65536 valori assumibili (65536 bytes = 64 kb). In pratica, con un registro si potevano indirizzare fino a 64 kb di memoria (puntatore near, vicino, nello stesso segmento), pochina per noi, ma ai tempi della progettazione anche sufficiente. Tuttavia ci si "preparò al futuro", e ci si inventò un nuovo metodo di indirizzamento, segmentoffset (puntatore far, lontano, con overriding del segmento), costituito da due registri a 16-bit, ma che in effetti era un indirizzo a 20-bit (2^20 bytes = 1 MB):

segmentoffset = segmento * 16 + offset = segmento * 10h + offset (16 è 10h in esadecimale)

A000:000F (segmentato) = A000 * 10 + F = A000F (lineare)

Quindi 20 bits di cui i meno significativi sono i 4 bits meno significativi dell'offset, e gli altri 16 sono costituiti dall'intero registro di segmento.

Con questo metodo di indirizzamento (senza scendere nei particolari dell'implementazione) si poteva quindi indirizzare 1 MB di memoria, che allora era tantissimo!

Quindi, a prescindere dalla memoria totale che possieda un PC, un processore Intel in modalità reale 16-bit può accedere solo al primo MB di RAM. Perché 640 kb? Perché i restanti 384 kb (640 + 384 = 1024 kb = 1 MB) sono riservati al BIOS e al sistema operativo. Diciamo che questa è la principale difficoltà della programmazione in DOS reale.

Cmq se programmi in C/C++ le differenze fra DOS e Windows appaiono relativamente, perché i problemi della memoria se li accolla il compilatore. Programmare in assembly per DOS reale invece è davvero una cosa PAZZESCA e oramai anche parecchio obsoleta, soprattutto se poi vuoi accedere a tutta la RAM e non solo ai 640 kb di memoria convenzionale, attraverso quindi XMS (memoria estesa) ed EMS (memoria espansa).

Invece in Windows e in DOS 32-bit il tipo indirizzamento è lineare (FLAT) a 32-bit (che spiega la dimensione fissa di 4 bytes di un qualsiasi puntatore, equivalente ad un 'long' in C/C++, sempre parlando dei processori Intel, s'intende), e quindi un puntatore può indirizzare fino a 2^32 = 4 GB di RAM! Bel cambiamento eh? E supportato dall'80386 fino ad ora, almeno per quanto riguarda gli Intel. Ma arriverà sicuramente il momento in cui sarà obsoleta anche questa architettura...

Ciao.

[lucasp]

marò come sei informato........... ma quanti anni hai?

[r0x]

19 ieri!