Newsgroup: it.comp.programmare.win32
Titolo: .dll & ANSI C

Ciao a Tutti!
E' la prima volta che posto su questo NG, e lo faccio nella speranza che
voi possiate aiutarmi....
AIUTOOOOOOO!
Ehm,...
Allora, Il cliente per il quale sto lavorando ha commissionato un progetto
da scrivere interamente in ANSI C, che usi una dll che lui stesso ha
fornito, in ambiente MS Visual C 6.0.
Il problema, che' di problema trattasi, e' il seguente:
1) siamo riusciti a caricare la dll unicamente a mezzo di LoadLibrary(...)
2) LoadLibrary(...) la usiamo a patto di includere <window.h>
3) il codice da noi prodotto è ANSI C ed ha estensione .c per forzare il
compilatore a compilare unicamente in C
4) avendo incluso <window.h>, il progetto è ancora da ritenersi ANSI C puro?
Grazie MILLEEE!
The Catcher
P.S.: Se ci avete capito qualcosa e riuscite anche a darmi una risposta....
NON HO PAROLE!
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

>4) avendo incluso <window.h>, il progetto è ancora da ritenersi ANSI C puro?
Imho no visto che tale header non e' parte dello standard ansi, ma se
programmi in ANSI C la non aderenza allo standard non e' da imputare a
te ma al tuo cliente.

 4) avendo incluso <window.h>, il progetto è ancora da ritenersi ANSI C puro?
IMHO è inutile scervellarsi su cosa sia ANSI C e cosa no, tanto questo è 
un (falso?) problema che si risolve alzando la cornetta del telefono e 
chiedendo al cliente cosa vuole :-)  Voglio dire, il cliente ti ha 
chiesto di scrivere il progetto in ANSI C, per te questa specifica non è 
(giustamente, fra l'altro) chiara e non ci guadagni nulla a far finta di 
aver capito :-)
Probabilmente vuole mantenere la portabilità del progetto, ma in tal 
caso deve fornirti la implib e l'header (portabile) delle funzioni 
esposte dalla dll. Altrimenti tu ci puoi fare ben poco e credo sia 
abbastanza comprensibile da parte sua...


Innanzitutto, Vincent, grazie per avermi risposto!
La necessità di scrivere codice ANSI C non è dovuta alla portabilità del
progetto,
ma al fatto che l'applicazione deve garantire un certo grado di sicurezza e
per questo, risparmiandoti il come si è giunti a tale requisito, il codice
'deve' essere ANSI C.
E' vero che potrei alzare la cornetta e chiedere, ma prima di farlo vorrei
poter dire con sicurezza al cliente 'guardi, per poter includere la .dll
fornitami in Visual Studio è necessario includere l'header file windows.h e
cio implica/non implica che il progetto non è più ANSI C, poichè windows.h è
scritto/non è scritto in C++, che facciamo?', capito?
Io dovrei risolvere i problemi al cliente, non presentarmi a lui con un
quesito che nemmeno io non ho ben chiaro in mente.
Per questo il mio problema rimane, windows.h è C++ o C, o meglio, includere
windows.h fa si che il mio progetto non sia più ANSI C complinace?
Un saluto a tutti!



 
Perchč?
P.S. Thank You for your kindness!


>Perchč?
Semplicemente perche' windows.h non fa parte della libreria standard
del C. 
Tieni presente che io considero standard quello che mi porto dietro
col compilatore: librerie, header etc, quello che sviluppo io o devo
usare per creare un programma.

 windows.h fa si che il mio progetto non sia piů ANSI C complinace?
A rigore di standard, un programma "C" che utilizza una qualsiasi
caratteristica non presente nello standard non puo' piu' essere
definito standard [1].
Includere una libreria del S.O. o chiamare una funzione tipo
LoadLibrary() rende il programma "C" non standard.
Chiaramente bisogna pure vedere cosa dovete fare... Se parli di
sicurezza usare la fopen() non e' certo la soluzione migliore per
impedire scritture concorrenti sullo stesso file e una CreateFile()
sarebbe molto piu' opportuna.
C:\>iao Angelo
[1]  Qui c'e' anche da decidere quale standard, C99 o C89? Il primo
     non e' ancora molto diffuso, ma, a rigore, lo standard del C e'
     quello.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 windows.h fa si che il mio progetto non sia più ANSI C complinace?
windows.h è sicuramente C. Tuttavia il problema non è questo, non è che 
usare librerie esterne rende in se il prodotto non ANSI compliance, il 
linguaggio C prevede la possibilità di usare funzioni definite altrove 
(apposta esistono le dichiarazioni), definire tipi con typedef, scrivere 
macro e costanti simboliche con #define, dare direttive al preprocessore 
e via discorrendo.
Se ti preoccupa includere windows.h, non hai che da scrivere:
#ifdef WIN32
#define MYCALL _stdcall /* Microsoft specific */
#else
#define MYCALL
#endif
void  * MYCALL LoadLibraryA(char *libName);
void  * MYCALL GetProcAddress(void * hmodule, char * name);
e sei a cavallo. Formalmente vorrei vedere come possono contestarti la 
non aderenza all'ANSI C di questo pezzo di codice, che funziona 
perfettamente sotto windows e naturalmente non su altri sistemi (occhio: 
sia chiaro che si compila tranquillamente ovunque, non riusciresti a 
linkare perchè ti manca la kernel32.lib), ma come tu hai chiarito la 
portabilità non è un problema.

 quello.
Ciao Angelo,
grazie per la tua attenzione!
Vorrei chiederti un'ultima cosa.
A tuo avviso, esiste un modo per poter chiamare una .dll di una terza parte
(non di S.O. e ovviamente non con LoadLibrary) in un programma ANSI C senza
porlo fuori standard (ammesso che la .dll sia essa stessa ANSI C)?
P.S. Se ad un certo punto avrai letto una cappellata tra le cose che ho
scritto oppure non ho capito una mazza della tua precedente risposta,
please, sii paziente con me. Le opere di bene, in un modo o nell'altro,
vengono sempre ricompensate.


 porlo fuori standard (ammesso che la .dll sia essa stessa ANSI C)?
Linkando nel progetto la libreria di definizioni che viene prodotta 
quando compili la dll.
Altrimenti, l'esempio che ho fatto nell'altro post non ha nulla che sia 
fuori standard, è solo non portabile.

 vengono sempre ricompensate.
Cosa non ti e' chiaro della mia risposta?
C:\>iao Angelo
