32bit-Anwendung unter 64bit

[stahli]

Wenn man mit D2009-XE eine "einfache" VCL-Formularanwendung erstellt, sollte die ja auch unter 64bit-Windows laufen...

In welchen Fällen kann man denn davon eigentlich NICHT ausgehen?
Wann muss ich also GRUNDSÄTZLICH davon ausgehen, dass meine Annwendung unter 64bit nicht korrekt laufen wird?

[RWarnecke]

Hallo Stahli,

mir ist da keine Variante bekannt, so lange Du nicht versuchst von einem 32Bit Programm auf eine 64 Bit DLL zuzugreifen.

Ich lasse mich natürlich eines besseren belehren.

Gruß
Rolf

[Mithrandir]

Eigentlich gibt es keine Probleme. Interessant wird es nur, wenn man von einer 32bit - Anwendung über MAPI ein 64bit Outlook 2010 ansprechen möchte. Da funktioniert nur die Basis-SendMessage - Funktion. Alles andere geht nicht. Trifft nicht auf Word und Excel zu. Was MS sich dabei gedacht hat - hm....

[jfheins]

Zitat:

Zitat von RWarnecke (Beitrag 1123111)

mir ist da keine Variante bekannt, so lange Du nicht versuchst von einem 32Bit Programm auf eine 64 Bit DLL zuzugreifen.

Oder andersrum. Der Explorer ist bspw. 64 bit, da dürftest du Probleme bekommen eine Shellextension mit Delphi 32 bit zu programmieren.
Vermutlich auch, wenn du beim Programmstart einen 5 GB Speicherblock anforderst.

[mkinzler]

Normalerweise sollte jede Anwendung korrekt funktionieren. Nur Programme/Treiber usw. die im Kernelmode betrieben werden müssen zwingend 64Bit sein.

[sx2008]

Programme mit Datenbankzugriff über ADO laufen nur im Kompatibilitätsmodus.
So zumindest meine Erfahrung mit einer mit D5 kompilierten Anwendung unter Win7/64Bit.

[Cicaro]

Also ich merke, dass meine D7 (32bit) Anwendungen auf meiner neuen 64bit Maschine mit Win 7 nicht über 60 FPS kommen.
Auf meinem alten Win XP Rechner (32bit und 3-5 Jahre alt) habe ich die gleichen Programme auf über 700 FPS gekriegt.

(FPS messen ? Fenster mit OpenGL viewport anlegen + mit Fraps die FPS ablesen.)

[Medium]

Vertical Sync

[Bernhard Geyer]

Zitat:

Zitat von sx2008 (Beitrag 1123126)

Programme mit Datenbankzugriff über ADO laufen nur im Kompatibilitätsmodus.
So zumindest meine Erfahrung mit einer mit D5 kompilierten Anwendung unter Win7/64Bit.

Also unsere D6-Apps mit MS-SQL-Zugriff über ADO (ohne ADOExpress/dbGO) laufen wunderbar.
Auch der Zugriff auf Access geht. Nur Access an sich zerlegt sich immer (Installationsreparatur nötig) da wir noch Apps mit Access-2000-Runtime im Einsatz haben welche eine Installertes Access 2010 beschädigt und umgekehrt..

[himitsu]

Zitat:

Zitat von Cicaro (Beitrag 1127838)

ich die gleichen Programme auf über 700 FPS gekriegt.

Abgesehn davon, daß du soviel eh nicht sehen/wahrnehmen kannst.

Bringt es überhaupt etwas, wenn dein Programm mehr liefert, als Monitor/Grafikkarte darstellen können? (abgesehn von womöglich unnötig verschwendeter Rechenleistung)


PS: Beim Fernsehn hast du nur 50 FPS, bzw ja eigentlich nur 2 * 25 Halbbilder pro Sekunde und es sieht dennoch recht flüssig aus.

[Union]

Ich glaub darum geht es ja nicht ob speziell das sinnvoll ist, sondern dass die Performance eben 10 Mal schlechter ist. Interessant wäre es zu sehen ob der Schwerpunkt auf Rechen- oder Grafikoperationen liegt. Sollte man mal profilen.

[jfheins]

Zitat:

Zitat von Union (Beitrag 1127852)

Ich glaub darum geht es ja nicht ob speziell das sinnvoll ist, sondern dass die Performance eben 10 Mal schlechter ist. Interessant wäre es zu sehen ob der Schwerpunkt auf Rechen- oder Grafikoperationen liegt. Sollte man mal profilen.

Ich denke eher, es geht darum dass bei dem einen Test (warum auch immer) vsync aktiviert war, bei dem anderen nicht. Und nun denken manche Leute die Performance WÄRE 10 mal schlechter, obwohl dem tatsächlich nicht so ist ;-)

[BUG]

Zitat:

Zitat von jfheins (Beitrag 1127866)

Ich denke eher, es geht darum dass bei dem einen Test (warum auch immer) vsync aktiviert war, bei dem anderen nicht.

60 FPS klingen zumindest verdächtig nach 60 Hz :mrgreen:
Im Grafikkartentreiber kann man bei meist VSync für alle OpenGL-Anwendungen erzwingen, vielleicht ist diese Einstellung gesetzt.

[Union]

Zitat:

dass bei dem einen Test (warum auch immer) vsync aktiviert war, bei dem anderen nicht

Ich gehe natürlich davon aus, dass Tests gleich laufen um vergleichbar zu sein.

[Cicaro]

Zitat:

Zitat von himitsu (Beitrag 1127844)

Zitat:

Zitat von Cicaro (Beitrag 1127838)

