Mi spiegate il funzionamento di SysWOW64 per i drivers di connessione ...

lunedì 10 febbraio 2014 - 18.05

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

ravalon Profilo | Expert

689 messaggi | Data Invio: lun 10 feb 2014 - 18:05

Salve, ho un gestionale sviluppato con VB.NET express edition su Windows XP, quindi a 32 bit che si interfaccia a 3 database tra cui ACCESS in versione .MDB. tramite OLE DB.

Un cliente mi ha riportato che su Windows 7 64 bit otteneva un errore sul driver di connessione di Access che non risultava registrato sulla macchina.

Girovagando ho letto che non esiste un driver a 64 bit per access e che potevo risolvere compilando il progetto non più come ANY CPU ma mettendo la compilazione per x86.

Cosi ho fatto ed ha funzionato.... ora vorrei capire meglio come ...

Ho letto anche che esiste sui 64 bit un ambiente chiamato SysWOW64 che praticamente emula i processi a 32 bit.

Devo quindi pensare che cambiando compilazione è proprio il SysWOW64 che si incarica di prendere la mia connessione a 32 bit verso access e che la fa funzionare ?

Se è cosi, mi merita abbandonare Access in favore di SQL Server Compact Edition 4 che a quanto vedo ha drivers sia per i 32 bit che per i 64 bit ?

Grazie a tutti.

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: lun 10 feb 2014 - 19:42

>Ho letto anche che esiste sui 64 bit un ambiente chiamato SysWOW64
>che praticamente emula i processi a 32 bit.
>
>Devo quindi pensare che cambiando compilazione è proprio il SysWOW64
>che si incarica di prendere la mia connessione a 32 bit verso
>access e che la fa funzionare ?

si, in pratica quasi tutte le applicazioni/librerie compilate a 32bit per windows, possono funzionare su sistemi a 64bit, attraverso questo emulatore a 32 bit chiamato appunto WoW64 (Windows 32bit on windows 64bit), che converte istruzioni e cambia i flussi di esecuzione dei compilati a 32bit per funzionare anche su sistemi a 64bit. Il problema appunto è che se la tua applicazione .net viene compilata in Any, in base all'ambiente in cui gira 32 o 64 bit, viene eseguito possibilmente con l'architettura nativa del sistema, quindi se sta girando su un 64bit, anche la nostra applicazione girerà a 64bit, questo però comporta il fatto che non stia girando nel sotto sistema WoW64 e di conseguenza non può caricare nessuna libreria compilata a 32bit. Allora in quali casi può servire settare l'Any? Semplice,, quando si hanno a disposizione entrambe le librerie, sia a 32bit che a 64bit, altrimenti sei davvero costretto a compilare la tua applicazione solo a 32bit e farla girare sotto WoW64, infatti vedrai nel task manager di windows, che al nome del tuo eseguibile seguirà un *32

>
>Se è cosi, mi merita abbandonare Access in favore di SQL Server
>Compact Edition 4 che a quanto vedo ha drivers sia per i 32 bit
>che per i 64 bit ?

sicuramente merita, e non solo per l'aspetto 32-64bit

>
>Grazie a tutti.

di niente

Ciao,
Michael Denny
Software Developer & Architect
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
Twitter: @dennymic

ravalon Profilo | Expert

689 messaggi | Data Invio: lun 10 feb 2014 - 19:55

Sei stato chiarissimo e gentilissimo...

un'ultima precisazione o due...

Se mantengo Access e voglio che funzioni anche sui 64 bit quindi devo continuare a compilare per x86 per forza giusto ?

E se invece usassi MySQL, PostgreSQL e SQL server CE, tutti forniti di librerie di connessione sia per 32 che per 64 bit e li fornissi insieme al setup , mi conviene quindi tornare a compilare su ANY CPU giusto ?
Cioè, questo WOW64 rallenta le prestazioni quando in azione o non c'è differenza ?

In sostanza, il problema è solo per Access in quanto non esistono librerie di connessione a 64 bit ? Se è cosi, come mai a questa pagina viene fornito il motore per Access sia per i 32 che per i 64 bit ?

http://www.microsoft.com/en-us/download/details.aspx?id=13255

Altra cosa... e poi finisco , giuro...

Se a corredo del mio software ho altri pacchetti esterni che lavorano solo a 32 bit (Report Manager), compilando per ANY CPU impedisco anche a questi componenti di funzionare oppure anche in tal caso si mette all'opera il sysWOW64 ? Cioè...questo sysWOW64 funziona per QUALUNQUE applicazione 32 bit che gira su un 64 bit oppure vale solo per i driver di connessione ai database ?

