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.
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.
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.