Conversione del codice C di Win16 in Win32

Question

In generale, cosa bisogna fare per convertire un programma Windows a 16 bit in Win32? Sono sicuro di non essere l'unica persona a ereditare una base di codice e rimanere sbalordito nel trovare il codice a 16 bit in agguato negli angoli.

Il codice in questione è C.

Answer 1

1. I significati di wParam e lParam sono cambiati in molti luoghi. vivamente ti incoraggio a essere paranoico e a convertirti il ??più possibile per utilizzare cracker di messaggi . Ti risparmieranno la fine del mal di testa. Se c'è solo un consiglio che posso darti, questo sarebbe.
2. Finché stai usando i cracker di messaggi, abilita anche STRICT . Ti aiuterà a catturare la base di codice Win16 usando int dove dovrebbe usare HWND , HANDLE o qualcos'altro. La conversione di questi sarà di grande aiuto con # 9 in questo elenco.
3. hPrevInstance è inutile. Assicurati che non sia usato.
4. Assicurati di utilizzare chiamate compatibili con Unicode. Ciò non significa che è necessario convertire tutto in TCHAR , ma significa che è meglio sostituire OpenFile , _lopen e _lcreat con CreateFile , per nominare l'ovvio
5. LibMain è ora DllMain e l'intero formato della libreria e le convenzioni di esportazione sono diversi
6. Win16 non aveva VMM. GlobalAlloc , LocalAlloc , GlobalFree e LocalFree devono essere sostituiti con equivalenti più moderni. Al termine, ripulire le chiamate a LocalLock , LocalUnlock e agli amici; ora sono inutili. Non che io possa immaginare che la tua app stia facendo questo, ma assicurati di non dipendere da WM_COMPACTING mentre sei lì.
7. Anche Win16 non aveva protezione della memoria. Assicurati di non utilizzare SendMessage o PostMessage per inviare puntatori a finestre fuori processo. Dovrai passare a un meccanismo IPC più moderno, come pipe o file mappati in memoria.
8. Win16 mancava anche del multitasking preventivo. Se volevi una risposta rapida da un'altra finestra, è stato assolutamente bello chiamare SendMessage e attendere l'elaborazione del messaggio. Potrebbe essere una cattiva idea adesso. Valuta se PostMessage non è un'opzione migliore.
9. Le dimensioni del puntatore e dell'intero cambiano. Ricorda di controllare attentamente ovunque tu stia leggendo o scrivendo dati su disco, specialmente se sono strutture Win16. Dovrai rifarli manualmente per gestire i valori più brevi. Ancora una volta, il modo meno doloroso per affrontare questo sarà quello di utilizzare i cracker dei messaggi ove possibile. Altrimenti, dovrai cercare manualmente e convertire int in DWORD e così via dove applicabile.
10. Infine, quando hai risolto l'ovvio, considera di abilitare i controlli di compilazione a 64 bit. Molti dei problemi affrontati passando da 16 a 32 bit sono gli stessi che vanno da 32 a 64 e Visual C ++ è in realtà piuttosto intelligente in questi giorni. Non solo affronterai alcuni problemi persistenti; ti preparerai anche per la tua eventuale migrazione su Win64.

---

MODIFICA : come sottolinea @ChrisN, la guida ufficiale per il porting di app Win16 su Win32 è ancora disponibile ed entrambe si sviluppano e si aggiungono ai miei punti sopra.

Answer 2

Oltre a correggere l'ambiente di compilazione, qui ci sono alcune specifiche da affrontare:

1. Le strutture contenenti ints dovranno cambiare in breve o ampliare da 16 a 32 bit. Se si modifica la dimensione della struttura e questa viene caricata / salvata su disco, sarà necessario scrivere il codice di aggiornamento del file di dati.

2. I dati per finestra vengono spesso archiviati con l'handle della finestra utilizzando GWL_USERDATA. Se allarghi alcuni dei dati a 32 bit, i tuoi offset cambieranno.

3. POINT & amp; Le strutture SIZE sono 64 bit in Win32. In Win16 erano a 32 bit e potevano essere restituiti come DWORD (il chiamante avrebbe diviso il valore di ritorno in due valori a 16 bit). Questo non funziona più in Win32 (ovvero Win32 non restituisce risultati a 64 bit) e le funzioni sono state modificate per accettare un puntatore per memorizzare i valori restituiti. Dovrai modificare tutti questi. Le API come GetTextExtent sono interessate da questo. Lo stesso problema si applica anche ad alcuni messaggi di Windows.

4. L'uso di file INI è sconsigliato in Win32 a favore del registro. Mentre le funzioni del file INI funzionano ancora, dovrai fare attenzione ai problemi di Vista. I programmi a 16 bit spesso archiviano il loro file INI nella directory di sistema di Windows.

Questi sono solo alcuni dei problemi che posso ricordare. È passato più di un decennio da quando ho effettuato il porting di Win32. Una volta entrato, è abbastanza veloce. Ogni base di codice avrà il proprio "sentire" quando si tratta di porting a cui ti abituerai. Probabilmente troverai anche alcuni bug lungo la strada.

Answer 3

C'è una guida definitiva nell'articolo Porting 16 -Bit Code su Windows a 32 bit su MSDN.

Answer 4

L'originale win32 sdk aveva uno strumento che scansionava il codice sorgente e contrassegnava le linee che dovevano essere cambiate, ma non ricordo il nome dello strumento.

Quando ho dovuto farlo in passato, ho usato una tecnica di forza bruta, ad es .: 1 - aggiorna i makefile o crea l'ambiente per utilizzare compilatore e linker a 32 bit. Facoltativamente, basta creare un nuovo progetto nel tuo IDE (io uso Visual Studio) e aggiungere i file manualmente.

2 - build

3 - correggi gli errori

4 - ripeti 2 & 3 fino al termine

Il dolore del processo dipende dall'applicazione che si sta migrando. Ho convertito 10.000 programmi di linea in un'ora e 75.000 programmi di linea in meno di una settimana. Ho anche avuto alcune piccole utility a cui ho appena rinunciato e riscritto (principalmente) da zero.

Answer 5

Sono d'accordo con Alan sul fatto che tentativi ed errori siano probabilmente il modo migliore.

Ecco alcuni buoni suggerimenti .

Answer 6

Convenuto che il compilatore probabilmente rileverà la maggior parte degli errori. Inoltre, se stai utilizzando " vicino a " e "lontano" puntatori è possibile rimuovere quelle designazioni: un puntatore è solo un puntatore in Win32.