ravalon Profilo | Expert

689 messaggi | Data Invio: mar 11 feb 2014 - 15:18

Aspetto con ansia la tua gentile risposta dato che credo tu sia in grado di risolvere tutti i miei dubbi...

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: mar 11 feb 2014 - 18:42

>Sei stato chiarissimo e gentilissimo...

Avevo pronta una bel risposta che è morta insieme al seabone di Milano che ha paralizzato la connessione di mezza Italia o più :( provo a riscrivere i concetti dal melafonino :)

>
>un'ultima precisazione o due...
>
>Se mantengo Access e voglio che funzioni anche sui 64 bit quindi
>devo continuare a compilare per x86 per forza giusto ?

Dipende dal driver che utilizzi che è strettamente collegato alla versione dei file Office che devi leggere, infatti da Office 2007 è stato introdotta una nuova famiglia di driver chiamati ACE in origine e poi convertiti in access database engine e viene automaticamente installato con Office oppure puoi scaricare la versione redistribuibile (cerca su google access database engine redistributable), questa libreria ad esempio è fornita anche per sistemi a 64bit. Quindi se devi usare jet o cmq un driver che è disponibile solo a 32bit, si, sei costretto a compilare a 32bit, cosa che può essere completamente indolore per te, l'unico grosso problema è la memoria, se il tuo software deve allocare più di 2 GB di memoria compilare a 32bit è facile che ti dia problemi.

>
>E se invece usassi MySQL, PostgreSQL e SQL server CE, tutti forniti
>di librerie di connessione sia per 32 che per 64 bit e li fornissi
>insieme al setup , mi conviene quindi tornare a compilare su
>ANY CPU giusto ?

Eh questo argomento ha portato a innumerevoli diverse interpretazioni, se cerchi in google any cpu vs x86 vedrai un sacco di pareri discordanti tra loro. In generale io non sono mai riuscito a vedere particolari differenze, se non come dicevo prima per i limiti fisici del 32bit come l'indirizzamento della memoria, io generalmente compilo in any cpu, l'ho fatto dalla versione 1.1 e non ho mai cambiato :) se non per progetti, come nel tuo caso, legati a dll 32bit.

Io personalmente tornerei a any cpu, il framework esiste anche per non preoccuparsi di queste cose, si sono sbattuti tanto per fare un CLR che non dipende da codice specifico e che può essere facilmente interpretabile per generare istruzioni macchina per diverse piattaforme, io vedo la possibilità di scegliere il target framework solo per esigenze simili a quelle che hai tu, per tutto il resto c'è any cpu :)

>Cioè, questo WOW64 rallenta le prestazioni quando in azione o
>non c'è differenza ?

Per il codice managed non dovrebbe cambiare quasi niente e di fatto ricordo che un modo per ovviare alle limitazioni della memoria per compilati a 32bit era fare una sorta di buffering in .net in modo da non sovraccaricare di memoria la dll 32bit e di tenere i dati sul framework in questo modo .net pure girando sotto wow64 sa benissimo di essere su un sistema a 64bit con più memoria e incomincia ad usarla anche oltre i 2GB purché i dati provengano da tipi .net... Insomma qualcosa del genere non ricordo ma dovresti trovare qualcosa in merito in rete.

>
>In sostanza, il problema è solo per Access in quanto non esistono
>librerie di connessione a 64 bit ? Se è cosi, come mai a questa
>pagina viene fornito il motore per Access sia per i 32 che per
>i 64 bit ?
>
>
>http://www.microsoft.com/en-us/download/details.aspx?id=13255
>

Ecco sono arrivato ora a leggere qui, e ti rimando alla risposta che ti ho dato appena sopra :)

>Altra cosa... e poi finisco , giuro...
>
>Se a corredo del mio software ho altri pacchetti esterni che
>lavorano solo a 32 bit (Report Manager), compilando per ANY CPU
>impedisco anche a questi componenti di funzionare oppure anche
>in tal caso si mette all'opera il sysWOW64 ? Cioè...questo sysWOW64
>funziona per QUALUNQUE applicazione 32 bit che gira su un 64
>bit oppure vale solo per i driver di connessione ai database
>?

Wow64 server per qualunque applicazione 32bit (so che ci sono delle limitazioni ma non le ho mai viste, trovi su msdn i dettagli, ma generalmente va tutto), quindi se hai altre dll che non puoi avere anche a 64bit non puoi compilare in any cpu, ma in 32bit, stessa cosa viceversa, se avessi delle librerie (parlo sempre di dll UNmanaged) a 64bit ma non a 32bit, dovresti compilare solo a 64bit. Tra l'altro in genere anche se hai a disposizione entrambe le librerie dovresti fare 2 pacchetti di installazione, uno per 32bjt e l'altro per 64bit, anche se ricordo di avere visto applicazioni compilate in any cpu e forse esiste un qualche trick per selezionare la libreria corretta mettendo nella bin una cartella x86 e un altro x64.

