64-bit aplikace

[Fala]

Projekty, které jsou náročné na paměť určitě využijí 64-bitovou kompilaci, ale co běžné aplikace, má to smysl?

[< z >]

jestli to ma nebo nema smysl, nejde asi posoudit,
jestli to je potreba - pokud nekdo nezasahuje do systemu nebo nejakych specialnich registru, tak to potreba neni

[pepak]

Mám o tom vážné pochybnosti.

[Radek Červinka]

Jako vetsinou to nevyuzijes, pokud tedy nepises:
- rozšireni pro nejaky 64bit program jako Outlook, IE a další (nebo DLL pro 64bit programy)
- něco co se integruje do shell v 64bit (dá se obejít)
- nemapuješ soubory vetší než 4GB, resp. nepracuješ s tak velkými daty (dá se obejít, ale takto je to mnohem efektivnější)
- nemáš do jako marketingový nástroj
a pár dalších věcí

[Vrtule]

Problém nastává asi hlavně v případě psaní systémových utilit. Jinak je snad výhodou pouze větší paměťový prostor a menší režie systémových volání (nejde se přes WOW64 obal).

Problémy mohou nastat např. pokud používáte Windows Hooks (funkce SetWindowsHookEx). 32bitové DLL knihovny totiž nemohou být vloženy do 64bitových procesů a naopak. Teď nevím, jestli toto omezení platí i pro WH_XXX_LL hooky, kde k DLL injection nedochází.

Pak můžete mít problém, pokud vaše utilita potřebuje měnit pameť cizích procesů. Na to myslím neexistuje ani žádná nedokumentovaná funkce (na čtení paměti myslím ntdll.dll exportuje fci NtWow64ReadVirtualMemory). Dále může nastat problém, pokud vaše aplikace komunikuje s komponentou, která posílá datové struktury, jejichž velikost závisí na tom, zda je systém 32bitový či 64bitový. Samozřejmě, tohle jde vyřešit, stačí trocha kódování.

Většina těchto problémů nastává dosti okrajově, řekl bych. A vláště pokud Delphi bereme jako nástroj pro tvorbu databázových aplikací. Víc problémů mě aktuálně nenapadá.

[sedrik]

- něco co se integruje do shell v 64bit (dá se obejít)

Jenže se zdá, že pro spoustu 32-bit programů je to nepřekročitelný problém. Znám spoustu programů, který se na Windows x64 prostě v kontextovym menu (souboru/složky...) neobjeví, i když s tim dle dokumentace (nebo i diskuzí) nemají mít za všech okolností problém (a to i když jsou jasně a na první pohled správně vidět i v registru v shellex). Docela by mě zajímalo, jak to tedy je (případně, jde-li to nějak obejít i z hlediska uživatele). Navíc se zdá, že ne všem "to nefunguje", ale asi záleží na jakýsi "neznámý" konfiguraci... Nevěděl by někdo? Moc jsem k tomu na netu nenašel...
Díky

[Fala]

tak se čím dál více utvrzuji, že pro běžného uživatele a to i ve firemní síti ty 64-bit aplikace spíš způsobí problémy. aktualizace se musí dělat na pro 32-bit a zvlášť pro 64-bit, dvojí knihovny atd... I pro toho AjŤáka bude jednodušší dát všude 32 bit aplikace, aby si ušetřil bezesné noci.

Nasazení 64-bit aplikace se z mého pohledu nabízí na serverech jako např. Aplikační server.

[Jan Fiala]

Ajtak nemá ani potřebu zavádět 64 bitové operační systémy a následně se prát se starými informačními systémy, které s něčím takovým nepočítají. Docela to pak komplikuje centrální správu.

[.]

Ad sedrik:
No, ono řešení existuje, ale je to jako drbat se levou rukou za pravým uchem (ovšem pochybuju o tom, že "někomu to funguje", protože pokud to daná aplikace nějak neobejde, nemůže to fungovat nikomu, a naopak).
http://social.technet.microsoft.com/Forums/en/w7itproui/thread/e237260d-ca42-4fbc-a657-89796d884715

Neboli, řešení jsou prakticky asi 3:

1. Donutit autora aplikace udělat 64-bit verzi povětšinou DLL knihovny, která dané kontextové menu obstarává.

2. Natvrdo odstřelit 64-bit explorer, a dle návodu spustit 32-bit explorer (průzkumník).
Jinak příkaz: "c:\windows\syswow64\explorer /separate" fungovat nebude, protože sice ve správci úloh na chvíli problikne *32, ale protože už běží *64 verze, *32 je ukončen a spuštěna je najust nová instance *64.

3. Použít aplikaci 3. strany, která menu pro 32-bit zpřístupní (http://www.gasanov.net/WOW64Menu.asp jsem ale netestoval, a doporučoval bych si o ní nejdřív podrobně zjistit informace jak na netu, tak někde v sandboxu, než bych se odhodlal jí použít naostro)