portare aplicatie VC++ de la 32 la 64 de biti

[Marius Bancila]

Ati lucrat careva la portarea unor aplicatii VC++ medii sau mari de pe 32 la 64 de biti? Daca da, ati putea impartasii din experienta, care au fost problemele majore sau cel mai des intalnite? Intreb pentru ca urmeaza sa lucrez la portarea unei astfel de aplicatii si as aprecia informatii pe aceasta tema (venite din experienta, ca de citit am tot citit).

Mersi

[Ovidiu Cucu]

De portare nu m-am ocupat pana acum dar am avut de-a face cu solutii gata facute pentru Win23 si x64.
O problema am avut-o si am pierdut ceva timp din cauza ei, in momentul in care am vrut sa fac build din linie de comanda (devenv.exe... ).
Recomandare: pune cele doua configuratii (pt Win23 si x64) in solutii (sln-uri) diferite.

[Ovidiu Cucu]

Alta problema.
Daca pui in kit un DLL care sa fie folosit de "Custom Actions" ala trebuie sa fie build-uit tot pe Win32 si pentru setup-ul de x64.

[cristianamarie]

Ati lucrat careva la portarea unor aplicatii VC++ medii sau mari de pe 32 la 64 de biti? Daca da, ati putea impartasii din experienta, care au fost problemele majore sau cel mai des intalnite? Intreb pentru ca urmeaza sa lucrez la portarea unei astfel de aplicatii si as aprecia informatii pe aceasta tema (venite din experienta, ca de citit am tot citit).

Mersi

Am lucrat pe treburi din astea, din experienta mea (si ce imi vine in cap acum):
1. DWORD vs DWORD_PTR, ULONG v ULONG_PTR. Mai exact, variable sau casts care erau relativ ok pe x86 (unde xx == xx_PTR), dar pe x64 nu mai sint la fel.
2. sizeof issues: FuncCall( dwordptrVal, sizeof(DWORD) ...) in loc de sizeof(dwordptr). Tot ce e sizeof e * 2 pe x64 intre xx si xx_PTR.
Astea sint cele mai multe.

3. Registry. Real pain in the ass - SysWOW64. Flagii KEY_WOW64_32KEY si KEY_WOW64_64KEY isi fac treaba. Daca sint folositi...
4. File system (a se vedea GetSystemWow64Directory).
Astea sint cele mai suparatoare.

5. Setup. Aici treaba devine enervanta, dar mai mult din cauza limitarilor si timpeniilor (as zice) din mecanismele lor. Cea mai mare parte tot la registry se rezuma, sau la localizarea de cai. Daca ai de facut un setup mix x86/x64, fa doua, unul x86, unul x64, baga-le ca resurse custom in .rc si lanseaza-le separat.
Runtime-ul de VS 2008 etc. si foarte diversele packages, product keys etc. te pot seca.
Blog-ul lui Aaron Stebner
http://blogs.msdn.com/b/astebner/
e locul pentru ze reference in ceea ce priveste intrarea in cacao.

[Silviu Ardelean]

Tot la capitolul "take care" trebuie avut in vedere cand vrei sa obti paths ce difera intre versiunile de OS (gen "Program Files" respectiv "Program Files (x86)") prin SHGetSpecialFolderPath() and staff.

Recomandare: pune cele doua configuratii (pt Win23 si x64) in solutii (sln-uri) diferite.

Care ar fi motivele pentru cele doua versiuni de soluti?
Noi avem una singura pentru ambele solutii si nu e nici o problema.

[Marius Bancila]

Ati folosit ceva tooluri de analiza statica pentru posibile probleme? Am gasit unul VIVA64, care arata destul de interesant. Am incercat versiunea trial si imi da mii de warninguri (bine, unele sunt complet nerelevante), dar oricum, idea de a lua la mana codul (din mii de fisiere) mi se pare de speriat. Un tool de analiza ar trebui sa fie un punct de plecare.

[Silviu Ardelean]

Marius, cred ca analiza statica de cod ar fi ultimul lucru la care trebuie sa te opresti. Important e sa te asiguri ca aplicatia ta merge la fel de bine ca pana acum pe win32 dar si pe un sistem de x64, in urma a doua build-uri specifice platformei.
De exemplu, cred ca aplicatia ta pe x64 de biti e de asteptat sa se instaleze si sa ruleze perfect din "\Program Files\" nu "\Program Files (x86)". La registrii, cum zicea si Cristi, de asemenea, e ceva distractie.

Revenind la analiza statica, la fostul job, imi aduc aminte ca impreuna cu un coleg am facut timp de 2 saptamani numai analiza statica cu PCLint pe un proiect cu cateva zeci de clase... maxim 10-15 mii de linii de cod. Dupa parerea mea, analiza statica nu te ajuta prea mult la portare platforma x64. Te ajuta sa scrii cod mai corect... si sa nu faci magari de genul: sa nu faci mai multe return-uri intr-o functie, sa pasezi parametri cu const by reference, sa nu arunci exceptii prin destructori si alte gogolaneli ce le-am vazut prin acel proiect preluat...

[Marius Bancila]

Silviu, te inseli. Analiza statica e foarte buna. Faptul ca multe din warninguri sunt false positives asta nu inseamna ca analiza nu ajuta. N-am cum sa iau la mana 5000 de fisiere si 2 milioane de linii de cod ca sa vad unde se fac conversi gresit, unde sunt operatii pe bit gresite, unde se folosesc numere magice care nu mai pusca pe 64 de biti, etc. etc. tot felul de probleme pentru x64. E mult pana sa ajung sa instalez programul si sa ajung sa vad ca merge OK. Pana atunci trebuie sa rezolv Nspe situatii care sigur nu merg. Installerul e una din ultimele probleme la care o sa ajung sa lucrez (ma rog, nu eu, ci un coleg); pana atunci e de munca.

[Silviu Ardelean]

Nu am spus ca nu e buna. Spun ca analiza statica e mai mult "bad practice code remover". Si daca nu iei la mana acele fisiere la ce te ajuta analiza statica? Daca ai lua la mana 2 milioane de linii termini in cativa ani.
Portarea de la win32 la x64 nu e un capat de tara daca tu ai codul deja scris pe win32. Trebuie multa rabdare, testare si perseverenta.
Trebuie sa ti cont de particularitatile ce apar pe x64 si in astfel de situatie sa ai sectiuni de cod incadrate intr-un #ifdef _WIN64 si sa le tratezi corespunzator pe ramura de true(fie declaratii de variabile, obiecte, sau cod mai complex), respectiv pe cea de else ptr. win32.

[cristianamarie]

Silviu, te inseli. Analiza statica e foarte buna. Faptul ca multe din warninguri sunt false positives asta nu inseamna ca analiza nu ajuta. N-am cum sa iau la mana 5000 de fisiere si 2 milioane de linii de cod ca sa vad unde se fac conversi gresit, unde sunt operatii pe bit gresite, unde se folosesc numere magice care nu mai pusca pe 64 de biti, etc. etc. tot felul de probleme pentru x64. E mult pana sa ajung sa instalez programul si sa ajung sa vad ca merge OK. Pana atunci trebuie sa rezolv Nspe situatii care sigur nu merg. Installerul e una din ultimele probleme la care o sa ajung sa lucrez (ma rog, nu eu, ci un coleg); pana atunci e de munca.

Cea mai buna analiza e compilarea cu /W4. Sar ca cosasii... asta scoate la iveala cam 85% din prostiile gen DWORD/DWORD_PTR, sizeof si altele asemenea.
Ramin din cele 50.000 de warnings sub 1500, cea mai mare parte si din alea o sa fie rezolvabile de UNREFERENCED_PARAMETER si ramin cele cu adevarat groase, hai sa zicem la 500. Din astea, 350 n-au de-a face cu x64 ci sint de-alde STL, iteratori modificati in bucle etc. (ca sa dau un exemplu) si poate ramin cele 150 care sint intr-adevar scularea din morti.

Asta presupunind ca nu ploua cu RegOpenKeyEx prin tot locul. De obicei inlocuirea cu clase proprii sau cu ATL::CRegKey daca se poate rezolva.

Analiza statica reala cred ca trebuie sa fie pasul de *dupa* astea de mai sus pe care eu le trec la categoria bun-simt.
De aici incolo ce zic treburi de-alde lint sau alte tools nu stiu cit mai au de-a face cu x64 cit cu bad practices.

[viorel2005]

Salut!

Eu recomand articolele de pe codeproject in privinta portarii aplicatiilor pe 64 bit.
Un articol bun este urmatorul:
http://www.codeproject.com/KB/architect ... 64BIT.aspx
In alta ordine de idei ar fi interesant daca ai putea da niste detalii despre specificul aplicatiei:codare video,prelucrari de imagini etc.
Poate o solutie mai buna ar fi o combinatie Win64+GPU(OpenCL).Pe Win64 poti aloca mai multa memorie.Dar, totusi cu cat registrul are dimensiunea
mai mica cu atat este mai rapid. Practic, pe WIn64 ai mai multi registrii, dar totusi conteaza si cum e codata aplicatia.Nu cred ca o simpla portare
va duce la un castig de performanta.In acest benchmark, de la adresa:http://www.tomshardware.co.uk/xeon-x568 ... 956-8.html
se vede clar ca pentru Xvid mai multe procesoare+ HT nu il ajuta. In schim aplicatia Vue 8 PLE scaleaza foarte bine(http://www.tomshardware.co.uk/xeon-x568 ... 956-9.html).
Cred ca o solutie ar fi recodarea aplicatiei si nu traducerera ei. E posibil ca folosirea unor tehnologii noi sa fie mai avantajoasa si sa reduca numarul de linii de cod.(Exemplu OpenMP vs crearea firelor de executie in Win32
si sincronizarea lor).

[Marius Bancila]

viorel, aplicatia mea e un sistem ERP. Articolul pe care mi l-ai dat nu e decat o copie a celor de aici http://www.viva64.com/developers-resources/ (in speta acesta http://www.viva64.com/content/articles/ ... evelopment). Le-am citit deja cam pe toate.

cristi, sigur, sunt de acord tu tine, prima data trebuie sa rezolv problemele indicate de compilator. In ce priveste /W4 asta folosim de mult. Atat doar ca nu tratam warningurile ca si erori.

[Silviu Ardelean]

Articolul e copie pentru ca autorul articolului chiar se pare ca a lucrat la http://www.viva64.com.

[Marius Bancila]

Andrey Karpov si Evgeniy Ryzhkov sunt cei doi autori ai VIVA64. "Copii" ale acestor articole sunt publicate pe mai multe site-uri, nu doar codeproject.

[Silviu Ardelean]

Poate ca oameni au facut acest lucru pentru a-si face reclama la tool-ul lor. Pana la urma, cred ca au mers la tinta.