Michael Denny
Software Developer & Architect
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
Twitter: @dennymic

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: mar 11 feb 2014 - 19:10

qua trovi un po' di considerazioni, ma fai attenzione a leggere anche i commenti delle persone che non sono per niente da sotto valutare:

http://blogs.msdn.com/b/rmbyers/archive/2009/06/09/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx

quindi sostanzialmente ritorno a pensare che sinceramente non deve essere un problema nostro, io compilo in any cpu perchè microsoft ha fatto un bel lavoro con il framework, rendendolo platform indipendent, e ora ci devono anche dare supporto :) poi quello che dice Rick che generalmente un applicazione gira più veloce a 32bit, eh cosa devo pensare io, male, molto male :) perchè guardando la storia, dove le piattaforme a 16bit sono completamente morte e sostituite da piattaforme a 32bit, se tanto mi da tanto, succederà anche con i 32bit, e quindi le applicazioni tenderanno ad essere solo a 64bit e quindi a girare più lente? vabbe ne dubito, o almeno non sensibilmente dai vantaggi che da. L'unico modo è fare dei load test sulla propria applicazione e vedere se ci sono significative differenze tra eseguire l'applicazione in any cpu o x86 o x64, sinceramente non mi sono focalizzato mai su questi problemi, un software generalmente inizia a dare problemi di performance molto prima per colpa di hardware insufficiente o di noi sviluppatori, prima di pensare che sia legato al target platform a cui ho compilato il codice

come lettura spassionata, leggi anche questo articolo, perchè da vs2012 hanno introdotto il "prefer 32 bit" per le piattaforme ARM:

http://dotnet.dzone.com/articles/what-anycpu-really-means-net

Michael Denny
Software Developer & Architect
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
Twitter: @dennymic

ravalon Profilo | Expert

689 messaggi | Data Invio: mar 11 feb 2014 - 19:19

Intanto ti ringrazio infinitamente!

Secondariamente, sto compilando in x86 perchè tra i 3 database che supporto c'è ACCESS con file MDB che quindi (confermami sta cosa) a quanto ne so usa JET engine che non esiste per 64 bit....giusto ?

Per ora ho risolto cosi ma sto progettando di lasciare ACCESS per SQL Server CE come ti dicevo; se riesco a farlo, dopo non avrò più questo limite in quanto tutti i DB supportati hanno drivers di connessione per 32 e 64 bit...
...quindi io potrei fornire tutti i pacchetti di drivers nel setup, l'utente sceglie durante l'installazione quello giusto in base al sistema che usa, ed io torno a compilare per ANY CPU....

...è giusto il mio ragionamento ? Può funzionare come soluzione ? Dimmi di si sennò mi sparo sedutastante !!

Se è giusto, la discussione la finiamo qui, ho già abusato della tua pazienza... ma ne aprirò un'altra perchè a quel punto devo trovare un modo per far leggere i database a Report Manager tramite dot net provider e non più tramite ODBC o OLEDB perchè altrimenti sono comunque bloccato sempre da un problema di drivers di connessione...

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: mar 11 feb 2014 - 19:42

>Intanto ti ringrazio infinitamente!
>
>Secondariamente, sto compilando in x86 perchè tra i 3 database
>che supporto c'è ACCESS con file MDB che quindi (confermami sta
>cosa) a quanto ne so usa JET engine che non esiste per 64 bit....giusto
>?

sinceramente sono un po' a digiuno di access e non l'ho più utilizzato da almeno 8 anni, e quindi non vorrei dirti castronerie, ma sicuramente Jet è stato abbandonato a favore di Ace (questo perchè l'ho letto dalla wiki

), però ad esempio googlando ho tovato questo driver

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=20065

e comunque anche chi usa ace (aka access database engine) anche per aprire mdb http://stackoverflow.com/a/7223713/1082342

forse il modo migliore e fare una piccola console application di test e fare qualche prova a collegarti al tuo mdb con ace o con l'altro driver che ti ho passato, perchè non credo sia legato solo all'estensione, ma piuttosto alla versione del file, cioè se è stato creato da una versione office 2007 in poi, è facile che possa funzionare anche con il driver ace.

>
>Per ora ho risolto cosi ma sto progettando di lasciare ACCESS
>per SQL Server CE come ti dicevo; se riesco a farlo, dopo non
>avrò più questo limite in quanto tutti i DB supportati hanno
>drivers di connessione per 32 e 64 bit...
>...quindi io potrei fornire tutti i pacchetti di drivers nel
>setup, l'utente sceglie durante l'installazione quello giusto
>in base al sistema che usa, ed io torno a compilare per ANY CPU....
>
>...è giusto il mio ragionamento ? Può funzionare come soluzione
>? Dimmi di si sennò mi sparo sedutastante !!

intanto bisogna distinguere quelle che sono le dll managed da quello unmanaged, cioè se sono compilate per .net/clr (c#, vb.net, ...) oppure native (c++ e compari)... perchè ad esempio se passi a sql server ce, hai delle librerie .net native a loro volta compilate in any cpu, quindi non ti devi preoccupare minimamente del discorso piattaforma, fai un setup sia per 32bit che 64bit, questo è la potenza che .net ti da se scrivi tutto codice .net

Se invece hai anche librerie unmanaged, cioè quelle compilate in codice macchina, come ad esempio jet, ace, e altre dll derivanti da compilazioni di codice c++, vb6, ecc... e quindi il tuo software è ibrido tra codice .net e codice nativo, la soluzione certa che conosco è quella di creare due setup differenti, un setup per sistemi a 32bit e uno per i 64bit, come del resto succede per tanti tanti software.

In questi casi la magia, sta nel cercare di utilizzare solo librerie managed, così da potersi dimenticare del problema cross-platform e avere solo un setup.

>
>Se è giusto, la discussione la finiamo qui, ho già abusato della
>tua pazienza... ma ne aprirò un'altra perchè a quel punto devo
>trovare un modo per far leggere i database a Report Manager tramite
>dot net provider e non più tramite ODBC o OLEDB perchè altrimenti
>sono comunque bloccato sempre da un problema di drivers di connessione...

questo report manager? http://reportman.sourceforge.net/

perchè ho visto che ha la libreria .net: http://reportman.sourceforge.net/docnet/index.html

se così fosse, e riesci a portare tutto il codice a managed (compreso librerie esterne managed), fai un setup in any cpu, e non ci pensi più!

Michael Denny
Software Developer & Architect
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
Twitter: @dennymic

ravalon Profilo | Expert

689 messaggi | Data Invio: mar 11 feb 2014 - 20:04

confermo che il mio db access è creato sfruttando il Jet engine che è deprecato

...confermo che ho codice misto...
io scrivo in .NET e basta ma ho il Report Manager (si , quello che hai indicato tu) che è compilato con Delphi credo... quello lo lascio installare all'utente, insieme ai drivers ODBC per PostgreSQL (gli unici supportati dai creatori), anch'essi scritti non so come... e i drivers ODBC per MySQL (qui mi fermo perchè entrerei nell'altro argomento per il quale aprirò un post, sperando che qualcuno mi risponda)...

...ma a parte ReportManager, trovo comunque gli installanti .MSI per 32 e 64, quindi basta che li faccio installare all'utente.

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: mar 11 feb 2014 - 20:19

un altro interessante post di hanselman:

http://www.hanselman.com/blog/BackToBasics32bitAnd64bitConfusionAroundX86AndX64AndTheNETFrameworkAndCLR.aspx

riguardo a questa mia affermazione "ricordo di avere visto applicazioni compilate in any cpu e forse esiste un qualche trick per selezionare la libreria corretta mettendo nella bin una cartella x86 e un altro x64.", ho trovato dei riferimenti interessanti che pare confermino il mio ricordo:

http://scottbilas.com/blog/automatically-choose-32-or-64-bit-mixed-mode-dlls/ attenzione che dice di leggere il commento ([Update: Stefan posted in a comment below a much simpler method. I recommend going with this instead of my considerably more complex method.])

http://stackoverflow.com/a/156024/1082342

non so se funziona anche per dll unmanaged puntando alle dll proxy (interop) della piattaforma corretta, se ti interessa potresti approfondire la cosa, diciamo che ti ho dato un punto da dove partirei anche io.

Michael Denny
Software Developer & Architect
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
Twitter: @dennymic

ravalon Profilo | Expert

689 messaggi | Data Invio: mar 11 feb 2014 - 20:29

Grazie di nuovo, spero di vederti rispondere anche alla prossima mia richiesta di chiarimenti perchè sei stato professionalissimo!

....forse sono io che su certe cose sono rimasto indietro...

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: mer 12 feb 2014 - 11:21

di niente, alla prossima

ciao,
Michael Denny
Software Developer & Architect
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
Twitter: @dennymic

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !