View Full Version : [C] enumerazione contenuto dir
allora, stavolta il mio problema è il seguente: sto lavorando sull'affarone delle DLL (ho fatto altri thread in passato, qualcuno quindi forse se lo ricorda) e devo semplicemente caricare nel mio processo tutte le mie DLL. tutto molto semplice, ma il problema è che il codice deve essere il più possibile portabile (tranne ovviamente il LoadLibrary), quindi devo scrivere un codice compilabile sia in VC++ sia col gcc che in un modo o nell'altro si procuri una lista delle librerie esterne da caricare e e carichi.
avevo pensato semplicemente di mettere le librerie in una dir speciale, e di far enumerare il suo contenuto dal programma, che poi fa un tentativo di caricamento per ciascun file che trova.
come si fa in C puro e portabile ad enumerare il contenuto di una cartella? :) altrimenti avete proposte migliori? thx
RaouL_BennetH
27-08-2005, 22:54
Al solito,ai tuoi quesiti io purtroppo non sono minimamente in grado di risponderti (e giustamente ti chiederai...perchè quindi non ti astieni dal farlo? -> la risposta è: non lo so! )...ma tu quando dici di voler compilare anche con gcc,intendi che vuoi comunque compilare sempre sotto windows?
Se la risposta è si,hai pensato di passare solo le opzioni al compilatore più che scrivere qualcosa in C puro apposta?
Gcc Directory Options
-Bprefix -Idir -iquotedir -Ldir -specs=file -I-
Perdonami se ho solo scritto stupidaggini.
RaouL.
man opendir :D
Scherzi a parte. opendir readdir e closedir sono standard posix e quindi esserci pure su windows.
ciao ;)
Al solito,ai tuoi quesiti io purtroppo non sono minimamente in grado di risponderti (e giustamente ti chiederai...perchè quindi non ti astieni dal farlo? -> la risposta è: non lo so! )... :rotfl:
LOL... però sei simpatico!!! :D
ma tu quando dici di voler compilare anche con gcc,intendi che vuoi comunque compilare sempre sotto windows? dovevo specificare meglio: la risposta è no, devo compilare col gcc e con qualsiasi altro compilatore C. ho scritto tutto in C standard tranne alcune parti non portabili (socket tcp/ip e poche altre cose) che Daniele si è offerto di aiutarmi a portare. :)
Perdonami se ho solo scritto stupidaggini. figurati; cioè NO!!! *non hai* scritto stupidaggini!!!! :D
(dai come gaf sarebbe stata stupenda... :D solo che visto che l'ho scritta non è una gaf... :D scherzi a parte, ognuno ha i suoi campi di specializzazione nei quali eccelle :p e poi se proprio vuoi saperlo le opzioni del gcc che hai scritto non le conosco, quindi sai almeno una cosa più di me :p)
ciao
man opendir :D
Scherzi a parte. opendir readdir e closedir sono standard posix e quindi esserci pure su windows. e infatti non ci sono... :doh:
cercando in MSDN ho trovato una sottosezione di "Win32 and COM programming" che spiega un certo Interix (non so cosa sia) e come migrare da UNIX a Windows... qualcuno ne sa qualcosa? potrebbe servirmi anche per l'università in effetti...
Ho provato a tirare fuori qualche ricordo di api e mi son ricordato qualcosa tipo FindNextFile, FindFirstFile ... forse è quello che ti serve. Ovviamente portabilità 0.
edit: google utile come al solito: http://www.microsoft.com/japan/developer/library/jpwinpf/_win32_findfirstfile.htm :asd:
ciao ;)
Ho provato a tirare fuori qualche ricordo di api e mi son ricordato qualcosa tipo FindNextFile, FindFirstFile ... forse è quello che ti serve. Ovviamente portabilità 0. infatti... e cmq le conoscevo già, e anche non conoscendole sarebbero bastati suppergiù 90 sec in MSDN :D
quello che mi serviva era qualcosa di portabile :\
edit: edit: google utile come al solito: http://www.microsoft.com/japan/deve...ndfirstfile.htm :asd: ma LOL :asd:
RaouL_BennetH
28-08-2005, 00:11
Ue :mbe:
ma io le opendir, readdir etc...che diceva vicius le ho trovate e sono compatibili con windows:
si devono includere le glib: #include <glib.h>
"Windows Compatibility Functions -- functions to support portability to the Windows environment."
http://developer.gnome.org/doc/API/glib/glib-windows-compatability-functions.html
fantoibed
28-08-2005, 00:16
avevo pensato semplicemente di mettere le librerie in una dir speciale, e di far enumerare il suo contenuto dal programma, che poi fa un tentativo di caricamento per ciascun file che trova.
come si fa in C puro e portabile ad enumerare il contenuto di una cartella? :) altrimenti avete proposte migliori? thx
Per cercare le dll usa FindFirstFileEx e FindNextFileEx:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/findfirstfileex.asp
Sono API del sistema operativo e quindi non dipendono dal compilatore (e nemmeno dal linguaggio).
Per caricare le librerie LoadLibrary o GetModuleHandle e per determinare l'entry point della funzione che ti interessa importare usa GetProcAddress che restituisce un long che è l'indirizzo di memoria della funzione che intendi chiamare. Per usare tale funzione, però, devi castarla (nel senso di type casting) al giusto prototipo.
Esempio: user32=GetModuleHandle("USER32.DLL");
SLWA=(BOOL ( __stdcall *) (HWND, COLORREF, BYTE, DWORD)) GetProcAddress(user32, TEXT("SetLayeredWindowAttributes"));
...dove user32 e SLWA sono dichiarate così:HMODULE user32;
BOOL (__stdcall *SLWA)(HWND, COLORREF, BYTE, DWORD);
Ue :mbe: LOL :D
ma io le opendir, readdir etc...che diceva vicius le ho trovate e sono compatibili con windows:
si devono includere le glib: #include <glib.h> si, ma non stanno nel Visual C++ :(
mi sa che per usare quell'header dovrei installare mingw...
Sono API del sistema operativo e quindi non dipendono dal compilatore (e nemmeno dal linguaggio). ehm, però come dire... dipendono dal sistema operativo... (per l'appunto...)
io cercavo un modo portabile per enumerare il contenuto di una cartella.
fantoibed
28-08-2005, 00:44
ehm, però come dire... dipendono dal sistema operativo... (per l'appunto...)
io cercavo un modo portabile per enumerare il contenuto di una cartella.
Hai parlato di DLL però, quindi si presume che l'OS sia Windows... O no?
AnonimoVeneziano
28-08-2005, 02:10
LOL :D
si, ma non stanno nel Visual C++ :(
mi sa che per usare quell'header dovrei installare mingw...
Se vuoi per forza compilare con Visual C++ difficilmente riuscirai a tirare fuori qualcosa di portabile :(
Devi usare un compilatore multipiattaforma , come GCC aka minigw/Dev C++
Forse è possibile anche con Visual C++ ma è sicuramente + semplice con GCC
Ciao
cdimauro
28-08-2005, 06:15
man opendir :D
Scherzi a parte. opendir readdir e closedir sono standard posix e quindi esserci pure su windows.
ciao ;)
Il sottosistema POSIX di Windows non c'è più a partire da XP, se non ricordo male (e comunque era molto vecchio e non aggiornato).
Forse la soluzione sarebbe quella di usare il classico #ifdef a seconda che si lavori con VisualStudio o MingW/Cygwin, creando delle apposite funzioni o macro.
Una palla, insomma... :(
Il sottosistema POSIX di Windows non c'è più a partire da XP, se non ricordo male (e comunque era molto vecchio e non aggiornato).
Forse la soluzione sarebbe quella di usare il classico #ifdef a seconda che si lavori con VisualStudio o MingW/Cygwin, creando delle apposite funzioni o macro.
Una palla, insomma... :(
È un peccato perché in fondo sono molto più facili e intuitive da usare per u programmatore C che ha usato per anni funzioni come fopen e fclose.
ciao ;)
be', riassumendo mi pare di capire che non c'è modo, quindi credo che adotterò quest'altra soluzione: scriverò in un file "index.dat" l'elenco delle librerie che il programma deve cercare nella directory e tentare di caricare: i files li posso leggere tranquillamente in maniera portabile. l'unica cosa che rimane non portabile è la LoadLibrary con relativa GetProcAddress.
fantoibed
28-08-2005, 16:42
be', riassumendo mi pare di capire che non c'è modo, quindi credo che adotterò quest'altra soluzione: scriverò in un file "index.dat" l'elenco delle librerie che il programma deve cercare nella directory e tentare di caricare: i files li posso leggere tranquillamente in maniera portabile. l'unica cosa che rimane non portabile è la LoadLibrary con relativa GetProcAddress.
Io non capisco ancora il tuo problema di portabilità. Hai parlato di VC, mingw e Dev C++ che sono tutti compilatori per Windows. Se usi FindFirstFileEx e FindNextFileEx il tuo codice girerà sarà protabile a tutti e 3 questi compilatori... :)
be', riassumendo mi pare di capire che non c'è modo, quindi credo che adotterò quest'altra soluzione: scriverò in un file "index.dat" l'elenco delle librerie che il programma deve cercare nella directory e tentare di caricare: i files li posso leggere tranquillamente in maniera portabile. l'unica cosa che rimane non portabile è la LoadLibrary con relativa GetProcAddress.
Scusa ma perché non ti crei la tua funzione piglia_lista_files(). la metti in un file separato e poi la implementi in modo diverso a seconda del sistema operativo su cui ti trovi, questione di un #ifdef.
ciao ;)
Io non capisco ancora il tuo problema di portabilità. Hai parlato di VC, mingw e Dev C++ che sono tutti compilatori per Windows. Se usi FindFirstFileEx e FindNextFileEx il tuo codice girerà sarà protabile a tutti e 3 questi compilatori... :) veramente non ho parlato ne' di mingw ne' tantomeno di Dev-C++ :Puke: :D
il programma che sto facendo è C++ puro con pochissime parti Win32 (socket e qualcos'altro) che Daniele mi aiuterà a portare (per fortuna i socket sono quasi identici a quelli di Linux). il sorgente deve essere portabile.
Scusa ma perché non ti crei la tua funzione piglia_lista_files(). la metti in un file separato e poi la implementi in modo diverso a seconda del sistema operativo su cui ti trovi, questione di un #ifdef. si, ma si fa prima leggendo dal file index ;)
scrivo una volta sola e vale sia per Windows che per Linux
cdimauro
29-08-2005, 08:53
È un peccato perché in fondo sono molto più facili e intuitive da usare per u programmatore C che ha usato per anni funzioni come fopen e fclose.
ciao ;)
Beh, se consideri che ogni compilatore C comunque ti offre le fopen, fclose, ecc., il problema nemmeno si pone. :p
Sono le cose fuori dalla libreria standard del C, che rendono la vita problematica per chi realizza codice multipiattaforma.
Comunque il sottosistema POSIX di Windows era veramente molto vecchio: hanno fatto bene ad averlo rimosso. Fermo restando che, a mio avviso, un s.o. che non è di derivazione Unix, era meglio che tenesse fede soltanto alla sua filosofia e quindi includesse soltanto il sottosistema Win32.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.