ich die gleichen Programme auf über 700 FPS gekriegt.

Abgesehn davon, daß du soviel eh nicht sehen/wahrnehmen kannst.

Bringt es überhaupt etwas, wenn dein Programm mehr liefert, als Monitor/Grafikkarte darstellen können? (abgesehn von womöglich unnötig verschwendeter Rechenleistung)

Es geht mehr ums Prinzip. Und bei der Echtzeit-Visualisierung schleichen sich kleine Fehler ein (nicht mehr Flüssig). Ich will da aber nicht ins detail gehen. Mich interessiert nur, warum das nun so zustande kommt.

[himitsu]

Zitat:

Zitat von Cicaro (Beitrag 1127962)

Mich interessiert nur, warum das nun so zustande kommt.

Das wurde doch schon gesagt?

http://de.wikipedia.org/wiki/Vertikale_Synchronisation


Oder dein neuer Rechner ist doch eine lahme Krücke und schafft wirklich nur noch 60 Bilder :roll:




Da dein Programm 700 schaffen würde, aber sowieso nur 60 Bilder angezeigt werden können, ist VSync doch eine gute Sache?
- dein Programm spart über 90% der Rechnenzeit/CPU-Last, da es sich nur noch um 60 Bilder kümmern muß
- und da dein Programm ein bild schneller berechnet, als zur Anzeige nötig wäre, gibt es mit VSync auch nicht die, in Wiki beschrieben Ruckler oder Glitches.

[Cicaro]

Zitat:

Zitat von himitsu (Beitrag 1127965)

Oder dein neuer Rechner ist doch eine lahme Krücke und schafft wirklich nur noch 60 Bilder :roll:

Ne das nicht, weil der in einigen anderen Spielen auch über 3000 FPS geht. Ich habs noch nicht überprüft, aber wenn MEIN Problem durch vsync zustande kommt, dann ist das ein recht dämmliches Feature, weil man bei 64 FPS keine Probleme mit dem Windows Timer/Ticks hat. Bei 60 FPS HAB ich die benannten Ruckler oder Glitches, bei 64 FPS nicht ^^

[jaenicke]

Zitat:

Zitat von Cicaro (Beitrag 1127992)

weil man bei 64 FPS keine Probleme mit dem Windows Timer/Ticks hat. Bei 60 FPS HAB ich die benannten Ruckler oder Glitches, bei 64 FPS nicht ^^

Das liegt aber mit sehr hoher Wahrscheinlichkeit nicht an der Synchronisation, sondern an deinem Code. ;-)

Bei mir ist die Synchronisation aktiviert und es gibt mit keinem Spiel Probleme. Dafür erzeugen die Spiele aber nicht sinnlos hohe Frameraten.

[Luckie]

Hat schon mal jemand versucht eine 32-Bit Shellextension unter 64 Bit zum Laufen zu bringen? Ich hätte da eine Idee für ein Programm. Es muss aber nicht unbedingt über eine DLL laufen.

[mkinzler]

Handelt es ich um eine eigene Dll?

[Luckie]

Ja, wenn dann schreibe ich sie selber mit dem BDS2006.

[jaenicke]

Eine echte Shellerweiterung für 64-Bit Windows muss auch selbst für 64-Bit kompiliert sein, anders geht es nicht.

Ohne 64-Bit (sprich <= Delphi XE) kannst du nur Menübefehle in ein Explorer-Kontextmenü einbringen und damit ein Programm aufrufen, aber nicht mehr.

[Luckie]

Zitat:

Zitat von jaenicke (Beitrag 1167858)

Ohne 64-Bit (sprich <= Delphi XE) kannst du nur Menübefehle in ein Explorer-Kontextmenü einbringen und damit ein Programm aufrufen, aber nicht mehr.

Habe ich mir fast gedacht. Aber eine DLL wäre eventuell auch gar nicht nötig. Ich muss nur die ausgewählte Datei an das Programm übergeben.

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1167858)

Ohne 64-Bit (sprich <= Delphi XE)

XE? Nicht XE2?

64 Bit werden doch erst von letzterem unterstützt?!

[DeddyH]

Korrekt, die 2 ist wahrscheinlich der Schreibfaulheit zum Opfer gefallen :mrgreen:

[jaenicke]

Zitat:

Zitat von Luckie (Beitrag 1167861)

Aber eine DLL wäre eventuell auch gar nicht nötig. Ich muss nur die ausgewählte Datei an das Programm übergeben.

Das kannst du ja einfach als Menüeintrag hinterlegen:
http://www.codeproject.com/Articles/...l-context-menu
(Das ist C#, aber das Vorgehen ist ja das gleiche.)

Zitat:

Zitat von Delphi-Laie (Beitrag 1167867)

Zitat:

Zitat von jaenicke (Beitrag 1167858)

Ohne 64-Bit (sprich <= Delphi XE)

XE? Nicht XE2?

Zitat:

Zitat von DeddyH (Beitrag 1167868)

Korrekt, die 2 ist wahrscheinlich der Schreibfaulheit zum Opfer gefallen :mrgreen:

Muss ich euch echt erklären was das Zeichen "kleiner oder gleich" bedeutet? :zwinker:
64-Bit gibt es ab XE2, dementsprechend gab es das bis einschließlich XE (eben <= XE) nicht. :idea:

[Delphi-Laie]

Der Punkt geht (mal wieder) an Dich, jaenicke. Ich muß gerade geschlafen haben. Mit <= ist es natürlich klar, daß es bis einschließlich XE bei nur 32 Bit blieb. Oder eben: <XE2.