Hallo,
ich entwickle gerade eine Applikation für Windows. Um nun die
Kompatibilität bei 32- und 64-Bit Windows herzustellen, habe ich mir
überlegt, meine Applikation auf einer 32 Bit Umgebung zu entwickeln und
auch dort zu kompilieren/linken.
Der Grundgedanke dabei ist, dass meine Applikation dann ohne
Anpassungen/Änderungen auf beiden Systemen läuft - einmal, da dort
enwickelt (32 Bit) und das andere mal im Kompatibilitätsmodus (auf 64
Bit Systemen).
Stimmt das so? Oder wie muss man das machen?
PS: Im übrigen greife ich auf FTDI-Treiber zurück, die ich auch statisch
dazu linke.
Gruß Gerd
Gerd schrieb:> PS: Im übrigen greife ich auf FTDI-Treiber zurück, die ich auch statisch> dazu linke.Das tust Du ziemlich sicher nicht. Devicetreiber werden sowieso nicht
zum Programm gelinkt, und die üblichen DLLs, die FTDI für seine
Bausteine 'rausrückt, auch nicht; wie auch, wo es doch DLLs sind.
Ansonsten ist Deine Vorgehensweise durchaus brauchbar, solange Deine
Anwendung keine 64-Bit-spezifischen Dinge tun soll, kann sie ruhig eine
32-Bit-Anwendung bleiben.
Allerdings gibt es einige Merkwürdigkeiten, die beim Gebrauch von
32-Bit-Anwendungen unter 64-Bit-Windows auftreten können, dazu gehören
verschiedene von MS vorgenommene Abstraktionen bei Dateisystem- und
Registryzugriffen. Deinem Programm werden Dinge vorgegaukelt, die nicht
unbedingt so sind, wie sie zu sein scheinen.
Christian R. schrieb:> Wieso nicht gleich auf x64 entwickeln und den Compiler auf x86 stellen?> Dann weißt du gleich, ob es im WOW unter x64 auch läuft.
weil das der untypische weg ist. MS hat sich (mehr oder weniger)mühe
gegeben das die x86 Anwendungen auch auf dem 64bit system laufen und
nicht andersrum. Es gibt z.b. Umgebungsvariablen die es nur bei einem
64bit system gibt und nicht auf einem 23bit.
Na das meine ich doch. x64 als Arbeits-OS, und darauf halt native x86
Anwendungen entwickeln. So braucht man keinen zweiten Rechner zum
Testen, ob die native x86 Anwendung auch unter einem x64 Windows
funktioniert.
Erstmal Danke für die Antworten.
Ich entwickle mit wxWidgets/MinGW und habe festgestellt, dass dabei das
32 Bit XP aus der Reihe springt. Was unter Viste/Windows 7 (32 und/oder
64 Bit) funktioniert, muss noch lange nicht auf dem 32er XP laufen.
Dabei handelt es sich vor allem um grafische Dinge. Somit habe ich mich
für 32 Bit XP als Entwicklungsplattform entschieden.
Das mit den Treibern war mir neu. D.h. meine Anwendung läuft erst, wenn
mein USB-Gerät während der ersten Enumeration die FTDI-Treiber
heruntergeladen hat. Aha!
Gruß Gerd
Christian R. schrieb:> Na das meine ich doch. x64 als Arbeits-OS, und darauf halt native x86> Anwendungen entwickeln. So braucht man keinen zweiten Rechner zum> Testen, ob die native x86 Anwendung auch unter einem x64 Windows> funktioniert.
so ebend nicht. weil du dann von einen X64 rechner ausgehst und dieser
z.b. andere Umgebungsvariablen hat als ein x86 rechner.
alles (alles übliches und keine hacks) was auf einen x86 geht geht auch
bei 64bit.
Aber alles was auf x64 geht, geht nicht auf x86. Zum testen muss man eh
beides verwenden wenn man sicher gehen will.
Gerd schrieb:> Das mit den Treibern war mir neu. D.h. meine Anwendung läuft erst, wenn> mein USB-Gerät während der ersten Enumeration die FTDI-Treiber> heruntergeladen hat. Aha!
Ich weiß nicht, was Du damit jetzt beschreiben wolltest.
>Ich weiß nicht, was Du damit jetzt beschreiben wolltest.
Ich gehe davon aus, dass die FTDI-DLLs nicht mit Windows ausgeliefert
werden. Wenn ich jetzt meine Applikation starte, bevor mein USB-Gerät
das erste Mal enumeriert hat (und somit auch die Treiber und DLLs über
Internet geladen wurden), dann müsste doch eigentlich meine Anwendung
mit einer Fehlermeldung abbrechen, da die DLL fehlt! ...es sei denn ich
liefere die mit aus .. soll ich das dann so machen, oder wie?
> ...es sei denn ich liefere die mit aus .. soll ich das dann so machen,> oder wie?
Ich weiss nicht ob die Treiber für die FTDI-Default VID/PID über Windows
Update gezogen werden können, spätestens wenn du an der VID/PID gedreht
hast musst du sie mitliefern (zusammen mit einem angepassten INF-File).
Prinzipiell würde ich (allgemein betrachtet) sowieso eher dazu
tendieren, die Treiber mitzuliefern, da sie dem Stand entsprechen, mit
dem du auch auf dem Entwicklungssystem die Tests durchgeführt hast.
Aus meiner Sicht halt vorteilhaft, weil man bei Problemen etwas besser
eingrenzen kann: Du kannst beim Kunden nachfragen, ob's mit den
Originaltreibern funktioniert hat, wenn er das bestätigt, dann weisst du
dass es am Treiber liegt. Lässt du die jeweils aktuelle Version aus dem
Web ziehen, weisst du nie, ob's am Treiber oder an was ganz anderem
liegt.
Ralf
Gerd schrieb:> dann müsste doch eigentlich meine Anwendung> mit einer Fehlermeldung abbrechen, da die DLL fehlt! ...es sei denn ich> liefere die mit aus .. soll ich das dann so machen, oder wie?
Die ftd2xx.lib dürfte eine "Import Library" sein (Grob gesagt eine *.lib
die quasi keinen echten Code enthält und lediglich ne *.dll lädt und
dafür sorgt das die Funktionsaufrufe auf die Funktionen in der *.dll
gelenkt werden)
Sofern du die ftd2xx.lib eingebunden hast, wird diese glaube ich sofort
bei Programmstart versuchen die ftd2xx.dll zu laden und ggf. ne
Fehlermeldung erzeugen.
Man kann das was die ftd2xx.lib tut notfalls auch per Hand machen
(LoadLibrary(), GetProcAddress())
Ansonsten könnte auch /delayload helfen:
http://msdn.microsoft.com/en-us/library/151kt790.aspx
Dann wird die dll erst versucht zu laden wenn man auf eine Funktion aus
der DLL zugreift. Dann hätte die Möglichkeit vorher zu prüfen ob die dll
existiert.
k.A. ob und wie das bei anderen Compilern einstellbar ist...
Vielleicht darf man die ftd2xx.dll (welche mit dem Treiber kommuniziert)
auch zusammen mit der Anwendung ausliefern, k.A.
Bisher läuft alles über FTDI (VID/PID etc.). Mal sehn was passiert, wenn
ich versuche meine eigenen ID's zu verwenden. Da ich die d2xx-Treiber
nehme, weiss ich garnicht, ob ich da überhaupt ein inf-File brauche.
Jeder Treiber braucht ein Inf-File auch der D2XX. Wenn du das
veränderst, um deine eigene VID oder PID reinzuschreiben, ist die
Signierung hin, und dann lässt sich der Treiber nicht mehr auf Windows
x64 installieren.
>Wenn du das veränderst, um deine eigene VID oder PID reinzuschreiben, ist>die Signierung hin, und dann lässt sich der Treiber nicht mehr auf Windows>x64 installieren.
Kommt da nicht ein Hinweis: 'Vorsicht unbekannter Treiber! Trotzdem
installieren?'
Noch eine Frage: Braucht man für eine 32-Bit-Anwendung im
Kompatibilitäts-Modus unter 64-Bit-Windows die 32 oder 64 Bit Treiber?
Gruß Gerd
Installieren geht, aber beim FTDI Treiber kommt dann Fehler 52 im
Gerätemanager, dass der nicht signierte Treiber nicht geladen werden
kann. Zumindest war das bei der 2.0.0.8 noch so. Sobald man das inf
ändert, muss die WHQL neu gemacht werden.
Und ja, jedes gerät auf einem x64 Windows System benötigt zwingend die
signierten 64 Bit Treiber. Egal, ob die Software 32 Bit oder 64 Bit ist.
Weisst Du zufällig auch, ob man überhaupt irgendwas
Hersteller-spezifisches (String-Deskriptoren?) mit FT_Prog am FTDI-Chip
ändern darf ohne diese WHQL zu verlieren?
