Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <ol> <li>The meanings of <code>wParam</code> and <code>lParam</code> have changed in many places. I <strong>strongly</strong> encourage you to be paranoid and convert as much as possible to use <a href="http://support.microsoft.com/kb/83456" rel="noreferrer">message crackers</a>. They will save you no end of headaches. If there is only one piece of advice I could give you, this would be it.</li> <li>As long as you're using message crackers, also enable <code>STRICT</code>. It'll help you catch the Win16 code base using <code>int</code> where it should be using <code>HWND</code>, <code>HANDLE</code>, or something else. Converting these will greatly help with #9 on this list.</li> <li><code>hPrevInstance</code> is useless. Make sure it's not used.</li> <li>Make sure you're using Unicode-friendly calls. That doesn't mean you need to convert everything to <code>TCHAR</code>s, but means you better replace <code>OpenFile</code>, <code>_lopen</code>, and <code>_lcreat</code> with <code>CreateFile</code>, to name the obvious</li> <li><code>LibMain</code> is now <code>DllMain</code>, and the entire library format and export conventions are different</li> <li>Win16 had no VMM. <code>GlobalAlloc</code>, <code>LocalAlloc</code>, <code>GlobalFree</code>, and <code>LocalFree</code> should be replaced with more modern equivalents. When done, clean up calls to <code>LocalLock</code>, <code>LocalUnlock</code> and friends; they're now useless. Not that I can imagine your app doing this, but make sure you don't depend on <code>WM_COMPACTING</code> while you're there.</li> <li>Win16 also had no memory protection. Make sure you're not using <code>SendMessage</code> or <code>PostMessage</code> to send pointers to out-of-process windows. You'll need to switch to a more modern IPC mechanism, such as pipes or memory-mapped files.</li> <li>Win16 also lacked preemptive multitasking. If you wanted a quick answer from another window, it was totally cool to call <code>SendMessage</code> and wait for the message to be processed. That may be a bad idea now. Consider whether <code>PostMessage</code> isn't a better option.</li> <li>Pointer and integer sizes change. Remember to check carefully anywhere you're reading or writing data to disk&mdash;especially if they're Win16 structures. You'll need to manually redo them to handle the shorter values. Again, the least painful way to deal with this will be to use message crackers where possible. Otherwise, you'll need to manually hunt down and convert <code>int</code> to <code>DWORD</code> and so on where applicable.</li> <li>Finally, when you've nailed the obvious, consider enabling 64-bit compilation checks. A lot of the issues faced with going from 16 to 32 bits are the same as going from 32 to 64, and Visual C++ is actually pretty smart these days. Not only will you catch some lingering issues; you'll get yourself ready for your eventual Win64 migration, too.</li> </ol> <hr> <p><strong>EDIT</strong>: As @ChrisN points out, <a href="http://msdn.microsoft.com/en-us/library/aa314542%28VS.60%29.aspx" rel="noreferrer">the official guide for porting Win16 apps to Win32</a> is still available, and both fleshes out and adds to my points above.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload